Bascom Bug in "Dim Variable as Eram Byte"

[raidy]

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.

[Michael]

Hallo raidy,

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

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

also ist Bascom doch nicht schuld?

Gruß, Michael

[Richard]

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

[Frank]

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!

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