|
Anzeige
|
Lock bits vs. Clock source auf 8-Bit AVRs
Gast
#903715
Ist es richtig, das ich die Taktquellen Fuses (CKSELX) nicht mehr programmieren kann, wenn ich die Lockbits (LBX) programmiert habe? Oder kann ich doch einerseits durch die Lockbits das neu-programmieren und auslesen des Prozessors verhindern, aber gleichzeitig das neu-Programmieren der Bits für die Taktquelle erlauben? Vielleicht auf einem unkomentierten weg, oder aus dem Bootloader heraus?
Gast
#903717
Stefan wrote: > Ist es richtig, das ich die Taktquellen Fuses (CKSELX) nicht mehr > programmieren kann, wenn ich die Lockbits (LBX) programmiert habe? Ja. Aber was spricht dagegen, die Fusebits vor den Lockbits zu programmieren ?
Gast
#903791
>Aber was spricht dagegen, die Fusebits vor den Lockbits zu programmieren ?
Es wäre nützlich gewesen die Fusebits nach den Lockbits zu
programmieren. So wäre es möglich einen beim Kunden befindlichen
Prozessor, dessen Lockbits programmiert sind, etwa auf eine andere
Taktquelle umzustellen. .Z.B. wenn der interne RC-Oszillator so
abweicht, das die Baudrate nicht stimmt, andererseits aber von ext.
Quarz auf int. RC-Osz. umschalten, wenn er (der Kunde) es möchte.
Dennoch wäre es dem Kunden nicht möglich das Programm wieder auszulesen.
Es gibt da so eine ungenutzte Kombination der LBX bits.
LB2 = 0 und LB1 = 1. Wenn man der Beschreibung folgt, dann könnte es
sein, das man damit zwar das auslesen, aber nicht das programmieren
verhindert.
Hat das schon mal jemand ausprobiert?
Dann hast du aber auch die Software dabei. Also machst du ein Chiperase, setzt die Fusebits, flashst die Software rein und setzt wieder die Lock Bits.
Gast
#903801
>Dann hast du aber auch die Software dabei.
Moment. Ist das ein Missverständnis? Ich habe die SW. Aber nicht
dabei. Ich bin ja nicht bei dem Kunden. Und er hat die SW nicht. Die
wird auf dem Prozessor ausgeliefert.
OK, dann bist du aber ganzschön leichtsinnig: - Einen Kunden nie etwas selbst programmieren lassen (außer das Ding hat einen Idiotensicheren Bootloader) - Nie den internen Oszillator für den UART verwenden (außer vielleicht zum Debuggen)
Gast
#903812
>Einen Kunden nie etwas selbst programmieren lassen (außer das Ding hat >einen Idiotensicheren Bootloader) Lasse ich ihn ja nicht. Er bekommt einen fertig programmierten Prozessor dessen Lock-Bits gesetzt sind. >Nie den internen Oszillator für den UART verwenden. Schnief. Heul. ;-) Darauf läuft es dann hinaus. Muss wohl den externen verwenden. Wie gross ist eigentlich ungefähr so ein entschlüsselnder Bootloader (AES oder sowas)?
Gast
#903815
Ich schrieb:
>Wie gross ist eigentlich ungefähr so ein entschlüsselnder Bootloader
(AES oder sowas)?
Aber das nützt mir ja nichts. Die Fuses für die Taktquelle kann er dann
ja trotzdem nicht selbst programmieren, wegen der Lock-Bits.
Mist.
Ein Kunde sollte den Takt des Controllers nicht ändern müssen / können. Das ist eine zusätzliche und unkalkulierbare Fehlerquelle. Stell Dir vor, der Kunde fust dummerweise auf externen R/C-Oszillator und da ist weit und breit kein R und kein C dran. Und tschüß! Generell sollte ein Kunde überhaupt nichts an der ISP-Schnittstelle zu suchen haben. Bootloader drauf, alle Fuses so setzen, wie sie müssen, Lockbits setzen und fertich! Updates werden über externe Schnittstellen (UART/RS232, Ethernetcontroller, Funk-Modul etc.) erledigt. Die Verschlüsselung muß nicht unbedingt AES sein, Du kannst Dir auch selber etwas ausdenken.
Gast
#905057
Hatten wir nicht mal Programmer-Dongles diskutiert? Also: In der Anwendung wird der Controller verbaut und mit einem Bootloader ausgestattet. Nach außen hin dann eine gescheite Schnittstelle. Muss der Kunde nun das Dingchen neuprogrammieren, bekommt er einen Dongle geschickt: Der besteht aus Batterie, Schnittstelle und ebenfalls einem Controller und dient quasi als Programmträger. Der flasht dann den Controller in der Anwendung und wird dann dem Hersteller zurückgeschickt. Quasi eine Diskette, die mitdenkt. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
