Forum: Mikrocontroller und Digitale Elektronik Probleme in C - kann kein EEPROM


von Chregu (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Foraner,

wie ja mancher weiss, kann ich fast kein C, trotzdem habe ich den 
angefügten Code für meine Zwergsignale adaptieren können. Es handelt 
sich um einen DCC-Dekoder von opendcc.de, den modifizierten Code von 
OpenDecoder 
(https://www.opendcc.de/elektronik/opendecoder/opendecoder_sw_signal.html) 
für Attiny2313P. BTW: die "P"-Ausführung habe ich ums Verrecken nirgends 
gefunden, aber geht auch ohne "P"...
Leider geht das Speichern/Laden des Zustandes vor dem Ausschalten nicht. 
Es wird nur ein Teil (scheinbar die oberen 4 Bits) gespeichert, und das 
UNABHàNGIG davon, ob der Jumper gesteckt ist oder nicht. Die Zuständige 
Define ist JUMPER_FITTED, aber ich sehe trotzdem nicht durch, warum das 
nicht gehen sollte. Hat es etwa mit der Optimierung zu tun? Mit "s = 
optimize for size" im Makefile passt der Maschinencode überhaupt ins 
Flash.
OT: Dass eine Programmiersprache, die für sich in Anspruch nimmt, 
maschinennahe zu sein und verschiedene Optimierungen hat, kann ja nicht 
sein...
Von den anderen Problemen, bis WinAVR und Make lief, ganz zu schweigen.

Wäre lieb, wenn mal jemand drüberschauen könnte.

Vielen dank, Gruss Chregu

von Jim M. (turboj)


Lesenswert?

Schau ins map file ob er die EE_* Sachen korrekt ins EEPROM packt.

von Christian M. (christian_m280)


Lesenswert?

Ich bin es nochmal, immer noch das gleiche Problem.
Ja, im Map-File ist alles OK, auch auslesen des EEPROM geht, und ergibt 
genau die Werte, die ich auch nach dem Einschalten an den LEDs habe. 
Weiter habe ich herausgefunden, dass immer das letzte Signal (Nibble im 
Byte NICHT gespeichert wird. Es wird also immer nur das andere Nibble 
gespeichert. Ich dreh noch durch. Es ist also ziemlich sicher in der 
Software!

Danke und Gruss Chregu

von Nautilus (Gast)


Lesenswert?

Chregu schrieb:
> Leider geht das Speichern/Laden des Zustandes vor dem Ausschalten nicht.


Der µC braucht eine Information das Ausgeschaltet wird.
Dann sollte ein Interrupt ausgelöst werden, der ein Programmroutine 
aufruft, die die restliche Energie aus dem Netzteil (Kondensatoren 
entladen sich) ausnutzt, den EEPROM zu beschreiben. Man sollte sicher 
stellen, dass die restliche Ladung dazu ausreicht (mehrere 100 ms).

von Michael D. (nospam2000)


Lesenswert?

Chregu schrieb:
> Dass eine Programmiersprache, die für sich in Anspruch nimmt,
> maschinennahe zu sein und verschiedene Optimierungen hat

Vielleicht hast du nur noch nicht verstanden, dass Optimierung immer 
eine Eigenschaft bevorzugt (z.B. Größe) und andere vernachlässigt (z.B. 
Geschwindigkeit).

Oft ist es so, dass man nicht alle gewünschten Eigenschaften 
gleichzeitig erreichen kann. Ein Sportwagen ist zwar schnell, aber für 
einen Umzug eignet sich ein langsamer LKW doch besser.

  Michael

von none (Gast)


Lesenswert?

Hi

frag mal im OpenDCC Forum - da wird normalerweise schnell und spezifisch 
geholfen

von c-hater (Gast)


Lesenswert?

Michael D. schrieb:

> Vielleicht hast du nur noch nicht verstanden, dass Optimierung immer
> eine Eigenschaft bevorzugt (z.B. Größe) und andere vernachlässigt (z.B.
> Geschwindigkeit).

So ist es. Der große Nachteil dieses Konzepts ist, dass es "global" ist, 
zumindest über eine einzelne C-Datei.

Blöderweise kann so eine Datei aber vollkommen unterschiedliche 
Funktionen beinhalten. Extremfall: selten genutzte Wartungsfunktion vs. 
ISR.

Es ist für jeden Nichtvollidioten vollkommen klar, dass es für diese 
beiden Funktionen i.d.R. keine gleichermaßen sinnvolle Optimerung geben 
kann. Der C-Compiler ist aber ein Idiot, wie er im Buche steht, denn dem 
ist das nicht klar...

von Christian M. (christian_m280)


Lesenswert?

Nautilus schrieb:
> Der µC braucht eine Information das Ausgeschaltet wird.
> Dann sollte ein Interrupt ausgelöst werden, der ein Programmroutine
> aufruft, die die restliche Energie aus dem Netzteil (Kondensatoren
> entladen sich) ausnutzt, den EEPROM zu beschreiben.

Wie ich die Software verstehe, wird JEDE Änderung gespeichert - nicht 
gerade erholsam für das EEPROM...

Gruss Chregu

von Wolfgang K. (opendcc)


Lesenswert?

Hier wurde offenbar ein uralter Stand geforkt (ist leider nicht mehr 
nachvollziehbar, man hat alle Hinweise zur History, zum copyright und 
zum Ersteller aus der Datei entfernt), meiner eigenen Historie nach 
wurde dieser Fehler am 04.06.2013 gefixed.

Zur Optimierung von C-Compilern: so ein ganzer Vollidiot, wie er im 
Buche stehen soll, ist das beileibe nicht (das war es vielleicht mal in 
den 80ern), der gcc macht da keinen so schlechten Job.

Viele Grüße

von Christian M. (christian_m280)


Lesenswert?

Hallo Wolfgang,

das ist der aktuelle Code von der Internetseite:

Chregu schrieb:
> den modifizierten Code von OpenDecoder
> (https://www.opendcc.de/elektronik/opendecoder/opendecoder_sw_signal.html)

Ja, und ich habe ihn für mich aufs nötigste reduziert - der 
Übersichtlichkeit wegen.

Gruss Chregu

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

c-hater schrieb:
> So ist es. Der große Nachteil dieses Konzepts ist, dass es "global" ist,
> zumindest über eine einzelne C-Datei.
>
> Blöderweise kann so eine Datei aber vollkommen unterschiedliche
> Funktionen beinhalten. Extremfall: selten genutzte Wartungsfunktion vs.
> ISR.
>
> Es ist für jeden Nichtvollidioten vollkommen klar, dass es für diese
> beiden Funktionen i.d.R. keine gleichermaßen sinnvolle Optimerung geben
> kann. Der C-Compiler ist aber ein Idiot, wie er im Buche steht, denn dem
> ist das nicht klar...

Ähm... ‘#pragma GCC optimize’ bekannt???

Da kannst du teilweise -Ofast nutzen und den rest z.b. in -Og lassen - 
wenn nötig fürs debugging.

73

von Joachim B. (jar)


Lesenswert?

Hans W. schrieb:
> Ähm... ‘#pragma GCC optimize’ bekannt???

nein, aber danke dafür!
https://www.boecker-systemelektronik.de/Seite-/-Kategorie-1/Vorsicht-bei-Compiler-Optimierungen

von Kleiner SWL (Gast)


Lesenswert?

Die Fa. Mit der if-Schleife.

von Kleiner SWL (Gast)


Lesenswert?

Würden Sie nun aber eine Schleife hinzufügen, die ähnlich wie diese 
aussähe ...



while(1) {

   if (isrFlag == true)

   {

      tueEtwas();

   }

von Kleiner SWL (Gast)


Lesenswert?

Der Compiler erkennt, das die Variable isrFlag am Anfang auf "false" 
gesetzt wird. Der Optimierer prüft nun, wo diese Variable auf "true" 
gesetzt wird. Er findet nur die Interrupt-Service-Routine, die er 
allerdings nicht als solche erkennt und findet ansonsten keinen 
Einsprung in diese Funktion. Also geht er davon aus, dass isrFlag nie 
gesetzt wird und optimiert die ganze if-Schleife weg.

Bitte 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
Noch kein Account? Hier anmelden.