Hey Jungs,
ich muss folgendes tun. Eine Software schreiben, mit der ich die
Variablen (z.B. Verzögerung in ms) nachhinein über UART einstellen kann,
ohne uC neu zu programmieren. Ich bin nicht sicher ob ich das richtig
angehe. Daher wollte ich euch fragen ob meine Vorgehensweise richtig
ist?
Ich muss in diesem Fall Bootloader schreiben, der bei System abfragt ob
ich den Wert der Variablen verändern will. Wenn Bootloader keine
Nachricht über UART bekommt, das die Werte verändert werden sollen, dann
startet der Bootloader das eigentliche Programm, ansonsten er fragt bei
jeder Variable den neuen Wert ab.
Ist das so ungefähr richtig? Oder gibt es einfachere Wege? Kennt jemand
ähnliche Beispiele (Codes) wo ähnliche Aufgaben gelöst wurden? Wie sieht
es dann aus mit der Rechengeschwindigkeit? Ich habe gelesen, dass
EEPROM langsamer zum Lesen und Schreiben ist. Stimmt das? Wenn ja wie
kann ich die Werte, nach dem das eigentlich Programm gestartet ist, ins
Flash holen und im Flash mit diesen Werten arbeiten?
Ich hoffe das waren nicht zu viele Fragen auf einmal.
Gruss
Werte im Flash kann man nicht während des laufenden Programms ändern.
Wahrscheinlich möchtest du die Werte im EEPROM halten, das kann vom
Programm selbst zur Laufzeit geändert werden.
Du musst das Programm dann so ändern, daß
1. Die Variablen bei Bedarf aus dem EEPROM genommen gelesen werden
2. zusätzlich zur normalen Programmfunktion noch laufend der UART
ausgelesen wird und dort auf Kommandos gewartet wird.
Wie diese Kommandos aussehen, kannst du dir selbst ausdenken, z.B. eine
Folge von name=wert-Sequenzen, getrennt mit LF. Je nach empfangenem
Namen wird der folgende Wert an der passenden Stelle im EEPROM abgelegt.
Solange nichts über UART kommt, passiert halt auch nichts.
Evtl. macht es Sinn, vor jedem name=wert auch noch bestimmte Füllzeichen
zuzulasssen und zu ignorieren, z.B. Leerzeichen, und zudem jedes
Kommando mit einer Prüfsumme zu garnieren und diese auszuwerten.
Hintergrund: Wenn man erst zur Laufzeit ein Kabel anklemmt oder
sonstigen Unfug treibt, kommt vielleicht auch mal etwas Verstümmeltes
an. Das sollte man dann auch erkennen und ignorieren.
Eine normale Sequenz würde dann also so aussehen:
- ein paar Leerzeichen (werden ignoriert)
- ein Name (a-z)
- =
- der Wert
- Trennzeichen, z.B. #
- Prüfsumme über Name und Wert
- Zeilenvorschub
Der Sender der Kommandos (PC?) kann dann einfach etliche Leerzeichen
vorweg schicken, dann seine Kommandos.
Das macht die Kommunikation gleich robuster.
Hi
Parameter in einem Programm per serieller Schnittstelle zu setzen ist
nicht so schwer. Schau dir mal das Tutorial über UART an. Das Prinzip:
Statt einer Konstanten, die du im Programm verankerst, gibst du eine
Variable an. In Assembler etwa so
statt:
LDI Reg_A, 10
so:
LDS Reg_A, Var_Wert
wobei Var_Wert im SRam entsprechend deklariert werden muß
.DSeg
...
Var_Wert: .Byte 1
...
oder im EEProm
.ESeg
....
Var_Wert: .Byte 1
...
Bedenke: im EEProm darf der Wert nicht ständig verändert werden, da
"nur" ca. 100000 schreibzyklen garantiert werden, Danach hat sich eine
EEPromzelle "verbraucht".
Eine Ablage aber als Parameter, der vielleicht nur in einer Anfangsphase
öfters verändert, danach aber stabil bleibt, ist im EEProm richtig
untergebracht.
Gruß oldmax
Klaus Wachtler schrieb:> Werte im Flash kann man nicht während des laufenden Programms ändern.
Warum nicht? Machen doch alle Bootloader so. Richtig wäre: Nicht alle
µCs können ihren eigenen Flasch ändern. Moderne µCs können es. Genaue
Informationen gibt es im Datenblatt.
> Evtl. macht es Sinn, vor jedem name=wert auch noch bestimmte Füllzeichen> zuzulasssen und zu ignorieren, z.B. Leerzeichen, und zudem jedes ...
Welchen Zweck sollen die Leerzeichen erfüllen? Wenn die Kommunikation zu
schnell ist, setzt man die Baud-Rate herunter. Ansonsten spielen die
Pausen zwischen zwei gesendeten Zeichen keine Rolle. Wenn es nichts zu
senden gibt, dann wird eben nicht gesendet.
Natürlich muss man sich um die Synchronisation kümmern, ob da ein
Leerzeichen das Richtige ist, wage ich zu bezweifeln.
@michil
Ich kann dir nur raten, das Datenblatt zu deinem µC genau zu lesen und
zu verstehen, dann beantworten sich die meisten Fragen von selbst.
