Here is a way to use all Arduino Module in NETMF IDEA!

Hello guys,

I’ve been messing around quiet few hardware that are meant for Arduino with the hopes that I can easily use them in NETMF, porting code and so on… but this proved to be a tedious task and I think this is one of the reason why NETMF is struggling to take off…

SO here is my IDEA and i’m hoping to see some interaction and comments from the community and of course GHI or Justin and the likes to build the darn thing :slight_smile:

how about a small, really tiny Arduino board that can act as an Interface to NETMF, so basically instead of porting code to NETMF one would use the module and upload the sketch to this Arduino and through a KNOW GENERIC INTERFACE, the two boards can interact… SPI; UART; I2C whatever you experts think would be best. so an Arduino board that plugs directly to say Socket S or U…

Think of ActiveX and COM…or RLP but with Arduino…

This will give all an easy access to all Arduino Modules… where one would take an Existing Module plug it into the Arduino Interface board test add a couple of function that would trigger something in NETMF through SPI, or whatever interface which would receive the data do something with it and call back a function to Arduino… let Arduino do the low level stuff and report back…

Does it make sense?

Jay.

3 Likes

DaisyLink protocol can be used for that.
What hardware are you talking about on Arduino that you want to use in NETMF?

Daisylink does not have a codebase behind it. Besides, even though Arduino IDE is terrible, yet still much better than Keil…

Do you think of an integrated board with both STM32 and Atmel microcontrollers on the same PCB? Or a Gadgeteer coprocessor module with an Atmel microcontroller and e.g. a SUY socket for the communication with any existing Gadgeteer mainboard?

Btw, for SPI, the NETMF board / component would be the master, Arduino the slave.

Go Bus would be an obvious candidate for the upper layers of the generic interface, but it still seems immature and evolving at glacial speed (if at all), in particular at the application layer - and it may be overkill for such a fixed point-to-point communication scenario.

At the application layer, there are necessarily different flavors of protocols - receiving tag IDs from an NFC reader is something different from sending setpoints to a motor controller. But a simple generic basis for different application-layer protocols would be cool.

I’d like to see whether CoAP (ARM CoAP Tutorial) would be a good choice at the upper layers, as it is an efficient encoding, trivially maps to HTTP, and shares the advantages of a RESTful architecture. Designed to be feasible with 8-bit processors.

In any case, the software stack on the Arduino side should not be so large that little memory is left for the application, which apparently is a problem with the Arduino Yun. So we should avoid this pitfall - keep it simple and small.

We’ve thought along similar lines for quite a while. It is no accident that Mountaineer boards have two SUX-compatible sockets… But at the time we conciously decided not to design something like Go Bus ourselves, as it is simply more work than we could stem in addition to our other Moutaineer projects. Whenever I look at the (non-)progress of Go Bus I am relieved we decided that way at the time. But if someone else had the resources, this might be a great adventure!

If low throughput is sufficient, DaisyLink could be further developed into that direction.

Which reminds me of another possible approach: starting with Windows 8, Microsoft has begun to use HID not just over USB and Bluetooth, but also over I2C:

Do we really need chainable bus here? Possibility to easily reuse existing Arduino code and hardware base looks lot more important to me then another daisyprotocol. It’s rarely needed, IMO. And if a bus protocol is needed, why not using CAN? It’s reliable, speedy, requires two wires only (even sometimes works with one) and is widely used. Not sure how cheap or expensive that would be, though…

Look how many daisylink/gobus modules we have. Barely some. That means they are not that useful…

No. Keep it simple, point-to-point.

Guys what i meant to say is an Arduino board instead of RLP…
So i would take any Arduino module out their hook it up to this board download the library, add a function, event, interface that would send the output of that module to netmf…netmf can do further work and send back the results or use that data to interface with a netmf module like a display… ex:
temp sensor hooked to the arduino board which is hook to netmf board that is hooked to a big nice touch display… sensor sends data to Arduino that sends it to netmf that displays it… a user touches the display netmf sends the touch as a request for a refresh of the temp data to the sensor through the arduino… so Arduino will be what RLP is today, the difference is I don’t have to learn RLP but instead I can use all the existing arduino sensors and libraries available out there.

It could be an arduino board with daisylink integrated to communicate with netmf…but simple straight forward would be better…

Why not just connect a generic Arduino or Medusa to a NETMF board via UART and use serial to exchange commands/data.

1 Like

My point is to make this board a gadgeteer ready to go, with the proper driver interface instead of me learning arduino, learning UART on both sides, hooking it up and so on…

Kind of like Medusa but the other way around with a simple interface to communicate between the two boards…

@ Jay Jay

Not Arduino, but take a look

http://mbed.org/cookbook/DotNET

4 Likes

@ slawek - This is very cool!

Now this is exactly what i’m talking about… Thank you…
imagine having an Arduino Board the size of Cerb40 or Medusa mini with a Gadgeteer Socket on one end that is hooked up to a NETMF Board and interfaces with a similar code in the mbed example above…

now that would open a door for us to use all the goodness Arduino community built over the years, we are talking about thousands of Sensors with Libraries… which will definitely allow NETMF to take over the world of IoT…

No need for Complex Dual Processor Boards, no need for complex Protocols, let each platform do what it does best and have them talk to each other…

I still havn’t seen any comments from GHI, I know they are probably freezing with all that snow, so i’m sure they will shim in when they are back…

Thank you Cuno for your interaction in the Topic, sorry I forgot to Mention you as a potential player in this. :slight_smile: counting on you to help come up with this simple cool board…

btw: I’ve been reading the mbed book, and honestly I like how some of their library architecture is structured, I which we can learn a thing or two from that…and use them in NETMF…
Ex: all mbed as soon as they are plugged show up as a USB Drive in the host machine… binary is copied to that and runs from there… this is great for at least two reasons:

  1. this would cut down on all of those issues that the beginners run into when they first start NTMF. imagine a new user plugs in his board and it shows up as a flash drive with html files that explains the version he has on board, the software he needs to download and any other useful info specific to his board and firmware version… better then telling him hey download this tool update the firmware down this SDK that SDK and so on… remember beginners want to try it as soon as they plug the darn thing, and worry about updates and firmware versions and so on later.

  2. it would allow App Deployement to be made easy… just like in mbed one would be able to copy a .pe file to the folder and boom the controllers detects and loads it…just like we do with .pe dynamic assembly loading but from internal flash instead of a USB or SD… a much easier path to production runs… security can be implemented to stop others from stealing or replace your code in the finished product through the same mechanism we have with hex and MFDeploy… or something easier…

look guys the lowest end of these boards come with 1MB of flash, and over 100kb of Ram, which is more than enough to do this… mbed has kbs and are taking advantage of it…

btw I have seen this done in Hydra using SDCards with a bin file for resetting it’s firmware…so it can be done…

honestly GHI can take the Medusa mini, add an RPC library and a Dedicated Socket that would connect to any gadgeteer board (still can use Extender for non gadgeteer boards through it) and bam start working… suddenly we will all have a one board with Two processors :slight_smile: without the complexity of cramping it all together in one board like micromint has been trying to do with adding another layer of learning how to program in C and al the complex stuff… sorry micromint…I had to pick on you…

Cheers,
Jay.

1 Like

Do you mean like a Gadegteer module that accepts an Arduino shield and exposes those as a number of socket types?

As for Arduino module support, all we would have to do is write a suitable driver.

No, I mean an arduino Board with only one gadgeteer socket that would be used to talk to a gadgeteer board through SPI, IC2 or UART…

So you would use your arduino as you would and control it from your netmf board as we do today with with RLP. Through some cool and easy software interface…

Basically this board would look like the ghi NULL MODEM module where one end plugs into an arduino and the other into a gadgeteer socket… with the supporting library on both platform…

Null modem: https://www.ghielectronics.com/catalog/product/498

Cheers,
Jay.

Why not an Arduino shield that is a Gadgeteer module? Now someone’s going to take the idea and run with it faster than I can :wall:

Yep That would work too ;), but i’d prefer a non shield one, to keep size small and cost down… which would allow the board to blend into the whole system and be unnoticeable :slight_smile: and of course one would be able to use it with all of these tiny Arduino compatible boards :slight_smile:

i’m sure the hardware is very easy to do… it will be a simple wiring if one would choose serial interface… but in the software part where the magic is required…

Cheers,
Jay.

So I looked into it guys I think this will be fairly easy to do…

SO far i think I2C is best for this type of interface instead of the other type of interfaces…

Unfortunately i do not have an Arduino to play with… so i will get started with the NETMF side of the code and try to come up with a draft interface…

So who’s in???

Hi Architect, I just reread your Blog entry today and noticed how you have been through this path and was wondering if you can share your findings, I think What you have done will be the basic block to give us access to all Arduino Sensors and libraries…

Arduino Daisylink Library is the answer, and frankly I don’t know why wasn’t this done in the first place instead of targeting the M0 as a the chip they should have targeted Arduino as the target chip for the daisylink protocol first and later introduce the M0 as a target this would have made porting all of those Arduino Sensors to NETMF a Breeze I think… am I wrong?

GHI a medusa like with Dasylink protocol that looks like the DL40 will be the answer ;), which we can program with Arduino IDE, plug the Arduino Sensors, using the broken out pins, Plug it into the gadgeteer board Socket and control it all you want :smiley:

Cheers,
Jay

actually this is exactly what I have been working on for a while now, arduino nano sized board with 2 gadgeteering ports for daisy link interfacing. i.e. dl40 but with arduino instead of m0 cortex chip.

I think this is easy way to add a lot of functionality and modules. I love the netmf based main board and the high end capability they have, but obviously this is too much work to add these sorts of chips to a small sub board, but by using a small atmel chip on a sub board a vast realm of possibilities appear.

also I find the rlp side of things quite daunting, whereas a arduino based sub board is a lot easier for me to build and develop, however that’s not to say the daisylink protocol is easy to implement but I`m getting there with it and its a fun thing todo over the winter months.

4 Likes