Hallo Leute, ich brauche mal Hilfe bei der Auswahl eines passenden JTAG Atapters, bzw. ISP. Mein Haupt-Ziel wird es sein, mal ein laufendes Programm auf einem AVR anzuhalten und zu debuggen. Allerdings halten sich meine Erfahrungen mit JTAG in Grenzen. Ich habe mal einen WRT54GL beim Aufspielen von DD-WRT geschrottet. Anschließend konnte ich ihn mit einem selbstgebauten JTAG Kabel aus einem Sub-D Stecker und ein paar Widerständen wiederbeleben. Der JTAG Anschluss war damals 12-Polig Dann gibt es irgendwie 10 Pin JTAG Ports oder auch 6 Port Ports. Was ich momentan nicht verstehe ist, was ich denn so brauche, damit es so eine Art Universal-Tool wird. Es gibt z.B. den Bus Blaster für rund 30 EUR, oder den AVR JTAG ICE MKII für 350 EUR. Alternativ gibt es in der Bucht auch z.B. die Riff Box, mit der Bootloader-Probleme bei verschiedenen Mobiltelefonen wiederherstellen kann. Als Anfänger bin ich da momentan irgendwie voll überfragt, was ich mir denn für ein Device kaufen sollte. Könnt ihr mir da etwas helfen?
JTAG ist nur die Schnittstelle. Die Funktion ist ein anderes Paar Schuhe. Ganz grob gibt es - Programmierer (günstig, nur Flash-Programmieren und -Lesen) - Debugger (etwas teurer, zum Debuggen wie der Name schon sagt) - Emulatoren (teuer, sehr leistungsfähig zur Entwicklung) Der AVRISP ist ein reiner Programmer, damit kann man nicht debuggen. Der AVRDragon ist ein meines Wissens schon ein echter Debugger. Der AVRICE ist ein "In Circuit Emulator" und entsprechend leistungsfähig und teuer.
Bronco schrieb: > Der AVRICE ist ein "In Circuit Emulator" und entsprechend leistungsfähig > und teuer. Nein, es ist klassenmäßig ähnlich dem AVR Dragon angesiedelt (oder einem nicht ganz so teuren JTAGICE3). „Echte“ Emulatoren waren früher üblich und wirklich sehr teuer. Basis dabei war ein FPGA, das den digitalen Code des Prozessors enthielt, ergänzt um (diskret hinzugefügte) wesentliche Peripherie des Controllers. Auf diese Weise erhielt man einen einigermaßen originalgetreuen Nachbau des Controllers, bei dem man aber interne Busse „anzapfen“ konnte (aus dem FPGA rausführen). All die JTAG-Debugger sind keine wirklichen Emulatoren mehr, das sie ja direkt auf der Ziel-CPU aufsetzen (statt sie zu emulieren). Man hat also in der echten Hardware Eingriffspunkte geschaffen, und greift über die (bereits aus anderen Gründen vorhandene) JTAG-Schnittstelle darauf zu. Das ist deutlich preiswerter als ein Voll-Emulator.
Hmmm... Mir ist momentan nicht klar, ob es sich wirklich lohnt, den AVR ICE MKII zu holen oder das Dragon Board. Und was ist jetzt der Unterschied dieser Tools zu den ganzen angebotenen JTAG Boxen, wie z.B. hier auf der Seite: http://www.fonefunshop.co.uk/Unlocking/sagemjigs.htm Jetzt einfach mal laut gedacht. Heute möchte ich mit dem Teil ISP und Debugging eines AVRs machen. Wenn ich es richtig verstehe, reicht mir da ein Dragon Board aus. Und mal so gefragt: Als damals mein WRT54GL Router sich verabschiedet hat, hatte mein Rechner noch einen LPT Port. Kann ich mit dem Dragon Board oder mit dem ICE KMII genauso die Firmware wiederherstellen, wie mit dem zusammengelöteten Kabel?
@ Mathias Ahrens (Gast) >Jetzt einfach mal laut gedacht. Heute möchte ich mit dem Teil ISP und >Debugging eines AVRs machen. Wenn ich es richtig verstehe, reicht mir da >ein Dragon Board aus. Ja. >Und mal so gefragt: Als damals mein WRT54GL Router sich verabschiedet >hat, hatte mein Rechner noch einen LPT Port. Kann ich mit dem Dragon >Board oder mit dem ICE KMII genauso die Firmware wiederherstellen, wie >mit dem zusammengelöteten Kabel? Ja.
Kann der Ice III auch ISP? So wie ich das verstanden habe nein. Grüsse, René
Mathias Ahrens schrieb: > Und was ist jetzt der Unterschied dieser Tools zu den ganzen angebotenen > JTAG Boxen Dass bei JTAG nur die Hardwareschnittstelle selbst sowie die Funktionalität für den ursprünglichen Verwendungszweck (Verdrahtungstests komplexer Platinen; JTAG = “Joint Test Access Group”) genormt ist. Die Erweiterungen der Schnittstelle zum Debuggen sind aufgesetzt und nicht standardisiert. Vielfach werden sie komplett herstellerspezifisch und proprietär realisiert; lediglich bei ARM ist die ganze Sache durch ARM selbst wieder genormt, weshalb dort 3rd-party-Lösungen preiswert zu haben sind (aber teilweise mit Abstrichen in der Funktionalität gegenüber den „aufgebohrten“ Debuggern der Hersteller). Kurz und gut: einen AVR kannst du nur mit einem der Atmel-Tools debuggen, die JTAG (bzw. PDI bei Xmega oder debugWIRE bei den kleinen AVRs) anbieten. Mit diesen wiederum kannst du aber weder einen ARM noch dein Smartphone debuggen. Rene H. schrieb: > Kann der Ice III auch ISP? So wie ich das verstanden habe nein. Dann hast du das falsch verstanden. Seitdem es debugWIRE gibt, welches für das Handling unbedingt auch ISP zusätzlich benötigt, hatte man bereits im JTAGICEmkII ISP implementiert, und genauso ist das auch im JTAGICE3.
Den JTAGICE III gibts für Studenten übrigens für 70€ inkl. Versand. http://student.embedded-projects.net/index.php?module=artikel&action=artikel&id=753
Jörg Wunsch schrieb: > Dann hast du das falsch verstanden. Seitdem es debugWIRE gibt, welches > für das Handling unbedingt auch ISP zusätzlich benötigt, hatte man > bereits im JTAGICEmkII ISP implementiert, und genauso ist das auch im > JTAGICE3. Danke! Das heisst das wenn ich den JTAG ICE III habe, der AT AVR ISP2 redundant ist? Korrekt? Grüsse, René
Rene H. schrieb: > Das heisst das wenn ich den JTAG ICE III habe, der AT AVR ISP2 redundant > ist? Nun ja, sagen wir mal, die Zielrichtung des AVRISPmkII liegt etwas anders: das soll ein robuster Massenprogrammierer sein, der schnell und zuverlässig ist. Daher ist er recht robust gegen Fehlbedienungen gebaut worden. Sofern man einen Controller mit genügend hohem CPU-Takt programmiert, ist er auch deutlich schneller als ein JTAGICE{mkII,3} (bei den standardmäßigen 1 MHz spielt das aber keine Rolle). Aber wenn es nur um die Möglichkeit, ISP zu machen, überhaupt geht, ja, dann decken sowohl JTAGICEmkII als auch JTAGICE3 (oder der AVR Dragon) dies mit ab.
> Aber wenn es nur um die Möglichkeit, ISP zu machen, überhaupt geht, ja, > dann decken sowohl JTAGICEmkII als auch JTAGICE3 (oder der AVR Dragon) > dies mit ab. Der MKII kennt keinen Atmega8. mfg. PS: Das ist aber schade. Heul.
Jörg Wunsch schrieb: > Die Erweiterungen der Schnittstelle zum Debuggen sind aufgesetzt und > nicht standardisiert. Vielfach werden sie komplett herstellerspezifisch > und proprietär realisiert; lediglich bei ARM ist die ganze Sache durch > ARM selbst wieder genormt, weshalb dort 3rd-party-Lösungen preiswert > zu haben sind (aber teilweise mit Abstrichen in der Funktionalität > gegenüber den „aufgebohrten“ Debuggern der Hersteller). Tut mir Leid, aber ich verstehe das nicht. Beim JTAG habe ich ja eigentlich nur vier Leitungen. TMS für den Mode Select TCK für den Tackt TDI für den Input TDO für den Output Und über diese vier Leitungen spreche ich dann mit dem Chip. Ich verstehe desahlb nicht, was die Debugger voneinander unterscheidet. IMHO ist das einzig-wichtige das setzen der richtigen Pegel. Alles andere ist eine Software-Geschichte.
@Mathias Ahrens (Gast) >> zu haben sind (aber teilweise mit Abstrichen in der Funktionalität >> gegenüber den „aufgebohrten“ Debuggern der Hersteller). >Tut mir Leid, aber ich verstehe das nicht. >Beim JTAG habe ich ja eigentlich nur vier Leitungen. >TMS für den Mode Select >TCK für den Tackt >TDI für den Input >TDO für den Output >Und über diese vier Leitungen spreche ich dann mit dem Chip. Ja. Das ist die Hardware und unterste Logikebene. Die ist überall gleich. > Ich >verstehe desahlb nicht, was die Debugger voneinander unterscheidet. Die Software, die in den höheren Ebenen sitzt. Ausserdem haben die einzelnen JTAG-Boxen meist alle eigenständige, unterschiedliche, nicht kompatible, nicht standardisierte Treiber. Damit ist eine universelle Nutzung weiter verhindert. > IMHO >ist das einzig-wichtige das setzen der richtigen Pegel. Alles andere ist >eine Software-Geschichte. Na dann mach mal das bisschen Software ;-) Klar, EIGENTLICH könnte das alles schon standardisiert sein, ist es aber nicht.
Thomas Eckmann schrieb: > Der MKII kennt keinen Atmega8. Quatsch mit Soße. Dem Adapter ist das shitegal, welchen Controller er programmiert. Die gesamte Parametrierung erfolgt zur Laufzeit. Was ein ATmega8 natürlich nicht hat, ist debugWIRE (und JTAG erst recht nicht), folglich kannst du ihn damit nur programmieren, nicht debuggen. Mathias Ahrens schrieb: > Alles andere ist eine Software-Geschichte. Ja, es gab/gibt in der Tat Versuche, die durch Atmel nicht dokumentierte Debugfunktionalität in 3rd-party-Tools nachzubauen. Opensource sind mir dabei nur in den Kinderschuhen steckende Aktivitäten von USBprog (bei shop.embedded-projects.net) bekannt. Inwiefern die chinesischen Cloner des JTAGICEmkII tatsächlich eigene Firmware gezimmert haben, oder ob es ihnen gelungen ist, Atmels Verschlüsselung ihrer Firmware aufzubrechen, habe ich keine Ahnung. Wenn du jetzt und heute etwas Funktionierendes haben willst und nicht nur "aus Prinzip" an besagter Opensource-Lösung auf Basis USBprog weiterbasteln möchtest, dann nimm einen AVR Dragon oder vielleicht ein JTAGICE3. Oder ein JTAGICEmkII halt, aber die Dinger sind vergleichsweise teuer.
Jörg Wunsch schrieb: > Wenn du jetzt und heute etwas Funktionierendes haben willst und nicht > nur "aus Prinzip" an besagter Opensource-Lösung auf Basis USBprog > weiterbasteln möchtest, dann nimm einen AVR Dragon oder vielleicht > ein JTAGICE3. Oder ein JTAGICEmkII halt, aber die Dinger sind > vergleichsweise teuer. Ich möchte tatsächlich etwas funktionierendes haben. Ich habe momentan nur ein Problem, was ich immer noch nicht verstehe. Wenn ich jetzt ein Dragon Board oder JTAGICE3 / 2 MKII hole, dann bekomme ich da sicherlich eine Software, mit der ich per Clicki Bunti den AVR programmieren kann. Ebenso werde ich ja dann wohl ein entsprechendes Interface haben, um den laufenden Code auf dem AVR zu debuggen. Aber wie sieht es z.B. aus, wenn ich sagen wir mal z.B. mit dem JTAG Finder http://www.jtagfinder.com mir bei einem Gerät einen JTAG Anschluss suche, kann ich dann mit den Tools mal auf die undokumentierten Debug-Funktionen zugreifen? Und dann verstehe ich leider immer noch nicht, was den (Preis-) unterschied des Dragon Boards, des JTAGICE3 und des JTAGICE2 MKII ausmachen.
Hi >Was ein ATmega8 natürlich nicht hat, ist debugWIRE (und JTAG erst >recht nicht), folglich kannst du ihn damit nur programmieren, nicht >debuggen. Nur taucht der ATMega8 auch nicht im ISP-Programmer-Dialog des AVR ICE MKII auf. Wird allerdings auch nur Leute abschrecken, die von den AVRs aus >10 Jahre alten Tutorials nicht loskommen. MfG Spess
Angehängte Dateien:
-
Ei_wo_isser_denn.JPG
37 KB
Jörg Wunsch schrieb: > Thomas Eckmann schrieb: >> Der MKII kennt keinen Atmega8. > > Quatsch mit Soße. Daß das jetzt kommt, war klar. > Dem Adapter ist das shitegal, welchen Controller er programmiert. Die > gesamte Parametrierung erfolgt zur Laufzeit. Meinem ist das nicht egal. > Was ein ATmega8 natürlich nicht hat, ist debugWIRE (und JTAG erst > recht nicht), folglich kannst du ihn damit nur programmieren, nicht > debuggen. Na das ist ja ganz was Neues. mfg.
Danke Jörg, Du hast in meiner Entscheidungsfindung sehr geholfen und ich kann man meine alte Parallelport Lösung wechseln. Grüsse, Rene
Mathias Ahrens schrieb: > Wenn ich jetzt ein Dragon Board oder JTAGICE3 / 2 MKII hole, dann > bekomme ich da sicherlich eine Software, mit der ich per Clicki Bunti > den AVR programmieren kann. Ebenso werde ich ja dann wohl ein > entsprechendes Interface haben, um den laufenden Code auf dem AVR zu > debuggen. Ja, die Software ist der Koloss, der sich da Atmel Studio nennt. > Aber wie sieht es z.B. aus, wenn ich sagen wir mal z.B. mit dem JTAG > Finder http://www.jtagfinder.com mir bei einem Gerät einen JTAG > Anschluss suche, kann ich dann mit den Tools mal auf die > undokumentierten Debug-Funktionen zugreifen? Das hängt von deiner Software ab. ;-) > Und dann verstehe ich leider immer noch nicht, was den (Preis-) > unterschied des Dragon Boards, des JTAGICE3 und des JTAGICE2 MKII > ausmachen. Das JTAGICEmkII ist der Großvater dieser Geräte. Wurde ziemlich teuer verkauft (offiziell wohl USD 300, was sich aber mit Umsatzsteuer und Eurolandzuschlag hierzulande in EUR 300 übersetzt hat). Da das für den chinesischen Markt dann irgendwie doch zu teuer war, hat man den Dragon als Abrüstvariante entwickelt. Ist im Großen und Ganzen etwas einfacher gehalten, keine Kabel dabei, einfacher gestrickte Schutzbeschaltungen. Dafür konnte man ihn für < USD 100 dann anbieten (und hat nebenbei noch die HV-Programmierung aus dem STK500 mit reingestopft). Beim JTAGICE3 hat man nun recht konsequent aber an anderen Stellen abgespeckt. Möglich wurde das durch das völlig neu konzipierte Atmel Studio 5 bzw. 6, bei dem man nicht mehr wie zuvor wesentliche Teile des Debuggers in die Firmware des JTAGICE ausgelagert hat, denn das zugrunde liegende Visual Studio besitzt bereits einen ordentlichen Debugger. Dadurch ist das JTAGICE3 bei mit dem JTAGICEmkII vergleichbarem Funktionsumfang beinahe so preiswert geworden wir einstmals der Dragon. Als Folge des neuen Konzepts läuft es aber natürlich nicht mehr zusammen mit dem alten AVR Studio 4, sondern nur noch mit dem neuen Atmel Studio 6. Spess53 schrieb: > Nur taucht der ATMega8 auch nicht im ISP-Programmer-Dialog des AVR ICE > MKII auf. Kann ja sein, das heißt aber nur, dass die aktuelle Atmel-Software dafür keine Beschreibungsdatei mitliefert. Warum auch immer. Die kann man sich entweder selbst stricken (ist ein simples Schnipsel XML), oder man nimmt halt was anderes, AVRDUDE zum Bleistift. Dem ist das egal, welche XML-Dateien Atmel Studio gerade mal mitliefert, das kennt sowohl den ATmega8 als auch ein JTAGICEmkII und kann folglich auch beide miteinander verheiraten. Für Thomas:
1 | $ avrdude -c jtag2isp -P usb -B 5 -p atmega8 -v |
2 | |
3 | avrdude: Version 6.0rc1, compiled on Jul 11 2013 at 23:35:06 |
4 | Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ |
5 | Copyright (c) 2007-2009 Joerg Wunsch |
6 | |
7 | System wide configuration file is "/usr/local/etc/avrdude.conf" |
8 | User configuration file is "/home/joerg/.avrduderc" |
9 | |
10 | Using Port : usb |
11 | Using Programmer : jtag2isp |
12 | Setting bit clk period : 5.0 |
13 | avrdude: usbdev_open(): Found JTAGICE mkII, serno: 00B0000011AE |
14 | JTAG ICE mkII sign-on message: |
15 | Communications protocol version: 1 |
16 | M_MCU: |
17 | boot-loader FW version: 255 |
18 | firmware version: 7.13 |
19 | hardware version: 0 |
20 | S_MCU: |
21 | boot-loader FW version: 255 |
22 | firmware version: 7.13 |
23 | hardware version: 1 |
24 | Serial number: 00:b0:00:00:11:ae |
25 | Device ID: JTAGICEmkII |
26 | AVR Part : ATmega8 |
27 | Chip Erase delay : 10000 us |
28 | PAGEL : PD7 |
29 | BS2 : PC2 |
30 | RESET disposition : dedicated |
31 | RETRY pulse : SCK |
32 | serial program mode : yes |
33 | parallel program mode : yes |
34 | Timeout : 200 |
35 | StabDelay : 100 |
36 | CmdexeDelay : 25 |
37 | SyncLoops : 32 |
38 | ByteDelay : 0 |
39 | PollIndex : 3 |
40 | PollValue : 0x53 |
41 | Memory Detail : |
42 | |
43 | Block Poll Page Polled |
44 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
45 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
46 | eeprom 4 20 128 0 no 512 4 0 9000 9000 0xff 0xff |
47 | flash 33 10 64 0 yes 8192 64 128 4500 4500 0xff 0x00 |
48 | lfuse 0 0 0 0 no 1 0 0 2000 2000 0x00 0x00 |
49 | hfuse 0 0 0 0 no 1 0 0 2000 2000 0x00 0x00 |
50 | lock 0 0 0 0 no 1 0 0 2000 2000 0x00 0x00 |
51 | calibration 0 0 0 0 no 4 0 0 0 0 0x00 0x00 |
52 | signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 |
53 | |
54 | Programmer Type : JTAGMKII_ISP |
55 | Description : Atmel JTAG ICE mkII in ISP mode |
56 | Vtarget : 5.1 V |
57 | SCK period : 8.00 us |
58 | |
59 | avrdude: AVR device initialized and ready to accept instructions |
60 | |
61 | Reading | ################################################## | 100% 0.16s |
62 | |
63 | avrdude: Device signature = 0x1e9307 |
64 | avrdude: safemode: lfuse reads as E1 |
65 | avrdude: safemode: hfuse reads as D9 |
66 | |
67 | avrdude: safemode: lfuse reads as E1 |
68 | avrdude: safemode: hfuse reads as D9 |
69 | avrdude: safemode: Fuses OK |
70 | |
71 | avrdude done. Thank you. |
Auch wenn ich hier nicht zu den Pros gehöre, aber im Simulator vom AVR Studio kann ich das Programm auch ablaufen lassen und in gewisser Weise auch so debuggen. Es gibt da jede Menge Videos auf YT dazu. Diese Videos von Atmel sind wirklich gut gemacht und man kann ne Menge dadurch auf einfache und schnelle Weise lernen. Das ist dann zumindest der billigste Debugger. Ich bin ja ein Drachen Fan.
Jörg Wunsch schrieb: > avrdude: Version 6.0rc1, compiled on Jul 11 2013 at 23:35:06 > Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ > Copyright (c) 2007-2009 Joerg Wunsch Ok, es geht. Aber mit sowas: > $ avrdude -c jtag2isp -P usb -B 5 -p atmega8 -v quäle ich mich nicht mehr ab. Ich weiss, das ist ganz einfach. Und vi ist auch der beste Editor der Welt. Ich hab aber keine Lust auf so ein Gefriggel. Allerdings ist es schon merkwürdig, daß Atmel den 8er einfach rausgeschmissen hat. In gewisser Weise natürlich konsequent, da er kein dW hat. Aber irgendwie auch kleinkariert. mfg.
F. Fo schrieb: > Auch wenn ich hier nicht zu den Pros gehöre, aber im Simulator vom AVR > Studio kann ich das Programm auch ablaufen lassen und in gewisser Weise > auch so debuggen. Naja, bei realen Programmen scheitert das früher oder später, wenn man Echtzeiteingaben aus der „richtigen Welt“ bräuchte. Kann man im Prinzip (zumindest teilweise) mit Stimuli noch nachhelfen, aber irgendwann stoßen auch die an ihre Grenzen. Wirklich sinnvoll simulieren lassen sich eigentlich nur Algorithmen. Thomas Eckmann schrieb: > Aber mit sowas: >> $ avrdude -c jtag2isp -P usb -B 5 -p atmega8 -v > quäle ich mich nicht mehr ab. Deine Sache. Ich quäle mich nicht mit so einem Koloss wie Atmel Studio ab, das Ding ist mir zu zäh und unflexibel. ;-) (Das bisschen AVRDUDE-Aufruf kann man ja auch problemlos in ein Makefile einbauen oder anderweitig in eine IDE integrieren.) > Allerdings ist es schon merkwürdig, daß Atmel den 8er einfach > rausgeschmissen hat. Ja, zumal sie ihn als ATmega8A noch neu aufgelegt haben. Aber du bist $KUNDE, es wäre also an dir, dich beim Support darüber zu beklagen. Ich benutze kein Atmel Studio, insofern habe ich keine Veranlassung, da einen Supportcall aufzumachen. Der AVRDUDE-Support zeigt zumindest, dass es kein grundsätzliches technisches Problem dabei gibt.
Vor einiger Zeit hatte ich mal hier an dieser Stelle eine echte Alternative zum Programmieren/Debuggen vom z.B. ATMega128 aufgezeigt: Beitrag "AVR-Developmentboard & Planarspulenbaukasten" Leider fand das nicht die erhoffte Resonanz, so dass zunächst die weiteren Arbeiten daran unterbrochen wurden. Es erfreut mich deshalb, da dass es offensichtlich dennoch Leute gibt, die sich mit solchen Dingen wie JTAG (bei AVR) befassen... Da die Dinge doch etwas komplizierter liegen, als oben ausgeführt, hatte ich mich schon sehr eingehend damit auseinandergesetzt. Nach wie vor bin ich der Auffassung, dass insbesondere JTAG ein willkommenes Werkzeug bei der Programm-Entwicklung anspruchsvoller µC-Anwendungen ist. Grüsse aus Berlin PSblnkd
PSblnkd schrieb: > vom z.B. ATMega128 Naja, für den ATmega128 würde es ja noch ein Uralt-Clone eines JTAGICE (mkI) tun. Allerdings ist der ATmega128 mittlerweile ein ziemliches Urgestein, auf dem ich eher keine Neuentwicklung mehr ansetzen würde.
Jörg Wunsch schrieb: > PSblnkd schrieb: >> vom z.B. ATMega128 > > Naja, für den ATmega128 würde es ja noch ein Uralt-Clone eines > JTAGICE (mkI) tun. Allerdings ist der ATmega128 mittlerweile ein > ziemliches Urgestein, auf dem ich eher keine Neuentwicklung mehr > ansetzen würde. Aber selbst der wurde noch von Atmel ge A delt. mfg.
Thomas Eckmann schrieb: > Aber selbst der wurde noch von Atmel ge A delt. Ja, aber ich würde auch keine Neuentwicklung mehr mit einem ATmega8[A] starten … Was sie nun als A neu aufgelegt haben und was nicht, dürfte doch in erster Linie widerspiegeln, welche Controller nach wie vor in großen Stückzahlen gekauft werden.
Jörg Wunsch schrieb: > Thomas Eckmann schrieb: >> Aber selbst der wurde noch von Atmel ge A delt. > > Ja, aber ich würde auch keine Neuentwicklung mehr mit einem ATmega8[A] > starten … Natürlich nicht. Wenn mich da einer zu zwingen würde, würde ich bei einem Atmega88 eine 8 wegkratzen oder durchstreichen. mfg.
Ok Leute, Danke für eure Hilfe! Ich habe mich jetzt für den JTAG ICE 3 entschieden. Mit Glück ist das Ding morgen bereits da. Ich bin schon gespannt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.