Hallo, ich bin dabei mir eine Schaltung aufzubauen die alle Nachrichten vom CANBus zum PC Senden. Bisher habe ich versucht per UART die daten zum PC zu senden. Allerdings ist mir jetzt aufgefallen das die übertragung bei einem 500kbit/s bus viel zu langsam ist. Gemessen habe ich mit meinem Logicanalyzer bei einer UART Geschwindigkeit von 115200 bit/s: und einer Datenmenge von 104 kbit = 1,145s einer Datenmenge von 520kbit = 5,721s Natürlich bremst die Übetragung das ganze. Da kann ich auch mit einem Buffer oder ähnliches nichts machen? oder kann ich die Daten Komprimieren? Was kann ich jetzt tun? die max. geschwindigkeit von uart beträgt ja gerade mal 115,2 kbit?
kevin mitn schrieb: > die max. geschwindigkeit von uart beträgt ja > gerade mal 115,2 kbit? Sagt wer? 1MBit habe ich auch schon ohne Problem geschafft. Also wenn du mit 1MBit sendest schaffst du das. Ingo
Am uC kein Problem. Der PC der das Ganze empfangen soll muss diese Baudrate aber erstmal unterstützen.
Die ankommenden daten möchte ich dann anhand von einem Programm (kein Terminal), dass ich mit VB schreibe, auswerten. Bei dem MSComm Objekte kann ich keine höhere Baudrate einstellen. Glaub schon öfter gelesen zu haben das die 115,2 kbit der Standart am PC für den UART sind?
Naja. Abgesehen davon, dass es kaum mehr Uarts gibt. Jetzt hat man USB-to-serial, und die koennen 1Mbit. Sonst sollte man auf Ethernet gehen, aber nicht mehr mit einem kleinen AVR, sondern mit einem AVR32UC3 oder so
wenn das vb-programm der flaschenhals ist: ersetz das programm durch eines, das höhere baudraten unterstützt. wenn die serielle kommunikation der flaschenhals ist: spendier dem µC genügend speicher für einen puffer und schick die daten so schnell wie möglich zum pc. alternativ kannst du auch über eine andere technologie nachdenken. wenn der flaschenhals woanders ist: such ihn, dann gibts vielleicht auch tipps wie du damit umgehst. wenn der flaschenhals aus mehreren teilen besteht: wäg für dich ab, wo du am leichtesten ansetzen kannst und wiederhole die oben genannten schritte...
Also ein FTDI sollte bis ca 1MBaud gehen, d.h. damit solltest du, wenn du nirgendwo anders einen Flaschenhals hast, genug Speed kriegen Auch wenn ich erstmal eine serielle Schnittstelle am Motherboard vorziehen würde, wenn die da hinterher kommt
Dann löt dirn FT232RL aufs Board und nutz die D2XX Treiber -> schwupps sind auch mal eben 2MBaud drinne.
Habe nun nochmal darüber nachgedacht. Den Standart UART zu nutzen, funktioniert wahrscheinlich nicht. In meinem PC ist ein 16550A UART verbaut und den kann ich max auf 115k2 einstellen. Ich habe herausgefunden das es mit zusätzlicher Hardware sprich PCI Karten oder ähnliches möglich ist eine höhere Baudrate über UART zu erreichen. Aber das erscheint mir nicht der richtige weg zu sein. @Ingo: wie hast du es gemacht 1Mbit über UART zu übertragen? Ein FIFO oder allgemein Buffer zu verwenden hab ich auch überlegt. Aber kann sein das der dann ständig überlaufen wird wenn die Daten fast 5x schneller ankommen als sie wieder verschickt werden können? Denke das die Daten vom CAN ziemlich kontinuierlich vom bus kommen und so keine größere Pause bleibt den buffer wieder zu entleeren. Bleibt nurnoch die möglichkeit extra Hardware für meine Platine zu bauen. Also die FTDI. Muss mich da aber erstmal schlau machen wie das genau funktioniert. Schade ist bei der Möglichkeit dann nur, dass ich das BTM222 Modul für die höhere Datenrate nicht mehr nutzen kann. Bei dem Modul kann ich zwar bis 921600 kbits einstellen, aber der Dongle kann nur wieder bis 115k. Vielleicht gibt es da einen anderen Treiber was ich aber nicht glaube.
kevin mitn schrieb: > Ein FIFO oder allgemein Buffer zu verwenden hab ich auch überlegt. Aber > kann sein das der dann ständig überlaufen wird wenn die Daten fast 5x > schneller ankommen als sie wieder verschickt werden können? Denke das > die Daten vom CAN ziemlich kontinuierlich vom bus kommen und so keine > größere Pause bleibt den buffer wieder zu entleeren. Ist denn auf dem CAN wirklich pausenlos Aktivität? Dass die Daten da mit 500kbit/s drüber rauschen ist ja erstmal nur für den Empfangsteil relevant, das muss mithalten können. Sobald in deinem CAN Controller ein Frame da ist, liest du es aus und bläst es auf die UART mit "gemütlichen" 115kbit/s raus. Parallel dazu kann der Controller schon wieder ein Frame einlesen usw. Mit etwas mehr RAM kannst du auch einige CAN Frames zwischenspeichern und hast nicht gleich Datenverlust, wenn die UART nicht nachkommt. Oder du setzt einen MC mit native CAN ein, dann geht das etwas eleganter. Und wenn das nicht mehr hilft, einen mit CAN & USB native. (edit: hab vom Transceiver gesprochen, sollte aber der Controller sein)
Ein FT232R von FTDI kann bis 3Mbaud. Bei den ATMegas hängt es vom verwendeten Quarz ab. Bei 16MHz wären das 2Mbaud. Beim FTDI funktioniert die Geschwindigkeit sowohl über VCP wie auch über D2XX. Die FTDI gibts auch direkt als fertiges Kabel bzw. als Adapter. Musst an deiner Platine also nix ändern.
Martin Wende schrieb: > Dann löt dirn FT232RL aufs Board und nutz die D2XX Treiber -> schwupps > sind auch mal eben 2MBaud drinne. Genau so gehts. FTDI for RS232-President :)
Hallo nochmal an alle. ich muss mich nochmal melden, in letzter Zeit sind viele fragen bei mir aufgetaucht die ich los werden muss. Ich habe mir den FT232RL gekauft und ihn an meine Platine wie im datenblatt unter "USB Bus Powered" und "USB to MCU UART Interface" angeschlossen. RTS und CTS sind nicht beschaltet. Die Kommunikation funktioniert. Senden und Empfangen auf 921,600k eingestellt. So jetzt mein Problem: Anschneinend arbeitet USB bzw der ft232rl chip nur dann richtig wenn statt einzelnen bytes, größere Datenpakete gesendet werden, richtig? Muss ich dazu einfach in einem bestimmten Zeitfenster die einzelnen bytes über uart wie gewohnt schicken und der FT232RL erledigt den rest von selbst (Solange warten bis der Speicher voll oder zeit abgelaufen?) Mein nächstes Problem: Ich stelle mir das so vor, dass wenn eine Nachricht am MCP2515 eintrifft ein Interrupt ausgelöst wird. Danach hole ich mir die Nachricht und Speicher diese in einer struct "CANMessage" (funktioniert soweit gut). Als nächste zeige ich die Nachricht auf dem LCD an und möchte sie dann über UART/USB senden. Natürlich dauert die anzeige auf dem LCD wahrscheinlich zu lange währendessen der nächste Interrupt für neue Nachricht ausgelöst wird und es zum durch einander kommt. Wie kann ich das Problem lösen? Kann ich das Problem mit einem FIFO lösen, der solange nachrichten aufnimmt bis zeit vorhanden ist alles "auf einen Rutsch" zu versenden? und wie funktioniert der FIFO dann eigentlich mit Strukturen? Vll kann der ein oder andere mir etwas Licht ins Dunkel bringen.
kevin mitn schrieb: > Hallo nochmal an alle. > Anschneinend arbeitet USB bzw der ft232rl chip nur dann richtig wenn > statt einzelnen bytes, größere Datenpakete gesendet werden, richtig? > Muss ich dazu > einfach in einem bestimmten Zeitfenster die einzelnen bytes über uart > wie gewohnt schicken und der FT232RL erledigt den rest von selbst > (Solange warten bis der Speicher voll oder zeit abgelaufen?) siehe Antwort von Abdul K., aber verloren gehen sollten keine Bytes! > Mein nächstes Problem: Ich stelle mir das so vor, dass wenn eine > Nachricht am MCP2515 eintrifft ein Interrupt ausgelöst wird. Danach hole > ich mir die Nachricht und Speicher diese in einer struct "CANMessage" > (funktioniert soweit gut). ok > Als nächste zeige ich die Nachricht auf dem > LCD an, du machst dir Sorgen über deine Geschwindigkeit am UART und willst die Daten auch noch an einem LCD anzeigen?? Das passt ja nun gar nicht zusammen! > und möchte sie dann über UART/USB senden. Natürlich dauert die > anzeige auf dem LCD wahrscheinlich zu lange währendessen der nächste > Interrupt für neue Nachricht ausgelöst wird und es zum durch einander > kommt. > > Wie kann ich das Problem lösen? Kann ich das Problem mit einem FIFO > lösen, der solange nachrichten aufnimmt bis zeit vorhanden ist alles > "auf einen Rutsch" zu versenden? und wie funktioniert der FIFO dann > eigentlich mit Strukturen? du kannst dir einen FIFO bauen, indem du die Strukturen in ein Array packst, wenn ich mal davon ausgehe, das die CANMessage's nicht alle gleich lang sind, das ist natürlich Speicherverschwendung, da die Struct ja immer die größte Message aufnehmen können muss. Besser währe es die Message's so wie sie kommen in einer Art Ringpuffer zu speichern, dann wird nur soviel belegt wie nötig und der puffer kann abhängig von der Nachrichtengröße mehr oder weniger viel aufnehmen. Solange Daten im Puffer sind werde die über UART versendet, optimal ist hier auch beim Senden Interruptgesteuert zu arbeiten. Nun zum Display: wenn du alle Nachrichten anzeigen willst, kann ich Dir auch nicht helfen - du kannst ja die Nachrichten auch gar nicht so schnell lesen wie neue kommen. Ein Filter auf bestimmte Nachrichen währe ja noch denkbar. Sascha
kevin mitn schrieb: > Als nächste zeige ich die Nachricht auf dem > LCD an und möchte sie dann über UART/USB senden. Natürlich dauert die > anzeige auf dem LCD wahrscheinlich zu lange währendessen der nächste > Interrupt für neue Nachricht ausgelöst wird und es zum durch einander > kommt. Das hört sich so an, als ob du dir echte Chances ausrechnest, die komplette Bibel innerhalb von 2 Minuten lesen zu können. Nur dann macht es Sinn, den ganzen Kram aufs Display zu schieben.
Guten Morgen... Danke für eure Antworten, bis auf die letzte die für dieses Thema etwas irrelevant ist. Hab nochmal nachgedacht und meine Idee mit alle Nachrichten auf dem LCD anzeigen zu lassen überdacht. Es sind zuviele Nachrichten mit dennen ich, ohne sie zu sortieren, sowieso nichts hätte anfangen können. Habe gestern das Ausgeben auf dem LCD aus meinem Programm entfernt und sende jetzt die Messages direkt zum PC. So funktioniert es jetzt auch ohne das ich einen Buffer Overflow Fehler vom MCP bekomme. Glaube aber das die Bus Auslastung nicht auf 100% ist. Also rein theoretische können bei 500kbit/s, 3864 Nachrichten in der Sekunden (bei CAN 2.0A und maximalen 8 Datenbytes) übertragen werden, richtig? Soviele Nachrichten hab ich jetzt nicht empfangen, aber ich denke das auch keine verloren gegangen ist. Sonst hätte wahrscheinlich der MCP ein Fehler Flag gesetzt denke ich mal.
Bitte 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.