Autor |
RS232 buffern ca. 20Byte mit einem IC? |
|
|
|
|
BID = 494960
Grimm Stammposter
Beiträge: 494 Wohnort: Bayern
|
|
Hallo,
habe folgendes Problem.
Im Puffer am Controller (RS232) werden mur 8BYTE gespeichert der Rest geht verloren beim Datenempfang.
Es werden nur alle 2 bis 3 Stunden ca. 20 BYTE gesendet.
Meine Frage:
Gibt es ein IC, in den man RS232 buffern kann und später die einzelnen BYTE auslesen kann.
Das Auslesen muss nicht unbedingt mit RS232 erfolge kann auch z.B mit I2C-Bus oder mit 8 Digitalausgängen erfolgen.
Es sollte möglich sein, ein BYTE nach dem anderen aus dem Buffer auszulesen. Zwischen den z.B. 2 BYTE und 3BYTE müsste eine Pause möglich sein u.s.w..
Gruß Dieter
PS:
Oder könnte man mit Echo den Datenstrom an der RS232 nach dem ersten BYTE stoben.
Das erste BYTE im Controller verarbeiten und dann das nächste BYTE an den Controller senden lassen.
|
|
BID = 495001
perl Ehrenmitglied
Beiträge: 11110,1 Wohnort: Rheinbach
|
|
Zitat :
| Oder könnte man mit Echo den Datenstrom an der RS232 nach dem ersten BYTE stoben. | Das kommt darauf an wieviele Leitungen der Schnittstelle du zur Verfügung hast und wie das sendende Gerät programmiert ist.
Normalerweise sind die Handshake-Leitungen Request-To-Send (RTS) und Clear-To-Send (CTS) dafür gedacht, um den Datenverkehr punktgenau zu stoppen.
Ich habe es aber auch schon erlebt dass die Daten mittels DMA abgeschickt wurden und wenn das erstmal angefangen hatte, der ganze Datenblock von bis zu 256 Bytes übertragen wurde.
Bei richtig langen Datenfernverbindungen kann auch noch viel in der Pipeline stecken, selbst wenn der Sender sofort aufhört.
P.S.:
Um deine Eungangsfrage zu beantworten:
Natürlich kannman einen kleinen Mikrocontroller so programmieren, dass er als Datenpuffer wirkt. Als reine Hardwarelösung wird das etwas schwieriger, weil es die entsprechenden UARTs nur noch antiquarisch gibt.
[ Diese Nachricht wurde geändert von: perl am 27 Jan 2008 14:24 ] |
|
BID = 495027
DonComi Inventar
Beiträge: 8605 Wohnort: Amerika
|
Moin,
wie perl sagte, entweder Hardwarehandschake benutzen, das ist recht datensicher.
Wenn das nicht möglich ist, dann muss man sich das Softwarehandshake Xon/Xoff anschauen, das geht aber nur, wenn die beiden dafür verwendeten Wörter (eben die Bytes Xon und Xoff ) nicht im sonstigen Datenstrom vorhanden sind. Das geht z.B. in den meisten Fällen dann, wenn es sich um reine ASCII-Zeichen handelt (ok, und die paar Steuerzeichen, die man für ein Terminal eben benötigt).
Wenn es sich um rein binäre Daten handelt, also alle 256 Bytes im Datenstrom vorhanden sind, ist das schlecht.
Da programmiert man, wenn man damit rechnen muss, dass der Empfänger die Daten nicht schnell genug verarbeiten kann, dann einen Puffer, der beispielsweise im mikrokontrollereigenem RAM liegt.
Kommen Daten an, wird in der ISR nur das Byte abgeholt, in einen bestimmten Bereich im RAM kopiert und ein bestimmter Zeiger auf die nächste Position gesetzt. Weiterhin wird eine Flagge gesetzt, die dann im Hauptprogramm darauf hinweißt, dass Daten im Empfangspuffer liegen.
Hat dein µC zuwenig RAM oder du willst sehr viel puffern, dann nimmst du einfach einen kleinen SRAM-Baustein, die du aus älteren Mainboards ausbauen kannst, und fütterst den mit den Daten.
Du musst dabei nur aufpassen, dass die Zeigerarithmetik funktioniert und dass es keine Pufferüberläufe gibt.
_________________
|
BID = 495037
perl Ehrenmitglied
Beiträge: 11110,1 Wohnort: Rheinbach
|
@DonComi: Man kann auch mit Softwarehandshake alle Bytes übertragen, einschliesslich XON, XOFF, NUL, ESC und DLE. Dafür wurden ja die Modemprotokolle geschaffen.
Vielleicht bekommt Grimm sein Problem ja schon in den Griff, wenn er nur die vorhandenen Leitungen auch benutzt.
_________________
Haftungsausschluß:
Bei obigem Beitrag handelt es sich um meine private Meinung.
Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.
Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !
|
BID = 495060
Grimm Stammposter
Beiträge: 494 Wohnort: Bayern
|
Hallo Jungs,
Die Pufferung der RS232 wird für meine allseits gefürchtete Handyüberwachung benötigt.
Die vorhandenen Leitungen zum Handy sind RX, TX und GND.
Eine IC - Lösung ist wahrscheinlich nicht so einfach. Ich dachte so an Schieberegister oder so was.
Ist das Einstellen des Echos (ATE1) am Handy so zu verstehen, dass ein Byte gesendet wird und auf das Zurücksenden wartet, bis das Byte vom Controller zurückgesendet wird.
Anschließend wird das nächste Byte an den Controller gesendet, Echo zurück ans Handy u.s.w..
Oder sendet das Handy bei Echo alle Byte an den Controller und dann werden alle Zeichen zurückgesendet.
Gruß
|
BID = 495165
faustian.spirit Schreibmaschine
Beiträge: 1388 Wohnort: Dortmund
|
"weil es die entsprechenden UARTs nur noch antiquarisch gibt."
16550A?
|
BID = 495169
perl Ehrenmitglied
Beiträge: 11110,1 Wohnort: Rheinbach
|
Auch den kannst du vernünftig nur programmgesteuert benutzen um z.B. an das Statusregister zu kommen.
Früher gabs mal einfache UARTs, ohne Baudrategenerator, im 40-poligen Gehäuse bei denen alle Bits parallel rauskamen.
_________________
Haftungsausschluß:
Bei obigem Beitrag handelt es sich um meine private Meinung.
Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.
Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !
|
BID = 495172
Jornbyte Moderator
Beiträge: 7178
|
Zitat :
| Gibt es ein IC, in den man RS232 buffern kann und später die einzelnen BYTE auslesen kann. |
Ja, sowas gibt es, jeder der kleinen µC egal ob Atmel oder PIC mit Ram und Uart kann so was.
_________________
mfg Jornbyte
Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.
|
BID = 495177
perl Ehrenmitglied
Beiträge: 11110,1 Wohnort: Rheinbach
|
Zitat :
| Die vorhandenen Leitungen zum Handy sind RX, TX und GND. |
Also kein Hardwarehandshake.
Vielleicht genügt es wenn du die Baudrate auf den geringstmöglichen Wert z.B. 300 einstellst, damit dein Controller nicht überfahren wird.
_________________
Haftungsausschluß:
Bei obigem Beitrag handelt es sich um meine private Meinung.
Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.
Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !
|