Bascom Bug in "Dim Variable as Eram Byte"

[raidy]

Der Fehler macht sich dadurch bemerkbar, dass geschriebene Werte beim Abruf nicht mehr da sind.
Entgegen obiger Aussage glaube ich jetzt, dass es schon eher am Bascom liegt, denn bei gleichem Programm in C geschrieben tritt der Fehler nicht mehr auf. Aber selbst wenns am AVR liegen sollte, dann könnte der Bascom-Compiler einfach das erste Byte "unterschlagen" und erst beim 2.tem Byte aufsetzen. Dies soll aber kein Rüffel sein, den der Entwickler von Bascom hat einen erstklassigen Compiler geschrieben.

[MagicWSmoke]

Entgegen obiger Aussage glaube ich jetzt, dass es schon eher am Bascom liegt, denn bei gleichem Programm in C geschrieben tritt der Fehler nicht mehr auf.

Bei möglicherweise fehlerhaft übersetztem Code, der nicht mal gezeigt wird, von einem Bascom-Fehler auszugehen ist abwegig.
Meistens sitzt der größte Bug vor dem µC.
Wie man aus der Variable Akkuleer vermuten kann, wird der µC evtl. im Grenzbereich seiner Spannungsversorgung betrieben, da wäre z.B. der BOD sinnvoll, der eben per Fuse einzuschalten ist, wird hier nicht gesagt ob die an oder aus ist. Gleichwohl vermisse ich Info ob das ein und dieselbe HW ist, in die Bascom und C geflasht wird. Wenn's verschiedene HW ist, kann der Fehler genauso dort stecken, fehlende Pufferkondensatoren, usw.

[raidy]

Es war ein und dieselbe HW. Der Attiny25 wird zwischen 4,2 und 3,5V betrieben. Bei 3,5V wird Akkualarm ausgegeben. Wie ich aber hier: https://www.roboternetz.de/community...l=1#post529013 erfahren habe, handelt es sich um einen Bug des avr, welcher im Genzspannungsbereich das Byte 0 des Eprom verlieren kann. Wobei ich diesen Bereich nur erreiche, wenn die Spannung ausgeschaltet wird und der Kondesnator sich entlädt, während das Programm munter wietertickt.
Trotzdem lasse ich Byte 0 des Eprom mit einem Dummywert reserviert, weil es dann ja gut läuft. Außerdem stoppe ich das Programm jetzt, sobald ein Akkualarm anliegt. Ich habe es hier reingeschrieben, damit andere nicht in die gleiche Falle tappen.
Es ist also KEIN Fehler von Bascom sondern einer des AVR. Dass es unter C nie passiert ist, kann ich mir nur sehr bedingt erklären, will aber hier keine Theorien aufstellen. Nur hatte ich beim googeln nach dem Fehler keinen Hinweis gefunden. Nachher ist man immer schlauer.

[MagicWSmoke]

Ist auch 'ne Frage des HW-Designs, Einsatz des BOD ist sinnvoll, das wurde Dir bereits geraten. Außerdem könnte man in gestörter Umgebung den µC mit 'ner Diode und einem Kondensator von kurzen Spannungseinbrüchen entkoppeln, Diode vorzugsweise Schottky.

[raidy]

Ist auch 'ne Frage des HW-Designs, Einsatz des BOD ist sinnvoll, das wurde Dir bereits geraten. Außerdem könnte man in gestörter Umgebung den µC mit 'ner Diode und einem Kondensator von kurzen Spannungseinbrüchen entkoppeln, Diode vorzugsweise Schottky.

Stimmt. Aber der ganze Mist musste in eine 12mm Röhre, da tut jedes Bauteil weh. So wie es jetzt geht, läuft es gut. Trotzdem Danke für die Tipps.

[MagicWSmoke]

Stimmt. Aber der ganze Mist musste in eine 12mm Röhre, da tut jedes Bauteil weh. So wie es jetzt geht, läuft es gut. Trotzdem Danke für die Tipps.

Klar, bitte. Wenn's SMD sein darf, keramische Kondensatoren in passender Kapazität (10-50µF) und Spannung sind recht klein, würden auch in D12mm locker Platz haben, Diode sowieso.

[raidy]

Klar, bitte. Wenn's SMD sein darf, keramische Kondensatoren in passender Kapazität (10-50µF) und Spannung sind recht klein, würden auch in D12mm locker Platz haben, Diode sowieso.

Übrigens ein Dankeschön für den BOD Hinweis. Das habe ich mir noch nie angesehen, ist aber eine feine Sache.