Printbin Fehler beim Mega328

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Printbin Fehler beim Mega328

      Während es beim Mega8 wie erwachtet funktioniert wird beim 328 das erste (letzte Byte durch ein b im Simulator und ein B in der gebrannten Version ersetzt ?(

      Quellcode

      1. $regfile = "m328pdef.dat"
      2. '$regfile = "m8def.dat"
      3. $crystal = 1000000
      4. $hwstack = $64
      5. $swstack = $64
      6. $framesize = $96
      7. $baud = 9600
      8. $eepleave
      9. $sim
      10. Config Base = 0
      11. Config Print = Portb.0 , Mode = Set 'Bei dieser Anweisung entsteht der Fehler
      12. Const Id = &H20316469 ' id1
      13. Const Bhelp = &H706C6568
      14. Const Bvers = $73726576
      15. Const Abled = $64656c62
      16. Printbin Id ; Abled ; 13 ; 10
      17. Printbin Id ; Bhelp ; 13 ; 10
      18. End
      Alles anzeigen
    • Pluto25 schrieb:

      Printbin Id ; Abled ; 13 ; 10
      Im Source gibst du binär Werte aus.
      In der obigen Zeile ist das am ende der Dezimalwert 10. das entspricht Hex B.

      Wird vielleicht das letzte Bit verschluckt durch den End-Befehl?

      Anstelle des END
      Kann man auch mal

      Do
      Loop

      schreiben.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Mitch64 ()

    • tschoeatsch schrieb:

      die $-Zeichen

      Mitch64 schrieb:

      nur in Libs zulässig
      Sei funktionieren problemlos. In dem Fall hatte ich die ersten ersetzt um festzustellen ob es sie vielleicht doch schuld waren - wär' zu einfach gewesen.

      Kalle_BMW schrieb:

      das ist nicht das Problem
      richtig

      Mitch64 schrieb:

      Dezimalwert 10. das entspricht Hex B
      richig =lf (Line Feed)

      Mitch64 schrieb:

      das letzte Bit verschluckt durch den End-Befehl
      der Code ist das "Extrakt" aus einem größeren, der nie zum end kommt.(kommen sollte)

      Michael schrieb:

      $sim ist immer schlecht in Programmen
      Hab ich von Euch gelernt. Hat bisher auch nie ein Problem gemacht. Und wenn es mal nicht auskommentiert war fiel das sofort auf weil weder Ausgabe noch Timing stimmte.

      tschoeatsch schrieb:

      beiden Kontrollern gleich aus
      gleich richtig oder gleich falsch? ;)
      Die Konstanten verhalten sich wie Dwords. Die if /case Abfragen funktionieren richtig. Allein das Printbin tut seltsam sobald er im 485 Mode ist.
    • Pluto25 schrieb:

      gleich richtig oder gleich falsch?
      keine Ahnung, ich hab' im Simulator nur auf die Uart-Ausgabe geschaut. Was da angezeigt wird, hab' ich nicht kapiert, war mir aber egal, ich sah aber die Unterschiede bei verschiedenen Kontrollern. Mit Variablen gibt's eben keine Unterschiede mehr. Ist schon verdächtig.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Hab mich selber aufgeklärt.

      Der Uart wird als 485-Bus verwendet.
      Und der Config Print dient dazu, den Richtungspin zu konfigurieren.

      Soweit OK.

      Aber nochmal wegen dem END

      Der Controller geht meines Wissens in einen HALT-Zustand.
      Ich weis nicht, ob da die letzten Bits noch übertragen werden.

      Ich würde dafür Testweise eine

      Do
      Loop

      versuchen.

      Ein Bug wäre auch noch denkbar.
    • Mitch64 schrieb:

      wegen dem END
      Ich kann versicheren das das End nicht schuld ist. Der vollständige Code läuft nun einige Tage und hat sich inzwischen einige tausend mal mit "id1B" gemeldet ohne je abzustürzen. Der Printbin befehl steht in einer Sub in Zeile 927. Das fiel erst gar nicht auf weil das empfangende Programm nur die ersten drei Zeichen auswertet um weiter zu arbeiten. Erst als ich mit hterm dazwischenfunken wollte sah ich "wie spricht der denn". Und seid dem versuche ich das Problem zu erkennen.

      Mitch64 schrieb:

      Der Controller geht meines Wissens in einen HALT-Zustand.
      dafür ist es da. Besser als er saust durch die danach folgenden Subs und dreht dann ganz durch. a_217_27b18bee
      Selbst im Simulator kommt noch einiges wenn das End fehlt. In der Realität wenn dort Schütze, Motoren, Brenner dranhängen a_166_29aea317

      Mitch64 schrieb:

      Ein Bug wäre auch noch denkbar.
      Deswegen die Reduzierung auf 19 Zeilen und das &H . Der Bug ist irgendwo in Bascom?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Pluto25 ()

    • Pluto25 schrieb:

      beim 328 das erste (letzte Byte durch ein b im Simulator und ein B in der gebrannten Version ersetzt
      Schaut man sich die beiden Buchstaben in Ascii an, sind sie nur durch ein Bit verschieden. Da das LS-Bit zuerst übertragen wird, ist das eher am Ende der Byte-Übertragung. Da der AVR auf 1MHz intern läuft, ist er vermutlich a, weder sonderlich genau und b, trifft er die eingestellte Baudrate auch nicht.
      Beides zusammen mag hier dazu führen, dass der PC an der entsprechenden Stelle 2 Bits statt einem liest.
      Am Atmega8 würde ich das nicht festmachen, jeder Oszillator ist anders.

      Pluto25 schrieb:

      Der Bug ist irgendwo in Bascom?
      dann wäre er schon längst aufgefallen. Anfänger neigen oft dazu, Bugs in Bascom zu sehen, wo er doch ganz woanders sitzt :D
    • Michael schrieb:

      ist das eher am Ende der Byte-Übertragung
      Die min Länge sind 10Byte das B ist das vierte. Alle anderen (max 42) kommen richtig an.

      Michael schrieb:

      trifft er die eingestellte Baudrate auch nicht
      Das war bisher erst bei einem der Fall und der ließ sich problemlos mit Osccal anpassen.
      Im Simulator sollte die Baud-verschiebung nicht erfasst werden können? (Er würde seine eigene Ausgabe anzweifeln)

      Michael schrieb:

      nur durch ein Bit verschieden
      ? aus Space(32) 0100 000 wird B (66)0100 0010 im Sim b(98)0110 0010
    • Ich hab' ja das Originalprogramm einfach compiliert und im Simulator laufen lassen. Da gibt es ja die Uartausgabe. Da wird die baudRate passen, zumindest nicht vom Kontroller zu Kontroller unterschiedlich sein. Und es kommen bei Konstanten unterschiedliche Ausgaben, ob mega8 oder mega168/mega328. Das ist doch das komische. Verwendet man Variablen, ist kein Unterschied sichtbar.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Ich hab sie mal durchprobiert allein der Mega8 machts richtig, die meißten anderen machen aus dem 4.(1.)Byte ein "b". Der atmega328pb macht ein " ` ".

      Quellcode

      1. $regfile = "m328def.dat" 'b
      2. '$regfile = "m328pdef.dat" 'b
      3. '$regfile = "m328pbdef.dat" '`
      4. '$regfile = "m168pbdef.dat" 'b
      5. '$regfile = "m168pdef.dat" 'b
      6. '$regfile = "m168def.dat" 'b
      7. '$regfile = "m8def.dat" 'ok
      8. '$regfile = "m8adef.dat" 'ok
      9. '$regfile = "m88def.dat" 'b
      10. '$regfile = "m88pdef.dat" 'b
      11. '$regfile = "m88pbdef.dat" 'b
      12. '$regfile = "m48def.dat" 'b
      13. '$regfile = "m48pdef.dat" 'b
      14. '$regfile = "m48pbdef.dat" 'b
      Alles anzeigen
    • Ich habe in Bascom (Optionen -> Compiler -> Communication) mal deine Taktfrequenz (1MHz) und deine Baudrate (9600) eingegeben.
      Dabei wird eine Fehlerrate von 7,84% angezeigt.

      Versuche mal die Baudrate auf 4800 oder 2400 zu reduzieren, da ergibt sich ein Fehler von nur 0,16%. Ist schon mal deutlich besser.
      Alternativ kann man auch die Taktfrequenz erhöhen.

      Aus eigener Erfahrung und stundenlanger Fehlersuche an eigenen Projekten habe ich mir auf die Fahne geschrieben:
      Bei Uart-Verwendung immer Quarz verwenden!

      Um deinen Fehler zu finden, würde ich, bis der Übertragungsfehler gefunden ist ein Quarz einsetzen. Später kannst du immer noch auf den internen Oszillator gehen und den kalibrieren.
    • Ich habe das Programm von ganz oben mal bei mir in den Simulator genommen.

      Habe verschiedene Baudraten, Taktfrequenzen probiert,
      mal mit Confog Print, mal ohne,
      mal mit $SIM, mal ohne.

      Es kommt bei mir immer das gleiche im Simulator raus. (Im Uart0-Fenster auf Hex-Anzeige umgestellt)

      Es wird alles vom PrintBin ausgegeben bis auf das Linefeed (10 am Ende des Befehls).

      Ein B kommt bei mir nicht.

      Damit habe ich getestet:

      BASCOM-Quellcode

      1. $regfile = "m328pdef.dat"
      2. '$regfile = "m8def.dat"
      3. $crystal = 1000000
      4. '$Crystal = 8000000
      5. $hwstack = $64
      6. $swstack = $64
      7. $framesize = $96
      8. $baud = 9600
      9. '$Baud = 4200
      10. $eepleave
      11. $sim
      12. Config Base = 0
      13. Config Print = Portb.0 , Mode = Set 'Bei dieser Anweisung entsteht der Fehler
      14. Const Id = &H20316469 ' id1
      15. Const Bhelp = &H706C6568
      16. Const Bvers = $73726576
      17. Const Abled = $64656c62
      18. 'Printbin Id
      19. 'Printbin Abled
      20. 'Printbin 13 ; 10;
      21. Printbin Id ; Abled ; 13 ; 10
      22. Printbin Id ; Bhelp ; 13 ; 10
      23. Do : Loop
      Alles anzeigen
      und hier ein Screenshoot:
      Dateien
      • Simulation.PNG

        (32,48 kB, 21 mal heruntergeladen, zuletzt: )