Wątek: Kontrolery Arduino

[vito_zm]

Dzięki 3.14ter, już działa. Jeśli damy powrót karetki i wyślemy AT to odpowie OK. Jeśli ustawimy zarówno NL i CR to na komendę AT odpowie -5. Niby trywialna sprawa, ale zabrało to trochę czasu. Teraz mogę ustawić na większą prędkość nadawania. Jeszcze raz dziękuje za pomoc i za zabranie Twojego czasu, dzięki.

[vito_zm]

Po ostatnich moich doświadczeniach z transmisją radiową (bluetooth) wpadłem na pomysł aby zastosować tę technikę do innych kontrolerów. Chcę wykonać testy z SimOUT oraz modułem XM-15. Połączenie SimOut z pc wymaga konwertera USB-RS232. Mam zamiar usunąć MAX232 oraz jego otoczenie i zastąpić go modułem XM-15. Ponieważ moduł ma regulator napięcia to nie potrzeba dodatkowych rezystorów redukujących napięcie 5V.
Z tego co zrozumiałem to możemy takich modułów XM-15 mieć kilka współpracujących z modułem USB (bluetooth) w pc wystarczy tylko komendami AT zmienić nazwy i ustawić parametry transmisji szeregowej. W platformie HSC ustawiamy tylko odpowiedni port COM.
Reasumując opłaciło się drążyć temat, ponieważ można to wykorzystać także w innych kontrolerach. Dzięki 3.14ter za pomoc w tym temacie.

[vito_zm]

Zauważyłem dzisiaj w wątku http://il2forum.pl/index.php/topic,17010.new.html#new  #35, że kolega sznink zrobił u siebie to samo co 3.14ter tzn. zastosował to samo filtrowanie x2. Ma problemy z zakresami, ale może proponowany moduł przez 3.14ter rozwiąże ten problem.

[Darth_Worm]

Przepraszam za offtopa, czy jest szansa na rozwinięcie tematu CY8CKIT-059 . Czy raczej potraktować zapowiedź  jako egzotyczne wcięcie? Na aliexpresie moduły 049 chodzą po 6- 7 dolców.

[3.14ter]

Narazie jedziemy z projektem na Arduino. Jeśli nie uda mi się stworzyć pełnego projektu na PSoC5LP, to przynajmniej postaram się napisać podstawową bibliotekę, podobną do tej na Arduino.
Uwaga!
049 != 059
049 to PSoC4, 059 PSoC5LP

[Darth_Worm]

Jak duża różnica jest między 049, a 059 jeśli chodzi o przydatność do naszych celów?

[3.14ter]

Dość istotna: 049, czyli procesor typu PSoC4 nie posiada USB.

[Darth_Worm]

Dziękuję za odpowiedź

[vito_zm]

Zrobiłem kolejne testy. Zmieniłem szybkość transmisji na 115200 oraz nazwę MX-15. Teraz pracuje z MegaJoy z prędkością 115200. Tutaj wystąpił ciekawy problem. Jeśli wpiszemy komendę AT+UART=115200,1,0 to jest problem w monitorowaniu MegaJoy programem PuTTY (tekst jest nieczytelny, generalnie bałagan). Musi być deklaracja  115200,0,0. Myślałem może, że to dotyczy bitu STOP, ale nie mam pojęcia dlaczego tak się dzieje. Fabryczne ustawienie MX-15 to 9600,0,0 i w tym ustawieniu pracuje także z MegoJoy przez PuTTY. Ważne, że pracuje może ktoś to wyjaśni.
Zainstalowałem program Termite 3.2. Jest bardzo prosty i niezawodny. Można komunikować się po bluetooth pc (Termite 3.2) z UNO (szeregowy monitor) programem do konfiguracji modułu MX-15.
Do monitorowania przy pomocy MX-15 oraz PuTTY używałem starszych wersji MegoJoy. W najnowszym programie MegaJoy odblokowanie #define DEBUG_UART   nie pomogło, ale to jest to zrobienia.
Chcę w przyszłosci stosować moduły MX-15 do komunikacji z SimOUT. Zastanawiam się nad problemem konfiguracji oraz parowania większej liczby tych modułów. Czy należy na początek zmienić nazwy oraz przepływność (w zależności od potrzeb) a później parować z pc. Każdy moduł będzie komunikował się po innym COM oraz z innymi parametrami. Czy tak to należy zrobić.

[sznink]

Na wstępie chciałbym pogratulować kolegom tworzącym ten wątek - kawał porządnej profesjonalnej roboty. Jak znajdę chwilę czasu to się z chęcią przyłączę .

Zauważyłem dzisiaj w wątku http://il2forum.pl/index.php/topic,17010.new.html#new  #35, że kolega sznink zrobił u siebie to samo co 3.14ter tzn. zastosował to samo filtrowanie x2. Ma problemy z zakresami, ale może proponowany moduł przez 3.14ter rozwiąże ten problem.

Niestety nie korzystałem z własnego kodu, a z możliwości jaką udostępnia MMJoy2. Z moich testów wynika, że ta funkcjonalność bardzo dobrze sprawdza się w przypadku sensorów Alegro A1302. Natomiast dla potencjometrów jest już gorzej, co nie znaczy że kompletnie nie nadaje się do użytku. Dzięki włączonemu filtrowaniu mogę używać jednego z potencjometrów na dźwigni przepustnicy joysticka Saitek X45 (oryginalnie przeznaczonego dla steru kierunku - ja go używam jako zoom). Bez filtrowania w moim przypadku ten potencjometr był bezużyteczny.

Chmm. Przypomniało mi się, że kiedyś mega_mozg_13 (twórca MMJoy2) coś pisał na temat implementacji. Poszukałem i ... znalazłem (http://simhq.com/forum/ubbthreads.php/topics/3902564/Re:_MMJoy_-_Build_your_own_USB#Post3902564):

Look here: https://code.google.com/p/mmjoy/source/browse/
Folder: common_libs
File: MMJoy.c
Function: Axis_Filter()

PS: All project materials are open source.

Read more: http://simhq.com/forum/ubbthreads.php/topics/3899105#ixzz4H3pbHWPw
Follow us: @SimHQ on Twitter | SimHQ on Facebook

Niestety od tego posta projekt zmienił lokalizację i gdzie teraz są kody źródłowe w tej cyrylicy? 

[vito_zm]

Niestety nie korzystałem z własnego kodu, a z możliwości jaką udostępnia MMJoy2.

Ja także przeszedłem ten etap tzn. MMJoy2,  ale w celach poznawczych. Trochę o tym pisałem na początku tego wątku. Pojawił się 3.14ter i sytuacja zmieniła się radykalnie. Nie spotkałem na forach zbyt dużo specjalistów tej klasy. Dla nas jest to duża szansa, że powstanie coś nowego i to z najwyższej półki.

[3.14ter]

Zrobiłem kolejne testy. Zmieniłem szybkość transmisji na 115200 oraz nazwę MX-15. Teraz pracuje z MegaJoy z prędkością 115200. Tutaj wystąpił ciekawy problem. Jeśli wpiszemy komendę AT+UART=115200,1,0 to jest problem w monitorowaniu MegaJoy programem PuTTY (tekst jest nieczytelny, generalnie bałagan). Musi być deklaracja  115200,0,0. Myślałem może, że to dotyczy bitu STOP, ale nie mam pojęcia dlaczego tak się dzieje. Fabryczne ustawienie MX-15 to 9600,0,0 i w tym ustawieniu pracuje także z MegoJoy przez PuTTY. Ważne, że pracuje może ktoś to wyjaśni.

http://www.linotux.ch/arduino/HC-0305_serial_module_AT_commamd_set_201104_revised.pdf
Strona 8 i 9. W skrócie, 0 jako drugi parametr oznacza 1 bit stop, następne 0 to brak parzystości. Czyli standardowe parametry jakie używane są w terminalach.

Zainstalowałem program Termite 3.2. Jest bardzo prosty i niezawodny. Można komunikować się po bluetooth pc (Termite 3.2) z UNO (szeregowy monitor) programem do konfiguracji modułu MX-15.
Do monitorowania przy pomocy MX-15 oraz PuTTY używałem starszych wersji MegoJoy. W najnowszym programie MegaJoy odblokowanie #define DEBUG_UART   nie pomogło, ale to jest to zrobienia.
Chcę w przyszłosci stosować moduły MX-15 do komunikacji z SimOUT. Zastanawiam się nad problemem konfiguracji oraz parowania większej liczby tych modułów. Czy należy na początek zmienić nazwy oraz przepływność (w zależności od potrzeb) a później parować z pc. Każdy moduł będzie komunikował się po innym COM oraz z innymi parametrami. Czy tak to należy zrobić.

U mnie odblokowanie DEBUG_UART uruchamia komunikację. Problem leży pewnie gdzieś indziej.
Udało mi się sparować dla moduły HC-05. Pojawiły się dwa nowe porty COM. Oprócz nazw każdy moduł ma jeszcze swój adres bluetooth, coś jak adres MAC karty sieciowej. Teoretycznie każde urządzenie powinno mieć swój indywidualny numer, ale jak wiemy, producenci dalekowschodni często robią różne skróty i może się okazać, że dwa moduły będą miały taki sam. W takim wypadku adres można zmienić komendami AT.

A ja tymczasem czekam na zamówione czujniki halla i przetworniki AD do testów. Układ na 32U4 ciągle ewoluuje. Poczekam aż przyjdą płytki z małym analogowym kalibratorem osi i przetestuję go w praktyce.

[vito_zm]

Dzięki za wyjaśnienia, to tłumaczy zachowanie PuTTY (2 bity STOP zamiast 1). Sprawdziłem jeszcze raz ostatnią wersję MegaJoy oraz wpływ #define DEBUG_UART.
Jeśli //#define DEBUG_UART to kursor w PuTTY na początku i brak informacji, w Termite 3.2 nic się nie dzieje.
Jeśli #define DEBUG_UART (odblokowany) to w PuTTY bez zmian natomiast w Termite 3.2 przesyłane są informacje.
W przedostatniej wersji MegaJoy jest ok. Jeśli jest aktualna wersja to spróbuję jeszcze raz ją pobrać.
Mam ciekawy problem związany generalnie z bluetooth.  MX-15 ma swoje 2 porty OM12 i 13 i po COM12 pracuje z MegaJoy. Chciałem ten sam MX-15 zmusić do pracy z urządzeniem SimOUT, które komunikuje się z pc przez konwerter USB-RS232. Na wejściu SimOUT jest MAX232, który zamienia poziomy sygnałów ma TTL.  SimOUT jest sterowany przez platformę HSC, gdzie można konfigurować RS232. Nie udało się nawiązać komunikacji, jest to pokazane na zdjęciu.



Teoretycznie powinno działać, ale może każdy MX-15 chce komunikować się z swoim kontrolerem, czyli w moim przypadku drugi MX-15. Może te COM12, 13 są zarezerwowane tylko dla MegaJoy a nowy MX-15 z nowymi COM dla SimOUT.               

[vito_zm]

Sytuacja z define DEBUG_UART już się wyjaśniła jest o.k. W ostatniej wersji MegaJoy przy testach z MX-15  zmieniłem szybkość transmisji na 9600, dlatego w PuTTY nie działało, ponieważ był ustawiony na 115200. Teraz dopiero sobie o tym przypomniałem.

[3.14ter]

Nie znam schematu płytki SimOut, ale z tego co widać na fotkach, to ominąłbym całą część RS232, wyjął scalak MAX232 z podstawki i do odpowiednich pinów podłączył moduł bluetooth.
Naturalnie, jeśli PuTTY jest połączone z COM12, to SimOut nie da rady się podłączyć, port jest zajęty.
MX-15, jak i HC-05 może pracować jako slave (standardowe ustawienie, sam nie nawiązuje połączenia, tylko może je odebrać), albo master. Jeśli mamy dwa moduły, jeden slave, a drugi master to można je połączyć razem. Akurat w naszym przypadku nie jest to potrzebne, bo chcemy komunikować się z PC.
W tym przypadku adapter USB-Bluettoth wpięty do PC będzie pracował jako master, a MX-15 jako slave.