ATmega328p: timestamp beim Flashen ohne Zusatzhardware?

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

meine 328er werden per Atmel-ICE geflasht.

Nun suche ich eine einfache Möglichkeit, beim Flashen einen Timestamp 
mit einzubringen (wird ins EEPROM geschrieben).
Grund: Unverwechselbarkeit der Geräte.

Zuerst hatte ich vor, über eine externe Datenbank eine Nummer zu 
vergeben, aber ein Timestamp erscheint mir einfacher.
Er sollte über den ICE mit geflasht werden...

Hat jemand damit schon Erfahrung gemacht oder einen Lösungsansatz? Ich 
bin fürs Erste recht ratlos, wie ich das ohne HW-Zusatz hinbringe..

[Stefan F. (Gast)]

Du könntest den zeitstempel in eine Datei schreiben und dann avrdude 
aufrufen, um das File ins EEprom zu übertragen. Mit Linux/Cygwin geht 
das ganz einfach.

[Amateur (Gast)]

Wie ist es mit der eingebauten timestamp. Mit dem Makro eine Konstante 
belegen und ab in den Flash-Speicher. Du kannst auch u. A. die Zeit, das 
Datum oder den Dateinamen extrahieren.
Dann nur neu Kompilieren und ab in den Flash-Speicher.

[Thomas E. (thomase)]

Hanno R. schrieb:
> Hat jemand damit schon Erfahrung gemacht oder einen Lösungsansatz?

Wie sind denn deine PC-Programmierfähigkeiten?

Nicht vorhanden: Vergiss es.

Vorhanden: Schreib dir einen Uploader, der mit den entsprechenden 
Avrdude-Aufrufen, das Flash.hex und das Eeprom.hex auf den Controller 
schreibt.

Das Eeprom.hex muß dabei vor jedem Aufruf mit den aktuellen Zeitwerten 
neu erstellt werden. Alternativ könntest du den Zeitstempel oder auch 
jede andere Information in die z.B. letzten 16 Byte des Flash.hex 
schreiben.

Ob das Programm nun mit einem Button bedient wird oder man einen halben 
Roman in die Tastatur hämmern muß, ist Geschmackssache.

Ich bevorzuge für sowas den Button:
Button klick
Flash.hex flashen
Eeprom.hex bearbeiten
Eeprom.hex flashen
fertig.

So ein kleines Tool lässt sich auch ins Avr-Stúdio einbinden und ist 
dann über Tools verfügbar. Jedenfalls geht das beim alter 4er. Beim 
aktuellen wahrscheinlich auch. Nur hat wohl noch niemand rausgefunden, 
wie man das macht.

[c-hater (Gast)]

Hanno R. schrieb:

> Nun suche ich eine einfache Möglichkeit, beim Flashen einen Timestamp
> mit einzubringen (wird ins EEPROM geschrieben).

> Zuerst hatte ich vor, über eine externe Datenbank eine Nummer zu
> vergeben, aber ein Timestamp erscheint mir einfacher.

Besser noch: eine GUID. Insbesondere dann, wenn der Grund ist:

> Grund: Unverwechselbarkeit der Geräte

> einen Lösungsansatz?

Der Lösungsansatz ist ein "Hook", also eine Stelle im Prozess des 
Flashens, an der du ein eigenes Stück Code zum Laufen einhängen kannst.

Es hängt also vor allem davon ab, mit welcher Software du flashst, 
nicht von der Hardware. Blöderweise hast du aber genau dazu nix 
gesagt...

[Hanno Reimann (Gast)]

c-hater schrieb:
> Der Lösungsansatz ist ein "Hook", also eine Stelle im Prozess des
> Flashens, an der du ein eigenes Stück Code zum Laufen einhängen kannst.
>
> Es hängt also vor allem davon ab, mit welcher Software du flashst,
> nicht von der Hardware. Blöderweise hast du aber genau dazu nix
> gesagt...

Ist schon ein wenig chaotisch: die Libs schreibe ich mit DEV-C++, die 
Module erst mal mit Arduino (= schnelles testen), größere Sachen mit 
Atmel Studio 7, die kleineren lass ich meistens im Ardu.

[Hanno Reimann (Gast)]

Stefan U. schrieb:
> zeitstempel in eine Datei schreiben und dann avrdude
> aufrufen, um das File ins EEprom zu übertragen

ist zu aufwendig für eine größere Stückzahl. Hier soll der Bestücker die 
ATmegas vor dem Bestücken programmieren, und der will schnell fertig 
sein...

[c-hater (Gast)]

Hanno Reimann schrieb:

> Ist schon ein wenig chaotisch: die Libs schreibe ich mit DEV-C++, die
> Module erst mal mit Arduino (= schnelles testen), größere Sachen mit
> Atmel Studio 7, die kleineren lass ich meistens im Ardu.

Und wir wissen nun immer noch nicht, wie genau nun dein Flashvorgang 
aussieht...

[Hanno Reimann (Gast)]

Thomas E. schrieb:
> Vorhanden: Schreib dir einen Uploader, der mit den entsprechenden
> Avrdude-Aufrufen, das Flash.hex und das Eeprom.hex auf den Controller
> schreibt.

.. leider am Thema vorbei. Der Bestücker will die Atmels vor dem 
Bestücken programmieren, es muss hier alles superschnell in einem Rutsch 
durchlaufen und fehlefrei sein. Der Junge hat mich bis jetzt schonb ganz 
schön getrieben...

[Hanno Reimann (Gast)]

c-hater schrieb:
> Der Lösungsansatz ist ein "Hook", also eine Stelle im Prozess des
> Flashens, an der du ein eigenes Stück Code zum Laufen einhängen kannst.

Dieser Ansatz gefällt mir am besten. Möglicherweise kann ich auch den 
timestamp vom Atmel-ICE benutzen. Damit hab ich mich noch nicht wirklich 
befasst, bisher flashe ich nur die hexen damit (Kanonen > Spatzen)..

[Hanno Reimann (Gast)]

c-hater schrieb:
> Und wir wissen nun immer noch nicht, wie genau nun dein Flashvorgang
> aussieht...

bis jetzt: hex erzeugen, dann mit Atmel Studio via ICE flashen, fertig.
Was da drin passiert, hat mich bisher noch nicht interessiert - 
Hauptsache es funzt.. Also Atmel Studio analysieren..?

[TestX (Gast)]

Als alternative gibt es einige UUID ICs die per i2c oder one-wire lesbar 
sind. Ist meistens einfacher und günstiger als Prozesse zu ändern.

[c-hater (Gast)]

Hanno Reimann schrieb:

> Der Bestücker will die Atmels vor dem
> Bestücken programmieren

[...]

> Also Atmel Studio analysieren..?

Wenn der Bestücker das Atmel-Studio zum Flashen verwendet, könnte das 
tatsächlich zum Ziel führen. Allerdings halte ich das für sehr, sehr 
unwahrscheinlich. Weil:

> und der will schnell fertig
> sein...

Dann wird er ganz sicher nicht das Atmel-Studio zu Flashen verwenden, 
oder er müsste völlig bescheuert sein...

Also sollte dir das weitere Vorgehen klar sein: den Bestücker fragen, 
was er verwendet und am besten auch gleich nach seiner Schnittstelle zum 
Einbinden exemplar-abhängiger Änderungen im "Flashgut".

Die Tools, die Bestücker verwenden, haben alle sowas. Entweder direkt 
eingebaut oder dadurch, dass das eigentlich Flash-Tool in ein Script 
eingebettet ist, aus dem sich auch andere Programme aufrufen lassen.

Hat dein Bestücker sowas nicht: Such' dir besser einen anderen. Der ist 
nicht professionell.

[Marc V. (Firma: Vescomp) (logarithmus)]

Hanno Reimann schrieb:
> bis jetzt: hex erzeugen, dann mit Atmel Studio via ICE flashen, fertig.
> Was da drin passiert, hat mich bisher noch nicht interessiert -
> Hauptsache es funzt.. Also Atmel Studio analysieren..?

 Nein.
 atprogram benutzen.
 Wenn es, wie du sagst über ICE geht:

  atprogram -t jtagicemkii -i jtag -d atmega328p write -ee -o 0x100 --values ABCD

 Damit schreibt dein Bestücker Timestamp (ABCD) ins Eeprom ab Adresse
 0x100 (über JTAG) oder mit -i isp über ISP.

 Hoffentlich ist der imstande, etwas entsprechendes zu schreiben...

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

c-hater schrieb:
> Dann wird er ganz sicher nicht das Atmel-Studio zu Flashen verwenden,
> oder er müsste völlig bescheuert sein...

Er nimmt es her. Weil der Atmel-ICE es verlangt. Er hatte vorher einige 
schlechte Erfahrungen mit verschiedenen Sticks gemacht.
Bescheuert stimmt nicht ganz - er ist ein Nordlicht...

c-hater schrieb:
> Also sollte dir das weitere Vorgehen klar sein: den Bestücker fragen,
> was er verwendet und am besten auch gleich nach seiner Schnittstelle zum
> Einbinden exemplar-abhängiger Änderungen im "Flashgut".

Wie gesagt: Atmel-Studio und ICE. Damit hat er bisher am wenigsten 
Ausschuss produziert. Obwohl das bestimmt nicht daran lag...

c-hater schrieb:
> Die Tools, die Bestücker verwenden, haben alle sowas. Entweder direkt
> eingebaut oder dadurch, dass das eigentlich Flash-Tool in ein Script
> eingebettet ist, aus dem sich auch andere Programme aufrufen lassen.

sowas ähnliches hatte ich ihm auch zur Verfügung gestellt, aber er war 
nicht überzeugt. Zumal er (immer noch !) Probleme mit den Fuses hat.
Was für Tools haben denn die Bestücker? Würde mich interessieren.

c-hater schrieb:
> Hat dein Bestücker sowas nicht: Such' dir besser einen anderen. Der ist
> nicht professionell.

Unprofessionell - das stimmt. Aber mein Kunde schwört auf ihn - er sitzt 
im Nachbardorf.... und das ist ein unschlagbares Argument.

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

Marc V. schrieb:
> ... Damit schreibt dein Bestücker Timestamp (ABCD) ins Eeprom ab Adresse
>  0x100 (über JTAG) oder mit -i isp über ISP.

Geil. Werde ich nachher gleich mal checken, mal sehen, was es hier für 
Hürden gibt... Werde berichten.

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

Marc V. schrieb:
> Hoffentlich ist der imstande, etwas entsprechendes zu schreiben..

Absolut nicht.

[wendelsberg (Gast)]

Wer nimmt denn anschliessend die Geraete in Betrieb?
Kannst Du evtl. beim ersten Einschalten eine Seriennummer in den EEPROM 
schreiben?

wendelsberg

[Robin S. (der_r)]

wendelsberg schrieb:
> Kannst Du evtl. beim ersten Einschalten eine Seriennummer in den EEPROM
> schreiben?

Das wäre auch mein Vorschlag. Beispielsweise in den Sockel zum Flashen 
auch noch den UART an den PC durchverbinden. Der AVR wird beim Startup 
prüfen, ob bereits eine Zeit im EEPROM steht, wenn nein:

- AVR sendet per UART kurzen Befehl an den PC, wo ein kleines Programm
  läuft
- PC antwortet mit Uhrzeit
- AVR schreibt diese Uhrzeit ins EEPROM
- Beim nächsten Startup steht bereits ein Wert != 0 an
  der EEPROM-Speicherstelle
  -> PC-Kontaktierung wird übersprungen
  -> UART kann normal verwendet werden


So ein Programm wäre in C beispielsweise mit wenigen Zeilen als 
Konsolenanwendung realisierbar. Als UART-Bridge könnte man die üblichen 
FT232RL-Platinchen vom Chinesen verwenden.

[Hanno Reimann (Gast)]

wendelsberg schrieb:
> Wer nimmt denn anschliessend die Geraete in Betrieb?

Inbetriebnahme erfolgt durch meinen Kunden. Der Bestücker testet 
Stichproben aus der Produktion - habe Prüfpunkte auf der Platine - 
mittels Nadeladapter und 3 Spannungsmessungen. Ein umfassendes 
Prüfprogramm ist ihm zu aufwendig.

> Kannst Du evtl. beim ersten Einschalten eine Seriennummer in den EEPROM
> schreiben?

Beim ersten Einschalten könnte man eine Seriennummer schreiben. Das 
setzt aber ein kleines Programm im PC voraus (Mini-Datenbank). Wurde 
schon bis zum Umfallen diskutiert, aber es wird zu aufwendig empfunden.
Das war mein erster Vorschlag zu dem Thema. Aber die wollen letztendlich 
nur noch einen Stichprobentest machen... wenn  die ersten 100 
durchgelaufen sind.

[Hanno Reimann (Gast)]

Robin S. schrieb:
> Das wäre auch mein Vorschlag. Beispielsweise in den Sockel zum Flashen
> auch noch den UART an den PC durchverbinden. Der AVR wird beim Startup
> prüfen, ob bereits eine Zeit im EEPROM steht, ...

Ja, den Sockel zu erweitern, wäre gerade noch so machbar (mehr trau ich 
denen ohne Hilfestellung nicht zu), aber da möchte ich doch gerne 
(gezwungenermaßen) dabei sein. Hab ich schon öfters erlebt, dass 
woanders Mist gemacht wird, und Schuld ist immer die Software. Kennt das 
jemand noch?

Leider ist mir das unangenehm weit - von Bayern nach NRW-Nordecke. 
Soweit möchte ich das nicht treiben... also so einfach wie möglich. Da 
ist der Grund für den timestamp.

[Hanno Reimann (Gast)]

Habe die ganze Geschichte nochmal weiter gedacht:

Kommt ein Konkurrent meines Kunden zu diesem Bestücker und drückt ihm 
ein paar Scheinchen in die Hand für das Schreiben eines 
Wunsch-Timestamps.
Was macht der? Stellt die PC-Uhr um. Super. Die Raubkopie erscheint 
damit echt.

Also muss man hier die Zeit über TCPIP (vom Zeitserver) holen. Dann ist 
die Geschichte schon etwas erschwert.
Außerdem muss vor der Verwendung des Timestamps noch eine 
Sicherheitskodierung über diesen laufen - man muss ja auch nicht gleich 
an der Seriennummer erkennen, dass das eine Zeitangabe ist.

Somit wird hier doch noch etwas mehr Gehirnschmalz einfließen müssen, 
und der Aufwand wird auch nicht geringer.

Nur gut, dass eine Dekodierung nicht erwünscht wird - die Seriennummer 
wird (wie seit Jahrzehnten) per Hand auf den Etikettendrucker 
übertragen, damit ist die Vebindung zum Endkunden bei der Auslieferung 
fixiert.

[Marc V. (Firma: Vescomp) (logarithmus)]

Hanno Reimann schrieb:
> Also muss man hier die Zeit über TCPIP (vom Zeitserver) holen. Dann ist
> die Geschichte schon etwas erschwert.
> Außerdem muss vor der Verwendung des Timestamps noch eine
> Sicherheitskodierung über diesen laufen - man muss ja auch nicht gleich
> an der Seriennummer erkennen, dass das eine Zeitangabe ist.
>
> Somit wird hier doch noch etwas mehr Gehirnschmalz einfließen müssen,
> und der Aufwand wird auch nicht geringer.

 Aus Erfahrung gesprochen:
 Je mehr Aufwand mit Schutz getrieben wird, desto weniger ist es das
 Programm überhaupt wert, geschützt zu werden.

 Und wenn beide Seiten (Entwickler und Bestücker) nicht einmal imstande
 sind, das Ganze anständig durchzuziehen, wird es echt tragikomisch...

[Jobst M. (jobstens-de)]

... und dann hat der Bestücker einen Gang-Programmer und N Geräte haben 
die selbe Nummer ;-)

Bei entsprechender Stückzahl würde ich mir Gedanken über eine 
Programmierhardware machen. Flash-Chip und RTC drauf.
Aufstecken, Spannung dran, (Knopf drücken,) Warten auf grüne (oder rote) 
LED, Spannung ab, abstecken.
Bei Bedarf kann er sich die vergebenen Nummern (und ob Erfolg oder 
nicht) auch merken.
Und wenn am Ende die Anzahl von der gelieferten abweicht, darf der 
Bestücker ein wenig Zeit mit Dir verbringen und erklären, wie es dazu 
kommt.


Gruß

Jobst

[Hanno Reimann (Gast)]

Jobst M. schrieb:
> Und wenn am Ende die Anzahl von der gelieferten abweicht, darf der
> Bestücker ein wenig Zeit mit Dir verbringen und erklären, wie es dazu
> kommt.

Dann ist es zu spät.

[Hanno Reimann (Gast)]

Marc V. schrieb:
> Aus Erfahrung gesprochen:
>  Je mehr Aufwand mit Schutz getrieben wird, desto weniger ist es das
>  Programm überhaupt wert, geschützt zu werden.

Leider ist es in diesem Fall nicht so. Die Konkurrenz (sehr mächtig, 
Marktführer, weltweite Niederlassungen) hat ein Auge auf dieses Modul. 
Und sie arbeitet mit äußerst unlauteren Mitteln.
Also ist ein gewisser Schutz unumgänglich.

[Hanno Reimann (Gast)]

Jobst M. schrieb:
> Bei entsprechender Stückzahl würde ich mir Gedanken über eine
> Programmierhardware machen. Flash-Chip und RTC drauf.
> Aufstecken, Spannung dran, (Knopf drücken,) Warten auf grüne (oder rote)
> LED, Spannung ab, abstecken.

Dieses Thema wurde schon vor einem Jahr diskutiert und - verworfen. 
Allerdings hält sich die Stückzahl im Rahmen (1-2k/j) - ich sehe das als 
noch grenzwertig für einen erhöhten Aufwand.
Und leider werden solche Entscheidungen a) aus dem Bauch und b) aus 
Kostengründen getroffen.
"Wer zahlt, schafft an"

[Jobst M. (jobstens-de)]

Hanno Reimann schrieb:
> Dann ist es zu spät.

Na gut, dann besser unentdeckt lassen ...


Gruß

Jobst

[Upgrade (Gast)]

Falls möglich, den 328 zu einem 328PB "upgraden". Der enthält schon in 
der Hardware eine 10-Byte lange ID...

[Stefan F. (Gast)]

Dein ganzes Konzept ist mir noch sehr unklar.

Verstanden habe ich bisher, dass dein Bestücker die Mikrocontroller mit 
individuellen zeitstempeln ausstatten soll, bevor sie eingelötet werden.

Das Ganze soll "irgendwie" vor Raubkopien schützen. Wie werden denn 
später die Zeitstempel auf Gültigkeit geprüft?

[Marc V. (Firma: Vescomp) (logarithmus)]

Hanno Reimann schrieb:
> Außerdem muss vor der Verwendung des Timestamps noch eine
> Sicherheitskodierung über diesen laufen - man muss ja auch nicht gleich
> an der Seriennummer erkennen, dass das eine Zeitangabe ist.
>
> Somit wird hier doch noch etwas mehr Gehirnschmalz einfließen müssen,
> und der Aufwand wird auch nicht geringer.

Jobst M. schrieb:
> Bei entsprechender Stückzahl würde ich mir Gedanken über eine
> Programmierhardware machen. Flash-Chip und RTC drauf.

 Genau.
 Es ist ein einmaliger Aufwand für die Hardware und entsprechende
 Software.
 Mit ESP anstatt RTC hätte man sogar die Kontrolle in Echtzeit und
 kann z.B. 100 Timestamps vergeben, danach ist (bis auf weiteres)
 Schluss.

[chris_ (Gast)]

Für das Compile Datum kann man folgendes in den Code einfügen:

#define MCSOFTBUFSIZE 128

char McSoftVersionBuffer[MCSOFTBUFSIZE];
char * position_pointer=m_strcpy(McSoftVersionBuffer,VersionInfo,&McSoftVersionBuffer[MCSOFTBUFSIZE]);

  // if compile with the GCC we have data and time information
  #ifdef __GNUC__

    position_pointer=strcpy(position_pointer,(char *) "compile date: ",   &McSoftVersionBuffer[MCSOFTBUFSIZE]);
    position_pointer=strcpy(position_pointer,(char *) __DATE__, &McSoftVersionBuffer[MCSOFTBUFSIZE]);
    position_pointer=strcpy(position_pointer,(char *) "  compile time",   &McSoftVersionBuffer[MCSOFTBUFSIZE]);
    position_pointer=strcpy(position_pointer,(char *) __TIME__, &McSoftVersionBuffer[MCSOFTBUFSIZE]);
  #endif

[Joachim B. (jar)]

und zusätzlich ein 1W Seriennummer bestücken ist keine Lösung?

https://www.maximintegrated.com/en/products/digital/memory-products/DS2401.html

[Hanno Reimann (Gast)]

Marc V. schrieb:
> Es ist ein einmaliger Aufwand für die Hardware und entsprechende
>  Software.

Richtig. Ist auch mein Favorit. Allerdings muss ich das Ganze nochmal in 
einer Diskussion aufwärmen.

> Mit ESP anstatt RTC hätte man sogar die Kontrolle in Echtzeit und
>  kann z.B. 100 Timestamps vergeben, danach ist (bis auf weiteres)
>  Schluss.

Das ist nett, aber die Stückzahl ist um einiges höher. Nehme RTC.

[Hanno Reimann (Gast)]

Joachim B. schrieb:
> und zusätzlich ein 1W Seriennummer bestücken ist keine Lösung?

Nein. Platine wird schon produziert, es ist nur im Rahmen der 
Programmierung noch was möglich...

[Hanno Reimann (Gast)]

chris_ schrieb:
> Für das Compile Datum kann man folgendes in den Code einfügen:
> #define MCSOFTBUFSIZE 128
> ....

 Das muss ich mir in einer ruhigen Minute beschnüffeln, gute Idee das..

[Marc V. (Firma: Vescomp) (logarithmus)]

Hanno Reimann schrieb:
>> Mit ESP anstatt RTC hätte man sogar die Kontrolle in Echtzeit und
>>  kann z.B. 100 Timestamps vergeben, danach ist (bis auf weiteres)
>>  Schluss.
>
> Das ist nett, aber die Stückzahl ist um einiges höher. Nehme RTC.

 LOL.
 Heute werden 100 Timestamps beantragt und genehmigt.
 Danach ist Schluss.

 In einer Woche werden dann wieder 50 Timestamps beantragt und
 genehmigt.

 Nach weiteren 4 Wochen werden...

[Hanno Reimann (Gast)]

Marc V. schrieb:
> Heute werden 100 Timestamps beantragt und genehmigt.
>  Danach ist Schluss.
>
>  In einer Woche werden dann wieder 50 Timestamps beantragt und
>  genehmigt.
>
>  Nach weiteren 4 Wochen werden...

Hab das schon diskutiert. Naja, der Aufwand...
Eigentlich - um den Aufwand auf der Bestückerseite niedrig zu halten - 
müßte ich für jede Platine eine eigene HEX liefern. Könnte bei mir in 
der DaBa geführt werden, aber eine Garantie für eine Doppelnummer gibt 
es hier auch nicht (Bestücker könnte die gleiche HEX mehrfach 
verwenden..)

[Marc V. (Firma: Vescomp) (logarithmus)]

Hanno Reimann schrieb:
> Hab das schon diskutiert. Naja, der Aufwand...
> Eigentlich - um den Aufwand auf der Bestückerseite niedrig zu halten -
> müßte ich für jede Platine eine eigene HEX liefern. Könnte bei mir in
> der DaBa geführt werden, aber eine Garantie für eine Doppelnummer gibt
> es hier auch nicht (Bestücker könnte die gleiche HEX mehrfach
> verwenden..)

 Nein, kann der nicht. 100 Stück sind 100 Stück und nicht 105 oder
 110.

 Und wenn die zu flashende Hexdatei in deinem Programmiergerät steht,
 noch dazu schön verschlüsselt, kann der gar nichts mehr machen.
 Updates und ev. ein neues Schlüssel geht wieder über ESP, die
 täglichen Flashquoten werden zurückgesendet.

 Kann alles mit verhältnismässig wenig Aufwand realisiert werden.

[Hanno Reimann (Gast)]

Marc V. schrieb:
> Und wenn die zu flashende Hexdatei in deinem Programmiergerät steht,
>  noch dazu schön verschlüsselt, kann der gar nichts mehr machen.
>  Updates und ev. ein neues Schlüssel geht wieder über ESP, die
>  täglichen Flashquoten werden zurückgesendet.

Habe das nochmal diskutiert - es ist inzwischen schon wieder ein anderes 
Konzept fixiert: die ersten paar hundert macht der Bestücker über 
Nadeladapter und Atmel-ICE. Geht zu langsam. Dann soll der Chiplieferant 
das übernehmen (er ist billiger). Wenn ich den erst mal kenne, kann ich 
die Geschichte mit ihm aushandeln. Aber er steht noch nicht fest...

Zum Schluss: recht vielen Dank für die reichlichen Anregungen.
Damit möchte ich den Thread schließen.

[Hanno Reimann (Gast)]

Nachtrag:

habe eine undokumentierte Möglichkeit gefunden, die Seriennummer des 
Chips vom ATMega328P (nicht PB!) auszulesen, damit ist alles andere 
plötzlich nicht mehr aktuell.
Hier haben wir die unverwechselbare, einmalige SN, die ich eigentlich 
über "timestamp" erzeugen wollte. Und an dieser Nummer kann keiner mehr 
rütteln, weil sie werksseitig vergeben und gebrannt wird..

4 Beispiele (gerade erzeugt):

ATMEL328P(1):
Signature :  0x1E 0x95 0xF
Serial Number :  0x55 0x35 0x35 0x30 0x34 0x33 0xFF 0x14 0x23 0x28

ATMEL328P(2):
Signature :  0x1E 0x95 0xF
Serial Number :  0x55 0x35 0x35 0x30 0x34 0x33 0xFF 0x14 0x19 0x23

ATMEL328P(3):
Signature :  0x1E 0x95 0xF
Serial Number :  0x55 0x35 0x35 0x30 0x34 0x33 0xFF 0xF 0x2C 0x16

ATMEL328P(4):
Signature :  0x1E 0x95 0xF
Serial Number :  0x55 0x35 0x35 0x30 0x34 0x33 0xFF 0x14 0x25 0x27

[Jörg W. (dl8dtl) (Moderator)]

Hanno Reimann schrieb:
> habe eine undokumentierte Möglichkeit gefunden, die Seriennummer des
> Chips vom ATMega328P (nicht PB!) auszulesen

Nun könntest du uns ja zumindest nicht dumm sterben lassen und
verraten, woher du sie liest. ;-)

„Undokumentiert“ heißt allerdings auch, dass Atm^H^H^HMicrochip das
Verhalten von heute auf morgen ändern kann, ohne dich per PCN oder
dergleichen darüber zu informieren.

[Hanno Reimann (Gast)]

Jörg W. schrieb:
> Nun könntest du uns ja zumindest nicht dumm sterben lassen und
> verraten, woher du sie liest. ;-)

Schnell im Arduino:

 #include <avr/boot.h>

void print_val(char *msg, uint8_t val)
{
    Serial.print(msg);
    Serial.println(val, HEX);
}

void setup(void)
{

    Serial.begin(9600);
    while (!Serial) ;
#define SIGRD 5
#if defined(SIGRD) || defined(RSIG)
    Serial.print("Signature : ");
    for (uint8_t i = 0; i < 5; i += 2) {
        Serial.print(" 0x");
        Serial.print(boot_signature_byte_get(i), HEX);
    }
    Serial.println();

    Serial.print("Serial Number : ");
    for (uint8_t i = 14; i < 24; i += 1) {
        Serial.print(" 0x");
        Serial.print(boot_signature_byte_get(i), HEX);
    }
    Serial.println();
#endif
}

> „Undokumentiert“ heißt allerdings auch, dass Atm^H^H^HMicrochip das
> Verhalten von heute auf morgen ändern kann, ohne dich per PCN oder
> dergleichen darüber zu informieren.

Wenn das geschieht, setzen wir den 328PB ein. Dort ist es dokumentiert.

[Jörg W. (dl8dtl) (Moderator)]

OK, also aus den weiteren Bytes der Signature Row.

[Jobst M. (jobstens-de)]

Hanno Reimann schrieb:
> 4 Beispiele (gerade erzeugt):

Und sie geben bei jedem Zugriff auch die selben Werte?
Sind also nicht Random?

Und wenn das Hex-File nun auf einen weiteren Chip (mit weiterer SN) 
geschrieben wird - wie ist das dann geschützt?

BTW: Wäre ich der große Konkurent, der mit allen Mitteln arbeitet, würde 
ich mir ein Gerät von Dir kaufen und den Chip knacken und auslesen.


Gruß

Jobst

[Hanno Reimann (Gast)]

Jobst M. schrieb:
> Und sie geben bei jedem Zugriff auch die selben Werte?
> Sind also nicht Random?

Jedesmal der gleiche Wert

> Und wenn das Hex-File nun auf einen weiteren Chip (mit weiterer SN)
> geschrieben wird - wie ist das dann geschützt?

geschützt ist es nicht, aber beim Hersteller (meinem Kunden) in seiner 
Datenbank gespeichert.
Wenn andere Seriennummern auftreten sollten, dann kann man dem nachgehen
Das ist der momentane Stand. Aber noch nicht aller Tage Ende - mein 
Kunde will alles nochmal überschlafen...

> BTW: Wäre ich der große Konkurent, der mit allen Mitteln arbeitet, würde
> ich mir ein Gerät von Dir kaufen und den Chip knacken und auslesen.

und was nützt das? Natürlich kann man die Hardware kopieren, die 
Software weniger gut (lockbit ist gesetzt). Selbst wenn, dann hat man 
nur das hexfile, kann also so ohne Weiteres auch kein reengineering 
betreiben.

Hier geht es auch nicht vorrangig um ein Kopieren, sondern dass man 
verhindert, dass Fehlfunktionen eingebaut werden. Tritt eine solche auf, 
dann liefert die Auflistung in der DaBa den Beweis, dass hier kriminelle 
Kräfte am Werk waren und absichtlich rumgefummelt haben...

[Jobst M. (jobstens-de)]

Hanno Reimann schrieb:
> Wenn andere Seriennummern auftreten sollten, dann kann man dem nachgehen

Als Konkurent würde ich das dann ja auch unter meinem Namen verkaufen.


Hanno Reimann schrieb:
> die Software weniger gut (lockbit ist gesetzt).

Deshalb schrieb ich ja 'Chip knacken', das Lockbit ist kein wirkliches 
Hindernis, wenn man mit großen Mitteln dran geht.


Hanno Reimann schrieb:
> Hier geht es auch nicht vorrangig um ein Kopieren, sondern dass man
> verhindert, dass Fehlfunktionen eingebaut werden.

Aha. Oben war es noch die Angst vor einer Kopie. ...?


> Tritt eine solche auf,
> dann liefert die Auflistung in der DaBa den Beweis, dass hier kriminelle
> Kräfte am Werk waren und absichtlich rumgefummelt haben...

Nö. Wie denn?


Ich habe den Eindruck, als wenn sich dort nicht die richtigen Gedanken 
gemacht werden oder man keine Ahnung hat.

Wenn Ihr vor all dem Angst habt, dann lasst die Boards sockeln und 
steckt den Chip selber rein oder lasst Euch die unprogrammierten Boards 
liefern, welche dann per ISP programmiert werden.

DAS ist die billigste Lösung vor all den Maßnahmen gegen einen 
unvertraulichen Bestücker.


Gruß

Jobst

[Joachim B. (jar)]

Hanno Reimann schrieb:
> Joachim B. schrieb:
>> und zusätzlich ein 1W Seriennummer bestücken ist keine Lösung?
>
> Nein. Platine wird schon produziert, es ist nur im Rahmen der
> Programmierung noch was möglich...

das ist aber eine falsche Entwicklung, auch Platinen können ein 
re-design bekommen, für die erste Serie kann man in Handarbeit an freie 
Portpins vom Atmel 
https://www.maximintegrated.com/en/products/digital/memory-products/DS2401.html 
nachrüsten.

[Hanno Reimann (Gast)]

Jobst M. schrieb:
> Als Konkurent würde ich das dann ja auch unter meinem Namen verkaufen.

Ist zu umständlich. Der Konkurrent hat eigene Lösungen, die er gut 
beherrscht. Aber das heutige Meeting hat ergeben, dass eine böswillige 
Veränderung die größte Gefahr darstellt (-> Beseitigen der Konkurrenz).
Fehlerhafte Geräte gehen ja an den Hersteller zurück. Dann kann man es 
abchecken, ob hier was geändert wurde oder ein wahrer Fehler vorliegt..

Jobst M. schrieb:
> Aha. Oben war es noch die Angst vor einer Kopie. ...?

ich schrieb: vorrangig

Jobst M. schrieb:
> Wenn Ihr vor all dem Angst habt, dann lasst die Boards sockeln und
> steckt den Chip selber rein oder lasst Euch die unprogrammierten Boards
> liefern, welche dann per ISP programmiert werden.

zu teuer.

Jobst M. schrieb:
> Ich habe den Eindruck, als wenn sich dort nicht die richtigen Gedanken
> gemacht werden oder man keine Ahnung hat.

Ich darf weitere Gründe (echte Gründe) nicht anführen...

[Hanno Reimann (Gast)]

Joachim B. schrieb:
> das ist aber eine falsche Entwicklung, auch Platinen können ein
> re-design bekommen, für die erste Serie kann man in Handarbeit...

Habe mich entschlossen, die Seriennummer des Chips zu benutzen. Aufwand 
einige Zeilen Code, sonst nichts. Schau in den Beitrag von 14:34 weiter 
oben..

[Stefan F. (Gast)]

Wenn du das Programm vor böswilligen Veränderungen schützen willst, dann 
bringt eine Prüfsumme und ein Check derselben sicher mehr, als der 
Zeitstempel.

[Jobst M. (jobstens-de)]

Hanno Reimann schrieb:
> zu teuer.

Nein. Das was Du vor hast ist zu teuer und bringt vor allem nichts.


Gruß

Jobst

[Joachim B. (jar)]

Hanno Reimann schrieb:
> Habe mich entschlossen, die Seriennummer des Chips zu benutzen.

ja ist klar aber nur wenn der immer so bleibt bei jeder Serie!

Ich persönlich würde das mit dem Re-Design und extra SerienNr. Chip im 
Hinterkopf behalten, ist ja auch ein guter Verkaufsgrund, neues 
verbessertes Modell (scnr)

[Jörg W. (dl8dtl) (Moderator)]

Joachim B. schrieb:
> ja ist klar aber nur wenn der immer so bleibt bei jeder Serie!

Bei jeder Serie?

Das ist eine Unique ID pro Chip, also letztlich genau das, was oben
schon mal als UUID vorgeschlagen worden war.  Der Unterschied ist
halt nur, dass sie hier von Atmel/Microchip bereits vor der
Auslieferung des Bauelements vorgegeben worden ist.

[Joachim B. (jar)]

Jörg W. schrieb:
> Bei jeder Serie?

das war dein Zitat

Jörg W. schrieb:
> „Undokumentiert“ heißt allerdings auch, dass Atm^H^H^HMicrochip das
> Verhalten von heute auf morgen ändern kann, ohne dich per PCN oder
> dergleichen darüber zu informieren.

mir wäre dann ein echter DS2401 Chip extern lieber

[Jörg W. (dl8dtl) (Moderator)]

Joachim B. schrieb:
> das war dein Zitat

Ach, darauf beziehst du dich.

Ist doch aber recht einfach: er muss die Nummer ohnehin erfassen,
damit wird es beim Auslesen offensichtlich, ob sie vorhanden ist
(und unique) oder nicht.

Das war ansonsten auch ein caveat emptor von mir: ich gehe nicht
ernsthaft davon aus, dass daran irgendwer was ändern wird,
insbesondere natürlich angesichts der Tatsache, dass die Nummer bei
den neueren PB-Typen tatsächlich dokumentiert worden ist.

[Hanno Reimann (Gast)]

Jörg W. schrieb:
> Das ist eine Unique ID pro Chip, also letztlich genau das, was oben
> schon mal als UUID vorgeschlagen worden war.  Der Unterschied ist
> halt nur, dass sie hier von Atmel/Microchip bereits vor der
> Auslieferung des Bauelements vorgegeben worden ist.

Ergänzung zum Thema:
Man verwendet UINs in erster Linie, um eine möglichst einfache 
Identifizierung zu gewährleisten, eine Alternative wäre die Verwendung 
von Attributen.
Oft benutzt man eine Kombination von bedingt eindeutiger Kennung und 
Attribut, etwa mit Hilfe von Zeitstempeln.

Jörg W. schrieb:
> Ist doch aber recht einfach: er muss die Nummer ohnehin erfassen,
> damit wird es beim Auslesen offensichtlich, ob sie vorhanden ist
> (und unique) oder nicht.

Eindeutig.

> Das war ansonsten auch ein caveat emptor von mir: ich gehe nicht
> ernsthaft davon aus, dass daran irgendwer was ändern wird,
> insbesondere natürlich angesichts der Tatsache, dass die Nummer bei
> den neueren PB-Typen tatsächlich dokumentiert worden ist.

Geh ich auch nicht von aus. Ich denke, die UIN ist schon länger im Chip 
(und Vorgänger), ohne dass hier eine Veröffentlichung erfolgte. Mit 
Einführung der PB-Serie kann man nun - da dokumentiert - mehr Dollars 
verlangen. Hab mal Mouser gecheckt, es sind wirklich 35 cent 
Unterschied.
Eine gute Strategie...

[Jörg W. (dl8dtl) (Moderator)]

Hanno Reimann schrieb:
> Mit Einführung der PB-Serie kann man nun - da dokumentiert - mehr
> Dollars verlangen.

Meiner Erinnerung nach hat die PB-Serie auch sonst noch paar Features
mehr, irgendwas an den Timern oder dergleichen.  Wobei ich natürlich
nicht ausschließen würde, dass es der gleiche Die ist, der nur als
„alter“ ATmega328P marketingwirksam für ein paar Cent billiger
verkauft wird as der PB.  Selbst das Abschalten der nicht mit
verkauften Features ist hardwaremäßig kein Thema.

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

Jörg W. schrieb:
> Wobei ich natürlich
> nicht ausschließen würde, dass es der gleiche Die ist, der nur als
> „alter“ ATmega328P marketingwirksam für ein paar Cent billiger
> verkauft wird as der PB.

Das soll nach Herstellerangeben nicht stimmen, ist ein neuer die:

Compared to existing ATmega328 variants, the following enhancements or 
additional features are available in ATmega328PB:
• PTC - Peripheral Touch Controller.
• CFD - Clock Failure Detection mechanism.
• OCM1C2 - Output Compare Modulator.
• USART start frame detection is available in all sleep modes
• Analog Comparator output is available on a pin. This pin is 
multiplexed with PE0.
• Unique device ID to identify the device
• Additional USART
• Additional SPI
• Additional TWI
• Additional Timer/Counters

Was mich stört, ist die unterschiedliche pin-Belegung:

32-pin TQFP/MLF package 
Pin   ATmega328   ATmega328PB
 3    GND         PE0/ACO
 6    VCC         PE1
19    ADC6        ADC6/PE2
22    ADC7        ADC7/PE3

[Jobst M. (jobstens-de)]

Hanno R. schrieb:
> Das soll nach Herstellerangeben nicht stimmen, ist ein neuer die:

Schreibt er doch. Lies Dir seinen Satz nochmal genau durch.

Hanno R. schrieb:
> Was mich stört, ist die unterschiedliche pin-Belegung:

Nutze sie einfach nicht!
Lass die Pins eben auf GND und VCC liegen ...


Gruß

Jobst

[Jörg W. (dl8dtl) (Moderator)]

Jörg W. schrieb:
> Das war ansonsten auch ein caveat emptor von mir: ich gehe nicht
> ernsthaft davon aus, dass daran irgendwer was ändern wird, insbesondere
> natürlich angesichts der Tatsache, dass die Nummer bei den neueren
> PB-Typen tatsächlich dokumentiert worden ist.

Eins fiel mir dazu noch ein: es könnte natürlich allemal passieren,
dass dir irgendwann einfach mal jemand ältere ICs vorsetzt, die das
Feature noch nicht haben.

[Joachim B. (jar)]

Jörg W. schrieb:
> Eins fiel mir dazu noch ein: es könnte natürlich allemal passieren,
> dass dir irgendwann einfach mal jemand ältere ICs vorsetzt, die das
> Feature noch nicht haben.

es gibt ja second source Verkäufe für ICs und da bin ich wieder bei

Joachim B. schrieb:
> mir wäre dann ein echter DS2401 Chip extern lieber

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

Jörg W. schrieb:
> es könnte natürlich allemal passieren,
> dass dir irgendwann einfach mal jemand ältere ICs vorsetzt, die das
> Feature noch nicht haben.

..das muss abgewartet werden. Jede Neubestellung muss halt darauf 
gecheckt werden. Ein kleiner Aufwand gegenüber der Einsparung durch die 
UID.
Ich checke in der Software erstmal die UID, wenn das in die Hose geht, 
dann werden die Teile anderweitig eingesetzt. Oder gehen zurück. Sie 
sind ja noch nicht verlötet.

[Marc V. (Firma: Vescomp) (logarithmus)]

Hanno R. schrieb:
> Ich checke in der Software erstmal die UID, wenn das in die Hose geht,
> dann werden die Teile anderweitig eingesetzt. Oder gehen zurück. Sie
> sind ja noch nicht verlötet.

 Checken geht, aber selber flashen nicht ?

 Irgendwas stimmt da nicht...

[Uhu U. (uhu)]

Jörg W. schrieb:
> Meiner Erinnerung nach hat die PB-Serie auch sonst noch paar Features
> mehr, irgendwas an den Timern oder dergleichen.

Siehe Anhang.

[Jörg W. (dl8dtl) (Moderator)]

Uhu U. schrieb:
> Siehe Anhang.

Ich glaube, eine URL hätte genügt ;), zumal's hier ja nicht direkt
um die PBs ging.

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

Marc V. schrieb:
> Checken geht, aber selber flashen nicht ?

checken über die firmware ja, aber warum flashen, wenn die UID nicht 
ausgelesen werden kann oder nicht exisitiert? Es gibt noch einige andere 
Projekt mit den 328er, die die UID nicht benötigen. Die können dann 
dafür zur Seite gelegt werden. Allerdings glaube ich nicht, dass die UID 
nicht auslesbar ist. Auch bei älteren Teilen. Die Zukunft wirds 
zeigen...
Ausserdem soll der Lieferant der 328er die Teile flashen - der hat das 
richtige Equipment dafür und ist dazu noch recht preiswert.

[Marc V. (Firma: Vescomp) (logarithmus)]

Hanno R. schrieb:
> Ausserdem soll der Lieferant der 328er die Teile flashen - der hat das
> richtige Equipment dafür und ist dazu noch recht preiswert.

 War das nicht der Bestücker ?

Hanno Reimann schrieb:
> .. leider am Thema vorbei. Der Bestücker will die Atmels vor dem
> Bestücken programmieren,

 Wenn es jetzt plötzlich der Lieferant macht, dann ist alles hinfällig
 und man braucht die UID gar nicht.

 Irgendwie stimmt das immer noch nicht...

[Uhu U. (uhu)]

Jörg W. schrieb:
> Ich glaube, eine URL hätte genügt

Hab ich leider nicht...

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

Marc V. schrieb:
> Wenn es jetzt plötzlich der Lieferant macht, dann ist alles hinfällig
>  und man braucht die UID gar nicht.

.. wir brauchen sie noch für einen ganz anderen Zweck, aber das würde 
hier zu weit führen.

[Alex W. (Gast)]

Hanno Reimann schrieb:
> Joachim B. schrieb:
>> das ist aber eine falsche Entwicklung, auch Platinen können ein
>> re-design bekommen, für die erste Serie kann man in Handarbeit...
>
> Habe mich entschlossen, die Seriennummer des Chips zu benutzen. Aufwand
> einige Zeilen Code, sonst nichts. Schau in den Beitrag von 14:34 weiter
> oben..

Das wird dir aber nicht viel bringen! Wenn ich dein Konkurrent wäre,
kaufe ich deine Hardware, schreibe mir eine eigene Firmware dafür mit 
Bootcode. Ab einem voreingestellten Trigger lass ich das Ding 
abschmieren.
Der Bootloader löscht mein Programm und um dich zu ärgern setze ich noch 
zusätzlich die Lockbits für den Ausleseschutz.

[Alex W. (Gast)]

fasst vergessen:
Die Seriennummer deines Chips ist dabei eindeutig von dir! Wer in der 
Produktionskette ist dann als Krimineller beschuldigt?

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

Alex W. schrieb:
> Die Seriennummer deines Chips ist dabei eindeutig von dir!

wie das?? Der Hersteller des Chips meißelt sie ein. Auch ich, und auch 
kein anderer, kann sie beeinflussen. Ich kann Deine Gedankengänge nicht 
verfolgen....

[Alex W. (a20q90)]

Hanno R. schrieb:
> Alex W. schrieb:
> Die Seriennummer deines Chips ist dabei eindeutig von dir!
>
> wie das?? Der Hersteller des Chips meißelt sie ein. Auch ich, und auch
> kein anderer, kann sie beeinflussen. Ich kann Deine Gedankengänge nicht
> verfolgen....

Eben genau der von dir verwendete IC hat eine Seriennummer die bei dir 
durch die Produktion gehen. somit ist eindeutig nachvollziehbar dass der 
Chip von dir stammt weil eben keine Veränderung der Seriennummer möglich 
ist. und das ist dein Problem. der Inhalt des Chips kann von deinem 
Konkurrenten geändert werden und spielt somit als wäre das System von 
dir! und somit hast du keine Möglichkeit herauszufinden ob das ein 
Fehler von dir ist oder ein böswilliger von deinem Konkurrenten, denn 
ihr habt die Möglichkeit nicht nachzuvollziehen auch nach dem Verkauf an 
den Chip irgendetwas verändert wurde

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

Alex W. schrieb:
> ...der Inhalt des Chips kann von deinem
> Konkurrenten geändert werden und spielt somit als wäre das System von
> dir! und somit hast du keine Möglichkeit herauszufinden ob das ein
> Fehler von dir ist oder ein böswilliger von deinem Konkurrenten...

das wäre wirklich kriminell, aber nicht unmöglich.

>> Hast Du einen Vorschlag? <<

Ist sicherlich bei dieser Diskussion auch für etliche andere 
interessant.

Ich meine, irgendwo sollte der Aufwand auch noch vertretbar sein.
Wenn der Aufwand zum Schutz den Aufwand der Firmware übersteigt, läuft 
was schief.

Der Firmwareaufwand lag bei ~250 h und hat 2270 endgültige Codezeilen 
erzeugt. In dieser Zeit sind Labortests, Feldtests und Zertifizierung 
eingeschlossen.

Mein Bauch sagt mir, weitere 10% dieser Zeit sind für Sicherheit nicht 
zu viel, aber dann ist auch hier Ende der Fahnenstange...

[Marc V. (Firma: Vescomp) (logarithmus)]

Hanno R. schrieb:
> Der Firmwareaufwand lag bei ~250 h und hat 2270 endgültige Codezeilen
> erzeugt. In dieser Zeit sind Labortests, Feldtests und Zertifizierung
> eingeschlossen.

 Das wird bestimmt nicht kopiert.

 Bei so wenig Gesammtaufwand kann ev. nur die Idee geklaut werden,
 die Firmware entwickelt man in ein paar Tagen oder Wochen selber.

 Die ganze Diskussion um Schutz war praktisch umsonst.

[Bernd K. (prof7bit)]

Marc V. schrieb:
> Hanno R. schrieb:
>> 2270 endgültige Codezeilen

Also ein trivialstes Kleinstprojekt. Erklär einem fähigen Entwicklerteam 
was das Gerät genau machen soll, gib ihnen ein paar Exemplare davon zum 
Rumspielen und die entwickeln einen Klon davon (vom gesamten Gerät!) 
from scratch binnen zwei Wochenenden. Und der kann dann im Gegensatz zum 
Orginal zusätzlich noch Kaffee kochen und Bier holen und ist 2€ billiger 
weil keine teuren Atmels verwendet werden sondern billige ARMs.

2270 Zeilen, das kann man ja fast noch in einem Rutsch durchscrollen 
ohne einmal am Scrollrad umgreifen zu müssen, an guten Tagen hab ich 
sowas an einem Tag runtergerissen.

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

Marc V. schrieb:
> Bei so wenig Gesammtaufwand kann ev. nur die Idee geklaut werden,
>  die Firmware entwickelt man in ein paar Tagen oder Wochen selber.

Wer ist "man"? Ich denke, dass DU es bestimmt nicht sein kannst (hab mal 
einige Deiner threads gelesen..) Aber ich will ja sachlich bleiben.

Hier geht es auch nicht um EINE Idee, sondern um einen Schwall von 
Ideen.
Wie will ich Ideen klauen, wenn ich nur ein HEX habe? Aufwand zu hoch 
dafür.

>  Die ganze Diskussion um Schutz war praktisch umsonst.

Wenn Du nicht weißt, was dahinter steckt, dann schweig bitte still.

Auch wenn es für dieses eine Projekt vielleicht nur einen marginalen 
Nutzen bringt, ist der Nutzen dieser Diskussion doch für viele 
Teilnehmer und Nurleser nicht unter den Tisch zu kehren. Hier sind viele 
Ideen zu Tage gekommen, die sicher für andere Projekte die Weichen 
stellen konnten.

Und damit meine ich sicher nicht nur meine Projekte, sondern die vieler 
anderer auch.

Und schon alleine aus diesem Grund war diese Diskussion sehr nützlich 
und richtungsweisend.

Also nochmal vielen Dank an alle Teilnehmer

[Jobst M. (jobstens-de)]

Bernd K. schrieb:
> Erklär einem fähigen Entwicklerteam
> was das Gerät genau machen soll, gib ihnen ein paar Exemplare davon zum
> Rumspielen und die entwickeln einen Klon davon (vom gesamten Gerät!)
> from scratch binnen zwei Wochenenden.

Nicht notwendig:

Hanno Reimann schrieb:
> Der Konkurrent hat eigene Lösungen, die er gut beherrscht.


Wenn das Progamm ebenso stümperhaft aufgebaut ist, wie an dessen Schutz 
herangegangen wird, ist es das Programm gar nicht Wert.

Die bisherigen Lösungen verhindern zumindest nicht, dass der Mitbewerber 
dazwischen hauen kann. Allerdings habe ich mittlerweile den Eindruck, 
dass Ihr Euch da etwas einbildet, was Ihr vielleicht gerne hättet.
Die einzige, zuverlässige und kostengünstige, wenn auch 
arbeitsintensivere Lösung ist: Selber programmieren der fertigen Boards 
und Direktvertrieb.


Gruß

Jobst

[Marc V. (Firma: Vescomp) (logarithmus)]

Hanno R. schrieb:
> Wer ist "man"? Ich denke, dass DU es bestimmt nicht sein kannst (hab mal
> einige Deiner threads gelesen..) Aber ich will ja sachlich bleiben.

 Sagen wir es mal so:
 Ich habe mehr vergessen als du jemals lernen wirst...
 Und nein, ICH kann es bestimmt nicht sein.
 Normalerweise machen so etwas Lehrlinge im 2. Jahr.
 Dachdecker Lehrlinge.

 Abgesehen davon, zeigt sich, dass ich doch Recht hatte:
Marc V. schrieb:
> Aus Erfahrung gesprochen:
>  Je mehr Aufwand mit Schutz getrieben wird, desto weniger ist es das
>  Programm überhaupt wert, geschützt zu werden.
>
>  Und wenn beide Seiten (Entwickler und Bestücker) nicht einmal imstande
>  sind, das Ganze anständig durchzuziehen, wird es echt tragikomisch...

 Und du bist ja nicht mehr als eine tragikomische Figur, die mit
 Gewalt etwas versucht was weder notwendig ist, noch selbst imstande
 ist, so etwas überhaupt zu machen.

Jobst M. schrieb:
> Hanno Reimann schrieb:
>> Hier geht es auch nicht vorrangig um ein Kopieren, sondern dass man
>> verhindert, dass Fehlfunktionen eingebaut werden.
>
> Aha. Oben war es noch die Angst vor einer Kopie. ...?

Marc V. schrieb:
> Hanno R. schrieb:
>> Ausserdem soll der Lieferant der 328er die Teile flashen - der hat das
>> richtige Equipment dafür und ist dazu noch recht preiswert.
>
>  War das nicht der Bestücker ?

 Soviel zu deiner Glaubwürdigkeit überhaupt.

 Und jetzt träume mal weiter von grossem Marktdurchbruch...

[Stefan F. (Gast)]

> Der Firmwareaufwand lag bei ~250 h. In dieser Zeit sind Labortests,
> Feldtests und Zertifizierung eingeschlossen.

Und da machst du so einen Aufriss? Das ist ein winzig kleines Pillepalle 
Projekt. Dein bisheriger Aufwand, diverse Schutzmethoden zu überdenken, 
war schon unverhältnismäßig hoch.

[Hanno R. (Firma: webatel hanno reimann) (realhanno)]

Hanno R. schrieb:
> Auch wenn es für dieses eine Projekt vielleicht nur einen marginalen
> Nutzen bringt, ist der Nutzen dieser Diskussion doch für viele
> Teilnehmer und Nurleser nicht unter den Tisch zu kehren. Hier sind viele
> Ideen zu Tage gekommen, die sicher für andere Projekte die Weichen
> stellen konnten.
>
> Und damit meine ich sicher nicht nur meine Projekte, sondern die vieler
> anderer auch.
>
> Und schon alleine aus diesem Grund war diese Diskussion sehr nützlich
> und richtungsweisend.
>
> Also nochmal vielen Dank an alle Teilnehmer

Hiermit verabschiede ich mich aus dem inzwischen arg aus dem Ruder 
gelaufenen Thread.
Ich denke, dass Beschimpfungen und Beleidigungen einen eigenen Thread 
erfordern.
Vielleicht unter "Wer ist hier der Größte?"