USART Übertragung innerhalb Byte abbrechen

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

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.

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

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

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

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

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

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

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

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.