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
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
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).
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
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...
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
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
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
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.
