Elvis

Co to za układ 788TV? nie mogę znaleźć datasheeta. Domyślam się, że stabilizator, ale na jakie napięcie? Musisz pamiętać, że na każdym stabilizatorze następuje spadek napięcia, np. 7805 musi być zasilany ok. 7V, żeby dawał 5V na wyjściu. Jeśli jest to układ LDO, to mniejszy jest spadek, ale nadal jest. Akumulatory mają tylko 4,8V, więc zastanawiam się ile ma być na wyjściu? Kolejna sprawa - 4,8V to jest napięcie znamionowe, będzie mniejsze jeśli się częściowo rozładują, poza tym mniejsze jeśli obciążysz je silnikami. Jednym słowem - chyba za małe dajesz napięcie. Co do procesora to możesz użyć ATmega8L i zasilać niższym napięciem.

Wpisz w google "boost converter" lub "step-up converter"

Z programatorem jest jeden problem - napięcie 3.3V. Nie można go podłączyć do 5V bo można procek upalić. Na schemacie jest 3.3V, ale moduł nie wystawia nigdzie 3.3, w dodatku musi być zasilany z 5V. Więc taki programator wymagałby własnego zasilania, albo projektując płytkę pod moduł trzeba uwzględnić 2 stabilizatory 5V i 3.3V. Ogólnie pomysł jest dobry, chociaż nie taki prosty. Ale chyba wybiorę moduł kakami zamiast propoxa. Tyle że lpc2148, nie 2142. [ Dodano: 19 Sie 09 06:29 ] Może nie będzie tak źle. Wygląda na to, że piny potrzebne do programowania tolerują 5V. Więc można zastosować 5V zasilanie dla programatora. Trzeba będzie sprawdzić jak to działa.

Moduł w propox jest jeszcze nieco tańszy - 79zł + vat. Co prawda LPC2138 zamiast 2148, i nie ma baterii dla RTC. Planowałem następny artykuł o takiej wersji. Konieczny jest konwerter RS232 - 3.3V. Można dodać jeszcze resetowanie procka przez RS, łatwiej wtedy wgrywać. Ogólnie to LPC2000 Flash Utility nie jest już rozwijany i bywają z nim problemy. Lepiej użyć FlashMagic.

Tak, będą przykładowe programy. Kompilatory jak najbardziej są. Nawet CrossStudio bazuje na darmowym gcc. Problem z darmowymi kompilatorami to skonfigurowanie środowiska - wcale nie takie łatwe na początek. CrossStudio daje ten komfort, że w 1 dzień można mieć działający program na ARM. Natomiast uruchomienie eclipse + yagarto trochę zajmuje (długo czytałem dokumentację zanim połączyłem się z prockiem). Planuję napisać 2 artykuły: * pierwszy, jak szybko zacząć przygodę z arm-ami * drugi jak tanio zacząć Niestety tanio znaczy trudniej

Tutaj powstaje artykuł o programowaniu LPC21xx: https://www.forbot.pl/forum/topics20/jak-rozpoczac-przygode-z-arm-ami-wersja-szybka-choc-droga-vt2258.htm#17383

Na początek potrzebujemy procesor. W przypadku AVR-ów było łatwo. Kupowaliśmy układ w obudowie DIP i mogliśmy pracować. Niestety ARM-y w takich obudowach nie występują. Jesteśmy więc skazani na zaprojektowanie własnej płytki i wlutowanie układu, albo kupienie płytki z układem już wlutowanym. Ja proponuję to drugie rozwiązanie. Wybór modułu z procesorem W dalszej części będę opisywał pracę z układem LPC-2148. Wykorzystywany moduł to: http://www.shop.kristech.eu/product_info.php?cPath=21_26&products_id=87 Jeśli jego cena jest za wysoka można skorzystać z innego, np.: http://www.shop.kristech.eu/product_info.php?cPath=21_26&products_id=89 – z układem 2103 http://www.propox.com/products/t_136.html – z układem LPC2138 Moduły olimex-a (dostępne na stronie kristech.eu) mają tę zaletę, że na płytce znajdziemy od razu gniazdo JTAG-a. Z drugiej strony moduł propox jest sporo tańszy. Jeśli będzie zainteresowanie opiszę przykładowy projekt na płytce propox-a. W tej chwili mam moduł na LPC-2148, więc zamierzam go wykorzystać. Na początek słowo o rodzinie układów LPC-21xx. Układy zaprojektowane zostały przez Philips, aktualnie produkowane są przez NXP. Wszystkie opierają się na jądrze ARM7TDMI. Procesory zasilane są napięciem 3.3V, niektóre wyprowadzenia tolerują napięcie 5V, jednak nie można tym napięciem zasilać procesorów. Procesor LPC-2103 jest przykładem starszej rodziny procesorów ARM – wymaga aż dwóch napięć zasilających – 3.3V dla peryferiów i 1.8V dla jądra. Na szczęście moduły wyposażone są w stabilizatory. Moduły można zasilać napięciem 5V (pamiętając, że procesory pracują na niższym). Procesory LPC2148 i LPC2138 są dość podobne. LPC2148 jest nowszą wersją układu, posiada obsługę USB. Natomiast LPC2103 jest znacznie słabszym układem. Na początek kilka parametrów układów, tak aby porównać z AVR. Procesory LPC2138 i LPC2148: * 32-bitowy rdzeń * 512kB pamięci Flash * 32kB/42kB pamięci RAM * częstotliwość zegara do 60MHz * zegar RTC z możliwością podłączenia zewnętrznej baterii podtrzymującej * szereg interfejsów komunikacyjnych UART, SPI, I2C, USB Procesor LPC2103 różni się głównie dostępną pamięcią: * 32kB pamięci Flash * 8kB RAM Wybór programatora Przyjmijmy, że już zdecydowaliśmy się, który układ chcemy użyć. Kolejny problem to programator. Układy LPC21xx mogą być programowane na dwa sposoby: * przez interfejs JTAG * przez RS-232 Programowanie przez JTAG Do tworzenia oprogramowania to rozwiązanie jest bardzo wygodne. Po pierwsze transmisja jest znacznie szybsza niż przez RS232 (a przesłanie 512KB długo trwa). Po drugie mam możliwość debugowania programu. Możemy ustawiać pułapki (breakpoints), odczytywać wartość zmiennych, itd. Wadą tego rozwiązania jest konieczność zakupu interfejsu. Jeśli jednak chcemy na poważnie zainteresować się programowaniem ARM-ów taki interfejs może być niezbędny. Do wyboru są 2 główne opcje: * JTAG po złączu równoległym * JTAG po USB Programator przez złącze równoległe (drukarki) jest sporo tańszy, niestety takie złącze rzadko jest montowane w laptopach. Jeśli jesteśmy szczęściarzami posiadającymi taki komputer, możemy kupić jeden z interfejsów: http://www.shop.kristech.eu/product_info.php?cPath=57&products_id=69 http://www.propox.com//products/t_122.html Można też spróbować samemu zmontować taki interfejs. Jeśli tak jak ja nie mamy złącza drukarkowego w komputerze pozostaje tylko interfejs przez USB. Ja używam interfejsu Olimex-a: http://www.shop.kristech.eu/product_info.php?cPath=57&products_id=97 Nie jest tani, jeśli uda nam się kupić inny, powinien być równie dobry. Polecam stronę: http://www.freddiechopin.info/index.php/pl/projekty/49-arm-jtag-rev01-rev02 Jest tam opisany JTAG własnej konstrukcji, znacznie tańszy niż gotowe rozwiązanie. Ja w dalszym ciągu będę opisywał pracę przez Olimex JTAG, jednak inne układy działają podobnie. Programowanie przez RS232 Jest to niewątpliwie najtańsza opcja programowania. Wygląda to podobnie jak w przypadku AVR przez ISP – wgrywamy program i obserwujemy, czy działa. Nie mamy niestety możliwości debugowania programu. Jest to dobre rozwiązanie, gdy program jest już gotowy. Pisząc program JTAG jest nieocenionym narzędziem. Wybór kompilatora Gdy mamy już sprzęt warto pomyśleć o kompilatorze. Istnieje możliwość programowania w środowisku Eclipse oraz kompilacji w gcc, jednak jest to nieco skomplikowane (polecam opis na stronie http://www.freddiechopin.info/ ). My, aby szybko zacząć wykorzystamy CrossStudio. Kompilator dostępny jest na stronie: http://rowley.co.uk/arm/index.htm Do nauki wykorzystamy 30-dniową wersję testową. Po tym czasie konieczny będzie zakup licencji (koszt 150$) lub zmiana kompilatora. Co potrzeba na początek Podsumowując, aby szybko zacząć, potrzebujemy: 1)moduł z procesorem LPC-H2148 – koszt 203 zł 2)interfejs ARM-USB-OCD – koszt 318,50 zł 3)kompilator CrossWorks for ARM – koszt 150$ (30-dniowa wersja darmowa) Więc na początek potrzebujemy ok. 520zł, do tego dojdzie koszt płytki uniwersalnej, elementów oraz ew. kompilatora. Jeśli jest to za duży koszt, i tak zachęcam do lektury artykułu. Jeśli będzie zainteresowanie, postaram się przygotować informację o tym jak zacząć pracę z ARM-ami znacznie taniej (na początek koło 100 zł, więc jak widać sporo taniej). Jednak taniej oznacza trudniej, coś za coś. Instalacja kompilatora Kompilator pobieramy ze strony firmy Rowley: http://rowley.co.uk/arm/index.htm . Po prawej stronie są linki ("Latest Downloads"->Version 2.0 for Windows). Samej instalacji nie będę opisywał, nie wyróżnia się niczym szczególnym. Po instalacji uruchamiamy program i dokonujemy aktywacji licencji 30-dniowej. Program przygotuje kod i wyśle go (za pomoca maila) do producenta. Zwrotnie dostaniem email z naszym kodem licencji. Jeśli będą jakieś pytania opiszę ten etap dokładniej, wydaje mi się jednak, że nie powinno być z tym problemu. Następny etap to instalacja tzw. pakietu dla naszego procesora. Kompilator CrossWorks (czy też CrossStudio, sam nie wiem jak on się nazywa) może obsługiwać rożne procesory, m. in. LPC2xxx, STM32, i wiele innych. Musimy jednak sami pobrać odpowiednie pakiety. Wybieramy opcję Tools->Install Packages... i wyszukujemy pakiet NXP LPC2000 (typu CPU Support Package). Naciskamy Next i gotowe. Po uzyskaniu licencji (i aktywowaniu) oraz instalacji pakietu dla LPC2000 jesteśmy gotowi do pracy. Podłączenie Najpierw instalujemy driver-y od JTAG-a. Powinny być na dołączonej płycie. Jeśli nie pobieramy z sieci sterowniki dla układu FT232. Podłączamy JTAG, sprawdzamy czy komputer poprawnie wykrył urządzenie USB. Podłączenie JTAG-a do modułu z procesorem jest dziecinnie proste. Gniazdo jest na płytce modułu, kabel jest dołączony do JTAGa. Pozostaje podłączyć zasilanie. Normalnie moduł jest zasilany z płyty głównej. My na początek wykorzystamy zainstalowane na nim gniazdo USB. Bierzemy zwykły kabel USB typu A-B (taki jak do podłączenia drukarki) i łączymy moduł z komputerem. Komputer wyświetli komunikat o nierozpoznanym urządzeniu. Nie przejmujemy się tym na razie, sprawdzamy czy diody na module świecą. Hardware mamy gotowy. Komunikacja z procesorem Uruchamiamy CrossStudio i sprawdzamy, czy mamy komunikację z procesorem. Zaletą, ale i wadą środowiska CrossStudio jest jego konfigurowalność. Wszystko można pozmieniać, poprzesuwać. Z drugiej strony na początku ciężko się połapać co gdzie jest. Jeśli po prawej stronie nie są widoczne okna „Targets” oraz „Properties Winows” wyświetlamy je wybierając opcję View->Targets oraz View->Properties Window. Układ powinien być taki jak na screenie zamieszczonym wcześniej. W okienku Targets wybieramy „Olimex ARM-USB-OCD”, klikamy prawym klawiszem i wybieramy „Connect”. Jeśli mamy szczęście nazwa interfejsu zostanie pogrubiona, co świadczy o dokonaniu połączenia. Ja miałem problemy z połączeniem, w końcu udało się po zmianie ustawień (wybieramy nasz interejs w oknie Targets, ustawienia zmieniamy w oknie „Properties”): Adaptive Clocking: Yes JTAG Clock Divider: 4 Po zmianie ustawień ponownie wybieramy Connect, tym razem połączenie następuje bez problemu. Pierwszy program Wybieramy opcję File->New Project. W oknie Categories wybieramy NXP (jeśli go nie ma, wracamy do punktu „instalacja pakietów). Następnie wybieramy z Project Templates wybieramy „An executable for NXP LPC21xx” (trzecia opcja od góry). W polu Name wpisujemy nazwę projektu oraz wybieramy, gdzie nasz projekt zostanie zapisany. Musimy pamiętać o zmianie katalogu docelowego – najlepiej utwórzmy nowy folder dla nowego projektu. Inaczej wszystko wyląduje w jednym domyślnym folderze. Klikamy Next. Tutaj zmieniamy częstotliwość kwarca (moduł LPC-H2148 ma kwarc 12MHz) i wybieramy procesor LPC2148. Pozostałe opcje możemy zostawić bez zmian. Kolejne okno pozwala na wybór plików, które utworzy dla nas środowisko. Odznaczamy pliki LPC210x.c, VIC.c i VIC_irq_handler.s. Są one związane z biblioteką zadań (taki mini RTOS), ale my na razie tworzymy pierwszy, prosty program. Musimy się za to upewnić, czy pliki crt0.s, Philips_LPC210X_Startup.s i Philips_LPC210X_Target.js są wybrane. Klikamy next. Tutaj możemy wybrać konfiguracje, które zostaną utworzone. Potrzebować będziemy tylko „ARM Flash Debug” oraz „ARM Flash Release”. Resztę możemy wyrzucić (albo zostawić jeśli chcemy się nimi pobawić). Naciskamy Finish i tworzymy pierwszy projekt. Ekran powinien wyglądać następująco (jeśli okno widoku projektu po prawej nam się zapodziało wybieramy View->Project Explorer). W oknie Project Explorer widoczne są 3 „foldery” Project Propoerties – tutaj można będzie zmieniać ustawienia naszego projektu, na razie zostawiamy bez zmian Source Files – miejsce na pliki z naszym programem, chwilowo puste System Files – pliki utworzone przez środowisko (mogę napisać opis - dla dociekliwych) Mamy projekt, czas napisać program. Z menu File wybieramy opcję New. Pamiętamy o wybraniu pliku typu „C File (.c)”, wpisujemy nazwę „main” (bez .c na końcu), przyciskamy „OK”. Następnie wpisujemy kod pierwszego programu: #include <targets/lpc2148.h> #define _BV(x) (1<<x) void main() { volatile int i; IO1DIR |= _BV(24); while (1) { for (i=0;i<1000000;i++) ; IO1SET = _BV(24); for (i=0;i<1000000;i++) ; IO1CLR = _BV(24); } } Naciskamy F7 (kompilacja), nie powinno być błędów. Pozostaje wgrać nasz pierwszy program. Naciskamy Ctrl+F5 i po chwili zielona dioda modułu powinna zacząć mrugać. Program działa Nie ukrywam, że miałem pewne problemy z konfiguracją środowiska – musiałem ręcznie zainstalować pakiet dla LPC2100. Jednak na koniec udało się bez problemu uruchomić program – jeśli ktoś będzie próbował uruchomić, proszę o info w razie problemów. Opis programu: IO1DIR – to odpowiednik DDRx na AVR. Ustawienie bitu sprawia, że port działa jako wyjście. IO1SET – ustawia bit na porcie wyjściowym, odpowiada PORTx |= bit IO1CLR – kasuje bit, odpowiada PORTx &= ~bit

Radiowa transmisja danych, czyli robot zdalnie sterowany cz.4 (moduły RFM12B/868D) Ostatnie z testowanych modułów to para RFM12B. Oba pracują na częstotliwości 868MHz. Wyższa częstotliwość zmniejsza nieco zasięg komunikacji, ale w zamian anteny mogą być dwa razy krótsze. Moduły łączą się z procesorem za pomocą interfejsu SPI. Dzięki temu łatwo jest oprogramować komunikację, czy to z wykorzystaniem sprzętowego interfejsu, czy programowego. Moduły RFM12B produkowane są przez tego samego producenta co HM-T868S. Dodatkowe informacje o modułach oraz przykładowe kody dostępnie są na stronie: http://www.hoperf.com/ . Testowane moduły są zasilane napięciem 3.3V i nie mogą pracować bezpośrednio z układami 5V. Ja rozwiązałem problem stosując układ Atmega8L i zasilanie niższym napięciem. Producent podaje informacje o modułach RFM12 (bez B), które mogą współpracować bezpośrednio z napięciami 5V – nie wiem gdzie są dostępne, ale dopasowanie napięć to duży atut modułów. Na stronie producenta podany jest przykładowe program do testowania modułów. Niestety proste przepisanie programów nic nie daje – po pierwsze konfiguracja w nich przewiduje częstotliwość 433MHz, po drugie w programie są błędy. Po przeczytaniu dokumentacji i zmianie ustawień 868MHz oraz poprawieniu błędów mi udało się uruchomić program który: wysyła co sekundę pakiet danych odbiornik ciągle nasłuchuje, po odebraniu poprawnych danych zapala diodę Transmisja przebiegała bez problemów. Testowałem pakiety o długości od 16 do 256 bajtów. Moduły wykonują całą nieprzyjemną robotę, którą w przypadku CC1000 trzeba było robić programowo, czyli: sam wykrywa preambułę danych znajduje początek danych i rozpoznaje bajty startu ramki odbiera i w wysyła dane dostarczone przez SPI Podsumowując, uważam moduły za bardzo udane. Obsługa jest o wiele łatwiejsze niż CC1000, są tylko nieznacznie droższe od prostych modułów HM-T868S, zapewniają dwukierunkową komunikację. Jako jedyną dostrzeżoną wadę mogę wymienić zasilanie napięciem 3.3V. Jednak zmiana na RFM12 powinno rozwiązać tę niedogodność. Na elektrodzie spotkałem się z negatywnymi opiniami o tych modułach, jednak z moich doświadczeń wynika, że moduły te są godne polecenia. Podsumowanie artykułu Moduły HM-T868S / HM-R868S – dobry wybór dla początkujących, przesył jedynie krótkich pakietów danych, transmisja jednokierunkowa. Dobry wybór, aby wykonać zdalne sterowanie, czy zdalny odczyt danych z czujnika. Moduły z układem CC1000 – układy raczej dla profesjonalistów. Skomplikowana obsługa, wymagają wielu linii procesora, wiedzy o transmisji radiowej, zajmują dużo czasu i pamięci procesora. Poza tym są drogie. Moduły RFM12B – bardzo dobry wybór, aby zbudować modem radiowy. Są tanie, a zarazem skuteczne. Pozwalają na transmisję nawet całkiem długich pakietów. Uwzględniając w protokole transmisji adresu urządzeń można zrealizować komunikację więcej niż dwóch urządzeń.

Dołączyłem do artykułu kod w C. U mnie działa.

W EP był cały cykl o programowaniu STM32. Jednak chodziło mi o artykuł dla osób które chcą zacząć. Czyli opisać co jest potrzebne, jak zainstalować środowisko, jak skompilować i uruchomić prosty program. Dalej każdy sobie poradzi To co widziałem w EP było bardziej o kolejnych funkcjach biblioteki do STM32. Nie lubię tej biblioteki, nie dość, ze jest brzydka, to jeszcze działa wolniej, niż bezpośrednie pisanie do rejestrów. [ Dodano: 18 Sie 09 09:18 ] Widzę, że chociaż niewielkie, ale zainteresowanie jednak jest. To teraz kolejny problem: Czy lepszy artykuł o tym jak najtaniej poznać army, czy jak najszybciej. Do tego pytanie czy LPC21xx, czy STM32. Jak chodzi o pierwsze pytanie, to zastanawiam się, czy opisać jak rozpocząć z użyciem CrossStudio - jest to płatne środowisko, ale 30-dniowa wersja jest darmowa. Zaletą jest duże ułatwienie. Instalacja CrossStudio jest tak łatwa jak AVRStudio, czy każdego innego programu. Natomiast zainstalowanie toolseta, eclipse, konfiguracja i uruchomienie całości to wcale niełatwe zadanie. Kolejna sprawa to wybór procesora. Niewątpliwie przyszłość to cortex, jednak STM32 ma zaletę, a jednocześnie wadę - bibliotekę producenta. Jest ona bardzo dobra, ale niestety zupełnie nie przypomina programowania innych procesorów. Funkcje, np. konfiguracji portów bazują na potwornie rozbudowanych strukturach, które trzeba wypełnić, a następnie przekazać jako parametr. Nie jest to wada samej biblioteki, raczej pewien styl programowania. Jednak na początku wcale nie jest łatwo się do tego przyzwyczaić (nie ukrywam, że mnie ta biblioteka odrzuca). W przypadku LPC21xx jest nieco łatwiej. Myślałem nad artykułem w rodzaju - jak to co robię na AVR zrobić na ARM-ie. Tutaj jest sporo łatwiej, przykładowo zamiast DDRA rejestr nazywa się IO0DIR. Działa właściwie tak samo.

Co jakiś czas pojawiają się na forum głosy o programowaniu ARM-ów. Zastanawiam, się ile osób byłoby zainteresowanych tematem i czy warto taki kurs przygotować. Ja od dość dawna programuję LPC21xx, ale coraz bardziej interesują mnie Cortex-y. Myślałem, czy nie opisać jak rozpocząć przygodę w świecie ARM.

Zamiast samemu robić płytkę eval można też zamówić coś gotowego. Propox ma moduł dla STM32 http://www.propox.com/products/t_174.html Pod adresem: http://www.shop.kristech.eu/index.php?cPath=68 są płytki olimexa. Ja mam http://www.shop.kristech.eu/product_info.php?cPath=68&products_id=142 - całkiem sympatyczna, żeby procesor lepiej poznać. A co do dyskusji, który procesor lepszy, to LPC21xx nie polecam początkującym Wszystko wskazuje na to, że ARM7 to już przeżytek, teraz świat podbija Cortex. Więc STM32 to dobry pomysł, chyba że ktoś jest miłośnikiem NXP i woli LP17xx. A przy okazji - NXP wysyła darmowe próbki LPC1766.

Ja chętnie na takie zawody Co prawda jeszcze nie mam na nie robota, ale jak termin będzie odpowiedni, to coś powinienem mieć. Może jeszcze jednego kumpla namówię, żeby tego typu robota skonstruował.

Dobrze rozumiesz z OCR0 i TCNT0, co prawda powinno być chyba 250-1, ale to bez większego znaczenia. Jakiego używasz procesora? Bo na atmedze16 ten kod daje dzielnik /64, ale na m128 /32. [ Dodano: 16 Sie 09 10:49 ] dla atmegi128 u mnie działa poprawnie: TCCR0=_BV(WGM01)|_BV(CS02); OCR0= 250-1; //count to 250 pulses (0,001s) [ Dodano: 16 Sie 09 11:41 ] Uruchomiłem na m16. Jedyna różnica u mnie to zegar 8Mhz, więc do OCR wpisałem 124. Działa bardzo ładnie, poszukaj czy poza tym kodem który przysłałeś nie ma błędu.

Ja bym proponował zostawić zliczanie na Timer1. Pozostaje problem jak sterować 2 diodami przez jedno wyście Timer2. W kodzie, który zaproponował Zuk druga dioda zawsze dostaje 255-jasność_diody_1, więc możesz na wyjściu Timer2 zrobić następująco: 1) sterowanie diodą blue bezpośrednio 2) sterowanie diodą red przez negator (np. 74hc04)

Radiowa transmisja danych, czyli robot zdalnie sterowany cz.3 (moduł CC1000PP-433) Kolejny testowany moduł oparty jest na układzie CC1000. Opisywany moduł oraz więcej informacji o nim dostępne jest pod adresem http://www.shop.kristech.eu/product_info.php?cPath=55&products_id=93. Polecam również przeczytać informację o zestawie uruchomieniowym do modułu: http://www.shop.kristech.eu/product_info.php?cPath=55&products_id=203. Do testowania transmisji niezbędne są dwa moduły. Oba podłączone zostały do płytek opisywanych poprzednio. Jako anteny wystarczają przewody o długości 16 cm. Moduły nie mogą być zasilane napięciem wyższym niż 3,6V więc do pracy ze zwykłym AVR konieczne jest zastosowanie konwerterów napięcia. Ja dla uproszczenia wykorzystałem procesor Atmega8L oraz zasilanie niższym napięciem. Układ CC1000 komunikuje się z procesorem za pomocą, aż dwóch interfejsów. Pierwszy wykorzystuje 3 linie (PALE, PDATA, PCLK) i służy do konfiguracji pracy modułu. Drugi używa 2 linii (DIO, DCLK) i zapewnia przesył transmitowanych danych. W sumie potrzebne jest aż 5 linii procesora, z tego jedna obsługująca przerwanie (producent podaje sposób podłączenia wykorzystując mniejszą liczbę linii, ale sam poleca używanie 5 linii). Skomplikowane podłączenie okazało się jednak tylko początkiem problemów. Prawdziwym wyzwaniem okazało się przygotowanie programu do sterowania modułami. Pierwszy krok to skonfigurowanie modułów. Producent układów dostarcza specjalny program, który pozwala na ustalenie wartości rejestrów – jest ich około 30! Gotowy program jest niewątpliwie ułatwieniem, jednak na początku już sama liczba jego opcji jest przytłaczająca. Program konfiguracyjny dostępny jest pod adresem http://focus.ti.com/docs/toolsw/folders/print/smartrftm-studio.html. Ja postanowiłem wykorzystać przykłady dołączone do modułu uruchomieniowego. Zostały przygotowane dla procesora PIC, jednak o wiele łatwiej było przenieść program na AVR niż pisać program zupełnie od nowa. Konfiguracja modułów do pracy jest do tego stopnia skomplikowana, że w sieci znaleźć można strony osób piszących prace magisterskie o konfiguracji układu CC1000. Kolejnym wyzwaniem jest obsługa protokołu transmisji danych między CC1000, a procesorem. Podczas niej układ CC1000 generuje sygnał zegarowy (na linii DCLK), a procesor działa niejako jako slave i wysyła lub odbiera dane (na linii DIO). Takie działanie ma duże plusy, procesor nie musi zajmować się synchronizacją zegarów, jednak zastosowany schemat transmisji wymaga obsługi przerwania o wysokim priorytecie (trzeba „zdąrzyć” odebrać lub wysłać dane) . Na tym nie kończą się zadania które musi spełniać oprogramowanie procesora. Pierwszy problem, który trzeba rozwiązać to wykrycie początku danych przez odbiornik. Wykonuje się to w ten sposób, że nadajnik nadaje najpierw ciąg bajtów o wartości 0x55, tzw. preambułę. Po nim nadaje bajt o ustalonej wartości, następnie pakiet danych. Program obsługujący obiornik używa tzw. rejestru przesuwnego do odbierania danych. Jeśli wykryje kod 0x55 lub 0xAA (0x55 przesunięty o 1 w lewo) zaczyna zliczać długość odczytanej preambuły i oczekuje na bajt o ustalonej wartości. Dopiero po odebraniu preambuły o minimalnej długości i bajtu specjalnego odbiornik zaczyna odbierać pakiet danych. Protokół transmisji powinien być wyposażony jeszcze w co najmniej 3 elementy. Jeśli pakiety mogą być różnej długości trzeba dodać długość danych. Warto dodać do pakietu adres odbiornika (jeśli chcemy używać więcej niż 2 modułów). Konieczne jest również dodanie sumy kontrolnej, ponieważ podczas transmisji zdarzają się przekłamania danych. Wszystko razem daje całkiem skomplikowany program. Pisanie go nie jest zadaniem dla początkujących programistów. W rezultacie można dostać bardzo sprawnie działający układ, jednak jest to skomplikowane zadanie. I nie wystarczy jeden wieczór na oprogramowanie takiej transmisji. Zalety: 1)Układ zapewnia wysoką jakość transmisji 2)Pozwala na transmisję o prędkości do 76.8kb/s 3)Obsługuje kodowania Manchester oraz NRZ 4)W przypadku kodowania Manchester zapewnia weryfikację zgodności zegarów 5)Umożliwia transmisję dłuższych danych (według informacji z sieci działa dobrze z pakietami od długości do 64 bajtów) Wady: 1)Wymaga zasilania 3.3V, piny nie tolerują 5V 2)Interfejs wymaga wielu pinów oraz szybkiego przerwania 3)Obsługa programowa jest bardzo skomplikowana 4)Procesor musi zajmować się głównie obsługą komunikacji Podsumowując CC1000 to bardzo dobry układ. Jednak nie nadaje się dla początkujących, ani nawet średnio zaawansowanych elektroników. Wymaga skomplikowanego programu, wiedzy o protokołach transmisji, umiejętności pisania zaawansowanych programów. Jednym słowem układ prawie idealny, niestety bardzo skomplikowany. Na szczęście dostępny jest nowszy układ tego samego producenta – CC1100. Układ ten zapewnia komunikację po SPI z procesorem, a jednocześnie sam wykonuje wszystkie skomplikowane funkcje wymagane przez CC1000, czyli: wykrywanie początku danych (generowanie preambuły) * obsługę pakietów * generowanie sum kontrolnych * obsługę adresów I wiele funkcji, które w CC1000 musi realizować procesor. Dostępne są moduły z tym układem http://www.propox.com/products/t_202.html?lang=pl. W kolejnych częściach postaram się opisać ten układ.

Co dokładnie chcesz zrobić? Nie wystarczy zwykły ADC?

Army nie są takie straszne. Przy najmniej ARM7. Jeśli chcesz ARM9 to zainstaluj linuxa Teraz to chyba najlepiej wybrac Cortex-m3, do STM32 są dobre biblioteki producenta. Ale to i tak trochę bardziej skomplikowane niż AVR. Poza tym 3.3V. Jakby co to o ARM7 mogę coś pomóc.

O ile rozumiem: Call Myszka(&B00010001 , X) - czyta z 0x11 Call Myszka(&B00010010 , Y) - z 0x12 Na stronie, którą podałeś jest: x=pan_read(0x17); y=pan_read(0x18); Więc to co i u mnie

Widzę, że te układy są prawie identyczne. Ja miałem problemy z odczytem z rejestrów 0x02, 0x03, więc czytam z 0x17 i 0x18 - tam już działa poprawnie. Jesteś pewien, że te układy są zgodne z I2C? Ja ręcznie napisałem procedury komunikacji i działają. Przy i2c wyjścia są OC, a nie wiem, czy ten układ ma wbudowane podciągi. Jak już coś odczytasz, to chyba jeszcze jeden błąd - rejestry Delta_X, Delta_Y zawierają przesunięcie od poprzedniego odczytu, więc trzeba ich wartości dodawać do większej zmiennej X i Y (większej niż 8 bitów). Poza tym Delta_ to 8-bitowe liczby ze znakiem. W C wystarczy rzutować na signed char i po kłopocie, nie wiem jak to uzyskać w bascomie.

Nie wiem czy czytasz z dobrych rejestrów. Mam tylko datasheet do PAN301 i tam były inne numery rejestrów, dlatego pytałem o linka do dokumentacji. W tym co znalazłem rejestr Delta_X ma adres 0x03, a Delta_Y 0x04. O ile rozumiem czytasz rejestry 0x11 i 0x12.

Mogłbyś podać linka do datasheetu tego układu? Znalazłem tylko do PAN301A, do PAN3103 jakoś nie moge. Program zupełnie nic nie wyświetla, czy czasem coś się pojawia przy ruszaniu myszą? [ Dodano: 09 Sie 09 07:00 ] Bascoma nie znam, ale zobacz czy parametr Zapis nie powinen być przekazywany przez referencję? Sub Myszka(byval Address As Byte , Byval Zapis As Byte)

Moj pierwszy robot (no może nibyrobot) to był przerobiony zdalnie sterowany samochodzik. Ale nic mądrego w kwestii sterowania nie udało mi się zrobić, lightfollower był z niego baaardzo kulawy. Więc tego typu konstrukcje porzuciłem i nie zamierzam wracać. Chyba ciężko takie coś oprogramować.

Mosfet-y to akurat nic skomplikowanego. Moim zdaniem trudniej zrozumieć zwykłe tranzystory bipolarne. Jest tylko jeden problem z mosfetami - są ich 4 rodzaje. Wszystkie mają 3 wyprowadzenia, oznaczane S (source), G (gate), D (drain). Tranzystor z kanałem wzbogacanym typu N ma symbol: Podłączamy taki tranzystor następująco: do S podłączamy masę, do D silnik (drugie wyjście silnika do zasilania), G łączymy z procesorem (najlepiej przez nieduży rezystor, można dać 100Ohm). Gdy procesor wystawia na pin 0, na wejściu G jest zerowe napięcie, a między pinami D i S nie płynie prąd. Po wystawieniu 1 na pin procesora, między G i S pojawi się napięcie ok. 5V. Tranzystor zacznie przewodzić i między pinami D i S (czyli przez silnik) popłynie prąd. Podsumowując: przez tranzystor płynie prąd jeśli na wejściu G podamy napięcie. Działa jak zwykły przekaźnik.

Radiowa transmisja danych, czyli robot zdalnie sterowany (Wstęp) Artykuł ten powstanie w kilku częściach, prawdopodobnie czterech, ale nigdy nic nie wiadomo. W kolejnych częściach planuję opisać różne możliwości bezprzewodowej transmisji danych między urządzeniami (np. robotami). Od razu uprzedzam, nie będę się zajmował ani Wi-Fi, ani Bluetooth. Jeśli kogoś stać na drogie moduły, ma możliwość używania TCP/IP, ten artykuł może przeczytać tylko po to, aby zobaczyć jak wiele problemów go ominęło. Moim celem jest znalezienie taniego modułu, za pomocą którego możliwe będzie przesyłanie informacji między układami. Jako przykład zastosowania niech posłuży robot. Pewnie każdy wymyśli wiele ciekawszych zastosowań komunikacji radiowej. Moje pomysły to: zdalne sterowanie robotem (proszę się nie śmiać, na początek zawsze coś) zdalne debugowanie pracy robota – czasem się przydaje zbieranie informacji, np. o otoczeniu robota wymiana informacji między robotami Wracając jednak na ziemię, wypada najpierw sprawdzić, co można kupić za rozsądną cenę. Postanowiłem zastosować gotowe moduły RF, ich wybór podyktowany był ceną oraz dostępnością: 1.HM-T868S, HM-R868S 2.RFM12B / 868D 3.CC1000PP-433 Pierwsza para modułów zapewnia tylko jednokierunkową komunikację (simpleks). Moduł HM-T868S jest nadajnikiem, HM-R868S to odbiornik. Nie ma możliwości przesyłania danych w przeciwnym kierunku. Jednak cena modułów sprawia, że rozwiązanie jest warte przemyślenia. Ceny z TME (www.tme.pl): HM-T868S – 12,13zł HM-R868S – 16,96zł Dodatkowym atutem jest bardzo prosty interfejs sterowania modułami, ale o tym dalej. Kolejnym kandydatem na idealny moduł jest RFM12B/868D. Jego cena (również TME) wynosi: 22,94 zł. Nieco więcej niż poprzednio, ale ten moduł może pracować zarówno jako nadajnik jak lub odbiornik. Trzecim i ostatnim opisywanym modułem jest CC1000PP-433. Dostępny jest na stronie www.mikroprocesor.pl, a jego cena wynosi 46,36zł. Platforma testowa Aby przetestować moduły niezbędne nam będą co najmniej dwa urządzenia, które będą się ze sobą komunikować. Do testów wykorzystałem dwie identyczne płytki (zaprojektowane pod moduł CC1000PP-433, ale pozostałe powinno być łatwiej podłączyć). Płytki testowe wyposażone są w procesor Atmega8L – wynika to z konieczności zasilania modułów napięciem 3.3V (szczegóły w dalszej części). Każda z płytek posiada 3 switch-e oraz 3 diody. Najprostsza wersja sterowania to zapalanie diody po naciśnięciu przycisku (na przeciwnym układzie oczywiście). Dodatkowo układy mają wyprowadzone piny od UART-a, więc istnieje możliwość podłączenia płytek do portu szeregowego komputera przez układ typu max232. Stosuję takie rozwiązanie, aby nieco zaoszczędzić, układ max232 mam na oddzielnej płytce, a testową traktuję jako jednorazową. Radiowa transmisja danych, czyli robot zdalnie sterowany cz.2 (moduły HM-T868S i HM-R868S) Testowany zestaw składa się z modułu nadajnika HM-T868S oraz odbiornika HM-R868S. Pierwszym zaskoczeniem jest wielkość modułów, są bardzo małe. W komplecie dostajemy do nich odpowiednio przycięte przewody, służące jako anteny. Kolejne zaskoczenie do liczba wyprowadzeń - nadajnik ma tylko 3 piny, odbiornik 4. Piny są rozmieszczone standardowo, co 2,54mm, więc bez problemu można moduły wpiąć do płytki testowej. Więcej informacji o modułach jest na stronie producenta: http://www.hoperf.com/ Piny nadajnika to: GND, DATA, VCC. Odbiornika: GND, DATA, VCC, ENABLE. Rozszyfrowanie oznaczeń nie sprawia problemów, jednak lepiej zapoznać się z krótkim datasheetem ze strony producenta. Moduły powinny być zasilane napięciem 3V, jednak mogą pracować do 5,4V, więc podłączenie do AVR-a nie sprawi problemu. Pin ENABLE odbiornika pozwala na wyłączenie modułu, gdy nie jest używany. Podanie na nim napięcia VCC uruchamia odbiornik. Nadajnik sam wykrywa brak danych i przechodzi w tryb uśpienia. Okazuje się, że moduł jest maksymalnie prosty w obsłudze. Nie zapewnia żadnego protokołu komunikacji, to co podamy na pin DATA nadajnika zostanie wysłane i pojawi się na pinie DATA odbiornika. Prosty test polegający na podłączeniu generatora do nadajnika i oscyloskopu do odbiornika potwierdza taki właśnie sposób działania modułów. Prędkość transmisji zalecana przez producenta to 4800bps, maksimum 9600, co w dzisiejszych czasach nie oszałamia. Przy częstotliwości w okolicach 10kHz widoczne jest zniekształcenie sygnału, więc lepiej nie liczyć na maksymalną prędkość transmisji. Prostota obsługi modułów ma swoje wady. Trzeba samemu obsłużyć protokół transmisji. Ja postanowiłem wykorzystać sprzętowy UART procesoraś. Nadajnik połączyłem więc do pinu TXD w płytce nadajnika, odbiornik do pinu RXD płytki odbiornika. Pozostało dodać podciąg pinu ENABLE w odbiorniku (niech pracuje cały czas, nie oszczędzam prądu podczas testów) i podłączyć zasilanie. W datasheecie producent sugeruje, aby pin ENABLE był nieaktywny podczas podłączania zasilania i aktywowany później. Okazało się to o tyle istotne, że inaczej odbiornik nie zawsze „wstaje”. Problem nie był duży – wystarczy podłączyć ENABLE do pinu procesora i programowo wystawiać 1 chwilę po uruchomieniu układu. W poprzedniej części opisałem z czego składają się moje płytki testowe, teraz zamieszczam więcej informacji o nich. Na schemacie jest procesor Atmega8, jednak użyłem Atmega8L – ze względu na zasilanie z 3V (będzie niezbędne dla modułu CC1000, o tym później). Gniazdo RS232 to wyprowadzenia UART-a wraz z zasilaniem, P1 i P2 to gniazdo do podłączenia CC1000. Poza tym jest oczywiście gniazdo programatora, 3 diody i 3 switche do sterowania układem oraz stabilizator 3.3V. Do obecnych testów można użyć uproszczonej wersji układu, przede wszystkim można użyć Attiny, ale miałem akurat atmege8, więc wykorzystałem co było pod ręką. Obecne testy przeprowadzałem na 5V (stabilizatory zalutuję później), więc zasilanie też można uprościć. Jedno o czym warto pamiętać to dodanie rezonatora. Ja używam rezonatorów 4MHz. Próbowałem najpierw działać bez nich, niestety układy nie mogły się komunikować poprawnie. Wystarczył upalny dzień i generator RC jednego z układów przestawił się na tyle, że dane po RS232 nie były poprawne. Rezonator zapewnia dużo większą dokładność zegarów. Program testowy Pierwszą czynnością jest konfiguracja modułu UART do pracy. Ustawiłem prędkość na 2400bps. Piny od przełączników ustawiane są jako wejścia, piny od diód jako wyjścia. Pętla główna odczytuje stan przełączników, jeśli któryś zostanie przyciśnięty, wysyła kod przycisku. Kodowanie jest bardzo proste i bazuje na znakach: 'A' – wciśnięty przycisk 1, 'B' – przycisk 2, 'C' – przycisk 3 Moduł odbiornika działa na przerwaniu i po odebraniu bajtu steruje diodami. 'A' – zapala diodę 1, 'B' – 2, 'C' -3 Są też kody gaszenia diód: 'a' – gasi diodę 1, 'b' – 2, 'c' – 3 Zarówno płytka nadajnika jak i odbiornika pracują na tym samym programie. Do testów wystarczy założyć zworkę na piny RXD i TXD – wtedy moduł komunikuje się sam ze sobą, naciskanie przycisków zapala odpowiednie diody. Moduły podłączyłem następująco: Nadajnik GND – do pinu 1 (GND) gniazda JP4 (RS232) DATA – do pinu 2 (TXD) gniazda JP4 (RS232) VCC – do pinu 4 (VDD) gniazda JP4 (RS232) Odbiornik GND – do pinu 1 (GND) gniazda JP4 (RS232) DATA – do pinu 3 (RXD) gniazda JP4 (RS232) VCC – do pinu 4 (VDD) gniazda JP4 (RS232) ENABLE – podciąg rezystorem do pinu VCC Po sprawdzeniu połączeń i podłączeniu zasilania spotkało mnie pierwsze rozczarowanie. Odbiornik odbiera straszne ilości „śmieci”. Natomiast dane z nadajnika lubią się „gubić”. Aby poprawić działanie układu zmieniłem program: 1)po naciśnięciu przycisku program cyklicznie wysyła kod zapalania diody 2)gdy przyciski są zwolnione ciągle wysyła kody gaszenia diód Takie zmiany pomogły – program działa bardzo ładnie. Niestety śmieci, nadal pojawiają się na odbiorniku. Należałoby dodać filtrowanie danych w odbiorniku, jednak na potrzeby sterowania diodami program działa bardzo ładnie. Testy pozwalają na podsumowanie, jakie są plusy i minusy układu: Zalety: 1)Niska cena 2)Prostota działania (nawet procesor nie jest niezbędny, można zrobić radiowy włącznik, czy czujnik bez procesora) 3)Łatwe podłączenie 4)Możliwa praca z 5V Wady: 1)Brak jakiegokolwiek protokołu transmisji 2)Zaśmiecony sygnał na odbiorniku 3)Konieczność wielokrotnego wysłania danych Podsumowując układ dobrze nadaje się dla początkujących elektroników, którzy nie chcą zajmować się programowaniem obsługi skomplikowanego układu. Za jego pomocą można łatwo wykonać układ zdalnego sterowania np. robota. Można też odczytywać stan czujników lub urządzeń, np. mierzyć temperaturę w innym pokoju.