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.