Mam docela radost ze se tu objevilo arduino :) Jenom pridam ze jestli se nekdo chce levne naucit s mikrokontrolerama pod linuxem, doporucuju ‚proste‘ zajit do elektra a koupit nejaky AVR (treba tiny2313 u nas asi za 30kc), konektor na paralelni port pc a nejakou bastldesku a ma vsechno co potrebuje k programovani mikrokontroleru. AVR maj v linuxu skvelou podporu pres avr-libc a gcc, programovani pres paralelni port pres avrdude :) Jinak samozrejme arduino to nenahradi – je treba si to poskladat, naucit se s tim Cckem nebo assemblerem (na strankach avr-libc jsou skvely priklady) a precejenom to programovani bude horsi nez wiring. Ale pro C kodery co se chtej zacit stourat v hardwaru je tohle si myslim skvela cesta jak se s tema svabama seznamit.
Podpora na Linuxu je skvělá pouze do chvíle než začnete potřebovat krokování programu a nějaký pořádný ladící nástroj. Pak zjistíte, že je to tragédie. Něco pořešíte třeba starým AVR studiem 3 pod Wine, v případě aktuální verze AVR Studia vás čeká jen vztekání se nad wine.
Nativní avrsimul je mrtvý nedodělek, který je dobrý tak na hraní, avarice ve spojení s gdb je všechno jen ne efektivní nástroj – ale se zatnutými zuby to pravda jde, podpora nových mikrokontrolérů je ale mizerná.
Ono to jde pomerne dobre i bez debuggeru. Ja jsem tak nejak zvykly na to debugovat embedded veci pomoci hlasek (nyni k tomu pouzivame www.microvga.com – jako ze primo aplikace v MCU vypisuje debug hlasky na monitor, ale samozrejme jde pouzit i RS232 do PC ci nejake FTDI na USB CDC). Ono to ma jednu obrovskou vyhodu – da se s tim ladit i ruzna komunikace a casove zavisle veci, to s debuggerem neudelate. A prijde mi, ze 90% problemu u embedded veci se pomoci debuggeru nevyresi. Tedy pokud jen neblikate diodou :-).
Dle meho nazoru Linux na vyvoj s AVR, ARM, MIPS, MSP430 apod. je docela vhodny. Alespon nemusite resit problemy typu „IDE mi pul hodiny ignorovalo zmenu v souboru cosi.c a proto se program choval divne, ale stacilo udelat close/open a vse se vyresilo“. Jedine IDE co pod Win32 za neco stoji je IMHO visual studio od MS.
Jo s tim souhlasim, me to debugovani od dob co sem se ucil s assemblerem uz zatim nechybelo. Jinak doplnim ze co vim tak akorat s PICakama je to spatny – neni k dispozici poradnej C prekladac, muze nekdo pls doplnit? zajimalo by me jak je to s picakama pod linuxem protoze se mi jich v supliku par vali :)
Dost odvážná a subjektivní tvrzení.
Právě v případech, kdy jen neblikáte ledkou je dobrý simulátor a debuger někdy k nezaplacení. Samozřejmě není to samospasitelné a jde to i bez toho, jen pak člověk někdy ztrácí čas nad něčím co je v debugeru jasné během chvíle. Příklad z nedávna- zapomenuté schování registru na zásobník na začátku rutiny(nebo nesprávné použití registru – jak chcete), která občas zničila jeho obsah a program díky tomu vykazoval podivné chování. V debugeru vyřešeno za chvíli, bez něj hodina laborování.....jen drobnost.
a debugovat na avrkach taky pod linuxem jde, vypada to ze avrsimxx nebo jak se tomu nadava je aktivni a uz podporuje par kousku. A pak je tu to stary avr studio. Jinak avarice + eclipse a mate normalni ide na debugovani hardwaru s avr. Ale ja osobne sem dlouho fakt simulator dlouho nepotreboval, radsi pisu prehledny C a snazim se assembleru vyhnout dokud to jde takze asi proto (souhlasim, opravdu je to subjektivni)
Jsem starý kořen, začínal jsem s programy pro 8080 a sqělou Z80 :-) a mán na věc následující názor. Pokud programuje člověk, co věci rozumí a nezjišťuje co dělá trivialita typu podmíněného skoku, tak debug spíše zdržuje. Já si vypisuji přes jeden port do terminálu info které potřebuji. Chápu že JTAG mi pomůže se vyhrabat z věcí, které jsou jinak těžko řešitelné, ale leděním si nepředstavuji krokování programu v debuggeru. Než bych ty tisíce loops prošel, tak bych umřel stářím. Člověk stejně ty programy skládá z odladěných bloků, které vytvořil dřív, takže případné překlepy nebo přehlédnutí odhalí terminálem. A dnes je možné reprogramovat flash klidně 20k krát a to by aplikaci odladilo i úplné nemehlo.
Také jsem starý kořen. Dokonce jsem vedle 8080 a Z80 začínal na procesoru minipočítače ADT4000.
Když debugujete tím způsobem, že v debugeru čekáte na provedení tisíce smyček, to máte fakt těžké. Něco jako breakpoint, step over, trace into, … a podobné vymoženosti vám nic neříká?
Na ADT4000 jsem si jen vykresloval na plotru, nic jsem tam neladil. Jistě že jsem se už setkal s breakpointy a přeskakováním volání, nicméně názor neměním. Zkrátka obvykle postupuji nez debuggeru, jen si vypisuji ladicí informace. Zkrátka mám pocit že tak dosáhnu konečného výsledku rychleji. Možná je to tím, že debugger zpomaluje běh procesoru a tak něco ani ladit nemůžu, zatím co výpis můžu umístit tam, kde mi malé zdržení nevadí. Jinak také někdy debugger použiju, není to pro mě nějaké dogma.
Ja pouzivam http://www.amctools.com/vmlab.htm . Pod wine funguje dobre.
Podle mne nekdy nepomuze ani simulator anidebuger kdyz se jedna o komunikaci mezi zarizenimi . Na toto sem si koupil logicky analyzer je to skvela hracka a funguje pod linuxem , je to sice pres wine ale vyrobce zarucuje funkcnost pod wine s tim ze dodava i so. knihovny do wine aby to jelo