8 replies to this topic

[Colin Taylor]

Hi all

 

I have a project that requires CANbus - or more specifically, two CANbus networks (they run at different speeds).

There aren't many messages so I'm not worried about latency too much at this point.  

 

I see on the datasheet for the CPU in the N+2 that it supports 2x CANbus interfaces.  However, lots of googling shows that it's not in the NetMF/Netduino SDK.

 

What is involved in creating support?  Some sites mention that it is too hard for MicroSoft to build onchip support as there are too many CPUs, but I'd be willing to have a go - trouble is - where do I start?

 

Thanks in advance

 

Colin

 

[NooM]

i dont think that will work, not only that you have to write the

native drivers yourself, the pins it nuses have to be broken out also.

 

id go with a spi <> canbus ic

[CW2]

Netduino Plus 2 microcontroller has the ability to configure alternate function mapping for its peripherals, so the CAN interfaces can be accessed via pins D5, D6 (CAN1_RX on PB8, CAN1_TX on PB9), resp. D4, D13 (CAN2_RX on PB12, CAN2_TX on PB13).

The CAN interface on STM32F4 does not include physical layer transceiver, so I would start with that - popular option is for example MCP2551, or SN65HV series by TI.

 

Then, I would create a prototype application, implemented in C/C++, perhaps using one of the existing libraries, I think the standard peripheral library by ST already contains CAN driver. The reason for this is that .NET MF is large and significantly affects (slows down) deployment and debugging, also it is much harder to troubleshoot anything in such complex system.

 

Based on the overall evaluation of the application, I would decide whether it is needed to include the functionality in the .NET MF itself, or whether any alternative is better (leave CAN interface implemented on separate microcontroller/board, use SPI-CAN bridge (e.g. MCP2515) as suggested by NooM etc.). GHI Electronics has included CAN support in their Premium library (GHI.Premium.Hardware.CAN), this could serve as inspiration for designing the managed API. By the time you get here, creating a new .NET MF interop project and adding it to the firmware will be piece of cake...

 

Note: If the project is for automotive, then there are ready to use solutions available for a few bucks on eBay, those various OBDII cables and modules are basically CAN to serial/USB converters, usually with a micro to parse the protocols.

 

Welcome to the community!

[Colin Taylor]

Thanks for the replies.  

 

The project is for automotive, I want some dashboard equipment from one make/model of vehicle in my own vehicle, hence the need for two canbus interfaces.

 

I like the idea of a very low level C++ application that should outperform the NET MF stuff.

 

I've used ASM on the PIC, but I don't (yet!) know C++ so I'm going to have to learn a lot to get going. 

 

Can you recommend a simple "hello world" guide for programming the STM32F4 from a C++ source?  

 

Thanks

 

Colin

[CW2]

There are examples (general I/O, CAN and more) included in ST's STM32F4 DSP and standard peripherals library and Mark Stevens has published some very nice articles on his blog. Also, popular toolchains usually come with examples for STM32F4, like STM32F4-Discovery board - it has the same microcontroller as Netduino Plus 2, only with different crystal, so one change (in PLL settings) is required to port the code. Also, STM32F4 are basically STM32F2 "on steroids", so the existing code for F2 should not require too much porting work, although I don't know exactly the differences related to CAN interface, ST has published a migration guide that describes the changes...

 

In case you would be heading towards low level C++ application (*), then you might want to check out PIC micros, they are available with CAN interfaces too. On the other hand, this would probably end up functionally very similar to the existing SPI-CAN bridge (?)

 

(*) I've suggested it based on my experience, it is much easier to start integrating into .NET MF something that is proven to be working. Clearly each approach has its own pros and cons, you'd have to evaluate them and then decide what's best for your particular use case ; )

[Colin Taylor]

CW2

 

Thanks again for the comprehensive and precise answer.  Very much appreciated.

 

I'm trying the C++ route - and am trying out CoIDE as mentioned in Mark's blog.  Seems quite good so far.

 

Now to get to grips with how to actually push code to the N+2.

[Colin Taylor]

I guess the CoIDE needs to use an ST-Link device to connect to the N+2 rather than the built-in USB port, right?

[JerseyTechGuy]

I guess the CoIDE needs to use an ST-Link device to connect to the N+2 rather than the built-in USB port, right?

 

For C++ I believe this is correct.

[Colin Taylor]

OK - ST-Link (and [color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]STM32F4-Discovery board with built-in ST-LInk) on their way from Farnell [/color]

[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;]Thanks for all the support   [/color][color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;] [/color]