| Ich nutze: C-Control II Unit, C164CI-ControllerBoard, CC2-Application-Board, CC2-StarterBoard, CC2-ReglerBoard, OSOPT V3.0, OSOPT V3.1 |
> Gemeinsame Ressource = CPU-Zeit? Könnte es sein, dass der der FIFO des UART oder was auch immer die
> Schnittstelle bedient, einfach überläuft, während die CPU gerade einen anderen Thread bedient?
Mit gemeinsamer Ressource meinte ich z.B. eher Variablen.
Aber ja, das kann auch passieren. Darum sollte der FIFO für die Anwendung ggf. immer
ausreichend groÃ? dimensioniert werden.
Wenn die standardmä�igen 32Byte nicht reichen, mu� man eben mit setbuf() den FIFO vergrö�ern.
> Ich glaube auch, dass es nicht der eine Thread von rbports ist, sondern irgendein Thread. Der rbports.main tut keine
> besonders aufwändigen Dinge, und ich habe noch einen zweiten Thread (der die Tastatur abfragt). Doch das Anhalten
> des rbports.main hat die Sache viel stabiler gemacht, und das ist schlicht eine Beobachtung. �brigens läuft noch immer
> ein Anwendungsthread im Hintergrund, und das erklärt auch, warum es einmal noch zu einem fehlenden Byte kam,
> trotz der Deaktivierung von rbports.main.
>
> Worauf ich aufmerksam machen wollte, ist, dass man sich mit dem Einbinden eines Moduls einen aktiven Thread
> "einhandelt", von dem man zunächst gar nichts wei�. Das sollte man beim Debugging beachten.
Der Main-Thread in rbports.c2 wird wahrscheinlich bald verschwinden, und durch
entsprechende Funktionen ersetzt.
Die Idee war einmal bei in Kaskade geschalteten Schieberegistern den Schaltzustand sicherzustellen,
da Schieberegister gerade bei nicht kurzem Kabel sehr leicht auf Störungen reagieren können.
Aber das Konzept Schieberegister-Porterweiterungen habe ich prinzipiell verworfen.
(Das war vor der gro�en "I²C-Bus-�ra" *grins*)
Der Aufbau von rbports.c2 ist daher noch ein Relikt von dieser Zeit. (Auch die Klemmen SH, ST und DS
beim ReglerBoard bis V1.2)
> Nein, ich nutze 9600 bps und sende einmal etwa 1KiB und dann nochmal 2KiB, beides mit hwcom.receive
> entgegengenommen. Vorher kommt jeweils ein Längenwort und ein CRC.
Gut, bei der Datenmenge können wir aber dennoch von einem �berlaufen des Puffers ausgehen.
Vergrö�ere einfach den Empfangspuffer auf 2kB:
byte fifo[2048];
...
hwcom.setbuf(fifo,2048);
> Ich hab' im �brigen einen CRC16 geschrieben und zu spüren bekommen, warum man so etwas tabellenbasiert und nicht
> bitbasiert tun sollte. Wenn du daran Interesse hast, melde dich.
Prinzipiell wäre das eine Aufgabe für etwas ASM.
Aber Deine Tabellenversion würde mich durchaus interessieren. ;-)
MfG André H.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
CRC16 (war Re: Stören Threads die serielle Übertragung?) (von Michael Zapf - 17.10.2007 15:12)Re: CRC16 (war Re: Stören Threads die serielle Übertragung?) (von Michael Zapf - 17.10.2007 15:16)