CAN to CAN Gateway mit AT90CAN

[Bruno K. (Gast)]

Hallo liebe Leute,

ich mache gerade meine ersten Gehversuche als Ingenieur 
(Praxissemester), habe bisher leider noch nie mit CAN gearbeitet und bin 
jetzt an einem Projekt dran, bei dem ich ein CAN to CAN Gateway 
entwickeln soll.

Die Aufgabe besteht darin, eine Hardware inlusive Software für das 
Gateway zu entwickeln. Dabei soll (für den späteren Kunden) zusätzlich 
die Möglichkeit bestehen am PC das Gateway zu konfigurieren und über 
eine Bluetooth-Schnittstelle den CAN-Bus auf einem mobilen Gerät (Tablet 
oder ähnliches) zu überwachen.
Konfigurationsmöglichkeiten:
 - Signalmapping (Gateway soll aus mehreren Botschaften die benötigten 
Informationen in einer Botschaft zusammenfassen
 - Identifierumsetzung (Anpassen der Botschafts-ID)
 - Nachrichtenfilterung (nicht relevante Nachrichten soll das Gateway 
ignorieren)
 - Datenratenanpassung (bei Übertragung von High- auf Low-Speed CAN und 
umgekehrt)

Gerade bin ich noch beim Hardware-Entwurf.
Durch einen Kollegen, der schon mit CAN zu tun hatte, bin ich auf 
folgendes Board aufmerksam geworden:
https://www.chip45.com/products/crumb128-can-5.0_avr_atmega_modul_board_at90can128_usb_rs232_can.php
Bei diesem Board ist ein AT90CAN128 + HighSpeed Transceiver (PCA82C251), 
ein USB-UART Wandler (CP2102) und eine RS232-Schnittstelle (MAX3221) 
verbaut.
Dieses Board, zwei Schaltregler (LM2574M-5.0, LM2574M-3.3), ein 
Verpolungsschutz (MOSFET), einen externen CAN-Controller (MCP2510) + 
Transceiver (MCP2551) und das Bluetooth-Modul RN41XV + Pegelwandler 
(MAX3395) habe ich bisher für mein Gateway-Board vorgesehen. (siehe 
Anhang)

Nun kommen wir zu den eigentlichen Fragen:
1.) Bei dem Crumb128CAN 5.0 sind beide USART-Schnittstellen des AT90CAN 
bereits durch die USB- bzw RS232-Schnittstelle belegt. Kann ich jetzt 
die jeweiligen PINs (RXD0/RXD1 und TXD0/TXD1) trotzdem ganz normal 
verwenden? Da müsste es doch Probleme geben oder zumindest müsste man 
aufpassen, dass es bei der Kommunikation keine Konflikte gibt, oder was 
meint ihr?

2.) Das Gateway soll später eventuell in ein Gehäuse und mit einer 
Spannung im Bereich von 7V - 18V versorgt werden. Dementsprechend muss 
der Anschluss (über Bananenstecker) für die Spannungsversorgung nach 
außen geführt werden. Könnt ihr mir für den Anschluss ein Bauteil in der 
EAGLE-Bibliothek empfehlen? Ich komm mit der unendlichen Bibliothek noch 
nicht zurecht. Gleiches gilt für die Shottky-Diode beim Schaltregler. 
Gibt es vielleicht welche die besser geeignet sind?

3.) Diese Frage bezieht sich auf den ersten Teil der 2.) Frage. Der 
CAN-Bus wird mit dem üblichen 9 Pin D-SUB Stecker bereit gestellt. Dabei 
ist auch eine Versorgungsspannung von 24V an PIN 9 vorgesehen. Kann ich 
diese Spannung einfach auf den Eingang vom Verpolungsschutz und den 
Ausgang des Verpolungsschutzes auf den Eingang der Schaltregler geben?

4.) Falls ihr Verbesserungsvorschläge zur Verschaltung/Beschaltung der 
Komponenten habt oder euch Fehler auffalllen, wäre ich über jeden 
Hinweis dankbar.

So des wars erstmal... Aber es kommen bestimmt noch ein paar Fragen ;-)

Mit freundlichen Grüßen
B0bbyR4y

[Rudolph (Gast)]

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.

[ARMler (Gast)]

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.

[Frank K. (fchk)]

Ich schließe mich den Empfehlungen meiner Vorredner an.

Anscheinend sind hier viele Leute unterwegs die CAN-Gateways machen 
sollen. Heute vormittag war einer mit PIC da, den ich auf einen 
dsPIC33EP gesetzt habe.

Beitrag "CAN Gateway mit PIC"

Einen PIC32MX795F512 ist auch leicht zu beschaffen und hat 80 MHz, 512k 
Flash, 128k RAM und die beiden erforderlichen CAN-Einheiten.

fchk

[Frank K. (fchk)]

Bruno Kempf schrieb:

> 3.) Diese Frage bezieht sich auf den ersten Teil der 2.) Frage. Der
> CAN-Bus wird mit dem üblichen 9 Pin D-SUB Stecker bereit gestellt. Dabei
> ist auch eine Versorgungsspannung von 24V an PIN 9 vorgesehen. Kann ich
> diese Spannung einfach auf den Eingang vom Verpolungsschutz und den
> Ausgang des Verpolungsschutzes auf den Eingang der Schaltregler geben?

Die SubD9-Standard-Pinbelegung ist ursprünglich von CiA (CAN in 
Automation, www.can-cia.org) definiert worden, und zwar in Standard 
CiA303 Part 1. Zu Pin 9 steht dort in Abschnitt 6.1 auf Seite 9:

"Optional CAN external positive supply (dedicated for supply of 
transceiver
and optocouplers, if galvanic isolation of the bus node applies)"

Auf deutsch: Die 24V dort sind nur für die Versorgung von Transceiver 
und Optokopplern gedacht, um bei galvanischer Trennung DC-DC-Wandler zu 
vermeiden. Die komplette Versorgung des Gerätes über den Busstecker ist 
gemäß diesem Standard nicht vorgesehen.

Du bist natürlich frei, von diesem Standard abzuweichen, solltest aber 
wissen, dass Du das tust.

fchk

[Bruno K. (Gast)]

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

[Antwortgeber (Gast)]

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.

[Antwortgeber (Gast)]

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.

[Rudolph (Gast)]

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.

[Bruno K. (Gast)]

@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

[Antwortgeber (Gast)]

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.

[Antwortgeber (Gast)]

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

[Rudolph (Gast)]

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.

[Bruno K. (Gast)]

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

[Antwortgeber (Gast)]

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.

[Rudolph (Gast)]

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. :-)