Sport-Anzeigetafel über USB

[wkrug]

Ok versuchen wirs mal Blockweise.
1. Ein Schieberegister ist im Endeffekt ein kleiner Speicher.
Du legst ein Bit an den seriellen Eingang des Schieberegisters und machst einen Impuls auf die Clock Leitung.
Dadurch wird dieses Bit in das Schieberegister eingelesen. Nun Legst Du ein weiteres Bit an den Eingang und machst einen weiteren Schiebeimpuls auf der Clock Leitung. Dadurch wird der erste Impuls einen Platz weitergeschoben und das neue Bit befindet sich nun auf dem Platz des Ersten.
So geht das nun weiter bis z.B. 8 Bit in dieses Schieberegister eingelesen sind.
Dann gibts ein Carry Out, auf den die Bits die in diesem Schieberegister keinen Platz mehr haben weitergeschoben werden. An diesen Carry Out hängt dann das nächste Schieberegister und so fort. Im Prinzip funktioniert das wie eine Eimerkette bei der Feuerwehr.
Für diese Funktion bräuchtest Du im Prinzip 2 Ausgänge des Microcontrollers für alle deine Segmente.

Da es aber zu einem Flackern in der Anzeige führen würde, sobald man eine neue Bitkombination in das Schieberegister einlesen will nimmt man eine Schieberegister mit Latch.
Dieses Latch ist im Prinzip ein Zwischenspeicher. Das schieben in so einem IC findet Quasi im Hintergrund statt.
Wird nun ein Latch Impuls gegeben, dann wird der aktuelle Stand des Schieberegisters in diesen Zwischenspeicher eingelesen und so lange beibehalten, bis ein neuer Latch Impuls kommt, der Chip restettet wird, oder der Strom abgeschaltet wird.
Dieses Latch ist direkt mit den Ausgängen so eines Schieberegisters verbunden.
Diesen Latch Impuls müsstest Du vom Controller ausgeben, wenn alle Bits für die Anzeige in das Schieberegister eingelesen wurden. Deshalb brauchst Du da noch einen Controller Pin.
Da dieses Schieberegister günstigerweise mit 5V Läuft und auch nur ca. 15mA Strom an seinen Ausgänge liefern kann, ist es sinnvoll einen Treiber nachzuschalten.
Am einfachsten wär da ein kleiner Transistor wie der FET BS170. Da Du aber sehr viele von diesen Transistoren + Beschaltung brauchen wirst, nimmt man dafür ein sog. Darlington Array. In diesem ULN2803 befinden sich 8 Darlingten Transistoren inklusive der nötigen Beschaltung, inklusive je einer Freilaifdiode, wenn man ein Relais anschlissen wollte.
Du brauchst also für jedes Segment ein Schieberegister und ein Darlington Array + 8 Strombegrenzungs Widerstände für die LED's.
Der vierte Anschlußpin an den Controller für die Anzeigesteuerung wäre eine Reset Leitung. Schaltet man diese Leitung, die mit allen Reset Eingängen der Schieberegister verbunden sein muß, aktiv, werden die Schieberegister zurückgesetzt. Wie schon geschrieben ist das nicht unbedingt nötig, weil man ja auch gleich beim Start des Controllers gültige Werte in die Schieberegister einschreiben kann, aber es würde den Controllerstart doch vereinfachen, wenn das nicht nötig wäre.
Das wären dann die Vier Steuerleitungen vom Controller zur Anzeige.

Eine software Multiplexansteuerung ist schon ein anderes Kaliber und in meinen Augen für so viele Stellen nicht sinnvoll.
Jede Stelle würde ja dann nur für 1/9 der Zeit bestromt und dadurch sehr dunkel erscheinen.

2. Zum Block Zeit:
Ich hatte das so verstanden, das immer die aktuelle Uhrzeit und zusätzlich! ein Countdown Timer angezeigt werden soll.
Wenn da nur ein Countdown passieren soll ist DCF natürlich Käse.

Trotzdem brauchst Du eventuell eine genaue Zeitbasis. Entweder Du nimmst einen Uhrenquarz und steuerst damit einen Timer im Controller an, oder Du machst den Controllerquarz abgleichbar ( Trimmkondensator ) damit auch nach einer Viertelstunde deine Zeitanzeige noch stimmt.

3. Leitungslänge:
Bei 5 bis 10m geht das auch noch ganz normal über die serielle Schnittstelle des PC. Allerdings brauchst Du dann auf der Controllerseite wieder einen Pegelwandler, weil der PC Spannungen von +/-12V für die einsen und nullen zum Controller sendet. Dafür gibts aber den Chip MAX232.
Wenn Du ohnehin nur einen PC mit USB Anschlüssen hast, bräuchtest Du einen USB zu seriell Konverter - Die zugegeben relativ günstig sind.
Auf der Anzeigen Seite ändert sich da aber nichts. Trotzdem ist da ein MAX 232 nötig.

Bei meinem Vorschlag würde auf der PC Seite ein FT232 USB nach seriell Wandler verwendet. Dieser gibt allerdings nur TTL Pegel an seinem Ausgang raus.
Diese TTL Pegel ( =0V /5V ) können aber auch bei Leitungslängen von 5m Probleme machen.
Deshalb der Vorschlag da für die Sende und auch die Empfangsrichtung - Falls der Controller auch mal was zum PC senden soll - Je einen RS485 Pegelwandler zu verwenden. Der benutzt 2 Leitungen und wechselt die Polarität auf der Leitung je nachdem ob an seinem Eingang eine 1 oder eine 0 anliegt.
Diese Pegelwandler müssen dann natürlich auch auf der Controllerseite eingebaut werden. Da es sich bei RS485 um ein symetrisches Signal handelt, geht die Übertragung sehr weit und Gleichtaktstörungen spielen auch keine Rolle.

Eine weitere Lösungsmöglichkeit wäre eine Funklösung via Bluetooth. Google mal nach den Chip BTM222.
Oder, als 868MHz Lösung, nach Wi.232EUR .

Google mal ein bischen rum und mach ein wenig Grundlagenforschung.
Wenn dann spezielle Probleme auftauchen, oder was unklar ist kannst Du dann ja konkret fragen.
Alles Mundgerecht vorkauen werd ich Dir nicht!

Wenn Du noch nie was mit so einem Controller selber geproggt hast, wirst Du das nach diesem Projekt können!

[ijjiij]

Vielen Dank für deine Ausführungen!
Jetzt bin ich auf jeden Fall um einiges schlauer!

Ich werde mich die Tage mal an die Stückliste, Bestückungspläne, Layouts und Schaltpläne setzen.

Ich habe jetzt nur noch eine Frage:

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?
Werde hier leider nicht wirklich schlau aus dem Datenblatt und konnte auch bei Google nichts passendes finden.
Die Kommunikation muss hier nur vom PC zum AtMega16 erfolgen, nicht in die Gegenrichtung! Das sollte die Schaltung ja noch weiter vereinfachen

[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.