Zpět na seznam článků     Zpět na článek

Komentáře ke článku

 
 
 BBCode
Jiri Pittner | 147.231.28.*18.1.2016 13:33
Ohledne debugovani u AVR pod linuxem - zatim jsem si vzdy vystacil
s kombinaci debug printu na USART a pro realtimove veci,
preruseni apod., debuguji pomoci 1-2 GPIO pinu a osciloskopu.
I2C, SPI apod. se stejne v pripade vetsich potizi musi prohlednout
osciloskopem nebo log. analyzatorem.
V mene kriticke rutine preruseni se casto da udelat kontrolni tisk 1 znaku na USART!
Vetsi atmegy podporuji JTAG a s nim se pak da pouzit OPENOCD a normalne GDB,
ale realtimove veci se tim stejne neodladi.

Co se tyce kompilace, proc psat scripty, kdyz mame GNU make, ktery zkompiluje je nove zmenene soubory?
V Makefilu nastavim aktualni projekt, soucastky a frekvenci krystalu
a po editaci kodu napisu 'make upload' nebo 'make upload2' (flash+eeprom)
Pouzivam tento Makefile [link]
Pro flashovani pouzivam bud avrdude, nebo jednodussi program uisp,
ktery jsem modifikoval tak, aby fungoval i pomoci GPIO pinu na Raspberry pi,
coz umoznuje delat vzdaleny update firmware na zarizenich kombinujicich
RPi a AVR hardware. UISP zdrojak viz [link]


Hnz2 | 85.71.231.*17.1.2016 13:50
nitram147: Malý dotaz ohledně práce s MCU pod Linuxem. Jak se pod Linuxem řeší debugging? Kdysi dávno jsem zkoušel GDB s ColdFirem v uClinuxu. Ale nebylo to nic moc...
nitram147 | E-mail17.1.2016 11:44
Vzhladom na to ze som linuxak a aj keby som chcel rozbehnut na ubuntu avr studio bolo by to dost problematicke, mile rad pisem takmer vsetko (c, c++, php, html, js ......) v Gedite. K AVRkam si vzdy spravim bashovy skript ktory to skompiluje za mna - ked si zobereme do uvahy cas ktory trva nieco skompilovat v AVR studio + nahrat to = je to okolo 20-30 sekund. No mojim jednoduchym sposobom to nezabere viacej ako 3-4 sekundy -> je to vyborne pri vyvoji kodu nieco malinko upravite a mozete to ihned napalit a odskusat :)

jednoducho sudo sh ./kompiluj.sh


----------- kompiluj.sh --------------
#/bin/bash
echo kompilujem ...
avr-gcc -mmcu=atmega329p -std=c99 -Os -DF_CPU=16000000UL -c ./lcd.c -o ./lcd.o
avr-gcc -mmcu=atmega329p -std=c99 -Os -DF_CPU=16000000UL -c main.c -o main.o
avr-gcc -mmcu=atmega329p -std=c99 -Os -DF_CPU=16000000UL -c uart.c -o uart.o
avr-gcc -g -mmcu=atmega329p -o main.elf main.o lcd.o uart.o
avr-objdump -h -S main.elf > main.lst
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avrdude -c usbasp -p atmega329p -U flash:w:main.hex
-----------------------------

Pre neznalejsich kompilacie na prikazovom riadku - staci vam upravit si nazov cipu na tej ktory aktualne pouzivate (v tomto priklade pouzivam Atmega329p) a pozmenit si nazvy kniznic, ktore sa tiez kompiluju, popripade ak mate arduino zmenit programator z usbasp na arduino alebo akykolvek iny programator, ktory pouzivate. Vela zdaru :)
Hnz2 | 85.71.231.*14.1.2016 18:19
Jiri Pittner: Tak to se živíte oblastí které vůbec nerozumím. Už taková FFT je pro mě nějaká "ďábelská" magie. A lidi co jí vládnou by měli upálit na hranici :-)

I když jako "vyučený" automatizačník bych k nějakému numerickému modelování nemusel mít teoreticky daleko. Hold skoro 8 let vývoje embedded systému udělalo svoje. Zabývám se převážně komunikacemi u měřících přístrojů a pak funkční bezpečností.
Prog0el | E-mail14.1.2016 18:17
Děkuji za podnětnou diskuzi a zmíněné chyby jsem již předal k řešení. Rovněž se přikláním k názoru, že LPT není příliš vhodný pro začátečníky, ať už se jedná o malou blbuvzdornost portu, nebo možné napěťové špičky na výstupech LPT.
Vaše komentáře jistě využiji ke zkvalitnění budoucích článků.
Jiri Pittner | 147.231.28.*14.1.2016 13:16
HNz2: Dekuji za vecne komentare.

Co se tyce programovani pres LPT, ja jsem tak zacinal a obcas to pouzivam dodnes.
Pravda je, ze v HW jsem nebyl uplny ignorant, takze se mi zadny port jeset odpalit
nepovedlo, ale souhlasim, ze to pro zacatecnika muze byt problem.
O problemech s LPT pod windows nevim, ja cely zivot pouzival jen unixovy
a pozdeji linuxovy desktop, takze jsem trochu "biased".

Ohledne prenositelnosti - samozrejme, periferie jsou uplne jine.
Ale nizkourovnove funkce se casto daji izolovat do nejake vrstvy
a napr. sifrovaci algoritmy, datove struktury a hlavni logika muze byt
napsana prenositelne. Vyrobil jsem si napr. bezdratove rizeny termostat,
jeden ve verzi s ATmega a pozdeji jiny ve verzi s LPC1114 a velkou cast kodu
jsem pouzil beze zmeny. Neni to sice zadne komplikovane zarizeni, ale
princip je pouzitelny myslim obecne.
Pro ev. zajemnce me open hardware/open source hobby projekty jsou na
[link]

Co se tyce IDE, proti gustu zadny disputat :-). Ja jsem si zvykl na shell,
vim, make, gdb/ddd a plne mi to vyhovuje i v praci - ale asi nejsem typicky pripad
- zabyvam se numerickymi metodami a high performance computing v teoreticke chemii.
Nektere dodnes pouzivane programy v tomto oboru jsou jeste ve Fortranu 77,
i kdyz C++ a obcas Python se zde uz take zacaly pouzivat :-).
Hnz2 | 85.71.231.*13.1.2016 19:59
Jiri Pittner: Jenom pár poznámek k Vaší poznámce.

Ad paralelní programátor:
Doporučovat začátečníkům paralelní programátor na LPT není dle mého názoru vůbec rozumné. LPT porty nejsou moc blbuvzdorné a není je problém jednoduše odpálit. Dále na x64 bit Windows je tyto programátory problém zprovoznit. LPT patří na x86 mezi i/o porty a tudíž systém na ně nepovolí přistupovat. Je nutný kernel driver. Na 32bit Windows je to ještě celkem rozumně řešitelné, ale u 64bit je to problém o poznání větší.

Ad přenositelnost:
Jinak použití typů int16_t, int32_t, atd. je určitě rozumné. I když nějaká větší přenositelnost kódu mezi různými platformami je spíše chiméra. MCU jsou hlavně o periferiích. A ty se liší rodina od rodiny. Snad nějakou míru přenositelnosti může nabídnout použití RTOS s příslušnými periferními knihovnami.

Osobně bych si svoji práci nedovedl představit bez dobrého IDE. V práci používáme převážně IAR. I když je to jiná cenová kategorie než různé "bastly" postavené na Eclipse a GCC tak efektivita práce je úplně jiná. Kdo nezkusil asi nepochopí...
Jiri Pittner | 147.231.28.*13.1.2016 11:05
Programovanim MCU (AVR i ARM) i hardwarem se zabyvam jako hobby uz 12 let.
Impulsem zacit byl pro mne clanek na abclinuxu.cz v roce 2004, takze tomuto serialu fandim :-).

8-bity jsou sice dnes zastarale, ale pro radu ucelu staci a definitivne jsou
pro zacatecnika vhodnejsi, protoze jadro i periferie jsou mnohem jednodussi a nevyzaduje
to tolik nastaveni ruznych veci.

K prvnimu dilu bych jeste dodal, ze je treba mezi VCC a GND dat keramicky kondenzator 100nF. Ono to bez nej muze bezet pri napajeni z programatoru s kratkymi vodici,
ale nebude to stabilni a s jinym zdrojem to pak treba nebude chodit vubec.

Pokud jste softwerari a nechcete se hardwarem zabyvat, je hotove arduino lepsi,
ale pokud si vse postavite sami z jednotlivych soucastek, naucite se vic.
Zrovna tak neni treba integrovane vyvojove prostredi, ja pouzivam avr-gcc, make,
a avrdude. to muze byt otazka vkusu, ja jsem trochu staromilec delajici vse z prikazove radky.

Pokud mate desktop nebo dokovaci stanici s paralelnim portem,
neni treba ani zadny programator, staci 5 dratu a konektor (google avr isp parallel port).
port) - nestoji to skoro zadne penize.

K tomuto dilu bych podotknul, ze kvuli prenositelnosti je lepsi pouzivat typy
uint8_t, int16_t atd., mne se to velmi osvedcilo, spoustu kodu puvodne napsaneho
pro AVR jsem s minimalnimi zmenami prenesl pro ARM 32bit.
SulisH@cker | E-mail | ICQ 496-635-7306.1.2016 12:26
Chvályhodná práce, jen tak dále :-)

----------
Není moudrý ten, kdo ví mnoho, ale ten, kdo ví, čeho je třeba...
opaka | E-mail | Website31.12.2015 12:01
Když tak rád opravuješ tak napiš svůj článek ,místo opravování ostatních.

Stránky: 1 2