Bascom Bug in "Dim Variable as Eram Byte"

Nachtrag/EDIT: Der "Fehler" liegt im AVR, wenn man BOD nicht verwendet!!! (siehe weiter unten)


Lange habe ich nach dem Fehler gesucht, doch jetzt habe ich ihn gefunden.

Wer in einem ATTiny Werte fest im Eram ablegen will sollte immer wie folgt vorgehen:


Dim Eedummy As Eram Byte 'AVR bug in eeram byte 1, deshalb 1.tes Byte als Dummy anlegen und nicht nutzen
Dim Akkuleer As Eram Word ....

Das erste Byte im Eram lässt sich nicht richtig ansprechen, warum auch immer. Deshalb lege ich das erste Byte auf eine nicht benutzte Variable "Dim Eedummy As Eram Byte" ab und benutze diese nie.
Ab jetzt kann man weitere Variablen beliebigen Typs ablegen und auslesen. Der Fehler ist in allen Bascom-Versionen. Ich vermute, der Fehler liegt nich im ATTiyn selbst.

Hallo raidy,

wie macht sich denn der Fehler bemerkbar?
"Lässt sich nicht richtig anssprechen" ist für mich nicht richtig nachvollziehbar.

Zitat:

---

Der Fehler ist in allen Bascom-Versionen. Ich vermute, der Fehler liegt im ATTiyn selbst.

---

also ist Bascom doch nicht schuld?

Gruß, Michael

Zitat:

---

Zitat von Michael

also ist Bascom doch nicht schuld?

Gruß, Michael

---

Wahrscheinlich nicht, Ich habe darüber schon etwas (sogar mit Begründung) gelesen, aber leider genaues vergessen. Irgrndwie (kann) unter bestimmten Bedingungen beim Initialisieren des Chip's das erste Byte im Eram mit zufälligen Werten belegt werden. Das ist allerdings eigentlich recht bekannt, es wird allgemein davor gewarnt das 1. Byte vom Eram bei AVR's zu benutzen.

Gruß Richard

Das erste Byte im ERAM ist bei vielen AVR´s problematisch. Stürzt der Controller ab oder gerät durch Spannungsabfall in undefinierbaren Zustand, so wird das erste Byte oft überschrieben.
Ich nutze in der Regel die ersten 5 Bytes nicht mehr, einfach zur Sicherheit!

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.

Zitat:

---

Zitat von raidy

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.

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.

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.

Zitat:

---

Zitat von 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.

---

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.

Zitat:

---

Zitat von raidy

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.

Zitat:

---

Zitat von MagicWSmoke

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.