Hi,
hab mal eine kleine C-Frage an euch. Ich spiele gerade mit einem Eeprom
von Atmel At24C04 herum und hab mir eine typedef struct angelegt, die im
Eeprom abgespeichert wird.
Jetzt möchte ich gern anhand dieser struct gezielt dessen Werte auslesen
können.
1
//mein typedef struct fürs eeprom
2
typedef struct {
3
unsigned char Update;
4
unsigned char VersionNbr[4];
5
unsigned char Reserved[3];
6
unsigned int Size;
7
8
} AT24C_FirmWare;
9
10
char AT24C_ReadByte (unsigned int Address, unsigned int size)
11
{
12
/*
13
Address: Startaddresse bei der das Auslesen des Eeproms startn
14
soll
15
size: wieviele Bytes ausgehend von der Address ausgelesen werden sollen
Im obigen Aufruf von AT24C_ReadByte möchte ich gern die VersionsNbr
auslesen. Ich weiß so wie ich es geschrieben habe geht es noch nicht,
aber es soll nur mal das Ziel zeigen, wo ich gerne hin möchte.
Wie kann man das so bzw. so ähnlich realisieren, dass (unsigned int
Address) den richtigen Wert erhält, den es benötigt? Oder gibt es eine
bessere Möglichkeit (lauter Defines mit den entsprechdnen sizeof())? Ich
möchte aus dem Code heraus sofort sehen können, welchen Wert ich gerade
auslese.
Gruß
Johannes
ok habs jetzt gelöst...
allerdings hab ich noch eine kleine Frage an euch. Am Anfang meiner
Write/Read Methode von I2C überprüfe ich ob das Busy-Bit gesetzt ist und
somit der I2C-Bus nicht verwendet werden kann.
Sollte dieses einmal aus irgendeinem Grund gesetzt sein, wie sollte sich
dann mein Programm verhalten? Kann man den I2C Bus in diesem Fall
resetten, damit dieser nicht mehr busy ist???
Hi
>ok habs jetzt gelöst...
wie hast du es nun gemacht?
es gibt mehrere Möglichkeiten dafür:
- alles in eine define Tabelle packen
- define Tabelle nach Datentype aufteilen
- eigene Section (siehe AVR EEPROM Macro)
Die 1. Methode habe ich schon nach 1 Tag wieder verworfen, hab mich
immer wieder verzählt ;-)
Die 2. benutze ich noch öfters. (wenn der Compiler nicht anderes zur
Verfügung stellt)
Die 3. ist die einfachste, denn hier Zählt der "Compiler" für einen und
man kann sich getrost um andere Sachen kümmern.
( geht aber halt nicht mit allen Compilern, und man unterliegt den
Launen (Versionen) des "Compilers" -> Daten können verrutschen 1x
passiert!)
Kannst du mal deine Lese / Schreibe Funktionen zeigen, vielleicht kann
man noch was verbessern.
>Kann man den I2C Bus in diesem Fall resetten, damit dieser nicht mehr>busy ist???
Ja, sollte man auch tun. sonst gehts nicht weiter! ;-)
Das gilt auch für Daten die nicht gelesen / geschrieben werden konnten!
Stephan
Stephan W. schrieb:> Ja, sollte man auch tun. sonst gehts nicht weiter! ;-)> Das gilt auch für Daten die nicht gelesen / geschrieben werden konnten!
Sobald der Bus aus irgendeinem Grund hängt muss man dann BitBangigang
anwenden? Wie muss ich hierfür den SDA schalten? GPIO, Output ohne
Pullup?
Hi
>...muss man dann BitBangigang anwenden?
nein, warum?
Ich hatte bis jetzt nur einmal ein Problem damit.
Eine Platine hatte von 10C bis -20C Probleme mit einem FRAM.
Ich versuche 3x einen Wert zu lesen / schreiben, funktioniert dies
nicht, gib ich eine Meldung aus. (RS232, Ereignis-Logger, LED) und lass
die SW gegen den Watchdog laufen. Wenn das Gerät wieder gestartet wird,
wird sowie so die HW getestet und sollte es hier ebenfalls zu Ausfall
kommen, wird wieder die Message ausgegeben und gegen den Watchdog
gelaufen.
Das Gerät stellt dann sozusagen den Dienst ein.
Du musst bei einem Fehler im Programm / HW, dafür sorgen das du das
Gerät in einen sicheren Zustand fährst.
Stephan
Stephan W. schrieb:> Du musst bei einem Fehler im Programm / HW, dafür sorgen das du das> Gerät in einen sicheren Zustand fährst.
die einzige Möglichkeit, die ich momentan sehe warum so ein Deadlock
passieren kann, ist wenn der User während des Schreib/Lesezugriffs auf
das Eeprom den Reset-Schalter betätigt...
Hab gelesen, dass auch durch die Neuinitialisierung des I2C Busses es
sein kann, dass dieser nicht wieder freigegeben wird, weil sich z.B. das
Eeprom aufgehängt hat. Und deren Lösung war immer ein Bitbanging, so
dass man dem Eeprom mitteilt, dass ein STOPP gesendet worden ist und
somit die Kommunikation auf dem I2C Bus eingestellt wird, so dass eine
neue wieder gestartet werden kann.
Johannes
Stephan W. schrieb:> Ich versuche 3x einen Wert zu lesen / schreiben, funktioniert dies> nicht, gib ich eine Meldung aus.Stephan W. schrieb:> Das Gerät stellt dann sozusagen den Dienst ein.
Das möchte ich halt auf jeden Fall vermeiden. Als einzige Alternative
zur Problembehebung gibt es ja dann nur noch das Ausschalten des
Gerätes.
Johannes schrieb:> den Reset-Schalter betätigt...
gibs bei mir nicht.
Johannes schrieb:> Das möchte ich halt auf jeden Fall vermeiden. Als einzige Alternative> zur Problembehebung gibt es ja dann nur noch das Ausschalten des> Gerätes.
Das geht aber nicht immer, denn wenn die Daten im Betrieb benötigt
werden, dann darf ich darauf nicht einfach verzichten und weiter machen
als ob nichts wäre.
Selbst wenn der Fehler-Logger nicht mehr läuft, macht das Gerät einen
Watchdog-Reset!
Erst bei einem Neustart und dem Testen der HW, kann bei bestimmten
Geräten, nicht bei allen, der Logger deaktiviert werden! Der Kunde
bekommt aber eine Meldung (RS232, LED) das ein Fehler vorliegt!
Ausschalten hatte damals auch nichts gebracht! Das macht der Kunde meist
von alleine, als erstes "Stecker ziehen". Erst dann ruft er den
Kundendienst.
Das mit dem Bitbanging kannst du gerne machen, aber dann hast du immer
noch das Problem, wenn du es damit nicht lösen konntest. was dann???
Stephan
PS: Wenn du eine Lösung mit dem Bitbanging hast, kannst du die dann
Posten?
Thread beobachten
Seitenaufteilung abschalten