Sport-Anzeigetafel über USB

[wkrug]

Wenn ich so ein FT232RL-Modul (z.B. http://www.elektor.de/products/kits-....1913324.lynkx) verwenden möchte, wie gestaltet sich dann die Kommunikation zwischen dem Modul und dem AtMega16?

Eigentlich sehr einfach.
Für den FT232 Chip gibts den sog. VCP Treiber ( Virtual Com Port ), den ich für dieses Projekt verwenden würde.
Downloaden kannst Du diesen Treiber bei Chiphersteller ftdi ( http://www.ftdichip.com/ ).
Sobald Du dieses Bord an deinen PC ansteckst wird eine serielle Schnittstelle erkannt, die Du wie gewohnt nutzen kannst. Also über Terminal Programme ansteuern, oder in eigene Software einbinden.

Wie gesagt gibt dieser ftdi Chip nur TTL Pegel an seinen Ausgängen raus. Diese sind aber für eine Übertragung über längere Leitungen denkbar ungeeignet.
Also setzt Du vor den RxD Eingang des FT232R einen RS485 Bustreiber ( =SN75176 ) der dann über 2 verdrillte Drähte mit einem RS485 Bustreiber in deiner Uhr verbunden wird. Dieser Bustreiber wird dann mit dem Ausgang TxD deines Controllers in der Uhr verbunden.
Für den Weg vom PC zur Uhr wird das genauso gemacht. Also FT232R TxD -> SN75176 Bustreiber -> verdrillte Doppelader -> SN75176 Bustreiber -> Controller RxD Pin.
Dann kannst Du im Controller den USART benutzen, was die Komunikation enorm vereinfacht.
Guck mal hier: http://de.wikipedia.org/wiki/RS485
Da Du für diese Lösung ohnehin 2 verdrillte Adern benötigst ist es sinnvoll ein Kabel mit mindestens 2 verdrillten Doppeladern zu nehmen.
Es ginge auch mit nur einer verdrillten Doppelader, aber dann wäre nur Halb Duplex möglich und Du müsstest Dir ein Protokoll Überlegen, das festlegt, wer jetzt Sender und wer Empfänger ist. Da es hier nur um ein paar Meter Kabel geht würd ich mir das nicht antun.

In einem Netzwerk - Patchkabel sind bereits 4 verdrillte Doppeladern eingebaut, der Wellenwiderstand passt und das Kabel ist nicht teuer.
Das würde ich für die Verbindung vom PC zum Display verwenden.
Bei der Wahl der Steckverbinder hast Du freie Auswahl. Fertige RJ45 Kabel wären eine Lösung, aber nicht besondes stabil. 5polige XLR Steckverbinder wären auch eine Lösung.
Noch was - Eine RS485 Verbindung mus an beiden Leitungsenden abgeschlossen ( = Terminiert ) werden. Das bedeutet auf der jeweiligen Sender und Empfängerseite muß ein Widerstand von 120Ohm eingebaut werden. Im Layout kannst Du ja schon mal einen per Jumper abschaltbaren Widerstand vorsehen.

Bei der Wahl der zu übertragenden Daten bist Du frei. Ich würde mir da ein ASCII Protokoll ausdenken, da das bei einem PC relativ einfach zu handeln ist.
Eine Möglichkeit wäre ein Steuerzeichen einzuführen und dann den Befehl mit den Parametern zu versenden.
Das Ende so einer seriellen Übertragung macht man oft mit den Steuerzeichen <CR> <LF>, also Carriage Return und Line Feed. Achtung hier sind nicht die Buchstaben gemeint, sindern die Hex Codes 10 und 13! Ein Terminalprgramm generiert diese Steuerzeichen automatisch bei der Betätigung der Return Taste!
Zudem wäre die Datenübertragung dann auch mit einem Terminalprogramm relativ einfach zu debuggen.
Beispiel für Eine Datenübertragung:
$S;1:1<CR><LF>
$ Wäre dabei ein Marker für einen Kommandoanfang.
S Wäre der Kenner für Spielstand
; Wäre ein Trenner der Daten von den Steuerzeichen
1:1 Wäre der zu übertragende Spielstand.
<CR><LF> Wäre das erwähnte Zeilenende.

Als Bestätigung könnte der Controller dann
@S;1:1<CR><LF> senden. Dadurch wäre dann auch die Datenübertragung verifiziert und ein hardwareloop würde auch erkannt werden.

Für andere Daten kannst Du dann andere Steuerzeichen verwenden.
$C;12:10<CR><LF> wäre dann eine Countdown Zeit von 12min 10 sek.
Der Controller könnte das dann mit
@C;12:10<CR><LF> bestätigen.

Wie gesagt ist nur ein Gedankenanstoss, kannst Dir ja auch dein ganz Eigenes Protokoll zusammen basteln.

Denkbar wäre auch ein Protokoll, das nur die Werte für die 9 einzelnen Segmente überträgt.
Also z.B.
$0;8;3;4;0,3,2,1,1<CR><LF>
Dann läge die Anzeigensteuerung allein im PC.

Eine weitere Idee wäre eine kleine Controllerbox zu basteln, die die Rolle des PC übernimmt und du Somit unabhängig von einem PC würdest. ATMEGA 16 mit 2 RS485 Treibern, Display, ein paar Tasten und ein Steckernetzteil sollten genügen. - Wie gesagt Du hast da ja alle Möglichkeiten!

Die Kommunikation muss hier nur vom PC zum AtMega16 erfolgen, nicht in die Gegenrichtung! Das sollte die Schaltung ja noch weiter vereinfachen

Würd ich nicht machen, weil Du dann auf der PC Seite nie Gewissheit hast, ob die Uhr die Daten jemals Empfangen, bzw. Fehlerfrei Empfangen hat.
Im Prinzip würdest Du Dir eine Doppelader und 2 Bustreiber sparen.
Kabel wäre wegen der mechanischen Stabilität ohnehin Sinnvoll. So ein Bustreiber kostet bei Re.... 0,26€ also Peanuts bei so einem Projekt!

[ijjiij]

Nochmal vielen Dank für deine Ausführungen!
Langsam bekomm ich wirklich Durchblick durch diese ganzen (für mich neuen) Bauteile.

Rein hypothetischer Fall jetzt, ich würde die Möglichkeit vorsehen wollen, eventuell mehrere solche "Anzeigetafeln" (in verschiedenen Größen, aber nach gleichem Konzept aufgebaut) an verschiedenen Orten des Sportplatzes platzieren wollen.
In dem Fall würde ich dann wohl an den PC das FT232 Modul anschließen, direkt dahinter dann gleich einen Controller, der dann ja 3+9 Datenströme (3 für die Schieberegler + 9 für den Seriellen Input 1 oder 0) ausgeben müsste. Die 12 Datenströme könnte ich dann ja eigentlich "splitten", also einfach einen "Verteiler" dazwischenschalten und alle 12 Signale auf z.B. 3 Wannenbuchsen ausgeben, über die ich dann 3 Displays anhängen könnte. Richtig soweit?
In dem Fall müsste ich dann hier, also vor den Wannenbuchsen bzw. in den Displays noch 12 Bus-Bauteile verbauen, richtig?

Das ganze ist jetzt nur ein hypothetischer Fall...
So würden zwar die Kosten für die "Controller-Einheit" etwas steigen, dafür die Kosten für die einzellnen Displays sinken, wodurch die relativen Kosten bei höheren Anzahlen von Displays aber sinken würden.
Dadurch hätten wir (also der Veranstalter) doch noch ganz einfach die Möglichkeit, weiter Displays z.B. in der Umkleide aufzuhängen, damit jeder den Spielstand immer im Blick hat.

Ist das so machbar?
Man müsste halt viel mehr BUS-Bausteine verwenden als wenn "nur" die Übertragung vom PC zum Display verstärkt wird. Dadurch würden halt auch viel mehr Kabel verlegt werden müssen.
Steht hier der Mehraufwand in irgendeiner Relation zum Nutzen?
Oder wäre es sinnvoller, das Signal vom FT232 zu "splitten" und die Controller in den Displays zu belassen? Dann hätte ich halt wieder nur 3 * 2 Duplexen zum verstärken mit BUS, aber auf der anderen Seite wieder Mehrkosten bei jedem weiteren Display durch die zusätzlichen Controller, die in jedem Display stecken würden. Außerdem wären dann ja 3 Controller im Einsatz, und damit bestünde die (wenn auch sehr kleine) Chanze, das die 3 Displays auf unterschiedliche Werte kommen? Zumindest für Bruchteile von Sekunden.

Hoffe das hab ich jetzt halbwegs verständlich Formuliert...

LG
ijjiij

PS:
Das von dir Angesprochene System würde dann mit 3 Displays iwie so aussehen:
Anhang 21992
richtig?

Würde das denn auf diese Weise funktionieren? (Versuche mich da gerade etwas Weiterzubilden )

[wkrug]

Einen eigenen Steuercontroller würde ich in jeder Uhr vorsehen.
Das mit den Schiebimpulsen über ein längeres Kabel halte ich nicht für eine gute Idee.

Es geht Busmässig sogar noch doller!
RS 485 muss an den beiden Enden! terminiert werden.
Die Treiber als solches sind aber so ausgelegt, das bis zu 32! Empfänger an eine Leitung angeschlossen werden dürfen.
Das bedeutet, Du kannst von Jeder Uhr zur nächsten weiter gehen und nur bei der letzten im Bus kommt ein Abschlußwiderstand rein!

Allerdings wird dann die Quittung über einfaches Wiederholen der Nachrichten vom Controller zum PC nicht mehr funktionieren.
Da dann ja mehrere Ausgänge auf 2 Drähten vorhanden wären.
Entweder Du machst dann nur eine Uhr mit so einer Kommandoquittung, die immer als letzte in den Bus kommt, oder Du verzichtest auf den Rückkanal, oder Du verwendest ein anderes Busprotokoll.
Da ich mir so was schon fast gedacht hatte, auch der Vorschlag mit den abschaltbaren Terminator Widerständen.

Eine Mögliche Alternative wäre eventuell CAN, mit dem ich mich zur Zeit beschäftige. Ist aber ganz schön komplex und die Chips sind auch teuerer als die RS485 Lösung.

Die Lösung mit der Unidirektionalen Verbindung über RS485 wird zum Beispiel bei DMX512 ( Lampensteuerung in Theatern und Veranstaltungen ) verwendet.
Dabei können bis zu 512 Kanäle in bis zu 30 Geräten über eine bis zu 1km lange Leitung verschaltet werden.
Die Beschränkung auf 512 Kanäle ist allerdings nur eine Softwaremässige!
Der Datenstrom ist dabei allerdings nur vom Steuerrechner zu den Empfängern vorgesehen. Ein Rückkanal ist bei DMX512 weder in Harware noch in Software vorgesehen. Das macht hier allerdings auch nichts aus, weil der Datenstrom ca. alle 10ms wiederholt wird.

Die Bus Terminierung kannst Du aber auch so lösen, wie es bei DMX512 gemacht wird.
Dort ist eine Männliche Buchse als Eingang vorhanden und eine weibliche als Ausgang.
Intern sind beide Buchsen parallel geschaltet.
An dieser zweiten Buchse steckt entweder ein weiteres Gerät ( weitere Anzeige ) oder ein Stecker mit einem Terminator Widerstand.

Von der Kommando Wiederholungs Lösung musst Du Dich auch nicht komplett verabschieden.
Du könntest ja auch eine kleine Controllerplatine entwickeln, die den Bus Abschliesst und alle Empfangegen Daten wieder mit dem Anderen Startzeichen an den PC zurück sendet.
Im einfachsten Fall könnte das auch nur ein Stecker sein, der die Sendeleitung mit der Empfangsleitung verbindet.
Die einzelnen Anzeigen brauchen dann nur Daten zu Empfangen.
Der Brückenstecker schickt dann alle gesendeten Daten an den PC zurück. Der kann somit kontrollieren, ob das Signal richtig über den Bus drüber ging.
Zusätzlich kannst Du in deinen datenstrom noch eine Prüfsumme mit einbauen ( EXOR oder CRC ). Dadurch kann dann jeder Empfänger feststellen ob er die Daten fehlerfrei Empfangen hat.

Ich hätte da mindestens 3 bis 4 Ideen wie man sowas realisieren könnte.

Ich hätte Skype - Wenn Du magst können wir uns ja Da mal drüber unterhalten.

[homedom]

Hi,
habe mir mal etwas durchgelesen was du so vor hast. Wkrugs Ideen finde ich schon richtig gut, aber warum versteifst du (wkrug) dich so auf die Rückmeldung einer "Empfangsbestätigung" zum PC? Eine Prüfsumme ist sicher nicht schlecht. Was ich mir noch vorstellen könnte wäre eine Lösung wie bei DMX512 (übrigens hat eine neue Version des Protokolls auch einen Rückkanal), dass einfach die Daten in sehr kleinen Abständen wiederholt verschickt werden. Dazu könnte man ein Controller Board zwischen PC und Bus setzen. Der PC überträgt dann einmal pro Sekunde, oder wenn sich was ändert, die Daten an das Board, welches dann alle paar Millisekunden die Daten auf den Bus schickt. Oder eben dieses Board managed, dass jedes Display die Daten erhalten hat indem man die Displays auch auf den Bus schreiben lässt und jedes Display eine Bestätigung an den Master schickt. Da müsste man sich aber eventuell Gedanken um Kollisionserkennung machen. Dazu könnte man aber eine Reihenfolge festlegen in denen die Displays antworten. Da jedes Display den Bus ja abhören kann, weiß es dann wann es seine Bestätigung auf den Bus schreiben darf.
Das wären nur mal so meine Ideen Aber es gibt sicher etliche wie man das noch realisieren kann.

Gruß, homedom

[wkrug]

...aber warum versteifst du (wkrug) dich so auf die Rückmeldung einer "Empfangsbestätigung" zum PC?

Weils ziemlich einfach zu realisieren ist und von der Hardware her wenig Aufwand macht und die Daten trotzdem nur im Bedarfsfall ( Neue Daten, oder Fehler ) gesendet werden müssen.
Eine Rückmeldung von jedem Empfänger würde, wie Du richtig bemerkt hast, eine Kollisionserkennung erfordern, oder ein Protokoll mit Zeitfenstern.
Zudem könnte der Master, also der PC nicht mehr zu jedem Zeitpunkt senden, solange noch Quittierungen fehlen.
Eine zeitmässig abgestufte Antwort der einzelnen Knoten ( Uhren ) würde wiederum eine Adressierung oder Priorisierung erfordern.

Die Methode mit den schnell aufeinander folgenden Nachrichten, wie bei DMX 512 würde einen zusätzlichen Controller mit eigens entwickelter Software nötig machen.

Zur Zeit würde ich deshalb den passiven Schleifenstecker als Lösung favorisieren.
Damit ist zumindest sichergestellt, das an allen Uhren die korrekte Nachricht anlag.
Der PC kann einen Fehler sofort erkennen und an den User weitergeben.

Ein Protokoll bei dem mehrere Slaves senden dürfen ist da immer aufwändiger. Entweder von der Hardware her, oder von der Softwareseite.

Zudem kann man so eine Konfiguration mit jedem beliebigen Terminalprogramm debuggen, weil die nötige Nachrichtenschleife ja vorhanden ist. Es handelt sich ja um eine Eigenentwicklung und da auf Anhieb ein fehlerfreies Programm hinzukriegen halte ich für nicht möglich.
Zudem ist die Anzahl der Busteilnehmer nur durch die Bustreiber begrenzt. Baut man einen Repeater ein kann man das Signal fast an beliebig viele Slaves ( Uhren ) versenden. Und jede Uhr kann mit der gleichen Software ohne zusätzliche Addressierung angebunden werden. Auch das vertauschen von 2 Uhren miteinander hat keinen Einfluss auf diesen Bus.

Eine weitere Möglichkeit wäre, das jede angeschlossene Uhr ihre empfangenen Daten einfach wieder an einer Ausgangsbuchse zur nächsten Uhr weitergibt.
Somit würde jede Uhr als Repeater fungieren. Am Ende der Kette könnte Dann wieder der Schleifenstecker zum Einsatz kommen.
Somit wären alle Uhren in der Kette auf ihre korrekte Funktion überwacht. Denn wenn ein Knoten keine oder falsche Daten weitergibt, kommt die korrekte Datensatz nicht mehr beim PC an.
Allerdings weisst Du dann noch nicht bei welchem Knoten das Problem liegt.
Eine Uhr ohne Strom würde aber dann den Ausfall aller folgenden Uhren bewirken.

Ich schrieb ja schon - Eine Alternative wäre CAN. Da ist bereits eine Kollisionserkennung mit eingebaut und das Protokoll wäre für diese Anwendung praktisch Ideal, weil ja praktisch jeder Knoten die gleichen Informationen braucht. Ausserdem überwacht jeder Knoten die CAN Busleitung auf Fehler. Die Reichweite wäre bei niedrigen Baudraten auch ausreichend und man würde nur eine Doppelader benötigen.
Aber wenn Du Dir mal das Datenblatt vom MCP2515 oder einem anderen CAN Controller anschaust wirst Du Deine Meinung über das vermeintlich einfache Protokoll schnell revidieren. Da sind dann schon mal 10 bis 15 Register mit den "richtigen" Daten zu versorgen bis so ein Chip vernünftig läuft.

Das mit dem Rückkanal bei DMX 512 war mir schon bekannt, wird aber faktisch so gut wie nicht genutzt und macht da auch nicht wirkich Sinn. Ausserdem benutzen sehr viele günstige DMX Geräte 3polige Buchsen, obwohl das natürlich nicht Normgerecht ist. Und spätestens da kannst Du dann den Rückkanal vergessen.

So wie im Anhang wäre ein bidirektionaler full Duplex Knoten aufgebaut. Also so wie er auf der PC Seite nach dem FT232 zum Einsatz kommen könnte.

[wkrug]

@ijjiij
Sorry ich hab gerade erst Deinen Dateianhang in Antwort #8 entdeckt.
Im Prinzip wär das so richtig, nur das es von der ersten Uhr zur zweiten und dann von der zweiten zur dritten Uhr gehen soll.
Das mit dem Schieberegister stimmt so. In jede Uhr kommt somit ein Controller, der die Schieberegister nur für diese Uhr bearbeitet.
Übrigens würde ich für eine Stelle 8 Bit verbraten. Zum einen Hat so eine Anzeige eventuell einen Dezimalpunkt und es passt auch besser in die 8Bit Struktur eines solchen Controllers. Da auch die Hardware SPI immer 8 Bits sendet.
Das bei den Zahlen die richtigen Segmente angesteuert werden lässt sich am geschicktesten über eine indizierte Tabelle erreichen.

unsigned char uc_disptable[10] {0b01100000,0b11011010,0b11110010,0b...... usw.}
Das indiz ist dann die Zahl die angezeigt werden soll, in der Tabelle verstecken sich die anzusteuernden Segmente.
Die Ziffer 0 würde dann den ersten Speicherplatz ansprechen also uc_dispplatz[0]=uc_displtable[0];
Die Dezimalpunktansteuerung würde ich nach dem Auswählen der Ziffer erst machen also uc_displplatz[0]|=0b00000001;
Sind alle Segmentinformationen beisammen wird alles in die Display Schieberegister geschoben.

for(uc_i=0;uc_i<10;uc_i++)
{
while(ssr&0b10000000==0){} //Warten bis die SPI frei ist Programmbeispiel im ATMEL Datasheet beachten!
{
sdr=uc_displplatz[uc_i]; //Zu übertragende Daten in das Datenregister der SPI übergeben
}
}
LATCH = 1; // Nachdem alle Daten zu den Schieberegistern übertragen wurden Latch Impuls generieren
#asm("nop");
LATCH = 0;

Ist jetzt natürlich nur ein pseudo Code. Die Registernamen der SPI hab ich jetzt nicht im Datenblatt nachgeguckt.

[ijjiij]

@ijjiij
Sorry ich hab gerade erst Deinen Dateianhang in Antwort #8 entdeckt.
Im Prinzip wär das so richtig, nur das es von der ersten Uhr zur zweiten und dann von der zweiten zur dritten Uhr gehen soll.

MUSS das Signal von Uhr zu Uhr gehen? Ja oder? Da gibts keine wirkliche Alternative dazu?
Beim Aufbau von 3 Displays (was meiner Meinung nach auf jeden Fall bald passieren wird...), würde es sonst in unserem Fall zu einer etwas ungünstigen Kabelverlegng kommen weil der Aufbau hier (räumlich gesehen) so aussehen würde:

kleineres Display -------- Großes Display + Laptop (Datenquelle) -------- kleineres Display

Dann würde die Kabelführung wohl vom Laptop zum 1. kleinen Display laufen, dann zurück zur großen Anzeige und rüber zum 2. kleinen Display. (Und dann wieder zurück zum Laptop? Oder kann das über die gleichen Leitungen wieder zurück geschehen?)
Dann hätte also jedes Display 2 Buchsen, eine für eingehendes Signal, eine für die Weiterführung des Signals zum nächsten Display. Richtig verstanden?

(Die Programmierung ist wie gesagt nicht so direkt meine Sorge, dafür hab ich Informatiker)