Hier sind zwei CAN-Knoten auf dem Steckbrett aufgebaut (geflasht mit der can-lib von Florian Greif) und 160m Kabel dazwischen geklemmt. Erste Tests. Beide Knoten (328p, MCP2515, MCP2561) sind über UART (Fleury) an je einen FTDI verbunden - beide USB gehen an denselben Rechner, auf dem zwei Konsolen offen sind - je eine verbunden an einen FTDI. So kann man in die eine Konsole tippen, in der anderen empfangen: int main(void) { cli(); uart_init(UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU)); io_init(); sei(); if ( can_init(4)) //10kBAUD @ 1MHz { PORT_DBGLED |= (1 << P_DBGLED1); // LED löschen // (some) filter is necessary! can_filter_t filter = { .id = 0, .mask = 0, .flags = { .rtr = 0, .extended = 0 } }; can_set_filter(0, &filter); } can_t msg; msg.id = 0x123456; msg.flags.rtr = 0; msg.flags.extended = 1; while(1) { c = uart_getc(); if (!(c & UART_NO_DATA)) { msg.length = 1; msg.data[0] = (char) c; can_send_message(&msg); } if (can_check_message()) { can_t rec_msg; // Try to read the message if (can_get_message(&rec_msg)) { uart_putc(rec_msg.data[0]); } } } } (tja, Formatierung verpfuscht, was solls) Beide CAN-Controller sind momentan nur mit 1 MHz Takt per CLKOUT vom Atmega versorgt, da (zumindest auf dem Steckbrett) der 16Mhz Kristall (zwar am Atmega, aber) nicht am MCP anschwingt. Quarz vorerst komplett entfernt und beide 328p mit 1 MHz getaktet per int. OSC 8MHz + CKDIV checked, der dann über CLKOUT den MCP2515 mit Takt versorgt. Baudraten: CAN: 10kBaud (konservativ, aber viel Spiel ist bei 1Mhz eh nicht) UART: 4800 Baud (passt nicht perfekt, aber mit 0,2% mismatch akzeptabel) Der Fleury UART hat 32 Byte Puffer (TX, und RX). Jetzt hab ich einen der zwei FTDI vom PC abgeklemmt, und in den Raspi gesteckt. Am Raspi die Baudrate eingestellt: sudo stty 4800 -F /dev/ttyUSB0 Kann man also jetzt auf der Raspi Konsole sowas eingeben wie: echo a >> /dev/ttyUSB0 und ein "a" erscheint auf der Konsole am PC, so wie gedacht. Beispielsweise ein echo abcdefghijklmn >> /dev/ttyUSB0 gibt aber perfekt reproduzierbar jedesmal nur: acbjnf aus. Nimmt man die 160m Kabel raus und verbindet direkt: dasselbe Ergebnis. Lässt man das CAN-Knäuel komplett raus und verbindet die beiden FTDIs (RX-TX) direkt, dann ist die Ausgabe korrekt. Also CAN das Problem (Firmware inklu, offensichtlich ;) ). Wenn der Raspi auf UART nur mit 4800 Baud darf, es zusätzlich FIFO Buffer mit 32 Byte für RX und TX bei Fleury gibt, und das bei (ja: ausreichend schnellem) 10kBaud CAN für dieses Szenario, dann liegt das Problem vermutlich doch nicht am CAN Layer, sondern in der Software? Die 10kBaud mögen nicht schnell genug sein, weil ein CAN Frame doch mehr aufträgt, als ein 4.8kBaud Uart Frame. Aber es sind ja nur 14 Bytes gesendet worden. Selbst beim Senden von "abc" gibt es schon "acb" in der Konsole. Ich kann vieles probieren, aber vielleicht hat jemand schon direkt Plan, was Phase ist?! (wer hier Schaltplan einfordert ist Troll)
ein CAN Frame hat normalerweise "nur" 8 Byte Nutzdaten, könntes es damit ein zusammenhang haben ???
Im Bespiel wird nur 1 Byte Nutzdaten verschickt, also jeder Charakter einzeln. Und es wird übrigends extended CAN-ID benutzt --> also maximaler Overhead. Aber ist ja nur ein Test. Im Fall abc-->acb überholt das b also das c. Das ist ein Szenario, dass man sich bei CAN vorstellen kann (sende abcb, das erste b überträgt fehlerhaft und wird wiederholt gesendet?!). Ich probier später mal eine kleinere UART Baud.
Eine Baud hatte ich vergessen: SPI zum MCP2515. Stand noch auf Prescaler 32 (eben auch konservativ). Steht nun auf 2. Aber zu langsam für den UART war SPI dann wohl trotzdem nicht. Glaub langsam, dass dieses hier das (oder ein) Problem ist, auf der Empfangsseite: if (!(c & UART_NO_DATA)) { msg.data[0] = (char) c; can_send_message(&msg); } --> also UART füttert schneller, als CAN senden kann Wahrscheinlich gibts deshalb auch das Protokoll im CAN Bootloader bei Kreatives Chaos (den ich noch verwenden will), das auf die Reihenfolge der zu sendenden/empfangenen Pakete Acht gibt. Gut, dann muss man wohl doch etwas weiter ausholen. Das schau ich mir mal an. Ja ok, bin geläutert. War wohl doch etwas schnell geschossen. Einziges Szenario für seriell über CAN-Tunnel wäre ja ohnehin das Übertragen des Hex-Files beim Flachen. Ich weiss, die mickrigen Baudraten momentan sind noch nicht optimal. Aber funktionieren sollte es damit ja prinzipiell auch. Wenn mal der 16MHz Quartz anschwiegen würde am MCP. Ich warte da noch auf die Platinen, um vom Steckbrett wegzukommen.
Oha, habs per Hardware erstmal gelöst. Der Quarz schwingt wohl doch (warum auch nicht?) am MCP. Allein, ich konnte es nicht detektieren. Per Oszi gings nicht (Spieloszi am MCP CLKOUT), und can-lib wollte zu dem Zeitpunkt gleichzeitig auch noch debugged werden (nein, nicht die Lib selbst - meine Anwendung derselben). Hab jetzt beide MCP mit 16 MHz getaktet und die beiden 328p mit 8 MHz vom internen RCO. CAN Baudrate auf 50Baud hochgesetzt (geht ja jetzt) und UART 9600 spendiert. Dann ist CAN schneller als UART, so dass nichts mehr verschluckt wird. Alphabete am Stück senden ist jetzt kein Thema mehr. Halleluja...
can-lib schrieb: > CAN Baudrate auf 50Baud hochgesetzt (geht ja jetzt) > und UART 9600 spendiert. Dann ist CAN schneller als UART, ein k vergessen?
noch Update: momentan wieder beide FTDI am PC. Für 50kBaud CAN lassen sich prima Textfiles auf die Konsole übertragen. Aber nur in eine Richtung. In die andere hängt es deutlich. Auf 100kBaud gegangen. Erste Richtung immernoch perfekt. Andere Richtung nicht, aber hängt deutlich weniger. Immerhin komme ich jetzt auf Speed. CAN Verbindung von "direkt" (=10cm Leitung) wieder geändert und die 160m Leitung eingehängt. Alles identisch. Prima. Naja, in eine Richtung gehts super. Da kann ich mal beruhigt schlafen gehen. Die andere Richtung --> es ist immer noch Steckbrett... als nächstes kann es an den Bootloader gehen denke ich. Noch die 9600Baud für UART gecheckt: sollten auch 0,2% Fehler sein, also Ok.
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.