Hallo, Kann mir jemand ein USB nach JTAG Adapter empfehlen, mit dem ich sowohl die AVRs (mittels AVRStudio+WinAVR) SOWIE!! die programmierenbaren Logik-IC's (cpld,fpga zB Lattice mit ispLEVER) programmieren kann?? Danke schonmal
Hi! Ich klinke mich da ein, habe aber kaum Hoffnung, dass es Antworten geben wird. Habe diese Frage ebenfalls schon mehr fach in unterschiedlichen Foren gestellt und keine zufriedenstellende Antwort erhalten. Das Problem ist wohl, dass es zwar ein mehr oder weniger ( eher weniger) einheitliches JTAG Protokoll gibt, dass aus einem entsprechenden Adapter herauskommt, aber kein definiertes Protokoll, dass diese Adapter gegenüber dem PC bzw der CPLD/FPGA-Software sprechen. Man kann mit Sicherheit einen AVR JTAGICE mkII nehmen und damit einen Lattice, Altera, Xilinx beschreiben, aber die entsprechenden IDEs kennen diesen JTAG Adapter nicht. Es liegt also nicht an der Hardware, sondern es fehlt die Schnittstelle zur IDE. Ich habe bislang aber auch noch keine SDKs für diese IDEs gefunden, die es ermöglichen einen entsprechenden Treiber zu programmieren. Ich habe aber auch noch nicht danach gesucht. Vorstellbar ist es, dass diese SDKs den professionellen Pakten dieser IDEs beiliegen, aber diese sind für den Hobbybereich unbezahlbar. Gruß, Ulrich
Hallo, möglicherweise können wir uns gegenseitig helfen. Ich bin dabei ein USB->JTAG device zu entwickeln. Das JTAG Protokoll ist im Kern genormt, jedoch gibt es da immer mal wieder Erweiterungen. Zu diesen Erweiterungen findet man aber nur sehr schwer Informationen. Wenn du also genauere Informationen zu den Protokollen findest, kann ich diese evt. mit in meine Software einbauen. Und du erhälst so genau das was du suchst. Momentan liegt mein Schwerpunkt jedoch auf AVR Studio und ATmegaxxx Auf Robotternetz.de habe ich einen eigenen Thread dazu. Ich heisse dort "789321" http://www.roboternetz.de/phpBB2/viewtopic.php?t=28842
Hi! Danke für die Einladung ins Roboter-Board. Im Grunde finde ich die Lösung nicht schlecht. Den FTDI im Bitbang zu betreiben verlagert natürlich die Treiber-Entwicklung komplett auf eine Seite des Systems, den PC. Das ist sicherlich von Vorteil. Ich bin mir noch nicht sicher, aber Du planst, dass man den Treiber und sein Frontend startet und diese dann einen AVR-JTAGICE (mkII) emulieren. D.h. im AVR-Studio wird dieses als Zielgerät für den Zugriff angewählt und genutzt als wäre es wirklich vorhanden. Die Kommunikation wird von deiner PC-Frontend Software umgeleitet und durch deinen Treiber in Bitbang-Muster umgesetzt, paktiert und an den FT232 gesendet. Das ist soweit ok. Ich bin mir aber noch nicht ganz sicher, ob das wirklich Zielführend ist und die nötige Effizienz mitbringt. Ich habe aktuell schon ein paar JTAG-Ziele, die ich mit diesem Programmer ansteuern möchte: - ATmega mit vollen Debug - Atmel ARM Serie mit Flash und vollem Debug - Xilinx CPLD XC-Serie, CoolRunner Serie - Broadcom Chipsatz (ARM) (Linksys Router) nur FLASH Support - Siemens SL4 (ARM) nur FLASH-Support - TI DSP TMS320 Serie nur FLASH, optional Debug - Zilog eZ80Acclaim, Flash, Debug Für Broadcom und SL4 gibt es bereits Parallelport Bitbanger in open source. Da es hierfür keine IDEs gibt, ist eine eigene Software, die dann auf das ATMEL mkII Protokoll aufsetzt kein Problem. Das EJTAG Subset für Boundary Scan und External Access sollte da reichen. Auch beim TI DSP sollte dieses Subset funktionieren. Man kann also eine einheitliche Software schreiben, die neben den Flash-Typen und deren Prog.-Algorhythmus nur noch die Chip-Kennung deuten können muss. Auch ein vernünftiger flexibler Flasher ist schnell geschrieben, das habe ich schon mehrfach gemacht und das ohne große Tabellen wo jeder neue Chip nachgepflegt werden muss, CFI sei dank. Probleme sehe ich nach wie vor bei der Anbindung des JTAG an vorhandene IDEs. Bei Atmel kein Problem, weil alle Protokolle aller JTAGs offen liegen. Bei Xilinx, Altera und Lattice sehe ich da Probleme. Bei TI kann ich was versuchen, aber deren IDE-Lieferanten sahnen mit Preisen jensets 3,5k€ zu kräftig ab, als dass sie sich die Butter vom Brot nehmen lassen würden. Bei Zilog bin ich mir nicht sicher, ob die das Protokoll nicht auch offen liegen haben. Beim Debug Support wäre es zudem denkbar, dass der Weg über Linux einfacher wäre. Ich habe mich damit noch nicht beschäftigt, aber die Toolchain enthält einige Mittel zum (online-) debugging. Die Unterstützung dieses Protokolls sollte Vorang haben. Ports für Windows sind vorhanden. Da müsste sich ein Spezialist mit einklinken. So, dass sind mal die Zusammenfassungen meine Wünsche. Ich denke, dass ein Microcontroller im JTAG Adapter die Arbeit auf Protokoll-Ebene vereinfachen kann. Wenn es darauf ankommt möglichst schnell und direkt Boundary-Scan Daten abzufragen, dann geht das lokal eben besser. Das Problem bisheriger Lösungen ist eben, dass alles immer auf einer einzigen Seite gemacht wurde. Bei den Bitbangern ist es der PC und es mangelt an einer elektrisch sicheren und geschützten Verbindung zum Target, bei den fertigen Adaptern ist alles mit Controller und es mangelt an der Flexibilität. Es ist kein Kostenaufwand, an einen FT232 einen mega32 zu kleben und das lowlevel Protokoll dort zu führen, die Daten zu paketieren und schnelles punktgenaues Eingreifen zu ermöglichen. Andererseits kann man am PC viel leichter auf Software- und Protokolländerungen /-Erweiterungen reagieren. Um das Henne-Ei Problem zu lösen wäre es auch denkbar einen AtxxUSB einzusetzen. Dieser würde beide Vorteile in sich vereinen und seine Software erhält er über den USB-Bootloader. Sogar dort kann man noch einen drauf setzen, wenn man auf das Jumpern für einen Bootload verzichten will und man setzt einen Cypress USB Controller ein. Diese erhalten ihre Software einfach durch den Treiber als Binärpaket bei der USB-Anmeldung. Sie haben einen 8051 Kern und führen ihren Code auch aus dem RAM aus. Ein Software-Update des Adapters würde sich damit darauf beschränken den Treiber zu installieren und das Device einmal ab- und wieder anzustöpseln (oder die Reset Taste zu drücken). Du siehst, viele Wege führen nach Rom, aber die Probleme vollständig von der einen auf die andere Seite zu verlagern, löst sie nicht unbedingt. Es ist auch eine Frage der Unterstützung, die man für so ein Projekt aus der Community erhalten kann. Du machst aus einem reinen Controller-Problem nun ein reinrassiges PC-Software Problem und das schränkt die möglichen Helfer ein. Ich könnte vermutlich nur wenig beitragen, da ich ein reiner DSP/Controller/Schnittstellen Spezi bin. PC-Software schreibe ich höchst selten. Nicht desto trotz, ein paar FTDI232 brauche ich für ein Projekt auch noch, ich kann also zumindest Messtechnisch und Low-Level etwas beitragen. Gruß, Ulrich
Vielleicht nicht uninteressant in diesem Zusammenhang ist die MPSSE genannte erweiterte Funktionalität des FT2232, die immerhin zusammen mit OpenOCD als JTAG-Engine Verwendung findet und auch von Atmel höchstselbst mit einer "JTAG-DLL" unterstützt wird: http://ftdichip.com/Projects/MPSSE/FTCJTAG.htm http://openocd.berlios.de/web/ Das dürfte vermutlich eleganter als "Bit-Banging" mit einem FT232/245 sein.
Interessant! Auch wenn das OpenOCD sich bislang namentlich auf ARM Strukturen beschränkt. Aber das ist ja auch das Ziel der Entwicklung, möglichst Controller und Prozessoren zu unterstützen. FLASH und andere Peripherie fallen als Nebenprodukt ab. Leider werden bei OpenOCD die AVRs nicht erwähnt, bei ATMEL ist im Bereich AVR von der von Dir erwähnten DLL nichts zu sehen. Diese vermute ich mal im ARM Segment. Kannst Du uns da mal verlinken? Gruß, Ulrich
Es scheint so zu sein, daß Atmel die Implementierungsdetails der JTAG-Schnittstelle der AVRs unter Verschluss hält; nach einer Dokumentation wurde hier bereits mehrfach erfolglos gefragt. Das ist auch der Grund, warum es (von einer Kopie abgesehen) wohl auch nur einen einzigen JTAG-Adapter für AVR gibt. Die von mir erwähnte DLL ist von FTDI und hat mit Atmel nichts zu tun.
Uh! Das ist finster. Da müsste man also erst mal einen JTAG Scanner bauen um das ein wenig reverse zu engineeren :) Übrigens, ehe da Missverständnisse auftauchen. Natürlich ist das OpenOCD ein open source Projekt, es lebt also von Mitmachern. Das ist mir klar und man muss akzeptieren, dass es nicht unbedingt Funktionalität Out-Of-The-Box gibt. Es ist jedoch eine Frage, ob ich alles neu erfinde, oder ob ich auf einen Zug aufspringe und da weiter mache, wo es sinnvoll ist. Ein eigenes JTAG in Hardware und Software zu entwickeln ist wenig sinnvoll, wenn man den Links des OpenOCD Projektes folg. Einen FTDI2232 auf eine Platine zu kleben und einen Levelshifter nebst 3 LEDs hinzu zu fügen ist eine Sache für einen verregneten Feierabend. Dann kann man sich aber an das machen, was fehlt, nämlich lediglich weitere bislang nicht unterstützte Bausteine dem OpenOCD Projekt hinzufügen. Das ist sinnvoll. Ich kann verstehen, dass die Entwicklung von Demo-Boards und Programmern Zeit und Geld kostet. Atmel zielt mit seinen SPI-Programmern auf den Hobby-Sektor. Es ist ein klares Verkaufsförderungprojekt. Das ganze muss aber irgendwie bezahlt werden und das Geld holt man sich über die Profi-Tools zu Profi-Preisen wieder rein. Nur wenn genügend Leute das Tool für 250€ kaufen, kann man das Hobby-Tool für 35€ weiter zum Selbstkostenpreis verschenken. Wenn ich hier tagsüber mit Profigeräten arbeite dann sehe ich diesen Zeitgewinn und damit Geldvorteil durchaus. Richtiges In-System-Debugging via JTAG ist genial und Zeitsparend. Aber ich kann zu Hause meist darauf verzichten, weil ich da auch die Zeit habe ein Debug-Interface über eine RS232 zu implementieren und meinen Code mit printf() zu spicken. Es ist daher nicht zu erwarten, dass man solche Dokus frei bekommen kann, da diese den Profi-Tool Herstellern das Wasser abgraben würde. Nicht desto trotz, wäre es ein Projekt das mich reizt. Endlich Profi-Tools auch für zu Hause. Aber wenn man es reverse austüftelt, dann muss man das Profi-Tool erst mal kaufen und dann stellt sich schnell der Punkt ein, wo man es einfach nutzt, warum sollte man dann noch das Teil ausspionieren, wenn man es eh da hat. Da beißt sich die Katze in den Schwanz. Gruß, Ulrich
Bevor ihr hier wild drauflos entwickelt, solltet ihr noch etwas recherchieren. JTAG für Boundary scan und Programmieren gibt es. 1. z.B. Göpel (Jena) bietet JTAG-Adapter an und eine IDE mit unterstützung für BSDL und Sprache in der man eigene Routinen zur Bondary-Test und programmieren der JTAG Devices machen kann. (in so eine Richtung müßtet ihr auch entwickeln bei eurer Wunschliste.) 2. OpenOCD wurde schon genannt und dürfte für den Hobbybereich wohl der beste Ansatz sein, da schon eine Unterstützung zum GDB besteht. Statt es selbst nochmal mit dem FTDI zu entwickeln. 3. Daß es kein SDK für das Avrstudio gibt, ist einfach nicht war! http://www.atmel.no/SDK/ 4. Die JTAGDLL gibt es bei FTDI dem Hersteller des FT2232 mit Dokumentation
Wolfram wrote: > Bevor ihr hier wild drauflos entwickelt, solltet ihr noch etwas > recherchieren. > JTAG für Boundary scan und Programmieren gibt es. > > 1. > z.B. Göpel (Jena) bietet JTAG-Adapter an und eine IDE mit unterstützung > für BSDL und Sprache in der man eigene Routinen zur Bondary-Test und > programmieren der JTAG Devices machen kann. (in so eine Richtung müßtet > ihr auch entwickeln bei eurer Wunschliste.) Korrekt. > > 2. OpenOCD wurde schon genannt und dürfte für den Hobbybereich wohl der > beste Ansatz sein, da schon eine Unterstützung zum GDB besteht. Statt es > selbst nochmal mit dem FTDI zu entwickeln. Das sagte ich ja. Für OpenOCD sind mehrere Hardware-Interfaces bereits vorhanden und erprobt, selber machen sollte sich da nur auf nachbauen, bestellen oder ggf. Erweitern beschränken. > > 3. Daß es kein SDK für das Avrstudio gibt, ist einfach nicht war! > http://www.atmel.no/SDK/ > Das ist bekannt, aber verbergen sich hinter der NDA und dem ganzen dann auch die Specs des JTAG Interfaces, oder geht es dabei nur um das SDK um Erweiterungen in der IDE zu machen? Es gibt da, wenn ich daran erinnern darf zwei Schnittstellen, an denen man kämpfen muss: IDE->JTAG-Tool und JTAG-Tool->JTAG-Chip Wenn das SDK nur eine Seite, nämlich die erstgenannte abdeckt, dann nützt es nichts. > 4. Die JTAGDLL gibt es bei FTDI dem Hersteller des FT2232 mit > Dokumentation Das kam Minuten vorher schon und ich habs gefunden. Zusammen mit dem OpenOCD und den dort verlinkten Seiten findet man schnell fertig kaufbare oder leicht nachbaubare Lösungen für ein FT2232->JTAG Interface. Frei verlötet für 30€ bei Einzelstücken, 99€ für ein fertiges Modul im blauen Kästchen. Danke, Ulrich
Bitte 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.