Hallo Jungens, ich hab da ein kleines Problem bei einem Projektchen. Dort werden nämlich serielle Daten eingelesen und auf Inhalt untersucht. Dummerweise ist der Sender manchmal sehr gesprächig, sodass es regelmäßig zu fehlerhaften Auswertungen kommt. Ringbuffer overflow. Ich kann dem Mega644 aber nicht mehr allzuviel Bufferplatz rausleihern. Weiß von Euch einer, ob es so etwas wie einen externen Puffer gibt? So in der 10kb Größenordnung... Danke schonmal für Eure Antworten. DF
@ DerFräger (Gast) >Dort werden nämlich serielle Daten eingelesen und auf Inhalt untersucht. >Dummerweise ist der Sender manchmal sehr gesprächig, Wie gesprächig? > sodass es >regelmäßig zu fehlerhaften Auswertungen kommt. Ringbuffer overflow. Shit happens. >Ich kann dem Mega644 aber nicht mehr allzuviel Bufferplatz rausleihern. Nimm einen AVR mit mehr SRAM. >Weiß von Euch einer, ob es so etwas wie einen externen Puffer gibt? >So in der 10kb Größenordnung... Sicher, bei Cypress und IDT, aber die willst du nicht wirklich nutzen, der Aufwand zur Ansteuerung übersteigt in diesem Fall den Nutzen um Größenordungen. Nimm einen größeren Controller oder ändere dein Protokoll (Handshake, Flußsteuerung) MFG Falk
Wenn der µC austauschbar ist, dann versuch es mal mit dem ATMEGA1284P. Der ist baugleich mit dem 644 und hat gleich 16kb SRAM anstatt 4kB.
>Weiß von Euch einer, ob es so etwas wie einen externen Puffer gibt? SRAM, MRAM, DRAM, SDRAM, FLASH, FIFO, DPRAM, CPLD, FPGA, (in uCs)
Wenn Dein µc das Einlesen und anschließende Puffern der Daten nicht mehr schafft, dann nimm entweder einen größeren µC oder spendiere einfach einen zweiten µC speziell für diese Aufgabe. Bei ähnlichen Anforderungen habe ich auch schon einige Schaltungen mit zwei µCs laufen, was relativ einfach zu realisieren war.
DerFräger schrieb: > Dort werden nämlich serielle Daten eingelesen und auf Inhalt untersucht. > ...Ringbuffer overflow. Warum dauert die Untersuchung so lang?
Leite doch die Daten in ein SPI RAM weiter, wenn der interne Ringbuffer voll ist. Dann kannst du die Daten später in aller Ruhe auslesen und verarbeiten.
Kommt eigentlich der gute alte Handshake immer mehr aus der Mode? Der ist genau für solche Sachen gedacht "Halt momentan bitte mal die Klappe, ich bin beschäftigt und komm nicht nach".
>Kommt eigentlich der gute alte Handshake immer mehr aus der Mode?
Aus der Mode kommt der nicht. Aber oft ist keine Zeit dafür.
DerFräger schrieb: > Ringbuffer overflow. 1.Auch der größte Buffer läuft mal voll, wenn die Strategie nicht stimmt. Besteht keine Möglichkeit RECHTZEITIG zu prüfen, ob diese Daten überhaupt sinnvoll sind? 2.Sendet Deine Quelle zuviele Daten oder es werden auf der Leitung zu viele Störungen eingesammelt?
Ich glaube du bist 40 Jahre zu spät dran: MM5034 Heute macht man das einfach mit einem ausreichend grossen uC, oder, falls es rasend schnell sein muss, passend programmierten FPGA.
MCUA schrieb: >>Kommt eigentlich der gute alte Handshake immer mehr aus der Mode? > Aus der Mode kommt der nicht. Aber oft ist keine Zeit dafür. Bei einer Seriellen an der sowieso schon ein Ringbuffer drannhängt (der nur eben zu klein ist)? Füllgrad über 80% -> CTS setzen, Füllgrad unter 20% -> CTS löschen. Das braucht doch keine Zeit.
Ui Ui Ui Ui! Das ist ja eine Flut von Vorschlägen. Vielen Dank erstmal. Zwei finde ich besonders gut: ATMEGA1284P und ein zweiter Prozessor evt mit externem RAM. @Karlheinz: Das wäre zu schön, aber hier wird nur bei einem Protokoll zwischen zwei Seiten mitgehört. Ich kann nicht aktiv eingreifen. @All: Es kommen mehrere kb ASCII Daten mit 9600bd rein, die auch die zu suchenden Daten enthalten. Die Abfrage ist bereits schon ziemlich gut optimiert mit einer State Machine. Die Uart Lib ist die von P.Fleury - also auch verlässlich. MM5034 - niedlich aber unpraktisch, weil parallel und ohne Intelligenz. Oder vielleicht doch den gesamten Puffer in ein externes SPI RAM auslagern? Das dumme ist das Hardware Design ist bereits angeschlossen. Die Änderungen sollten daher leicht zu realisieren sein. Die SPI wäre noch frei für ein Piggyback Board ... Auf jeden Fall danke für die Eingebungen - muss mal sinnieren.
> Daten mit 9600bd rein
Das ist ja schnarchlangsam.
Such doch WÄHREND die Daten reinkommen.
Höffi schrieb: > Such doch WÄHREND die Daten reinkommen. Nur als Anregung: Bau eine State-Machine! Wenn die Begriffe bekann sind relativ trivial, ansonsten siehe Knuth-Morrison-Pratt.
Es läuft bereits eine State Machine, die die eingehenden Daten untersucht. Nur halt während des normalen Programmablaufs und nicht in der UART Interrupt Routine. Das wollte ich vermeiden, denn es gibt zwei weitere Uarts zu bedienen. Bei 6,95 für den AtMega1284P ist die Entscheidung für den ersten Test schonmal gefallen :-) Plug&Play :-)
Ich denke eher die Suchmaschine ist Schrott. Das wird sich ja zeigen, wenn die Loesung nichts taugt. Denn ein SPI RAM anzusteuert ist nicht gratis. Waehrend dem ihr das externe Ram adressiert haett ich meine Suche schon durch denk ich. Die Suche ist eine Binaersuche in einem Baum ? Falls nicht ... ist sie zu langsam. Wie lang sind den die Eintraege, die durchsucht werden muessen ?
Pico Oschi schrieb: > Waehrend dem ihr das externe Ram adressiert haett ich meine > Suche schon durch denk ich. Du darfst nicht vergessen, dass wir nur Dummbattel sind. Du hingegen bist ein Universalgenie, das sogar Probleme lösen kann, dies es gar nicht kennt.
DerFräger schrieb: > Es läuft bereits eine State Machine In Zahlen 1. Schulterklopf, schulterklopf... ;-) Nur mal so ein Einwurf aus der Hardwareecke (FPGA): Eine (in Zahlen: 1) FSM ist keine (in Zahlen: 0) FSM. Erst ab 4 verschachtelten FSM wird das Design interessant. Wobei ich der Ehrlichkeit halber zugeben muss, das schon ein Zähler eine FSM ist... ;-) > Die Abfrage ist bereits schon ziemlich gut optimiert mit einer State > Machine. Was hast du da so Wichtiges zu untersuchen, dass das 10 Sekunden lang dauern könnte? Ich berechne mir diese Zeit überschlägig aus den Angaben > So in der 10kb Größenordnung... und > Daten mit 9600bd rein weil 10000 * 1ms = 10s, und weil du angeblich keine Zeit hast, das online beim Empfang zu machen... Wo wird da die ganze Rechenleistung verbraten? Denn immerhin kann der uC mit 8MHz in dieser Zeit ca. 80Millionen Operationen ausführen, von denen die allerwenigsten zur Pufferverwaltung benötigt werden.... :-o
DerFräger schrieb: > Nur halt während des normalen Programmablaufs und nicht in der UART > Interrupt Routine. Das wollte ich vermeiden, denn es gibt zwei weitere > Uarts zu bedienen. Na und? Dein Controller läuft doch hoffentlich mit 16-20MHz, dann hat er genug (Echt-)Zeit. Natürlich mußt Du vor der 'Suche' den globalen Interrupt wieder freigeben.
Poste mal Dein Programm dann wirst Du ... ääääh ich meine Dein Programm hier sicher fachgerecht auseinandergenommen :->
> Denn immerhin kann der uC mit 8MHz in dieser Zeit ca. 80Millionen > Operationen ausführen ... Das glaube ich nicht.
Heinz schrieb: >> Denn immerhin kann der uC mit 8MHz in dieser Zeit ca. 80Millionen >> Operationen ausführen ... > > Das glaube ich nicht. EDIT: Habe mich verlesen :)
@Heinz (Gast) >> Denn immerhin kann der uC mit 8MHz in dieser Zeit ca. 80Millionen >> Operationen ausführen ... Das glaube ich nicht. Ich schon. 80e6 mal NOP ;-)
Die Suche macht man natuerlich in Echtzeit, dh waehrend die Bytes kommen, nicht nachher. Bei 9600Baud kommen ca 1000 byte pro sekunde. Bei 8MHz clock macht das demnach 8000 Befehle, die pro byte zur Suche zur Verfuegungs stehen. Das sollte reichen fuer einen Binaerbaum und noch etwas drauf.
Pico Oschi schrieb: > Das sollte reichen fuer einen Binaerbaum und noch > etwas drauf. Hmm, zeig mir mal wie du einen Binärbaum für Streamdaten machst. Und zwar auf einem µC mit wenig RAM.
Udo Schmitt schrieb: > zeig mir mal wie du einen Binärbaum für Streamdaten machst. Ja, wenn man nur wüsste, was da eigentlich mit diesen Daten gemacht werden soll bzw. gemacht wird. Man muss ja nicht immer gleich vom Schlimmsten ausgehen.... ;-)
Lothar Miller schrieb: > Ja, wenn man nur wüsste, was da eigentlich mit diesen Daten gemacht > werden soll bzw. gemacht wird. Man muss ja nicht immer gleich vom > Schlimmsten ausgehen.... ;-) Hallo Lothar, Hat der TO doch gesagt: DerFräger schrieb: > @Karlheinz: > Das wäre zu schön, aber hier wird nur bei einem Protokoll zwischen zwei > Seiten mitgehört. Ich kann nicht aktiv eingreifen. Das heisst er parst einen kontinuierlichen Datenstrom mit. Allerdings sollte es mit einem geeignetem Algorithmus trotzdem möglich sein auf ein Dutzend Schlüsselworte in Echtzeit zu prüfen. Er hat ja 5000 - 7000 Takte pro neuem Zeichen. Aber binäre Suche oder gar binärer Baum sehe ich da irgendwie nicht als Lösung, lass mich aber gerne hier belehren. Gruß, Udo
>Aber binäre Suche oder gar binärer Baum sehe ich da irgendwie nicht als >Lösung, lass mich aber gerne hier belehren. WENN man z.B. Säcke von überflüssigen Nullen schon mal aussieben könnte, würde das die Datenmenge wesentlich reduzieren. Da ich aber Deine Daten nicht kenne, halte ich mich mit überflüssigen Ratschlägen jetzt zurück.
oszi40 schrieb: > Da ich aber Deine Daten > nicht kenne, halte ich mich mit überflüssigen Ratschlägen jetzt zurück. Sind nicht meine Daten, sondern die vom TO, aber der hat dazu nichts rausgerückt.
Es gibt immer noch Dual-ported-RAM http://www.cypress.com/?id=82 die haben Warnausgänge für "fast voll" oder "fast leer" und Hardware-Handshake über sogenannte Semaphore, die werden von der einen Seite gesetzt und der anderen rückgesetzt.
Grundsätzlich jedoch durfte sich der Erkennung als simple FSM herausstellen, bei der jeder Eingang eine Transition auslöst. Dabei sind 3 Aufgaben zu lösen. Die Auswahl der Transition, das Setzen des neuen Zustands und die Überprüfung ob ein Akzeptanzzustand erreicht wurde. Also eine Suche, ein Vergleich und eine Zuweisung. Das sollte in den zu Verfügung stehenden Takten erledigt werden können. Der Aufwendige Punkt ist die Suche der Transition. Es kommt nun darauf an, in welcher Form dies geschieht. Wie schnell kann die richtige Transition gefunden werden? Suchalgorithmus? Fixe if-else oder geschachtelte switch codierung ersetzen? Eine RegEx Suche auf 9.6kBit sollte keine Probleme bereiten. Da sollte eher massive Langeweile auftreten.
Ich finde das Parsen im Interrupt viel zu kompliziert. Man muß sich ja nen Haufen merken bis zum nächsten Zeichen. Und damit geht wieder ein Haufen CPU-Zeit verloren, die Variablen zu sichern und wieder zu laden. Ich puffere nur im Interrupt und das Main parst. Man kann höchstens noch das Protokoll soweit analysieren, daß der Interrupt weiß, wann ein Paket zuende ist und dann ein Flag setzen. Wenn es z.B. ein Textprotokoll ist, prüft der Interrupt das Byte auf 0x0A oder 0x0D, ersetzt es durch 0x00 und setzt das Flag. Peter
So ein Binaerbaum kann recht effizient implementiert werden. Pro daten byte 2 pointer zu 16 bit. Natuerlich ohne dynamisches Memorymanagement. Dann muesste man noch wissen ob der Suchbaum konstant oder dynamisch ist.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.