Hallo Jungs, ich habe 3 unterschiedliche XMEGA in unserem Gerät verbaut. Jeder XMEGA ist auf einem seperaten Board untergebracht. Bis jetzt habe ich die XMEGAs immer mit einem JTAGICE MKII über das PDI Interface programmiert. Demnach besitzt jedes Board einen PDI Steckverbinder. Unser Gerät besitzt ein USB Interface zum PC. In unserem Gerät ist ein USB Hub verbaut so das im Gerät mehrere USB Anschlüsse zur verfügung stehen. Mein Chef hat mich nun beauftragt das die XMEGA µC über das USB Interface programmierbar sein müssen. Dies ist unbedingt notwendig, so das der Support übers Internet auf den PC zugreifen kann und dann die Firmware vom µC updaten kann. Ich habe überlegt alle 3 µC in eine JTAG Kette einzubinden, jedoch besitzen die kleine XMEGA Gehäuse wie z.B. der XMEGA 32A4U kein JTAG Interface. Ich hatte auch überlegt ein AVRISP MKII zu kaufen. Diese wolle ich dann aufmachen und reinschauen was verbaut ist. Anschließen wollte ich den Inhalt vom AVRISPII ins Gerät auf einer Platine unterbringen. Den AVRISP MKII wollte ich dann an den internen HUB anschließen. Nur habe ich gelesen das PDI eine serielle sychrone bidirektionale USART ist. Demnach benötige ich dann 3 AVRISP MKII Dowaloader im Gerät. Ich wollte unbedingt das AVR Studio weuiter benutzen, um die Firmware auf den XMEGA hochzuladen. Hat jemand bessere Vorschläge wie ich die 3 XMEGA über ein USB Interface programmieren kann?
>> Auf dem XMEGA ist doch ein BOOTloader drauf.
Das nicht, hat aber eine Bootloader Section.
Stefan
Der muss doch einen Standard Bootloader drauf habe sonst könnte ich doch nicht über das PDI Interface oder über JTAG Daten auf den XMEGA bekommen. Ich könnte jetzt natürlich einen Bootloader schreiben so das die Daten über eine SPI, RS232 oder I2C Interface in den XMEGA geschrieben werden, dies finde ich aber nicht unbedingt notwendig. Oder was für einen entscheidenen Vorteil soll dies haben?
Bootloader: Billig, da oft bereits vorhandene Schnittstellen genutzt werden.... Alternative mk2 mit usb-avr emulieren (Stichwort lufa mk2 Clone)...
Johann schrieb: > Der muss doch einen Standard Bootloader drauf habe sonst könnte ich doch > nicht über das PDI Interface oder über JTAG Daten auf den XMEGA > bekommen. Das ist kein Bootloader (Software), sondern das macht die Hardware selbst. Prinzipiell ist die PDI-Schnittstelle dokumentiert, sofern es sich um das reine Programmieren handelt. (Das Debuggen ist nicht dokumentiert.) Du kannst dich also hinstellen und deinen eigenen Programmer dafür bauen. (*) > Ich könnte jetzt natürlich einen Bootloader schreiben so das die Daten > über eine SPI, RS232 oder I2C Interface in den XMEGA geschrieben werden, > dies finde ich aber nicht unbedingt notwendig. Oder was für einen > entscheidenen Vorteil soll dies haben? Es wird der kostengünstigste und schnellste Weg sein, den du haben kannst. (*) Wenn ich mal nach "opensource pdi programmer" gugele (hättest du auch selbst tun können ;-), dann hat offenbar Dean Camera sowas schon gemacht. Eventuell kannst du das ja für dich benutzen.
Ich fasse mal Eure Vorschläge zusammen: Ich muss in meinem Gerät einen USB auf RS232 Converter verbauen. Dann muss ich einen eigenen Bootloader für eine RS232 Interface schreiben (dieser muss dann auch wirklich absolute zuverlässig funktionieren) Anschließend mus ich eine PC Software schreiben die mein Hex File in den XMEGA schreibt. Dies muss auch wieder zurückgelesen werden. Ich möchte nicht unhöflich wirken aber dies ist eine sehr aufwendige und fehleranfällige Lösung. Bis man erst dies umgesetzt hat ist sehr viel Zeit vergangen. Und was noch viel schlimmer ist das ich das Rad neu erfinden muss. PDI ist ja nichts anderes als eine bi-directional half-duplex USART. Diese funktioniert zuverlässig und ist auch von Atmel getestet. Demnach muss ich dies nicht noch einmal programmieren. Zudem gibt es das AVR Studio als Software, somit habe ich auch eine Software mit dem ich mein HEX File auf den XMEGA bekomme. Das was ich nun benötige ist eine USB auf RS232 Converter. ATMEL selbst hat auf dem XPLAIN Board dan AT90USB1287 verbaut. Da ich ja 3 XMEGA verwende benötige ich also 3 USB auf RS232 Converter. Kann ich auch einen FTDI Chip verwenden oder erkennt das AVR Studio diesen USB auf RS232 Converter nicht?
>> Ich muss in meinem Gerät einen USB auf RS232 Converter verbauen. Es gibt XMEGA .U. >> Dann muss ich einen eigenen Bootloader für eine RS232 Interface >> schreiben (dieser muss dann auch wirklich absolute zuverlässig >> funktionieren) goolge mal Bootloader XMEGA. Ich denke die gibts schon. >> Anschließend mus ich eine PC Software schreiben die mein Hex File >> in den XMEGA schreibt. goolge mal Bootloader XMEGA. Ich denke die Software ist dabei. >> Kann ich auch einen FTDI Chip verwenden oder erkennt das AVR >> Studio diesen USB auf RS232 Converter nicht? Wäre mein Favorit, noch lange vor den U-Typen. Du brauchst auch nur einen, die Dinger haben CBUS Pins die Du zum adressieren der entsprechenden UART benutzen kannst. Der 230X kostet nicht mal wirklich Geld. Aber dann zum Brennen eigene Software. Stefan
Johann schrieb: > Ich muss in meinem Gerät einen USB auf RS232 Converter verbauen. Nicht unbedingt. Du kannst auch irgendeinen USB-fähigen Controller benutzen (AT90USB1286, ATmega32U4 oder so). > Dann > muss ich einen eigenen Bootloader für eine RS232 Interface schreiben > (dieser muss dann auch wirklich absolute zuverlässig funktionieren) Ja, dafür gibt's aber Beispiele. > Anschließend mus ich eine PC Software schreiben die mein Hex File in den > XMEGA schreibt. Dies muss auch wieder zurückgelesen werden. Musst du nicht unbedingt. Wenn du ein Protokoll benutzt, welches von gängiger Programmiersoftware (AVR Studio's Programmierwerkzeug(e), AVRDUDE) unterstützt wird, kannst du dir diesen Schritt sparen. STK500v2 oder AVRISPmkII wären ein Beispiel (auf höherer Ebene sind diese beiden gleich, die physische Datenübertragung ist ein wenig verschieden). > Ich möchte nicht unhöflich wirken aber dies ist eine sehr aufwendige und > fehleranfällige Lösung. Bis man erst dies umgesetzt hat ist sehr viel > Zeit vergangen. Ja. > Und was noch viel schlimmer ist das ich das Rad neu erfinden muss. Nein. Du kannst viele Sachen davon im Netz finden und nachnutzen. Musst nur bei GPL-basierter Software aufpassen, dass du demjenigen, dem du die Geräte gibst, auch den Sourcecode anbieten musst. Für einen reinen Bootloader wäre dies aber kein Thema; eine Implikation, deshalb auch die mit dem Bootloader zu ladende Firmware als Sourcecode weitergeben zu müssen, kann man daraus nicht ableiten. > PDI > ist ja nichts anderes als eine bi-directional half-duplex USART. Ja, und STK500v2 ist einfache RS-232-Kommunikation. So what? Der Aufwand liegt eben jenseits dieser simplen Aussage. > Das was ich nun benötige ist eine USB auf RS232 Converter. Warum? Du benötigst einen USB-auf-PDI-Konverter, und der heißt halt AVRISPmkII. Wenn du den Zwischenschritt RS-232 nimmst, dann bist du beim Bootloader. > Da ich ja 3 XMEGA verwende benötige ich also 3 USB auf RS232 > Converter. Man könnte auch einen USB-Controller nehmen und den das verteilen lassen. Allerdings fürchte ich, dass die maximal 6 USB endpoints eines (beispielsweise) AT90USB1286 nicht genügen, um drei serielle Links gleichzeitig (nebenläufig) implementieren zu können. Eine Alternative wäre es, eine "Weiche" in die Firmware deines internen Programmieradapters einzubauen, die entscheidet, mit welchem der drei Controller jetzt gearbeitet werden soll. Sowas könnte man als Erweiterung eines bestehenden Programmierprotokolls (wie AVRISPmkII) realisieren und dann beispielsweise mit einer privaten Version von AVRDUDE arbeiten, die um diese Erweiterung weiß und sie benutzen kann. > Kann ich auch einen FTDI Chip verwenden oder erkennt das AVR Studio > diesen USB auf RS232 Converter nicht? Das AVR Studio erkennt überhaupt nichts. Du musst dir erstmal im Klaren werden, was du machen willst. Du schreibst hier die ganze Zeit irgendwas von einem USB<->RS-232- Konverter. Was folgt denn dann danach, welches Programmierprotokoll soll damit gesprochen werden? Falls es mit AVR Studio klappen soll, fiele mir da nur STK500v2 ein, denn das ist ein rein auf RS-232 aufsetzendes Protokoll. In diesem Falle müsstest du in deinem Betriebssystem einen Treiber für den FTDI haben, der einen fiktiven seriellen Port abbildet, und diesen Port sprichst du dann aus deinem AVR Studio an. Dabei hat AVR Studio keinen Schimmer, ob sich dahinter eine Hardware-UART oder eben ein USB<->RS-232-Adapter befindet. Willst du jedoch dem AVR Studio vorgaukeln, dass du einen AVRISPmkII hast, dann kannst du den FTDI zur Seite legen. Das AVRISPmkII ist kein USB<->RS-232-Konverter, sondern es besitzt einen USB-Chip (ich glaub von NXP), der mit dem berühmt-berüchtigten Jungo-Treiber arbeitet. Was hinter dem USB-Chip ist, muss dann das AVRISPmkII- Protokoll sprechen. Natürlich kann man USB-Chip und "das dahinter" auch wiederum in einem USB-fähigen Controller vereinen, aber du müsstest das alles USB-seitig so aussehen lassen, dass der Jungo-Treiber sich verarschen lässt und das Gerät als seins akzeptiert. Keine Ahnung, inwiefern sich da Dean Cameras oben genannte Lösung integrieren lassen könnte.
Jörg Wunsch schrieb: > Du > schreibst hier die ganze Zeit irgendwas von einem USB<->RS-232- > Konverter. Ah, mir dämmerst's gerade. Vermutlich glaubst du, nur weil PDI physisch eine half-duplex-UART ist, könnte man das direkt an eine RS-232-Schnittstelle (mit entsprechender Pegelwandlung/ -invertierung) klemmen und dann mit irgendeiner Art ASCII-Zeichen direkt darauf herumopern? Nein, so einfach ist die Welt leider nicht. Btw., PDI ist nicht UART-fähig, sondern es ist ein synchrones Protokoll. Der PDI-Master gibt den Takt mit vor.
Wenn es ein Gerät ist, warum dann 3 XMegas? Eine Leistungsstarke CPU würde es doch sicher auch tun. Würde das Gerät sicher im ganzen auch deutlich günstiger werden lassen. Bei 3 XMEGAS hast du sicher auch 3 Programme und jeder XMEGA braucht dann einen eigenen Bootloader, alle 3 Programme müssen gepflegt werden usw. Eine 32 bit ARM MCU mit 176 Pins gibt es zwischen 10 und 20 Euro. Die hätte dann 168 MHz, USB, I2C, Can, SPI und vieles mehr... Da du sowieso gerade das RAD neu erfinden willst, würde ich darüber mal nachdenken. Jörg
Ich habe bereits einige FTDI USB Converter verbaut. Der FT230x sieht wirktlich sehr interessant aus. Dieser ist wirklich sehr klein. Dieser ist momentan aber nicht bei Digikey verfügbar. Wie kann ich denn mit dem CBUS Leitungen zwischen den unterschiedliche XMEGA auswählen? Benutzt DU die CBUS Leitung als CLK Leitung die dann beim XMEGA an den RESET_CLK Pin angelegt wird? Gibt es für die FTDI Chips bereits Demoprogramme als Code und als Exe? Über den XMEGA U Variante habe ich bereits auch schon nachgedacht. Dieser ist auch sehr klein und sehr günstig. Dann benötige ich ein Programm für den XMEGAU der über 3 Unterschiedliche RS232 Verbindungen 3 µC ansteuern kann. Auf dem XPLAIN das ich besitze ist der AT32UC3B1256 Verbaut. Dieser ist mit 10$ schon recht teuer würde aber noch gehen. Dafür gibt es sicherlich eine Firmware von Atmel. Dadurch kann ich sofort das AVR Studio verwenden. Es ist halt nur die FRAGE ob man bei der FIRMWARE vom AT32UC3B1256 3 unterschiedliche XMEGA programmieren kann?
>> Der FT230x sieht wirktlich sehr interessant aus. Dieser ist wirklich >> sehr klein. Dieser ist momentan aber nicht bei Digikey verfügbar. TME , Mouser hatten letztens welche für unter 2€. >> Benutzt DU die CBUS Leitung als CLK Leitung die dann beim XMEGA >> an den RESET_CLK Pin angelegt wird? Ich habs noch nicht gemacht aber ich würde einfach zwei im Reset halten dann quatscht nur einer. Du kannst natürlich auch die CBUS einzeln auf 24MHZ stellen (vielleicht ergibt sich mit PLL ein CPU höherer Takt, keine Lust jetzt nachzurechnen) und das als Clock für den XMEGA nehmen. Wenn Du mutig bist nimm gleich 48 ;-). >> Gibt es für die FTDI Chips bereits Demoprogramme als Code und als Exe? FTDI hat eine LIB als DLL. Da ist auch ein Demo bei. Lässt sich ganz easy wie ein Windows COM-Port programmieren. >> Auf dem XPLAIN .... lass den Scheiß ;-) Stefan
Bei Mouser sind 3000 FT230X auf Lager. Dann werde ich mal so ein Demoboard kaufen und dies damit mal ausprobieren :-)
Die 12 oder 24MHz sind vollkommen ausreichend. Wie mache ich es denn mit der RX und TX Leitung. Unterstützt der FTDI denn eine bi-directional half-duplex syncrone RS232 Schnittstelle mit mehreren Empfängern? Ich muss ja an der RX und TX Leitung 3 µC anschließen. Ist dies überhaupt sinnvoll? Da ich ja überall die XMEGA U Modelle verwende könnte ich diese auch mit einem Bootloader direkt über USB programmieren?
Johann schrieb: > Unterstützt der FTDI denn eine bi-directional > half-duplex syncrone RS232 Schnittstelle mit mehreren Empfängern? Siehe oben: vergiss das als Idee! PDI ist nicht einfach "eine bi-direktionale Halbduplex-UART", der du nur noch einen USB-RS232-Wandler voranstellen musst. Lies dir gottverdammich mal durch, was Dean Camera alles tun musste, um seinen Opensource-PDI-Programmer zu bauen. Danach überdenkst du dann deine Idee nochmal. Wenn du gedenkst, mich weiterhin ignorieren zu müssen, dann renn' bitte weiter gegen die Wand. Aber jammer' hinterher nicht, wenn der Aufprall weh tut. :-)
Johann schrieb: > Ich hatte auch überlegt ein AVRISP MKII zu kaufen. Diese wolle ich dann > aufmachen und reinschauen was verbaut ist. Anschließen wollte ich den > Inhalt vom AVRISPII ins Gerät auf einer Platine unterbringen. Den AVRISP > MKII wollte ich dann an den internen HUB anschließen. Nur habe ich > gelesen das PDI eine serielle sychrone bidirektionale USART ist. Demnach > benötige ich dann 3 AVRISP MKII Dowaloader im Gerät. Nicht unbedingt. Es gibt sogenannte "Bus Switches", bidirektionale Multiplexer also, mit denen Du zwischen verschiedenen Ports umschalten kannst. Schau Dir mal den Fairchild FST3253 an. Das ist ein 4:1-Multiplexer für zwei Signale, könnte also passen. Jetzt müßtest Du nur noch einen Weg finden, wie Du die Umschaltung bewerkstelligen kannst, z.B. über irgend einen FTDI-Chip und ein kleines PC-Tool. Du musst nur aufpassen, dass die Kabellängen der PDI-Ports nicht zu groß werden. fchk
Blos weil mal einer Probleme mit dem PDI Port hatte heist es ja nicht das es nicht möglicht ist. Immerhin hat er es dann ja auch geschafft. Ich habe das AVR 1612 Paper bei mir auf den Tisch liegen und das PDI sieht jetzt nicht ungewöhlich kompliziert aus.
Der FTDI besitzt 4 CBUS Leitungen damit kann man den Mulitplexer dann schalten
Johann schrieb: > Mein Chef hat mich nun beauftragt das die XMEGA µC über das USB > Interface programmierbar sein müssen. Zeig mal, dass Du das Geld wert bist, welches Dein Chef in Dich investiert.
Johann schrieb: > Blos weil mal einer Probleme mit dem PDI Port hatte [...] Deine Ignoranz/Arroganz ist noch größer als deine Ahnungslosigkeit. Warum fragst du eigentlich erst in einem Forum nach, um dann sowieso alles besser zu wissen? > [...] heist es ja nicht > das es nicht möglicht ist. Das hat auch keiner behauptet. (Im Gegenteil: Dean Camera hat es gemacht, sehr wahrscheinlich als erster.) Aber die Welt ist nicht so einfach, wie du sie dir denkst. AVR Studio kümmert sich einen Schei*** um das PDI. Das ist Aufgabe des AVRISPmkII. Folglich müsstest du dir dein eigenes AVRISPmkII nachbauen (das ist letztlich das, was Dean Camera gemacht hat) oder direkt ein solches verbauen. Ein USB-Seriell-Wandler von FTDI nützt dir dabei herzlich wenig, mit der Ausnahme vielleicht, dass man über dessen GPIO-Pins die 3-Wege- Umschaltung organisieren könnte.
Ich muss mir sicherlich die PDI Doku noch mal genauer durlesen, jedoch sendet man doch z.B. den schreib in den Flash bei Adresse X und dann sendet man auch gleich danach die Daten. Der AVR erhöht dann automatisch den Adresszeiger so das man nur die Daten anschließend neu schreiben muss. Der FTDI Chip war nicht ganz mein Vorschlag sondern kam auch von einem anderen User. Meine Hauptaufgabe ist nicht diesen Bootloader zu schreiben, sondern nur sicherzustellen das die beste und vor allem zuverlässigste Lösung implementiert wird. Dies ist nur ein kleines Nebenprojekt. Und ich denke das die LUFA-Lib in meinen Augen überhaupt nicht dazu zählt. Da sitzt ein Programmieren in einem kleinen Zimmer und werkelt vor sich hin. Was passiert wenn plötzlich doch ein Fehler auftritt dann kann ich nur hoffen das er diesen findet. Vielleicht hat er auch nach 1 Monat keine Lust mehr und Lufa wird nie wieder weiter entwickelt oder er bricht sich eine Arm. Ich habe einen Linux Sat Receiver zu hause. Dieser wurde auch von einer kleine Gemeinschaft gepflegt ist ist in einem total schlechten Zustand und keiner hat mehr Lust die Firmware weiter zu schreiben.
Johann schrieb: > Und ich denke das die LUFA-Lib in meinen Augen überhaupt nicht dazu > zählt. Dean Camera ist mehr als nur LUFA. Unter anderem war er zumindest zeitweise (oder ist möglicherweise noch) Contractor für Atmel in Trondheim. Du darfst ihm also ein gewisses Maß an Einblick zutrauen. Außerdem hast du ja den Sourcecode, insofern bist du nicht auf ihn persönlich dafür angewiesen. Aber mach' ruhig, was du denkst. Ich klink' mich dann mal aus. Deine Besserwisserei geht mir auf den Senkel.
Ich weiß nicht wieso Du mich immer der Besserwisserei beschuldigst. Blos weil DU DEINE Lösung durchdrücken möchtest. Ich habe nur die Nachteile Deiner Version aufgeführt, die ich auch berücksichtigen muss.
Ich habe für die Umsetzung nicht mal 1 Woche Zeit, daher werde ich keine Variante benutzen wo ich selber noch basteln muss. Sondern eine Varinate auswählen die dann auch in der vergegebenen Zeit funktioniert. Und meistens kostet diese Lösung auch Geld.
Johann schrieb: > Ich habe für die Umsetzung nicht mal 1 Woche Zeit, Dann mach Überstunden und schreib nicht so viel in Foren herum. Johann schrieb: > Sondern eine Varinate > auswählen die dann auch in der vergegebenen Zeit funktioniert. If Gehirn Then Gehirn=1 Johann schrieb: > Und > meistens kostet diese Lösung auch Geld. Willkommen in der realen Welt.
Johann schrieb: > Blos > weil DU DEINE Lösung durchdrücken möchtest. Ich will nicht "meine Lösung durchdrücken". Aber mach mann, du weißt ja, was du tust. (Im Gegensatz zu mir, ich habe inzwischen nciht einmal mehr eine Vorstellung, was du dir gerade vorstellst.)
Da du ja nur eine Woche Zeit hast. Kaufst du dir ein paar simple USB to TTL Uart Wandler. Gibt es in 1000 Varianten bei Ebay. Dann liest du das hier und setzt es um. http://www.atmel.com/Images/doc8242.pdf Alles andere ist ja gar nicht zu schaffen in einer Woche.
>> Ich muss ja an der RX und TX Leitung 3 µC anschließen. Ist dies >> überhaupt sinnvoll? Drei UART parallel sollte hier funktionieren (vielleicht ein paar kleine Widerstände in Reihe). Während eines normalen Start muss USBseitig Ruhe sein. Die Megas führen den Bootloader aus an dessen Ende Die UARTPins hochohmig werden und die UART abgeschaltet wird. Zum flashen alle drei im Reset halten (die Pins sind jetzt hochohmig) einen freigeben und anfangen zu flashen. Sollte eigentlich funktionieren. Als kleines Gimmick kann man jetzt auch die XMEGAs gezielt resetten falls nötig. Ansonsten kam ja auch schon der Hinweis zu Bus-Multiplexern. Stefan
@ Jörn B. Ich habe alles noch mal überdacht. Ich könnte einen XMEGA U Mikrocontroller direkt an den USB Hub anschließen. Jedoch denke ich das die USB Kommunikation und das Schreiben der PC Software in einer Woche schwer zu realisieren ist. Zudem muss man dazu noch das PDI Interface programmieren. Daher bevorzuge ich folgende Lösung: Ich nehme eine USB zu RS232 Converter. Das RS232 Signal gebe ich dann auf einen kleinen ATMEL µC wahrscheinlich so ein XMEGA 32 mit möglichst kleinem Gehäuse. Somit umgehe ich die USB Kommunikation. Die RS232 Konverter vom FTDI habe ich schon sehr häufig verwendet, daher komme ich da zeitlich sehr schnell vorwärts. Eine RS232 Empfangsroutine mit CRC16 Checksumme habe ich bereits auch schon fertig, so das ich dort auch kaum Arbeit investieren muss. Demnach muss ich "nur" noch die PDI Schnittstelle programmieren. Hier wäre es schön wenn es von Atmel ein C-File gibt das die PDI über eine RS232 Schnittstelle ansteuert, so das ich "nur" noch die Funktionen aufrufen muss
Du mit deinem PDI Mach es doch über den ganz normalen UART des XMEGA wie es von ATMEL vorgesehen ist. Dafür gibt es von ATMEL einen fertigen Bootloader. Wenn es so einfach über PDI wäre dann bräuchte niemand ein "teures" Programmiergerät. Wenn du so weiter machst steht du in einer Woche genauso dar wie jetzt. Mit nichts.
Johann schrieb: > Demnach muss ich "nur" noch die PDI Schnittstelle programmieren. Musst Du nicht. Wenn Du einen Bootloader hast, können alle XMEGAs zeitgleich über eine USB-UART geflasht werden. Oder auch zeitversetzt mit Adressen und verschiedenen Hex-Files. Johann schrieb: > Ich nehme eine USB zu RS232 Converter. Ja. Johann schrieb: > Das RS232 Signal gebe ich dann > auf einen kleinen ATMEL µC Nein. Das UART-TX schließt Du an alle XMEGAs an einen UART-RX-Pin. Johann schrieb: > Eine RS232 Empfangsroutine mit CRC16 Checksumme habe ich bereits Kannst Du Dir schenken. Der Bootloder kann (wenn Du es kannst) direkt mit hex-Files arbeiten und diese auf Validität prüfen, während die Daten in´s Flash geschrieben werden. XMEGAs mit CRC-Modul können anschließend nochmal das Flash auf korrekte Daten prüfen, wenn nötig. Jetzt kannst Du anfangen, Du hast noch 4 Arbeitstage und ein Wochenende.
Knut Ballhause schrieb: > Johann schrieb: >> Ich nehme eine USB zu RS232 Converter. > > Ja. Nimmt er nicht, es sei denn du möchtest den Umweg über einen Pegelwandler nehmen.
ich dachte das gerät hat bereits eine USB-SChnittstelle? Irgend ein Controller muss diese doch bedienen. Kann man den nicht auch benutzen, um die Firmwares an die XMegas zu verteilen? http://www.chip45.com/avr_bootloader_atmega_xmega_chip45boot2.php bietet vorkommpilierte Hexfiles für xmegas, die ein extrem einfaches Interface haben. man schickt denen direkt das hexfile. Das heißt man könnte somit auch ganz einfach ohne viel Aufwand den Hauptcontroller zum Programmieren benutzen
Wieso soll ich denn bitte schön noch einen Pegel Wandler benutzen? Die FTDI erzeugen doch einen 3.3V Datenstrom, der ideal zum µC passt. Momentan sind alle meine 3 µC über einen seperaten USB auf RS232 Converter am PC angeschlossen. Demnach muss ich nur einen RS232 Bootloder für einen XMEGA benutzen und die Sache funktioniert dann? Ich dene mal das ich noch den Reset Pin beschalten muss damit der Bootloader gestartet wird oder sehe ich das falsch.
>> Demnach muss ich "nur" noch die PDI Schnittstelle programmieren. >> Hier wäre es schön wenn es von Atmel ein C-File gibt das die PDI über >> eine RS232 Schnittstelle ansteuert, so das ich "nur" noch die >> Funktionen aufrufen muss. Du hast jetzt einen FTDI und noch einen XMEGA. Warum noch ein _X_mega? Jeder deiner µC mit 6 freien Pins lässt sich als Multiplexer nutzen! Warum nicht einfach den (bzw. falls möglich einen) XMEGA als Multiplexer nutzen und einfach das HEX über RS232 an einen Bootloader senden? Was Fertiges ist wohl zu einfach? Wenn es aber unbedingt PDI sein muss... Ich bin auch raus. Stefan
Ich muss mir die XMEGA RS232 BOOTLOADER mal genauer anschauen. Kann man bei dem Bootloader einstellen welche RS232 Schnittstelle verwendet werden soll? Diese Lösung hör sich doch am besten an da muss ich auch am wenigsten machen :-)
>> Ich muss mir die XMEGA RS232 BOOTLOADER mal genauer anschauen. >> Kann man bei dem Bootloader einstellen welche RS232 Schnittstelle >> verwendet werden soll? Ja. Der Bootloader ist ein kleines 'Extra-Programm' in einer eigenen Section des Flash das vor dem Start des eigentlichen Programm ausgeführt wird. Was es machen soll bestimmst Du. Vergiss nicht die Fuses lt. Datenblatt zu setzen! >> Diese Lösung hör sich doch am besten an da muss ich auch am wenigsten >> machen :-) Na ja, da waren wir aber schon kurz nach elf ;-) Stefan
Kann man de PDI Bootloader auch zerstören oder ist dieser schreibgeschützt?
Johann schrieb: > Wieso soll ich denn bitte schön noch einen Pegel Wandler benutzen? Die > FTDI erzeugen doch einen 3.3V Datenstrom, der ideal zum µC passt. Genau weil du keinen USB zu RS232 Wandler benutzt. Sondern USB zu UART TTL. Oder benutzt du so was? http://www.ebay.de/itm/USB-RS-232-Konverter-Kabel-RS232-Kompaktadapter-Premium-Adapter-DB-9-SAT-Update-/251106240947?pt=DE_Computing_Monitor_AV_Kabel_Adapter&hash=item3a771929b3
Johann schrieb: > Kann man de PDI Bootloader auch zerstören oder ist dieser > schreibgeschützt? Klar, leg mal 230 V an den PDI Eingang :D
>> Kann man de PDI Bootloader auch zerstören oder ist dieser >> schreibgeschützt? Nein, zerstören kannst Du nur etwas das existiert! Stefan
@ Jörn B Nein ich nutze nicht so etwas von Ebay sondern dies hier: http://www.ftdichip.com/Products/ICs/FT232R.htm
@ Stefan der PDI Bootloader existiert ja auch, sonst könnte ich über dieses Interface ja auch keine Daten auch den XMEGA hochladen. Wenn ich jetzt einen eigenen Bootloader schreibe oder den RS232 Bootloader von Atmel benutze bleibt dann der PDI Bootloader noch auf den XMEGA oder überschreibt man diesen dann?
@ Jörn. Die XMEGA laufen mit 3.3V die FTDI USB auf RS232 Converter erzeugen ebenfalls einen 3.3V CMOS Pegel und kein 5V TTL Pegel, daher kann man diese Converter direkt mit dem XMEGA ohne Pegel Converter verbinden
Johann schrieb: > Wenn ich jetzt einen eigenen Bootloader schreibe oder den RS232 > Bootloader von Atmel benutze bleibt dann der PDI Bootloader noch auf den > XMEGA oder überschreibt man diesen dann? Wann kapierst du endlich, dass es keinen PDI Bootloader gibt?! PDI ist eine HARDWARE-Schnittstelle. Gruß Marius
Ich denke gerade darüber nach, dass der Chef gut beraten wäre, sich bis nächsten Donnerstag noch eine Fallback-Lösung einfallen zu lassen...
>> Wenn ich jetzt einen eigenen Bootloader schreibe oder den RS232 >> Bootloader von Atmel benutze bleibt dann der PDI Bootloader noch auf >> den XMEGA oder überschreibt man diesen dann? Hatte Jörg schon gestern früh beantwortet : /Zitat Das ist kein Bootloader (Software), sondern das macht die Hardware selbst. /Zitat >> die FTDI USB auf RS232 Converter erzeugen ebenfalls einen 3.3V >> CMOS Pegel und kein 5V TTL Pegel na ja kommt drauf an was man mit was verbindet, die können auch 5V. >> Ich denke gerade darüber nach, dass der Chef gut beraten wäre, sich bis >> nächsten Donnerstag noch eine Fallback-Lösung einfallen zu lassen... Die µCs sockeln und dann einen kleinen Roboter .... ;-) Stefan
Stefan schrieb: > Die µCs sockeln und dann einen kleinen Roboter .... ;-) > > Stefan Der XMEGA wird, in diesen Falle leider, nicht mehr im DIP Sockeln gefertigt ;)
Der PDI Bootloader sorgt dafür das ich den Flash und den EEPROM überschreiben kann. Der Softwarebootloader macht nichts anderes nur das ich selbst progerammiere über welche Schnittstelle ich die Daten erwarte. Anschließend muss ich die Daten auch in den FLASH oder EEPROM schreiben. Hinter den 2 PDI Ports wird auch ein Softwarebootloader stecken, der die empfangenen Befehle erkennt und verarbeitet. Die Frage ist halt ob ich diesen berschreiben kann oder ob dieser Bereich schreibgeschützt ist. Daher sind beides Bootloader. P.S. Ich liege sehr gut im Zeitplan :-)
Johann schrieb: > Hinter den 2 PDI Ports wird auch ein Softwarebootloader stecken, der die > empfangenen Befehle erkennt und verarbeitet. Mit Sicherheit nicht. Bedenke: Du kannst über PDI die CPU auch anhalten, Register auslesen und setzen, Breakpoints setzen etc. Das könntest Du nicht, wenn das Software wäre. Und dass die CPU tatsächlich steht, kann man anhand des Stromverbrauchs nachweisen. Das ist alles hartverdrahtete Logik, Hartware also. fchk
Frank K. schrieb: > Mit Sicherheit nicht. Ach was. Du brauchst Johann nicht mit rationalen Argumenten kommen.
Es geht übrigens auch ohne die Hardware eines USB/UART-Umsetzers oder spezielle USB-COntroller, siehe hier: http://www.fischl.de/avrusbboot/ und hier: http://www.obdev.at/products/vusb/usbasploader.html
Im übrigen, falls hier jemand Langeweile hat, ich hätte da noch ein paar nette Projekte wo man seine Kreativität sinnvoll einsetzen könnte :D
Jörg schrieb: >Eine 32 bit ARM MCU mit 176 Pins gibt es zwischen 10 und 20 Euro. >Die hätte dann 168 MHz, USB, I2C, Can, SPI und vieles mehr... Vielleicht läßt sich mit mehreren Prozessoren die gestellte Aufgabe einfach besser erüllen. Das Steuerteil für das Lego-Roboter-System hat z.B. auch zwei Prozessoren eingebaut, nen ARM (AT91SAM7S256,48MHz) für die höhere Intelligenz und nen ATMega48 für die Ansteuerung der Motoren und so. (Ganz schick das Teil, hat auch ne Menge Schnittstellen(Bluetooth,USB,I²C,RS485), habe aber noch nie so richtig was damit gemacht.) Sabine
>> Es geht übrigens auch ohne die Hardware eines USB/UART-Umsetzers oder >> spezielle USB-COntroller Es geht ... aber es geht nicht sonderlich gut. Stefan
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.