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?
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?
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
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.
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
@ 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
>> 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
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
