What about CAN? How to get access on CAN, using a FEZ Cerbuino Net Board?

Dear Community,

I suppose that this it the typical way to get CAN / Bluethooth or whatever going:

  • Using I2C, SPI or UART via Microsoft.SPOT…
  • to communicate to another chip providing CAN / Bluetooth or whatever wanted.

Is that right?

Does GHI.IO or any other library from GHI provide access to further hardware (e.g. for FEZ Cerbuino Net) making further external chips unecessary?

Assuming GHIs libraries are prividing such an access to the CAN-hardware of the Cerbuino microcontroller: How does this access look like? How many OSI-layers do I have to write on my own?

Will .NET Micro already be installed with such further GHI-libraries if I buy a FEZ Cerbuino Net Board?

What about updates? How can I get the actual GHI-library when I will already have such a nice board?

Thank you very much for all your answers!

CAN is supported. Just use the latest software.

Start simple, download the latest SDK and blink an led, then look into other features. Take a look at the support page for everything you need please.

And here is a link for you

1 Like

Hi Wutz,

I’ll elaborate as well.

You have the right idea - most devices are communicated over some form of inter-device communication channel like I2C or SPI or UART.

For BT and BLE, as well as CAN, that is almost always UART (I don’t remember seeing a device that was not).

If you buy a Cerberus device you can use one of these modules https://www.ghielectronics.com/catalog/product/311 that uses a C socket. The Cerbuino devices do NOT have a C socket so can’t simply use this module.

Whatever device you purchase, they will come with a firmware on it - but you should always update it to the latest, that gets installed when you install the GHI SDK. This is an easy update process, so you won’t have a problem.

Thank you very much, Brett!

Please tell me if I missunderstood anything:

A TJA1050T IC from NXP is placed on the module you mentioned.

  • This means I don’t need to think about OSI-layer 1 and 2, as they are already implemented as hardware in TJA1050T.
  • This IC is a bridge between uC-CAN-Pins and the physical CAN-network.

About which C-code are you writing?
Is there any further code to be placed outside of the Cerbuino-Board?

I think there is no chance to place C-code besides or below the .NET-Micro on the Cerbuino-Board. Is that right?

When I said C socket, I meant the letter C not the language. C on a Gadgeteer socket is a CAN enabled socket.

It seems like you may not quite understand what netmf is and what you’re asking here about. A quick rundown is that netmf provides an operating environment for user-written code, running on a hardware platform. And Gadgeteer are some additional libraries that wrap certain devices (modules) with drivers that make them easy to program. Netmf is programmed in C# or VB.

What we discussed above was a dual solution - hardware to meet the CAN bus connection, as well as the first two software layers necessary (not to be confused with OSI layers!). Hardware wise, you use the CAN module plugged into a Cerberus (or other mainboard that has CAN capability on a C socket). Software wise, the Cerberus comes with a netmf firmware loaded which you can then keep updated (as I mention, update it when you get it) and you can then create your user-written code leveraging the Gadgeteer module’s driver, and deploy that to your Cerberus. That then means you never have to delve into the depths of C code for the microcontroller you’re using.

Your C# code then just needs to deal with the data that you can get off the bus (via the driver). Does all that help give you a little more idea about how you can achieve this ?

Hello Brett,

thanks again for your immediate anwer!!

You where right: I did not know about the expression C-Sockets related to Gadgeteer - as I am out of the embedded world, not being a solely .NET-developer.

I think I got the point:

  • .NET-Micro seems to be a “monolytical framework”, having hardware-drivers inherited, not allowing to place further code (e.g. C-Code) besides it.
  • The only way to use .NET-Micro is programming within .NET (C#, VB)
  • The only way to include further drivers is doing this within .NET, as done by GHI-Electronics for its products.
  • Besides to those hardware-drivers included within the .NET-Micro; external hardware-bridges can supplement such hardware related code (as eplained on the CAN-expample).

I think you will fully agree to what I understand, right?

No, that’s not correct. There is a GHI feature called “RLP” that allows you to load limited C/C++ code in conjunction with Netmf. But if you wanted to remove netmf, the Cerberus is purely a STM32F4 based hardware platform, but then you have to do ALL the hard work that NETMF includes.

To program in Netmf you need to program in C# or VB (but that’s not exactly what you said). Netmf is different to .Net, so don’t get them confused. Netmf doesn’t do everything you can do in .Net. You don’t have to be a .Net developer to program for Netmf, but if you were I can imagine the transition time would be very quick.

No, that is not correct. You can extend hardware however you like. You would write the driver in C# (managed driver) or if needed you could drop down into C/C++ on GHI’s products you could use RLP. But largely, most features can be done in managed code, so it’s unlikely that you would need to go outside netmf for a new driver.

This is no different to any other hardware device added to a microcontroller - you use IO pins to interface between the micro and the other hardware, and your driver understands how to talk to it, so I am not sure what distinction you want to make here ?

No I didn’t :slight_smile: