Störsichere serielle Datenübertragung

F

Florian Hirschberg

Guest
Hallo NG,

Ich hab inzwischen die Ballwurfmaschine soweit zum laufen bekommen. Leider
funktioniert die Anzeige die die Reichweite des Schusses anzeigen soll nicht
richtig. Die Steuerung hängt sich bei der Übertragung der Daten zum Display
auf, da dort auch kein Timeout eingebaut ist.. Der Grund dafür sind wohl die
beiden großen 550W Permanentmagnetmotoren die ordentlich Störungen
verursachen. Zuhause auf dem Schreibtisch funktionierte das ganze nämlich
prächtig. Nun meine Frage:
Weiß jemand eine einfach zu realisierende serielle Datenübertragung die
einigermaßen Störsicher ist? Es sind nur etwa 1.5m - 2m zu überbrücken. Auf
der Displayplatine sitzt ein AT90S1200 der die beiden 7 Segmentanzeigen per
Multiplex ansteuert. In der Steuerung ist ein ATMega16. Leider ist die SPI
Schnittstelle beim Mega schon belegt, ich muss also Softwaremässig sowas in
der Art nachbilden. Hat jemand einen guten Tipp für mich? Bin echt am
Verzweifel. Die Maschine soll doch auch anzeigen wie weit der Ball in etwa
fliegt.

Vielen Dank nochmal für die bisherigen Anregungen zu meinen anderen Threads,
ich warte schon gespannt auf die nächsten.

Gruß,
Florian Hirschberg
 
Florian Hirschberg schrieb:

Hallo NG,

Ich hab inzwischen die Ballwurfmaschine soweit zum laufen bekommen. Leider
funktioniert die Anzeige die die Reichweite des Schusses anzeigen soll nicht
richtig. Die Steuerung hängt sich bei der Übertragung der Daten zum Display
auf, da dort auch kein Timeout eingebaut ist.. Der Grund dafür sind wohl die
beiden großen 550W Permanentmagnetmotoren die ordentlich Störungen
verursachen. Zuhause auf dem Schreibtisch funktionierte das ganze nämlich
prächtig. Nun meine Frage:
Weiß jemand eine einfach zu realisierende serielle Datenübertragung die
einigermaßen Störsicher ist? Es sind nur etwa 1.5m - 2m zu überbrücken. Auf
der Displayplatine sitzt ein AT90S1200 der die beiden 7 Segmentanzeigen per
Multiplex ansteuert. In der Steuerung ist ein ATMega16. Leider ist die SPI
Schnittstelle beim Mega schon belegt, ich muss also Softwaremässig sowas in
der Art nachbilden. Hat jemand einen guten Tipp für mich? Bin echt am
Verzweifel. Die Maschine soll doch auch anzeigen wie weit der Ball in etwa
fliegt.

Vielen Dank nochmal für die bisherigen Anregungen zu meinen anderen Threads,
ich warte schon gespannt auf die nächsten.
Click to expand...
Kein Grund zum Verzweifel ;-)

Serielle Datenübertragungsprotokolle gibt's wie Sand am Meer.

Gehe ich recht in der Annahme daß Du nur eine Übertragungsrichtung
brauchst (vom ATMega zum AT90S1200)? Dann würde ich ein asynchrones
Übertragungsprotokoll wählen. Der AT90S1200 müßte das softwaremäßig
ddecodieren. Bei Atmel gibt's dazu bestimmt eine application note. In
Deinem Fall würde ich entweder symmetrische Übertragung (z.B. RS422)
oder eine Stromschleife benutzen. Das sollte ausreichend störsicher
sein. Der ATMega hat eine USART-Schnittstelle, die das Signal per
Hardware erzeugen kann.

Wenn Du die übertragenen Daten per Prüfsumme oder CRC absicherst und die
Werte periodisch überträgst (anstatt nur einmal), dann kannst Du beim
Empfänger die Nachrichten mit falscher Prüfsumme einfach ignorieren.
Sobald eine Nachricht korrekt durchkommt stimmt die Anzeige wieder. Das
ist einfach und sehr robust.

Die Baudrate würde ich nach den Bedürfnissen des Empfängers bestimmen

--
Cheers
Stefan
 
Hallo Florian,

Weiß jemand eine einfach zu realisierende serielle Datenübertragung die
einigermaßen Störsicher ist? Es sind nur etwa 1.5m - 2m zu überbrücken. Auf
der Displayplatine sitzt ein AT90S1200 der die beiden 7 Segmentanzeigen per
Multiplex ansteuert.
Click to expand...
die einfachste Methode ist wahrscheinlich blockweise Datenübertragung
mit Prüfsumme und Softwarehandshake. Du erstellst also vor dem Senden
die Prüfsumme der Daten (aufaddieren kann schon reichen, CRC ist besser)
und das Display überprüft die empfangenen Daten anhand der Prüfsumme.
Dieser Block wird dann durch ein "OK" bestätigt, oder über ein "ERR"
noch einmal angefordert. Das Handshake kann man sich sparen, wenn man
die Übertragung ständig wiederholt und das Display nur die Daten
übernimmt, deren Prüfsumme stimmt.

Gruß,

Ed
 
Hallo Florian

RS232 mit ordentlicher Amplitude plus Hysterese im Empfaengerchip hat es fuer mich in solchen Faellen immer getan. Ein stoersicheres Protokoll wie es die anderen vorschlugen sollte es dann wirklich sicher machen.

Wichtig ist, die Stoerungen an der Wurzel zu packen. Wenn es Spitzen vom Motoranlauf sind, kann man viel mit Ringkernen machen. Andere Kernformen gehen auch, wenn es nur Ferrit ist. Das duenne serielle Kabel so oft es geht durch einen Ferritkern wickeln, als Ganzes. Am besten an beiden Seiten. 43er Material, oder auch 77er ist dafuer gut. Der Empfaenger sollte einen RC Tiefpass am Eingang haben, der bei etwa der doppelten Taktfrequenz abrollt.

Gruesse, Joerg

http://www.analogconsultants.com
 
Florian Hirschberg schrieb:

Weiß jemand eine einfach zu realisierende serielle Datenübertragung die
einigermaßen Störsicher ist? Es sind nur etwa 1.5m - 2m zu überbrücken. Auf
Click to expand...
Was hast Du denn bisher? TTL Pegel?

Nimm halt RS232, oder wenn's narrensicher sein soll RS422/485. Dafür
gibts billigste Transceiver ICs von Maxim & Co.

Für diese uC gibt es Software UARTs, die man mehr oder weniger an jedem
Portpin installieren kann. Für einfache Signalisierungen reicht das.

- Carsten

--
Audio Visual Systems fon: +49 (0)2234 601886
Carsten Kurz fax: +49 (0)2234 601887
Von-Werth-Straße 111 email: audiovisual@t-online.de
50259 Pulheim / Germany WGS84:N50°57'50.2" E06°47'28.5"
 
Hallo,

Kein Grund zum Verzweifel ;-)
Click to expand...
Das sagst du so, das soll ja mal wieder alles morgen laufen... Wie das eben
so ist.

Serielle Datenübertragungsprotokolle gibt's wie Sand am Meer.
Gehe ich recht in der Annahme daß Du nur eine Übertragungsrichtung
brauchst (vom ATMega zum AT90S1200)? Dann würde ich ein asynchrones
Übertragungsprotokoll wählen. Der AT90S1200 müßte das softwaremäßig
ddecodieren. Bei Atmel gibt's dazu bestimmt eine application note. In
Deinem Fall würde ich entweder symmetrische Übertragung (z.B. RS422)
oder eine Stromschleife benutzen. Das sollte ausreichend störsicher
sein. Der ATMega hat eine USART-Schnittstelle, die das Signal per
Hardware erzeugen kann.
Click to expand...
Das ist soweit richtig. Allerdings ist der USART schon belegt. Aber ein
Asynchrones Protokoll kann ich auch an beiden per Software implementieren.
Im Prinzip hab ich das ja auch schon. Ich habe 3 Signale genommen. 1 x Ack
um einen Übertragungsbeginn anzukündigen. Dann 1 x Data um die Daten zu
übertragen, und das Clock Signal, das der langsamere AT90S1200 erzeugt damit
der Mega nich zu schnell sendet. Die Ausgänge am Mega habe ich direkt zum
Display gelegt, und dort mit 470 Ohm gegen Masse gelegt. An dem Widerstand
hab ich dann die Signale in den AT90S1200 geführt. Die Clock Leitung dann in
der umgekehrten Richtung genau so. Das scheint aber nicht wirklich zu
funktionieren. Zumindest nicht bei laufender Maschine.

Wenn Du die übertragenen Daten per Prüfsumme oder CRC absicherst und die
Werte periodisch überträgst (anstatt nur einmal), dann kannst Du beim
Empfänger die Nachrichten mit falscher Prüfsumme einfach ignorieren.
Sobald eine Nachricht korrekt durchkommt stimmt die Anzeige wieder. Das
ist einfach und sehr robust.
Click to expand...
Das mit der Prüfsumme ist mir auch schon in den Sinn gekommen. Werd ich auf
jeden Fall mal probieren.

Mfg
Florian Hirschberg
 
Hallo,


Was hast Du denn bisher? TTL Pegel?
Click to expand...
Ja, quasi. (Schäm)

Nimm halt RS232, oder wenn's narrensicher sein soll RS422/485. Dafür
gibts billigste Transceiver ICs von Maxim & Co.
Click to expand...
Leider ist die RS232 Schnittstelle schon belegt. Der At90S1200 hat gar
keine. Dem müsste man dann eine Softwareschnittstelle verpassen.

Für diese uC gibt es Software UARTs, die man mehr oder weniger an jedem
Portpin installieren kann. Für einfache Signalisierungen reicht das.
Click to expand...
Der ATMega16 hat leider nur ein USART das wie gesagt bereits belegt ist :-(

Mfg
Florian
 
Florian Hirschberg schrieb:

Leider ist die RS232 Schnittstelle schon belegt. Der At90S1200 hat gar
keine. Dem müsste man dann eine Softwareschnittstelle verpassen.

Für diese uC gibt es Software UARTs, die man mehr oder weniger an jedem
Portpin installieren kann. Für einfache Signalisierungen reicht das.

Der ATMega16 hat leider nur ein USART das wie gesagt bereits belegt ist :-(
Click to expand...
Na und, was hindert dich dran, diese Transceiver an beliebige Portpins
zu hängen? Denen ist egal, ob sie an einem Hardware- oder Software UART
hängen ...


- Carsten

--
Audio Visual Systems fon: +49 (0)2234 601886
Carsten Kurz fax: +49 (0)2234 601887
Von-Werth-Straße 111 email: audiovisual@t-online.de
50259 Pulheim / Germany WGS84:N50°57'50.2" E06°47'28.5"
 
Florian Hirschberg wrote:
Was hast Du denn bisher? TTL Pegel?
Ja, quasi. (Schäm)
Click to expand...

Uii, kein Wunder, dass Du Probleme hast. Eigentlich ist ja in den
bisherigen Antwortmails schon alles gesagt worden, aber vielleicht
nochmal zusammenfassend, welche Moeglichkeiten es gaebe:

- Am besten ist natuerlich eine Entstoerung an der Wurzel
(mit Ferriten, Kondensatoren etc.)
- Rauf mit den Spannungspegeln (Stoerabstand erhoehen).
Pegelkonverter kosten sehr wenig, z.B. HIN202 (oder ST202
oder MAX202 oder... so etwa 1 Euro bei RS und Konsorten).
Als Aussenbeschaltung reichen 4..5 100nF Kondensatoren.
Das gibt Spannungspegel von ca. +/- 8..9V (also eine
Spannungsdifferenz von etwa 16..18V gegenueber 5V vorher).
- Runter mit der Baudrate, 115kBaud und Konsorten sind keine gute
Idee, wenn man die Datenrate gar nicht braucht. 9600 sollte auch
reichen.
- Leitung abschirmen (Schirm auf einer Seite mit Masse verbinden
- Evt. RS485/RS422 verwenden. Da werden differentielle Pegel verwendet,
wodurch sich (Gleichtakt)Stoerspannungen automatisch aufheben.
Ich fahre damit in industrieller Umgebung 9600Baud auf einer
Laenge von 1800m (!!).
Chips sind recht billig, z.B. MAX485 und brauchen als
Aussenbeschaltung vielleicht gerade noch einen C 100nF
zwischen VCC und GND.
- Wichtig waere natuerlich ein Protokoll mit Pruefsummensicherung,
wenigstens CRC8 oder aehnliches, XOR ist auch besser als nichts.
Fuer eine CRC8 kann ich Dir C-Code mailen, wenn Du willst
(ist recht kurz und schnell).

LG,

--
Bernhard Roessmann
Don't Fear The Penguins!
 
In article <40d1d234$0$177$9b622d9e@news.freenet.de>,
"Florian Hirschberg" <fhirschberg@fhelectronic.de> writes:
Hallo NG,

richtig. Die Steuerung hängt sich bei der Übertragung der Daten zum Display
auf, da dort auch kein Timeout eingebaut ist.. Der Grund dafür sind wohl die
beiden großen 550W Permanentmagnetmotoren die ordentlich Störungen
verursachen. Zuhause auf dem Schreibtisch funktionierte das ganze nämlich
prächtig. Nun meine Frage:
Click to expand...
Bist du sicher daß dein Problem mit der Datenübertragung zusammenhängt.

Gerade die alten at90s... sind berüchtigt für resets und abstürze
bei EM verseuchung in ihrer umgebung.

Da kann schon ein Relais reichen :-(

--
MFG Gernot
 
Servus,


Das ist soweit richtig. Allerdings ist der USART schon belegt. Aber ein
Asynchrones Protokoll kann ich auch an beiden per Software implementieren.
Im Prinzip hab ich das ja auch schon. Ich habe 3 Signale genommen. 1 x Ack
um einen Übertragungsbeginn anzukündigen. Dann 1 x Data um die Daten zu
übertragen, und das Clock Signal, das der langsamere AT90S1200 erzeugt damit
der Mega nich zu schnell sendet. Die Ausgänge am Mega habe ich direkt zum
Display gelegt, und dort mit 470 Ohm gegen Masse gelegt. An dem Widerstand
hab ich dann die Signale in den AT90S1200 geführt. Die Clock Leitung dann in
der umgekehrten Richtung genau so. Das scheint aber nicht wirklich zu
funktionieren. Zumindest nicht bei laufender Maschine.

[...]

Das mit der Prüfsumme ist mir auch schon in den Sinn gekommen. Werd ich auf
jeden Fall mal probieren.
Click to expand...
Das mit dem asynchronen Protokoll halte ich für ne gute Idee. Deine
Motoren werden dir aber solche Störungen reinhusten dass du vielleicht
Arger bekommst weil immer alle Prüfsummen falsch sind.
Ich würde das Problem an zwei Stellen angehen.
1. Störungen reduzieren
2. Übertragung störfester machen.

Zu 1:
Sind deine Motoren entstört? Wie werden die angesteuert?
Frequenzumrichter? Relais? Ich weiß noch früher vom Modellbau her
wollte meine Fernsteuerung absolut nicht mehr, wenn der Filter am
Motor fehlte. Das sind typischerweise ein paar nF zwischen den
Anschlüssen und dann jeweils nochmal von + und - gegen das
Motorgehäuse. Hast du es mal mit geschirmten Kabeln zum Motor
versucht?
Ein Klappferrit über die Motorleitung hat bei mir schon Wunder gewirkt
(in der EMV-Messhallte meßtechnisch bewiesen!)

zu 2:
Verwende ruhig dein einfaches asynchrones propritäres Protokoll. Nimm
aber zur Übertragung einen TTL->RS485 Umsetzer (Maxim hat massenhaft
von den Dingern, aber auch z.B. TI). Ich verwende die goldene Regel
niemals auf gar keinen Fall nicht einen IC-Pin nach außen zu legen der
nicht dafür gemacht ist. TTL (oder das was man heute als Digitalpegel
verwendet) gehört auf kein Kabel!
RS485/422 auf paarweise verdrillter Leitung (Telefonkabel genügt) und
du hast keinen Ärger. Außerdem solltest du vielleicht deinen Takt
reduzieren.


Gruß


Frank
 
Hallo,


Bist du sicher daß dein Problem mit der Datenübertragung zusammenhängt.

Gerade die alten at90s... sind berüchtigt für resets und abstürze
bei EM verseuchung in ihrer umgebung.

Da kann schon ein Relais reichen :-(
Click to expand...
Ja, denn das Display Funktioniert nach dem "Absturz" der Steuerung immernoch
einwandfrei auch ohne es zu resetten. Bei einem Reset würde es sonst auch
kurz alle Segmente einschalten (Displaytest).


Mfg,
Florian
 
In article <cauo74$sb1$02$1@news.t-online.com>,
"Florian Hirschberg" <fhirschberg@fhelectronic.de> writes:
Hallo,


Bist du sicher daß dein Problem mit der Datenübertragung zusammenhängt.

Gerade die alten at90s... sind berüchtigt für resets und abstürze
bei EM verseuchung in ihrer umgebung.

Da kann schon ein Relais reichen :-(

Ja, denn das Display Funktioniert nach dem "Absturz" der Steuerung immernoch
einwandfrei auch ohne es zu resetten. Bei einem Reset würde es sonst auch
kurz alle Segmente einschalten (Displaytest).
Click to expand...
Du schreibst daß du ein SPI-ähnliches protokoll verwendest.
Wenn du für clock einen Interrupteingang verwendest solltest du im Interrupt
prüfen ob wirklich ein interrupt anliegt oder ob es bloß ein spike war.

Mit deinen 3 Leitungen würd ich sowas machen:

Nach einer gewissen Pause z.b. 10 ms resetet sich der Empfangsbitcounter.

Sender: Empfänger:
Bit0 an D
0 an clock -> bit0 lesen,0 an ack
warten auf 0 an clk
Bit 1 an D
1 an clock -> bit1 lesen,1 an ack
warten auf 1 an clk
..
..
..

beim timeout beim warten wird alles auf grundstellung gebracht und
20 ms gewartet. Dadurch syncronisiert sich der at90s1200.

--
MFG Gernot
 
Hallo,

Na und, was hindert dich dran, diese Transceiver an beliebige Portpins
zu hängen? Denen ist egal, ob sie an einem Hardware- oder Software UART
hängen ...
Click to expand...
Ähh, sorry. Hab das "Software" vor dem UART überlesen.
Ich werd mal sehen was ich da machen kann. Ich glaub ich hab hier auch noch
irgendwo solche RS485 Übertrager. Das werd ich mal probieren.
Danke für die Tipps.

Mfg
Florian
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top