Hallo zusammen! Nach einigem hin und her ist nun in etwa klar, wie das Projekt für meine Diplomarbeit aussieht. An einer Sache hänge ich zur Zeit gedanklich. Ich muss ein serielles Signal (von einem Feldbus abgewandelt) lesen und schreiben. Dabei muss ich ein break field genrieren und auch abfangen können. Nun ist diese break field leider nicht UART konform. Die Spannung wird nämlich auf 0 gezogen für mindestens 14 bits. Danach gibts dann konforme Zeichen (sync mit 0x55 = 1010101). Ich denke, daß man das am günstigsten mit nem Software UART hinter dem eigentlichen UART realisieren kann. Wobei der HW - UART einfach nur die Bits puffert und weiterschiebt. Eine andere Variante wäre es noch (das würede aber sehr kompliziert ausfallen) das Ganze über einen zusätzlich angeschlossenen ADC zu machen. Der wird sowieso angeschlossen, da es auch das physikalische Signal abgetastet werden soll. Das was ich nun wissen will: Sind meine Gedankengänge da richtig? (habe nicht viel Erfahrung auf dem Gebit) und wenn ja: wie realisiere ich diesen Software UART? gibts da schon SW, die man quasi fertig runterladen kann und nutzen darf (Open Source). Bis jetzt habe ich da den genereic software UART von Colin Gittins bei IAR systems gefunden... Danke schonmal für Antworten! Grüße Florian
Was ist das Problem an "BREAK"? Das ist zwar ein gezielter Anschlag auf das serielle Datenformat, aber schon ungefähr so alt wie die asynchrone Übertragung selber. Identifizierbar beispielsweise als Datenbyte 00 mit Framing Error.
hmmmm... dann wäre doch aber die Spannung auf der TX Leitung konstant 5 und nicht 0 Volt, oder kann der Befehl speziell genutzt werden? ausserdem könnte ich den lediglisch schreibend nutzen...ich könnte kein break Signal von 14 Byte länge erkennen, wenn es gesendet wird...
Wenn es wichtig ist, genau 14 Bits zu erkennen: Rx nicht nur an den UART-Pin vom Controller sondern auch an einen Timer-Pin anschliessen. Und wenn die UART des SAM7 selber kein BREAK senden kann: Den Tx-Pin des Transceivers/Pegelwanders per AND- oder Diodengatter zusätzlich an einen normalen IO-Pin anschliessen.
Sagen wir es ist tatsächlich essenziell... Nun ist das alles natürlich recht viel gebastel..vor allem in der Software, weil das Timing für das Break-Signal sehr genau stimmen muss..ausserdem ist das ja ein MINIMUM von 14 Bytes und ist laut Spezifikation realtiv offen... Wäre es nicht tatsächlich einfacher dann gleich den UART Softwareseitig zu realisieren? ich habe ja nur die RX und die TX Leitung und kaum irgendwelche speziellen Checksummen oder dergleichen... Ich denke ich hätte weniger Ärger...ich bin mir eben nur nicht sicher, ob meine Gedankengänge korrekt sind
Soft-UART ist hardwareseitig einfacher, softwareseitig komplizierter. Wenn dieser Feldbus wie üblich half duplex arbeitet geht's per Soft freilich ganz gut. Aber such es dir aus.
yep..das machter...es gibt immer noch einen der sendet und jede Sendung muss vom Master Node initiiert werden... Ich wüsste halt nicht, wie ich das Ganze timen soll, wenn ich z.B. einen IO an einen kleinen Schalter hängen würde und quasi als pull-down-enable nutzen würde. Man muss es ja genau so einstellen, daß der UART dann das sync byte (0x55) empfangen kann und so lange die metaphorischen Füße still hält. Beim empfangen könnte man den sowieso schon angeschlossenen ADC nutzen...oder wäre das auch zu kompliziert? Ich habe leider einfach zu wenig Erfahrung bei solchen Dingen und versuche mir das mit meinem bisherigen Wissen herzuleiten. Nur will ich nicht den falschen Weg einschlagen und hinterher beim Schreiben der Diplomarbeit in größere Zeitbedrängnis geraten...
"Der wird sowieso angeschlossen, da es auch das physikalische Signal abgetastet werden soll." wobei mir gerade auffällt, daß das Ding vor dem Interface angeschlossen wird...also hat sich die Sache sowieso...
Ein kurzer Blick ins Datasheet vom SAM7SE zeigt, dass dessen UART explizit BREAK senden und erkennen kann. Und das Timing vom BREAK-Status erfassbar ist. Was also soll der Zirkus???
@a.k.: das der at91sam7s breaks senden und empfangen kann stimmt, allerdings kann das break nur 11 bits lang werden und florian braucht aber 14 bits. wobei ich mir ja nicht vorstellen kann, welch "kranker" feldbus mit 14 bits langem break arbeitet. aber vielleicht verrät es es uns ja noch. gruss gerhard
Sorry, ich les das anders. Der kann Break beliebig lang generieren. Nur nicht exakt 14 Bitzyklen. Aber oben wird auch nur mindestens 14 verlangt.
@a.k.: du hast recht, ich habe sowohl das datasheet als auch die anforderungen nicht genau genug gelesen. damit sollte das ganze eigentlich ohne probleme funktionieren gruss gerhard
Wie schon gesagt...ich versuch hier mein Bestes, um das hinzubekommen und hab da wohl was übersehen... der kranke Feldbus ist der LIN-Bus..
hallo florian, einer der vorteile von lin ist, daß mit einem standard-uart das auslangen findet. unte der unter http://www.atmel.com/products/AVR/auto/ findest du eine app. note inkl. source code für einen lin master/slave aus basis avr. da kannst du dir mal ansehenm wie das synch break mit einem standard uart erzeugt werden kann. gruss gerhard
holla..hab gut zu tun den Code zu verstehen..ist nicht so ganz einfach... :)
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.