Stránka 1 z 1
Podporované MCU pro china JTAG ICE ??
Napsal: 13 kvě 2015, 14:00
od pirat077
Rád bych zprovoznil debug u některých MCU
(momentálně mi jde hlavně o Atmega165P)
tímto debuggerrem:
http://www.ebay.com/itm/USB-Download-Pr ... 4195f60eb2
Kde najdu seznam podporovaných MCU???
+ uvítal bych případně i tip na jiný debugger (cenově třeba do pětistovky)
Napsal: 13 kvě 2015, 14:12
od mtajovsky
Debugger by měl spolupracovat s MCU, které mají rozhraní JTAG.
ATMega16, ATmega16L, ATMega162, ATmega162V, ATmega165, ATmega165V, ATMega169, ATmega169V, ATMega32, ATMega323, ATmega323L, ATmega32L, ATMega64, ATmega64L, ATMega128, ATmega128L, AT90CAN128 a vůbec obecně větší pouzdra. Viz DS.
Za pětistovku nic moc lepšího nedostanete, ale
tohle není špatné.
Napsal: 13 kvě 2015, 14:36
od FHonza
Jenom u toho "China" je potřeba nezapomenout, že funguje jenom v AVR studiu 4.x
A na eBay se dá sehnat
levněji.
Napsal: 13 kvě 2015, 17:09
od pirat077
Díky!!
A není nějakej čínskej Jtag ice, kterej funguje s novějším Atmel studiem (6+) ??
Napsal: 13 kvě 2015, 19:07
od mtajovsky
Problém je, že Atmel Studio6 už nepodporuje spojení přes RS232. Existují i čínské klony AVR JTAG ICE MKII edice XPI i XPII - odolný, ale cena už není tak zajímavá - něco přes $100.
Kromě toho, oproti lepším debuggerům, jako Dragon nebo ten Atmel ICE, levné debuggery JTAG ICE umožní jen málo breakpointů současně - maximálně asi 3 + 4. na krokování. A také jejich odezva na akce ve studiu je o dost pomalejší. Osobně používám Dragon a jen v případě připojení obvodů pod vyšším napětím (a tím vzniku nebezpečí pro debugger) přejdu dočasně na levnou Čínu.
Napsal: 13 kvě 2015, 21:27
od pirat077
mtajovsky píše:Problém je, že Atmel Studio6 už nepodporuje spojení přes RS232. Existují i čínské klony AVR JTAG ICE MKII edice XPI i XPII - odolný, ale cena už není tak zajímavá - něco přes $100.
Kromě toho, oproti lepším debuggerům, jako Dragon nebo ten Atmel ICE, levné debuggery JTAG ICE umožní jen málo breakpointů současně - maximálně asi 3 + 4. na krokování. A také jejich odezva na akce ve studiu je o dost pomalejší. Osobně používám Dragon a jen v případě připojení obvodů pod vyšším napětím (a tím vzniku nebezpečí pro debugger) přejdu dočasně na levnou Čínu.
A neexistuje někde nějaké porovnání Dragon X Atmel ICE ??
Nevím, jaké parametry bych tam měl hledat...o breakpointech, podpoře AtmelStudia, atd... se nikde nepíše...
Víc jak šest breakpointů jsem zatím nikdy nepotřeboval, rychlá odezva se hodí... pak potřebuju jen to, aby to fungovalo spolehlivě a nechovalo se to vyloženě users unfriendly
Cenově už je skoro jedno, jestli bych šel do tohohle:
http://cz.farnell.com/atmel/atatmel-ice ... dp/2407172
Nebo do Dragona:
http://www.kacir.com/vyvojove-prostredk ... ragon.html
Ten Atmel ICE je mi takovej sympatickej tím, že je v krabičce (+je i levnější)
// Potom by mě ještě zajímalo, jakej je rozdíl mezi těmahle:
(nejdražší vs nejlevnější)
http://www.tme.eu/cz/katalog/programova ... C114871%3B
Napsal: 13 kvě 2015, 22:09
od mtajovsky
Víc breakpointů jsem potřeboval, když se provádělo nechtěné přerušení a já
jsem potřeboval jednoduše zjistit, co se děje. Na adresy vektorů neobsloužených přerušení jsem nasázel breakpointy a bylo to.
Do Dragona bych už dnes taky nešel, jeho jediná výhoda je, že umí i paralelní a HV serial naprogramování MCU. Zato je mimořádně choulostivý a neopravitelný vzhledem k nedostupnosti schématu a také pro velmi jemnou povrchovou montáž. Někde jsem dokonce četl, že odcházel kvůli dlouhým kabelům k MCU. Na netu je několik návodů na ochranný interface. Inu, bylo to ve své době low price řešení, kde se šetřilo, jak se dalo a Dragon nemá žádné ochrany.
Ten Atmel ICE si můžete koupit v nejlevnější verzi jen jako PCB a do krabičky dát sám.
Oba dva debuggery (Dragon i Atmel ICE) umí i debugWire a Atmel ICE i několik dalších rozhraní. Co se týče sortimentu 8 bit AVR MCU, tak jsou téměř rovnocenné.
Z toho srovnávacího výběru, který jste uvedl, tak to nejlevnější je jen programátor, neumožní on-chip debugging.
Napsal: 13 kvě 2015, 22:17
od pirat077
Díky moc za odpoveď!
mtajovsky píše:Z toho srovnávacího výběru, který jste uvedl, tak to nejlevnější je jen programátor, neumožní on-chip debugging.
=> U tohoto odkazu jsem myslel porovnání těch čtyř Atmel ICE (vždycky jsou zřejmě dva bez krabiček a dva v krabičce)
Jeden typ je dvojnásobně dražsí než ten druhý....zajímalo, kde se skrývají nedostatky toho levnějšího..?
ISP programátor USBAsp zdárně používám.
Napsal: 13 kvě 2015, 22:24
od mtajovsky
Srovnáváte trošku hrušky a jablka.
Ten první AT91SAM-ICE je pro jiný sortiment MCU. 2. až 4. položka je pořád Atmel ICE, tudíž "střeva" a sortiment MCU se neliší. Liší se tím, jestli je to v krabičce a jaké je k tomu příslušenství kabelů a adaptérů. Na stránkách Farnell nebo přímo Atmel máte lepší popis.
Napsal: 24 zář 2015, 21:49
od pirat077
Po dlouhé době jsem se dostal k jtag debuggingu Atmegy 32 s Jtag Ice
Poradíte mi prosím nějaké zásady a tipy, jak pracovat s breakpointy a taknějak s Atmel studiem obecně??
Představoval jsem si, že při vypisování písmenek na displej hodím breakpoint na příkaz, který vypisuje text na první řádek displeje.... a potom si postupně krokováním zobrazím každej řádek...
Jenže tohle se neděje...
Nevím, jestli je problém I2C při debug módu??
Ani LEDka mi nebliká v průběhu debuggingu
jsem na rychlosti 3,3MHz...
Kdyby existoval nějakej tutoriál, rád se podívám (návody od Atmelu mi přijdou nicneříkající a asi moc odborné)
Napsal: 26 zář 2015, 11:48
od frpr666
Já to chápu tak, že když dáš breakpoint tak se stopne chod programu.
Proto ledka přestane blikat a přestane se vysílat do LCD.
Pokud chceš debugovat "on-fly" tak si napiš funkci která posílá např. 16byte jako text na UART, tu volej na vhodných místech programu a pozoruj na PC výpisy...
Start->AvrStudio4.18->Help->AVR Tools User Guide->Simulator->Overview
Start->AvrStudio4.18->Help->AVR Tools User Guide->AVR Dragon User Guide->On-Chip Debugging
Start->AvrStudio4.18->Help->AVR Studio User Guide->Debug
Napsal: 26 zář 2015, 14:57
od pirat077
frpr666 píše:Já to chápu tak, že když dáš breakpoint tak se stopne chod programu.
Proto ledka přestane blikat a přestane se vysílat do LCD.
Pokud chceš debugovat "on-fly" tak si napiš funkci která posílá např. 16byte jako text na UART, tu volej na vhodných místech programu a pozoruj na PC výpisy...
Start->AvrStudio4.18->Help->AVR Tools User Guide->Simulator->Overview
Start->AvrStudio4.18->Help->AVR Tools User Guide->AVR Dragon User Guide->On-Chip Debugging
Start->AvrStudio4.18->Help->AVR Studio User Guide->Debug
Dík, podívám se
Mám ten problém, že když použiju program jen pro blikání LEDky, tak LEDka nebliká!! (bez breakpointu nic, s breakama taky bez odezvy) !!
(pro mě nezvyké je i to, že mi Atmel studio hlásí nějakou chybu, když hodím break na řádek s _wait_ms() )
To posílání na UARTu by mělo fungovat stejně jako posílání znaků na I2C...
Napsal: 26 zář 2015, 17:07
od frpr666
tak tam zkus nahrat tohle:
Kód: Vybrat vše
// blikani led na portu PB0
// atmega32
// odzkouseno: n*/y
#define F_CPU (1000000UL)
#include <avr/io.h>
#include <util/delay.h>
void setup (void);
void loop (void);
uint8_t value;
int main (void)
{
setup();
for(;;)
{
loop();
}
return(0);
}
void setup (void)
{
PORTB = 0;
DDRB = _BV(0);
}
void loop (void)
{
if(value != 0)
{
value = 0;
PORTB |= _BV(0);
}
else
{
value = 1;
PORTB &= ~_BV(0);
}
_delay_ms(100);
}
//EOF
Napsal: 29 zář 2015, 23:28
od mtajovsky
pirat077 píše:pro mě nezvyké je i to, že mi Atmel studio hlásí nějakou chybu, když hodím break na řádek s _wait_ms()..
S debugováním za přítomnosti rutin pro časová zpoždění je spojena jedna nepříjemnost - tyto rutiny pracují většinou správně jen při zapnuté optimalizaci kódu. Jinak překladač hlásí varování, že skutečné zpoždění nebude odpovídat. Na druhou stranu, když se zapne optimalizace kódu, tak je velká pravděpodobnost, že řádek s breakpointem je optimalizován a de facto nemá ve výsledném strojáku svůj obraz. Pak se procesor na tomto řádku nezastaví, i když ve zdrojovém textu vidíte nastavený BP.
Buďto se dočasně pro ladění smíříte s chybou časových rutin nebo můžete kód reorganizovat do více modulů a potřebná časová zpoždění soustředit do samostatného modulu. Pro celý projekt pak vypnete optimalizace s výjimkou tohoto modulu.