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
Schau ins map file ob er die EE_* Sachen korrekt ins EEPROM packt.
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
Hi frag mal im OpenDCC Forum - da wird normalerweise schnell und spezifisch geholfen
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
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
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
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
Würden Sie nun aber eine Schleife hinzufügen, die ähnlich wie diese aussähe ... while(1) { if (isrFlag == true) { tueEtwas(); }
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.