Sound parallel zu anderen Aktionen

    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!

    • Es ist ja auch kein Problem und sicherlich fällt der Effekt bei den Frequenzen noch nicht sonderlich auf. Es sind verschiedene Geräte. Die 128 boten sich an weil er nur einmal pro Mitnute reagieren muß. Bei dem anderen wurden die 8Mhz erzwungen weil sonst die Servos verückt spielten. Letzeres soll vielleicht auch irgenwann kommuniezieren können. Aber erst wollte ich das doofe wechselnde LCD loswerden und dem ganzen das "sprechen" beibringen um dannach das IP-verlierende AVR-Net zu ersetzen. Spätestens dann werde ich bestimmt wieder Probleme bekommen. Sinn er meisten ist die Heizungsanlage zu steuern/loggen.
      Die Lösung ist ja auch nicht zwingend Projectbezogen; es ist einfach gut den Timer2 zappeln lassen zu können für evtuelle zukünftige Lösungen (z.B Blaulicht-sirene) oder wichtiger zu wissen das der Simulator nicht immer vollständig richtig liegt.
    • Fühlt sich komisch an, auf der einen Seite ist die Verarbeitung der seriellen Daten zeitkritisch und auf der anderen Seite den Takt runternehmen und 0,5 mA zu sparen.
      Die gepufferte serielle Schnittstelle benutze ich auch gerne, weil ich dann auch 2 zeitkritische Themen gut gelöst bekomme.
      Was das Bitkippeln u.ä. angeht: Solange Grundregeln wie Kondensator direkt an Vcc und GND und keine offenen Pins mit elektrostatisch verhüllter Umgebung da sind - da passiert einfach nichts.
      Die Drahtverhaue von TTL-Schaltungen im Maschinenbau sind auch mit 10-20MHz gelaufen, ohne täglich auszufallen.

      Meistens ist die Software das Problem und deren zu Grunde liegende Architektur.
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • hero schrieb:

      monkye schrieb:

      Die gepufferte serielle Schnittstelle benutze ich auch gerne, weil ich dann auch 2 zeitkritische Themen gut gelöst bekomme.
      Aber hoffentlich nicht wie Pluto mit Bytematch=All. Dann kann es nicht so zeitkritisch sein.

      Die Idee hinter der Pufferung ist ja die zeitliche Entkopplung zwischen Senden/Empfangen ggf. mit Hardwareunterstützung. Damit prüfe ich i.d.R. in der Mainloop, ob eine Verarbeitung notwendig und möglich ist, damit bestimmte Prozesse nicht unterbrochen werden.
      Das geht umso besser, je mehr Takte während des „Frei“-Phase zur Verfügung stehen.

      Es macht auch manchmal Sinn, bestimmte Aktionen zu bestimmten Zeiten zu unterlassen - z.B. damit das Display nicht Schrott anzeigt...

      Nachtrag: Das Ganze nennt sich auch Priorisieren :)
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • Hallo monkye,
      schon recht.
      Mir ging es darum, darauf hinzuweisen, dass diese Pufferung nicht irgendwie magisch über HW zustande kommt, weil die AVRs dazu nichts an Board haben, sondern gleichwohl in SW erstellt wird. Dies kann im Hintergrung durch den Config Serialin Befehl stattfinden, wobei du dabei keinen Einfluss hast, was dort genau passiert und ob all dies für deinen Fall nötig ist. Oder du kannst es selber machen, wozu nur drei oder vier Befehle nötig sind und du dann die volle Kontrolle hast.
    • Hallo
      ich habs nun zusammengebaut und er zappelt und er ist MOSI


      djmsc schrieb:

      Dann nimm doch ein anderes Display


      darauf hätte ich hören sollen. Es scheint Glühbirnen als Hintergrundbeleuchtung zu haben. Sie braucht mehr Strom als ich einen Pin zumuten möchte. Dann hängt sein Vo über 20k an Vdd womit der OC2=MOSI -pin so stak belastet wird das ich das Display ausstöpseln muß um die ISP zu benützen.
      Aber erstmal kann es seinen Job tun.

      Die serielle Geschichte wird doch umfangreicher als zuerst vermutet. Gibt es bei Bascom nicht die Möglichkeit das eingegangene Zeichen gleich wieder zurückzusenden?
      Dann könnte ich Bytematch auf Enter setzen wobei dann jedoch der Buffer überlaufen könnte und dann geht gar nix mehr. Läßt der sich nicht als Ring auslegen oder automatisch löschen falls er überläuft?

      hero schrieb:

      Oder du kannst es selber machen,
      ist vermutlich die beste Lösung , andererseits hat Bascom ja den großen Vorteil nicht alles selber machen zu müssen.

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

    • Pluto25 schrieb:

      Gibt es bei Bascom nicht die Möglichkeit das eingegangene Zeichen gleich wieder zurückzusenden?
      Klar, printen in der Serial0ByteReceived

      Pluto25 schrieb:

      Dann könnte ich Bytematch auf Enter setzen wobei dann jedoch der Buffer überlaufen könnte und dann geht gar nix mehr.
      Mach doch den Buffer größer, du sagst doch, dass du genügend Speicher hast.

      Pluto25 schrieb:

      Läßt der sich nicht als Ring auslegen oder automatisch löschen falls er überläuft?
      Du wirst es nicht glauben, aber der Serial Buffer ist tatsächlich als Ringspeicher implementiert.
    • hero schrieb:

      Pluto25 schrieb:

      Gibt es bei Bascom nicht die Möglichkeit das eingegangene Zeichen gleich wieder zurückzusenden?
      Klar, printen in der Serial0ByteReceived

      Pluto25 schrieb:

      Dann könnte ich Bytematch auf Enter setzen wobei dann jedoch der Buffer überlaufen könnte und dann geht gar nix mehr.
      Mach doch den Buffer größer, du sagst doch, dass du genügend Speicher hast.

      Pluto25 schrieb:

      Läßt der sich nicht als Ring auslegen oder automatisch löschen falls er überläuft?
      Du wirst es nicht glauben, aber der Serial Buffer ist tatsächlich als Ringspeicher implementiert.

      Der Ringpuffer läuft m.M.n. nicht über, sondern schmeißt Zeichen weg. Es ist an Dir den Puffer passend auszulegen...
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • Klar, printen in der Serial0ByteReceived

      Nur wird die leider nicht mehr angesprungen sobald Bytematch was anders als all ist


      "Mach doch den Buffer größer, du sagst doch, dass du genügend Speicher hast."

      Dazu müsste ich vorhersehen könne wieviel Müll sich ansammeln könnte. Aber das Problem war keins denn Bytematch funktioniert noch wenn der Puffer "überläft" - richtig keine weiteren Zeichen aufnimmt. (Richtig Monkey)


      "Du wirst es nicht glauben, aber der Serial Buffer ist tatsächlich als Ringspeicher implementiert."

      Er hat zwar Tail und Head aber beide werden 0 beim "überlauf"

      Bleibt noch die Frage wie kriege ich das gerade reingekommene Zeichen wieder zurückgesannt . Dazu brächte ich sowas wie "ByteNotMatch:"
    • Oder Du verwaltest den Puffer selbst und reagierst auf den Interrupt URXC beim Empfang. Selbst mit dem Wegsichern aller Register schaffst Du bei 57k einen Durchsatz von 5-6kB mit einem ATMega328 und 16MHz.
      Der Stromverbrauch ist bei mir ca. 0,6 mA gewesen.
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • @monkye Das war mein Vorschlag vor gefühlten 30 Posts.


      Pluto25 schrieb:

      Aber das Problem war keins denn Bytematch funktioniert noch wenn der Puffer "überläft" - richtig keine weiteren Zeichen aufnimmt. (Richtig Monkey)
      Das Label Serial0ByteMatch wird in dem Fall angesprungen. Aber die Daten, die dann im Puffer stehen, wirst du nicht nutzen können, denn es ist ja wahrscheinlich etwas falsch gelaufen, sonst wäre der Puffer ja nicht übergelaufen. Also hilft das nur zum Synchronisieren auf das nächste Paket.


      Pluto25 schrieb:

      Er hat zwar Tail und Head aber beide werden 0 beim "überlauf"
      Zumindest werden beide gleich, wenn die max. Größe erreicht ist.
      Alle andere würde bei einem Ringpuffer keinen Sinn machen.

      Pluto25 schrieb:

      Dazu brächte ich sowas wie "ByteNotMatch:"
      Die Bascom Routine ist halt für verschiedene Anwendungsfälle geschrieben. Wenn du davon abweichen willst, wird es schwierig, diese weiter zu benutzen. Und es ist wirklich nicht so schwer, sich diese selber zu schreiben.
    • Das richtig Monkey bezog sich auf die wegeschmissenen Daten. Bei einem Ring würde ich erwarten das die tail auf das letzte eingegangene Zeichen zeigt und die jeweils ältesten überschrieben werden. Aber in diesem Fall ist es sowieso besser neu zu Synchronisieren.
      Ich hab das jetzt erstmal so gelöst:
      Serial0bytereceived:
      If Ring = 1 Then Print Chr(udr);
      If _rs_bufcountr0 >= 19 Then Clear Serialin0
      If Udr = 13 Then
      Neu = 1
      Ein = _rs_bufcountr0 - 1
      End If
      Return
      Um den URXC nutzen zu können muß ich es wirklich selber machen. Etwas für ruhigere Zeiten - da müssen Register in festgelegten Reihenfolgen gelesen werden und/oder änderen sich nach dem Lesen oder ... mit zweimal Datenblatt überfliegen ist es nicht getan.
      Daher RESPEKT an die dies können.
    • Das hast du aber sicherlich auch nur im Simulator ausprobiert.
      In HW wird das nicht gehen, weil du den Inhalt des UDR Registers, der den letzten Aufruf ausgelöst hat, nicht mehr zu sehen bekommst, wenn der eigentliche URXC Interrupt das Register gelesen hat.

      Ich wüsste außer UDR übrigens kein einziges Register, welches du lesen müsstest, geschweige denn in einer bestimmten Reihenfolge. Und das UDR liest du ja hier auch schon.
    • Das Konzept ist mit Stand jetzt suboptimal, denn Du bekämpfst die Folgen und nicht die Ursache.

      Belasse den Empfang in den Puffer per Interrupt-Routine und kümmere Dich in der Mainloop um eine priorisierte Verarbeitung. Die Verarbeitung des seriellen Puffers kannst Du auch per Hardware steuern, denn dazu gibt es ja CTS/RTS.
      Das Löschen des Puffers kannst Du Dir sparen, wenn Du die Puffrlänge sauber mitführst (nach dem Auslesen der Zeichen entsprechend anpassen - das macht ja BASCOM implizit auch).
      Aus datenschutzrechtlichen Gründen befindet sich die Kontaktdaten auf der Rückseite dieses Beitrages.
    • Richtig - war nix. Er sand es um eins verzögert zurück und verstand auch nix mehr. So:


      BASCOM-Quellcode

      1. $baud = 9600
      2. Dim Inbuf(20) As Byte
      3. Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8
      4. On Urxc Rx_rdy
      5. Enable Urxc 'set RXCIE
      6. .
      7. Rx_rdy:
      8. U = Udr
      9. If Ring = 1 Then Print Chr(u);
      10. Inbuf(ein) = U
      11. Incr Ein
      12. If U = 13 Then
      13. Neu = 1
      14. Else
      15. If Ein >= 19 Then Ein = 0
      16. End If
      17. Return
      Alles anzeigen



      gehts. Ich hab zum Versuch mal ca 6k sinnlosen Text hingesand und er kam vollständig zurück ohne die Hauptroutine zu stören.