Hallo zusammen, ich möchte ein bestehendes Projekt erweitern und suche dazu Hardware für ein CAN/CAN Gateway. Das Projekt ist auf Basis von AVRs und MCP2515 aufgebaut, die Busspeed ist 125 kbit/s. Theoretisch kann ich an die bestehenden Knoten auch zusätzliche MCPs hängen und mir das Routing programmieren, aber dazu müsste ich erstmal wieder ein Layout erstellen, Platinen herstellen lassen und dann ist es fraglich, ob die Geschwindikeit der AVRs ausreichend ist (max 4 MHz interner Takt) Idealerweise ist die Hardware auch als Gateway für weitere Physical Layers nutzbar, beispielsweise CAN/ZigBee, CAN/868 MHz usw. für die es dann auch entsprechende Libs gibt :-) Bei meiner Suche bin ich auf das Teensy 3.6 Board gestossen. Kennt ihr noch weitere Hardware? Bei den ganzen Arduino Sheelds konnte ich nicht ersehen, dass diese auch mehrere Sheelds unterstützen. Bin für jeden Hinweis dankbar! Viele Grüße Volker
Wie wäre es mit einem STM32F4 Discovery Board für ca. 15€. Der Controller hat 2 CAN Controller direkt integriert (viel effizienter und einfacher nutzbar als CAN-Controller per SPI wie der MCP2515). Da müssen nur noch 2 CAN Transceiver angeschlossen werden. Der hat auch mehr als genug Leistung für 2x 1MBaud CAN's.
Sowas wäre zB geeignet und auf jeden Fall mehr als leistungsfähig genug: http://www.microchip.com/wwwproducts/en/dsPIC33EP128GM604 fchk
Frank K. schrieb: > Sowas wäre zB geeignet und auf jeden Fall mehr als leistungsfähig > genug: > > http://www.microchip.com/wwwproducts/en/dsPIC33EP128GM604 Ich glaube die Frage war nach fertigen Platinen. Dass es Mikrocontroller mit mehreren CAN's gibt war dem TO wohl klar...
Einfach bei Bosch, Continental oder TRW anfragen, die können sowas aus dem Regal ziehen.
Ich hätte für diese Aufgabe auch einen STM32F4 empfohlen. Der ist schnell genug für die Aufgabe. Dazu 2x den CAN Transceiver ISO1050, damit hat man galvanische Trennungen zu zu den beiden CAN Busen.
Passt mal auf mit Tipps, das ist gerade das Thema von div. ausgeschriebenen Projekt- und Abschlussarbeiten an der TH Nürnberg (genau so ein Gateway hängt gerade als Thema aus). Der Boy hier will die Lösung fürn good ol copy and paste drive by Abschluss.
Egon schrieb: > Passt mal auf mit Tipps, das ist gerade das Thema von div. > ausgeschriebenen Projekt- und Abschlussarbeiten an der TH Nürnberg > (genau so ein Gateway hängt gerade als Thema aus). Ein CAN Gateway als Abschluss Arbeit? Abschluss für die Baumschule? So was macht doch jeder halbwegs kompetente Entwickler noch vor der Mittagspause fertig.
Hallo zusammen, danke schon mal für eure Antworten. Ja, mir ist bekannt, dass es µCs mit mehreren internen CAN Controllern gibt :-) Ich suche in der Tat eine "fertige" Hardware für das Thema und nein, es handelt sich um keine Abschlussarbeit der TH Nürnberg. Das liegt bei mir schon Jahrzehnte zurück. Ist doch immer wieder lustig, welche Querbeziehungen hier generiert werden. Zum Glück bin ich ein fröhlicher Mensch und überlese das "Boy" einfach mal... Der Vorschlag bei Bosch, TRW oder Conti nachzufragen ist auch nicht sonderlich hilfreich. Keine der genannten Firmen hat so etwas im Regal liegen, die greifen eher auf fertige HW von PEAK oder Eberspächer zurück. Aber das ist für die geplante Erweiterung "out of budget". Und bevor jetzt noch einer kommt. Ja, bei Vector gibts das auch zu kaufen, ja, ich kenne CANalyzer, CANoe, Busmaster und Co :-) So, nun wieder back to topic. Der Vorschlag mit einem STM32 klingt spannend. Damit wollte ich schon lange mal was machen, hab sogar einen STM32F4 hier. Allerdings fange ich da quasi bei Null an, vom Scheduler angefangen. Gibt es fertige CAN Bibliotheken für den F4? Welche Entwicklungsumgebung wird hier verwendet? Wahrscheinlich kann ich bei dem Einarbeitungsaufwand auch eine Platine in meinem bisherigen System routen :-) Was spricht gegen das Teensy Board? Viele Grüße Volker
Dr. Sommer schrieb: > Egon schrieb: >> Passt mal auf mit Tipps, das ist gerade das Thema von div. >> ausgeschriebenen Projekt- und Abschlussarbeiten an der TH Nürnberg >> (genau so ein Gateway hängt gerade als Thema aus). > > Ein CAN Gateway als Abschluss Arbeit? Abschluss für die Baumschule? So > was macht doch jeder halbwegs kompetente Entwickler noch vor der > Mittagspause fertig. Ein CAN/CAN Gateway kann schon ganz schön kniffelig werden, vor allem wenn unterschiedliche Busgeschwindigkeiten und harte Anforderungen ans Timing zu berücksichtigen sind. Wenn dann noch hohe Buslast, viele Quantisierungen und limitierte Ressourcen einschränken... aber daraus eine Abschlussarbeit zu generieren wäre mir zu wenig. Achja, bei mir sind es auf beiden Bussen 125 kbit/s. Quantisierungen sind nicht nötig. Im Prinzip dient das Gateway "nur" dazu den Bus mit einer langen Stichleitung zu verlängern und dann eben nur die Botschaften auf den Strang zu routen, die dort auch von Interesse sind. Viele Grüße Volker
Volker schrieb: > Der Vorschlag mit einem STM32 klingt > spannend. Damit wollte ich schon lange mal was machen, hab sogar einen > STM32F4 hier. Allerdings fange ich da quasi bei Null an, vom Scheduler > angefangen. Gibt es fertige CAN Bibliotheken für den F4? Ist das denn bei dem Teensy anders? > Welche > Entwicklungsumgebung wird hier verwendet? Was meinst Du mit "Entwicklungsumgebung" genau? Eine IDE? Wenn ja, dann achte genau drauf, daß Deine Software und die verwendeten Bibliotheken etc. auch vollständig compilieren ohne daß Du eine IDE dafür verwenden musst. Ansonsten hast Du immer den Klotz der IDE am Bein. Die hat normal viel mehr Abhängigkeiten als eine reine Toolchain zum compilieren und das macht bei der langfristigen Pflege schnell mal viel Aufwand. Ne IDE hilft, wenn es um Code-Navigation, Auto-Vervollständigung etc. geht. Aber mehr auch nicht. > Wahrscheinlich kann ich bei > dem Einarbeitungsaufwand auch eine Platine in meinem bisherigen System > routen :-) Ne Platine routen ist einfach und schnell gemacht. Der Aufwand steckt hier eher in der Software. Aber das ist halt eine Investition in die Zukunft: wenn Du mit der verwendeten µC-Serie mehrere Projekte machen möchtest, kennst Du Dich nach dem Ersten damit schon aus und kannst dann deutlich schneller starten. > Was spricht gegen das Teensy Board? Siehe oben. Sagt Dir der Kinetis vom Teensy oder der STM32 mehr zu? Was für eine Serie passt besser zu den anderen Projekten die Du noch vor hast?
Volker schrieb: > Dr. Sommer schrieb: >> Egon schrieb: >> Ein CAN Gateway als Abschluss Arbeit? Abschluss für die Baumschule? So >> was macht doch jeder halbwegs kompetente Entwickler noch vor der >> Mittagspause fertig. > > Ein CAN/CAN Gateway kann schon ganz schön kniffelig werden, vor allem > wenn unterschiedliche Busgeschwindigkeiten und harte Anforderungen ans > Timing zu berücksichtigen sind. Wenn dann noch hohe Buslast, viele > Quantisierungen und limitierte Ressourcen einschränken... aber daraus > eine Abschlussarbeit zu generieren wäre mir zu wenig. Da soll ein ganzes System (mehrere Baugruppen) für Versuche aufgebaut werden, zudem soll der Kram auch noch meshen und tausend Sachen machen, das ist aber eh nur eine Projektarbeit an der man effektiv ein paar Tage arbeitet (Luschen brauchen dafür dann ein bis zwei Semester).
>> Was spricht gegen das Teensy Board? > > Siehe oben. Sagt Dir der Kinetis vom Teensy oder der STM32 mehr zu? Was > für eine Serie passt besser zu den anderen Projekten die Du noch vor > hast? Ich muss vielleicht noch etwas weiter ausholen. Ein Freund und Kollege hat vor kurzem einen 3D Drucker gebaut. Dazu verwendete er einen Arduino mit speziellen Sheeld (keine Ahnung, wie das Ding genau heisst). Hier hat alles "out of the box" sofort funktioniert. Mir ist schon klar, dass ich das für meine Anwendung nicht übertragen kann, aber der Gedanke beispielsweise eine Arduino Plattform zu verwenden und ein CAN Sheeld darauf zu betreiben hat schon etwas. Bei dem Ansatz muss ich mich nicht um die Hardware kümmern und kann mehr oder weniger sofort mit meiner Gateway Implementierung anfangen. Bei einer kleinen Recherche hab ich dann aber schnell festgestellt, dass ohne HW-Äderung keine zwei CAN Sheelds an einem Arduino zu betreiben sind. Das bedeutet, ich müsste dann doch wieder einen Treiber programmieren usw. (ich habe mir allerdings die Sourcen für die einzelnen Sheelds nicht angeschaut, aber nachdem das ChipSelect und die Interruptleitung fest verdrahtet sind, erwarte ich hier keine Flexibilität) Anschließend bin ich dann auf das Teensy Board gestoßen. Hier wird auch wieder die Arduino Entwicklungsumgebung verwendet (nein, ich habe bislang keine Erfahrung damit, sah bei meinem Kollegen aber sehr intuitiv aus). Den großen Vorteil verspreche ich mir daraus, dass ich "später" dann auch andere Interfaces (Sheelds), z.B. ZigBee, Bluetooth usw. nutzen kann und eben auch hier wieder auf Bibliotheken für die einzelnen Sheelds zurückgreifen kann. Bei der Arduino-HW läuft im Hintergrund ja ein Atmel Controller. Mit den µCs kenne ich mich ganz gut aus, hab sie schon in vielen Projekten eingesetzt und dadurch auch einiges an SW dafür geschrieben (Scheduler mit Überwachungsfunktionen, Laufzeitmessungen, Bootloader, usw.). In meiner naiven Annahme ging ich davon aus, dass ich bei den Arduinos zumindest einen Scheduler "frei Haus" mitbekomme und ich auch eine rudimentäre Interruptverwaltung vorfinde. Quasi CAN Sheelds dran und losprogrammiert :-) Die STM32 Familie ist Neuland für mich. Ich kenne nur ein paar Eckpunkte der Controller, hab aber beispielsweise keine Ahnung, wie Interrupts verwaltet werden (gibt es verschiedene Prioritätsebenen?), welche Timer zur Verfügung stehen (Scheduler), wie ein Bootloader zu implementieren ist usw. Ich weiß noch nicht einmal, welchen Compiler ich dafür verwenden sollte, wie darauf debugged wird usw. Ich fange quasi bei Null an... würde aber eine steile Lernkurve erwarten :-) Die letzte Option ist dann eben doch eine Platine zu Routen und in meinem bisherigen Universum zu bleiben. Das wäre auch mein Ansatz gewesen, wenn ich meine bestehenden Platinen einfach höher takten könnte (aus Platzgründen habe ich damals keinen externen Quarz verwenden können). Am Ende bedeutet das dann aber wieder, dass ich bei der Adaption von z.B. ZigBee wieder vor der selben Fragestellung stehen werde...
Volker schrieb: > Im Prinzip dient das Gateway "nur" dazu den Bus mit > einer langen Stichleitung zu verlängern und dann eben nur die > Botschaften auf den Strang zu routen, die dort auch von Interesse sind. Für CAN gibt es auch Repeater, die kann man zwar nicht konfigurieren und filtern können die auch nicht, dafür kann man da auch nicht viel falsch machen. Der AMIS42770 ist ein CAN Repeater. 2x AMIS42770 für 4 Ports. Ich kenne eine Firma die so ein Teil herstellt, bitte PN schreiben falls Interesse besteht.
Hier ein board mit 4 can schnittstellen. Out of the box. Und du kannst noch über einen bus zusatzhardware aufstecken.
Volker schrieb: > Anschließend bin ich dann auf das Teensy Board gestoßen. Hier wird auch > wieder die Arduino Entwicklungsumgebung verwendet (nein, ich habe > bislang keine Erfahrung damit, sah bei meinem Kollegen aber sehr > intuitiv aus). Die ist genau das, wovor ich oben gewarnt habe: die hat ein ziemlich kaputtes Bibliothekskonzept, bei dem die Abhängigkeiten nicht sauber im Projekt selbst verwaltet werden, sondern irgendwie in die IDE eingepflanzt werden müssen. Das compilieren läuft normal nur aus der IDE und nur, wenn man vorher die richtigen Versionen der richtigen Bibliotheken installiert hat. Verschiedene Projekte fordern verschiedene Versionen von den selben Bibliotheken, das kann die IDE nicht sauber abbilden und schon kann man nur entweder das eine Projekt oder das andere bearbeiten. Usw. Das ist ziemlich genau das Gegenteil einer professionell nutzbaren IDE. Man kann auch Arduino-Projekte mit ordentlichen Makefiles aufsetzen. Das findet man aber nur selten und ist mehr Aufwand. > Bei der Arduino-HW läuft im Hintergrund ja ein Atmel Controller. Mit den > µCs kenne ich mich ganz gut aus, hab sie schon in vielen Projekten > eingesetzt und dadurch auch einiges an SW dafür geschrieben Nein. Nicht wenn Du das Teensy-Board verwendest. Dann hast Du einen Kinetis Controller von NXP (ehemals Freescale). Der hat (ebenso wie der oben empfohlene STM32F4) ein ARM Cortex M4F-Kern. Ich schätze den Einarbeitungsaufwand in den Kinetis und den STM32F4 etwa ähnlich ein. Für manche Projekte passt die Hardware des einen besser, für andere die des anderen. Manchen liegt die Doku der Kinetis besser, anderen die der STM32. > Die STM32 Familie ist Neuland für mich. Ich kenne nur ein paar Eckpunkte > der Controller, hab aber beispielsweise keine Ahnung, wie Interrupts > verwaltet werden (gibt es verschiedene Prioritätsebenen?), welche Timer > zur Verfügung stehen (Scheduler), wie ein Bootloader zu implementieren > ist usw. Ich weiß noch nicht einmal, welchen Compiler ich dafür > verwenden sollte, wie darauf debugged wird usw. Ich fange quasi bei Null > an... würde aber eine steile Lernkurve erwarten :-) Das ist beim Kinetis nicht anders. Auch ein Cortex M4F, Interrupt-Prioritäten etc. sind identisch. Hardware wie Timer und Bootloader sind etwas anders, aber ich würde mal sagen auf ähnlichem Niveau. Compiler würde ich etwas auf dem gcc basierendes empfehlen. Fürs Debugging ein Segger Jlink Edu. Wenn Du ein STM32F4Discovery-Board nimmst, kannst Du direkt starten. Da ist alles was Du brauchst drauf, inkl. einem Debugger-Interface. Geliefert wird es mit ST-Link, Du kannst es aber auf Jlink umflashen (Download siehe Webseite von ST).
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.