Hallo, ich habe hier einen DSP, der über USB mit dem PC verbunden wird und mittels GUI programmiert werden kann. Die Kommunikation geschieht dabei über einen USB Treiber, der einen virtuellen COM Port einrichtet, also serielle Kommunikation zwischen PC und DSP. Mit einem Terminalprogramm kann ich ausserdem Kommandos seriell in den DSP senden und die Antworten vom DSP empfangen. Ich würde gerne mit einem Atmega samt LCD Display mit dem DSP kommunizieren, also ohne PC. Der Atmega soll auf Tastendruck ein Kommando an den DSP senden, der gibt dann entsprechende Ausgaben aus, die der Atmega auswerten und entsprechend Daten am Display darstellt. Die Steuerkommandos hierfür sind mir bekannt. Nur wie bekomme ich den Mikrokontroller an den DSP angebunden, als serielles Gerät per USB? Ich hoffe ich habe mich verständlich ausgedrückt!? Ich freue mich auf Antworten :-)
Einen USB Host (wie den PC) auf dem AVR zu implemetieren, ist recht kompliziert, aber wahrscheinlich nicht unmöglich. Einfacher allerdings wäre es, sich den seriellen Port direkt unter den Nagel zu reissen, der auf dem DSP Board ist. Wie ist das realisiert? Gibt es einen Boardcontroller oder einen USB-Seriell Chip? Hast du einen Schaltplan des DSP Boards?
Gar nicht. Du bräuchtest einen µC, der USB Host Modus unterstützt. Das habe ich bisher nur bei neueren 32 Bittern (wie Cortex M3/4) in Funktion gesehen, weil es deutlich aufwändiger als UART ist.
Matthias Sch. schrieb: > Einen USB Host (wie den PC) auf dem AVR zu implemetieren, ist recht > kompliziert, aber wahrscheinlich nicht unmöglich. Einfacher allerdings > wäre es, sich den seriellen Port direkt unter den Nagel zu reissen, der > auf dem DSP Board ist. Wie ist das realisiert? Gibt es einen > Boardcontroller oder einen USB-Seriell Chip? > Hast du einen Schaltplan des DSP Boards? Schaltplan gibts leider nicht, ich schau mir aber die Platine genauer an ob ich da was finde
Hi, Wenn ich das richtig verstehe fungiert der PC bisher als USB HOST. Wenn du den PC nun durch einen µC ersetzen willst musst der µC nun die Rolle des USB HOST übernehmen. Es gibt zwar AVR mit nativen USB Port, aber diese fungieren alle nur als DEVICE und können nicht als USB HOST fungieren. Du müsstest also die USB Host funktionalität durch einen Externen Baustein bereitstellen! Im ergebniss also "DSP" <-USB-> "USB-HOST-BAUSTEIN" <-SPI-> "ATMEGA" Das ist aus meiner Sicht allerdings relativ Sinnfrei. Mein Rat: Vergiss die ATMEGA für den Zweck und greife zu einem µC der auch eine USB HOST Funktion bereitstellt. Fündig wirst du bei diversen ARM Cortexen oder auch bei den PIC24 & PIC32... Ob nun ARM Cortex oder PIC24/32 für dich die elegantere Wahl ist sei mal dhingestellt (ist GEschmackssache und abhängig von anderen Randbedingungen). Funktionieren wird beides. Für die PIC weiß ich aber -da schon mehrmals erfolgreich eingesetzt- das es gerade für CDC eine vernünftige und kommerziell ohne Gebühren verwendbare CDC-Host funktion fast Mundgerecht serviert gibt. Gruß Carsten
Gerd J. schrieb: > Die Kommunikation geschieht dabei über einen USB Treiber, der einen > virtuellen COM Port einrichtet Wenn Du das mit einem USB-Host nachbilden willst, musst Du das verwendete Protokoll nachvollziehen. Es könnte sein, daß hier USB-CDC verwendet wird, aber es kann natürlich auch irgendwas anderes sein (so, wie es bei den üblichen USB-Seriell-Bridges gemacht wird, die verwenden alle ihr eigenes, zu allen anderen inkompatibles Protokoll, ob nun von Prolific, TI, SiLabs oder FTDI). Das aber musst Du herausfinden, denn das muss Dein USB-Host nachbilden, damit er mit dem DSP "reden" kann.
Ok, das wird glaube ich sehr aufwendig mittels USB host :-( Für den DSP habe ich noch eine kleine Controllererheit, die mit einem Atmega8 versehen ist. Anbindung zum DSP erfolgt über einen RS485 mit einer 4 adrigen Leitung, wovon 2 wohl die Controllereinheit mit Spannung versorgen. Mit der Controllereinheit kann man z.B. den Ausgangspegel des DSP regeln. Keine Ahnung ob und wie ich das Protokoll zwischen DSP und Controllereinheit 'belauschen' kann. Habe schon daran gedacht die Controllereinheit mit dem PC zu verbinden. Nur wie?!
Gerd J. schrieb: > Keine Ahnung ob und wie ich das Protokoll zwischen DSP und > Controllereinheit 'belauschen' kann. Habe schon daran gedacht die > Controllereinheit mit dem PC zu verbinden. Nur wie?! RS485 ist einfach. Es handlet sich um eine serielle Kommuniktion wie UART, nur mit differentiellen Signalen (symmetrisch, wenn eines + ist, ist das andere - und umgekehrt). Für RS485 gibt es einfache kleine Transceiver (z.B. MAX485), die das Umsetzen erledigen können und direkt an z.B. die UART eines AVR angeschlossen werden. Abhören kann mit dem PC sogar evtl. ganz ohne zusätzliche Hardware erfolgen, entweder direkt am COM Port, wenn dein Rechner so etwas noch hat, oder eben über einen USB - Seriell Adapter. Du musst RXD des PC nur mit der richtigen Ader der differentiellen Übertragung verbinden und die richtige Baudrate finden.
:
Bearbeitet durch User
Gerd J. schrieb: > Keine Ahnung ob und wie ich das Protokoll zwischen DSP und > Controllereinheit 'belauschen' kann. Habe schon daran gedacht die > Controllereinheit mit dem PC zu verbinden. Nur wie?! 'Belauschen' setzt zwei Dinge voraus: - eine Software, die etwas mit dem Datenstrom anfangen kann (im einfachsten Fall ein Terminalprogramm, z.B. HTerm) - einen physischen Zugriff auf den Datenstrom. In deinem Fall wäre das z.B. ein USB-Seriell Wandler für RS485 Signale, den du nur empfangsseitig nutzt, um die vom DSP oder die vom Controller gesendeten Daten abzuhören.
Eine Alternative ist es, die Datenleitungen zwischen RS485-Treiber und dem AVR abzugreifen. Dann weiß man auch, wer gerade sendet, der AVR oder der DSP. Zum ordentlichen Mithören braucht man dann am PC zwei serielle Schnittstellen, die o.g. Datenleitungen werden jeweils über einen passenden RS232-Treiber mit der RxD-Leitung der Schnittstellen verbunden. Somit kommt auf der einen Schnittstelle das an, was der AVR sendet und auf der anderen das, was der DSP antwortet. Natürlich muss man noch die Baudrate bestimmen, dazu eignet sich ein Oszilloskop.
Reicht es den Controller mit Strom zu versorgen und an RXD zu lauschen, oder muss der DSP verbunden sein? Es muss doch Master und Slave vorhanden sein, richtig?
Gerd J. schrieb: > Reicht es den Controller mit Strom zu versorgen und an RXD zu lauschen, > oder muss der DSP verbunden sein? Wenn da ein Protokoll verwendet wird, müssen natürlich beide Seiten da sein.
Gerd J. schrieb: > Es muss doch Master und Slave > vorhanden sein, richtig? Master und Slave in dem Sinne gibt es bei RS485 nicht, es kann aber halbduplex ('wechelsprechen') sein, d.h. es kann sein, das der DSP auch was an den Controller sendet. Wissen wir nicht, deswegen ist es am besten, die existierende Verbindung anzuzapfen. Dann siehst du auch gleich, welche Datensequenzen welche Auswirkungen haben.
Auf der Controllerplatine ist ein ADM485 verbaut, an A und B sind 1000Ohm Widerstände in Reihe. Soweit ich erkennen kann (SMD) sind RE und DE gebrückt und an den Atmega8 geführt. Weitere Verbindungen muss ich erst noch rausfinden :-) Ist der Ausgangspegel des 485 ok für den COM Port des PC oder muss da noch ein Max232 zwischen?
Gerd J. schrieb: > Ist der Ausgangspegel des 485 ok für den COM Port des PC oder muss da > noch ein Max232 zwischen? Nahezu allen heutigen COM Ports erkennen ein 0V Signal auch als gültige '1', was zwar nicht ganz normgerecht ist, aber meistens doch funktioniert. Da dein ADM485 eine Ausgangsspannung zwischen Vcc und 0V produziert, könnte es also klappen. Du musst lediglich die richtig 'gepolte' Ader erwischen, wenn ich mich nicht irre, müsste es die B-Ader sein. Wenn in deinem System ein Bias Netzwerk mit Widerständen vorhanden ist, funktioniert es dann wieder nicht so einfach, dann müsstest du tatsächlich mit einem Max232 o.ä. 'fischen'. http://www.rn-wissen.de/index.php/RS485 https://de.wikipedia.org/wiki/EIA-485 Gerd J. schrieb: > Soweit ich erkennen kann (SMD) sind RE > und DE gebrückt und an den Atmega8 geführt. Das ist die Sende/Empfangsumschaltung. Es könnte also wirklich eine Halbduplex Kommunikation stattfinden.
:
Bearbeitet durch User
Gerd J. schrieb: > Ich dachte ich soll das Signal zwischen 485 und AVR abgreifen. > Also RO oder DI!? Wenn Du das tust, brauchst Du einen RS232-Treiber, und Du musst sowohl RO als auch DI abgreifen. Das bietet den Vorteil, klar zu wissen, wer gerade sendet - was beim Abhören am RS485-Bus nicht ohne weiteres möglich wäre.
Angehängte Dateien:
-
image.jpg
190 KB
So wie im Anhang? Nur ohne RTS, da die Umschaltung zwischen Senden/Empfangen durch die Controllereinheit des DSP erfolgt.
Zum Mithören nicht. Du hast zwei Signale, die Du beide an den PC senden willst, und zwar abwechselnd (wenn Du nur eine serielle Schnittstelle am PC hast). Das eine Signal geht von RO des RS485-Transceivers an RxD des AVR - das kommt zusätzlich an T1IN des MAX232, damit kannst Du abhören, was der DSP dem AVR erzählt. Das andere Signal geht vom TxD des AVR an DI des RS485-Transceivers. Das kommt zusätzlich an T2IN des MAX232, damit kannst Du abhören, was der AVR dem DSP mitteilen möchte. Auf der anderen Seite des MAX232 schließt Du zwei zweiadrige Kabel an - eine Ader ist jeweils Masse, die andere T1OUT bzw. T2OUT. Jedes Kabel kommt an eine 9polige SubD-Buchse, Masse an Pin 5, T1OUT bzw. T2OUT an Pin 2. Zum Mithören steckst Du entweder das eine oder das andere Kabel in die serielle Schnittstelle Deines PCs -- oder Du verwendest zwei Schnittstellen und schließt beide Kabel gleichzeitig an. R1IN/R2IN und R1OUT/R2OUT des MAX232 lässt Du unbeschaltet, ebenso /RE und DE des RS485-Transceivers, die werden ja schon vom AVR bzw. vom DSP angesteuert.
Klingt logisch so wie du es erklärst, danke!!! Die Baudrate muss ich noch rausfinden, Oszi ist vorhanden. Bei der eingangs erwähnten Verbindung über den virtuellen USB-COM Port muss ich 38400,8,N,1 einstellen. Wird wahrscheinlich hier genauso sein.
:
Bearbeitet durch User
Kleines Update von mir. Die Controllerplatine ist auch ohne DSP nutzbar. Es findet nur Datenfluss vom Controller in Richtung des DSP statt. Also keine Antwort vom DSP wie, 'ok, Daten empfangen'. Mit Oszi gemessen, dass mit angeschlossenem DSP nichts am RO des 485 ankommt. Also Controllerplatine mit 5V versorgt, und am DI den 485 den Max232 angekoppelt und mit Com Port des PC verbunden. Hterm gestartet und verschiedene Baudraten probiert. Irgendwie kommt da nicht das Richtige an :-( Als Hintergrund. Der Controller kann z.B. den Ausgangspegel des DSP regeln. Bei jeder Änderung schickt der Controller ein Datenpaket an den DSP. Dieses Datenpaket scheint kein normales serielles Signal zu sein. Daher kommt im Hterm nur Datenmüll raus. Gibts einen Tipp für eine DatenloggerSW die am Comport alles mitloggt, am besten Freeware. Das Signal fängt z.B. mit einem längerem Puls an, dann folgen die einzelnen Bits. Am Oszi kann ich die Bits nachvollziehen, sagen mir aber nichts. Ich mach mal einen Screenshot am Oszi und stelle die Kurve hier dann rein, evtl. kann jemand damit was anfangen und mir weiterhelfen.
Gerd J. schrieb: > Das Signal fängt z.B. mit einem längerem Puls an, dann folgen die > einzelnen Bits. Klingt ein bisschen, als wäre das (ähnlich wie DMX) Frame-orientiert. Das lange Signal ist dann das Signal für Framestart und dann kommen die Bits. Wenn es dir gelänge, die Länge eines Bits zu messen, kann man HTERM entsprechend auf die Länge des Framestartes einstellen (neue Zeile) und dann die Bits dekodieren. DMX z.B. verwendet 250kBits/s, d.h. ein Bit ist 4µs lang. Der Bytestrom bei DMX kommt dann ohne absetzen bis zum Frameende, aber schon mit Start- und Stopbit zwischen den einzelnen Bytes. Kann es denn sein, das das Gerät aus der Show- und Entertainment Szene stammt? Dann wäre eine DMX Steuerung nämlich gar nicht so weit hergeholt. Hat es Adress-Schalterchen?
:
Bearbeitet durch User
Angehängte Dateien:
-
image.jpg
400 KB
Der erste längere Puls ist lt. Oszi 38us lang, siehe Anhang. Im 2. Anhang finden sich die Bits etwas gestreckt. Das Bit zwischen den Cursormarkern dürfte eine 0 sein (etwa 25us), gefolgt von einer 1.
Gerd J. schrieb: > also serielle Kommunikation zwischen PC > und DSP. USB ist immer seriell. Gerd J. schrieb: > Ich würde gerne mit einem Atmega samt LCD Display mit dem DSP > kommunizieren, also ohne PC. Da nimmt man dann eher sowas wie SPI oder IIC. Gerd J. schrieb: > Nur wie bekomme ich den Mikrokontroller an den DSP angebunden, als > serielles Gerät per USB? Gar nicht, ausser Du schiesst mit Kanonen auf Spatzen.
Gerd J. schrieb: > Das Bit zwischen den > Cursormarkern dürfte eine 0 sein (etwa 25us), gefolgt von einer 1. Ja, das sieht nicht kompliziert aus, und sollte recht leicht zu dekodieren/kodieren sein.
Angehängte Dateien:
-
image.jpg
300 KB
Danke erstmal. Ich habe das Datenpaket, welches der AVR dem DSP bei Änderungen der Einstellungen sendet, mit dem Oszilloskop analysiert. Das gesamte Datenpaket hat eine Länge von 2.178ms. Zuerst wird ein 38us langes High geschickt, gefolgt von einem 16us langem Low, zu sehen auf dem vorletzten Anhang (5 Postings zurück). Dann kommen 88 Bits, jeweils ca.25us lang, die wie im Anhang unten aussehen. Erinnert mich irgendwie an IRDA Protokolle. Keine Start/Stop Bits. Durch Vergleich der verschiedenen Einstellungen beim Controller konnte ich diese im Datenpaket wiederfinden. Z.B. Volume kann per Poti zwischen hex 00 bis 99 eingestellt werden, dieser Wert wird im Datenpaket gesendet. Den Controller würde ich gerne weiterverwenden, nur eben mit einem 2. AVR das Datenpaket 'belauschen' die Werte entsprechend auswerten/rausfiltern und auf LCD ausgeben. Problem für mich ist, wie programmiere ich den AVR dass er aus der gezeigten Art der Bits ein High oder Low erkennt. Bascom würde ich dafür benutzen. Die Bits haben ja keinen 'normalen' Zustand während der 25us, sondern die Länge des High Zustands unterscheidet zwischen 1und 0.
Gerd J. schrieb: > Die Bits haben ja keinen 'normalen' Zustand während der 25us, > sondern die Länge des High Zustands unterscheidet zwischen 1und 0. Genau das ist dein Ansatzpunkt. Mit der steigenden Flanke startest du den Timer und wartest bis die Flanke wieder fällt. Ist die Zeit 38µs, hast du das Startsignal. Ist die Zeit grösser als 16µs und kleiner als 20µS hast du eine 0, ist sie länger als 5 und kürzer als 9µs, ist es die 1 (Das ist aber reine Definition, man kann auch umgekehrt agieren) Roll die Bits in einen Buffer und übergib sie an die Anzeige (z.B. als 11 Bytes), wenn du das Startsignal bekommst.
:
Bearbeitet durch User
Leider habe ich von Timer Programmierung nicht sooooo viel Ahnung :-( Codeschnippsel am besten in Bascom währen sehr hilfreich.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.