JTAG=>USB für AVR+Logik-ICs

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

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

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