Hallo Leute, hallo Jörg ;-) Der Versuch das EEPROM meines CAN128 anzusprechen wurde mal wieder im Keim erstickt. Zwar ist die Routine für ein Byte in der Bedienungsanleitung beschrieben, aber wer will schon ein Byte sichern? Die Vorgefertigenten Routinen von WinAVR unterstützen natürlich den CAN128 nicht. Die Theorie ist klar. Eine Array definieren und Byteweise in den Speicher schieben und dabei die Adresse hochzählen. Bevor ich das Rad nun neu erfinden muss, wollte ich fragen ob jemand da schon was Fertiges hat, dass er mir zur Vefügung stellen würde? Viele Grüße fw
Nimm eeprom.S aus dem Quellcode der avr-libc und kompiliere sie als Bestandteil deines eigenen Projektes. Die in der Bibliothek mitgelieferte Version funktioniert nur deshalb nicht, weil beim AT90CAN128 die EEPROM-Register woanders liegen als bei den meisten AVRs, der Code selbst funktioniert aber schon.
<... der Code selbst funktioniert aber schon Na darum hab ich ja auch geschrieben "unterstützt" den CAN128 nicht ;-) Ich würde denken das "eeprom.S" eine Datei ist? Ich stell mich wohl mal wieder zu doof an, ich find sie nicht.
Ja, es ist eine Datei. Ich glaube, du brauchst mehr als eine Datei. Siehe z. B. hier: http://savannah.nongnu.org/cgi-bin/viewcvs/avr-libc/avr-libc/libc/misc/
Ah ja! Assembler?! Du hast Recht. Ich glaube auch, ich brauche mehr als eine Datei. Da wird es dann wohl doch auf selber tippeln hinauslaufen.
Nein, warum denn? Warum ziehst du dir denn nicht einfach die genannten Dateien, schmeißt sie als Assemblerquellen zu deinem Projekt dazu, fertich die Laube?
@Jörg, klar ist das einfach, wenn man weiß wie es geht. Es ist gewiß auch genauso einfach, die Subroutinen in eigene c-files zu packen, damit man beim schreiben nicht immer durch das ganze Programm scrollen muss. Ich habe auch kein Problem eine existierende .c Datei einzubinden und die Funktionen darin aufzurufen, aber wenn ich selbst versuche so eine Subroutine zu schreiben springt mir der Compiler mit dem Arsch ins Gesicht. Wenn der ver.... Compiler meine Subroutinen in ausgelagerten c-files nicht mag, schreib ich sie eben alle ins main.c und wenn ich den Inhalt oder die Verwendung der Subroutinen nicht verstehe, schreib ich halt was, womit es schlußendlich auch geht. Ein Verzeichnis der Funktionen ist für die heutigen Compiler ja offenbar unzumutbar, selbst für die, für die man 2000 Flocken hinblättert. Ich bräuchte hier wohl erst mal eine Einweisung in das Basiswissen uC-Programmierung.
>Ich bräuchte hier wohl erst mal >eine Einweisung in das Basiswissen uC-Programmierung. Ersetze "uC" durch "C"...
Ja, in der Tat. Ansonsten: führe diese Dateinamen hinter ASRC in deinem Makefile auf.
< Ansonsten: führe diese Dateinamen hinter ASRC in deinem Makefile auf. Danke. Ich versuch mal mein Glück.
Hallo liebe Forenuser, hallo Jörg ;-)
Also mit "eeprom.S" komme ich leider nicht weiter. Das gibt
Fehlermeldungen ohne Ende. Dafür bin ich auf was anderes gestoßen. Der
Mega168 wird nach der Auskunft der eeprom.h auch nicht unterstützt und
was finde ich in der Software zum Butterfly?
#include "eeprom.h"
void StoreEEPROM(char *pBuffer, char num_bytes, unsigned int
EEPROM_START_ADR)
{
unsigned char i;
for (i=0;i<num_bytes;i++)
__EEPUT(EEPROM_START_ADR++, pBuffer[i]); // Store parameters
}
und so weiter.
Wie kann das gehen? Mache ich mir vieleicht ein Problem wo keines ist?
Und warum eigentlich
<< ... weil beim AT90CAN128 die EEPROM-Register woanders liegen
??
Wenn ich das oben richtig interpretiere, muss ich doch eh die Adresse
angeben, an der ich die Bytes speichern will oder gibt es da noch was,
was mir bisher entgangen ist?
Ich würde jetzt einfach rotzfrech die Routine aus dem Butterfly
abkupfern wenn da keine elementaren Probleme zu erwarten sind
> Also mit "eeprom.S" komme ich leider nicht weiter. Das gibt > Fehlermeldungen ohne Ende. Dann löse sie auf, statt die nächste Baustelle zu versuchen. > Wie kann das gehen? Ich kenne den Butterfly-Code nicht genug, möglicherweise bringen die einfach ihre eigene Bibliothek dafür mit. > Wenn ich das oben richtig interpretiere, muss ich doch eh die > Adresse angeben, an der ich die Bytes speichern will oder gibt es da > noch was, was mir bisher entgangen ist? Ja, du sprichts von den Adressen im EEPROM, ich von den Adressen der IO-Register, mit denen man auf den EEPROM zugreift. Wie geschrieben, beseitige die Fehlermeldungen, die du siehst. Ich sehe sie nicht, also weiß ich auch nicht, wie ich sie beseitigen soll.
Jörg sei bitte nicht sauer, aber das mit dem Assembler ist wirklich nicht mein Ding. Ich verstehe es auch nicht. Der Tip mit der EEprom.s war ja wohl nicht falsch, aber ich bekomme die Datei schon garnicht runtergeladen. Ich muss den Text im Browserfenster kopieren und in ein Projekt im AVR-Studio einfügen. Den Rest meiner Versuche das in mein Programm einzubinden erspare ich Dir. Wenn ich es in C hinkriege, bin ich schon zufreiden und alles Andere nehme ich mir vor, wenn ich Zeit habe. Wenn ich Dich Recht verstehe, heißt Diene Zeile oben, dass ich, wenn ich auf EEARH zugreife, ggf. die dahinter in der eeprom.h hinterlegte Adresse falsch ist? (ist nur ein hypothetisches Beispiel, ich habe es nicht überprüft!) Dann könnte ich das Problem doch umgehen, wenn ich eeprom.h in eepromf.h kopiere und umbenenne und die Adressen einfach korregiere, oder nicht? fw
Hmm, vielleicht solltest du ja mal lernen, einen Webbrowser zu bedienen... Rechte Maustaste, Speichern unter... oder sowas. Mit AVR Studio und seinen Projekten hat das alles gar nichts zu tun. AVR Studio hat derzeit kein API, um externe Compiler anzubinden, also lass es bitte außen vor und benutze es bestenfalls als Simulator, aber nicht als Editor, Projektverwaltung, ... Den Assemblerkram musst du ja nicht verstehen, um ihn benutzen zu können, du musst lediglich in der Lage sein, ein paar Dateien, die auf .S enden, in das Verzeichnis abzuladen, in dem sich dein C-Programm befindet, dein Makefile zu editieren (die Zeile mit ASRC=), und dann alles neu zu bauen. Nein, umbenennen von irgendwelchen Headerdateien wird deine Probleme überhaupt nicht lösen. Solange du nicht wenigstens ansatzweise verstehst, was wobei passiert, wird allerdings (sorry) vermutlich nichts und niemand deine Probleme lösen können.
<< Hmm, vielleicht solltest du ja mal lernen, einen Webbrowser zu bedienen... Rechte Maustaste, Speichern unter... oder sowas. Nun ja, das bekomme ich gerade noch hin, geht aber nicht. Ich mag zwar in C und Assembler eine Niete sein, aber die Grundfunktionen des Webbrowsers habe ich ganz gut unter Kontrolle. Aber viele Webseiten funktionieren halt nicht wie gewohnt, wenn man nicht den ver@'!?$$!! MakroSchrott InternetExplodierer verwendet. Du hast aber Recht. Ich hätte die Pagesorce anzeigen können und die dann als eeprom.S speichern können. Hätte mich aber auch nicht weiter gebracht ... Ich versuchs noch mal mit dem was Du mir geschickt hast, ohne es zuvor in WinAvr zu kompilieren ... Schauen wir mal. Danke erst mal fw
Ich wage mal zu bezweifeln, daß auch nur eine einzige Seite von "Savane" auf den IE optimiert ist lol
Mein geändertes Make-File
# it will preserve the spelling of the filenames, and gcc itself does
# care about how the name is spelled on its command-line.
ASRC = ee_rb.s \
ee_rblk.s \
ee_rw.s \
ee_wb.s \
ee_wblk.s \
ee_ww.s \
eeprom.s \
# List any ...
Und was der Compiler dazu meint :
Er ist ja sehr blumig in seiner Aussprache, und klar ist, das der
fehler bei mir liegt, weil es ja mit so viel fehlern nicht den Weg auf
die Savanna - Page finden würde ...
eeprom.s: Assembler messages:
eeprom.s:57: Error: junk at end of line, first unrecognized character
is `('
eeprom.s:59: Error: unknown opcode `_u'
eeprom.s:60: Error: constant value required
eeprom.s:60: Error: `,' required
eeprom.s:60: Error: constant value required
eeprom.s:60: Error: garbage at end of line
eeprom.s:61: Error: garbage at end of line
eeprom.s:63: Error: constant value required
eeprom.s:63: Error: `,' required
eeprom.s:63: Error: constant value required
eeprom.s:63: Error: garbage at end of line
eeprom.s:65: Error: constant value required
eeprom.s:65: Error: `,' required
eeprom.s:65: Error: constant value required
eeprom.s:65: Error: garbage at end of line
eeprom.s:66: Error: constant value required
eeprom.s:66: Error: `,' required
eeprom.s:66: Error: constant value required
eeprom.s:66: Error: garbage at end of line
eeprom.s:67: Error: register name or number from 0 to 31 required
eeprom.s:68: Error: register name or number from 0 to 31 required
eeprom.s:68: Error: constant value required
eeprom.s:68: Error: garbage at end of line
eeprom.s:77: Error: junk at end of line, first unrecognized character
is `('
eeprom.s:79: Error: unknown opcode `_u'
eeprom.s:80: Error: constant value required
eeprom.s:80: Error: `,' required
eeprom.s:80: Error: constant value required
eeprom.s:80: Error: garbage at end of line
eeprom.s:81: Error: garbage at end of line
eeprom.s:83: Error: constant value required
eeprom.s:83: Error: `,' required
eeprom.s:83: Error: constant value required
eeprom.s:83: Error: garbage at end of line
eeprom.s:85: Error: constant value required
eeprom.s:85: Error: `,' required
eeprom.s:85: Error: constant value required
eeprom.s:85: Error: garbage at end of line
eeprom.s:86: Error: constant value required
eeprom.s:86: Error: `,' required
eeprom.s:86: Error: constant value required
eeprom.s:86: Error: garbage at end of line
eeprom.s:87: Error: constant value required
eeprom.s:87: Error: register r24, r26, r28 or r30 required
eeprom.s:88: Error: constant value required
eeprom.s:88: Error: constant value required
eeprom.s:88: Error: garbage at end of line
eeprom.s:90: Error: constant value required
eeprom.s:90: Error: `,' required
eeprom.s:90: Error: constant value required
eeprom.s:90: Error: garbage at end of line
eeprom.s:92: Error: constant value required
eeprom.s:92: Error: `,' required
eeprom.s:92: Error: constant value required
eeprom.s:92: Error: garbage at end of line
eeprom.s:93: Error: constant value required
eeprom.s:93: Error: `,' required
eeprom.s:93: Error: constant value required
eeprom.s:93: Error: garbage at end of line
eeprom.s:94: Error: register name or number from 0 to 31 required
eeprom.s:94: Error: constant value required
eeprom.s:95: Error: register name or number from 0 to 31 required
eeprom.s:95: Error: constant value required
eeprom.s:95: Error: garbage at end of line
eeprom.s:108: Error: junk at end of line, first unrecognized character
is `('
eeprom.s:110: Error: unknown opcode `_u'
eeprom.s:111: Error: constant value required
eeprom.s:111: Error: `,' required
eeprom.s:111: Error: constant value required
eeprom.s:111: Error: garbage at end of line
eeprom.s:112: Error: garbage at end of line
eeprom.s:114: Error: constant value required
eeprom.s:114: Error: `,' required
eeprom.s:114: Error: constant value required
eeprom.s:114: Error: garbage at end of line
eeprom.s:116: Error: constant value required
eeprom.s:116: Error: `,' required
eeprom.s:116: Error: constant value required
eeprom.s:116: Error: garbage at end of line
eeprom.s:117: Error: constant value required
eeprom.s:117: Error: `,' required
eeprom.s:117: Error: constant value required
eeprom.s:117: Error: garbage at end of line
eeprom.s:118: Error: constant value required
eeprom.s:118: Error: constant value required
eeprom.s:118: Error: garbage at end of line
eeprom.s:120: Error: constant value required
eeprom.s:120: Error: `,' required
eeprom.s:120: Error: constant value required
eeprom.s:120: Error: garbage at end of line
eeprom.s:121: Error: constant value required
eeprom.s:121: Error: `,' required
eeprom.s:121: Error: constant value required
eeprom.s:121: Error: garbage at end of line
eeprom.s:122: Error: constant value required
eeprom.s:122: Error: `,' required
eeprom.s:122: Error: constant value required
eeprom.s:122: Error: garbage at end of line
eeprom.s:134: Error: junk at end of line, first unrecognized character
is `('
eeprom.s:136: Error: unknown opcode `_u'
eeprom.s:137: Error: register name or number from 0 to 31 required
eeprom.s:139: Error: constant value required
eeprom.s:139: Error: constant value required
eeprom.s:139: Error: garbage at end of line
eeprom.s:141: Error: constant value required
eeprom.s:141: Error: `,' required
eeprom.s:141: Error: constant value required
eeprom.s:141: Error: garbage at end of line
eeprom.s:144: Error: constant value required
eeprom.s:144: Error: `,' required
eeprom.s:144: Error: constant value required
eeprom.s:144: Error: garbage at end of line
eeprom.s:146: Error: constant value required
eeprom.s:146: Error: `,' required
eeprom.s:146: Error: constant value required
eeprom.s:146: Error: garbage at end of line
eeprom.s:147: Error: constant value required
eeprom.s:147: Error: `,' required
eeprom.s:147: Error: constant value required
eeprom.s:147: Error: garbage at end of line
eeprom.s:149: Error: constant value required
eeprom.s:149: Error: `,' required
eeprom.s:149: Error: constant value required
eeprom.s:149: Error: garbage at end of line
eeprom.s:150: Error: constant value required
eeprom.s:150: Error: `,' required
eeprom.s:150: Error: constant value required
eeprom.s:150: Error: garbage at end of line
eeprom.s:151: Error: constant value required
eeprom.s:151: Error: `,' required
eeprom.s:151: Error: constant value required
eeprom.s:151: Error: garbage at end of line
eeprom.s:152: Error: register name or number from 0 to 31 required
eeprom.s:155: Error: constant value required
eeprom.s:155: Error: register number above 15 required
eeprom.s:156: Error: constant value required
eeprom.s:156: Error: register number above 15 required
eeprom.s:157: Error: constant value required
eeprom.s:157: Error: constant value required
eeprom.s:158: Error: register name or number from 0 to 31 required
eeprom.s:180: Error: junk at end of line, first unrecognized character
is `('
eeprom.s:182: Error: unknown opcode `_u'
eeprom.s:183: Error: constant value required
eeprom.s:183: Error: constant value required
eeprom.s:184: Error: constant value required
eeprom.s:184: Error: constant value required
eeprom.s:186: Error: unknown opcode `load_x'
eeprom.s:188: Error: constant value required
eeprom.s:188: Error: `,' required
eeprom.s:188: Error: constant value required
eeprom.s:188: Error: garbage at end of line
eeprom.s:192: Error: constant value required
eeprom.s:192: Error: `,' required
eeprom.s:192: Error: constant value required
eeprom.s:192: Error: garbage at end of line
eeprom.s:194: Error: constant value required
eeprom.s:194: Error: `,' required
eeprom.s:194: Error: constant value required
eeprom.s:194: Error: garbage at end of line
eeprom.s:195: Error: constant value required
eeprom.s:195: Error: `,' required
eeprom.s:195: Error: constant value required
eeprom.s:195: Error: garbage at end of line
eeprom.s:196: Error: constant value required
eeprom.s:196: Error: register number above 15 required
eeprom.s:197: Error: constant value required
eeprom.s:197: Error: register number above 15 required
eeprom.s:198: Error: constant value required
eeprom.s:198: Error: constant value required
eeprom.s:198: Error: garbage at end of line
eeprom.s:199: Error: constant value required
eeprom.s:200: Error: constant value required
eeprom.s:200: Error: register number above 15 required
eeprom.s:201: Error: constant value required
eeprom.s:201: Error: register number above 15 required
eeprom.s:212: Error: junk at end of line, first unrecognized character
is `('
eeprom.s:214: Error: unknown opcode `_u'
eeprom.s:215: Error: constant value required
eeprom.s:215: Error: constant value required
eeprom.s:216: Error: constant value required
eeprom.s:216: Error: constant value required
eeprom.s:218: Error: unknown opcode `load_x'
eeprom.s:219: Error: constant value required
eeprom.s:219: Error: constant value required
eeprom.s:219: Error: garbage at end of line
eeprom.s:221: Error: constant value required
eeprom.s:221: Error: `,' required
eeprom.s:221: Error: constant value required
eeprom.s:221: Error: garbage at end of line
eeprom.s:224: Error: constant value required
eeprom.s:224: Error: `,' required
eeprom.s:224: Error: constant value required
eeprom.s:224: Error: garbage at end of line
eeprom.s:226: Error: constant value required
eeprom.s:226: Error: `,' required
eeprom.s:226: Error: constant value required
eeprom.s:226: Error: garbage at end of line
eeprom.s:227: Error: constant value required
eeprom.s:228: Error: constant value required
eeprom.s:228: Error: `,' required
eeprom.s:228: Error: constant value required
eeprom.s:228: Error: garbage at end of line
eeprom.s:230: Error: constant value required
eeprom.s:230: Error: `,' required
eeprom.s:230: Error: constant value required
eeprom.s:230: Error: garbage at end of line
eeprom.s:231: Error: constant value required
eeprom.s:231: Error: `,' required
eeprom.s:231: Error: constant value required
eeprom.s:231: Error: garbage at end of line
eeprom.s:232: Error: constant value required
eeprom.s:232: Error: `,' required
eeprom.s:232: Error: constant value required
eeprom.s:232: Error: garbage at end of line
eeprom.s:233: Error: constant value required
eeprom.s:233: Error: register number above 15 required
eeprom.s:234: Error: constant value required
eeprom.s:234: Error: register number above 15 required
eeprom.s:235: Error: constant value required
eeprom.s:235: Error: register number above 15 required
eeprom.s:236: Error: constant value required
eeprom.s:236: Error: register number above 15 required
im datenblatt des CAN128 stehen doch fertige routinen, die kann man 1:1 in gcc uebernehmen, ohne avr/eeprom.h zu bemuehen. ein interrupt-schutz um den eeprom-code und das ganze entspricht von der funktion eeprom_read/write_byte aus der avr-libc. die word/block-funktionen lassen sich darauf aufbauend auch "von hand" implementieren. der ansatz entspricht dem im gcc-port des BF-codes. der gezeigte codeausschnitt ist aus dem atmel code fuer den IAR compiler.
Benenne die Dateien im Makefile bitte mit einem großen .S, genau so, wie sie im Zip-File auch stehen.
Diese Dateien musst du wohl noch in das Verzeichnis werfen, sorry, hatte ich beim ersten Mal vergessen.
ja ja, ich weiß, aber ich wollte ein bisschen faul sein und mich auf fremdem Lorbeer ausruhen. Da schwebte mir dann sowas wie im Butterfly - Code vor, zumal ich auch noch nicht genau weiß, wie ich meine Variablen ins EEprom schreibe. Es muss ja wieder Byteweise geschen und da werde ich bestimmt wieder sprintf bemühen müssen. Ich weiß, es geht auch mit itoa aber das geht nicht immer und ich weiß noch immer nicht, warum es mal geht und ein andern Mal nicht.
@Jörg
Das passiert, wenn das "S" groß ist :
Assembling: ee_rb.S
avr-gcc -c -mmcu=at90can128 -I. -x assembler-with-cpp
-Wa,-adhlns=ee_rb.lst,-gstabs ee_rb.S -o ee_rb.o
In file included from ee_rb.S:30:
eeprom.S:38:22: ctoasm.inc: No such file or directory
make.exe: *** [ee_rb.o] Error 1
und ich hab sie nicht umbenannt, sie stehen mit großem "S" im
Directory.
mit kleinem "S" und den zugefügten Dateien habe ich jetzt das:
vr-gcc (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Compiling: main.c
avr-gcc -c -mmcu=at90can128 -I. -g -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 main.c -o main.o
Compiling: delay.c
avr-gcc -c -mmcu=at90can128 -I. -g -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=delay.lst -std=gnu99 delay.c -o
delay.o
Compiling: display.c
avr-gcc -c -mmcu=at90can128 -I. -g -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=display.lst -std=gnu99 display.c -o
display.o
make.exe: *** No rule to make target `ee_rb.s', needed by `main.elf'.
Stop.
> Process Exit Code: 2
Ich muss das revidieren. Die .S - Files waren weg. Gehen die beim Clean weg? Wenn ja warum und wie unterbindet man das?
Wenn du die .S-Namen unter SRC= angibst, werden sie bei make clean gelöscht. Bei ASRC= sollte das aber nicht passieren. Die .inc-Dateien hatte ich separat nachgereicht, hatte ich beim ersten Mal nicht dran gedacht.
Ich hab da irgendwas gelesen, das er de Dateien beim Clean löscht, wenn das "S" klein geschrieben ist, aber beim ersten Versuch wollte er sie mit grossem "S" nicht. Ist aber auch egal, jetzt geht es und alles Andere ist Schnee von gestern. Eine Frage habe ich jedoch noch. In der Bedienungsanleitung meine ich gelesen zu haben, das beim schreiben und lesen der EEprom-Daten die Interrupts abgeschaltet sein sollen? 1. Ist das richtg? 2. Wird das durch eeprom_read_block ... automatisch gemanagt?
Nun, da du den Quellcode aller Funktionen vorliegen hast, kannst du ja auch gleich selbst reingucken. ;-) Ja, meines Wissens werden die Interrupts sauber suspendiert.
Nun, das mit dem "selbst reinschauen" ist noch nicht ganz so effektiv. Ich war der irrigen Meinung, das mein Progamm nun mit eeprom_read_block oder eeprom_write_block was anfangen könnte. Weit gefehlt. Ich muss also noch irgendwas includen, aber was? eeprom.h isses nich und eeprom.S isses auch nicht. ...?
Ja, <avr/eeprom.h> solltest du noch includen. Du benutzt ja dieselben Funktionen, die darin deklariert werden, nur dass du eben ganz zufällig dafür die Implementierungen lokal herumliegen hast.
ah ja! Probieren wir das doch gleich mal. Was mache ich damit? Ignorieren? avr-gcc -c -mmcu=at90can128 -I. -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 main.c -o main.o In file included from main.c:5: C:/Programme/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/avr /eeprom.h:87:3: warning: #warning "The functions from <avr/eeprom.h> are not supported on this MCU." Linking: main.elf
Die Gute Nachricht: Irgendetwas wird ins eeprom geschrieben. Die Schlechte Ich bin natürlich zu doof die Funktion zu benutzen. sprintf(displaystring,"%-3.5f", (double)testzahl); eeprom_write_block(displaystring,0x000,10); funktioniert, eeprom_write_block(displaystring,0,10); funktioniert auch, eeprom_write_block(displaystring,0x020,10); funtioniert nicht und diverse anderer Versuche ...
Ja, die Warnung sollst du natürlich in diesem Falle ignorieren. Eine Alternative wäre es, diese Datei ebenfalls noch mit ins lokale Verzeichnis zu kopieren, statt mit <avr/eeprom.h> dann mit "eeprom.h" zu includen (man achte auf die Anführungszeichen, die sind wichtig dann) und darin die Warnung rauszulöschen. Definiere bitte "funktioniert nicht", was passiert denn dabei?
Hallo Jörg! Entschuldige die blöde Nerverei, aber ich bin zu doof, ich bekomme es nicht hin. Wenn ich eine Adresse wie 0x000 angebe macht er problemlos mit, nur das die Daten nicht am Anfang des EEproms stehen, sondern irgendwo mitendrin. gebe ich 0x0010 oder etwas ähnliches ein kommt ain.c: In function `adjust_geo_breite': main.c:555: warning: passing arg 2 of `eeprom_write_block' makes pointer from integer without a cast gebe ich 0 ein spielt er mit und die Daten stehen auch an der Adresse 0000 gebe ich 10 ein ain.c: In function `adjust_geo_breite': main.c:555: warning: passing arg 2 of `eeprom_write_block' makes pointer from integer without a cast gebe ich im als Adresse "0000" oder "0010" vor klappt es hervorragend, nur dass die Daten irgendwo im EEprom stehen und nicht da, wo ich sie erwarte. Noch habe ich die Daten noch nicht wieder versucht zurückzulesen, also ob das, was da am Ende im Eeprom drin steht auch wirklich das ist was es sein soll ist noch offen.
Nun, du solltest dir mal die Doku für die Funktion eeprom_write_block() zu Gemüte führen: void eeprom_write_block (const void *buf, void *addr, size_t n) Der zweite Parameter ist eine Adresse. Die Überführung einer 0 in eine Adresse ist im C-Standard genormt, daher bekommst du bei Angabe einer 0 keine Warnung. In allen anderen Fällen versuchst du, eine Integer-Zahl in eine Adresse zu überführen, ohne einen typecast zu benutzen. Du solltest also »(void *)0x10« schreiben. > gebe ich im als Adresse "0000" oder "0010" vor klappt es > hervorragend, nur dass die Daten irgendwo im EEprom stehen und nicht > da, wo ich sie erwarte. Davon abgesehen, dass du dir selbst widersprichst (etwas weiter oben schriebst du, mit 0 wäre alles OK, hier behauptest du, sie würden ,,irgendwo'' stehen), wo bitte stehen sie denn genau -- und wo würdest du sie erwarten? Ich würde sie für den zweiten genannten Fall jedenfalls auf Adresse 8 erwarten.
@Hallo Jörg. Also ich hab alles mögliche ausprobiert, aber auf (void *)0x10 wäre ich nie gekommen. Ich habe in der Doku uint16_t gefunden und habe es unter anderem mit (uint16_t)0x10 versucht. Habe ich ehrlich gesagt noch nie gesehen, diesen Ausdruck. Was ich nicht ganz verstehe ist, dass ich doch eigentlich 1,5 also 2 Byte für die Adressierung brauchen müßte, also müßte es doch irgendwas wie 0x0010 sein ??? Nein nein! Wiederspricht sich nicht. Es ist ein Unterscheid, ob ich 0 oder "0" schreibe. "0" wird offenbar als Ascii-Zeichen interpretiert und landet dann bei dez48 glaube ich ... Ich versuchs jetzt erst mal mit (void *)0x10 und schau mir das Ergebnis an...
Wenn doch der Funktionsprototyp schon einen "generischen Zeiger" erwartet (void *), sollte das doch am nächsten liegen. Wie man von void * allerdings auf uint16_t schliessen kann, bleibt mir ein Rätsel :-)
es steht sowas in der doku #include <eeprom.h> void eeprom_read_block(void* buf, uint16_t addr, size_t n); description. Reads a block of EEPROM memory. The starting address of the EEPROM block is specified in the addr parameter. The maximum address depends upon the device. The number of bytes to transfer is indicated by the n parameter. The data is transferred to an SRAM buffer, the starting address of which is passed in the buf argument. Ist aber unwichtig, es geht jetzt und dafür erst mal ganz herzlichen Dank... Jetzt muss ich bloß noch rausfinden, wie ich sprintf dazu bringe die führenden und abschließenden Nullen mitzuzschreiben, und wie man aus dem String, der beim lesen da rauskommt wieder eine dezimale Zahl wird ....
...das muss man aber erst zweimal lesen, bevor man weis, was Du willst :-) 1. führende nullen? Meinst Du den Formatstring für die Ausgabe? 2. Warum überhaupt erst in einen String wandeln?
zu 1 wenn ich Zahlen speichere, ist ja ungewiss, wieviele Stellen sie haben. Die Anzahl der Stellen muss ich aber wissen umd die Zahl im EEprom zu speichern. Wenn ich als 7 Stellen speichere, aber die Zahl hatte in diesem Fall gerade nur 3 Stellen, dann dürfte ab der 4.Stelle ziemlicher Mist in meinem EEprom stehen. Das weiß aber die Funktion die die Zahl wieder auslesen muss nicht und liest eben die 7 Stellen komplett aus. ... zu 2 weil ich bis 9:52 des 4.3.05 noch nicht ahnte, dass es auch anders geht?
@oldbug jetzt habe ich auf Deinen Tip hin mal ein bisschen mit eeprom_write_word rumexperimentiert. aber da bekomme ich leider nur den ganzzahligen Anteil meiner gespeicherten Zahl zurück. Es wäre wirklich interessant zu efahren , wie Du das machen würdest
Was hast du denn für ein Zahlenformat? Du musst natürlich so viel speichern, wie groß die Zahl ist. eeprom_write_block(&zahl, (void *)eeprom_offset, sizeof zahl); Wenn "zahl" vom Typ double ist, dann ist sizeof zahl == 4.
scheibenkleiser kann das alles einfach sein, wenn man weiß wie es geht. Ich habe keine Ahnung was das & vor der Variablen macht, aber es funktioniert hervorragend. Warum gibt es so einfache Beispiele und Anleitungen nicht irgendwo zum anschauen, nachlesen und erklären. Erst mal ganz herzlichen Dank. Ich habe jetzt erst mal einen Haufen Variablen durch den Rest zu bringen. @Jörg Wir sehen uns im Sommer zu nem großen Bier?
Du solltest C lernen. Lass das Bier mal, kauf dir lieber bitte einen K&R für das Geld -- und lies ihn dann auch.
hab ich schon, aber damit komme ich überhaupt nicht klar. Ich hab noch ein altes Unix-C Buch das ist schon besser, geht aber nicht auf die uC-Programmierung ein.
Die Probleme, die Du bisher hattest, hatten auch rein gar nichts mit µCs zu tun...
damit hast Du sogar Recht. Die Hardware ist auch einigermaßen einfach zu bewältigen und was man nicht weiß findet man in Beispielschaltungen oder kann es sich aus anderen Projekten ableiten. Aber die C-Bücher die ich habe sind ein nackte Katastrophe. Kennst Du z.b. das Makrobuch von Excel4? Sowas suche ich für C. Klar, schüssig ohne seitenfüllendes Blabla, klare Defnitionen, Kurzerklärungen, praktische Beispiele, verwandte Funktionen, Umkehrfunktionen. Was immer ich schlechtes über MS zu sagen habe, das Buch ist richtig gut gewesen, leider nicht für C
Und Du hast Dir tatsächlich den K&R angesehen? Welche Ausgabe? In der zweiten Ausgabe (ca. 1990, erschienen im Hanser Verlag) steht in klarer und knapper Weise alles drin, was man über ANSI-C wissen muss. Solltest Du noch eine antiquarische erste Ausgabe (irgendwann vor 1990, ebenfalls Hanser Verlag) erwischt haben, kann ich allerdings verstehen, daß Du damit nicht klargekommen bist. Grauenerregend übersetzt (vermutlich von einem Automaten), schlechte Beispiele, schlechte Typographie (Sourcelistings in einer Proportionalschrift!) und vor allem wird nur das antiquierte "K&R"-C ohne Typüberprüfung und Funktionsprototypen beschrieben.
Also ich habs grad nicht da, aber ich hab es erst vor einem halben jahr gekauft, was, so meine ich, für eine neue Ausgabe spricht und ich meine das K&R die Abkürzung für dieses Standart-Werk ist, dass hier gerne empfohlen wird, ... Roter Paperback-Einband und sauteuer. Finde ich vollkommen verfehlt. Hab ich ein paar Mal reingeschaut, Informationen gesucht, und beiseite gelegt. Schon das Inhaltsverzeichnis ist eine Zumutung und gibt Aufschluss über die Organisation des Inhalts. Ich hätte sowas nie im Laden gekauft, wenn es nicht so warm in diesem Forum gehandelt worden wäre.
Mag natürlich sein, daß die neueren Ausgaben des K&R schlechter geworden sind; müsste mir mal eine aktuelle Ausgabe ansehen. Ansonsten gibt es natürlich immer individuelle Unterschiede beim Lesen und Verstehen von Büchern, was der eine wirr findet, ist dem anderen klar und umgekehrt. Dennoch: Lass' den Kopf nicht hängen, man kann C programmieren lernen, auch wenn viele "C-Programmierer" das unter Hinterlassung von viel fehlerhaftem Quelltext zu umgehen suchen ... aber das ist bei jeder Programmiersprache so.
Warum den Kopf hängen lassen? Was das Buch nicht her gibt, läßt sich doch in diesem Forum klären. Manchmal etwas zäh, und manchen Kommentar überliest man besser, aber am Ende zählt nur das Ergebnis.
Hmm, verkauf den K&R wieder, wenn du damit nicht klarkommst. So ganz verstehe ich es aber nicht, er hat schließlich schon Generationen von C-Programmierern als Einstieg gedient. Man sollte allerdings das Kapitel über Pointer and Arrays (weiß nicht, wie sie es ins Deutsche übersetzt haben) wirklich nicht aussparen. Erst danach hat man C einigermaßen verstanden. (Danach kommen `Structures' und `Input and Output', die ist man dann wieder eher geneigt zu lesen. ;-)
also ich hab noch mal nachgeschaut und es ist K&R und ich finde es grauenhaft. Ich habe noch ein altes aus dem TEWI Verlag von Bernhard Davignon, das ist zwar auch nicht der Brecher, aber ich feinde es deutlich besser, als das das KR.
> Was das Buch nicht her gibt, läßt sich doch in diesem Forum klären. > Manchmal etwas zäh, und manchen Kommentar überliest man > besser, aber am Ende zählt nur das Ergebnis. Wenn du das wirklich glaubst, was ist denn nun das Ergebnis dieses Threads? Hast du tatsächlich verstanden, wieso der Code jetzt funktioniert?
Ist das wichtig? Es funktioniert, wenn man statt der Variablen an sich nur den Zeiger auf die Variable reinschreibt. Das wirft die Frage auf, ob ich in gleicher Weise das sprintf sparen kann, wenn ich der Displayroutine statt der Variablen den Zeiger serviere. Das werde ich einfach bei Gelegenheit ausprobieren. Ehrlich gesagt, finde ich die EEProm-Routine etwas umständlich mit dem ganzen Dateien, die ich im Moment dafür brauche, dafür ist die Benutzung sehr einfach, wenn man erst mal weiß, wie es geht. Das Ergebnis ist genau das, was ich brauche und darum ist es perfekt.
> Ist das wichtig?
Ja, oder möchtest du dein Leben lang ein Copy&Paste-Coder bleiben?
Nimms mir nicht übel, aber dann wirst du in spätestens ein paar Tagen
wieder mit einer trivialien Frage hier aufkreuzen...
Nimm den Rat bitte Ernst und kauf dir ein gutes C-Buch. Es hat absolut
keinen Sinn, C über ein Forum lernen zu wollen; ein Forum kann niemals
ein C-Buch ersetzen.
@Chris Wann ist eine Frage Trivial? Ist eine Frage nur darum trivial, weil ich auf Anhieb die Antwort kenne?
Vielleicht sollte man ,trivial' durch ,elementar' ersetzen. Grundlagenwissen von C halt, was dir ganz deutlich fehlt.
eine Frage belibt dann doch noch, die ich auch mit dem neuen C-Buch noch nicht zu kären vermochte warum kann ich mit eeprom_write_block(&interval,(void *)0x0060,sizeof interval); und eeprom_read_block(&speicher,(void *)0x0060,sizeof interval ); meine variable ganz gervorragend im EEprom sicher und und wieder auslesen, wenn "interval" vom Typ float ist und habe nur 00 im EEprom zu stehen, wenn "interval" vom Typ int ist?
Welchen Typ hat den speicher? Der Typ muß identisch zum Typ von intervall sein. Volkmar
na ja, speicher ist ein float, weil alle Variablen davor halt floats sind. Ich würd mich ja auch nicht beklagen, wenn es denn am auslesen liegen würde. Aber es steht im EEprom schon nur noch 00 drin. Das Auslesen über speicher und die anschließende Zuweisung interval = (int)speicher klappt übrigens problemlos. Ich hab schon überlegt, ob ich einfach eine hilfsvariable anlege über die ich aus dem interval eine float mache, bevor ich es speichere, aber dass kann unmöglich der richtige Weg sein. Ok, jetzt habe ich erst mal mein Intervall generell zu einem float gemacht, aber es geht doch sicherlich auch mit int?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.