Hi, kennt jmd. einen Trick, wie ich zur Laufzeit rauskriege, auf welchem ATtiny mein Code gerade läuft? Idealerweise die Signatur erkennen, die den Knirps ja modellmäßig identifiziert. Dann könnte ich im Setup-Teil meines Codes, wo ich Ports und Timer definiere, Fallunterscheidungen machen und dann mit einer einzigen Codebasis auf mehreren (im kleinen Rahmen) verschiedenen MCU agieren. Das wäre schon praktisch. VG, Jan.
:
Verschoben durch User
Google Suche sagt: http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html#gaf375d2543ba38dc56697b4f4bc37a717 boot_signature_byte_get http://stackoverflow.com/questions/12350914/how-to-read-atmega-32-signature-row Das funktioniert aber nur auf wenigen µCs, die das Bit "SIGRD" im "SPMCR" haben. Selber versucht hab ichs noch nicht, scheint auch nur von sehr wenigen Controllern offiziell unterstützt zu sein.
Du bist mir ein Lustiger! Und für welchen willst Du dann compilieren? Gruss Chregu
Tr schrieb: > Google Suche sagt: > http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html#gaf375d2543ba38dc56697b4f4bc37a717 > > boot_signature_byte_get > > http://stackoverflow.com/questions/12350914/how-to-read-atmega-32-signature-row > > Das funktioniert aber nur auf wenigen µCs, die das Bit "SIGRD" im > "SPMCR" haben. Selber versucht hab ichs noch nicht, scheint auch nur von > sehr wenigen Controllern offiziell unterstützt zu sein. Ah, das sieht vielversprechend aus. In die Richtung grabe ich weiter. Danke hierfür (und sorry, daß ich nur hier im Forum gesucht habe :-o )
Christian M. schrieb: > Du bist mir ein Lustiger! Das stimmt! Erstaunlich, wie schnell Du das erkannt hast ;) > Und für welchen willst Du dann compilieren? > Gruss Chregu Ich gebe die MCU im Makefile an. Oder, wenn manuell, eben im Compileraufruf. Der Code bliebe in diesen untersch. Fällen der gleiche, was einiges in der Versionsverwaltung erleichtert.
> Ich gebe die MCU im Makefile an. Oder, wenn manuell, eben im > Compileraufruf. Dann kannst Du die Geräteunterscheidung aber auch zur Compilezeit machen. Das spart viel Arbeit.
Jan R. schrieb: > Der Code bliebe in diesen untersch. Fällen der gleiche, was einiges in > der Versionsverwaltung erleichtert. Trag hier mal nicht so dick auf. Wozu braucht jemand, der so einen Unsinn vorhat, eine Versionsverwaltung? Schon mal was von bedingter Kompilierung gehört?
Thomas E. schrieb: > Schon mal was von bedingter Kompilierung gehört? Ich nehme an, dass er EIN Binary für mehrere Controller haben möchte. Bedingte Kompilierung fällt dann also aus. Sobald man die ID lesen kann, ist das kein Problem mehr. Edit: Das einzig pfriemelige ist, dass evtl. funktionsgleiche Register an unterschiedlichen Adressen stehen und man sie deshalb von Hand (also per Adresse) im Programmcode eintragen muss. Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > Ich nehme an, dass er EIN Binary für mehrere Controller haben möchte. > Bedingte Kompilierung fällt dann also aus. Nein: Jan R. schrieb: > Ich gebe die MCU im Makefile an. Oder, wenn manuell, eben im > Compileraufruf.
Jan R. schrieb: > Ich gebe die MCU im Makefile an. Oder, wenn manuell, eben im > Compileraufruf. > > Der Code bliebe in diesen untersch. Fällen der gleiche, was einiges in > der Versionsverwaltung erleichtert. Aber wozu dann zur Laufzeit erkennen? Zur Compilezeit reicht doch völlig aus.
Jan R. schrieb: > Ich gebe die MCU im Makefile an. Oder, wenn manuell, eben im > Compileraufruf. Dann mach die unterschiedliche Pin-Konfiguration und sonstige unterschiedliche Konfiguration ebenfalls per #ifdef bereits zur Compilezeit. Das spart nicht nur Entwicklungszeit und Nerven sondern auch Laufzeit und Flash.
:
Bearbeitet durch User
Jan R. schrieb: > Dann könnte ich im Setup-Teil meines Codes, wo ich Ports und Timer > definiere, Fallunterscheidungen machen und dann mit einer einzigen > Codebasis auf mehreren (im kleinen Rahmen) verschiedenen MCU agieren. > Das wäre schon praktisch. Praktisch für was ? So einen Blödsinn habe ich schon lange nicht gelesen... Wie willst du etwas zur Laufzeit definieren wenn es sich auf verschiedenen Adressen befindet ? Da müsste dann Code für alle Tinys compiliert sein und vor jeder Ausgabe müssten dann mehrere Abfragen erfolgen, dementsprechend die Adresse ausgewählt werden, die Ports müsste man mit Adresse und nicht mit Namen ansprechen - das soll praktisch sein ?
Der Tiny kann keinen dynamisch nachgeladenen Code (ohne Flash-Neuprogrammierung) ausführen, weil AVR eine Harvard-Architektur ist. Damit steht bereits zur Compilezeit fest, welchen Tiny du benutzt und du kannst dir die Laufzeiterkennung sparen. Wenn du den Flash neu programmieren willst, dann lasse den vorhandenen Bootloader eine Signatur ausgeben. Ist einfacher.
S. R. schrieb: > Der Tiny kann keinen dynamisch nachgeladenen Code (ohne > Flash-Neuprogrammierung) ausführen, weil AVR eine Harvard-Architektur > ist. Damit steht bereits zur Compilezeit fest, welchen Tiny du benutzt > und du kannst dir die Laufzeiterkennung sparen. ATmegas , die auch AVRs sind können das aber, da ist der Flash in bootloader und application sector unterteilt. Zumindest während des boots kann man code dynamisch nachladen. Auch die tinys unterstützten in gewissen Grenzen die SPM-instruction und damit das selbst-programming
C. A. Rotwang schrieb: > ATmegas , die auch AVRs sind können das aber, da ist der Flash in > bootloader und application sector unterteilt. Zumindest während des > boots kann man code dynamisch nachladen. > > Auch die tinys unterstützten in gewissen Grenzen die SPM-instruction und > damit das selbst-programming S. R. schrieb: > (ohne Flash-Neuprogrammierung)
Man kann natürlich das Signatur-Byte auslesen und dadurch feststellen, auf welchem AVR das Programm läuft. Aber auch ich bin der Meinung, dass das nur wenig bis keinen Sinn macht aus eben schon oben genannten Gründen und weil solche uC wie die AVRs doch nur in sehr speziellen Anwendungen eingesetzt werden. IMO sind ATTiny- und Co Programme in der Regel auch nicht wirklich sooo komplex, dass man hier nicht schon zur Compilerzeit entscheiden könnte, auf welchem AVR das Programm laufen wird. Einfach mal einen Blick in die jeweiligen Bibliotheken werfen wie das z.B. Atmel gelöst hat. Beispiel: avr/io.h, wenn ich als MCU z.B. den ATTiny45 wähle werden ja auch nur dessen Pindefinitionen durch die avr/io.h eingebunden, nicht aber z.B. die vom Atmega328. Das kann man ganz schnell auch mal prüfen: Als MCU den ATTiny45 angeben und im Code Timer 2 konfigurieren: Der Compiler wird melden, dass er die Register bzgl. Timer 2 gar nicht kennt.
Daniel H. schrieb: > C. A. Rotwang schrieb: >> Auch die tinys unterstützten in gewissen Grenzen die SPM-instruction und >> damit das selbst-programming > > S. R. schrieb: >> (ohne Flash-Neuprogrammierung) Unter Flash-Neuprogrammierung versteht man üblicherweise die Programmierung von einem PC einem Programmiergerät. ein Programmiergerät/PC braucht man beim Self programming nicht, es ist somit sehrwohl möglich Code dynamisch in den Programmspeicher nachzuladen. Damit ist genau das möglich was der TO erfragt im Bootloader checken auf welchen typ das Prog läuft und dann in den Appl-sector das passende programm (nachzu-)laden.
Seid ihr beide aus demselben (Troll)Verein ? Troll B: C. A. Rotwang schrieb: > Programmiergerät/PC braucht man beim Self programming nicht, es ist > somit sehrwohl möglich Code dynamisch in den Programmspeicher > nachzuladen. Damit ist genau das möglich was der TO erfragt im > Bootloader checken auf welchen typ das Prog läuft und dann in den > Appl-sector das passende programm (nachzu-)laden. Und das passende Program, welches (nach)geladen wird, steht wo ? Troll A: Jan R. schrieb: > Dann könnte ich im Setup-Teil meines Codes, wo ich Ports und Timer > definiere, Fallunterscheidungen machen und dann mit einer einzigen > Codebasis auf mehreren (im kleinen Rahmen) verschiedenen MCU agieren. Er will auf einer einzigen Codebasis (re)agieren. Troll A+B: Wie soll das mit den Interrupts gelöst werden ? Und der Zweck von solch einem Blödsinn ist ? Die Umgebung kann sich ändern, aber der uC nicht, was soll das Ganze ?
:
Bearbeitet durch User
Tr schrieb: > Das funktioniert aber nur auf wenigen µCs, die das Bit "SIGRD" im > "SPMCR" haben. Bei den Tinys sind das gerade mal ATtiny87/167. Bei den Megas gibt es einige, die das können. p.s.: Für alle diejenigen, die sich partout nicht vorstellen können, warum man solch ein Feature gebrauchen kann: Stellt euch vor, ihr wärt Atmel und müsstet den STK500 im Feld mit Firmwareupgrades unterstützen. Davon gibt es hornalte Versionen mit einem AT90S8535 und neuere mit einem ATmega8535. Wenn man es schafft, alles in einem einzigen Binary unterzubekommen, dann hat man mit der Verteilung, Softwareupdates etc. deutlich weniger Stress, als wenn man mehrere Versionen parallel verteilen will.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Stellt euch vor, ihr wärt Atmel und müsstet den STK500 im Feld mit > Firmwareupgrades unterstützen. Davon gibt es hornalte Versionen > mit einem AT90S8535 und neuere mit einem ATmega8535. Wenn man es > schafft, alles in einem einzigen Binary unterzubekommen, dann hat > man mit der Verteilung, Softwareupdates etc. deutlich weniger Stress, > als wenn man mehrere Versionen parallel verteilen will. Wurde das dort denn nicht mit (externen) Widerstandskombinationen am A/D Pin entsprechend für die verschiedenen Hardwareversionen erledigt?
Es geht ja nicht darum, wie man erkennt, auf welcher Hardware man nun tatsächlich läuft, sondern dass es zuweilen sinnvoll sein kann, ein einziges Binary für verschiedene Controllertypen zu haben. Dass die Controller natürlich alle zur gleichen Architekturfamilie gehören müssen, damit das überhaupt funktioniert, sollte selbstredend klar sein. Das meint hier nicht nur „sind alle AVR“, sondern eher das, was GCC als -mmcu=avrXXX zusammenfasst.
Jörg W. schrieb: > p.s.: Für alle diejenigen, die sich partout nicht vorstellen können, > warum man solch ein Feature gebrauchen kann: Warum und wozu ? Vielleicht bin ich dumm, aber so dumm auch wieder nicht. Jörg W. schrieb: > Es geht ja nicht darum, wie man erkennt, auf welcher Hardware man > nun tatsächlich läuft, sondern dass es zuweilen sinnvoll sein kann, > ein einziges Binary für verschiedene Controllertypen zu haben. Nein, es ging darum wie man erkennt, auf welcher Hardware das Program läuft: Jan R. schrieb: > Dann könnte ich im Setup-Teil meines Codes, wo ich Ports und Timer > definiere, Fallunterscheidungen machen und dann mit einer einzigen > Codebasis auf mehreren (im kleinen Rahmen) verschiedenen MCU agieren. Das ist eindeutig ein Denkfehler oder ein klarer Fall von Trollitis. Ergibt ungefähr so viel Sinn wie: Ich heisse Erwin, bin ein Mensch und ich weiss, dass ich Erwin heisse und ein Mensch bin, aber falls ich eines Morgens beim Aufwachen feststellen sollte, dass ich nicht mehr Erwin heisse oder das ich kein Mensch sondern eine Blumenvase bin, will ich entsprechend darauf reagieren...
Marc V. schrieb: > Nein, es ging darum wie man erkennt, auf welcher Hardware das Program > läuft: … zu dem Zweck, mit einem Binary auf verschiedener Hardware arbeiten zu können. Ob man die Erkennung nun per Auslesen der Signatur macht oder per externem Strapping, bleibt sich ja erstmal gleich. Inwiefern das bei TE sinnvoll ist, mag eine andere Sache sein. Zu viele Details hat er ja nicht durchblicken lassen.
Marc V. schrieb: >> Codebasis auf mehreren (im kleinen Rahmen) verschiedenen MCU agieren. > > Das ist eindeutig ein Denkfehler oder ein klarer Fall von Trollitis. Du missverstehst das Szenario: Sinnvoll ist das ganze bei booten mit code-broadcast bei unidirectionalen Kommunikationstrecke, etwa so: Ich (das boorprogramm) wache früh in einem (fremden) Bett auf. Ich schaue auf den Zettel auf dem Nachtisch. Da steht ich hab den Job des Feuerwehrmann. Ich schalte das Radio an. Im Radio wird das tagesprogramm für alle die aufwachen gesendet. Ich warte bis der Abschnitt "Für den Feierwehrmann" kommt. Den speichere ich auf meine ToDo-liste. Dann schalte ich das Radio ab und mache meinen Job. Das ist keine Trollitis, das ist ein ganz normales Bootszenario.
Marc V. schrieb: > Jörg W. schrieb: >> Es geht ja nicht darum, wie man erkennt, auf welcher Hardware man >> nun tatsächlich läuft, sondern dass es zuweilen sinnvoll sein kann, >> ein einziges Binary für verschiedene Controllertypen zu haben. > > Nein Kannst du vielleicht mal erklären, wo du den Unterschied siehst zwischen: Jörg W. schrieb: > ein einziges Binary für verschiedene Controllertypen zu haben. und Jan R. schrieb: > mit einer einzigen Codebasis auf mehreren (im kleinen Rahmen) > verschiedenen MCU agieren. ? > Jan R. schrieb: >> Dann könnte ich im Setup-Teil meines Codes, wo ich Ports und Timer >> definiere, Fallunterscheidungen machen und dann mit einer einzigen >> Codebasis auf mehreren (im kleinen Rahmen) verschiedenen MCU agieren. > > Das ist eindeutig ein Denkfehler oder ein klarer Fall von Trollitis. > > Ergibt ungefähr so viel Sinn wie: > Ich heisse Erwin, bin ein Mensch und ich weiss, dass ich Erwin heisse > und ein Mensch bin, aber falls ich eines Morgens beim Aufwachen > feststellen sollte, dass ich nicht mehr Erwin heisse oder das ich > kein Mensch sondern eine Blumenvase bin, will ich entsprechend darauf > reagieren... Sieh es mal so: Es gibt auch Software für den PC, die zur Laufzeit zwischen verschiedenen Prozessor-Varianten unterscheidet, und das obwohl die wenigsten PCs während ihrer Lebensdauer jemals den Prozessor-Typ wechseln. Dein Vergleich passt nicht, weil dein Erwin zugleich der µC und die Software ist. Hier geht's aber darum, dass die Software wissen soll, wie der µC heißt.
:
Bearbeitet durch User
Jörg W. schrieb: > Inwiefern das bei TE sinnvoll ist, mag eine andere Sache sein. Zu > viele Details hat er ja nicht durchblicken lassen. Stimmt, aber: Jan R. schrieb: > Dann könnte ich im Setup-Teil meines Codes, wo ich Ports und Timer > definiere, Fallunterscheidungen machen Im Setup-Teil, sagt der TE. Jörg W. schrieb: > Stellt euch vor, ihr wärt Atmel und müsstet den STK500 im Feld mit > Firmwareupgrades unterstützen. Und wie ? a) Stecker - per ISP/JTAG oder wie auch immer - Signatur wird direkt ausgelesen, entsprechendes Program wird geflasht. b) Bootloader - per WiFi/LAN/Internet oder wie auch immer - Signatur wird angefordert und zurückgeschickt, daraufhin wird entsprechendes Program geflasht. In beiden Fallen hat man alle Versionen des Programs für alle Typen des uC und braucht kein bisschen nachzudenken, kann auch nichts verkehrt machen. Je nach Signatur wird richtiges Program geladen.
Ordner schrieb: > Ich (das boorprogramm) wache früh in einem (fremden) Bett auf. Ich > schaue auf den Zettel auf dem Nachtisch. Da steht ich hab den Job des > Feuerwehrmann. Das bist aber immer noch du (Erwin) in einem fremden Bett und nicht der Nachbar Otto.
Rolf M. schrieb: > Dein Vergleich passt nicht, weil dein Erwin zugleich der µC und die > Software ist. Hier geht's aber darum, dass die Software wissen soll, wie > der µC heißt. Nöö, dein Vergleich passt nicht, weil die Software nicht vom Disk oder USB gelesen, sondern geflasht wird. Und beim flashen weiss ich den uC Typ sowieso, ob vorher oder durch auslesen der Signatur ist egal, was gibt es da zu kontrollieren ? Ein Vergleich mit BIOS wäre viel passender, aber da fällt dein Beispiel glatt durch...
Marc V. schrieb: > a) Stecker - per ISP/JTAG oder wie auch immer - Signatur wird direkt > ausgelesen, entsprechendes Program wird geflasht. Und wenn eben "die Signatur auslesen" nicht möglich ist, respektive als vermeidbare Komplexität bewertet wird?! Nicht jeder will bidirektionales ISP in seiner Applikation (Kopier/Ausleseschutz) > b) Bootloader - per WiFi/LAN/Internet oder wie auch immer - Signatur > wird angefordert und zurückgeschickt, daraufhin wird entsprechendes > Program geflasht. Ja und wenn man eben kein WLAN-gedöns für das Update einbauen will? Die einfachste Lösung ist doch ein binary mit klar unterscheidbaren Abschnitten für die jeweilige Hardware-konfig an die jeweiligen Prozess rauszustreamen und der Bootloeader dex µC such sich das Passende raus.
Marc V. schrieb: > Ordner schrieb: >> Ich (das boorprogramm) wache früh in einem (fremden) Bett auf. Ich >> schaue auf den Zettel auf dem Nachtisch. Da steht ich hab den Job des >> Feuerwehrmann. > > Das bist aber immer noch du (Erwin) in einem fremden Bett und nicht > der Nachbar Otto. Du musst aber nicht wissen wer du bist, das steht ja auf den Zettel. Es gibt eben nur ein (dummes) Bootprogramm -für Erwin und Otto dasselbe- und nicht ein spezielles für Otto und ein anderes für Erwin.
so z.B. vor dem main loop: jeder könnte noch seine eigene fest codierte Seriennummer im Quellcode bekommen für Arduino
1 | //------ section seriell PRINT ------
|
2 | DEBUG_PRINTLN(F("tach auch....")); |
3 | DEBUG_PRINT(F("Arduino = "));DEBUG_PRINT(ARDUINO); |
4 | #if defined(__AVR_ATmega1284P__)
|
5 | DEBUG_PRINTLN(F(", auf migthy m1284p")); |
6 | #endif
|
7 | Serial.print(F("File: ")); Serial.println(_name()); // Serial.println(_date_str); Serial.print(F(" (")); Serial.print(c_date_str); Serial.println(F(")")); |
8 | Serial.print(F("compile: ")); Serial.println(c_str); |
9 | DEBUG_PRINT(F("CPU Takt : ")); DEBUG_PRINT(insert_char_in_num_vr((unsigned int)(F_CPU/1000L), ',', 3)); DEBUG_PRINTLN(F(" MHz")); |
oder AVR Studio noch mit mcpu ergänzt ?!
1 | usart_write("\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\nSystem Ready\r\n"); |
2 | usart_write("Compiliert am "__DATE__" um "__TIME__"\r\n"); |
3 | usart_write("Compiliert mit GCC Version "__VERSION__"\r\n\r\n"); |
Ordner schrieb: > Und wenn eben "die Signatur auslesen" nicht möglich ist, respektive als > vermeidbare Komplexität bewertet wird?! Nicht jeder will bidirektionales > ISP in seiner Applikation (Kopier/Ausleseschutz) Ordner schrieb: > Ja und wenn man eben kein WLAN-gedöns für das Update einbauen will? Tja, keine Arme, keine Kekse. Wenn es weder ISP noch eine andere Updatemöglichkeit gibt, dann gibt es demzufolge auch kein Update und keine Änderungen, wozu dann die Abfrage auf uC Typ - weisst du überhaupt wovon du redest?
Jan R. schrieb: > Dann könnte ich im Setup-Teil meines Codes, wo ich Ports und Timer > definiere, Fallunterscheidungen machen und dann mit einer einzigen > Codebasis auf mehreren (im kleinen Rahmen) verschiedenen MCU agieren. > Das wäre schon praktisch. Ist Dir klar, dass AVR nur eine Interrupt Tabelle hat und die für unterschiedliche Modelle auch unterschiedlich belegt ist? IMHO ist schon das ein Ausschlusskriterium für Deine Idee. Klar könnte man fiese Tricks mit function pointer machen, aber ein Tiny hat auch nur sehr begrenzt RAM und Flash übrig. Da passt kein Bloat rein. Lustig würde es auch werden wenn sich Hardware Register Addressen unterscheiden. Die teilst Du dem Compiler ja implizit über die Auswahl der MCU mit. Blöd ist auch das das Auslesen der Signatur wohl eher nicht vom Code aus geht, da bleiben nur fiese Tricks zur Erkennung der MCU Variante übrig. Alles in Allem muss sich der OP die Frage stellen, ob hier nicht Aufwand größer als der Nutzen ist.
:
Bearbeitet durch User
Marc V. schrieb: > Wenn es weder ISP noch eine andere Updatemöglichkeit gibt, dann > gibt es demzufolge auch kein Update und keine Änderungen, wozu dann > die Abfrage auf uC Typ - weisst du überhaupt wovon du redest? Wer spricht denn davon das keine updatemöglichkeit gibt? Eben nur eine unidirektionale, beispielsweise einen IR-Receiver und keine bidirektionale wie beim ISP. Viel Erfahrung mit embedded Hardware und Update-Hardware hast du offensichtlich nicht. Kopierschutz heist nicht das das ganze nicht updatefähig bleiben kann. Es gibt Anwendungen bei den write-only nicht so dumm ist wie es für den unbedarften klingen mag.
Ordner schrieb: > Wer spricht denn davon das keine updatemöglichkeit gibt? Eben nur eine > unidirektionale, beispielsweise einen IR-Receiver und keine > bidirektionale wie beim ISP. Und ev. Fehler bei der Übertragung lassen wir einfach durchgehen. > Viel Erfahrung mit embedded Hardware und > Update-Hardware hast du offensichtlich nicht. Sagen wir es mal so: Ich habe mehr vergessen, als du jemals lernen wirst. Und viel lernen wirst du sowieso nicht, da du mit Logik auf Kriegsfuss stehst... Das, was der TE vorhat (und sowieso nie machen wird, weil ihm ganz einfach die entsprechenden Kenntnisse dazu fehlen) ist und bleibt absoluter Unsinn. Marc V. schrieb: > Da müsste dann Code für alle Tinys compiliert sein und vor jeder > Ausgabe müssten dann mehrere Abfragen erfolgen, dementsprechend die > Adresse ausgewählt werden, die Ports müsste man mit Adresse und nicht > mit Namen ansprechen - das soll praktisch sein ? Marc V. schrieb: > Troll A+B: > Wie soll das mit den Interrupts gelöst werden ? Marc V. schrieb: > Die Umgebung kann sich ändern, aber der uC nicht, was soll das Ganze ? Und die Aufgaben können sich natürlich dementsprechend ändern, aber der uC wird sich deswegen niemals ändern. Und natürlich ist ein Tiny mit seinen Unmengen von Flash und RAM für so etwas besonders gut geeignet. Von den erheblich kürzeren Ausführungszeiten gar nicht zu reden...
Marc V. schrieb: > Ordner schrieb: >> Wer spricht denn davon das keine updatemöglichkeit gibt? Eben nur eine >> unidirektionale, beispielsweise einen IR-Receiver und keine >> bidirektionale wie beim ISP. > Und ev. Fehler bei der Übertragung lassen wir einfach durchgehen. Nein, aber für test auf Übertragungsfehler braucht es keinen Rückkanal. ein paar Zeilen Parity berechnen/Prüfsumme berechnen und 99,9% der Übertragungsfehler werden erkannt. >> Viel Erfahrung mit embedded Hardware und >> Update-Hardware hast du offensichtlich nicht. > > Sagen wir es mal so: > Ich habe mehr vergessen, als du jemals lernen wirst. > Und viel lernen wirst du sowieso nicht, da du mit Logik auf > Kriegsfuss stehst... Womit die Frage wer hier der Troll ist klar beantwortet wäre. > Das, was der TE vorhat ... ist und bleibt > absoluter Unsinn. Und du bist das einzige Genie das das ganz klar durchschaust hast und deine Zeit ist viel zu kostbar um uns unwissenden das narrensicher zu beweisen :-(
Ordner schrieb: >> Das, was der TE vorhat ... ist und bleibt >> absoluter Unsinn. > > Und du bist das einzige Genie das das ganz klar durchschaust hast und > deine Zeit ist viel zu kostbar um uns unwissenden das narrensicher zu > beweisen :-( Ich habe das auch durchschaut: Jan R. schrieb: >> Und für welchen willst Du dann compilieren? >> Gruss Chregu > > Ich gebe die MCU im Makefile an. Oder, wenn manuell, eben im > Compileraufruf. > > Der Code bliebe in diesen untersch. Fällen der gleiche, was einiges in > der Versionsverwaltung erleichtert. Jan R. ist übrigens der TO.
Thomas E. schrieb: > Jan R. schrieb: >>> Und für welchen willst Du dann compilieren? >>> Gruss Chregu >> >> Ich gebe die MCU im Makefile an. Oder, wenn manuell, eben im >> Compileraufruf. >> >> Der Code bliebe in diesen untersch. Fällen der gleiche, was einiges in >> der Versionsverwaltung erleichtert. > > Jan R. ist übrigens der TO. Das klingt schon abentuerlich, aber je nachdem wie man das interpretiert nicht unmöglich. Eben eine Mini-HAL, die im "Setup-code" umgesetzt wird. Wie groß sind überhaupt die unterschiede zwischen den verschiedenen tiny's? Denkbar war auch eine Realisierung wie weiland tinybasic, nur 2 bis 3k Interpreter der rest kompatibele "scriptsprache". Und die vorgeschlagene Zusammenfassung aller uC-codes zu einem binary um die flashprogrammierung zu vereinfachen ist über bootloader realisierbar. Das erleichter das "Flashen" schon erheblich, man wirft jeden uC das selbe hex-file zu und der such sich den passenden Abschnitt selbst heraus. Ist deutlich einfacher in Feld zu handeln, als wenn man für jeden uc eine spezifische Routine starten muss. Insbesonders wenn man es mit äußerlich identischen Geräten zu tun hat. Kein umständliches ermitteln der Bestückvariante anhand der seriennummer um das richtige hex-file anzugeben. Gabs das nicht schon bei Apple zu Zeiten MC68xxx/PowerPC-Migration? Okay, nicht ganz dasselben wie ein avr tiny aber das Prinzip ist vergleichbar.
Ordner schrieb: > Wie groß sind überhaupt die unterschiede zwischen den verschiedenen > tiny's? Das kann man so pauschal einfach nicht beantworten. Es gibt sehr spezialierste ATtinys, bei denen man die Timer aus einer höherfrequenten PLL takten kann, aber auch eine Palette von Tinys, die sich doch stark ähneln. Am Ende muss das der TO für sich selbst verifizieren, inwieweit die angedachten Teile binärkompatibel sind.
Jim M. schrieb: > Ist Dir klar, dass AVR nur eine Interrupt Tabelle hat Das stimmt nicht. Jeder Mega hat deren zwei und die zweite davon kann sogar auch noch an verschiedenen Stellen im Flash liegen (BOOTSZ-Fuses). Allerdings erwähne ich das nur der Vollständigkeit halber, weil mir deine offensichtlich von keiner Ahnung getragen Äußerung massiv auf den Sack ging. Für das gestellte Problem hingegen spielt es keine Rolle. Dafür ist nur eins wichtig: "Self-Programming". D.h.: die Fähigkeit des Codes, seine eigene Codebasis zur (ersten) Laufzeit den Erfordernissen der Umgebung anzupassen. D.h.: Der Code muß im ersten Anlauf erstmal nur das herausfinden, was nötig ist, um sich ggf. selbst umprogrammieren zu können. Und das ist garnicht mal so schwer. Im Prinzip hat jeder, der schonmal selber einen halbwegs universellen Bootloader für die AVR8 programmiert hat, einen großen Teil der nötigen Kenntnisse. Der Rest ist reine Fleißarbeit. Allerdings, und hier bin ich wieder vollkommen deiner Meinung, wozu soll so ein Aufwand eigentlich gut sein? Schon für diese erste grundlegend notwendige Stufe für ein ein Universal-Binary wäre ein unverhältnismäßig hoher Programmieraufwand erforderlich. Machbar, aber eben auch ziemlich sinnlos... Von den Weiterungen, um dann die eigentliche Applikation "in-circuit" auf jeden beliebigen AVR8 anzupassen mal ganz abgesehen...
Jim M. schrieb: > Blöd ist auch das das Auslesen der Signatur wohl eher nicht vom Code aus > geht, da bleiben nur fiese Tricks zur Erkennung der MCU Variante übrig. Ich finde die Fragestellung schon sinnvoll, und es gibt auch Anwendungsmöglichkeiten in der Praxis. Bei den PICs liegen die Config Words (die Äquivalente zu den Fuses bei AVR) im Adressraum des Prozessors, d.h. ich kann hier zur Laufzeit per TBLRD (LPM/ELPM bei AVR) den Prozessortyp und die Revision auslesen. Ich weiß damit zB, ob das beispielsweise ein Chip für 5V oder eine Version für 1.8...3.6V ist - beide Versionen sind softwaretechnisch identisch und gleich schnell, aber eventuell braucht der ADC oder ein Digitalpoti eine andere Einstellung. Oder: Es gibt Prozessortypen, die sich nur durch die Flash- und RAM-Ausstattung unterscheiden, ähnlich wie Mega48/88/168/328. Auch das ließe sich mit einem Binary abhandeln. Oder: Ältere Chiprevisionen benötigen vielleicht einen Workaround für einen Bug, neuere nicht. Da die Revision auslesbar ist, kann man den Workaround nur bei den Prozessoren einsetzen, die ihn wirklich brauchen. Dass Atmel hier einiges vergurkt hat, bedeutet nicht, dass das alles generell Unsinn ist. Es kommt halt drauf an. fchk
Frank K. schrieb: > Dass Atmel hier einiges vergurkt hat Neuere AVRs haben das Feature ja auch. Nur bis zu den Tinys hat es sich nicht groß rumgesprochen, aber das sind dummerweise die, für die der TE es gern hätte.
Frank K. schrieb: > Es gibt Prozessortypen, die sich nur durch die Flash- und RAM-Ausstattung > unterscheiden, ähnlich wie Mega48/88/168/328. Auch das ließe sich mit > einem Binary abhandeln. Schon gepatzt :-) Die beiden kleineren haben einen anderen Instruktionssatz: Sie kennen kein CALL und auch kein JMP (nur RCALL und RJMP). Ließe sich zwar dadurch abdecken, dass man nur Binaries <= 8 KiB verwendet, aber selbst dann wird es schwrierig, denn 1) Die beiden kleineren daben 16-Bit IRQ-Vektoren, bei den beiden größeren belegt ein Vektor 32 Bits. 2) Damit auf einem ATmega88 ein RJMP korrekt funktioniert, muss ein Sprung, der vom Ende des Flashs zum Anfang hin geht, nach VORNE springen; die Hardware macht dann 'nen wrap-around. Dies lässt sich durch ein einzigen Binary nicht abbilden — zumindest wüsste ich nicht, wie. Fälle, in denen das, was der TO will, sinnvoll ist, gibt es; ja. Aber der TO scheint sich das einfach nicht überlegt zu haben. Zudem scheint es nicht um Erwägungen der eigentlichen Zielsorftware und deren variablen Umgebung zu gehen, sondern darum Jan R. schrieb: "einiges in der Versionsverwaltung zu erleichtern". Wenn Jan die o.g. Probleme betrachtet, wird er ganz fix und viel lieber die "Probleme" mit der Versionsverwaltung lösen wollen ;-)
Frank K. schrieb: > Ich finde die Fragestellung schon sinnvoll, und es gibt auch > Anwendungsmöglichkeiten in der Praxis. Nein, eben nicht. So wie in der Fragestellung ist es Blödsinn, es bleibt Blödsinn und nein, es gibt keine (zumindest keine sinnvollen) Anwendungsmöglichkeiten in der Praxis. Frank K. schrieb: > Ich > weiß damit zB, ob das beispielsweise ein Chip für 5V oder eine Version > für 1.8...3.6V ist - beide Versionen sind softwaretechnisch identisch > Oder: Es gibt Prozessortypen, die sich nur durch die Flash- und > RAM-Ausstattung unterscheiden, ähnlich wie Mega48/88/168/328. Auch das > ließe sich mit einem Binary abhandeln. Kann man alles anhand der Signatur sehen und nur die passende Version flashen. > Oder: Ältere Chiprevisionen benötigen vielleicht einen Workaround für > einen Bug, neuere nicht. Da die Revision auslesbar ist, kann man den > Workaround nur bei den Prozessoren einsetzen, die ihn wirklich brauchen. Eben nicht. Bei dieser genialen Lösung wird der Workaround bei allen geflasht - ob es gebraucht wird oder nicht. Im übrigen stimme S.Landolt voll zu: S. Landolt schrieb: > Fragt der µController: "Wer bin ich, und wenn ja, wieviele?"
Marc V. schrieb: > Nöö, dein Vergleich passt nicht, weil die Software nicht vom Disk > oder USB gelesen, sondern geflasht wird. > Und beim flashen weiss ich den uC Typ sowieso, ob vorher oder durch > auslesen der Signatur ist egal, was gibt es da zu kontrollieren ? Richtig, beim flashen weis ich das. Aber wenn ich das MLF bzw. HEX-File erstelle weiß ich das ggf. noch nicht auf welchen AVRs das Programm laufen soll. Marc V. schrieb: > Nein, eben nicht. So wie in der Fragestellung ist es Blödsinn, es > bleibt Blödsinn und nein, es gibt keine (zumindest keine sinnvollen) > Anwendungsmöglichkeiten in der Praxis. Jörg hat IMO ein gutes Beispiel mit dem STK500 gebracht wo es sinnvoll sein kann ;)
:
Bearbeitet durch User
> Jörg hat IMO ein gutes Beispiel mit dem STK500 > gebracht wo es sinnvoll sein kann Ich weiß nicht, kenne das STK500 nicht, aber läuft da der ATmega8535 nicht einfach im Compatibility-Mode?
S. Landolt schrieb: > Ich weiß nicht, kenne das STK500 nicht, aber läuft da der ATmega8535 > nicht einfach im Compatibility-Mode? Das weiß ich auch nicht aber ich finde, es ist ein gutes Beispiel: Man baut über Jahre hinweg immer die gleiche Hardware und im Laufe der Zeit wird ggf. der ursprüngliche uC abgekündigt und gegen einen neuen ersetzt. Da man mit Firmwareupdates aber auch die alte Hardware weiter unterstützen will gibts zwei Möglichkeiten: Zwei Firmware-Versionen (und der User muss die richtige raussuchen) oder eben nur eine Firmware die selber schaut auf welcher Hardware sie läuft. Das halte ich durchaus für ein plausibles Szenario, wenn auch das im uC-Bereich, in dem AVRs eingesetzt werden, wohl nur äußerst selten auftreten wird.
Ordner schrieb: > Nein, aber für test auf Übertragungsfehler braucht es keinen Rückkanal. > ein paar Zeilen Parity berechnen/Prüfsumme berechnen und 99,9% der > Übertragungsfehler werden erkannt. Aha, und die erkannten Übertragungsfehler werden wie zurückgemeldet ?
Warum fragt man den µC nicht einfach wer er ist und flasht dann anschließend die richtige Firmware? Nach dem Motto: Wer bist Du? Hans Peter Hallo Hans Peter hier kommt dein Käsebrot. Wer bist Du jetzt? Karl Gustav Hallo Karl Gustav hier kommt dein Wurstbrot. Anstatt Hallo, hier kommt ein Wurst- und ein Käsebrot. Ich bin Hans Peter und mag Käsebrot, das Wurstbrot lass ich liegen.
:
Bearbeitet durch User
Nico W. schrieb: > Warum fragt man den µC nicht einfach wer er ist und flasht dann > anschließend die richtige Firmware? Weil das viel zu einfach und daher uncool ist?
M. K. schrieb: > Zwei Firmware-Versionen (und der User muss die richtige raussuchen) Warum? Das kann doch die Updatesoftware auf dem PC erledigen?
Bernd K. schrieb: > Warum? Das kann doch die Updatesoftware auf dem PC erledigen? Ja, kann sie. Kann aber auch anders gelöst werden wie wir hier ja sehen. Es gibt halt viele Möglichkeiten.
Bernd K. schrieb: > Das kann doch die Updatesoftware auf dem PC erledigen? Die ist nur ein generisches Programmierwerkzeug, die bedient ja weiter nichts als den AVR910-Bootloader. Die Alternative hätte dann also (damals) bedeutet, ein eigenes, separates Programmierwerkzeug zu bauen, statt im gleichen Hexfile beide Hardwarevarianten zu unterstützen. Ich sehe es auch so, dass man sowas in der Praxis eher selten braucht, aber es von vornherein komplett als Blödsinn abzutun zeugt eher von fehlender Weitsicht: nur, weil man es selbst noch nie benötigt hat, spricht man allen anderen das Recht ab, es ggf. doch mal zu benötigen.
Nico W. schrieb: > Warum fragt man den µC nicht einfach wer er ist und flasht dann > anschließend die richtige Firmware? > > Nach dem Motto: > Wer bist Du? > Hans Peter > Hallo Hans Peter hier kommt dein Käsebrot. > > Wer bist Du jetzt? > Karl Gustav > Hallo Karl Gustav hier kommt dein Wurstbrot. > > Anstatt > Hallo, hier kommt ein Wurst- und ein Käsebrot. > Ich bin Hans Peter und mag Käsebrot, das Wurstbrot lass ich liegen. Wenn man nicht fragen kann... Es gab mal vor WLAN/Zigbee/etc also vor ca. 25 Jahren eine clevere smartwatch von RELOX glaube ich. Die war drahtlos programmierbar, ein Stecker sähe an dem schicken Teil einfach bescheuert aus. WLAN etc war Anfang der Neunziger nicht erfunden, also machte man das Ganze mit einer Fotodiode/-transistor. Und als Sender musste der PC-Monitor herhalten. Also die Uhr an den Moni halten, Bildschirm flackern lassen - fertig. Problem, die Fotodiode funktioniert nur als Empfänger, das Steuerprogramm kann also nicht fragen, welcher uC am ende des Lichtstrahl sitzt und welches binary zu senden ist. Aber mit dem selfprogramming einfach lösbar. Bei der Fertigung der Uhr wird ein extern programmierter µC verbaut. Dessen bootprogramm liest die Fotodiode aus, checkt seine signature/HW-ID und transferiert das passende Schnipsel aus dem Lichtstrom in den Flash - eben broadcast über eine unidirektionale ISP-Alternative. Selbst wenn man fragen kann welcher µC am anderen Ende zu betanken ist, ist zu überlegen ob die µC-Selbstauswahl nicht die narrensichere Variante ist. Nicht jeder Yuppie/Hausfrau/servicetechniker/DAU ist in der Lage ein µC-Programmiertool korrekt zu bedienen und abzulesenen welcher uC auf dem zu programmioerenden Gerät steckt.
Ordner schrieb: > Es gab mal vor WLAN/Zigbee/etc also vor ca. 25 Jahren eine clevere > smartwatch von RELOX glaube ich. Die war drahtlos programmierbar, ein > Stecker sähe an dem schicken Teil einfach bescheuert aus. WLAN etc war > Anfang der Neunziger nicht erfunden, also machte man das Ganze mit einer > Fotodiode/-transistor. Und als Sender musste der PC-Monitor herhalten. > Also die Uhr an den Moni halten, Bildschirm flackern lassen - fertig. So macht die Kreissparkasse das heute noch mit ihren TAN Generatoren. Der Nachteil ist, das ganze ist fummelig und dauert recht lange. Andere Banken (z.b. DB) setzen da auf eine App welche per Kamera ein Muster (nicht QR, sondern farbige Punkte) vom Bildschirm liest. Geht sau schnell, in <1 Sekunde. Da hat die Kamera noch nicht mal für mich sichtbar fokusiert. Nur die KSK hat sicher deutlich mehr Kunden ohne Smartphone und braucht deshalb die Variante.
Marc V. schrieb: > Ordner schrieb: >> Nein, aber für test auf Übertragungsfehler braucht es keinen Rückkanal. >> ein paar Zeilen Parity berechnen/Prüfsumme berechnen und 99,9% der >> Übertragungsfehler werden erkannt. > > Aha, und die erkannten Übertragungsfehler werden wie zurückgemeldet ? Diese Rückmeldung ist im beschrieben Scenario nicht notwendig. Halt wie ne IR-fernbedienung, fire and forget.
Ordner schrieb: > Problem, die Fotodiode funktioniert nur als Empfänger, das > Steuerprogramm kann also nicht fragen, welcher uC am ende des > Lichtstrahl sitzt und welches binary zu senden ist. Dann sendet das Steuerprogramm eben alle Binaries nacheinander als Blob / Fat Binary und der Empfänger sucht sich raus, was er will. Das ist der Apple-Ansatz, und der richtet sich eher selten an erfahrene Computerbenutzer.
S. R. schrieb: > Dann sendet das Steuerprogramm eben alle Binaries nacheinander als Blob > / Fat Binary und der Empfänger sucht sich raus, was er will. Ja, man kann sich natürlich alle möglichen anderen Szenarien ausdenken. Das alles ist aber kein Grund, das Ansinnen des TOs völlig zu negieren, nur weil's nicht in die eigene Vorstellungswelt passt. Anyway, der TO ist sowieso über alle Berge, und ob das, was er vor hatte, in der Tat sinnvoll gewesen wäre, kann man mangels genauer Infos seinerseits nicht beurteilen.
Jörg W. schrieb: > Das alles ist aber kein Grund, das Ansinnen des TOs völlig zu negieren, > nur weil's nicht in die eigene Vorstellungswelt passt. Das es für jede noch so abstruse Problemlösung dann doch irgendwo ein passendes Problem gibt, mag ja sein. An der Art der Fragestellung des TO lässt sich aber zweifelsfrei ablesen, daß er das passende Problem nicht hat, und daher die Standardfrage "Warum" genau richtig ist. Oliver
Oliver S. schrieb: > An der Art der Fragestellung des TO lässt sich aber zweifelsfrei > ablesen, daß er das passende Problem nicht hat, und daher die > Standardfrage "Warum" genau richtig ist. Ja, wahrscheinlich ist dem so. Ich vermute mal, dass der TO das passende Werkzeug "Preprocessor" nicht gut genug kennt. Denn sonst hätte er seine Ports & Pins (um die es ihm ging, s.o.) mit ein paar #ifdef at compile time abgefackelt.
:
Bearbeitet durch Moderator
Oliver S. schrieb: > daher die Standardfrage "Warum" genau richtig ist Dagegen habe ich ja gar nichts einzuwenden, nur gegen die Argumentationen, dass man sowas „niemals nicht auf gar keinen Fall“ brauchen kann.
Jörg W. schrieb: > Dagegen habe ich ja gar nichts einzuwenden, nur gegen die > Argumentationen, dass man sowas „niemals nicht auf gar keinen Fall“ > brauchen kann. Bitte genau zitieren, wenn schon mit Anführungszeichen. Marc V. schrieb: > Nein, eben nicht. So wie in der Fragestellung ist es Blödsinn, es > bleibt Blödsinn und nein, es gibt keine (zumindest keine sinnvollen) > Anwendungsmöglichkeiten in der Praxis. Wie gesagt, "so wie in der Fragestellung". Und wie auch gesagt, anwenden kann man vieles, ob es aber sinnvoll ist ? Und wenn etwas Blödsinn ist, dann ist die Behauptung, dass es Blödsinn ist, weder beleidigend noch stört es irgendeinen normalen Menschen. Und mein Lieblingszitat am Ende: S. Landolt schrieb: > Fragt der µController: "Wer bin ich, und wenn ja, wieviele?"
Jörg W. schrieb: > Dagegen habe ich ja gar nichts einzuwenden, nur gegen die > Argumentationen, dass man sowas „niemals nicht auf gar keinen Fall“ > brauchen kann. Und? Kann er jetzt gucken, wer er ist oder kann er nicht? Man möge mir ja widersprechen, aber ich sage: Er kann nicht. Insofern ist doch das STK500-Beispiel einfach nur Makulatur. Was nützt es dem jeweiligen Controller, wenn er gar nicht weiß, wer er ist und wie er sich denn nun initialisieren muß? Und nein, die haben nicht in weiser Voraussicht schon bei der ersten Version damit gerechnet, daß sowas irgendwann einmal nötig werden könnte.
:
Bearbeitet durch User
Thomas E. schrieb: > und wie er sich denn nun initialisieren muß? Zwischen Architekturen, bei denen sich die Initialisierung grundlegend unterscheidet, kann man solche Vorgehensweise natürlich vergessen, das ist sonnenklar. Einen Xmega und einen Tiny wirst du nicht in ein Binary bekommen. Zwischen Architekturen, die sich ähneln, ist sowas jedoch machbar, wenn man es unbedingt braucht. Ob man dabei die konkrete Konfiguration nun aus den Fuses auslesen kann oder über externes Strapping (Widerstände, die bestimmte Pins ziehen), ist dabei ziemlich zweitrangig. > Und nein, die haben nicht in weiser Voraussicht schon in der ersten > Version damit gerechnet, daß sowas irgendwann einmal nötig werden > könnte. Sie waren weitsichtier als du glaubst: der STK500 hat vier Bits an einem IO-Expander für das Einlesen einer Hardware-ID vorgesehen, schon ab der ersten Version.
Jörg W. schrieb: > Zwischen Architekturen, die sich ähneln, ist sowas jedoch machbar, > wenn man es unbedingt braucht. Ob man dabei die konkrete > Konfiguration nun aus den Fuses auslesen kann oder über externes > Strapping (Widerstände, die bestimmte Pins ziehen), ist dabei > ziemlich zweitrangig. Keineswegs. Denn das setzt immer eine unterscheidbare Hardwarekonfiguration voraus. Die, wenn sie nicht im Inneren des Controllers sowieso vorhanden ist, extern "angelötet" sein muß. Jörg W. schrieb: > Sie waren weitsichtier als du glaubst: der STK500 hat vier Bits an > einem IO-Expander für das Einlesen einer Hardware-ID vorgesehen, > schon ab der ersten Version. Na gut. Ob das gedachte Update-Szenario nun das Motiv dafür war, sei mal dahingestellt. Nutzbar wäre es dafür natürlich, sofern die Hardware-Version auch den Controller beinhaltet und nicht nur die Peripherie. Denn, wenn ich z.B. auf einem Board vorhandene 20-mA-LEDs gegen Low-Current-Versionen mit entsprechend anderen Vorwiderständen austausche, habe ich selbstverständlich eine neue Hardwareversion, benötige aber weder eine neue Software noch einen anderen Controller. Damit könnte ich problemlos den Lagerbestand der alten Controller aufbrauchen und irgendwann auf den neuen umsteigen.
:
Bearbeitet durch User
Thomas E. schrieb: > Ob das gedachte Update-Szenario nun das Motiv dafür war, sei mal > dahingestellt. Daran hat man zu diesem Zeitpunkt gewiss noch nicht gedacht. Aber man war weitsichtig genug, sowas vorzusehen, damit man im Falle eines Falles später in der Firmware darauf reagieren kann. Klar, dass man für den Ersatz von ein paar LEDs mit anderen Vorwiderständen nicht unbedingt eine neue Hardware-Rev braucht, aber nur deshalb würde wohl sowieso niemand eine komplett neue Rev ausrollen. Die Grundkosten für sowas sind hoch genug, als dass man da erstmal einige Änderungen zusammenkommen lässt, bevor man das macht.
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.