Serout und Uart0 stören sich?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Serout und Uart0 stören sich?

      Liebes Forum,

      hich habe mal wieder ein komisches Problem:

      Auf einem 256ger gebe ich per Uart0 mit Print in regelmäßigem Abstand alle paar Sekungen ein paar Daten aus.
      Die können dann z.B. mit einem Hyperterm empfangen werden.
      Parallel kann es im Programm dazu kommen, das per Serout-Befehl über einen Soft-Uart ein Soundmodul angesteuert wird.
      Hier gibt es aber offensichtlich ein Problem, denn das Soundmodul (ich gebe damit Sprachansagen aus) sagt nichts mehr, nachdem ich eine Phrase ausgelöst konnte.
      Also: Es "spricht" einmal, danach nicht mehr.

      Ich habe nun den Verdacht, dass hier Uart0 und der Soft-Uart sich stören, denn wenn ich die Datenausgabe auf Uart0 im Code auskommentiere, läuft das Sprachmodul ohne Anstand.

      Kann es sein, dass die sich irgendwie in die Quere kommen?
      Z.B. weil Bascom serielle Ausgaben mit einer Routine abarbeitet, die dann "explodiert", oder sowas?
    • Hi Zitronenfalter, es ist das "MP3-Flash-10P" von Flyron.
      Wir haben das genommen, weil es einen Flash-Speicher hat, mit SD Karte ist das so eine Sache mit den den Kontakten auf Dauer. Das Ding ist in meinem Controller der Streambox verbaut, und die sitzt in der (manchmal) etwas kalten Leibung bei den Fenstern, da wollten wir nichts riskieren von wegen Kondensat an den feinen Kontakten der SD-Cards.

      Verirrte Zeichen waren auch mein erster Gedanke, das wird es auch sein. Aber da die Ports ja völlig unterschiedlich sind (ein Soft-Uart und Uart0)...wo sollen die falschen Zeichen herkommen, denn wenn ich Uart0 deaktiviere, gibt es mit dem Modul ja keine Probleme.
      Es muss also tatsächlich was mit falschen Zeichen zu tun haben, aber warum kommen überhaupt falsche Zeichen vom Uart0 an den Softuart, das war ja eigentlich auch die Frage, also quas meine letzter Satz aus der ersten Mail.
      Ob also alle seriellen Ausgaben mit der selben Routine in Bascom abgearbeitet werden und sich daher was verheddern kann...

      Grüße Peer
    • Also es sollte jedenfalls egal sein ob Soft- oder Hard-RS232.
      Ausser es beist sich da was in der Software wie z.B. dass ein IRQ reinschießt.

      Was ich meinte ist wie denn der Print-Befehl abgehandelt wird.
      Denn bei
      Print "Test";
      wird eben kein CRLF mitgesendet, bei
      Print "Test"
      aber schon (man beachte das Semicolon!).

      Und diese Module mögen meistens eben keine weiteren Zeichen nach dem Befehlsstring.
      Ich weiß aber jetzt nicht, ob da irgend eine Fehlerabhandlung von wegen z.B. löschen des Empfangsbuffers des Moduls integriert ist wo das dann sogar egal wäre wenn dann wieder ein korrekter Befehlsstring gesendet wird.
    • Da du keinen Code zeigst, kann man auch nur Raten!

      Aber ich sehe 2 Dinge als mögliche Ursache, wenns mit der seriellen Schnittstelle nicht klappt.
      Wenn man internen Clock verwendet, ist der Takt zu ungenau (Fehlerrate).
      Selbes gilt bei ungünstiger Quarzfrequenz bezogen auf die Baudrate.

      Software-Uart ist immer dann Kritisch, wenn während der Ausgabe auf diesem Interrupts ausgeführt werden.
      Das Bringt das Timing durcheinander.
      Solche Quellen sind z.B. Timer-Interrupts oder z.B. ein Sende/Empfangsbuffer für Uart.

      Ich glaube kaum, dass vom Hardware-Uart irgendwelche wirren Zeichen auf den Sortware-Uart kommen.
      Die Code-Routinen sind völlig getrennt.


      Fazit:
      1. Baudraten-Quarz verwenden (Fehlerrate 0% bei der/den gewünschten Baudrate/n).
      2. Interrupts abschalten, wenn auf dem Software-Uart gesendet oder empfangen wird.
    • @ Zitronenfalter: Ja, das stimmt. Das habe ich aber nicht im Code, also ein Semikolon in der Zeile am Ende (aber das checke ich noch mal, nicht dass ich hier was übersehen habe), sollte aber nicht auf einen völlig anderen Port durchschlagen

      @ Mitch64: Mit dem Code ist das so eine Sache, weil der 8000 Zeilen hat und ich das nur schlecht separieren kann, außerdem könnte der Fehler von irgendwo aus dem Code einstreuen...
      Ich verwende natürlich einen Baudratenquarz 7.4.... MHz (ist die 3V-AVR-Variante, der kann nur 8MHz), oder sowas. Sollte also nicht das Problem sein.
      Wie gesagt, es geht beides einzeln ohne Probleme. Die Print-Ausgabe macht auch überhaupt keinen Ärger.
      Der Sound an sich auch nicht, nur, wenn ich beides hintereinander betreibe, dann hakts beim Soundmodul mit "Serout"...
      Und richtig, die Interrupts habe ich auch schon abgeschaltet, hat aber noch nichts gebracht, aber ich versuche es hier weiter.

      Außerdem versuche ich mal, die serielle Print-Ausgabe in der Zeit der Soundausgabe zu vermeiden. Der Soundchip gibt mir ja ein Busy-Signal....
    • Sato wrote:

      Kannst uns bitte erzählen wo dieses Modul zu kaufen ist und fals möglich auch den Preis?
      Die Suche bei google brachte folgende Ergebnisse:

      5 stücke X MP3-FLASH-10P YX6100-16S MP3 ... - AliExpress

      5pcs X MP3-FLASH-10P YX6100-16S MP3 module SPI drive ...

      1pcs X MP3-FLASH-10P YX6100-16S MP3 module SPI drive ...

      und viele weitere :)
      Eine Lösung habe ich nicht, aber mir gefällt Ihr Problem.
    • Peer Gehrmann wrote:

      Das habe ich aber nicht im Code, also ein Semikolon in der Zeile am Ende
      Da dieses Soundmodul offenbar ähnlich funktioniert wie auch der DF-Player-Mini (USB oder SD-Medium) aber auch wie die Module JQ6500 oder JQ8400 (Flash-Medium) und wohl einen Befehlsstring (der aus acht Byte besteht) erwartet der wiederum aus allen 256 möglichen Bytes bestehen kann, kann es sein, dass es da dann eben "kracht" wenn irgend etwas diese Befehlsausgabe stört.

      Kanst du die Schnittstelle nicht via Open-Befehl verwenden und in der Folge den PrintBin-Befehl verwenden?
      Hier bei mir funktionieren die so angesteuerten DF-Player so einwandfrei mit ATmega328 wo an der HW-Schnittstelle mit RS485 gesprochen wird und auf einem SW-Port dann der DF-Player angesteuert wird. Und ein 20ms - IRQ läuft auch dauernd mit.

      Du müsstest ja zuerst mal klären was da überhaupt genau passiert (also statt dem Soundmodul mal zu einem Terminalprogramm schreiben, um zu sehen, ob und was da genau gesendet wird.
      Ebenso ist unklar wie die Module reagieren wenn der Datenstrom nicht korrekt ist. Im Idealfall verwirft das Modul einfach die empfangenen Daten solange bis z.B. das Stopp-Byte kommt, im Extremfall erwartet es eben die acht Byte und wenn das Start- und Stopbyte nicht korrekt daherkommen, funktioniert das halt nicht, Ich denke aber, dass die soweit Intelligent sind auf das Startbyte zu warten und dann die nächsten sieben Bytes zu verarbeiten (es also zu gar keinem Dead-Lock kommt).
      Die Module sind ja eigentlich auch Plaudertaschen und geben so sogar einige Antworten zurück (verarbeitest du diese oder sendest nur "stur" Befehle hin?

      In der Hilfe steht übrigens sogar explizit beim Serour-Befehl, dass die IRQs stören können.
    • Peer Gehrmann wrote:

      die serielle Print-Ausgabe
      Ist sie buffered? Andernfalls benutzt sie keine Interrupts. Der Empfang allerdings schon. Spricht ihn jemand an? (Echo?)
      Ein SW Uard verträgt keinerlei Ints. Aber werden die nicht sowieso von der Routine bei jedem Byte global abgeschaltet ? Sonst würde jede Art Int stören (Timer ect) Wohl schein bar nicht (s. Zitronenfalter)
      Dann muß man das wohl selbst übernehmen. Aber schon erstaunlich das es nicht "immer" zu Problemen kommt - oder hat der Code kaum Ints?
      Ein Übersprechen oder Stromversorgungsengpass kann ausgeschlossen werden?
      Was sagt ein Oscar zu der Signalqualität?
      Eine Doppelverwendung von Variablen? Nicht das eine Int zwischen zwei Byte die Sendung schreddert.
      Was würde ein anderes Gerät beim mithören Empfangen? Das würde solche Fehler gut zeigen.