Hi @ all Ich möchte gerne einen Bootloader für den Mega128 schreiben. Anbindung über USB (FT245BM). Als Dateiformat sende ich eine Hex File. Kann ich direkt Byte für Byte des Hex Files in den Flash des AVRs kopieren?? Wieviel RAM kann der AVR verwenden wenn das Programm in der Bootloader Section liegt. Soviel wie der AVR hat?? Leider verwende ich Interrupts für das Handshake des USB Chips. Irgendwie muss ich die Interruptsprungtabele verschieben, habe ich gelesen. Wie funktioniert das genau? Besten Dank im Voraus mfg Martin
hallo, zu frage 1: klaro. zu frage 2: afaik soviel wie da. zu frage 3: rtfm :) steht da schön drin bei der irq-beschreibung (recht weit vorne im wälzer). beispiel (andere mcu):
1 | /*!
|
2 | * \brief Enable irq vector change.
|
3 | *
|
4 | * Enables interrupt vector change by setting the appropriate bits.
|
5 | */
|
6 | static inline void enable_irq_vector_change(){ |
7 | MCUCR |= (1<<IVCE); |
8 | }
|
9 | |
10 | /*!
|
11 | * \brief Switch irq vector table to bootloader section.
|
12 | *
|
13 | * Switch interrupt vector table to bootloader section.
|
14 | * Performs actions as described at page 64 of documentation.
|
15 | */
|
16 | static inline void change_irq_vector_to_bl(){ |
17 | uint8_t mcucr_save = MCUCR; |
18 | enable_irq_vector_change(); |
19 | MCUCR = mcucr_save | (1<<IVSEL); |
20 | }
|
hth, bye kosmo
achja, frage 1: byte für byte schreiben ist so nicht, habe ich missverstanden. musst schon das bootloader-prozedere befolgen, steht auch im manual oder siehe avr-libc oder siehe viele viele bootloader-implementationen.
Ich habe zu genau dem Thema auch ein paar Fragen und ich denke es passt hier vielleicht rein. Also ich habe ein HEX File in dem zB dies hier drinsteht: :10 0000 00 12C02BC05BC04AC039C027C026C025C0 63 :10 0010 00 24C023C022C022C020C01FC01EC01DC0 DB :10 0020 00 1CC01BC01AC011241FBECFE5D4E0DEBF 28 :10 0030 00 CDBF10E0A0E6B0E0E6E1F0E102C00590 3F :10 0040 00 0D92A036B107D9F710E0A0E6B0E001C0 EC :10 0050 00 1D92A036B107E1F738C1D2CF1F920F92 9F :10 0060 00 0FB60F921124CF93DF93CDB7DEB7DF91 98 :10 0070 00 CF910F900FBE0F901F9018951F920F92 67 ... Ich habe die Zeilen etwas auseinandergerückt. Wenn ich die Spezifikation von Intel da richtig verstanden habe, dann ist 10 die Länge der Bytes im Datenfeld hier also 16 (dez). Danach folgen 2 Byte für die Anfangsadresse des Datenblocks. Jetzt der Datentyp also 00 bedeutet hier Daten. Nun 16Byte Daten und am Ende ein Byte Checksumme. Ist das soweit richtig? Wenn ich nun einen Bootloader bauen möchte, dann würde ich gerne diese boot_program_page (uint32_t page) Beispielfunktion verwenden. Ich dachte mir das in etwa so: Ich lege einen Buffer an der 64 Byte groß ist. Lese sozusagen 4 Zeilen aus dem Hexfile in den Buffer und rufe dann diese boot_programm_page Funktion auf. Meine Frage ist nun aber, was muss ich als page übergeben? Ist das immer der Offset aus dem Hexfile für die nächsten 65 Byte? Also bei den ersten 64 Byte 0x0000 beim zweiten schreiben dann 0x0040 usw? Vielen Dank schonmal Gruß Philipp
>Ist das soweit richtig? Ja (zumindest habe ich Intel-HEX bis jetzt auch so verstanden). Ist der Bootloader-Schreibvorgang nicht mit einer bestimmten Blocklänge verbunden? >Ist das immer der Offset aus dem Hexfile für die nächsten 65 Byte? Also >bei den ersten 64 Byte 0x0000 beim zweiten schreiben dann 0x0040 usw? Im Prinzip schon. Wenn du allerdings Adress-Sprünge (aus welchen Gründen auch immer) in der HEX-Datei hast, läuft dein Verfahren schief. (Ist zwar unwahrscheinlich, aber möglich...) Besser wäre es dann wohl, immer nur eine Zeile auszuwerten und zu schreiben.
Ja aber man muss ja immer 64Byte (eine Page) auf einmal schreiben, so wie ich das verstanden habe, deshalb braucht man auch den Buffer usw. Wenn dann müsste man bei einem Sprung (wo kann sowas passieren?) den Rest irgendwie auffüllen. Oder hab ich da was falsch verstanden?
Versteht sich eigentlich von selbst, daher duerfte dieser Beitrag ueberfluessig sein: Du musst natuerlich die Bytes auch noch vom ASCII-Hex Format in's Binaerformat wandeln. Hebbe.
>@Herbert worauf bezieht sich das nun? Darauf: >> Kann ich direkt Byte für Byte des Hex Files in den Flash des AVRs >> kopieren?? Die Formulierung legt nahe, dass der OP die Bytes direkt so, wie sie ueber dir Leitung kommen, in's Flash schreiben moechte (Annahme: Es findet keine Hex-Binaerwandlung auf PC Seite statt, was wohl halbwegs unsinnig waere)
Jetzt weiß ich schon mehr :) Einige Fragen hab ich noch ;) Also wie genau wird die CRC des Intel HEx Formates gebildet?? Zur Hex Binär Wandlung. VErstehe ich das richtig. ICh wandler die 2er Hex Zahlen in Dezimale Zahlen um, fülle damit die Bootpages und sende die dann über die Schnittstelle, oder?? >>Ist das immer der Offset aus dem Hexfile für die nächsten 65 Byte? Also >>bei den ersten 64 Byte 0x0000 beim zweiten schreiben dann 0x0040 usw? >>Im Prinzip schon. Wenn du allerdings Adress-Sprünge (aus welchen Gründen >>auch immer) in der HEX-Datei hast, läuft dein Verfahren schief. (Ist >>zwar unwahrscheinlich, aber möglich...) Das werde ich einbeziehen... Gruß Martin
So jetz weiß ich mehr. Bzw ích vermute es ;) Also die CRC ist die Summer der Reste jedn Bytes bei einer Division durch 256. Sprich Summer von Moduko 256 bei jedem Byte. Stimmt das so?? Gefunden hab ich das hier: http://www.schulz-koengen.de/biblio/intelhex.htm Unten sind auch Beispiele. Bei dem 2. Beispiel (Datenbytes sind alle auf 0) komme ich aber nicht auf die CRC. Nach meiner Methode komme ich auf 0x41. Stimmt das? Danke im Voraus Gruß Martin
Das mit dem 2er Komplement werd ich auch gleich mal nachrechnen, ein sehr guter Link :) Was mir noch nicht ganz klar ist: Kann ich an die boot_programm_page() Funktion die Startadresse der Daten übergeben, oder werden die Pages einzeln durchnummeriert? Also Page 1, 2 , 3 zB mit je 64 Byte oder übergebe ich als Page Adresse dann zB 0x0040 für die 2. Page weil es ja die nächsten 64 Byte (oben hatte ich irgendwo 65 stehen, sollte natürlich 64 sein) sind? Und auch nochmal zu dem angesprochenem Sprung: Sollte es nun wirklich in dem Hex File mal so einen Sprung geben, füllt man dann Raum zwischen den Adressen mit 0xFF? (Man muss ja die Page irgendwie beschreiben) @Martin, ich hoffe es stört dich nicht, das ich in deinem Thread einfach so mit rumfrage, aber ich denke wir stehen vor den gleichen Problemen :) Vielen Dank schonmal Gruß Philipp
> Also die CRC ist die Summer der Reste jedn Bytes bei einer Division > durch 256. Sprich Summer von Moduko 256 bei jedem Byte. Stimmt das so?? Das klingt reichlich kompliziert. Du zählst einfach alle Bytes zusammen, wobei du eventuelle Überläufe der Summe von einem Byte ins nächste ignorierst. Du rechnest einfach alles mit 8 Bit (In Assembler: in einem Register die Summe bilden und ein eventuelles Carry bleibt aussen vor. In C: die Summe ist ein uint8_t bzw. unsigned char) 1. Zeile 10 + 00 + 50 + 00 + 69 + 73 + 20 + 70 + 72 + 6F + 67 + 72 + 61 + 6D + 20 + 63 + 61 + 6E + 6E + 6F = 683 Da wir aber nur mit Bytes rechnen: 83 Die Prüfsumme ist daher das 2er Komplement davon: FF - 83 + 1 = 7D Der Sinn der Berechnung des 2er Komplements besteht darin, dass, wenn ich die Prüfsumme in der Addition auch noch mit dazu nehme, immer 0 rauskommt. 83 + 7d = 100. Wir rechnen aber im 8 Bit Raum und ignorieren alle Überträge: Also 00 2. Zeile 10 + 11 + 20 + ein ganzen Haufen 0 = 41 Die Prüsumme ist das 2 er Komplement: FF - 41 + 1 = BF Beim Testen: 10 + 11 + 20 + ein ganzer Haufen 0 + BF = 100, also 00 -> passt In Assembler rechnest du das 2 er Komplement natürlich nicht wie oben aus. Viele Prozessoren haben einen Befehl dafür. Wenn nicht, dann haben sie einen Befehl für das 1er Komplement (alle Bits umdrehen) gefolgt von einem inc auf das Register. Gibt es auch kein 1er Komplement, dann macht man einen XOR mit FF, gefolgt vom inc In C würde man wohl auch schreiben: Pruef = ~Summe + 1; oder ganz einfach: Pruef = -Summe; Besonders in der letzten Formulierung ( Pruef = -Summe ) sieht man sehr schön, warum da am Ende 0 rauskommen muss. Die Prüfsumme wird geerade so konstruiert, dass sie die Differenz zu 0 ist.
hallo, >Was mir noch nicht ganz klar ist: Kann ich an die boot_programm_page() >Funktion die Startadresse der Daten übergeben, oder werden die Pages >einzeln durchnummeriert? Also Page 1, 2 , 3 zB mit je 64 Byte oder >übergebe ich als Page Adresse dann zB 0x0040 für die 2. Page weil es ja >die nächsten 64 Byte (oben hatte ich irgendwo 65 stehen, sollte >natürlich 64 sein) sind? woher hast du die routine boot_programm_page()? da sollte zu erfahren sein, wie das zu machen ist.
Ich habe diese Funktion identisch in einigen Bootloader gesehen und als ich danach gegoogelt habe, habe ich dies hier gefunden: http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html Leider kam dieser Übergabewert immer von der Gegenseite des Bootloaders in den Beispielen, die ich gesehen habe, deshalb weiß ich nicht was dort eingestzt wurde. Und auch in der Beschreibung aus dem Link hier werde ich nicht schlau. Hat jmd einen Hinweis für mich? Diese Funktion würde ich auch gerne benutzen. Vielen Dank Gruß Philipp EDIT: Hmm, wo ich mir die Funktion nochmal so ansehe, da wird die Adresse ja bei jedem Byte inkrementiert. Dann erscheint es vielleicht doch logisch die Adresse des 1. Bytes der Page zu übergeben. Also um bei meinem Beispiel von oben zu bleiben. Bei der 2. Page übergebe ich dann 0x0040 für die 64Byte in meinem Buffer. Sehe ich das richtig?
ah ja, sorry, habe ich überlesen (gedanklich zu weit oben). du nimmst irgend eine adresse aus der page, die du schreiben willst. also meinethalben 0x40. vorher sollte man sich aber einmal schlau machen, wie groß die page auf der mcu eigentlich ist. ich bezweifle einfach mal die 64 byte, aber mag ja sein. hängt vom controller ab. ist dein puffer kleiner als die page, hast du ein problem, da die routine die page vorher platt macht. das kann man sicher ändern :) oder aber den puffer so anpassen, das die page beim flashen nie wieder angefasst wird. letzteres ist meiner meinung nach ein wenig unflexibel, aber soll jeder halten wie er mag. wo wird denn die adresse inkrementiert?
Die Adresse wird bei jedem Aufruf von boot_page_fill inkrementiert, also für das Byte (page + i). Zu der Page Grösse befrag ich nochmal das Datenblatt, weiß gar nicht mehr wo ich die 64Byte her hatte. (Ging um den Mega 8) Vielen Dank Gruß Philipp EDIT: Laut S.225 32 Words -> 64Bytes
ok, wir reden von zwei verschiedenen dingen. voraussetzungen: 1. der avr besitzt einen sog. temporary buffer. der ist so groß wie eine page. der inhalt dieses und NUR dieses puiffers wird in eine page geschrieben. das flash-prozedere lautet daher: 1. der temporary buffer muss gefüllt werden. das nennt sich bei atmel "page loading". in der avr-libc nennt sich das boot_page_fill (ist nur ein macro). das füllen geschieht word- weise, deswegen der uint16_t im beispiel der avr-libc. 2. der inhalt des temporary buffers wird in eine page geschrieben. welche page, das hängt vom inhalt des z-pointers ab. die avr-libc fasst die schritte dazu mit dem boot_page_write- macro zusammen. in der doku steht das sehr ausführlich drin, afaik sogar mit einem beispiel, wenn auch in asm.
Achso, die Bootloader die ich bisher gesehen habe, die hatten ein 64 Byte großes Array (dann wohl im RAM), darin wurden die Daten erstmal geschrieben, zB vom I2C kommend. Wenn 64 Byte voll waren, dann wurde diese boot_program_page() aufgerufen. Aber, wenn es so ist wie du sagst, dann kann ich mir doch eigentlich das 64 Byte Array sparen und mit boot_page_fill() direkt die Bytes in diesen Puffer schreiben und nach 64 Bytes einmal boot_page_write() aufrufen. Die page Variable um 64 erhöhen und bei boot_page_fill wieder von vorne anfangen. Oder hab ich das jetzt falsch verstanden? Gruß Philipp
hm, könnte man - meiner meinung nach - auf den ersten blick so bringen. vorsicht ist auf jeden fall geboten, da du den temp buffer nur einmal pro word schreiben kannst. willst du nochmal auf dieses word schreiben, musst du den ganzen puffer kicken (per page write oder rwwscre) und von vorne anfangen (seite 216 doku) die doku vom atmega8 sagt auch, das beim page_write die letzten 6 bit der adresse (also im beispiel von "page") auf 0 sein müssen. d.h. page-aligned vorgehen, 0x00, 0x40, 0x80, 0xC0, 0x100 usw. sorry, da gabs wohl ne änderung zwischendurch.
Das im Ram zwischenzubuffern, hat auch andere Vorteile. Z.b. kann man mit einem Bottloader, der die Dateien entschlüsselt, es gibt so auch recht kleine Verschlüsselungsalgorithmen, getrost ein verschlüsseltes Firmwareupdate rausgeben, ohne daß man das Produkt nachbauen kann und einfach das downloadbare update raufschmeissen kann. Die Erweiterung zu den bestehenden bootloader gibt es, werden nur nicht im Internet zum Download bekanntgegeben.
Ja war auch nur eine Frage zum Verständnis. Ich werde am Donnerstag (leider kann ich nicht früher, obwohl es langsam in den Fingern juckt :) ) mal anfangen zu testen. Das ganze möchte ich für mein Auto haben, um die schlecht zugänglichen Module per CAN zu programmieren (keine Angst ist ein eigener CAN Bus, einen CAN hatte mein altes Auto vorher gar nicht) Wenn ich den Bootloader geschrieben habe, wie sag ich dem gcc eigentlich, dass es ein Bootloader ist und er das Hex File so anlegt, dass zB avr-dude den ganzen Kram in der Bootloader Section ablegt und nicht am Anfang des Flash? Und der Bootloader hat ja eine main() und diesen jump_to_app Kram (der einfach auf Adresse 0x0000 springt) Muss ich vorher noch etwas beachten oder kann ich (wenn ich die IRQs nicht umgebogen habe) einfach jederzeit aus meinem Bootloader in die normale App springen? Dann könnte ich mir das doppelte initialisieren des MCP2515 sparen, weil das ja schon der Bootloader erledigt hat. Und muss in der App danach noch etwas beachtet werden oder kann ich die so programmieren wie früher auch mit einer main() usw? (zweimal main() sollte ja egal sein, weil es ja woanders liegt) Vielen Dank schonmal Sorry das es so blöde Fragen sind, aber ich habe bisher keine Antworten dazu gefunden. Gruß Philipp
Also, bei den bootloadern über i2c, can usw. ist es üblich, daß die Applikation zum Bootloader springt, nicht umgekehrt. Dies ist darin begründet, daß das modul nur über ein Netzwerk erreichbar ist, eben nicht direkt. Üblicherweise haben die eine fixe serielle number, die Eindeutig ist, z.B jahr,monat,tag,id als 32bit nummer sowie eine kleinere 16bit Random sowie eine 8bit priorität und eine 8bit produktnummer, mit der gewisse Verhalten gesteuert werden, die dann nötig sind, um so ein Netzwerk von unprogrammierten Modulen gleichzeitig in kurzer zeit über das Netzwerk zu lokalisieren, steuern und uploaden. Es kann noch einen hw-jumper geben, wobei dann der bootloader einspringt, aber die ist eigentlich nur für den absoluten Fehlerfall.
Naja die CAN Funktionen brauche ich ja eh in der Anwendung und in dem Bootloader. Ich dachte mir aus Sicherheitsgründen startet es ganz normal wie die seriellen Bootloader mit dem Bootloader, so ist sichergestellt, dass ich das Modul immer flashen kann notfalls indem ich kurz den Strom unterbreche (Jumper ist schlecht, weil zB je ein Modul in der Tür ist da müsste ich zum Jumpern die Türverkleidung entfernen). Den Bootloader wollte ich vom Programm anspringen, indem ich über eine CAN Nachricht das Modul in eine Endlosschleife springen lasse und so der Watchdog das Modul neustartet. Oder gibt es weitere Gründe den Bootloader aus der Applikation anzuspringen und diesen nicht beim start anzuspringen? Gruß Philipp EDIT: Der Bootloader muss dafür natürlich direkt pro Modul ansprechbar sein.
Und was ist, wenn das Modul aufgrund eines Fehlers/EMF/... per Watchdog rebootet, kann dann das Modul und der Flash korrumpiert werden ? Weiters, wenn du mehrere module hast, und du den Strohm wegnimmst, dann kannst du nicht alle gleichzeitig Flashen. OK, die haben eine eindeutige CAN-Addresse, aber was, wenn das neue Firmware nicht funkt und den WDT aktualisiert. Dann musst du einen cold-reset machen, und alle module wollen neu geflasht werden.
Bootloader für mega8 und mega32 über CAN gibt es bei dem HCAN projekt. Solltest dir mal ansehen.
Warum sollte ich nicht alle gleichzeitig Flashen können? Außerdem ist das doch auch nicht notwendig. Ich habe mir vorgestellt, das sie beim starten eine Meldung senden welche Firmware Version sie zur Zeit haben und warum sie resetet haben (das mache ich auch jetzt schon). Darauf bekommen sie vom PC dann entweder den Befehl eine neue Firmware zu empfangen oder ganz normal die Firmware zu starten. Kommt diese Meldung meinetwegen nicht innerhalb von 500ms so starten sie ganz normal die Firmware. Also ein Watchdog reset würde das Modul dann maximal 500ms ausser Gefecht setzen, aber wenn der auftritt läuft eh irgendwas nicht richtig. Wenn das Modul wirklich aufgrund falscher Firmware zwar den Watchdog resetet, aber trotzdem nicht auf CAN Nachrichten hört, dann kann ich immernoch einfach die Sicherung rausziehen und wieder reinstecken. Ich kann doch trotzdem per CAN gezielt einem Modul sagen, dass es nun eine neue Firmware bekommt. Die anderen starten eh nach 500ms neu (falls sie mit an der Sicherung hingen) oder sie bekommen sofort die Nachricht, dass sie normal starten sollen. Habe ich dabei etwas übersehen? Wie gesagt bisher sind das nur meine Gedanken noch läuft es nicht so. Gruß Philipp Edit: Gerade das Szenario mit dem falschen Firmware die den Watchdog trotzdem zurücksetzt spricht IMHO für die Version mit dem starten des Bootloaders beim Reset, denn sonst kann man das Modul ja gar nicht mehr flashen ohne diesen oben erwähnten Jumper. (Denn die falsche Firmware ja auch ignorieren könnte)
Hi! Ich hoffe ich darf mich hier auch einklinken, denn ich habe sehr ähnliche Probleme. Basis bei mir ist ein ATmega32, auch er hat Pages a 64 Bytes. Das mit den Pages ist vollkommen OK und meine Software braucht auch nur in Pages aktualisiert zu werden. Ein Problem habe ich schon gelöst, da man im GCC eigene Segmente definieren kann und daher kann ich Versionsnummern und andere Infos in der letzten Page unter dem Bootloader unterbringen. Ein großes Problem habe ich aber mit dem Bootloader: Entweder muss ich ihn in das Projekt selbst einbinden. Das würde mir helfen, da ich komplexe Serielle Treiber für ein unidirektionales sehr schnelles RS485 Netz nur einmal schreiben brauche und diese auch aus der Cleint-Software nutzen kann. Das würde es aber notwendig machen, ggf. auch den Bootloader selbst austauschbar zu machen. Aus Sicherheitsgründen muss also ein Bootloader-Bootloader ins System. Oder ISP ist angesagt. Macht Spaß bei 100 Modulen pro Schrank und mind. drei Schränken. Ist etwa so nervig, wie das zerlegen und zusammenbauen von Autotüren mit Folienversiegelung. Also die andere Version: Der Bootloader enthält eine abgespeckte Version der RS485 Treiber und ist autark. Also müssen keine Querverweise in der Software auf ihn existieren und nur eine virtuelle Funktion für seinen Ansprung ist nötig. Aber nun kann AVR Studio mit AvrGCC nicht mehr mithalten. Die Summe aller Segmente ist immer der komplette Flash des mega32. Ich finde keine Option dem LD beizubringen, dass mein mega32 nur ein Flash von 0x3800 hat. Wie kann ich das dem Linker beibringen? Ich hab schon gesucht, aber ich sehe es nicht. Die beschriebene Lösung würde auch Philipp helfen, denke ich. Danke im Voraus Ulrich
So hab nun wieder ein paar Fragen ;) Angenommen ich benutze einen Meg128 mit 128kB Flash. Wie schaut das dann im Hex File aus?? Im Hex File kann die Adresse bis FFFF = 64kB gehen. Wie kann man das lösen?? Wie sind die Flashbytes im Ausgangszustand?? Auf 0 oder FF?? Es ist ja sicher sinnvoll, bzw eiin Muss, die restlichen Bytes zu überschreiben, oder?? Mein Bootloader bietet derzeit auch die Option den Flash auszulesen und daraus eine Hexfile erzeugen. Doch derzeit ist das noch umständlich... Denn angenommen ich hab einen Mega128 mit 4kB Code im Flash, dann erzeugt mir mein Programm ein Hexfile das den ganzen Inhalt des Flashs beschreibt. Kann man irgendwo im Avr oder im geflashten Hexfile auslesen wieviel Code sich im Flash befindet?? Kann man beim Avr die ID des jeweiligen Bausteins auslesen?? Gibt es wo eine Tabelle wo man sieht welche ID welcher µC ist?? Danke im Voraus Gruß Martin
Gibt es eine Liste, wo alle Avrs aufgelistet sind, die eine Bootloader Section haben? Gruß Martin
Danke, Und wie siehts mit den ATinys?? Die haben keine? Und AT90er Serie? zB die USB und PWM Reihe? Wie schauts nun aus bei Hexfiles > 64kB?? Kann mann irgendwie per RS232 oder anderswärtig (aber nicht über ISP) die Device ID auslesen? Steht im Avr irgendwo, wie groß die geflashte File ist? Gruß Martin
Hi, hab noch immer keine Lösung gefunden. Weiß da jemand mehr?
hallo, >Und wie siehts mit den ATinys?? Die haben keine? keine ahnung, bei atmel schauen. >Und AT90er Serie? zB die USB und PWM Reihe? die 90er CAN haben. ansonsten: siehe oben. >Wie schauts nun aus bei Hexfiles > 64kB?? schau dir an, wie hex-files aufgebaut sind. google ist dein freund. z.b. da: http://en.wikipedia.org/wiki/Intel_HEX meines wissens nach wird ein "02, Extended Segment Address Record" verwendet, wenn man bei 'FFFF' ankommt, und dann geht's wieder bei '0000' los. hab aber grad kein beispiel-hex-file parat, aber schon mal gesehen sowas. >Kann mann irgendwie per RS232 oder anderswärtig (aber nicht über ISP) >die Device ID auslesen? das soll nicht gehen. >Steht im Avr irgendwo, wie groß die geflashte File ist? nicht dass ich wüsste, und warum sollte es auch. bye kosmo
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.