USBtin - Maximale Geschwindigkeit? - Alternativen mit AVR

Hi  Patrick,

ich habe den USBtin hier mit einem 1Mbaud-CAN Bus verwendet, dabei 
verliert er leider öfter Pakete. Das ist auch nicht verwunderlich, weil 
er für die CAN-Schnittstelle den MCP2515 über die SPI-Schnittstelle 
benutzt.
Wie weit Du mit der Baudrate runtergehen musst, damit keine Daten 
verlorengehen, kann ich Dir leider nict sagen.

Gruß, Stefan

Stefan U. schrieb:
> Du hast gar nicht gesucht. Wenn man bei google "AVR Can" eingibt, werden
> einem direkt Bilder von diesem Teil geliefert:
>
> http://www.watterott.com/de/AVR-CAN
>
> Sowie zahlreiche andere Alternativen.

Doch doch, gesucht habe ich schon. Wollte aber erstmal die Meinung 
anderer hören^^

Dein Link sieht auch sehr interesant aus. Danke!

Ich finde diese Umsetzung 
(http://www.kreatives-chaos.com/artikel/can-debugger) sehr interessant, 
ich kann aber leider nicht zweiseitig Ätzen, deswegen wird das wohl 
nichts...

Stefan K. schrieb:
> Ich habe den USBtin hier mit einem 1Mbaud-CAN Bus verwendet, dabei
> verliert er leider öfter Pakete. Das ist auch nicht verwunderlich, weil
> er für die CAN-Schnittstelle den MCP2515 über die SPI-Schnittstelle
> benutzt.

Ok, sowas in der Art habe ich vermutet. Ich denke aber nicht, dass die 
SPI da der Flaschenhals ein kann. Wohl eher die Verbindung zwischen PC 
und USBtin.

> Wie weit Du mit der Baudrate runtergehen musst, damit keine Daten
> verlorengehen, kann ich Dir leider nict sagen.

Da kann ich nicht dran drehen, weil ich ja den Datenverkehr im Auto 
mitschneiden möchte, da ist die Übertragungsgeschw. ja fest.

Patrick L. schrieb:
> Ok, sowas in der Art habe ich vermutet. Ich denke aber nicht, dass die
> SPI da der Flaschenhals ein kann. Wohl eher die Verbindung zwischen PC
> und USBtin.

Leider doch. Der mc muss nicht nur die reinen CAN-Daten über den SPI 
einlesen. Für jede Status- und IRQ-Abfrage an den MCp2515 muss eine 
SPI-Übertragung gestartet werden. Dadurch steigt der Overhead extrem. 
Ich habe selbst den MCP2515 in einem Projekt verbaut und fand das damals 
extrem nervig.

Hast Du schon einmal darüber nachgedacht, den STM32F103 als 
CAN-Controller einzusetzen? Billiger als ein AVR mit CAN und mit 
deutlich mehr Leistungsreserven.
Es gibt bereits integrierte optoentkoppelte CAN-Transceiver. Habe ich 
selbst noch nicht benutzt, wurden hier aber schon öfters erwähnt.

Gruß, Stefan

Stefan K. schrieb:
> Leider doch. Der mc muss nicht nur die reinen CAN-Daten über den SPI
> einlesen. Für jede Status- und IRQ-Abfrage an den MCp2515 muss eine
> SPI-Übertragung gestartet werden. Dadurch steigt der Overhead extrem.
> Ich habe selbst den MCP2515 in einem Projekt verbaut und fand das damals
> extrem nervig.

Ahh, alles klar. Wieder was dazu gelernt. Das scheint ja auf jedenfall 
so der Standard-Chip zu sein, der auch bei vielen Selbstbauprojekten 
eingesetzt wird.

> Hast Du schon einmal darüber nachgedacht, den STM32F103 als
> CAN-Controller einzusetzen? Billiger als ein AVR mit CAN und mit
> deutlich mehr Leistungsreserven.

Ja, habe ich schonmal nachgedacht drüber. Ich setze diesen auch schon in 
Verbindung mit einem STM Discovery Board ein. Allerdings noch nicht mit 
CAN, immer nur Gyros und Accelerometer. Das hört sich aber womöglich 
nach der besten Lösung an!

Was mich an den STM32 immer gestört hat, dass man da immer soviel vorher 
Konfigurieren (PLL, ...) muss bevor der läuft. Außerdem habe ich mit dem 
noch nie ein Layout gemacht, dementsprechend habe ich keine Ahnung von 
der Minimalbeschaltung. Und Breadboard tauglich sind die Chip-Gehäuse 
auch nicht.

> Es gibt bereits integrierte optoentkoppelte CAN-Transceiver. Habe ich
> selbst noch nicht benutzt, wurden hier aber schon öfters erwähnt.

Ich weiß gar nicht, ob ich das umbedingt brauche. Ich glaube die 
amtlichen CAN-Debugger haben auch keine galv. trennung

Patrick L. schrieb:

>> Hast Du schon einmal darüber nachgedacht, den STM32F103 als
>> CAN-Controller einzusetzen? Billiger als ein AVR mit CAN und mit
>> deutlich mehr Leistungsreserven.
>
> Ja, habe ich schonmal nachgedacht drüber. Ich setze diesen auch schon in
> Verbindung mit einem STM Discovery Board ein. Allerdings noch nicht mit
> CAN, immer nur Gyros und Accelerometer. Das hört sich aber womöglich
> nach der besten Lösung an!
>
> Was mich an den STM32 immer gestört hat, dass man da immer soviel vorher
> Konfigurieren (PLL, ...) muss bevor der läuft. Außerdem habe ich mit dem
> noch nie ein Layout gemacht, dementsprechend habe ich keine Ahnung von
> der Minimalbeschaltung. Und Breadboard tauglich sind die Chip-Gehäuse
> auch nicht.

Dann nimm doch einen dsPIC33FJ64GP802-I/SP. 28SDIP, 40 MHz, 16k RAM, 
ECAN drin (eine deutlich verbesserte Version dessen, was im MCP2515 ist, 
minus dem SPI-Interface natürlich), DMA drin.

Oder dsPIC33EP128GP502-I/SP, quasi das gleiche mit 70 MHz statt 40.

fchk

Sowas wie das hier kannst Du auch als DIP-Replacement nehmen:

http://www.watterott.com/de/STM32F103TB-ARM-Cortex-M3-Development-Board

Wobei Du schauen musst, ob da alle Pins herausgeführt sind, die Du 
brauchst.

Auch wenn das Konfigurieren der Cortexe etwas komplexer ist: im 
laufenden Betrieb sind sie wesentlich umgänglicher. Einen MCP2515 kannst 
Du praktisch kaum debuggen, weil seine Register mit dem Debugger nicht 
zugänglich sind.

Bei diesem Board hast Du übrigens schon einen CAN-Transceiver onboard:

https://www.olimex.com/Products/ARM/ST/STM32-P103/

Gruß, Stefan

Alles klar, ich werde mein Glück mal mit einem STM32 versuchen^^

temp schrieb:
> Hoffentlich vergesst ihr beim STM32F103 nicht, dass der nur USB oder CAN
> kann. Beides gleichzeitig geht leider nicht.

Das wusste ich jetzt nicht, wieso das?

Oh ich seh schon... Das ist ja uncool:

Beitrag "STM32 USB und CAN gleichzeitig nutzen"