Störsichere serielle Datenübertragung

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

Reply to
Florian Hirschberg
Loading thread data ...

Florian Hirschberg schrieb:

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
Reply to
Stefan Heinzmann

Hallo Florian,

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

Reply to
Edzard Egberts

Florian Hirschberg schrieb:

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
 Click to see the full signature
Reply to
Carsten Kurz

Hallo,

Das sagst du so, das soll ja mal wieder alles morgen laufen... Wie das eben so ist.

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.

Mfg Florian Hirschberg

Reply to
Florian Hirschberg

Hallo,

Ja, quasi. (Schäm)

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

Der ATMega16 hat leider nur ein USART das wie gesagt bereits belegt ist :-(

Mfg Florian

Reply to
Florian Hirschberg

Florian Hirschberg schrieb:

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
 Click to see the full signature
Reply to
Carsten Kurz

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!
Reply to
Bernhard Roessmann

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
Reply to
Gernot Fink

Servus,

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

Reply to
frankhaussmann

Hallo,

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

Reply to
Florian Hirschberg

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
Reply to
Gernot Fink

Hallo,

Ä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

Reply to
Florian Hirschberg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.