( bucko | 2019. 09. 20., p – 08:01 )

valaki helyesen leírta nagyságrendileg C64 szintű teljesítménye van
Csak nem helyesen. Eltekintve a speciális hangcsiptől és a nagyobb memóriától, egy mai szerkezet (PIC16/18, 8-16MHz utasítás-órajel) kb. 30x gyorsabb. Ráadásul a beépített periféria választék is olyan, hogy "minden van", akár egy 8 lábú tokban.

Nem is állítottam olyat, hogy 100 sor mindent kezel, hanem egy kérdés volt:
Avagy mennyire kell egy 100 soros assembler programnak hasonlítania egy RTOS alá megírt szoftverhez?

Már 85 óta állapotgép - de nem menü, hanem eseményvezérelt automata (FSM) alapú programokat készítek. Elég megírni az eseményhez tartozó akciót, ami általában rövid. Ha szükséges, lehet debuggolni, de minden esetben felesleges. Legfeljebb a "print" alapú követést vagy állapotkijelzést használom. Úgy is van USB, amihez elegendő egy HID terminál. Ha meg nincs, akkor soros port és putty. Itt egy kis példa, ami ugyan nem 100 bájt, de legfeljebb 94 utasítás. Hálózatra szinkronizált hiányzó impulzus detektor. Ha Sanyi kolléga lekapcsolja a villanyt a fürdőszobában, akkor még - jumper segítségével konfigurálhatóan - 2 vagy 4 percig megy a ventillátor. Ez egy eseményvezérelt végesállapotú gép, főprogram nincs. Ez a könnyebben olvasható C átirat. (Nem biztos, hogy működőképesek vagy komplettek az átiratok!) Debuggolni, szimulálni minek.
De a 10k méretű assembler program is így készül.

Sajnos nagyon gyors lett a hardverek kivezetésének a tempója.
Akkor ebben a Microchip sokkal jobb. Nagyon sokáig gyártja a mikrokontrollereket. Ha valami megszűnne, akkor van olyan típus, ami kód kompatibilis. A perifériák uniformizáltak és egy osztályban processzorok egyformák. Az ATMega 2560 meg nagyon drága.

gyorsabb lesz fejlesztés közben a visszajelzés, ha nincsen benne az égetés, átülés a vashoz, stb a folyamatban.
A 80-as évek végén kölcsönkérték az EPROM égetőnket. ;)
Az asztalomon ezek voltak:
- XT V20 processzorral, amin futott a natív 8080 kód és így az Intel Isis-II fejlesztőrendszer is.
- nyomtatókábel
- a fejlesztett hardver +4k RAM
A lefordított programot kiküldtem, amit a hardverben a betöltő program relokált és futtatta.

Az algoritmust egy kollégám tervezte, de csak bipoláris processzorokhoz értett. Én az egyes hardverelemek kipróbálása után (Vajon jól rakta-e össze a műszerész?) megírtam az egyes részek működtetésére szolgáló programocskákat és makrókat, meg a seek-hez szükséges perc:másodperc.frame számításokat. A fő algoritmust egy hétvégén átírtam 8085-re, és hétfőre működött egy CDROM. Az egész fejlesztés jó 12 hétig tartott, hárman csináltuk. Ennek tetemes részét tette ki az embargós lopott CDROM szabvány, a Reed–Solomon és a másodlagos hibajavítás tanulmányozása, illetve az optomechadeck kicsit hibásan működő parancskészletének kicselezése.
Meg még az osztályvezetőnek is kellet szerezni egy AT-t, meg nekem az XT-t, hogy legyen min dolgoznom. ;) Az ilyen "adminisztrációs" feladatokat a csapat harmadik tagja végezte.
A program szerkezete egy kicsivel bonyolultabb volt a fenti példánál:
- A főprogram nem volt üres, mert ellenőrizte, hogy megnyomták-e a tálca nyitás nyomógombját és standby állapotban vagyunk vagy olvasunk. Az utóbbi esetben meghívta a vezérlés által bekészített szubrutint.
- A többit az 5db huzalozott megszakítás intézte. (A 8085 ennyit tud.)

Meg olyan is előfordul, hogy ahogy adják hozzá a funkciókat, a termék kinövi a vezérlőt, és akkor nagyobbra kell lépni.
Ilyet nem igazán tudok elképzelni, ha jó volt az alkatrészválasztás. Persze, ha a tíz évvel elzelőtti kenyérpirítóból azóta űrhajó lett, akkor talán. ;) Ugyanabban a 8 bites családban nincsen sokkal gyorsabb elem, így legfeljebb a 8-16 bites váltás marad, de az drágább. Meg a csak 5V-os verzióban létező szenzorokat újra kellene illeszteni a 3,3V-os processzorhoz. Szóval csak a baj lenne vele. Az összes többi problémára meg ott van az I2C busz, amire lehet port extendert és memóriát is kötni - és még olcsóbb is. A program mérete a komplexitással egyre kevésbé nő. Nekem 12k a legnagyobb programom a 16k területen. Ha ezt kinőném, akkor ott a 24k-s verzió is.
Két eset volt csak, amikor majdnem megszorultam. Nőtt a bemenetek száma és a hozzá tartozó analóg hardver mennyisége is. Ekkor közölte a tervező bácsi, hogy még egy ellenállás és jön a 4 réteg - bár hely az még van. A másik esetben meg majdnem elfogytak a portok, pedig csak USB, egy nyomásmérő, egy nyomógomb, egy eeprom és egy túlbonyolított tápegység volt a panelen.

Szerintem az a baj, ha szoftveres akar szoftver eszközökkel hardvert fejleszteni és a fejlesztést szoftverrel támogatni. :-D Nekem meg mindegy miben írom, ezért az algoritmust tesztelem awk-ban és megírom assemblerben.
Vitatkoztam már hasonlón egy szoftvermérnökkel. Nem értette, hogy ha egyszer elkészül egy firmware és működik, akkor ahhoz nem kell többé hozzányúlni. Mert ha kellene, akkor nem jól működne, azaz kész se lenne. ;) Tehát én hibátlanul programozok. Vagy mégse? ;) Szóval néha tényleg kell javítgatni, de a működés és használhatóság kívülről nézve mindig ugyanaz marad.
Bár egyszer vissza kellett hívni 10db terméket. A főnököm a "teszteld" helyett azt értette, hogy "add el". ;)