Rys. 3. Kod LPC2148_port.vi odpowiedzialny za ustalanie kierunku pinu portu 1
Rys. 4. Kod LPC2148_port_set_clear.vi odpowiedzialny za ustalanie stanu pinu portu 1
Konstrukcja przedstawionych .vi wymaga komentarza. Użyłem w nich tzw. Inline C node. Funkcjonalnie odpowiada konstrukcji inline znanej z języka C. Kod zawarty w tej strukturze zostanie wstawiony właśnie jako funkcja inline w generowanym kodzie wynikowym. W ten sposób możemy tworzyć swego rodzaju drivery do bloków peryferyjnych znajdujących się na płytce uruchomieniowej.
Kod LV aplikacji przedstawiono na rys. 5.
Rys. 5. Aplikacja przełączająca diodę LED0 co 200 ms
Analizując od lewej strony (przepływ danych w LabVIEW zawsze odbywa się od lewej strony) wykonujemy inicjalizację pinu 16 portu, 1 (ustawiamy go jako wyjście), po czym wpadamy w główną pętlę programu wykonującą się w nieskończoność co 200 ms. Na pętli założono rejestr przesuwny przechowujący bieżącą i poprzednią wartość typu BOOL. W każdej iteracji pętli, za pomocą komponentu negacji, zmieniamy jej wartość. W każdej iteracji też rzutujemy tę wartość BOOL na 0 lub 1, a następnie zmieniamy typ tak powstałej wartości liczbowej na unsigned char podawaną na wejście LPC2148_port_set_clear.vi (jako argument wartości logicznej na pinie 16).
Przed jednokrotnym uruchomieniem tego .vi musimy się upewnić czy Execution Target’ jest przełączony na platformę ZL9ARM (lewy dolny róg okna vi). Jeśli widnieje tam inna nazwa możemy przełączyć się wybierając z menu Operate>Switch Execution Target. Jeśli wszystko przebiegło poprawnie, zostaniemy poproszeni o utworzenie nowego projektu Embeded. Kliknięcie na
New spowoduje uruchomienie menadżera projektu (rys. 6). W jego rozwijanym menu Target znajdują się dwie najbardziej interesujące nas opcje, czyli: Build (kompilacja) i Download (ładowanie pliku .hex do pamięci mikrokontrolera).
Rys. 6. Okno Embedded Project Manager
Podsumowanie
Nie sposób w jednym artykule przekazać wszystkie punkty istotne dla poprawnego portowania LabVIEW na platformę sprzetową. Zdaję sobie sprawę z tego, że pojawi się wiele niejasności i wątpliwości.
Część Czytelników zapewne zada sobie pytanie, po co to wszystko? Po co dla napisania aplikacji na mikrokontroler, angażować tak potężne środowisko, jakim jest LabVIEW?
Aby uzyskać odpowiedź trzeba niestety zmienić punkt obserwacji problemu: LabVIEW Embedded Developement Module powstał po to, aby umożliwić programistom LV bezbolesną zmianę platformy. Nie zawsze wszak potrzebujemy do sterowania przekaźnikiem całego komputera PC. Dzięki opisywanemu modułowi samo środowisko LV zostaje uwolnione od sprzętu National Instruments, (który oczywiście posiada w ofercie kilka platform sprzętowych mniejszych i prostszych niż PC). Wbrew pozorom, gotowy port LV nie jest przeznaczony dla osoby, która to narzędzie tworzyła, a właśnie dla wspomnianych wyżej programistów LV. Osobiście uważam, że moduł ten jest niezwykle interesujący i pokazuje jak używając prostych mechanizmów można z języka wysokiego poziomu zrobić użytek na platformie, której jego twórcy nigdy nie widzieli na oczy.
Dużym „łukiem” obszedłem w artykule problem debugowania aplikacji. Dała się tu we znaki znikoma pojemność pamięci RAM mikrokontrolera. System eCOS do debugowania aplikacji używa środowiska Redboot. Jest to nic innego jak programowy bootloader, który zainstalowany na platformie przejmuje kontrolę nad systemem i aplikacją. Umożliwia wymianę informacji pomiędzy aplikacją debugera na PC a aplikacją wbudowaną zgodnie ze standardem GDB.
O ile udało mi się zbudować poprawny obraz Redboota na platformę ZL9ARM, to już załadowanie przy jego pomocy aplikacji stworzonej w LV okazało się niewykonalne (ze względu na zbyt małą objętość RAM-u), a szkoda, ponieważ LV dostarcza przykładów współpracujących z Redbootem.
Marcin Chruściel
