Port WaveForms SDK na Pascal
informacje o urządzeniu i sterowanie zasilaczem

część 1

podstawowe informacje o urządzeniu i sterowanie zasilaczem
cykliczna akwizycja danych i histereza triggera
UART - Digital I/O i obsługa protokołów
I2C - Digital I/O i obsługa protokołów
SPI - Digital I/O i obsługa protokołów (mostek Wheatstone'a)
SPI - Digital I/O i obsługa protokołów (pomiar Iadj w LM317)
Digital I/O - ROM Mode, przerzutnik RS i dekoder do rosyjskiej VFD
Digital I/O - bezpośredni dostęp, wyświetlacz HDSP-2111 i termometr MCP9700
Analog OUT - woltomierz True RMS z przetwarzaniem sygnału


Pascal? w 2018? serio?

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 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

program ad2application;
{$mode objfpc}{$H+}
uses
    {$IFDEF UNIX}{$IFDEF UseCThreads} cthreads, {$ENDIF}{$ENDIF}
    Classes, crt, sysutils, dwf; // <-- !!!!!
var
   hAd2 : HDWF;             // uchwyt urządzenia
   msgErr : TDwfString512;  
begin
  // otwarcie dostępu do AD2
  if not FDwfDeviceOpen( -1, @hAd2 ) then
  begin
       FDwfGetLastErrorMsg( msgErr );
       writeln ( msgErr );
       exit;
  end;

  (* tu nasze wypociny czyli logika biznesowa *)
  
  // zwolnienie zasobu
  FDwfDeviceClose( hAd2 );
end.

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

Natasza Biecek 2004-2019/~, e-mail