|
Port WaveForms SDK na Pascal informacje o urządzeniu i sterowanie zasilaczem część 1 |
|
|
Mniej więcej tak brzmiała pewna wypowiedź na forumowym czacie, oj spory już czas temu. Szczęściem autorstwo owej wypadło mi z łepetyny, uważam jednak za stosowne kilka zdań wyjaśnienia, dlaczego tak uczepiłam się po raz kolejny języka Pascal, a dokładnie Free Pascal w środowisku Lazarus. Po prostu, po wielu różnorakich poszukiwaniach i eksperymentach właśnie FPC/Lazarus został się na placu boju jako środowisko ponadplatformowe i zapewniające sensowny kompromis pomiędzy produktywnością i komfortem tworzenia aplikacji a efektywnością kodu i dostępnością wszelkiej maści bibliotek, szczególnie do okienkowych interfejsów. Z reguły dłubię na dwa systemy na raz, na Linux Mint i na Win7, teraz doszło do kompletu Raspberry ze swoim śmiesznym Debianem i na wymienionych kompilują mi się te same źródełka z wystawionego po Sambie udziału. Pewnie, że można zacząć dysputę o wyższości X nad Y, perspektywicznością Z i martwotą W, tylko po jasną choinkę? Jest problem do rozkminienia - to szukamy [b]dla siebie[/b] najwygodniejszego w danym przypadku narzędzia, ewentualnie czegoś, co sprawia największą frajdę [b]nam[/b] - a nie, pisze w tym a tym bo tak modnie. No i tak stanęło na FPC :) A żarcik dodatkowy taki, że WaveForms SDK i garstka programików demonstracyjnych dla Pascal będą miały etykietkę 'made in Poland'. A zatem... ❦ WaveForms SDK dla Free Pascal No niech już będzie, że jeden plik *.h oraz *.dll/so to jest ten System Development Kit, każdy przyzna - brzmi ambitnie. Państwo sympatyczni z firmy Digilent przygotowali całkiem pokaźne stadko przykładowych programów prezentujących różne aspekty wykorzystania funkcji bibliotecznych (a jest ich jakieś 379 (sic!)) zarówno dla języka C/C++ jak i Python. Dodatkowo, ostatnimi czasy objawił się w sumie ciekawy pakiet waveforms4j czyli melanż AD2 i Java (ale z wykorzystaniem mechanizmów JNI, zatem więcej tam C niż Javy). A o Pascalu jakoś zapomniano, zatem nadrabiam ten drobny brak. Pliczek dwf.pas to zwykły pascalowy unit, którego lwią częścią jest sekcja deklaracyjna z dostępnymi w dwf.so funkcjami. Zostało to przygotowane na zasadzie masakrystycznie wręcz nudnego przepisania z dwf.h i niewykluczone, że z literówkami, życie zweryfikuje. Wszelkie automaty typu h2pas i inne - wymiękły, a produkt finalny przypominał ujmując wprost - kaszanę - stąd kilka godzin klawiaturowania przy muzyce, ale udało się. W firmowych deklaracjach od Digilent (*.h) można znaleźć różne dziwadła, na przykład ustawianie ilości kroków przez wskaźnik na double, funkcja FDwfAnalogInChannelRangeInfo() podczas gdy jej koleżanka obok robi podobnie, ale korzystając z intuicyjnie akceptowalnego wskaźnika na int. Wartości zmiennoprzecinkowe w formie 1.0 jako odpowiednik logicznego TRUE, na przykład w FDwfAnalogIOChannelNodeSet() to już drobiazg. Swego czasu (na Forum) namarudziłam się o tym, ale API jest jakie jest, a darowanemu darmo koniowi w zęby się nie zagląda, ani nigdzie. Wracając do unit-a - wskazanie na fizyczny nośnik implementacji, czy to windowsową DLL-kę czy linuksowe .so jest objęte kompilacją warunkową, tak więc przedstawione dalej programiki budują się i działają żwawo zarówno w Linux jak i Windows. Cały wzmiankowany cudak dwf.pas znajduje się w lokalizacji: ➮ https://github.com/bienata/AnalogDiscovery2/blob/master/dwf/dwf.pas , aby z niego skorzystać należy podłączyć go do lazarusowgo projektu jak każdy inny unit. No i uszy do góry - tam pewnie będą jeszcze zmiany, ponieważ ciągle jakieś niedogodności mi wychodzą przy pisaniu demek. No właśnie, demka - najlepiej coś zaprezentować na konkretnych przykładach. ❦ szablon - szkielecik każdej kolejnej discoverowej aplikacji ❦ devinfo1 - informacje o urządzeniu Projekt Lazarus: ➮ https://github.com/bienata/AnalogDiscovery2/blob/master/devinfo1/devinfo1.lpr Tragicznie prosty wręcz programik, który wypisuje nam na ekran wersję SDK, nazwę urządzenia, jego numer seryjny i sygnaturkę, oraz kto używa ( tak, AD2 można sobie podpisać :) ). Kolejny krok, to iteracja po kanałach analogowych i ich węzłach (tak logicznie podzielono AD2) celem pozyskania informacji o ich nazwach i funkcjach. Efekt działania programu widzimy na obrazku poniżej.  ❦ psudemo1 - test regulowanego zasilacza Projekt Lazarus ➮ https://github.com/bienata/AnalogDiscovery2/blob/master/psudemo1/psudemo1.lpr Programik nieco bardziej skomplikowany, uruchamia i konfiguruje bloczki AD2 występujące w roli regulowanego, laboratoryjnego mini zasilacza. W tym wypadku korzystam tylko z części dodatniej, nie chciałam zaciemniać całości drugą połową - obsługa jest identyczna. Instalację testową przedstawia fotografia: a wynik działania programiku zrzut konsoli:  No i oczywiście na koniec filmik jak to wygląda na żywo. Takie spostrzeżenie odnośnie API i AD2 - jest pewien niedosyt, no tak to odbieram. Weźmy na przykład funkcję FDwfAnalogIOChannelNodeStatus(), potrafi pobrać wartość analogową ze wskazanych obszarów kontrolnych Analog Discovery, czy to napięcie z USB, czy to temperaturę pudełka. No to chyba byłoby miło móc na przykład odczytać bieżąca wartość prądu pobieraną z wyjścia naszego regulowanego zasilacza. A tu guzik! Nie ma. Pomiar prądu zrobiony jest tylko na głównych regulatorach systemu. Zasilacz dla użytkownika, choć o sterowanej wartości układowo nie wspiera pomiaru Iout - po resztą można zerknąć na schematy: ➮ Power Supplies and Control. O kolejnych żarcikach w API - w następnym odcinku. #slowanawiatr, grudzień 2018 |
|
|
 |
|