Hi! Ich schreibe an einem Softwareprojekt auf einem Texas Instruments TMS320F28335 Mikrocontroller rum. Im Rahmen dieses Projekts gehts auch drum, einige dieser Controller per Bus zusammen zu schalten, einen PC (bevorzugt Windows) als Teilnehmer zum Bus hinzuzufuegen und dann darueber in alle Richtungen zu kommunizieren. Ein schoener Bus auf dem C28x ist natuerlich der CAN Bus. Nun kann ich mit der Schnittstelle auf dem C28x ja bereits einige grundlegende Protokollfunktionen nutzen, also z.B. die Adressierung, Timing, etc. Wunderschoen! Nur moechte ich natuerlich groessere und laengere Dialoge abwickeln mit Daten, die groesser als ein Paket sind und sich ueber mehrere Nachrichten erstrecken. Im Prinzip muesste ich also auf das CAN-Modul aufsetzend eine hoehere Kommunikationsschicht programmieren, die mir das alles ausfuehrt. Wunderschoen. Nur ist das doch eigentlich eine Aufgabe, die immer wieder aufkommt und da dachte ich mir, dass es sowas doch schon als Standard und als Code geben muesste. Habe etwas recherchiert und bin fluechtig z.B. an CANopen haengen geblieben. Als Open Source Implementierung gibt es wohl auch schon CANopenNode (sf.net), allerdings nicht fuer den TMS320F28... . Bevor ich mich jetzt dran mache, das Projekt zu portieren - hat jemand von euch ein Protokoll im Kopf, fuer das es implementierte Stacks fuer TI TMS320 und Windows als open source gibt (C/C++)? Oder gibt es griffige Design Patterns, die die ganze Sache ganz nett, kurz und systematisch machen? Vielen Dank!
Gast
#3844849
Hi, da ich im Moment selbiges Problem jedoch mit einem TMS320F2812 habe, wollte ich mal fragen was bei dir damals rausgekommen ist? Hast du was gefunden oder hast du es selbst geschrieben? Danke für deine Antwort!
Hallo merb + Marten, CANopen ist schon der richtige Weg. das könnte in diese Richtung gehen: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/68824.aspx Bei den meisten DIY-Stacks fehlt SDO-Block-Transfer, leider... Aber mit "expetited" (toggle bits) geht auch schon ne Menge. Grüße runout
Gast
#3844965
Die SDO Transfers sind allerdings auch recht simpel aufgebaut. Das nachzubauen ist am Ende vermutlich einfacher als eine komplette CANopen Libraray in das Projekt einzubinden...
SDO Block-Transfer benötigt man eher selten. Will man kleinere Strings oder Domains übertragen reicht meist auch der segmentierte SDO Transfer.
Gast
#3844996
Dr. Sommer schrieb: > Die SDO Transfers sind allerdings auch recht simpel aufgebaut. Das > nachzubauen ist am Ende vermutlich einfacher als eine komplette CANopen > Libraray in das Projekt einzubinden... Je mehr Funktionalität dieses Dienstes Du nutzen willst und je Standardkonformer du sein willst, um so aufwändiger wird es. Typischerweise merken es die Anwender erst, wenn sie die Arbeit reingesteckt haben. Will man wirklich nur das eine Problem damit erschlagen Daten auf mehrer Telegramme zu verteilen, hast Du allerdings recht. Doch auch hier kommen häufig während des Projektes weitere Kommunikations-Anforderungen. Vieles davon wäre dann mit einem vollwertigen CANopen Stack bereits inklusive. Bei einer Eigenentwicklung muss man erneut Arbeit reinstecken.
das hier ist mehr als fair... http://www.firmwaremarket.com/communications/can/canopen-stack-source-code.html schau mal, ob dein "Target" dabei ist...
Naja, CanFestival, CanFestival-3 und die angebotenen Ports von CanFestival von Inteliss enthalten keinen DSP. Da bei DSPs typischerweise auch am Unterbau angepasst werden muss, wäre es schade, wenn Inteliss ihre Anpassungen nicht veröffentlicht hätten.
Hallo Marten Ich möchte gern den F28377 (Launchpad) mit CANOpenNode einsetzen. Konnest du CanOpenNode für den F28335 portieren? Würdest du dein Port teilen? Viele Grüsse René
Gast
#4935689
Hi Rene, leider nein, wir haben im Endeffekt auf etwas Eigenes gesetzt. Viele Grüße