-         
Seite 10 von 10 ErsteErste ... 8910
Ergebnis 91 bis 98 von 98

Thema: Bascom Bug melden

  1. #91
    Benutzer Stammmitglied
    Registriert seit
    21.02.2008
    Beiträge
    35

    Ausrufezeichen Fehler bei Single Multiplikation mit kleinen Werten

    Anzeige

    Bug Report:

    Betrifft Bascom nach dem letzten Update auf 2.0.7.7
    Hier liegt ein Fehler bei der Berechnung von Single-Variablen vor. Wenn man eine Variable nur oft genug mit 0.9 multipliziert, wird die wie erwartet 0. Wenn man weiter macht wird sie irgendwann NAN und dann irgendwann irgendwas ganz großes. Hier ein Beispielprogrämmchen mit dem der Fehler auf einem xmega nachvollzogen werden kann.
    Code:
    $regfile = "xm256a3def.dat"
    $crystal = 32000000                                                                                                     '32MHz
    $hwstack = 256
    $swstack = 256
    $framesize = 256
    $lib "xmega.lib"
    $external _xmegafix_clear
    $external _xmegafix_rol_r1014
    
    Config Portf.3 = Output
    Config Portf.2 = Input
    
    Dim A As Single
    Dim Loopcount As Long
    
    Config Osc = Enabled , 32mhzosc = Enabled
    Config Sysclock = 32mhz , Prescalea = 1 , Prescalebc = 1_1
    Config Com7 = 9600 , Mode = Asynchroneous , Parity = None , Stopbits = 1 , Databits = 8
    
    Open "COM7:" For Binary As #1
    A = 10
    Wait 5
        Do
            Incr Loopcount
            A = A * 0.9
            Print #1 , Loopcount ; "    " ; A
        Loop
    Der Fehler tritt nach 853 Durchgängen (NAN) und nach 1485 Durchgängen (3924871168.0) auf. Ändert man die Zeile A=A*0.9 in
    A=A*9
    A=A/10
    funktioniert alles einwandfrei. Es scheint, daß der Fehler nur bei Multiplikationen von sehr kleinen Werten auftritt. Ob es noch andere Fälle gibt ist mir zumindest nicht bekannt. Bei Bascom 2.0.7.6 tritt der Fehler nicht auf.
    Geändert von kritias (30.03.2014 um 22:37 Uhr)

  2. #92
    Benutzer Stammmitglied
    Registriert seit
    21.02.2008
    Beiträge
    35

    Jetzt ist es raus!

    Das ist kein Bug. Das war die NSA!
    http://www.elektor.de/news/EmbedNet-Mikrocontroller/

  3. #93
    Benutzer Stammmitglied
    Registriert seit
    21.02.2008
    Beiträge
    35
    Es gibt Neuigkeiten. Mark Alberts hat ein Update veröffentlicht. Einfach in Bascom auf Hilfe und Update. Der ganz normale Vorgang.

    An dieser Stelle nochmal besonderen Dank an Mark Alberts für die extrem schnelle Reaktion.

  4. #94
    Erfahrener Benutzer Roboter Genie Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.537
    Blog-Einträge
    127

    nosave Interrupt-Service-Routine Fallstricke

    BASCOM-AVR Demo Version 2.0.7.5 auf ATTiny25

    Es ist kein unmittelbarer Fehler, den ich in BASCOM-AVR Version 2.0.7.5 festgestellt habe, aber doch ein Verhalten, daß eine intensive Fehlersuche zur Folge hatte.

    Zum schnellen Datenaustausch hatte ich eine Interruptserviceroutine in Assembler mit auch noch einem timingkritischen Abschnitt darin ohne Sichern der Prozessorregister (bzw manuellem Sichern, Stichwort: nosave) geschrieben.

    Da es zu Problemen kam, nahm ich das Programm mittels Disassembler unter die Lupe und fand heraus, daß Bascom ohne Meldung Assemblerbefehle austauscht, anstatt eine Fehlermeldung oder zumindest eine Warnung zu erzeugen. Außerdem wird dabei ein Register benutzt, daß man in einer "nosave ISR" möglicherweise nicht gesichert hat. Siehe Kommentare im Code:
    Code:
    '### Verkürztes kompilierbares Demo zur Problembeschreibung
    '### BASCOM-AVR Demo Version 2.0.7.5 (Compiler Version 2.0.7.5)
    '
    $regfile = "ATtiny25.DAT"
    $framesize = 32
    $swstack = 32
    $hwstack = 34
    $crystal = 16000000
    
    Pcmsk = Bits(pcint3 , Pcint4)
    On Pcint0 Isr_receive_data_compelled Nosave                 'keine Register sichern
    Enable Pcint0
    Enable Interrupts
    
    Do
    Loop
    
    End                                                         'end program
    
    
    Isr_receive_data_compelled:
    
      sbi gifr, pcif                                            'löschen Interrupt Flag
    
    '### Mit Bascom assembliert und dann mit ReAVR von ja-tools zum Überprüfen
    '### disassembliert zeigte, daß aus der SBI Zeile ohne Warnung Folgendes entstand
    '### und dabei r23 verändert wurde.
    '###
    '###   lds        r23,(p3A+0x20)        ; io register
    '###   ori        r23,k20
    '###   sts        (p3A+0x20),r23        ; io register
    '###
    '### OK, SBI kann nicht auf das GIFR im ATTiny25 zugreifen, da das Register außerhalb
    '### des Adressbereiches von SBI liegt.
    '###
    '### In einer ISR, die keine Register sichert kann die Änderung von r23 OHNE Warnung
    '### aber fatal werden. Bei zeitkritischen Routinen können außerdem die zusätzlichen
    '### Takte des Ersatzcodes noch graue Haare wachsen lassen wenn man von dem Austausch
    '### zunächst nichts mitbekommt - Programm läuft ja eigentlich.
    
    Return
    In der gleichen "nosave ISR" verwendete ich folgendes Kommando:
    Loadadr Flash_data(write_block_array_pointer) , X
    Hier wird das Register r10 verändert. (Das X für r26, r27 steht, ist normalerweise bekannt)

    Problem ist nicht weitergemeldet und vielleicht ist das ja auch irgendwo dokumentiert.
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  5. #95
    Benutzer Stammmitglied
    Registriert seit
    21.02.2008
    Beiträge
    35
    Ich gehe da immer so vor:
    ich schließe zeitkritische Teile mit einer Menge NOP ein und kompiliere das ganze. Das Ergebnis sehe ich mir dann im AVR-Studio in Assembler an. Durch die vielen NOPs ist die Stelle auch leicht zu finden. Den Zeitkritischen Assembler-Teil optimiere ich dann. Also das unnötige wegspeichern der Register entfernen, so wenige wie möglich Register verwenden und was einem sonst so auffällt. Dann muss ich im Falle eines Interrups nur noch die verwendeten Register sichern. (Nosave!) Dabei hat Bascom noch nie etwas einfach so geändert.Die NOPs kommen nach getaner Arbeit weg. Verzählen darf man sich halt nicht wenn man den Stack von Hand beackert. Da hab ich schon meine bösen Überraschungen erlebt. War dann aber meine Dummheit und kein Fehler von Bascom.

  6. #96
    Erfahrener Benutzer Roboter Genie Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.537
    Blog-Einträge
    127
    Zitat Zitat von kritias Beitrag anzeigen
    Ich gehe da immer so vor:
    .
    .
    Ja, so oder so ähnlich werde ich das auch in Zukunft machen. Ich war halt total überrascht, daß ein Assemblerbefehl ausgetauscht wurde. Mit gutem und richtigen Grund, da ja auf einem ATTiny25 ein SBI GIFR,PCIF nicht möglich ist. Das sollte aber bei einem Assembler Befehl nicht ohne dicke rote Warnung geschehen. Der Compiler/Assembler hat ja erkannt, daß da etwas nicht paßt und könnte eben auch eine Meldung erzeugen. Vielleicht wurde auch in höheren Versionen da schon etwas vorgesehen.

    Bei LOADADR mit einem indirekt adressierten Array als Argument würde mich ein Hinweis auf das zusätzlich verwendete Register zufrieden stellen

    Ich hatte bisher in nosave ISRn immer nur die Register gesichert, die ich auch selbst in der ISR verwendet habe. Trotz der möglichen Verbesserungen finde ich den einfachen Gebrauch von Assembler innerhalb von Bascom Programmen genial.

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  7. #97
    Erfahrener Benutzer Roboter Genie Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.537
    Blog-Einträge
    127
    Zitat Zitat von Searcher Beitrag anzeigen
    Code:
      sbi gifr, pcif                                            'löschen Interrupt Flag
    
    '### Mit Bascom assembliert und dann mit ReAVR von ja-tools zum Überprüfen
    '### disassembliert zeigte, daß aus der SBI Zeile ohne Warnung Folgendes entstand
    '### und dabei r23 verändert wurde.
    '###
    '###   lds        r23,(p3A+0x20)        ; io register
    '###   ori        r23,k20
    '###   sts        (p3A+0x20),r23        ; io register
    '###
    '### OK, SBI kann nicht auf das GIFR im ATTiny25 zugreifen, da das Register außerhalb
    '### des Adressbereiches von SBI liegt.
    '###
    '### In einer ISR, die keine Register sichert kann die Änderung von r23 OHNE Warnung
    '### aber fatal werden. Bei zeitkritischen Routinen können außerdem die zusätzlichen
    '### Takte des Ersatzcodes noch graue Haare wachsen lassen wenn man von dem Austausch
    '### zunächst nichts mitbekommt - Programm läuft ja eigentlich.
    Was mir gerade bewußt geworden ist. Diese Zeilen
    Code:
    lds        r23,(p3A+0x20)        ; io register
    ori        r23,k20
    sts        (p3A+0x20),r23        ; io register
    die Bascom statt dem "sbi gifr, pcif" eingesetzt hat, löschen nicht nur das PCI-Flag, sondern alle Interrupt Flags im GIFR. Übel! Das "ori" ist gut um in anderen Registern Bits zu setzen aber gar nicht gut um ausgewählte Interrupt Flags zu löschen.

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  8. #98
    Erfahrener Benutzer Roboter Genie Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.537
    Blog-Einträge
    127
    Zitat Zitat von Searcher Beitrag anzeigen
    Da es zu Problemen kam, nahm ich das Programm mittels Disassembler unter die Lupe und fand heraus, daß Bascom ohne Meldung Assemblerbefehle austauscht, anstatt eine Fehlermeldung oder zumindest eine Warnung zu erzeugen.
    Ich hatte dieses Verhalten doch noch an mcs gemeldet, da ich beim Löschen eines Interrupt Flags dadurch echte Fehler bekam und habe auch Antwort bekommen.

    Kurz: Das Verhalten ist kein Fehler, sondern ist so designed. Es gibt aber einen switch, mit dem man den Austausch der asm Befehle verhindern kann. Bei Verhindern des Austausches mit dem switch kommt es dann zu einer Fehlermeldung in meinem Beispiel. Tja, hätte ich die Doku doch vorher gründlicher, noch gründlicher gelesen

    Der switch ist "$notransform on". Steht in der Doku zwar mit Doku-Fehlern, die aber von mcs noch behoben werden.

    Der switch wird ab sofort bei mir in Verbindung mit asm intensiv genutzt werden!

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

Seite 10 von 10 ErsteErste ... 8910

Berechtigungen

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