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 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".
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.
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.
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.
