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.
Geändert von raidy (26.10.2011 um 12:14 Uhr)
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!
Mit bestem Gruß
Frank
Admin Roboternetz.de - RN-Wissen.de - Elektronik-Blog
Überzeugter und begeisterter Elektroauto Fahrer seit 2018
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.
Geändert von raidy (25.10.2011 um 14:52 Uhr)
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.
Lesezeichen