debugWIRE van Atmel, zelfbouw?

[SA007]

Ik ben al een tijdje aan het zoeken, maar het valt me op dat er echt heel weinig te vinden is over debugWIRE.

Ja ok, Atmel heeft de specs niet vrijgegeven, maar komop, zo moeilijk kan het toch niet zijn, het is maar een 8-bit platform en hoe een AVR verder werkt is wel helemaal bekend.

Was zelf eigenlijk aan het zoeken naar een mooie kleine debugger/programmer welke ik gewoon altijd mee kan nemen. Nu heb je eigenlijk maar 2 devices die debugWIRE hebben, de AVR ICE mkII en de AVR dragon.
de dragon is wel goedkoop (~50 euro kan je ze al vinden) maar is wel erg groot en als losse print niet echt practisch als mobile-debugging op locatie ofzo.
De ICE is wel wat kleiner en heeft een behuizingkje, maar is weer erg duur en dat dunne ffc kabeltje lijkt me niet al te robuust om er continue mee rond te slepen.

Nu kan je wel een hoop via ISP, waar meer dan genoeg meuk voor is, maar debugwire met 2 draadjes is toch wat makkelijker dan isp met 5 en je hoeft er in je ontwerp eigenlijk geen rekening mee te houden.

Heeft er dan echt nog niemand moeite gedaan om debugWIRE te gaan reverse-engineeren? Lijkt me stug eigenlijk. Of zou het dan toch zo'n moeilijk systeem zijn om uit te vinden?

[madwizard]

Even los van je eigenlijke vraag, debugWire kan gebruikt worden om te programmeren maar dat is niet het primaire doel. Zo zul je eerst debugWire moeten enablen, wat uiteraard niet via debugWire kan en dus via ISP (misschien ook via JTAG) moet. Eenmaal aan kun je debuggen en de chip herprogrammeren, maar fuses kun je dacht ik niet aanpassen (al hoeft dat meestal maar 1 keer). DebugWire uit kan wel via debugWire (moet ook, want ISP werkt niet meer omdat de reset pin een andere functie heeft gekregen). Permanent debugwire aan laten staan werde geloof ik ook afgeraden, iets met sleep modes en timers die niet helemaal werken zoals normaal (zal vooral met sleep mode te maken hebben, je avr blijft dan in een soort debug mode).

[wacco]

Tsja. Ik ken het niet. Hoeveel werk is het om een tweede microcontroller mee te laten luisteren op die bus en de boel te samplen? Lijkt me niet al te veel werk aangezien het 'maar' een serieel protocol is. Wat basis command sequences moet je er wel uit kunnen halen op die manier.

Nu is dit natuurlijk waarschijnlijk een royale understatement van het eigenlijke werk wat je te wachten staat maar het is iig wel hoe ik het zou aanpakken om te beginnen.

[SA007]

Dat heb ik dus ook, maar als het echt gewoon een simpel serieel protocol is waarom is het dan nog niet gehacked.

@madwizard, de sleepfuncties hebben in debugwire mode wel problemen inderdaad, maar verder is er imho weinig anders, de chip draait normaal tenzij je ermee zit te kloten via debugwire.

[Radiant]

De kabeltjes van de ICE gaan (bij intensief gebruik) langer mee dan je zal verwachten hoor. En ze zijn los verkrijgbaar. Een ICE is inderdaad wel duur, maar voor een beetje bedrijf is 250 euro per developer niet zoveel, als je al bedenkt dat de serieuze compilers meer dan 1000 euro kosten per licentie.
Voor de hobbyisten (die meestal ook niet in het veld hoeven te debuggen) is er de Dragon.

Het zelf uitvinden moet inderdaad te doen zijn, maar voor veel mensen/bedrijven waarschijnlijk niet interessant ivm. de grote hoeveelheid werk. Echt een markt voor andere debuggers is er volgens mij ook niet, ik ken bijvoorbeeld maar 1 JTAGICE mkII kloon (die overigens lang niet zo goed werkt als een originele af en toe).

[SA007]

De mkII heeft imho geen kloon? afaik zijn er alleen klonen van de niet-mkII versie.

[Radiant]

AVRVI mkII