Main Site Documentation

Bluetooth PAN

#1

I have a platform question. I don’t see Bluetooth PAN support in NetMF.

Looking around, some Bluetooth chipsets handle some of the PAN profile in the BT IC, but it looks like at minimum a host EDM driver is required:

http://support.connectblue.com/display/PRODBTSPA/Bluetooth+Serial+Port+Adapter+PAN+Profile

In NetMF we have an Ethernet stack, and the ENC Ethernet chips GHI uses effectively do a similar translation, taking SPI data from the ENC chips and pushing the raw packets out into the network layer.

I see the Open Source library is here as a nice example, which I guess I could use to write a platform level driver:

Can you write packet drivers in C#? Or, can end users write C++ packet drivers for use with the Premium library?

Of course, perhaps this has been done before, but Google doesn’t show anything.

Thanks!

#2

mIP is an option, but it’s an odd beast, as it doesn’t supply a Socket interface (or at least, it didn’t when I looked at it ages ago…).

You could probably write a driver similar to GHI’s for the OSHW board, but don’t expect them to take it as a patch, they don’t generally take community contributions (as it might lead to competition with Premium offerings…).

You could probably have them write the driver for the Premium products, but it’s not going to be cheap.

#3

Thanks.

mIP looks interesting and also has an example ENC driver. I suspect I could get something working using that as a starting point. Seems odd adding a second IP stack, but is something to look at.

#4

It’s not as odd as it seems. Writing a platform-level (unmanaged) driver requires recompiling firmware, and the current firmware requires a compiler that costs thousands of dollars. The only real option is to write a managed driver, and voila, mIP was born.

#5

Both the Hydra and Cerb firmware can be compiled with GCC.

The Hydra firmware compiles with GCC as is from codeplex.

The codeplex code for the Cerberus firmware requires some tweaks, but this is something that some of the members here have done. The effort involved is relatively minor now that others have cracked the nut.

#6

Not because competition but because we want better control and better quality of the open source firmware. we have always welcomed a community version of the firmware with all extra features.

#7

Control, yes, that’s what I said. As for quality, are you suggesting that the features that have been created by the community are of poor quality?

#8

Any code will probably have a bugs, no matter who writes it. Once we include a feature developed by someone else and ship to our customers we are at that point responsible for that feature’s outcome. We can’t say “this is a community feature so go talk to godefori about it” for example. At that point, we are stuck fixing the issue ourselves, which means we need to understand godefroi’s code and the feature itself, which can be very difficult and expensive.

The problem is not in community using it, since they understand the situation, but in commercial customers who are typically not on this forum and they expect everything to work perfectly, no matter who wrote it and of it is open source or not.

We talked about this sometime back and we explained this. If you or anyone wants to take charge of a community firmware we would welcome that and we would even help whenever possible. And of it even competes with the premium offers we would welcome it more and help more!