Moderatorzy: moderatorzy2014, moderatorzy
- szymon_wolebez
- Posty: 1241
- Rejestracja: środa 03 lut 2010, 18:33
- Lokalizacja: WARSZAWA
- szymon_wolebez
- Posty: 1241
- Rejestracja: środa 03 lut 2010, 18:33
- Lokalizacja: WARSZAWA
Czy leci z nami moderator ? bo chyba ostatnie 8 postów jest nie na temat a ja dokładam 9.
OSD Remzibiego możliwe że też zostanie powiązane z MWC aczkolwiek napotkałem na jeden problem - GPS nadaje na prędkości 9600b, a MCW domyślnie ma prędkość 115kb. Nie ma problemu zmienić w kodzie MWC prędkości transmisji i dopisać dodatkowych procedur jednak przestaje wtedy działać konfigurator w którym nie ma możliwości zmiany prędkości (a przy prędkości 9600 z pewnością też by działał prawidłowo) więc trzeba by wymóc dodatkowy parametr w konfiguratorze - prędkość transmisji.
Gdyby wziąć pod uwagę OSD bez GPSu to nie ma wtedy tego problemu, potrzeba by tylko drobnej zmiany w sofcie przez Remzibiego.
OSD Remzibiego możliwe że też zostanie powiązane z MWC aczkolwiek napotkałem na jeden problem - GPS nadaje na prędkości 9600b, a MCW domyślnie ma prędkość 115kb. Nie ma problemu zmienić w kodzie MWC prędkości transmisji i dopisać dodatkowych procedur jednak przestaje wtedy działać konfigurator w którym nie ma możliwości zmiany prędkości (a przy prędkości 9600 z pewnością też by działał prawidłowo) więc trzeba by wymóc dodatkowy parametr w konfiguratorze - prędkość transmisji.
Gdyby wziąć pod uwagę OSD bez GPSu to nie ma wtedy tego problemu, potrzeba by tylko drobnej zmiany w sofcie przez Remzibiego.
od tego jest biblioteczka fastserial:miś pisze:Serial.print, czy Serial.write w ardu działa w czasie rzeczywistym, a nie na przerwaniach, więc wysyłając w ten sposób cokolwiek dłuższego niż kilka bajtów na 9600baud robisz straaaaaszne przestoje i lagi w pętli głównej.
http://code.google.com/p/arducopter/sou ... FastSerial
No tak ku... cholerne Arduino, jak by nie mogli pisać w normalnym przejrzystym C, kurde normalnie drugi Bascommiś pisze:Serial.print, czy Serial.write w ardu działa w czasie rzeczywistym, a nie na przerwaniach, więc wysyłając w ten sposób cokolwiek dłuższego niż kilka bajtów na 9600baud robisz straaaaaszne przestoje i lagi w pętli głównej.
Aktualnie mam pomysł żeby przełączać prędkość transmisji w zależności od pinu PC2 (A2), zwarte 115k i współpraca z MWConfig, rozwarte 9600 i przepisywanie RXa na TXa oraz wstrzykiwanie ramek z danymi akcelerometru, ale będę musiał coś wymyślić z tą prędkością wysyłania pakietów.
A i był bym zapomniał: Cholerne Arduino
Cholo, ale to kolejna biblioteka pożerająca zasoby i dokładająca kolejne bufory w RAM. Odbiór w oryginale jest na przerwaniach, więc wystarczy dopisać procedury nadawania, czyli obsługę przerwania TX oraz procedure inicjującą wysyłanie. Jako bufor można wykorzystać zadeklarowany już w kodzie bufor uint8_t s[128] bo zapisy do niego idą szybko i nie częściej jak co 20ms, a wysłanie 50 bajtów RS'em na 115200 to w sumie ok 5ms.
W 100% popieram. Niby C ale nie C, zakręcone jak wagon słoików.Radzu pisze:A i był bym zapomniał: Cholerne Arduino
Pzdr. -----MIŚ-----
uzywam biblioteki FastSerial w sofcie do quada i przy petli stabilizujacej 300hz wysylam sporo danych do osd Remzibiego (20hz), wiec nie jest tak zle z tym procesorem ;)
a odnosnie Arduino, Panowie chyba zapomnieli do czego zostalo stworzone. mial to byc prosty jezyk dla prostych ludzi do prostych zastosowan i moim zdaniem sprawdza sie pod tym wzgledem znakomicie
a gdyby nie prostota arduino nie bylo by pewnie wielu projektow opensource z MultiiWii wlacznie
a odnosnie Arduino, Panowie chyba zapomnieli do czego zostalo stworzone. mial to byc prosty jezyk dla prostych ludzi do prostych zastosowan i moim zdaniem sprawdza sie pod tym wzgledem znakomicie
a gdyby nie prostota arduino nie bylo by pewnie wielu projektow opensource z MultiiWii wlacznie