Hallo allerseits, ich stell mich vermutlich nur etwas zu blöd, aber ich bekomm das mit einem XMega irgendwie nicht hin: Ich würde gern das schreiben eines Bytes über die USART-Schnittstelle noch innerhalb des Bytes das schon im TX-Puffer liegt abbrechen. Also zB. nachdem die ersten 3 Bits geschrieben wurden soll abgebrochen werden. Hat dazu evtl. jemand eine Idee? Gruß Sepp
:
Verschoben durch Moderator
hab ich auch schon überlegt, aber dann würd ichs lieber noch in Hardware umstricken und einen anderen Pin als TX-Enable verwenden. Hätte nur gehofft, dass das schonmal jemand gemacht hat... Gruß Sepp
SeppR schrieb: > hab ich auch schon überlegt, aber dann würd ichs lieber noch in Hardware > umstricken und einen anderen Pin als TX-Enable verwenden. Hätte nur > gehofft, dass das schonmal jemand gemacht hat... Da das eine sehr ungewöhnliche Aufgabenstellung ist, stehen die Chancen eher schlecht. Warum sollte man ein laufendes Byte mitten in der Übertragung abwürgen und was sagt die Gegenstelle dazu? Solche 'Forderungen' tragen normalerweise den Geruch von "You ask for troubles" mit sich.
SeppR schrieb: > zB. nachdem die ersten 3 Bits geschrieben wurden soll abgebrochen > werden. Definiere "abgebrochen werden". Wer bricht was ab, wem ist es egal?
wieso nicht vorher bitmaske und die nachfolgende bits so machen das der ausgang nicht verändert wird. dürfte ja dem abbrechen gleichkommen oder muss der takt stimmen ?
Hardware-Gatter hinter die UART schalten, und per ausgangs-Pin toschalten. Über Sinn oder Unsinn musst du dir selber klar werden. Oliver
würde mich auch sehr überraschen wenn das ohne externe hardware möglich wäre, normale Menschen wollen eben nicht das ihre uart-übertragung abbricht nur weil sie den Uart disablen oder die clocksource ändern. Jeder normale Anwender würde zumindest hoffen das die Übertragung noch zuende geführt würde.
Tastkopf schrieb: > Jeder normale Anwender würde zumindest hoffen das die Übertragung noch > zuende geführt würde. Nur gut dass du weisst, was normale Anwender wollen. Ohne weitere Infos vom TO ist das hier alles ziemlich sinnlos. 1) Wer bricht ab? Eine Seite, oder beide? 2) Was heisst abbrechen? Das Stop-Bit verhindern? Die Leitungen anderweitig nutzen? 3) Wie kommt so eine Anforderung zustande?
Grober Hintergrund: es geht um einen LIN-ähnlichen Bus, mit multimaster Funktionalität. Als Kollisionsvermeidung wird CSMA/CA zum Einsatz kommen. Einfacher: wenn ein schreibender Controller (µC1) einen dominanten Buspegel liest, der nicht von ihm stammt soll das Senden abgebrochen werden. Damit der Frame von dem anderen Controller (µC2) nicht komplett vor die Hunde geht soll also der µC1 das senden sofort einstellen und nicht noch das restliche Byte raustakten. Gruß Sepp
zeitnahe Abschaltung per Software!? LIN ist nicht sooo schnell, oder?
Genau beim Abschalten per Software liegt das Problem. USART disablen würd ich gern vermeiden, da dann ja auch das Byte von dem anderen µC nicht empfangen wird.
Du könntest vorzeitig das Stop Bit senden. Der Empfänger kann den Abbruch dann aber nicht erkennen. Der Empfang des Bytes dauert immer noch genau so lange, wie es vorgesehen ist und die fehlenden Bits werden mit "1" aufgefüllt (weil das Stop-Bit 1 ist). Nach dem Abbruch darfst Du nicht sofort das nächste Byte senden, denn der Empfänger erkennt das Start Bit erst, wenn der Empfang des vorherigen Bytes abgeschlossen ist (also die entsprechende Zeit abgelaufen ist). Andererseits könntes Du selbst auf das Senden des Stop-Bits verzichten. Dann bestimmt der Zufall, mit welchem Wert der Empfänger die fehlenden Bits auffüllt bzw. einen Framing Fehler (Stop-Bit hat falschen Wert) meldet. Das ist wohl nicht so gut. Den Framing Fehler kannst Du natürlich auch gezielt auslösen, beispielsweise indem Du den seriellen Port deaktivierst und den TxD Pin "manuell" auf Low setzt. Der Empfänger wird dann eine Weile auf das Stop Bit warten, da es aber nicht kommt, einen Framing Fehler melden und das letzte Byte verwerfen.
Wenn Du den ganzen UART nicht disablen willst, dann disable nur die TxD Leitung mit Hilfe eines externen UND Gatters.
Das ganze in Hardware umzubasteln haben wir auch schon überlegt. Wenn uns nichts anderes mehr einfällt wirds wohl auch so kommen. Gruß Sepp
und was soll die gegenseite mit einem "nicht komplett vor die hunde gegangen" frame anfangen? ein nur "halb vor die hunde gegangenes" frame bringt ihr ja auch nix. csma/ca haben schon andere implementiert...eine übertragung mitten im byte abzubrechen ist dafür nicht nötig. dafür gibts ja den timeout...
Kann man nicht während die Übertragung noch läuft die uC-Pins als Eingänge schalten, dann dürfte der UART auch kein Stop-Bit mehr senden!? Ich glaube schon, dass man die Übertragung entsprechend abbrechen kann. Allerdings, wann/wie willst du prüfen, ob gerade ein anderer uC auf den Leitungen sendet? Damit die laufende Kommunikation nicht gestört wird, sollte dein uC VOR dem Senden prüfen, ob der Bus frei ist. Wenn man das so hindreht, braucht man das Abbrechen aus meiner Sicht gar nicht.
Entschuldigung, aber ich bin schon etwas ... blind (hätte ich - wie das meiste - schonfrüher schreiben sollen): es gibt mehrere Teilnehmer am Bus, nicht nur 2. Wenn eine Kollision auftritt heißt das ja nur, dass 2 Controller gleichzeitig senden wollen, und wenn der "klügere" der beiden rechtzeitig nachgibt wird der Frame vom anderen Controller korrekt übertragen. Sepp
SeppR schrieb: > wenn ein schreibender Controller (µC1) einen > dominanten Buspegel liest, der nicht von ihm stammt soll das Senden > abgebrochen werden. Dann nimm doch einfach CAN. Dann wird auch die Software viel einfacher, weil der CAN-Controller schon alles selber macht. Peter
CAN - leider nicht möglich (ausserdem viel zu teuer). Der Bus ist vorgegeben. Für später werden wir uns noch nach anderen Controllern umsehen und falls uns nichts anderes mehr einfällt wirds eben für das Testboard eine Hardwarelösung werden. Sepp
Hallo, BMW hat so einen Bus im Einsatz der nennt sich IBUS oder auch KBUS, das braucht aber ein spezielles IC soweit ich mich erinnere. und die Übertragungsgeschwindigkeit ist max. 9600 Baud. Von daher ist CAN schon sinnvoller mfg
SeppR schrieb: > Grober Hintergrund: es geht um einen LIN-ähnlichen Bus, mit multimaster > Funktionalität. Als Kollisionsvermeidung wird CSMA/CA zum Einsatz > kommen. Einfacher: wenn ein schreibender Controller (µC1) einen > dominanten Buspegel liest, der nicht von ihm stammt soll das Senden > abgebrochen werden. Damit der Frame von dem anderen Controller (µC2) > nicht komplett vor die Hunde geht soll also der µC1 das senden sofort > einstellen und nicht noch das restliche Byte raustakten. Falls die Hardware das erlaubt, könntest Du im Senderegister die restlichen Bits des teilweise ausgesendeten Bytes auf den rezessiven Wert setzen, so daß das Byte zwar zu Ende gesendet wird, aber keine Störungen auf dem Bus mehr verursachen kann. Wie machst Du eigentlich die Kollissionserkennung? Falls in Hardware, liefert sie Dir doch eigentlich schon das Signal, das Du zum hardwaremäßigen Sperren der Tx-Leitung brauchst. Falls in Software, dürftest Du damit schon relativ nahe an einem Soft-UART sein, so daß Du von da aus auch gleich das Senden übernehmen könntest.
Hallo Das Überschreiben des TX-Registers geht nicht solange noch ein Byte aus dem Schieberegister getaktet wird. Das wird im XMega über das DREIF Bit verhindert. CAN ist wie geschrieben für diese Anwendung nicht möglich (Bus ist gegeben bzw. Kompatibilität muss sichergestellt sein. Ein sauberes CAN Interface wäre deutlich teuerer als ein LIN-Transceiver). IBus: kannte ich noch nicht, liest sich aber auf den ersten Blick sehr ähnlich. Da werden auch LIN-Transceiver als Bus-Interface verwendet. Bei uns ist die Übertragungsrate allerdings auf 19200 (LIN-üblich) festgelegt. Was ich bisher nicht rauslesen konnte, ob IBus Multimaster ist. Gruß Sepp
Es gab mal eine Hardware-UART, die diesen bizarren Designfehler umgesetzt hat -- und bei der deswegen das prinzipiell mögliche Hardwarehandshake nicht genutzt werden konnte. Das war die 6551, eine aufgrund des für damalige Verhältnisse recht flexiblen Baudratengenerators eigentlich sehr attraktive UART, nur mit kaputtem Hardwarehandshake (eben dem sofortigen Kappen der Übertragung mitten im gerade gesendeten Byte).
Hallo, IBUS, KBUS: sind Multimasterfähig. Deshalb werden spezielle Schnittstellen IC eingesetzt, welche die Übertragung bei Kollision automatisch kappen. LIN: ist ganz klar ein Single Master System, daher braucht es bei LIN auch kein kappen der Übertragung. Die Kollisionen die es geben kann sind nur bei der Event Abfrage. Dort wird ein zerstörtes Telegramm aber auch nur erkannt und die Slaves dann einzeln abgefragt. LIN wurde konstruiert um den teuren CAN Bus bei einfachen Sensoren / Aktuatoren zu ersetzen. mfg
D. F. schrieb: > IBUS, KBUS: sind Multimasterfähig. Deshalb werden spezielle > Schnittstellen IC eingesetzt, welche die Übertragung bei Kollision > automatisch kappen. Sehe ich auch so, Du brauchst spezielle ICs. Oder Du machst die UART komplett in SW mit Output-Compare und Input-Capture. Sehe grad, Du nimmst XMega. Da hat Atmel ja richtig tief gepennt, die ohne CAN zu machen. CAN hat doch heutzutage jeder moderne MC, oft sogar 2..4-fach. Daß CAN teurer ist, als andere Lösungen, war vielleicht früher mal so. Zum CAN-MC braucht man nur noch den Transceiver (Reichelt MCP2551: 0,98€). Peter
Kan asta schrieb: > Tastkopf schrieb: >> Jeder normale Anwender würde zumindest hoffen das die Übertragung noch >> zuende geführt würde. > > Nur gut dass du weisst, was normale Anwender wollen. find ich auch gut das ich sowas weis, macht mein Leben viel einfacher
SeppR schrieb: > Für später werden wir uns noch nach anderen Controllern umsehen und falls > uns nichts anderes mehr einfällt wirds eben für das Testboard eine > Hardwarelösung werden. Dann vergesse nicht den STM32Fxxx an zu schauen. Damit hätte man gleich mehrere Möglichkeiten den UART während der Übertragung still zu legen: - Peripherie Clock für den einen UART wegnehmen - den einen UART Reseten - oder den Pin als Output ohne Funktion umkonfigurieren Werfe gleich mal ein Blick in den Artikel STM32
Und wie will ein stm bitgenau eine kollision überhaupt erkennen? Die Vorschläge den Port Pin umzukonfigurieren sollten. Ei jedem uc gehen. Das abschalten des Taktes lässt mit hoher Wahrscheinlichkeit den Pegel am Portion stehen, was ganz daneben wäre. Meines Erachtens wollt da nur jemand Werbung für einen kontroller machen hat aber die problematik de TE nicht verstanden
Umkonfigurieren vom Port/Pin hab ich noch nicht versucht, da ich vom DB von was von ...Override im Kopf hatte. Genauer steht da: When the transmitter has been enabled, the normal port operation of the TxD pin is overridden by the USART and given the function as the transmitter's serial output. The direction of the pin must be set as output using the direction register for the corresponding port. Der letzte Satz könnte aber auch bedeuten, dass man den Pin während des Sendens als Eingang umkonfigurieren könnte. Das würde ja schon reichen. Werd ich mal versuchen. Danke schonmal, mal sehen obs klappt. Gruß Sepp
Karl Heinz Buchegger schrieb: > Warum sollte man ein laufendes Byte mitten in der > Übertragung abwürgen und was sagt die Gegenstelle dazu? CAN fordert das sogar ;-)
@Peter: CAN ist eine feine Sache, macht aber nur Sinn bei Geräten die es auch brauchen. Bei kleinen Sensoren oder Aktoren im Automobilbereich wirst du kaum einen CAN antreffen, weil einfach zu teuer. Du darfst nicht nur den Transceiver sehen. Drumherum ist noch einiges, wie die aufwendigere Hardware, zusätzlicher Pin am Gerät / Kabelbaum, Implementierungsaufwand,... Daher wird bei neueren Systemen (kleine (billige) Sensoren/Aktoren) auf andere Schnittstellen zur Signalübertragung, wie SENT(unidirektional) oder PSI5 gesetzt. Ist in unserem Fall aber relativ egal, da die Schnittstelle gegeben ist. Gruß Sepp
... schrieb: > CAN fordert das sogar ;-) Bei CAN werden aber auch alle Empfänger bei jeder Flanke und nicht nur beim Startbit auf dem Bus neu synchronisiert. Bei einem UART bei dem bloß in der Bit-Mitte (manchmal auch bis zu dreifach) abgetastet wird sehe ich das Problem daß eine Kollision nicht immer sicher erkannt werden kann wenn die Baudraten leicht differieren. Gruß Anja
Angehängte Dateien:
-
TXD_Override.png
4,9 KB
Das Verfahren, das auch der BMW IBus (I-Bus) benutzt, ist CSMA/CR (http://de.wikipedia.org/wiki/Carrier_Sense_Multiple_Access/Collision_Resolution). Hierfür kann man folgenden Lösungsansatz verwenden, falls man keinen speziellen Transceiver-IC einsetzen kann/möchte: 1. Das Senden über den HW-USART lässt sich von Software-Seite ja nicht mitten im Frame abbrechen. Dafür kann man aber mit minimalem HW-Aufwand (1 I/O-Pin + 1 Widerstand) eine "Override" Leitung bauen, s. Anhang. Im Normalbetrieb wird der Override-Pin auf Tri-State (Input ohne Pull-Up) gestellt. Wird eine Kollision erkannt, wird der Pin auf Output + High gelegt und "überschreibt" damit ggf. folgende dominante Bits, die über den TXD-Pin kommen. 2. Zur Kollisionserkennung kann man einen Pin-Change-Interrupt benutzen, den man auf die über RXD empfangenen Daten lauschen lässt. Wird durch diesen Interrupt eine fallende Flanke (= Beginn dominantes Bit) auf der RXD-Leitung detektiert UND der TXD-Pin liegt gleichzeitig auf High (rezessiv) UND es ist gerade eine ausgehende Übertragung vom µC aktiv, so ist eine Kollision aufgetreten und erkannt. In diesem Fall ist sofort das Senden zu unterbrechen (-> TXD-Override, s.o.) und erst nach einiger Zeit erneut zu versuchen. Für diesen Ansatz braucht der Pin-Change-Interrupt "nur" während des Sendens durch den µC aktiv zu sein, kann in dieser Zeit aber (bei 9600 Bit/s) mit max. 4800hz ausgelöst werden, was je nach Anwendung ggf. nicht tolerabel 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.