Hallo, hoffe man kann mir hier mal wieder helfen. Stehe im Moment vor dem Problem, ein CAN Gateway realisieren zu müssen und zwar mit einem AVR Prozessor. Leider hab ich keinen AVR Prozessor mit 2 CAN Controllern gefunden. Nun sehe ich nur die Möglichkeit das Gateway mit einem AVR Controller und 2 externen CAN Controllern aufzubauen. Leider kann ich jetzt aber nicht abschätzen, ob ich mit diesem Aufbau bei einer Übertragungsrate bis zu 1MBit/s Probleme bekomme. Es sollen bis zu 5 Messages gefiltert und verändert wieder weitergereicht werden. Der Rest des Messages soll unverändert weitergeleitet werden. Hat hier schon mal jemand so etwas mit einem AVR Controller gebaut? Oder hat mir jemand irgendwelche Tipps? Bin für jeden Tip dankbar. Vielen Dank schon mal.
Kannst Du abschätzen, wie viel auf dem CAN-Bus los ist? Auch wenn die Telegramme mit bis zu 1MBit/s übertragen werden, ist die netto-Datenrate im Regelfall deutlich geringer. Daher gehe ich mal davon aus, das das mit einem Mega-xx - µC realisierbar ist. In den externen Can-Controllern (z.b. MCP 2515) kann man Filter definieren, so dass die nicht auf alle Telegramme reagieren. Auf diese Weise könnte man die Last für den µC noch weiter reduzieren.
Um auszurechnen, ob deine Prozessorleistung ausreicht, musst du ermitteln wie lange a) Eine Nachricht auf dem Bus liegt und b) wie lange die Durchlaufzeit (=Verarbeitungszeit) deines Gateways ist Die Verarbeitungszeit besteht aus: 1) Nachricht aus Empfangspuffer lesen 2) Daten interpretieren (Welche ID, wohin routen) 3) optional: Datenmanipulation 4) Zielnachricht generieren und in den Versendebuffer schreiben Ich kenne den AVR jetzt nicht näher, aber wenn das ein 32bitter ist, wird er bei halbwegs anständiger Programmierung mit zwei CAN Bussen locker klar kommen. Was ein wenig komplizierter werden kann ist die Datenmanipulation. Kannst du hierüber nähere Auskunft geben? Ich meine wenn du da z.B. anfängst einen Sinus zu berechnen, dann siehts schlecht aus ;-) Schreib einfach ein bissl mehr über dein Vorhaben, und auch warum es unbedingt ein AVR sein muss. Gruß, Peter
Warum muss es unbedingt ein AVR sein (welche Art überhaupt? 8bit oder 32bit) Mir würde mindestens eine Kontrollerfamilie einfallen, die solche Gatewayaufgaben fast ohne den CPU zu belasten schaffen. Einfach weil deren CAN Schnittstellen so verknüpft sind, das ein Routen und ummappen von Daten in der Hardware erledigt wird. Wenn die Zeit die eine Nachricht durch das Gateway braucht nicht so kritisch ist kann man auch zwei AT90CAN über einen DualPort-Speicher verknüpfen, oder man nutzt einfach die ISP um die Daten von einem AVR in den anderen zu bringen.
Peter B. wrote: > In den externen Can-Controllern (z.b. MCP 2515) kann man Filter > definieren, so dass die nicht auf alle Telegramme reagieren. Auf diese > Weise könnte man die Last für den µC noch weiter reduzieren. Bei internen auch. Aber das nützt nichts, weil alle Messages durch sollen. Thomas U. wrote: > und zwar mit einem AVR Prozessor Wenn du das mit einem ATMega machen willst würde ich abraten. Nimm einen µC mit 2 CAN Controllern. Zum Beispiel: dsPic, ARM,...
Woher kommt die (bloedsinnige) Vorgabe einen AVR fuer ein CAN Gateway herzunehmen? Also wenn beide Schnittstellen gleichzeitig aktiv sein sollen, also der Datenverkehr von beiden Seiten evtl. analysiert und veraendert werden muss, dann wird das meiner Meinung nach ziemlich knapp mit einem AVR (ich nehme an 8-bit 16 MHz). Ich nehme ausserdem an, dass beide CAN Busse gleich schnell laufen, ansonsten ist die Bufferverwaltung (FIFO oder Prioritaet oder Kombination der beiden) alleine wahrscheinlich mehr als ein AVR schaffen wuerde. So ein LPC2119 schafft das locker, ein LPC23xx auch. Es gibt hier immer wieder Mahnungen, warum gleich fuer alles einen 32-bitter hernehmen, diese Fragen sind teilweisse auch berechtigt. Lass mich hier fragen, warum mit einem AVR?? Vor kurzem wurde nochmal Leben in ein Thread eingehaucht, das sich mit simplen Benchmarks beschaeftigt Beitrag "LPC2103 63MIPS?" darin kann man mindestens sehen wieviel langsamer der AVR selbst beim schaufeln von 8-bit Daten ist, ganz zu schweigen, wenn man aus einem interenen CAN Controller die Daten 32-bit breit auslesen kann. Kurz und gut, diese Definition CAN Gateway 1MB und AVR hoert sich nach einer Tortur an. Robert
Hallo, also, ich versuche jetzt auf alle Antworten einzugehen. Netto-Datenrate bei ziemlich genau 500 kBit/s Filter und Masks in einem MCP bringen mir nichts, da alle Nachrichten wetergeleitet werden müssen und einige wenige davon geändert weitergeben werden müssen. Sind sehr einfache Rechenaufgaben a la y = m*x + t. Die Verarbeitungszeit kann ich auf die schnelle nicht abschätzen. Aber genau diese macht mir zu schaffen. Da ich denke, dass ich hier in Teufels Küche komme. Zu der Vorgabe eines AVR zu nehmen kam es vor kurzem durch einen Zulieferer, der sich einen AVR wünscht, damit für ihn alles besser zu handeln ist. Natürlich sollte das dann auch ein 8-bitter sein, da günstiger. Das System ist eigentlich schon fertig aufgebaut mit einem M16C6NK. Mit diesem Controller habe ich auch keine Bauchschmerzen. Und ich denke ich habe mich schon entschieden das ganze weiter mit dem M16 zu machen. Jetzt werde ich mir ein paar Argumente einfallen lassen. Pro M16, contra AVR. So wie ich das sehe werde ich wohl einen Bootloader für den M16 schreiben müssen, damit sollte dann der Zulieferer auch zufrieden sein. Da es hauptsächlich um die Programmierung des fertigen Systems geht, wo mehrere Controller verbaut sind und alle über die gleiche Schnittstelle programmiert werden müssen. Vielen Dank für die Antworten, mir wurde hier mal wieder super schnell geholfen. Hat vielleicht zuletzt noch jemand gute Literaturtipps zum Thema Bootloader, weil in dieser Hinsicht bin ich absolut Blank. Vielen Dank
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.