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.
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
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 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.
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 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).
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.... ;-)
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.
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.
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?
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.
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
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.
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? ;)
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)
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).
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
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.