Forum: Mikrocontroller und Digitale Elektronik Standard-Programmer als DIY-Projekt


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von ich (Gast)


Lesenswert?

Hallo. Ich habe vor, statt eines PICs mal einen ARM zu benutzen. Es gibt 
für wenig Geld ja von einigen Herstellern Eval-Boards, die einen JTAG 
Programmer mit drauf haben. Doch da ich soetwas für unpraktisch halte 
(vorallem, wenn man mal den Hersteller wechseln will), wollte ich 
Fragen, obs da nicht einen Universalprogrammer gibt.

Inwiefern braucht man denn überhaupt einen? Ansich würde ich ja denken, 
dass JTAG eben JTAG ist und man somit alle uCs (und ansich auch FPGAs) 
damit beschreiben kann. Dem ist so wie ich das mitbekommen habe aber 
nicht so. Doch warum nicht? Einen USB zu JTAG IC gibt es doch von z.B. 
FTDI, der Rest sollte doch nur Software sein.

So wie ich das recherchiert habe, ist einer der universellsten 
einsetzbaren Programmer der SEGGER J-LINK. Ich wunder mich, wieso es 
sowas nicht als OpenSource gibt, so wie der Sprut-Brenner. Es gibt doch 
so viele Hammer Projekte und Leute, die es drauf haben. Aber sowas gibt 
es nicht? Oder habe ich es nur übersehen? Gut, die Zeit der Sprutbrenner 
ist ansich vorbei, da es das PICKIT schon für 25$ gibt. Aber so ein 
SEGGER kostet ja schon einiges. Mal abgesehen davon, dass man ein Gerät 
für PIC32, ein paar Atmels, ARM (ST, NXP, TI, ...), einige DSPs und 
FPGAs (XILINX, Altera, Microsemi, Lattice) hätte. Kein ständiges 
wechseln "tausender" einzelnen Programmer. Zugegeben, bei FPGAs ist 
diese Variation vielleicht nicht erforderlich, da es wirklich große 
Unterschiede im Aufbau und IDE gibt (wobei auf der anderen Seite ja nur 
ein simpler Programm-Flash beschrieben werden muss), aber bei der 
Kompatibilität, mit der die ARM Technologie immer beworben wird, ist 
soetwas denke ich Pflicht. Eine IDE, ein Compiler (da ja alle ARMs 
gleich sein sollen) und ein Programmer. Hat ein STM32F4 Vorteile, dann 
nehme ich den. Im nächsten Projekt könnte es dann ein EFM32 Gecko sein 
oder ein LPC...


So ein Selbstbau-Universal Programmer muss für mich nichtmal Debugging 
können. Ich würde aber gerne eine Software für irgendeinen ARM schreiben 
können und dieses Programm dann auch auf den uC. Für mich macht dieser 
Mangel an Programmer, die zumindest alle ARMs unterstützen, die ARMs 
"uninteressant". Wenn ich Leistung brauche, habe ich noch den PIC32. 
Doch ich wollte mich ja mit den ARMs beschäftigen, eben weil man da ja 
die Wahl von verschiedenen Herstellern hat. Sollte es so sein, dass man 
für jeden Hersteller nen eigenen Programmer, IDE und Compiler braucht, 
dann verstehe ich den Sinn vom ARM und JTAG Standard nicht. Dann sind 
das doch nichts anderes als verschiedene, untereinander komplett 
unkompatible 32bit uCs.

von Gerhard O. (gerhard_)


Lesenswert?

Hallo "ich"

irgendwie finde ich, daß sich der Selbstbau hier nicht sehr lohnt weil 
alles (HW+SW) zusammen funktionieren muß. Sogar bei namhaften 
Herstellern gibt es oft ärgerliche Probleme beim Betrieb. Aber 
vielleicht wäre das von Interesse:

für Hobby und Schulzwecke gibt es den JLINK schon ab $CDN77 bei uns. Das 
ist doch schon sehr günstig. Man darf ihn nur nicht kommerziell 
verwenden.

http://www.digikey.ca/product-detail/en/8.08.90%20J-LINK%20EDU/899-1008-ND/2263130

Benutzungsbedingungen:

http://media.digikey.com/pdf/Data%20Sheets/Segger%20PDFs/J-LINK%20EDU_Terms.pdf




mfg,
Gerhard

: Bearbeitet durch User
von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

ich schrieb:
> der Rest sollte doch nur Software sein.

Sollte. Aber die Schnittstellen unterschiedlicher Systeme zu den 
JTAG-Adaptern ist sehr unterschiedlich, wie auch die über das reine 
JTAG-Protokoll hinausgehende Datenübertragung sich von Prozessorfamilie 
zu Prozessorfamilie unterscheidet.

Deswegen lassen sich AVRs auch nicht mit selbstgebauten JTAG-Adaptern à 
la "Wiggler" (für den Frickelport) oder FT2232-basierten JTAG-Adaptern 
programmieren/debuggen, und bei MSP430 sieht das nicht anders aus.

Eine "Universallösung" ist daher nicht ohne weiteres möglich.

von Peter D. (peda)


Lesenswert?

ich schrieb:
> Ansich würde ich ja denken,
> dass JTAG eben JTAG ist

Im Prinzip ist es das.
Aber JTAG heißt nichts weiter als, es gehen 4 Leitungen zum Chip, auf 
denen sowas wie SPI läuft.

Was für ein Protokoll auf diesen 4 Leitungen gesprochen wird, halten die 
Chiphersteller geheim und ist für jeden Chip unterschiedlich.

Ich vermute mal, bei den selbstbau JTAGs muß mal jemand an einem 
professionellen Gerät mitgelauscht und das Protokoll entschlüsselt 
haben.

von JTagger (Gast)


Lesenswert?

Rufus Τ. Firefly schrieb:
> Aber die Schnittstellen unterschiedlicher Systeme zu den
> JTAG-Adaptern ist sehr unterschiedlich

Die JTAG-Schnittstelle ist einheitlich, da gibt es keine Unterschiede, 
da es nur die Signale TMS, TCK, TDI, TDO und optional TRST gibt. Das ist 
bei allen Herstellern gleich, die Schnittstelle ist in IEEE1149.1 
genormt.

von GB (Gast)


Lesenswert?

Von CooCox gibt es das CoLinkEx als Selbstabauprojekt, das unterstützt 
viele Cortex M Prozessoren (M0, M0+, M3, M4).
Kann man auch selbst bauen, als Prozessor ist der LPC1343 verbaut, der 
lässt sich nämlich ohne JTAG-Adapter flashen (meldet sich als 
USB-Massenspeicher beim Anstecken an den USB-Port, und die Firmware wird 
einfach darauf kopiert).

von Oliver J. (skriptkiddy)


Lesenswert?

Ich werfe mal das hier in den Raum:
http://www.versaloon.com/
Kingt interessant.

Grüße Oliver

von John Wayne sein Garagennachbar (Gast)


Lesenswert?

Oliver warf:
>Ich werfe mal das hier in den Raum:
>http://www.versaloon.com/

Aua! Guck das nächste Mal erst in den Raum, ob jemand im Wege steht....
;-)

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

JTagger schrieb:
> Rufus Τ. Firefly schrieb:
>> Aber die Schnittstellen unterschiedlicher Systeme zu den
>> JTAG-Adaptern ist sehr unterschiedlich
>
> Die JTAG-Schnittstelle ist einheitlich

Du hast exakt nicht verstanden, was ich geschrieben habe. Es geht 
nicht um die elektrische Schnittstelle, sondern um den "Rest" 
drumherum.

Nur zwei kleine, aber nicht banale Beispiele:

a) Wie kommuniziert die Software unter Betriebssystem XY mit dem 
jeweiligen JTAG-Adapter?

b) Wie wird über das JTAG-Interface z.B. das µC-interne FLASH 
programmiert?


Wären diese Punkte standardisiert, könnte man AVRs auch mit anderen 
JTAG-Interfaces als dem recht teuren JTAG-ICE von Atmel programmieren 
und Debuggen, so auch mit einem Frickelport-"Wiggler" oder einem 
FT2232-basierenden OpenOCD-Adapter ...

Kann man aber nicht, genausowenig wie man das mit MSP430 statt AVR 
anstellen kann.

Ebensowenig kann man anstelle von µCs irgendwelche FPGAs damit 
ansteuern.


Und das alles, obwohl die JTAG-Schnittstelle ja "einheitlich" ist.

von ich (Gast)


Lesenswert?

Gerhard O. schrieb:
> Hallo "ich"
>
> irgendwie finde ich, daß sich der Selbstbau hier nicht sehr lohnt weil
> alles (HW+SW) zusammen funktionieren muß. Sogar bei namhaften
> Herstellern gibt es oft ärgerliche Probleme beim Betrieb. Aber
> vielleicht wäre das von Interesse:
>
> für Hobby und Schulzwecke gibt es den JLINK schon ab $CDN77 bei uns. Das
> ist doch schon sehr günstig. Man darf ihn nur nicht kommerziell
> verwenden.
>
> http://www.digikey.ca/product-detail/en/8.08.90%20...
>
> Benutzungsbedingungen:
>
> http://media.digikey.com/pdf/Data%20Sheets/Segger%...
>
> mfg,
> Gerhard

Ja. Die Edition habe ich auch gesehen, doch durch das kürzel Edu dachte 
ich,, es gilt nur für Schulen/Unis und deren Besucher..


Rufus Τ. Firefly schrieb:
> ich schrieb:
>> der Rest sollte doch nur Software sein.
>
> Sollte. Aber die Schnittstellen unterschiedlicher Systeme zu den
> JTAG-Adaptern ist sehr unterschiedlich, wie auch die über das reine
> JTAG-Protokoll hinausgehende Datenübertragung sich von Prozessorfamilie
> zu Prozessorfamilie unterscheidet.
>
> Deswegen lassen sich AVRs auch nicht mit selbstgebauten JTAG-Adaptern à
> la "Wiggler" (für den Frickelport) oder FT2232-basierten JTAG-Adaptern
> programmieren/debuggen, und bei MSP430 sieht das nicht anders aus.
>
> Eine "Universallösung" ist daher nicht ohne weiteres möglich.

Ich hatte mir das so vorgestellt: Ein Bauteil (FTxxxx oder nen uC) 
bekommt von einer PC-Software via USB eine Anweisung (z.B. 
programmieren), ein Device (z.B. STM32F4xxx) und die hex-file bzw dessen 
Inhalt. Nun ist es an dem uC die Daten via JTag zum Device zu bekommen. 
Je nach dem, was der Ziel-uC braucht, werden mehr oder weniger IOs 
genutzt und auch die Übertragung ansich kann ja anhand der übermittelten 
Device-Info umgestellt werden.


Peter Dannegger schrieb:
> ich schrieb:
>> Ansich würde ich ja denken,
>> dass JTAG eben JTAG ist
>
> Im Prinzip ist es das.
> Aber JTAG heißt nichts weiter als, es gehen 4 Leitungen zum Chip, auf
> denen sowas wie SPI läuft.
>
> Was für ein Protokoll auf diesen 4 Leitungen gesprochen wird, halten die
> Chiphersteller geheim und ist für jeden Chip unterschiedlich.
>
> Ich vermute mal, bei den selbstbau JTAGs muß mal jemand an einem
> professionellen Gerät mitgelauscht und das Protokoll entschlüsselt
> haben.

Ach ist das nicht offen? Aber mithören wäre eine Möglichkeit.


GB schrieb:
> Von CooCox gibt es das CoLinkEx als Selbstabauprojekt, das
> unterstützt
> viele Cortex M Prozessoren (M0, M0+, M3, M4).
> Kann man auch selbst bauen, als Prozessor ist der LPC1343 verbaut, der
> lässt sich nämlich ohne JTAG-Adapter flashen (meldet sich als
> USB-Massenspeicher beim Anstecken an den USB-Port, und die Firmware wird
> einfach darauf kopiert).

Sieht nicht schlecht aus. Der LPC1341 scheint ja für sowas wie gemacht 
zu sein. Anders als beim Sprut Brenner8. Mein Gedanke wäre also, diesen 
uC zu holen (Mouser: 3,74€) ein bisschen Hühnerfutter und eine kleine 
Platine (ggf selbst gemacht). Macht zusammen keine 5€. Ist gegenüber dem 
(dafür ansich schon günstigen) J-LINK EDU ein 10tel so teuer, kann 
natürlich auch weniger. Wenn man aber nur ein, zwei Projekte mit einem 
(speziellen) ARM realisieren will, lohnen sich selbst die 50€ nicht.

Aber wieso unterstützt der nur die/ein paar LPC1xxx und keine LPC2xxx, 
3xxx und 4xxx? Ich hätte gedacht,  dass die Übertragung gleich aussieht.


Oliver Ju. schrieb:
> Ich werfe mal das hier in den Raum:
> http://www.versaloon.com/
> Kingt interessant.
>
> Grüße Oliver

Sieht auch gut aus. Ist weniger drauf, unterstützt aber auch weniger 
Bauteile.

von Michael L. (michaelx)


Lesenswert?

Rufus Τ. Firefly schrieb:

> Nur zwei kleine, aber nicht banale Beispiele:
>
> a) Wie kommuniziert die Software unter Betriebssystem XY mit dem
> jeweiligen JTAG-Adapter?

Das sehe ich auch als Hauptproblem, dass die Kommunikation zwischen der 
IDE und dem JTAG-Adapter herstellerspezifisch ist.

Also scheitert ein Universal-JTAG-Programmer wahrscheinlich an der 
Integration, oder müsste irgndwelche Treiber-Software für jede IDE 
mitbringen, um die JTAG-Adapter der Hersteller zu emulieren. Die 
Alternative ist eine Stand-alone-Programmer-Lösung, die eine zuvor 
ausgewählte Datei einfach in den Chip schreibt (am besten über ein 
Mini-Fenster was immer im Vordergrund steht, so wie beim Win-PIC).

> b) Wie wird über das JTAG-Interface z.B. das µC-interne FLASH
> programmiert?

Hm, weiß ich nicht so genau. Aber da JTAG prinzipiell das 
In-Reihe-Schalten mehrerer Chips erlaubt, muss es zumindest ein paar 
Grundregeln in der Kommunikation geben. Vielleicht weiß da jemand mehr?

von ich (Gast)


Lesenswert?

Michael L. schrieb:
> Das sehe ich auch als Hauptproblem, dass die Kommunikation zwischen der
> IDE und dem JTAG-Adapter herstellerspezifisch ist.
>
> Also scheitert ein Universal-JTAG-Programmer wahrscheinlich an der
> Integration, oder müsste irgndwelche Treiber-Software für jede IDE
> mitbringen, um die JTAG-Adapter der Hersteller zu emulieren. Die
> Alternative ist eine Stand-alone-Programmer-Lösung, die eine zuvor
> ausgewählte Datei einfach in den Chip schreibt (am besten über ein
> Mini-Fenster was immer im Vordergrund steht, so wie beim Win-PIC).

Der erwähnte CoLinkEx hat wohl für CooCox, Keil und IAR nen Plugin. Der 
kann auch einige Prozessoren flashen. Ich verstehe nur nicht, wieso z.B. 
ein paar EFM32 nicht unterstützt werden, oder aber auch nur ein paar 
LPC1xxx aber keine 2xxx, 3xxx und 4xxx. Ich habe wie gesagt bisher nur 
was mit PICs gemacht, aber da werden alle PICs, von PIC10 bis PIC32, 
gleich via ICSP programmiert. So würde ich das bei NXPs ARMs auch 
erwarten, nur wieso werden nur so wenig unterstützt?

So eine Stand-Alone-Lösung würde mich nicht stören. Aus meiner Sicht ist 
so ein DIY Programmer für diejenigen, die kein/wenig Geld ausgeben 
wollen. Und da finde ich persönlich eine umfangreichere Unterstützung 
wichtiger, als eine Einpflegung in verschiedene IDEs. Es kann ja auch 
sein, das jemand ein fertiges Projekt nachbauen will und sich für den uC 
gleich die fertige hex läd. Dann ist eine IDE freie Möglichkeit 
vielleicht sogar besser. Naja.. Es is besser als nichts. Wer mehr will, 
muss wohl zahlen oder selbst ran.


> Hm, weiß ich nicht so genau. Aber da JTAG prinzipiell das
> In-Reihe-Schalten mehrerer Chips erlaubt, muss es zumindest ein paar
> Grundregeln in der Kommunikation geben. Vielleicht weiß da jemand mehr?

Ich kenne mich mit dem JTAG auch nicht wirklich aus, aber wenn es 
ähnlich zu SPI ist, gibts es nur wenig unterschiedliche Art und Weisen, 
Daten zu übertragen. Ich denke das Problem ist eher, welche Daten werden 
wann und wie genau übertragen. Aber ich hab bisher auch gedacht, dass es 
nicht sooo schwer sein kann, einen Universalprogrammer zu bauen. 
Höchstens dass es noch keiner für nötig fehalten hat, sowas selbst zu 
machen.

von Frank K. (fchk)


Lesenswert?

ich schrieb:

> Der erwähnte CoLinkEx hat wohl für CooCox, Keil und IAR nen Plugin. Der
> kann auch einige Prozessoren flashen. Ich verstehe nur nicht, wieso z.B.
> ein paar EFM32 nicht unterstützt werden, oder aber auch nur ein paar
> LPC1xxx aber keine 2xxx, 3xxx und 4xxx. Ich habe wie gesagt bisher nur
> was mit PICs gemacht, aber da werden alle PICs, von PIC10 bis PIC32,
> gleich via ICSP programmiert. So würde ich das bei NXPs ARMs auch
> erwarten, nur wieso werden nur so wenig unterstützt?

Weil das Beschreiben des Flash bei jedem anders ist. Unter anderem.

Sieh es einfach so: Du hast eine Druckerschnittstelle, früher parallel, 
jetzt USB. Elektrisch überall gleich. Du brauchst jetzt aber für jeden 
Druckertyp einen extra Treiber, und das auch für jedes Betriebssystem. 
Und früher bei DOS-Programmen auch für jedes Programm.

So ist das hier auch.

fchk

von Ulrich H. (lurchi)


Lesenswert?

Es gibt schon genügend Schaltpläne für JTAG Adapter. Das Problem ist 
aber das man mehr als nur die JTAG Hardware braucht. Der Hardware-Teil 
ist genormt, so das es da auch offenen Lösungen gibt - leider halt 
relativ viele verschiedenen.

Zur Hardware braucht es aber noch die Software, die dem µC sagt das man 
etwa das Flash oder Register lesen oder beschreiben will. Dieser Teil 
ist nicht zu 100% genormt und zum großen Teil auch ein "Geheimnis" der 
Chiphersteller. Leider hat sich keine allgemeine Hardware Durchgesetzt, 
so dass man halt zum µP eine passende Software von µC Hersteller 
braucht, und dann eine zu der Software passende Hardware (oder eine 
Hardware mit Treiber Software). Je nach µC ist man da halt leider oft 
auf spezielle recht teure Produkte angewiesen.

Es gibt eine offene JTAG Software, die aber nur einige µC und da auch 
teilweise auch nur mit eingeschränkter Funktion (z.B. nur Flash 
schreiben/Lesen) unterstützt. Das Problem ist da halt die fehlende 
Information der Hersteller.
http://openocd.sourceforge.net/

Für ARMs sieht es da noch relativ gut aus, bei PICs und AVRs aber eher 
schlecht.

Wenn man also was neu entwickeln müsste dann eher Treibersoftware, 
sodass man mit bekannter offener Hardware mehr Herstellersystem 
unterstützen kann, etwa so dass AVRStudio dann mit FTxxxx Jtager oder 
Wigglern klar kommt.

von ich (Gast)


Lesenswert?

Frank K. schrieb:
> Weil das Beschreiben des Flash bei jedem anders ist. Unter anderem.
>
> Sieh es einfach so: Du hast eine Druckerschnittstelle, früher parallel,
> jetzt USB. Elektrisch überall gleich. Du brauchst jetzt aber für jeden
> Druckertyp einen extra Treiber, und das auch für jedes Betriebssystem.
> Und früher bei DOS-Programmen auch für jedes Programm.
>
> So ist das hier auch.
>
> fchk

Ich verstehe was du meinst, nur warum sollte das der Hersteller für 
seine Produkte immer wieder neu machen? Wie gesagt, meines Wissens nach 
ist das bei den PICs so. Zuerst meinetwegen die ConfigBytes (zwar 
unterschiedlich viele aber das ist ja egal), danach der Flash und danach 
ggf. EEPROM Inhalt. Vielleicht auch mit ein zwei Steuerbefehlen, sodass 
bei nem kleinen Prog nicht der gesamte Flashbereich beschrieben werden 
muss. Klar ist bei nem PIC10 ansich alles anders als bei einem PIC32, 
doch beide haben Configbytes und nen Programm-Flash. Und nur darum geht 
es ja beim programmieren.


Off-Topic:
Wie schreibt man eigentlich dieses "Ein zwei ..." korrekt? "Ein zwei 
Steuerbefehle", "ein, zwei Steuerbefehle", "ein/zwei Steuerbefehle" oder 
müsste man "ein bis zwei Steuerbefehle" schreiben, also dass das 
weglassen des "bis" umgangssprachlich ist? ;)

von ich (Gast)


Lesenswert?

Ulrich H. schrieb
> Für ARMs sieht es da noch relativ gut aus, bei PICs und AVRs aber eher
> schlecht.
> Wenn man also was neu entwickeln müsste dann eher Treibersoftware,
> sodass man mit bekannter offener Hardware mehr Herstellersystem
> unterstützen kann, etwa so dass AVRStudio dann mit FTxxxx Jtager oder
> Wigglern klar kommt.

Echt? Woher hat dann der SprutBrenner Entwickler die Infos? Abgesehen 
davon ist die Firmware zum PICKIT3 bei Microchip zu haben (ist ja auch 
ein PIC drinne). Da sollte man doch relativ einfach an die Infos 
rankommen (z.B. via disassembler)

von Soul E. (Gast)


Lesenswert?

ich schrieb:

> (...) wollte ich
> Fragen, obs da nicht einen Universalprogrammer gibt.

Sowas zum Beispiel: http://usbprog5.embedded-projects.net/index.html

Das Problem ist halt, auch wenn der Programmer universal ist, so ist 
doch die Anbindung an die jeweilige Programmierumgebung höchst 
proprietär. Du musst Dir immer den passenden Treiber und ggf die 
passende Firmware schreiben (lassen).

von Frank K. (fchk)


Lesenswert?

ich schrieb:

> Ich verstehe was du meinst, nur warum sollte das der Hersteller für
> seine Produkte immer wieder neu machen?

Weil Du zu kurz denkst. Zuallererst ist JTAG keine 
Programmierschnitstelle, sondern eine Schnittstelle für den Test des 
Chips an sich und den elektrischen Test der Schaltung. Dass Du damit 
auch die internen Speicher beschreiben und lesen kannst, ist ein 
angenehmer Nebeneffekt, war aber nicht Ziel beim Entwurf von JTAG. Das T 
in JTAG steht übrigens für Test. Deswegen ist JTAG an sich auch so 
komplex im Vergleich zu zB der ISP-Schnittstelle der AVRs, die wirklich 
nur zum Programmieren gedacht war und auch nichts anderes kann. Und so 
ist zu erklären, dass JTAG extrem chipspezifisch sein muss.

Wenn es ans Debuggen geht, wird es nochmals eine Stufe komplexer. Dann 
kommen nämlich die verschiedenen Prozessorkerne mit ihren Interna hinzu.

fchk

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
Noch kein Account? Hier anmelden.