-         

+ Antworten
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 11

Thema: Bascom Bug in "Dim Variable as Eram Byte"

  1. #1
    Benutzer Stammmitglied Avatar von raidy
    Registriert seit
    26.09.2006
    Ort
    bei Stuttgart
    Beiträge
    52

    Bascom Bug in "Dim Variable as Eram Byte"

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    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)

  2. #2
    Erfahrener Benutzer Roboter Genie Avatar von Michael
    Registriert seit
    17.01.2004
    Ort
    Karlstadt
    Alter
    47
    Beiträge
    1.246
    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

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.556
    Zitat Zitat von Michael Beitrag anzeigen


    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

  4. #4
    Administrator Robotik Einstein Avatar von Frank
    Registriert seit
    30.10.2003
    Beiträge
    4.955
    Blog-Einträge
    1
    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

  5. #5
    Benutzer Stammmitglied Avatar von raidy
    Registriert seit
    26.09.2006
    Ort
    bei Stuttgart
    Beiträge
    52

    Warum ich BASCOM-Fehler geschrieben habe?

    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)

  6. #6
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    01.10.2009
    Beiträge
    437
    Zitat Zitat von raidy Beitrag anzeigen
    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.

  7. #7
    Benutzer Stammmitglied Avatar von raidy
    Registriert seit
    26.09.2006
    Ort
    bei Stuttgart
    Beiträge
    52
    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: http://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.

  8. #8
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    01.10.2009
    Beiträge
    437
    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.

  9. #9
    Benutzer Stammmitglied Avatar von raidy
    Registriert seit
    26.09.2006
    Ort
    bei Stuttgart
    Beiträge
    52
    Zitat Zitat von MagicWSmoke Beitrag anzeigen
    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.

  10. #10
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    01.10.2009
    Beiträge
    437
    Zitat Zitat von raidy Beitrag anzeigen
    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.

+ Antworten
Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Ämfänger braucht hilfe "Byte nach BCD auf Portx"
    Von dremeier im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 10
    Letzter Beitrag: 07.09.2008, 17:03
  2. Byte wird "rückwärts" ausgegeben
    Von ikarus_177 im Forum AVR Hardwarethemen
    Antworten: 3
    Letzter Beitrag: 31.07.2008, 13:55
  3. Jeweils 2 Bit mit einem byte "verknüpfen"
    Von kalletronic im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 4
    Letzter Beitrag: 24.11.2007, 22:00
  4. Ziffern aus einer Integer Variable "extrahieren"
    Von coCo im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 3
    Letzter Beitrag: 17.05.2007, 22:09
  5. "byte" in Eclipse einfärben
    Von cumi im Forum C - Programmierung (GCC u.a.)
    Antworten: 0
    Letzter Beitrag: 11.05.2006, 17:09

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •