Forum: Mikrocontroller und Digitale Elektronik AVR-Modell zur Laufzeit erkennen?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jan R. (janra)


Bewertung
0 lesenswert
nicht lesenswert
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 Moderator
von Tr (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christian M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du bist mir ein Lustiger! Und für welchen willst Du dann compilieren?

Gruss Chregu

von Jan R. (janra)


Bewertung
-1 lesenswert
nicht lesenswert
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 )

von Jan R. (janra)


Bewertung
0 lesenswert
nicht lesenswert
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.

von g457 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
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
von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von S. Landolt (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Fragt der µController: "Wer bin ich, und wenn ja, wieviele?"

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
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
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
1 lesenswert
nicht lesenswert
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 ?

von S. R. (svenska)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Frank (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Um welche Tinys handelt es sich denn?

von C. A. Rotwang (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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

von Daniel H. (Firma: keine) (commander)


Bewertung
0 lesenswert
nicht lesenswert
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)

von M. K. (sylaina)


Bewertung
1 lesenswert
nicht lesenswert
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.

von C. A. Rotwang (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-2 lesenswert
nicht lesenswert
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...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Ordner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Ordner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ordner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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");

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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
von Ordner (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Ordner (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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 :-(

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ordner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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...

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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 ;-)

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
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?"

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
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
von S. Landolt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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?

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
2 lesenswert
nicht lesenswert
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 ?

von Nico W. (nico_w)


Bewertung
0 lesenswert
nicht lesenswert
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
von Daniel H. (Firma: keine) (commander)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Zwei Firmware-Versionen (und der User muss die richtige raussuchen)

Warum? Das kann doch die Updatesoftware auf dem PC erledigen?

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ordner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ordner (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Oliver S. (oliverso)


Bewertung
1 lesenswert
nicht lesenswert
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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-2 lesenswert
nicht lesenswert
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?"

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.