Názory k článku Osmibitové mikrořadiče Rabbit: praví dědicové mikroprocesoru Zilog Z80
-
diky za pripomenuti, tenhle processor znam a zazil jsem s nim mnoho bezesnych noci.
Predevsim diky "skvelemu", taktez zminenemu, kompilatoru Dynamic C.
To bylo naproste nestesti.Historie byla priblizne takova - delali jsme prenosne terminaly se Z180. Ale byly hardwarove prilis slozite, byla zapotrebi 4 vrstva deska, bylo tam moc soucastek. Tak jsme se rozhodli, ze to predelame pro Rabbita.
Zdalo se, ze vsechno bude velmi jednoduche, Rabbit ma spoustu nozicek, vetsina IO bude primo na nem. Skutecne, hardwarove to vyslo jednoduse, jenom Rabbit a par dalsich soucastek.
Pak jsme portovali program (napsany vetsinou v C) na tohle Dynamic C. To byla silenost. Dynamic C je (nebo tehdy kolem 2000 byl) na hony vzdaleny normalnimu C. Nic nechtelo fungovat, byla to nocni mura. Stare terminaly ve skladu pomalu dochazely a nove jeste nebyly hotove, protoze chybel firmware. Tam to doslo dokonce i tak daleko, ze jsme poslali cele zdrojaky autorum tohoto kompilatoru at zjisti, proc to kompiluje spatne. Skutecne si ty zdrojaky asi cetli, protoze v jednom komentu bylo napsano "Dynamic C di merda" (italsky "na hovno") a Larry Cicchinelli (techsupport firmy ktera tento kompilator delala), jehoz jmeno prozrazuje jeho italsky puvod potom tento koment citoval v odpovedi :-). Na problem sice neprisli, tvrdili, ze u nich to kompiluje dobre, ale pak jsme to nejak obesli.V kazdem pripade to nakonec dopadlo tak, ze jsme to pak nejak dostali do fungujiciho stavu, ale po par mesicich jsme se dostali do slepe ulicky. Program fungoval, ale jakakoliv zmena v programu zpusobila prepsani casti vysledneho kodu - proste linker prepsal kus uz hotoveho kodu dalsim blokem - bylo to krasne videt v hex file. Nebyli jsme schopni dal udrzovat firmware, vzpominam si, ze posledni upravy jsem uz delal primo do binarniho kodu. Ceckovy kod uz byl neprelozitelny a vyrobce Dynamic C s tim nebyl schopen nic udelat. Dokonce jsem zacal uvazovat o tom, ze budu portovat gcc na Rabbita.
Nastesti jsme nasli jiny kompilator, WinIDE od Softools a ten byl podstatne lepsi, bylo to standardni C, ne takovy bastl jako Dynamic C a po portovani zdrojaku na tohle nove C vsechno fungovalo skvele. Vysledny kod byl o kus kratsi a hlavne fungoval. Zajimave bylo i to, ze Softools byl v te dobe one-man-show. Kdyz byl nejaky problem, a ze jich taky par bylo, tak to behem par dni opravil. Predpoladam, ze nektere z mych idei jak ten kompilator vylepsit, jsou v nem dodnes. Napriklad idea, at preprocessor prida slozene zavorky kolem { #asm ... #endasm }, se autorovi kompilatoru velmi libila. Puvodne mel totiz block #asm velka omezeni, nemohl byt treba tesne pred returnem, ale prisel jsem na to, ze kdyz se vlozi do ceckoveho bloku, prestane to delat problemy. Tak jsem mu poradil at to udela primo preprocessor.
Dodnes, kdyz slysim Dynamic C, prestanu mit chut na jidlo :-)
-
mhi (neregistrovaný)
:-))) Nektere vzpominky jsou na opravdu desive nocni mury.
Pamatuji, ze jeden prekladac delal nekonecne cykly tak, ze nekonecne uplne nebyly. Stacilo udelat while(1) { konkretni kod bez jakehokoliv break ci return nebo chyb } a ukoncilo se to (obcas). Pritom stacilo udelat drobnou zmenu a kod se sam "opravil" :-).
Nebo prekladac C pro Microchip PIC18 umel udelat kod, kdy pridanim jedne naprosto bezne radky typy "intpromenna++;" se nejak domrsila cela fce, ze prestala fungovat (cele telo funkce se zmenilo). Do dnesni doby mam v kodu jednu trivialni fci rozdelenou asi do 5ti s komentari jak pridavat kod, aby se to prave cele vubec nerozbilo. Nezanalyzoval jsem kde byl problem, generovany kod same movXXX a rozkodovat co to dela se ukazalo jako skoro nemozne.
-
Pavel TišnovskýZlatý podporovatelJj to býval dost problém pro spoustu osmibitů; možná někdy napíšu o C pro DSPčka od TI, ten byl taky v některých věcech vychytaný :-/ Mno a první překladače pro HC11...
Nezkoušeli jste SDCC? Pro Rabbit jsem ho sice nezkoušel (píšou, že je podporovaný), ale pro čipy od Freescale (H08...) to generuje pěkný kód.
-
SDCC jsem pouzival pro 8051, byl jsem s nim celkem spokojeny. Delal jsem na nem scanner s OCR, ovsem v nekterych mistech byl radek ceckoveho programu v komentu a za nim blok #asm a u nej comment "// SDCC tohle nedokaze prelozit" :-). Rabbita tehdy neumel.
Jinak, zacinal jsem s AZTEC C pro CP/M a musim po vsech tech letech rict, ze to byl nejlepsi kompilator C pro 8080/Z80. V nem jsem nikdy nenarazil na chybu. A to s nim moji spoluzaci delali opravdu velke projekty - treba automaticky navrh plosnych spoju. Pro firmware jsem pouzival IAR C pro Z80 a Z180, to byl dobry kompilator. V nem jsme tehdy delali ten firmware pro prvni verzi terminalu. V mezicase jsem narazil i na Keil, ale to jenom tak okrajove.
Kdyz uz jsme u tech kompilatoru C, pro PIC se mi celkem libi cpik od Alaina Gibauda, taky je v nem pekny kus meho kodu :-). Ovsem nakonec stejne pouzivam to silene vyvojove prostredi od Microchipu a ten jejich celkem pohodlny klikaci system na konfigurovani periferii. Pohadka? Ne, Nightmare. Pohodlne si naklikas konfigurace pinu a periferek (oscilatory, a/d, voltage reference, usart apod) a oni ti pak zmeni klikaci program, ted uz neni kompatibilni s tim, co bylo predtim, takze sice to jeste prelozis, ale uz do toho nemuzes delat zmeny. Musis si vsechno naklikat znovu, protoze ti idioti neudelali proceduru pro import konfigurace. Otazka pro chytre deti - jak to udelas, kdyz mas ted novou verzi klikaciho programu, otevres po 2 letech ten svuj program v novem krasnem prostredi a vsechny konfigurace jsou ztracene? Pamatujes si jeste jak to bylo zkonfigurovane abys to naklikal znovu? To je pak zazitek. Vzdycky jsem si delal srandu z lidi, co misto psani programu klikaji a ted jsem se chytil do te same pasti :-)
-
Petr M (neregistrovaný)
Klikací noční můra je teď pro mě STMCube. Naklikám cokoliv, ale:
- Na co dokumentovat generovaný kód?
- V ovladačích chybí naprosto zásadní věci, například funkce pro čtení dat z endpointu pro USB Device apod. - CMSIS HAL má v sobě cyklické závislosti .h souborů
- Jenou z nejdražších komodit je RAMka. Při tom handle periferky je struktura, ve které je vložena struktura, která obsahuje konfiguraci ve formátu "každá položka je uint32", a to i když ve výsledku je to jeden bit v registru periferky. Ti už to píšou jak pro Widle.
- Ačkoliv jde přiklikat FreeRTOS, HAL jej nepodporuje a je to jedna race condition vedle druhé :( Místo mutexem se zamyká normální proměnnou, čeká se v cyklu místo osDelay(), xEventGroupWait() nebo xSemaphoreGet(),...
- Zapouzdření modulů neexistuje. Dělám s UARTem, vidím i na USB a Ethernet,..Takže STMCube je sice fajn, ale pro návrh HW, kdy hned vidím, jaký pouzdro použít, jakou periferku zvolit a na který nohy namapovat. Z generovanýho kódu pak preparuju jenom parametry periferky...
-
ehmmm (neregistrovaný)
No, ja v tom po roce 2000 delal neco, co komunikovalo po RS232 i po ethernetu. Nejak jsem do toho naohejbal i ten jejich ukazkovy FTP server i jsem si tam zmastil nejaky HTTP server (nejaky krizenec HTTP/0.9 a HTTP/1.0).
Byla to moje prvni zkusenost s C, kdyz nepocitam nejake trivialni semestralky ve skole.
Kdyz jsem na to nadaval, tak mi tehdejsi sef rikal, ze pry existujou i horsi prostredi. Nemel jsem duvod mu neverit. (Ale on je taky ta generace, co kdyz ve vyzkumaku nafasovali prvni procesor, tak do nej posilali jednotlive tiky hodin a sledovali na nozickach, co to dela.) Nakonec jsem to psal v PSPadu, ale se samotnou kompilaci jsem problem nemel. Ale taky jsem po tom procesoru nechtel zadny zazraky - prijmout data, odeslat data.
Jinak ja do sveta MCU pouze nakukuju a je to takovy zvlastni vesmir. Nez se clovek od napsani zdrojaku dostane do stavu, ze to bezi v procesoru, tak se obcas potrapi.
-
Ten povzdech se zlatym Dynamit C se tentokrat tykal IDE. Ide pro arduino je neco naprosto sileneho, nedokazu si predstavit, ze by to nekdo pouzival pro neco vetsiho nez blikani ledkou a piskani beeperem. Treba absence project file - kompiluji se vzdycky vsechny moduly v adresari a nic jineho - nemuzes si tam linknout tvoje moduly odjinud. Jediny zpusob jak do arduinoveho projektu dostat zdrojaky odjinud je file, ve kterem je pouze include "/neco/nekde/jinde/tvuj_file.c", Tohle muze fungovat pro projekt, kde jsou 2-3 files, ale ne pro nic seriozniho. Mimochodem, jejich slavne "knihovny", kdyz je kompilujes rucne s -Wall, tak maji spoustu warningu. Knihovny, ktery generuje warningy, nestoji zanic.
Ovsem co se tyce kompilatoru, proti nemu nemam absolutne nic, kompiluje se to totiz gcc. Pokud se ti podari vyrobit Makefile a kompilovat to z command line a na editovani pouzivat nejaky normalni editor, tak se s Arduino da udelat i neco co funguje.
Osobne pouzivam arduino jenom pro 3d tiskarnu a pokazde, kdyz to prekladam se musim divit 1. ze to ten processor AVR stiha a 2. kterej debil dosahnul toho, ze arduino je de-facto standard pro rizeni takhle komplexniho zarizeni. Tady by to chtelo ARM. Prvni takovou tiskarnu jsem skutecne delal s ARM a stravil jsem par tydnu portovanim firmware na ARM, ale pak vyvoj firmware sel dopredu a ja jsem zustal viset na tom, ktery jsem upravil. Takze dalsi tiskarny jsem uz potupne musel delat taky s arduinem.
-
Petr M (neregistrovaný)
U lepící pásky rozlišujeme dva typy. První, co nejde přilepit, druhý, co nejde odlepit.
U IDE je to skoro to samý. To, ve kterým člověk týden stráví konfigurací a rozcházením, ale pracuje se v tom samo (např. Eclipse) nebo to, ve kterým se nedá psát, ale ladění atd. funguj instantně (IAR EW).
Nebo může mít člověk obojí, v bývalým EmBlocku nastavovat build v XML (v klikátkách je tak 1/3 voleb, chybí např. režim FPU pro M4) a ještě nemít navigaci v kódu, to je otřes. A vzhledem k nestandardnímu make to ani nejde nacpat do nástroje pro CI...
