Sport-Anzeigetafel über USB

[ijjiij]

Ganz einfache Frage zur USB-Seriell Datenübertragung wie sie geplant war:
Also du hast gesagt, wenn der Laptop ein Signal sendet, muss er gleichzeitig auch wieder eines Empfangen (Empfangsbestätigung also sozusagen). Gilt das umgekehrt auch so? Also muss zuerst ein Signal gesenet werden um eines erhalten zu können?

Ich habe dazu auch gegoogelt, mangels sinnvoller Suchbegriffe zu dem Thema aber leider kaum was gefunden...

EDIT:
Ganz naiv drauflosgedacht jetzt einmal:
Das USB-Experimentierboard von Velleman hat ja nur Digitale/Analoge In- bzw. Outputs.
Könnte man nicht ganz einfach hier an die Outputs die Steuerung für Displays anschließen? Also eventuell noch einen AtMega, dann den BUS, dann das Display...
An die Inputs könnte man dann ja auch die Buzzer, bzw. das komplette Buzzer-System anschließen.

Die Frage die sich mir hier dann stellt ist halt, ob man die Display-Steuerung mit dem Board überhaupt so betreiben kann? Hier gibt es ja keinen RxD / TxD Anschluss, sondern Lediglich digitale/analoge In- und Outputs.

[wkrug]

Also du hast gesagt, wenn der Laptop ein Signal sendet, muss er gleichzeitig auch wieder eines Empfangen (Empfangsbestätigung also sozusagen). Gilt das umgekehrt auch so? Also muss zuerst ein Signal gesenet werden um eines erhalten zu können?

Das ist absolut kein muß.
Es ging darum eigentlich um das debuggen mittels Terminal Programm.
Alle Daten die dein PC sendet werden nicht! im Nachrichtenfester des Terminalprogrammes angezeigt.
Die Nachrichten die von der Zielschaltung zum PC gesendet werden, zeigt tas Terminalfenster dagegen an.
In fast jedem Terminalprogramm gibt es eine Einstellung für ein "Local Echo". Mit dieser Einstellung werden wieder alle vom PC gesendeten Daten im Terminalfenster angezeigt. Allerdings auch, wenn die Zielschaltung gar nicht an der Komunikation teilnimmt.

Du kannst als Ebenso gut die Daten quasi "blind" vom PC aus senden und Dir von der Zielschaltung eine Quittung geben lassen:
z.B. Du sendest "blind" $t14:15<CR><LF>
Der Atmega antwortet mit OK<CR><LF> wenn er die Nachricht verstanden hat und mit Error<CR><LF> wenn die Nachricht unbekannt, oder fehlerhaft war.

Somit kann der PC feststellen, obe er den überhaupt ein Gegenüber hat ( Kommandoquittung kommt an ) und ob die Nachrichten richtig angenommen wurden ( OK oder Error ).
Weiterhin kannst Du das System ja noch ausweiten und bei "Error" einen Error cause mit ausgeben.
Error 0<CR><LF> könnte so z.B. Nachricht nicht verstanden bedeuten.
Error 1<CR><LF> wäre dann vieleicht Ausgang Bus Fehler.

Zudem kannst Du auch die betätigten Buzzer an den PC zuück senden lassen.
Buzzer 09<CR><LF> wäre z.B. Buzzer 9 betätigt.

Aber ich bin jetzt schon wieder mal in den Details. Ich versuch mal Dich mittels SKYPE zu erreichen.

[ijjiij]

Gut, ich war gerade dabei die neuen Schaltpläne nach unserer gestrigen Unerhaltung zu zeichnen. Leider kennt mein Eagle die MCP2515 und MCP2551 nicht.
Muss ich mir wohl neue Bibliotheken aus dem Internet besorgen...

[wkrug]

Wenn Du welche findest OK.
Wenn nicht, ich hätte da was passendes für Eagle 5.6 hier.
Lediglich für den MCP2515 ist die SMD Bauform für die Handverlötung ein wenig ungünstig, aber brauchbar