Műszervezérlés - irányok 2.

Sokminden (hívhatjuk semminek is) történt mióta utoljára írtam a műszervezérlő alkalmazásról.

Név

Nem szeretem a random neveket amiket ennek a rendszernek adtam idáig. Nem látszott, éreztem professzionálisnak. Végülis találtam neki nevet: MeasureFlow

Regisztráltam egy domaint is hozzá:

measureflow.org

(még nincs rajta semmi)

Készült egy github és egy gitlab csoport:

https://github.com/MeasureFlow

https://gitlab.com/MeasureFlow

Szoftver

Azt hiszem (legalábbis részben) megvan az irány. A szoftver plug-in alapú volt idáig, de más szempontból nem volt moduláris. Úgy döntöttem, hogy architekturálisan szétválasztom a frontend-et és a backend-et. A backend egy minimális REST API dotnet 6 alapon. A frontend még mindig kérdéses.

Elkezdtem a backend fejlesztését. A kódbázis nem ígényel túl sok portolási munkát amíg csak egy műszer folyamatos méréséről beszélünk és nem valami komplex munkafolyamatról. Tehát a dolog nagyjából már működik (csak az utolsó kódrészleteket még nem próbáltam ki)

Hardver

A megrendelt panelek megérkeztek (mind az USB-GPIB mind az USB-RS232). Voltam olyan szerencsés, hogy ebben a chiphiányos időszakban találtam 10db ATMEGA32U4-et egy helyi kereskedőnél.

Egyelőre még nem volt időm beforrasztani és tesztelni. Amúgyis, még kell rá firmware, szóval amíg a firmware-el kapcsolatos kérdéseket nem oldom meg, az egész használhatatlan.

Firmware

Elérkeztünk arra a pontra, ami jelenleg a legnagyobb fejfájást okozza az egész képben.

Az elmúlt két hétben, amikor időm volt ezzel foglalkozni, próbáltam megérteni azt az USBTMC implementációt, amit találtam a github-on. Nem lettem nagy rajongója. Sajnos nem egy megfelelő, újrahasznosítható USBTMC implementáció, ami betartaná a LUFA tervezési elveit. Egy félkész, nem túl jó LUFA demo-n alapul, rosszul kezeli a az AVR lábait, nagyon fura a konfiguráció kezelése (A szabványban nem létező, az USBTMC-n kívüli konfigról beszélek).

Próbáltam megérten, hogyan működik, hogyan tudom átültetni a saját hardveremre. Eredetileg, csak a lábkiosztást akartam megváltoztatni a saját terveimhez, de már tudom, hogy nem állhatok meg itt.

A múlt vasárnap, végül rájöttem, hogy mi a legnagyobb probléma az egész dologgal. Sokkoló felismerés volt. A probléma gyökere, nem a megvalósításban keresendő, hanem a szabványban magában.

A szabványosító testület teljesen másképp gondolkodott mint én.

Az ő céljuk: kialakítani egy olyan megoldást ami műszer oldalon be tudja "csomagolni" a meglévő GPIB csatolót az USB-be, időt adva a natív USBTMC megvalósítás előállítására.

Az én célom: kialakítani egy olyan megoldást ami a (akár több) műszer GPIB csatolója és az USB közé tehető, becsomagolva a meglévő GPIB csatolót. Ezen túl kezeli a műszer oldalon a másodlagos címzést is.

Első olvasásra talán nem tűnik úgy, hogy túl sok különbség lenne a kettő között. A különbség, hogy a szabvány nem tartalmaz semmit ami a GPIB címzésre vonatkozik. Feltételezi, hogy az USB488 kiterjesztéssel rendelkező USBTMC eszköz, egy USB eszközként jelenik meg és nem többként.

Ha másodlagos GPIB címzés nélküli eszközökkel szeretnék csak foglalkozni, akkor talán együtt lehetne élni ezzel, de sajnos, nem ez a helyzet. Vannak VXI kereteim, valamint egy moduláris tápegységem másodlagos címzéssel.

Ha kicsit tovább ások kiderül, hogy sem a HP (Agilent/Keysight), sem a National Instruments nem valósította meg az USB488-al kiegészített USBTMC szabványt a saját USB-GPIB csatolóiban (HP 82357B, NI GPIB-USB-HS). Az egyikük "standard base device"-t használ a másik meg "vendor specific device"-t. Ezek meg cégen belüli zárt megoldások.

Visszatérve az eszközre magára. El kell döntenem, milyen irányba haladjak tovább a firmware fejlesztéssel. Itt vannak azok az irányok amik elképzelhetőek:

1. Újraindítom az USB-CDC alapú megvalósításomat (Prologix parancskészlet alapú). Ennek megvannak a maga hátrányai, mint a CDC lassabb mint a natív USB "bulk" végpontok, a PC oldalon portolnom kell a saját meghajtómat a MeasureFlow alá, az eredmény egyetlen meglévő PCs software csomaggal sem lesz kompatibilis.
2. Az AR488 firmware-t használom. A fenti hátrányokon túl, még a másodlagos címzést is meg kell valósítanom, az ő kódbázisukon miután az ott még nincs meg.
3. Lemásolni a HP vagy az NI csatoló működését. Ez több szempontból is problémás. Rengeteg USB kommunkáció elemzéssel, jogi problémákkal, stb. jár.
4. Fejleszteni egy USB kompozit eszközt (meg kell nézni egy móricka programban, hogy a Keysight IO library kezeli-e). Szóval a koncepció: fogni egy CDC eszközt amin keresztül lehet az egész cuccot vezérelni (úgy mint manuális beállítások, vagy SCPI emuláció). Csinálni dinamikusan készülő USBTMC eszközt minden GPIB műszerhez (elsődleges és másodlagos cím), ami vagy az automatikus felderítésen, vagy a CDC manuális beállításokon alapul.

Egyelőre ez az utolsó tűnik a célnak, ha nem futok bele valami megoldhatatlan gondba.

USB-GPIB csatoló V2.1

 

Ez egy némi javítás, hibakezelés a korábbi ATMEGA32U4 alapú USB-GPIB csatolómhoz. Az előzőnek volt néhány baja. Ütközött a bootloader LED-jeinek a konfigurációja a GPIB jelekkel. Teljesen újradefiniáltam az eredeti Arduino jelekhez képest, hogy ki tudjam használni az interrupt kezelést. Továbbá egy teljes 8 bites portot használtam adatbuszként, hogy egyben írható/olvasható legyen és ne bitenként.

Az új verzióban kicsit más lett a megközelítés:

• Próbáltam az Arduino Leonardo lábkonfigurációjánál maradni, amennyire tudtam.
• Feladtam az interrupt kezelést az SRQ vonalat leszámítva
• Megtartottam a 8 bit adatbuszt
• Konfigurálhatóvá tettem - lehet választani az AR488 által használt konfiguráció és a fenti 8 bites egybe adatbusz között (az AR488 verziónak nem kell speciális bootloader)
• Megtartottam az állapot LEDeket
• Hozzáadtam egy hibakeresésre használható soros portot

Később ez a terv lesz az alapja a teljes GPIB csatolónak, megfelelő vonalmeghajtókkal együtt. Ez a verzió, csak egy műszer vezérlésére használható (lehet, bírna többet is, de inkább nem próbálom ki). 

A kapcsolási rajz:

A nyák terv:

A robbantott 3D model:

Igen tudom, hogy a csatlakozó neme, nem a megfelelő (bár ki tudja ma már, hogy mi a megfelelő nem), de sajnos nem találtam megfelelő 3D modellt, és annyira nem volt fontos, annyi volt a lényeg, hogy reprezentálja a megfelelő méretet a 3D modell tervezéshez.

A teljes terv itt található:

https://gitlab.com/measurementcontrol/gpibinterfacehardware

Ezzel az a témában elkészült új tervek száma kettőre emelkedett, szóval itt az ideje, hogy megrendeljem a paneleket.

Műszervezérlés - újrakezdve

 

Bevezető

Az elmúlt években rengeteg munkát raktam a különböző műszereim számítógépes vezérlésébe. A terv az volt, hogy valami hozzáadott értéket teremtsek vele, úgy mint logolás, jobb láthatóság, több - integrált - funkció, stb.

Úgy néz ki, hogy ezzel kicsit megbuktam, miután semmi sem jutott el, a használhatósági állapotba.

Az egészet, hónapokkal ezelőtt félretettem. Most úgy érzem, ideje leporolnom és újrakezdenem, hogy valami "működő" állapotig eljussak vele.

Tervek

A forrás repók újraszervezése

Ez azért szükséges, mert rengeteg dolgot tanultam az elmúlt években a munkám kapcsán a gitről (branch stratégiák, release kezelés, etc.)

USB-RS232 interfész tervezés

Van egy pár eszközöm ami RS232 interfésszel rendelkezik a GPIB helyett/mellett. Igen, vehetsz USB-Soros átalakítót gombokért. Miért kell egy másik? A legtöbb darab amit kapsz, nem tudja a megfelelő jelszinteket. TTL szintet használnak RS232 helyett. A legtöbb professzionális műszernek szüksége van a megfelelő jelszintekre. A megfelelő csatoló nem olcsó, vagy azt kockáztatod, hogy veszel valami vackot az Aliexpressen ami azt állítja magáról, hogy megfelelő, közben nem.

USB-GPIB hardver újratervezése

Az ATMEGA32U4 alapú interfészem tökéletesem működik. Az elmúlt években ugyanakkor kiderült pár dolog ami arra késztet, hogy szükség van pár módosításra:

• Olyan fizikai terv kialakítása, hogy 3D nyomtatott dobozba lehessen tenni.
• Elhagyni azokat a csatlakozókat amiket későbbi továbbfejlesztésre terveztem bele mint kijelző plusz eszközök vezérlése, stb.
• Soros debug lehetőség (az AR488-nak megfelelően)
• Az Arduino Leonardo bootloaderrel való kompatibilitás
• Megtartani a teljes 8bites buszból adódó adat transzfer előnyöket (módosított bootloader szükséges)
• Az AR488 szoftverrel való kompatibilitás megtartása (https://github.com/Twilight-Logic/AR488)
• Aktivitás LED-ek hozzáadása (az eredeti Arduino Leonardo-nak megfelelően)
• Teljes GPIB meghajtó TI ICkkel (másik hardver verzió szükséges)

Az AR488 kompatibilitás megtartása nem jelenti azt, hogy a saját firmware-emet ki tervezném dobni. Változatlanul nem békéltem megy a 3000+ sor kóddal egyetlen forrásfájlban. Az AR488 még mindíg nem támogatja a GPIB másodlagos címzést. Van egy rakás eszközöm (VXI keretek, moduláris labortáp keret), amiknek szüksége van erre. A másik oldalon támogatja a device üzemmódot, a TI GPIB IC-it, amik az enyémből hiányoznak, továbbá megvan a szoftver támogatása olyan eszközökben mint a sigrok.

Proper bootloader for USB-GPIB

Csináltam egy bootloadert a v2.0-ás panelhez. Ez egy annak a mellényúlásnak az eredménye volt, hogy újrahasznosítottam az Arduino Leonardo USB visszajelző LEDjeit, ami megölte a GPIB kommunikációt. A problémát akkor megoldottam, de az eredménye egy rosszul dokumentált (https://it-pro-hu.blogspot.com/2020/04/gp-ib-5-v20-panel.html), nehezen reprodukálható állapot lett. Ráadásul ez kinyírja a LED-eket és nem áthelyezi más uC lábakra. Most létre akarok hozni egy karbantartható, újrafordítható, megfelelően telepíthető megoldást. Ezen túl szeretnék a szabályoknak megfelelő PID/VID páros kérni a pid.codes-tól.

Tápegység vezérlő szoftver

A virtuális műszer szoftverem sok dologra lenne alkalmas, de rájöttem, hogy túl magasra tettem a lécet, első nekifutásra. Sok mindent megcsináltam már benne, a jelenlegi újrakezdéshez kisebbet akarok fogni.

Tehát megtartva a cserélhető driver támogatást akarok csinálni egy tápegység vezérlő szoftvert a rengeteg tápegységemhez (ráadásul a HP 66000A moduláris tápegység nem is használható szoftver nélkül, mert nincs hozzá meg a saját billentyűzete). Ebbe egyenlőre nem akarom magasabb szintű funkciókat rakni.

Továbbiak...

Természetesen, nem akarok itt megállni, újra akarom indítani a virtuális műszer fejlesztésem, a karakterisztika rajzolót, stb.

Ezek a dolgok egyenlőre homályosak, és ha elveszítem a fókuszt ezem megint, annak csak egy polcra rakott project hegy lesz az eredménye. Megint.

Műszer vezérlés 1. - A kezdetek

Konvergencia

Ez a szó jut eszembe, amikor erre a projectre gondolok.

Úgy érzem, hogy ez az a pont ahol a műhely építés, műszer gyűjtés, mérő interfész (GP-IB) építés és mérés erőfeszítéseim összekapcsolódnak, hogy valami magasabb szintű képességet produkáljanak a dolgok amikkel rendelkezem.

Hol is kezdődött?

Gyerekkoromban audio cuccokat építettem. Később (nem kis kihagyás után) újraindult ez a hobbi, az volt a terv, hogy folytatom a munkát az audio elektronikán. Nem volt mérőeszközöm (egy döglődő digitális multimétert leszámítva). Építeni akartam, ahelyett, hogy veszek valamit. Ez térített el a digitális elektronika irányába.

Később rengeteg műszert vettem (kattant idióta). Egy ponton vettem egy HP 8903B audio analizátort, hogy képes legyek grafikonokat rajzolni az erősítők képességeiről. A gond ott volt, hogy a XY rögzítőt csatlakoztatni számomra, egy igencsak túlhaladott megoldás lett volna. Ahhoz, hogy számítógépre kösd, meg szükséged van egy interfészre. Nem voltam elégedett a jelenleg kapható GP-IB interfészekkel, itt született meg a saját tervezésű GP-IB csatolóm.

Később kerestem vezérlő szoftvert a HP 8903B-hez, és nem szerettem amit találtam. Ezen túl még az is a fejemben volt, hogy más műszereimet is hozzákössem a PChez, miután más ötelteim is vannak, nem csak az audio analizátor vezérlése. Néhány kísérlet után megszületett a "Virtual Instrument" projectem.

Két év után, rengeteg szenvedéssel, újrakezdéssel és újratervezéssel, úgy tűnik, a rendszer elkezdett működni.

A koncepció:

Valami rugalmas megoldást akartam, aminek a használata, ugyanakkor nem igyényel programozási ismereteket. Valami olyasmit akartam, ami mérési sorozatokhoz használható, és működik a saját cuccaim nagy részével, kompatibilis sokféle kommunikációs interfésszel. Az egész rendszernek beépülő modulokon kell alapulnia, a jövőbeli fejleszthetőség érdekében.

Létrehoztam pár objektum típust a fentiekhez:

Vezérlő (controller):

Valami ami az egészet viszi a hátán. Elindítja a mérési sorozatot, esetleg még valami alapadatot is produkál. Egyenlőre ezek készültek el:

- Folyamatos vezérlő (continuous controller): Csak lefuttatja a méréseket egymás után, majd újra és újra, amíg meg nem állítod. Ez a szokásos működési módja a legtöbb műszernek, mint pl. a multimétereknek.

- Single shot vezérlő (képtelen vagyok értelmes magyar nevet találni neki): Lefuttat egyetlen mérést, majd megáll.

- Változó vezérlő (variable controller): Beállítható a mérési sorozatokhoz. Ad egy vagy lineáris, vagy logaritmikus forrás adat sorozatot. Eredetileg a HP8903-ra gondolva készült. Az első kísérletekben logaritmikus frekvencia forrásként használtam a beépített szinusz generátorhoz.

Műszer (instrument):

Eszköz (tipikusan műszer), ami mér valamit. Képes a láncban korábbi mérés eredményét használni, és/vagy mérési eredményt produkálni a láncban utána lévőknek.

Eddig két műszer típus készült el: HP8903 Audio Analizátor, HP3478A 5,5 digites multiméter (a többi folyamatban)

A műszerek minden esetben külső (szoftver) trigger üzemmódban működnek. Az ok: a fenti szoftver vezérlők intézik a mérést és nem a műszer belső vezérlése.

Szűrő (Filter):

Eredetileg arra terveztem, hogy eredményeket lehessen velük szűrni, matematikai számításokat végezni, adatokat konvertálni. A fejlesztés közben kiderült, hogy ehhez hasonló funkciókra, a műszerek között is szükség van. Rájöttem, hogy a szűrő plug-in-ek külön tartása semmilyen hozzáadott értékkel sem rendelkezik.

A szűrő funkciótól meg fogok szabadulni és a szűrőket műszerként fogom létrehozni.

Cél (target):

Valami ami meg tud jeleníteni, vagy el tud menteni mért eredményeket. Jelenleg két cél eszköz érhető el:

- Digitális megjelenítő: ki tudja írni a mért értéket, továbbá minimum, maximum és átlag értéket is kijelez, változtatható helyiértékkel (pontossággal)

- Grafikon megjelenítő: A mért értéksorozatot grafikonként jeleníti meg, több különböző mérési sorozat megjelenítésére alkalmas, lineáris vagy logaritmikus skálát használva (még nincs teljesen kész)

Kapcsolatok (connections):

Ez nem része a mérési láncnak. Ez a műszerek és a PC közötti kommunikációs interfész. Ami jelenleg elérhető:

- AvrGPIB - Az én saját tervezésű GPIB csatolóm (a fejlesztésről írtam pár cikket korábban)

- IVI VISA - Az iparági szabvány csatoló. Én a Keysight szoftver könyvtárával és egy Keysight USB/GPIB csatolóval próbáltam. Ez egyenlőre még eléggé instabil. További fejlesztés szükséges.

- Soros - Ezt meg is valósítottam meg nem is. Az AvrGPIB ezt használja mint legalsó szoftver réteg, de közvetlenül egyenlőre próbáltam, így ilyenkor lehetnek vele gondok.

Tehát, itt tartok jelenleg. Kipróbáltam a HP 3478A-val:

Majd később a HP 8903B-vel is:

Ez csak egy váltakozó feszültségű szint mérés, a kimenet és a bemenet közvetlenül összekötve, 20-20000Hz-es pásztázás, 1V jelszint. Sajnos ezen látható némi hiba:

Némi módosítással a grafikon (még mindig nem végleges):

Látszik egy 2% körüli hiba. A műszer némi javításra szorul (minimum a táp kondenzátorok cseréjére).

Folytatni akarom a fejlesztést, hozzáadva további műszerek támogatását. Ezen túl is rengeteg ötletem van a program továbbfejlesztésére.

A kód C#.Net-ben készült Visual Studio 2019-el. A kód itt található:

https://gitlab.com/suf/suf-electronics-VirtualInstrument

Bárki akinek tetszik a project, van szabadideje, némi programozási tudása, és szeretne segíteni a fejlesztésben, jelentkezzen nálam, minden segítséget szívesen fogadok.

GP-IB 5. - V2.0 Panel

Amikor az előző részét írtam ennek a bejegyzésnek, az egyik barátom megjegyezte, hogy túl rövid lett. Megígérhetem. Ez nem lesz az.

Előzmény
Már van egy pár GPIB modul az asztalomon. Van a saját fejlesztésem 1.0-ás, az 1.1-es (és mostmár a 2.0-ás) verziójából. Az egyik 1.0-ás modul nem működik jól. Arra gondoltam, szükségem van némi diagnosztikára a szoftverbe, hogy könnyebben megtaláljam a probléma forrását. Tehát írtam némi diagnosztikai kiegészítést a jelenlegi parancskészlet mellé. Ez képes közvetlenül manipulálni a GPIB lábakat (ezzel meg is próbáltam megtalálni a hibát, de eredménytelenül).

V2.0-ás modul
Hogy továbblépjek a projecttel, beforrasztottam egyet a következő generációs panelből. Ehhez némi szoftver módosítás is tartozik miután ATMEGA32U4-et használtam hozzá az ATMEGA328P helyett.

Minden könnyen ment. Túl könnyen
Az ISP programozás azonnal sikeres volt. A szoftver módosítások nem tartottak tovább öt percnél. A modul azonnal működött egyetlen könnyen javítható szoftver hiba kezelése után.
Hozzákötöttem a tesztre használt HP3478A multiméteremhez. Lefuttattam egy scan parancsot. Azonnal megtalálta a multimétert és jött is vissza a válasz. Az egyetlen pici probléma annyi volt, hogy a visszajövő karakterek egyesével, igen lassan jelentek meg a terminálon.

Következő nap - hibakeresés
Azt gondoltam, hogy a hibát, egy rosszul beforrasztott láb, és ebből következő időtúllépés okozza.
Elindítottam a diag üzemmódot, és azt tapasztaltam, hogy a D1, IFC, SRQ és ATN lábak mindenképp magas logikai szinten vannak, bármit csinálok.
A probléma gyökerére nézve - a többi, működő modullal játszva - kiderült, hogy a diag mód bizonyos lábakat nem korrektül kezel. Módosítottam a diag mód kódját. Ez megoldotta a problémát az 1.0-ás és 1.1-es modulon, de ezen nem. A D1 és az ATN probléma megmaradt.
Később, valahogy rájöttem, hogy ezeket a lábakat az Arduino Leonard panel (aminek a konfigurációját és bootloaderét használtam) az USB kommunikáció RX és TX LEDjének meghajtására használja.
Anyám.

Újratervezés vagy harc?
Itt jött a dilemma. Két lehetőségem van:
Vagy újratervezem a panelt és újra elküldöm gyártásra, vagy megküzdök az Arduino bootloaderrel, a core-al, vagy bármivel, ami szembe jön. Azt választottam, hogy harcolok. Okok:

• A tervezés és gyártás pénzbe kerül, és jópár napig (vagy hétig) eltart amíg az új panel ideér
• Az ATMEGA32U4-nek két teljes 8 bites kívülről elérhető portja van. Ezeket tudom gyorsabb párhuzamos kommunikációra használni közvetlen port manipulációval. Sajnos a két LEDet pont belerakták egy-egy lábára a két portnak. Tehát, ha azokat a lábakat nem használom, sebességet vesztek.
• Ásni ez esetben, szórakoztató. Tudok tanulni belőle

Okoljuk a bootloadert
Tulajdonképpen nem is tudom miért, talán olvastam valamit az egyik fórumon, azt gondoltam, módosítanom kell a bootloadert és ez megoldja a problémát (talán a soros kommunikáció a bootloader kódját használja, nem tudom)

Új bootloader
Először is megkerestem a bootloader forráskódját. Itt található (https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina). Belenéztem a Makefile-ba, a forráson kívül szüksége van a LUFA könyvtárra az USB kommunikációhoz. Ezt is kiszedtem a git-ből. Hozzácsaptam a legutolsó Win64 kompatibilis avr-gcc-t és a make-et.
Több dolgot is kipróbáltam, hogy a Makefile megtalálja a LUFA-t, minden kísérletem zátonyra futott. Továbbá a grep-et is hiányolta. Úgy éreztem, a Windowsos kísérletem zsákutcába jutott.

Irány a Linux
Nem akartam Linux gépet építeni, vagy Hyper-V alapú Linux gépet telepíteni. Ezért beüzemeltem a Windows Linux alrendszerét és felraktam rá egy Ubuntu 18.04LTS-t a Microsoft Store-ból.
Felraktam rá az avr-gcc-t, build-tools-t, make-et, stb.
A Windows fájlrendszeren keresztül bemásoltam a forrásokat.
Nem működött. Mindenféle jogosultsági bajaim voltak a másolt fájlokkal, tehát feladtam ezt és inkább lehúztam mindent újra a gittel.
Amikor megpróbáltam lefordítani, a grep-et leszámítva ugyanazok a hibák jöttek elő, mint a Windows-on. Jónéhány elérési út módosítás és az USB VID és PID megadása után végül elindult a fordítás. Az eredmény katasztrófa:

A kérdéses bootloaderhez 8 éve senki sem nyúlt. Mind az avr-gcc, mind a LUFA könyvtár fejlődött azóta.
Kiderítettem, hogy melyik LUFA repo tag-gel fordították eredetileg és átkapcsoltam arra. Így, gond nélkül lefordult a bootloader.

Bootloader próba
Nem akartam belehekkelni a bootloadert az Arduino IDE-be, tehát manuálisan raktam fel a panelra.
Feltöltöttem a saját kódom is. És...

Nem működött. Az eredeti hiba maradt.

Hekkeljük meg a core-t?
Nem. Ugyan kiderítettem, hogy a probléma az USBCore.c-ben van. Nem akartam belepiszkálni. Nem lenne egy jövőálló megoldás.
Körülnézve és gondolkozva arra jutottam, hogy egy Arduino board specifikációt kell gyártanom a projectemhez.

Új board konfiguráció? - még nem
Először is akartam valamit, amiből tanulhatok. Találtam egy ATMEGA32U4 alapú módosított panelt az ArachnidLabs-tól (http://www.arachnidlabs.com/tsunami/), és a hozzá tartozó git repót https://github.com/arachnidlabs/arachnidlabs-boards
Azonnal világossá vált, hogy szükségem van egy stabil helyre a json és a package zip tárolására/megosztására. Valamire, amire számíthatok, hogy hosszútávon ott lesz. Valamire, ami elérhető, mindenféle authentikációs vudu (lásd OneDrive) nélkül.
Az AVR-GPIB projectem a GitLab-on lakik, így ott néztem körül. Ahogy a GitHub-on van GitHub pages, úgy a GitLab-on van GitLab pages - milyen meglepő.
Elolvastam a dokumentációját, nem lett tőle érthetőbb, hogyan kell a GitLab pages-t összerakni.
Csináltam egy suf.gitlab.io nevű repót, és belepakoltam a fájljaim. Semmi sem történt.
Rendben, úgy tűnik, hogy szükségem van a gitlab-ci.yml-re az oldal összerakásához. Ez nem meglepő koncepció számomra, miután az elmúlt pár évemet DevOps mérnökként éltem. Jenkins CI/CD scripteket írok nap mint nap.
Megírtam a scriptet, bepakoltam a repóba, hiba. Valami elnevezési probléma. Javítottam.
Következő. Most lefordul hiba nélkül. Az oldal még mindig 404-et ad vissza.
Sok próbálkozás után rájöttem, hogy a GPIB alkönyvtár tartalma a weboldal gyökérkönyvtárában landol. Arra gondoltam, hogy az lehet az ok, hogy a gyükér könyvtár üres, nincs benne fájl, csak a GPIB könyvtár. Így hozzáadtam egy index.html-t.
A korábban sikeres fordítás, most elhasalt.
Sok dolgot elolvasva, több próbálkozás után kiderült, hogy az egyetlen módszer, ami működik, átpakolni mindent egy újonan generált átmeneti könyvtárba és átnevezni (mv) public-ra, ami a publikációra kijelölt könyvtár.
Végül megszületett a GitLab pages oldalam: https://suf.gitlab.io
Kicsi is, sárga is, savanyú is, de a miénk.

Új board konfiguráció? - mostmár tényleg
Megírtam a json fájlt, módosítottam a pins_arduino.h-t (a LED-ek, most két olyan MCU lábra mutatnak, amik nincsenek a tokból kivezetve), összeraktam a csomagot, legeneráltam a hash-t, hozzáadtam a json-hoz, feltöltöttem az egészet a GitLabra, hozzáadtam a json-t az Arduino IDE-hez, bementem a board manager-be és...
semmi sem történt.
Megjavítottam két dolgot, ami bugnak látszott: a json fájl nevét. Mint kiderült ez követelmény, valamint a package fájl hosszát a json-on belül.
Fel a gitre, be az Arduino-ba. Mostmár megjelent a cuccom a board manager-ben.
A telepítés - elszállt. A package.zip-en belül egy db gyökér könyvtárnak kell lennie.
Javítottam, újra végigmentem a procedúrán. Mostmár működik a telepítés.
Megpróbáltam feltölteni a saját kódomat.
Kaptam mindenféle össze-vissza hibát, kommunikációs problémák. Visszamentem az Arduino Leonardo-ra. A hibák maradtak. Windows COM probléma szaga volt. Gép újraindít, a kommunikációs hibák eltűntek.
Megint megpróbáltam feltölteni. avrdude paramétereket hiányolt. Mindenféle paraméter jellegű dolog jött elő később.
Végülis beraktam mindent a package.txt-be amit találtam és értelmesnek tűnt. Úgy tűnik, az ArachnidLabs féle konfiguráció egy korábbi Arduino IDE verzióhoz készülhetett, ami még nem igényelte ezeket a paramétereket.
Végre a feltöltés működik.

Próbáljuk ki
A GP-IB diagnosztika funkció végre úgy működik, ahogy kell. Készen vagyunk!!!!
Neeeeeeeeeeem.
A diagnosztika megy, a kommunikáció az eszközökkel, na az nem. Elég! Alvás!

Másnap
Valami viszketett az agyamban. Kipróbáltan a korábban működő modulokat is. Azok is megszűntek működni.
Vagy a tesztekhez használt HP 3478A multiméterem döglött meg, vagy a diagnosztika szoftver módosítás belekavart a kommunikációba.
Gyorsan kiderítettem: a diag volt a bűnös. Javítottam. Mostmár működik a v2.0 modul.

Vége a történetnek.
További hardver és szoftver fejlesztés következik a GP-IB adapterhez.

GP-IB 4.

Kilenc hónap. Ma napra pontosan kilenc hónappal ezelőtt írtam utoljára a GP-IB adapteremről (http://it-pro-hu.blogspot.com/2019/07/gp-ib-3.html). Nehéz szülés volt.
Büszkén jelentem be, mint apa a működő GP-IB interfész szoftverem. Még nőnie és tanulnia kell. A tudásából még hiányoznak képességek, mint a device üzemmód és a USBTMC.
Mind az apa:

Az anya:

És a gyermek:
https://gitlab.com/suf/suf-electronics-gpib

Jó formában vannak:

És várják hosszú és eredményes életét.