Zitat :

Einfach die 32 Werte je als Byte in eine BIN Datei schreiben, fertig ! Ich versteh ehrlich gesagt das Problem nicht...

Doch genau da liegt es

Ich erstelle im Editor eine "table.hex" und schreibe dort z.B. rein:

10, 20, 30, 40 (dezimal)

oder

10 20 30 40

oder
10
20
30
40

oder sogar
0x0A 0x0B 0x0C (hex)

Verstehst du jetzt, wo bei mir der Hase im Pfeffer liegt?

Zitat :

Ist das nicht Platzverschwendung ? Wenn die Werte doch schon in einem Speicher sind, dann lass die doch dort und les die nur aus, wenn die wirklich benötigt werden.

Die Idee ist nett, scheitert jedoch an der AVR-Architektur. Ich habe in der ISR nur relativ wenig Zeit und da möchte ich nicht unbedingt, das EEPROM lesebereit machen, wenn es fertig ist den Prozessor für mehrere Cycles anhalten dann den kram auslesen...

Da ist es zeitsparender, einfach etwas SRAM dichtzumachen - ich hab ja eh mehr als genug davon

Grüße, hendrik

Du nimmst dir einen Hexeditor und schreibst da die Werte rein, speicherst das als BIN Datei, fertig.
Wenn du eine Hex Datei schreiben willst (mit einem normalen Editor), dann must du zusätzlich zu den Daten noch die Checksumme usw. berechnen und schreiben, das macht deshalb niemand, und genau dafür gibt es einen Hexeditor !

Kannst du mir da einen HexEditor empfehlen.

Gibt es irgendwo genauere Infos über den Dateiinhalt (checksum...)? So könnte ich ein kleines Programm basteln, mit dem man die Dimmercurves EQ-artig erstellen kann, das am Ende die fertige Datei rausschmeißt...

Grüße, hendrik

Du kannst auch dem Assembler diese Aufgabe stellen.
Dazu wurden die Directiven erfunden.
In der ASM-Hilfe steht es:

Zitat :

The ESEG directive defines the start of an EEPROM Segment. An Assembler file can consist of several EEPROM Segments, which are concatenated into one EEPROM Segment when assembled. An EEPROM Segment will normally only consist of DB and DW directives (and labels). The EEPROM Segments have their own location counter which is a byte counter. The ORG directive can be used to place the variables at specific locations in the EEPROM. The directive does not take any parameters.

_________________
mfg Jornbyte

Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.

Danke Jorn!

Das habe ich auch gerade in einem AVR-Tutorial entdeckt

Daraufhin wird ein eep-File erstellt, das aus

:'Adresse''15Bytes''1Byte_checksum"
:nächste Zeile...
:0..01FF (Ende)

besteht. (das Ergebnis wird übrigens nicht in den Simulator übertragen )

Da ich am liebsten ein kleines delphi-Programm schreiben würde, das mir die Tables erstellt, frage ich mich noch über die Zusammensetzung der checksum:

alle Bytes "0":
1.Zeile: F0
2.Zeile: E0
3.Zeile: D0
...

eines der Bytes der ersten Zeile
=1 EF
=2 EE
=3 ED

Die Summe von mehreren bytes einer Zeile wird wie ein einzelnes byte behandelt.

Deswegen glaubte ich schon an die Formel
F0 - Summe(n) =crc

Bei ein Byte =255 kam allerdings F1 raus, was meine Theorie ja wohl zu nichte macht...

Habt Ihr eine Ahnung wie diese Prüfsummen gebildet werden??
Ich finde nichts darüber

Grüße, hendrik

Guck z.B. mal hier:

http://www.cs.net/lucid/intel.htm

oder hier:

http://chaokhun.kmitl.ac.th/~kswichit/illustrate/hex.htm

oder auch hier:

http://www.keil.com/support/docs/1584.htm

da findest du auch was:

http://www.8052.com/tutintel.phtml


Einfach mal in Google "Intel hex" eingeben, und du findest genug Links zu diesem Thema.

_________________
Wie immer gilt: Erst googeln, dann fragen!

(Für ICQ bitte erst Anfrage per PM, da alles andere nicht angenommen wird.)

Oder noch einfacher. Im AVR-Studio das EEPROM öffnen, die Werte eintragen und in den Atmel brennen. Fertig

_________________
mfg Jornbyte

Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.