Hallo, folgendes Problem.. Ich bin gerade dabei, eine große Anzeige mit 64x8 LEDs zu realisieren, als Projekt in der Schule zu Lernzwecken. Ich möchte nun eine Datenkommunikation zwischen dem µC (Atmega644) und dem PC herstellen, hierfür habe ich auf der Platine einen MCP2200 vorgesehen, da dieser bei uns in der Schule sonst auch vorkommt. Jetzt ist es so, dass ich noch so meine Probleme habe, wie ich die Verbindung aufbaue. Ich habe mir vorgestellt, ein C++ Programm am PC über den virtuellen COM Port mit dem µC kommunizieren zu lassen. Es würde schon reichen, wenn der PC nur Daten zum µC senden kann. Ich habe nun gelesen, dass es HID gibt, um keine Treiber installieren zu müssen, sondern die Systemeigenen genommen werden können. Kann ich das mit dem MCP2200 realisieren? Gibt es irgendwelche Bibliotheken für den MCP2200 für den Datenaustausch oder wird das einfach mit "normalen" Befehlen über den COM Port geschickt? Grüße und schönen Abend, reindo
Hast Du den denn mal an den USB-Port gesteckt? Im Datenblatt steht nämlich:
1 | Uses standard Microsoft® Windows® drivers for Virtual Com Port (VCP) |
Guten Abend, nun derzeit ist die Platine noch in der Herstellung, sodass ich das noch nicht testen kann. Unsere Testboards der Schule jedoch (MCP2200, Atmel C51) laufen garnicht ohne Treiber von MCP. Möglicherweise liegt es daran, dass in der Schule noch XP im Einsatz ist? Habe es unter neueren Systemen noch nicht testen können - erst wenn die Platine dann hier ist. Wollte mich nur schonmal vorbereiten und mir überlegen, wie ich es angehen soll. Aber ich denke, ich schiebe es mal auf und warte bis die Platine da ist. Nun aber zur anderen (wichtigeren) Frage, wie das mit dem Datenaustausch ist.. Ich weiß, dass man über die Verbindung Daten Byteweise übertragen muss. Ist auch kein Problem meine Daten so hinzuwursten. Nur wie genau sende ich denn Daten und Empfange diese, muss ich dies beim µC irgendwie vorbereiten oder wird das dann via Interrupt autonom empfangen? Grüße
Dominik Rein schrieb: > Nur wie genau > sende ich denn Daten und Empfange diese, Am PC benutzt du dafür ein Terminalprogramm, wie HTerm oder HyperTerminal und stellt es auf den Virtual Comport ein, denn der MCP enumeriert hat. Den kannst du im Gerätemanager sehen. Dominik Rein schrieb: > muss ich dies beim µC irgendwie > vorbereiten oder wird das dann via Interrupt autonom empfangen? Autonom geht nichts, wenn du den Mikrocontroller nicht so programmierst, das er seine serielle Schnittstelle (meistens UART genannt) zur Kommunikation benutzt. Der MCP2200 wird also die USB Kommunikation schon in serielle Signale umsetzen, aber der angeschlossene MC muss diese Daten dann auswerten und evtl. auch welche senden.
Dominik Rein schrieb: > Ich habe nun gelesen, dass es HID gibt, um keine Treiber installieren zu > müssen, sondern die Systemeigenen genommen werden können. Kann ich das > mit dem MCP2200 realisieren? Für den MCP2200 brauchst Du wie für alle CDC-ACM Devices nur ein passenden .inf, aber keinen extra Binärtreiber. Der systemeigene reicht. Bei XP ist SP3 Pflicht, aber das ist es ja ohnehin aus Sicherheitsgründen. HID ist nur fürs Bitbanging der Ports da. Da der MCP2200 nur ein vorprogrammierter PIC18F14K50 ist, kannst Du natürlich auch ein PICKIT3 dranhängen und mit der Microchip Application Library eine eigene Applikation basteln, die HID auch für den Datentransfer benutzt. Wenn Du dann so weit bist, wirst Du einsehen, dass es schlauer ist, Deinen Atmega gegen einen PIC18F46K50 oder PIC18F46J50 zu tauschen, um den extra USB-Chip einzusparen. > Gibt es irgendwelche Bibliotheken für den MCP2200 für den Datenaustausch > oder wird das einfach mit "normalen" Befehlen über den COM Port > geschickt? nix spezielles. CDC-ACM Devices werden wie COM-Ports behandelt, Custom HID Device sprichst Du per setupapi.dll und hid.dll an. fchk PS: Wenn Du keine Handshake-Leitungen brauchst, kannst Du auch den MCP2221 verwenden. Das ist ein vorprogrammierter PIC16F1455. Vorteil: billiger und braucht für den USB-Betrieb nicht zwingend einen Quarz. Für USB ist der PIC16F1455 und der PIC16F1454 (ohne Analogfunktionen) die billigste Möglichkeit, ein komplett USB 2.0 standardkonformes, zertifiziertes Full-Speed Device (also nicht dieser VUSB-Müll) zu bauen. Ein ATTiny 85 ist nur wenige Cents billiger, aber nicht 100% standardkonform und nur low-speed.
Matthias Sch. schrieb: > Am PC benutzt du dafür ein Terminalprogramm, wie HTerm oder > HyperTerminal und stellt es auf den Virtual Comport ein, denn der MCP > enumeriert hat. Den kannst du im Gerätemanager sehen. Sprich das kann mein C Prog dann auch. Muss ich mich also weiter schlau machen. > Autonom geht nichts, wenn du den Mikrocontroller nicht so programmierst, > das er seine serielle Schnittstelle (meistens UART genannt) zur > Kommunikation benutzt. Der MCP2200 wird also die USB Kommunikation schon > in serielle Signale umsetzen, aber der angeschlossene MC muss diese > Daten dann auswerten und evtl. auch welche senden. AFAIK kann der Txd und Rxd einen Interrupt generieren, sprich ich sende vom PC ein "Wach auf" und der µC springt in die ISR, in welcher ich die Daten dann empfange? Wie ist das mit Puffer, sprich sind die ersten Daten bis er anfängt auszuwerten verloren oder wartet der PC mit dem senden, bis der µC bereit ist?
Hast du es schon mal mit der UART des µC probiert bzw wie man damit daten an den PC überträgt? Wenn dieses verstanden ist, ist die Umsetzung mit dem MCP2200 für USB denn nicht mehr ganz so schwer.
Frank K. schrieb: > HID ist nur fürs Bitbanging der Ports da. Kannst mir kurz erklären, was du mit Bitbanging meinst? > Deinen Atmega gegen einen PIC18F46K50 oder > PIC18F46J50 zu tauschen, um den extra USB-Chip einzusparen. > PS: Wenn Du keine Handshake-Leitungen brauchst, kannst Du auch den > MCP2221 verwenden. Das ist ein vorprogrammierter PIC16F1455. Vorteil: > billiger und braucht für den USB-Betrieb nicht zwingend einen Quarz. Das Problem ist das der MCP2221 nicht pinkompatibel zum MCP2200 ist und die Platine bereits in Produktion ist. Aber für zukünftige Projekte interessant - danke!
PPS: Windows 10 soll angeblich kein .inf mehr für CDC-ACM Devices verlangen. Warum die aktuellen Windows-Versionen das brauchen, verstehe ich nicht. OSX und Linux und OpenBSD kommen auch ohne aus, da funktioniert das Zeugs nach dem Anstecken einfach so. Wahrscheinlich hatte Microsoft ein NIH-Problem (Not Invented Here). Die haben ja auch RNDIS erfunden, anstelle das Standard CDC-NCM vernünftig zu unterstützen.
chris schrieb: > Hast du es schon mal mit der UART des µC probiert bzw wie man damit > daten an den PC überträgt? > Wenn dieses verstanden ist, ist die Umsetzung mit dem MCP2200 für USB > denn nicht mehr ganz so schwer. Wie meinst du das? Sprich mit nem MAX232 und "wirklich COM" übertragen? Ist ja denke ich das gleiche, nur das es via MCP2200 via USB und virtuellem COM Port läuft - oder? Kann ich also die gleichen Befehle wie hierfür nehmen?
Dominik Rein schrieb: > Frank K. schrieb: > >> HID ist nur fürs Bitbanging der Ports da. > > Kannst mir kurz erklären, was du mit Bitbanging meinst? Direkte Ansteuerung der IO-Pins des MCP2200 vom USB-Host. Siehe http://ww1.microchip.com/downloads/en/DeviceDoc/93066A.pdf
Dominik Rein schrieb: > Ist ja denke ich das gleiche, nur das es via MCP2200 via USB und > virtuellem COM Port läuft - oder? Kann ich also die gleichen Befehle wie > hierfür nehmen? Ganz genau. Wenn du mit einem MAX232 das schon mal gemacht hast, ändert sich auf der MC Seite nix, ausser das du statt dem MAX den MCP anschliesst.
:
Bearbeitet durch User
Frank K. schrieb: > Direkte Ansteuerung der IO-Pins des MCP2200 vom USB-Host. Ach, dafür sind sie GP Outputs da? Super Sache, so im Nachhinein.. Danke für den Hinweis - da wäre ich nicht so schnell draufgekommen!
Matthias Sch. schrieb: > Ganz genau. Wenn du mit einem MAX232 das schon mal gemacht hast, ändert > sich auf der MC Seite nix, ausser das du statt dem MAX den MCP > anschliesst. Ok, klingt soweit logisch. Aber eigentlich dürfte sich ja auch auf PC-/Anwendungsseite auch nicht viel ändern, bis auf eventuelle Treiber o.ä. - oder? Der COM Port existiert für die Software ja weiterhin, sie dürfte ja eigentlich garnicht merken, dass es ein virtueller ist und der MCP2200 müsste ja alles einfach wie ein MAX232 weiterreichen? Grüße
:
Bearbeitet durch User
Dominik Rein schrieb: > AFAIK kann der Txd und Rxd einen Interrupt generieren, ja > vom PC ein "Wach auf" und der µC springt in die ISR, ja > in welcher ich die Daten dann empfange? ja > Wie ist das mit Puffer, muss selbst programmiert werden > sprich sind die ersten Daten bis er anfängt auszuwerten verloren oder > wartet der PC mit dem senden, bis der µC bereit ist? jein hängt von deiner Programmierung ab, denn sollte man mit RTS / DTS arbeiten siehe http://de.wikipedia.org/wiki/RS-232 unter Verkabelung Matthias Sch. schrieb: > Dominik Rein schrieb: >> Ist ja denke ich das gleiche, nur das es via MCP2200 via USB und >> virtuellem COM Port läuft - oder? Kann ich also die gleichen Befehle wie >> hierfür nehmen? > > Ganz genau. Wenn du mit einem MAX232 das schon mal gemacht hast, ändert > sich auf der MC Seite nix, ausser das du statt dem MAX den MCP > anschliesst. Das ist richtig doch hier werden gewisse Grundlagen gelegt die es vom Verständiss her, einfacher machen würden. Warum komm ich drauf: Dominik Rein schrieb: > Nun aber zur anderen (wichtigeren) Frage, wie das mit dem Datenaustausch > ist.. Ich weiß, dass man über die Verbindung Daten Byteweise übertragen > muss. Ist auch kein Problem meine Daten so hinzuwursten. Nur wie genau > sende ich denn Daten und Empfange diese, muss ich dies beim µC irgendwie > vorbereiten oder wird das dann via Interrupt autonom empfangen? Impliziert für mich das mit serieller Datenübertragung recht wenig was gemacht wurde da die UART der Dreh und Angelpunkt ist.
chris schrieb: > Dominik Rein schrieb: >> sprich sind die ersten Daten bis er anfängt auszuwerten verloren oder >> wartet der PC mit dem senden, bis der µC bereit ist? > > jein hängt von deiner Programmierung ab, denn sollte man mit RTS / DTS > arbeiten siehe > > http://de.wikipedia.org/wiki/RS-232 unter Verkabelung Habe mir das gerade durchgelesen und sehe gerade, dass diese Anschlüsse vom MCP2200 bei mir zwar unbedrahtet, aber glücklicherweise als Lötpunkt rausgeführt worden sind. Heißt ich werte diese dann einfach aus, der PC bekommt ein RTS (Sendeanforderung) und da er weiß, dass er nicht angefordert hat, schält er auf Empfang und schickt CTS (Sendeerlaubnis) und umgekehrt?
Dominik Rein schrieb: > Ok, klingt soweit logisch. Aber eigentlich dürfte sich ja auch auf > PC-/Anwendungsseite auch nicht viel ändern, bis auf eventuelle Treiber > o.ä. - oder? Der COM Port existiert für die Software ja weiterhin, sie > dürfte ja eigentlich garnicht merken, dass es ein virtueller ist und der > MCP2200 müsste ja alles einfach wie ein MAX232 weiterreichen? So isses. Leider geht das mit den INF Dateien bei Windows ein wenig durcheinander, aber wenn der MCP Trieber erstmal installiert ist, behandelt jedes Terminalprogramm diesen COMPort so, wie einen 'echten'. Baudrate muss auch hier mit dem Empfänger ( dem MC) übereinstimmen. Dominik Rein schrieb: > Heißt ich werte diese dann einfach aus, der PC > bekommt ein RTS (Sendeanforderung) und da er weiß, dass er nicht > angefordert hat, schält er auf Empfang und schickt CTS (Sendeerlaubnis) > und umgekehrt? Ja, nennt sich Hardware Handshaking und ist im Gerätemanager für den Comport einzustellen. Das erfordert auf der MC Seite allerdings die Programmierung, fast keine UART in einem MC unterstützt das von alleine. Eine Alternative ist noch Software-Handshaking XOn/XOff. Hier sendet der überforderte Empfänger dem Sender ein 'XOFF' Code und der Sender wartet, bis er ein 'XON' Code bekommt, um dann weiter zu senden.
Dominik Rein schrieb: > Heißt ich werte diese dann einfach aus, der PC > !!!bekommt!!!! ein RTS (Sendeanforderung) und da er weiß, dass er nicht > angefordert hat, schält er auf Empfang und schickt CTS (Sendeerlaubnis) > und umgekehrt? Schau dir mal bitte das Blockschaltbild auf Seite2 an mit CTS/RTS und die Pfeilrichtung beachten. PC !!!schickt!!!! eine Sendeanforderung µC ready für Daten ? µc bekommt das RTS-Signal µC !!!schickt!!!! eine Sendeerlaubniss PC ready für Daten ? PC bekommt das CTS-Signal
chris schrieb: > PC !!!schickt!!!! eine Sendeanforderung µC ready für Daten ? > µc bekommt das RTS-Signal > > µC !!!schickt!!!! eine Sendeerlaubniss PC ready für Daten ? > PC bekommt das CTS-Signal Oh, ja das habe ich wohl verwechselt. Macht so auch mehr Sinn! Hoffe meine Platine kommt nächste Woche damit ich es mal testen kann, Bauteile habe ich schon.
Man muss halt nicht Zwangsläufig damit arbeiten(RTS/CTS) wenn man nur ein paar bytes rübertingelt. Wenn man aber doch ne größere Menge hat und man sich vielleicht noch nicht schlüssig ist wie man es später realisieren will das bei zu vielen Daten die Kommunikation kurz eingestellt wird damit der µC Zeit hat die auch weg zu schaufeln.
chris schrieb: > Wenn man aber doch ne größere Menge hat und man sich vielleicht noch > nicht schlüssig ist wie man es später realisieren will das bei zu vielen > Daten die Kommunikation kurz eingestellt wird damit der µC Zeit hat die > auch weg zu schaufeln. Also immer wieder ein paar ms warten? Danke für den Hinweis :-) Naja, schönen Abend noch, morgen gehts wieder früh los.
reindo schrieb: > Also immer wieder ein paar ms warten? Danke für den Hinweis :-) negativ. Die Empfangsunterbrechung sollte nur so lang wie nötig sein, nicht so lang wie möglich. Soll heißen bis das alle Daten auf dem RAM sind und die ISR sollte nicht länger dauern als ein BYTE zeitlich lang ist bei 1Baud(1bit/s) sollte die ISR nicht länger als 1s dauern zum abarbeiten weil dann die nächsten Bytes verloren gingen....
chris schrieb: > negativ. Die Empfangsunterbrechung sollte nur so lang wie nötig sein, > nicht so lang wie möglich. Soll heißen bis das alle Daten auf dem RAM > sind und die ISR sollte nicht länger dauern als ein BYTE zeitlich lang > ist bei 1Baud(1bit/s) sollte die ISR nicht länger als 1s dauern zum > abarbeiten weil dann die nächsten Bytes verloren gingen.... Achso, ich bin jetzt davon ausgegangen, dass der Mikrocontroller sobald er in die ISR springt solange darin bleibt, bis alles übertragen ist und der Sender ein Ende signalisiert?
reindo schrieb: > Achso, ich bin jetzt davon ausgegangen, dass der Mikrocontroller sobald > er in die ISR springt solange darin bleibt, bis alles übertragen ist und > der Sender ein Ende signalisiert? Ja das stimmt auch aber nur für 1Byte... soll heißen Bit1 wird übertragen . . . Bit8 wird übertragen und nachdem alle 8Bit empfangen wurden wird das RX-Complet-Flag gesetzt und löst damit deine ISR aus für 1byte wohlgemerkt!!!!!!!! Wenn du jetzt natürlich alles dort abhandeln willst geht das auch und könnte wie folgt aussehen: $AA Start Übertragung $FF Ende Übertragung PC sendet ein $AA damit BEGINN µc empfängt Byte, vergleicht auf $AA PC = µc Gleich: PC sendet Daten µc speichert im RAM die Daten µC vergleicht auf $FF wenn ja zu Ungleich, bei nein zu Gleich PC != µc Ungleich: ENDE ISR Das Problem ist wie möchte man vorgehen wenn die RX-ISR noch im Gange ist und andere ISR's auftauchen, möchte man die RX-ISR unterbrochen oder nicht usw usf
reindo schrieb: > Achso, ich bin jetzt davon ausgegangen, dass der Mikrocontroller sobald > er in die ISR springt solange darin bleibt, bis alles übertragen ist und > der Sender ein Ende signalisiert? Das macht man aber (normalerweise) nicht so. Denn dann ist der µC für die gesamte Zeit des Empfangs blockiert und kann nicht anderes machen - nicht mal eine andere ISR (z.B. Timer-ISR) kann (beim AtMega) ausgeführt werden. Daher würde ich empfehlen: Die RX-ISR wird angesprungen, wenn 1 UART-Zeichen empfangen wurde. Das Zeichen wird dann in einen Puffer geschrieben. Gesteuert wird alles durch das Protokoll, in dem man festgelegt hat, wie die Zeichenkette beginnt, wie lang sie ist oder wie das Ende gekennzeichnet ist. Diese Steuerung passiert auch in der ISR. Ist alles fehlerfrei empfangen wird durch einen Merker dem Hauptprogramm gemeldet, das ein kompletter Datensatz im Speicher steht. Das Hauptprogramm fragt diesen Merker ab, bearbeitet den Datensatz und gibt über den Merker den Empfang des nächsten Datensatzes wieder frei. Beispiel: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART#Empfangen_.28RX.29 Gruß Dietrich
Dietrich L. schrieb: > Die RX-ISR wird angesprungen, wenn 1 UART-Zeichen empfangen wurde. Das > Zeichen wird dann in einen Puffer geschrieben. Du kannst dir dabei noch eine Eigenart der meisten UARTs im MC zunutze machen, nämlich das sie den kompletten Empfang eines Byte nach dem ersten Stopbit melden. Wenn du die Kommunikation auf 2 Stopbits konfigurierst, hat der MC die gesamte Zeit des 2ten Stopbit zur Verfügung, um was in den (Ring-)puffer zu legen oder auf irgendwas zu prüfen. DMX z.B. macht das so, weil hier ein beinhartes Timing angewendet wird und zur Zeit der Erfindung viele Rechner noch nicht so schnell waren. XON/XOFF hat bei einer Flusskontrolle den Vorteil, das sie keine zusätzlichen Leitungen benötigt, und somit eine extra Hardware Verdrahtung entfällt.
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.