CAN to CAN Gateway mit AT90CAN

So gern ich auch mit dem 90CAN32 arbeite, als Gateway taugt der nicht 
weil der nur eine richtige CAN-Schnittstelle hat.
Die Nummer mit dem MCP am SPI ist nur eine Krücke aus einer Zeit als es 
noch  nichts besseres gab.

Nimm was mit zwei CAN-Schnittstellen das bei Euch im Haus programmiert 
werden kann, es gibt soviel davon.
AVR32UC3C, V850ES, MCP5602 (alles mit 64 Pins im 0,5 mm Pitch verfügbar)
dsPIC33irgendwas, STM32, irgendwelche ARMs von TI und so weiter und so 
weiter

Wenn es Automotive sein soll wird die Liste kürzer, STM32 ist dann 
schonmal glatt raus weil ST die nicht für diesen Markt baut sondern 
lieber PPC-Kerne in Lizenz von Freescale anbietet.

Für ein Gateway ist ein Controller mit floating point wohl auch nicht 
die schlechteste Wahl.

Also eine Abstimmung mit den Softwerkern ist da eine gute Idee.

Bruno Kempf schrieb:
> - Datenratenanpassung (bei Übertragung von High- auf Low-Speed CAN und
> umgekehrt)

Low-Speed CAN ist nicht einfach nur langsamer, das erfordert einen 
anderen Transceiver der auch nicht pin-kompatibel ist.
Also muss man für solche Geschichten alles doppelt vorhalten.

Du solltest erstmal abschätzen, wie viele Daten du da in welche 
Geschwindigkeit drüber routen willst. Deine Anwendung klingt wie 
Automobil und da wird auch gern bis zu High-Speed CAN gegriffen. Je nach 
dem, was du dann noch mit den Daten zwischendurch machen willst kann das 
mit dem AVR äußerst eng werden. Sind es überwiegend ein paar 
ID-Änderrungen, kein Thema, aber wenn du noch Berechnungen oder 
eingebettete Simulink-Modelle durchgehen musst ... Und je länger du 
rechnest, desto mehr CAN Daten musst du zwischenspeichern. Da kann bei 
HighSpeed CAN in kürzester Zeit einiges zusammen laufen. Du solltest 
auch beachten, dass eventl. die Zykluszeit der Nachrichten eine Rollle 
spielt, welche eventl. dann bei bestimmten Botschaften durch vorherige 
Verarbeitung andere Botschaften verändert werden ...

Ich empfehle dir lieber eine leistungsstärker Hardware zu wählen, ist 
kaum teurer und bietet am Ende vielleicht ein paar Reserven statt 
Datenverluste und Schweiß auf der Stirn.

Hi,

danke schon mal für die Anregungen. Ich werde mir mal die 
Mikrocontroller ansehen, die ihr mir vorgeschlagen habt. Allerdings 
sollte der AT90CAN ausreichen und ist für das erste Projekt auch ganz 
gut, um rein zu kommen.

Das mit der Spannungsversorgung über den Sub-D Stecker werde ich sein 
lassen.

Mit freundlichen Grüßen
Bruno Kempf

Bruno Kempf schrieb:
> Allerdings
> sollte der AT90CAN ausreichen und ist für das erste Projekt auch ganz
> gut, um rein zu kommen.

1. Um rein zu kommen ist es ganz gut ne LED blinken zu lassen, nicht ein 
CAN Gateway zu programmieren.

2. Musst du zwei CAN Controller über SPI ansteuern, das ist deutlich 
schwerer als einfach einen Controller zu programmieren der beides intern 
hat.

Ich würde dir raten einen dspic33 zu nehmen mit zwei CAN Modulen. Da 
gibts beliebig viele. Dann nimmst du dir den Beispielcode von Microchip 
für zwei CAN Module, verbindest die und bist schon fast fertig. Damit 
hast du schnelle Erfolgserlebnisse und kannst danach filter und sowas 
dazubauen.

Aber du musst nicht auf meinen Rat hören, ich finde es immer lustig wenn 
sich Leute das Leben schwer machen und dann hier jammern.

Rudolph schrieb:
> Für ein Gateway ist ein Controller mit floating point wohl auch nicht
> die schlechteste Wahl.

Für was genau braucht man bei einem CAN Gateway eine FPU?
Ich glaube es gibt bisher noch nicht viele die bei der Arbeit mit CAN 
float gebraucht haben. Würde mich jetzt echt mal interessieren.

Antwortgeber schrieb:
> 2. Musst du zwei CAN Controller über SPI ansteuern, das ist deutlich
> schwerer als einfach einen Controller zu programmieren der beides intern
> hat.

Warum meinst Du heisst der µC AT90CAN? Der hat schon einen, aber eben 
nur einen internen CAN-Controller. :-)
Was aber nichts daran ändert, dass der per SPI angebundene MCP eine 
Krücke ist.

Antwortgeber schrieb:
>> Für ein Gateway ist ein Controller mit floating point wohl auch nicht
>> die schlechteste Wahl.
>
> Für was genau braucht man bei einem CAN Gateway eine FPU?
> Ich glaube es gibt bisher noch nicht viele die bei der Arbeit mit CAN
> float gebraucht haben. Würde mich jetzt echt mal interessieren.

Mein Job ist eigentlich Hardware-Entwickler im Automobil-Bereich, dabei 
decke ich aber im unteren Bereich auch schon mal Projekte mit eigener 
Software auf kleinen Controllern ab.
Unsere "richtigen" Steuergeräte verwenden 32 Bit Controller von 
Freescale, Renesas oder Infineon und auf denen arbeiten unsere 
Software-Entwickler mit Matlab-Simulink oder auch Autosar.

Ein CAN-Gateway braucht man zum Beispiel in der Entwicklung wenn man 
Steuergeräte verschiedener Fahrzeug-Plattformen miteinander kombinieren 
will.
Und da ist es laut unseren Software-Entwicklern von Vorteil wenn man 
grosse Parameter-Sätze mit Floating-Point umrechnen kann.

Dagegen ist der Level der hier normalerweise so läuft und auf dem ich 
selber bei der Software mitspiele nur Spielzeug.

@Antwortgeber:
Keine Sorge eine LED hab ich schon mal blinken lassen ;-) Es ging um die 
Steuerung von CAN-Modulen. Falls es wirklich so schwer ist einen (keine 
zwei) CAN-Module per SPI anzusprechen werde ich wohl auf einen µC mit 
zwei CAN-Modulen setzen.
Ein bisschen weniger Sarkasmus und das wäre des beste Antwort bisher 
gewesen ;-) Das Problem ist nämlich nicht dass ich nicht programmieren 
oder ein Schaltplan erstellen kann. Das Problem ist für mich zu wissen 
welche Komponenten gibt es und welche davon sind für die 
Aufgabenstellung geeignet bzw. welche weniger. Dann geht es gleich 
weiter... Welche von den ganzen Funktionen der Komponenten brauche ich, 
welche nicht. Mit solchen Dingen habe ich zu kämpfen, da mir einfach das 
praktische Wissen und die praktische Erfahrung fehlt. Deshalb bin ich 
über jede Hilfe froh, die ich in dieser Hinsicht bekomme.

Mit freundlichen Grüßen
Bruno Kempf

Rudolph schrieb:
> Warum meinst Du heisst der µC AT90CAN?
Ok, das macht leicht besser (geschätzt 8%)

> Und da ist es laut unseren Software-Entwicklern von Vorteil wenn man
> grosse Parameter-Sätze mit Floating-Point umrechnen kann.

OK, verstehe. Das hat aber ja nichts mit dem CAN Gateway zu tun. Ein 
Gateway leitet ja nur Nachrichten nach betimmten Regeln weiter.

Wenn dann natürlich die funktionalität noch soweit erweitert wird dass 
zwischendrin auch mal Daten umgerechnet werden ist das was anderes.
Das Denken deiner Softwerker stammt aber sicher daher, dass die zum 
programmieren kein Texteditor sondern Simulink benutzen. Hat ja seine 
Berechtigung, aber für alle die hier unterwegs sind gilt: CAN läuft 
maximal mit 1 MBaud/s, da kommen keine so großen Datenmengen dass man da 
Probleme mit dem Rechnen bekommen würde.

Bruno Kempf schrieb:
> Ein bisschen weniger Sarkasmus

Das du es erkannt hast lässt dich schon mal in die nächste Liga 
aufsteigen ;-)

Wenn du dich für meinen Vorschlag interessiert hier noch Infos:
- Controller wurde im Parallelthread schon der kleinstmögliche genannt:
Beitrag "Re: CAN Gateway mit PIC"
Der ist allerdings relativ neu.

- Wenn du einen willst der seit Jahren bewährt und gut verfügbar ist:
dsPIC33FJ64GP706A, dsPIC33FJ64GP708A, dsPIC33FJ64GP710A

- Code für den Einstieg
http://embeddedcodesource.com/developer/microchip_technology_59/ce034__can_loopback

Antwortgeber schrieb:
> OK, verstehe. Das hat aber ja nichts mit dem CAN Gateway zu tun. Ein
> Gateway leitet ja nur Nachrichten nach betimmten Regeln weiter.

Ein Gateway ist kein Switch. :-)

Wenn man zwei Steuergeräte verbinden will die sich normalerweise nicht 
verstehen kann man nicht darauf hoffen, dass einfach nur die IDs 
verdreht werden müssen.
Man muss schon damit rechnen, dass die transportierten Information 
woanders und auf andere Art und Weise verpackt sind.

Und wenn man noch mehr Spass hat muss das Gateway auch noch eine 
Restbus-Simulation machen, also CAN-Teilnehmer simulieren die real 
garnicht da sind.

Danke nochmal an alle, die sich die Mühe gemacht haben zu antworten. 
Jetzt habe ich einen groben Überblick über die µController und werde 
(vielleicht gleich am Wochenende) einen neuen Schaltplan mit dem 
AT32UC3C0128C (http://www.atmel.com/devices/AT32UC3C0128C.aspx) 
entwerfen.

Der Link mit dem Code für den Einstieg wird sich wahrscheinlich auch 
noch als nützlich erweisen. Erst mal werde ich noch ein bisschen mit der 
Hardware beschäftigt sein -.-
Sobald ich dann mit der Software anfange werde ich nochmal um eure Hilfe 
bitten :-) Gerade das mit den Bootloadern ist mir noch nicht ganz klar. 
Welchen brauche ich? usw.

Aber noch eine andere Frage:
Optional (d.h. falls das Praxissemester nicht schon vorbei ist) soll ich 
noch eine Hardware-Komponente vorsehen die eine Botschaftsmanipulation 
ermöglicht. Dabei sollen durch die Botschaftsmanipulation Fehler in der 
CRC-Summe sowie Bit-Stuffing Fehler erzeugt werden können. Ich habe 
bisher noch nicht so viel Gehirnschmalz in diese Aufgabe gesteckt, da 
ich mich erst mal auf das Wesentliche konzentrieren will (reicht auch 
für den Anfang finde ich :-D). Aber ich bin mir sicher das ihr ein paar 
Anregungen/Ideen habt, wie so eine Hardware ungefähr aussehen könnte.

Mit freundlichen Grüßen
Bruno Kempf

Bruno Kempf schrieb:
> falls das Praxissemester nicht schon vorbei ist

Mach dir keine Gedanken darüber. Ich kann dir garantieren, dass du das 
nicht auch noch während des Praxissemesters schaffst.
Deine eigentliche Aufgabe ist schon Taff.

Bruno Kempf schrieb:
> einen neuen Schaltplan mit dem
> AT32UC3C0128C (http://www.atmel.com/devices/AT32UC3C0128C.aspx)
> entwerfen.

Warum nimmst Du keinen AT32UC3C2* wenn die Wahl schon auf AVR32 gefallen 
ist?
144 Pins scheint für ein Gateway leicht übertrieben zu sein. :-)

So oder so, AVR32 ist hier ein wenig exotisch, wenn Du was davon posten 
kannst, immer her damit. :-)