Hallo, ist der AT90CAN128 stark genug um Daten eines 500kbit CAN Busses auszuwerten? ich möchte in einer bestimmten nachricht ein paar sensorwerte auslesen und per UART ausgeben. der sensor arbeitet mit 15 hz und gibt pro abtastung 200 nachrichten aus. die 200 nachrichten haben alle die gleiche ID aber im datenpaket gibt einen eindeutigen identifier den ich suche und der dann den gewünschten datensatz markiert. wenn ich diese nachricht gefunden habe, muss ich nur den wert umrechnen und per uart ausgeben. es sollten 15 hz ausgabefrequenz erreicht werden. gruß Patrick
Hallo Patrick, ich habe so etwas auch schon einmal ausprobiert. Wenn 15Hz * 200 Werte mögliche 3000 Botschaften pro Sekunde ergeben, dann liegt deine Buslast bei gschätzten 80-90%. Bei 500kBaud sind max. ca. 3300 8DatenbBytes - CAN Botschaften möglich. Wenn die ID nicht wechselt, könnte der AVR das schaffen. Aber wie sendest Du die Daten raus? Als Rohdaten? - Dann wären auf 0x00 Bytes bei der UART möglich. Damit haben die meisten Programme Probleme und brechen ab. ODer es fehlt dann etwas. Ich vermute jedoch, dass Du die CAN-Daten bereits im AVR textlesbar umwandeln möchtest. Und das kannst Du bei der Datenrate vergessen. Denn die UART für Terminalanwendungen funktionieren bis 115kBaud recht stabil. Darüber hinaus habe ich selbst mit UART2USB-Konvertern häufig BLuescreen auf dem PC gehabt. Ich habe diesen Weg nicht weiterverfolgt. Vielleicht mag es auch am Treiber der Brücke gelegen haben. Aber die Daten über UART zu senden ist nicht anspruchlos. Vielleicht beschreibst Du Dein VOrhaben noch einmal genauer.
Hallo Patrick, ich habe einen AT90CAN128 mit 16 MHz der einen CAN-BUS mit 1Mbit überwacht, zusätzlich hat dieser noch viele andere Aufgaben (ADC, Tasterabfrage, berechnungen,...) und packt das locker. lt- Datenblatt muss der AT90CAN128 mit min. 8MHz getacktet werden um diese Datenraten bei CAN verarbeiten zu können
Hallo cskulkw , Hallo Hugin, das klingt ja schon mal nicht schlecht wenn 1mbit schon erfolgreich "überwacht wurde". der Sensor liefert 15 mal die Sekunde alle Sensorwerte. Leider wird jeder Sensorwert in der gleichen Botschaft verschickt, genauer gesagt das Botschaftspaar: MSG ID 0x7a1 und 0x7a2 dieses Paar kommt also pro abtastung 100 mal 0x7a1 data 0x7a2 data 0x7a1 data 0x7a2 data 0x7a1 data 0x7a2 data 0x7a1 data 0x7a2 data USW... danach ein paar andere uninteressante nachrichten und es geht wieder von vorn los. es wird mit 15 Hz abgetastet, PEAK Can meldet >90% Busload. "data" ist folgender maßen aufgebaut: [SensorNummer, Rohwert, andere Daten...] ich bin nur an bestimmten Sensorwerten interessiert, beispiel "10" und "11". d.h. ich muss das Datenpaket der Botschaftspaare anschauen und 10 und 11 finden. Dort sind dann weitere Daten drin (Rohwert) die ich umwandeln möchte und über UART bei 38400 baud 8N1 in einem lesbaren format sende. die datenrate auf seitens UART sollte passen, denn 15 mal pro sekunde 2 Sensorwerte solten kein problem sein. Aber das anschauen der CAN Botschaften etc kann ich schlecht abschätzen. ich kenne mich halt mit den 8bit Atmel teilen noch etwas aus und das programmieren ging immer ganz gut, aber das war bislang nur UART; SPI; ADC; und die neueren ARM Cortex usw sind halt doch etwas aufwändiger...
Hallo Patrik, also mußt Du nach den CAN-IDs 0x71 und 0x72 suchen lassen. Wenn Dich die anderen Botschaften nicht interessieren, schaltest Du dafür 2 MOBs (Message Objekte) auf Empfang. Dabei solltest Du die Filter (Maskierung) genau auf diese Addressen einstellen, damit die Hardware den nicht notwendigen Traffic auf dem CAN filtert. Sollen als Konsequenz 15 * (1/sec) * 100 Botschaften überprüft und ggf. in ASCII-Strings umgewandelt und über UART gesendet werden? Wie viele Datenbytes enthält "data" (3 oder 8?) Solltest Du den Anpruch haben im Extremfall 1500 Sensorwerte auszufiltern und den String über UART auszugeben, wird es nicht funktionieren. Wenn pro Sensorwert "nur" 10 Bytes (incl. CR = 0Dhex(mit LF = 0Ahex?)) gesendet werden sollen, werden 10 Bytes * 10 UART-Bits benötigt (Startbit, 8 Datenbits, Stopbit) entsprechend 100 Bits fällig werden. Bei der Baudrate von 38300 Baud kannst Du dann max. 383 Sensorwerte pro Sekunde ausgeben. Wenn Du schlank programmierst und Dich bei der Konvertierung auf das Notwendige beschränkst, könnte der AT90CAN bei einer Baudrate von 115kByued entsprechend 1150 Sensorwerte konvertieren und senden. Das Schwierige beim AT90CAN ist der indirekte Zugriff auf die MOB-Register. Du mußt bei zwei IDs über das Register CANPAGE ständig je nach Interruptauslösung, das man in CANSIT herausfindet, den Zugriff im CANPAGE einstellen. Erst dann hast Du Zugriff auf die MOB-Datenregister. Bei 2. ID ist das noch machbar. Bei 15 nicht zusammenhängenden IDs hast Mega so tun, dass ihm Botschaften durchrutschen. Ich habe deshalb mit dem MCP2515 weiter gemacht. Für anspruchsvollere Aufgaben ist der AT90CANxxx zu umständlich in der Handhabung. Wenn Deine CAN-IDs zusammenhängen. 0x71 und 0x72 dann brauchst Du u. U. nur ein MOB und stellst den Filter CANIDM(1-4) auf 0x03FE ein. Das heißt die HW filtert nur die Bits des Identifiers größer gleich 2 heraus. Dann würdest Du bei jeden Interrupt entweder die Daten aus 0x71 oder 0x72 vorfinden. Weil Du sowieso in den Daten das Entscheidungskriterium hast, sollte die ISR knapp programmiert werden können und somit schnell sein. Die UART-Baudrate wird dann ggf. der Flaschenhals werden. Da mußt Du mal schauen. Ich versuche gerade den AVR32UC3Cxxx CAN-techisch zum laufen zu bekommen. Das Ding ist trotz Framework sehr umfangreich zu konfigurieren und das Debugging läuft noch nicht so gut wie bei den kleinen. Mit den kleinen AVRs kommt man eben schneller zum Ziel. Ich denke der ARM wird Dich nicht viel glücklicher machen. Viel erfolg
jo danke, also "Data" enthält immer 8 Bytes. das erste Byte enthält die Sensornummer. die restlichen 7 Bytes sind Sensordaten. wenn 0x71 gefunden wurde mit der Sensornummer "10" dann folgt direkt danach 0x72 ebenfalls mit Sensornummer "10". Von beiden Nachrichten sind dann jeweils die restlichen 7 Datenbytes interessant. Pro Abtastung sind es nur 2 Sensorwerte die ich über UART ausgeben möchte. Also 15 mal 2 Sensorwerte pro Sekunde, wobei eine Nachricht 8 Bytes enthalten wird. Also 15 2 8 Bytes. Das sollte kein Problem sein für die UART... :) "Weil Du sowieso in den Daten das Entscheidungskriterium hast, sollte die ISR knapp programmiert werden können und somit schnell sein." tja ich denke das muss ich jetzt einfach versuchen. in dem Artikel hier: http://www.mikrocontroller.net/articles/CAN_Bibiliothek_für_AT90CAN_Prozessoren sehe ich alerdings schon ein kleines problem: anscheinend muss man was an der UART sache Ändern, Stichwort: keine "busy-wait" Warteschleifen "Ich habe deshalb mit dem MCP2515 weiter gemacht. Für anspruchsvollere Aufgaben ist der AT90CANxxx zu umständlich in der Handhabung." das hört sich sehr interessant an. außerdem kenn ich mich in SPI besser aus. da gibts auch schöne beispiele an die ich mich halten kann: http://www.kreatives-chaos.com/artikel/can-testboard ein kleines Testboard habe ich hier mit einem ATMeg644 @ 20Mhz. da könnte ich einen MCP2515 dranhängen, oder was meinst du? so wie ich das sehe ist das die einfachere / erfolgsversprechendere lösung...
Hi Patrick, also, wenn Dir SPI keine Schwierigkeiten bereitet, nimm den. Bei Microchip kannst Du noch die DIL16-Chip als kostenlose Muster bekommen. Die spendierten bisweilen 5 für lau. Also, beim MCP hast Du den Vorteil, dass Empfangs- und Sendemailboxen physikalisch getrennt sind. Außerdem kannst du die beiden Empfangsboxen als FIFO schalten. Das nennt sich Rollover. Wenn Dein AVR noch nicht die 1. auslesen konnte, schwappt eine eintreffende CAN-Botschaft einfach in die 2. und geht so nicht verloren. Die Maskierung ist beim MCP ein wenig anders als beim AVR. Ich habe den Taktausgang zum Treiben des MCPs genommen. Außerdem kannst hast Du jeweils für RXB0 und RXB1 eine Interruptleitung, die mit dem Oszi (oder LED oder was auch immer) gecheckt werden kann. Muß jedoch konfiguriert werden, sonst funktionieren sie nicht. Aber das wirst Du dann schon rausfinden. Total klasse finde ich die SPI-1-Byte-Befehle. Also, Du mußt beim RXB0-Interrupt nicht umständlich jedes einzelne Register mit Addresse auslesen, sondern, Du kannst ein Kommando-byte "gebe mir den Inhalt als RXB0/1 mit oder ohne ID", 0x61 und 0x71 bzw. 0x66 und 0x76 glaube ich. Danach brauchst Du nur 0-Bytes schreiben und bekommst die ganzen Registerinhalte gemäß Registerlayout ausgespuckt. Und wenn so brav die Daten ausgelesen worden sind, löscht der MCP sogar selbsttätig die Interruptleitung, weil die Befehle mailboxzugehörig sind. Übrigens fällt mir noch ein, dass Du sogar im MCP in den Daten eine Vorplausibilisierung durchführen lassen kannst. D. h. (ich habe es nur gelesen), dass Du die Prüfung auf die 10 hex in den Daten der MCP machen kann. Das bräuchte u. U. Deine AVR - SW nicht mehr machen. Wär doch cool oder? Möglicherweise setzt er dann erst auch die Int-Leitung. Thema Busy-Wait ... (Synchronisation) Ja, darunter verstehe ich mehrere autarke Aufgaben asynchron auf einer Maschine zu beherrschen. Entweder kannst Du garantieren, dass in den Informationslücken der Sensorwerte nichts zu berücksichtigen ist, dann kannst Du alles prozedural abwickeln und warten solange es dauert, oder Du mußt parallele Prozesse einführen. Das Thema wird hier im Forum in den Programmbeispielen sehr stiefmütterlich behandelt. Darum schreibe ich mir meine Treiber selbst, weil diese dann multitaskingfähig sind und auf grund von Timings nicht andere Tasks blockieren. Außerdem weis man dann, warum man etwas macht. Ist allerdings der langwierigere Weg. So, noch mals viel Spaß und Erfolg
vielen Dank, das hilft mir sehr gut weiter. Bis ich die Hardware habe, dauerts noch etwas, ich werde aber über den Fortschritt berichten.
Ich kann von dem MCP nur abraten! Der hat doch viel weniger MOBs als der AT90CAN.... Ich habe den MCP aus allen Designs rausgeworfen, weil es mit dem AT90CAN viel komfortabler geht...
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.