Just in case you didn’t think IoT was going to be the next wave in computing.
What is more interesting is the opening statement
So IBM is far from the only biggie that is going all in with IoT so good time to be a Gadgeteer dude riding in front of the wave, Akaw!
When IBM hears “Internet of Things” they hear the same thing Microsoft hears, which is, “big data and analytics, running on lots of high-margin hardware in high-margin datacenters and running high-margin software”.
Or are they spinning up a new hardware engineering unit to produce low-cost mass-produced WiFi modules, or a competitor to ARM cores?
@ godefroi - They’ve partnered with mbed as being a “recommended” mbed partner and their contribution is the cloud. Free open source IoT OS and development tools from Arm | Mbed and IBM Developer
I am still surprised to see the amount of backing mbed gets from everywhere…???
@ njbuch - I’m not sure surprised is the word, ARM made a huge investment for the commercialization of mbed, I will be surprised if there are any small companies like ours involved in the future if they are not already involved.
@ Gary - involved or evolved? ;D
Please explain…???
Why are you surprised?
I have recently been playing with CMSIS directly (LPC810) and of course I have been exposed to mbed through the GHI/OC offerings, I think mbed is amazing, simple enough libraries, consistent across devices, performs pretty well and if you need even more performance it is all within your reach. CMSIS is significantly harder to work with, mbed is only slightly harder than .NETMF and in some ways almost easier, not struggling with installing drivers, updating firmware etc. it truly just works, YMMV.
Now honestly I do still think that the Gadgeteer hardware platform is awesome. I think a native library built around that interface would be amazing. I did a demo awhile back where I implemented a few of the NETMF interfaces including full threading in C++ and it is possible to come very close to the .NETMF experience. And of course for a one off $50/$60 you can get a JLink EDU that will give you a really good debugging experience as well.
For me I would go with .NETMF/Gadgeteer for the primary control and then use mbed/native modules to offload any real-time work or if I needed additional peripherals, the best of both worlds. mbed makes that integration really easy, want a basic SPI client to communicate with you NETMF/Gadgeteer mainboard mbed makes it about as easy as possible to do, sure it is not interrupt driven etc. but it works and it is easy and if you need more you can still do it.
@ taylorza - Good points.
But my primary angle of attack has always been from the hardware side, being able to modify the hardware setup in a few minutes and thereby being able to cater customer needs much better by enabling a rapid prototyping approach on the hardware side.
Thats why I think the Mikrobus.net http://www.mikrobusnet.org/who-i-am is attractive as I get NETMF with a sturdy and yet very flexible hardware setup. I know there is an ongoing discussion as if Gadgeteer cables can go into a final product, but most customers dont think so. The clicks can actually fit professionally onto a final product.
Mbed does not have a hardware prototyping framework, and thats why I still think its strange that makers big and small and talking so much about it… :think:
Let me clarify, when I say “involved” I mean involved as a “recognized partner” or a “listed partner” on marketing materials. I say this because mbed is using a “pay to play” business model. If you want to be listed a “partner” you have to sign a contract and pay a annual fee. That annual fee allows you a certain number of “official” platforms. If you want more “official” platforms listed then you have to pay more money. We just happened to have entered right before they cut off public adding of official platforms. But it wouldn’t surprise me if we got an email saying that if we wanted to continue to have a platform listing then we would need pay.
While I understand the need for ARM for monetize mbed, the fees and contracts IMO will keep companies like GHI from further innovating any new “official” platforms and related products. For example with Microsoft, for any information or any access that we may or may not have, we have not paid them any membership dues.
[quote=“taylorza”]
I did a demo awhile back where I implemented a few of the NETMF interfaces including full threading in C++ and it is possible to come very close to the .NETMF experience.[/quote]
@ Taylorza, did you ever publish anything on this ? I was hoping to see something after you mentioned this several moons ago 
[quote=“Rajesh”]
Me too!
@ Gary - I did not know that mbed is now a “pay to play” business model, I missed that important point. That may be limiting.
@ kiwi_stu - it’s only pay-to-play if you want to be listed as an official partner or have an official partner platform. It’s free to develop if you have compatible hardware.
I do not know anything about Mikrobus.net, but as I understand it the hardware standard is Microbus by MikroElektronika and Mikrobus.net is an implementation of .NETMF using that hardware standard. In the same way mbed could be implemented on that same standard. If I have missed something regarding Mikrobus and the .NETMF implementation I apologize, that is purely my ignorance.
[quote=“Rajesh”]
No, for two reasons. Firstly I discovered mbed (via mbuino) shortly after that and felt that there is probably not any room for yet another native library “standard”. I still think it is a cool idea, I like the .NETMF library interface, but there is also nothing wrong with mbed. Now if I thought people would actually go for it and support the library I would happily pursue it further, but honestly my impression in this space is that it would not be of significant value other than the learning experience for myself.
Thank you for the update. I think I am taking this out of context of this topic, but I have not been able to do anything with the Gadgeteer/NETMF as I been busy building a large application on iOS/Android with wireless sensor boards pushing data over 2.4Ghz radio.
I used to think that the pefect framework / chipset required to have everything : USB host, device, SD, RGB LCD etc. etc. but now I am thinking more on the lines of low cost and simple. Something that is easy to start, has proper abstraction, has a built in scheduler (RTOS ??) and support the basic stuff like timers, GPIO, SPI, I2C, RS232 is good enough. If I need a display I would prefer to use a phone / android or linux board or just send the data to a web server.
NETMF is attractive for the debugging capability but can be done using mBed offline, uVision and DAP.
Do I need a M4 device to do something that an M0 would do ? If I dont need a display do I need more RAM/ROM ?
These may sound like a begineer question but I have been away too long to start to think different this time.
Taylorza… over the years I have learnt several things from you and will appreciate your thoughts.
@ Rajesh - I believe we are in agreement. My preference is to used small scale devices for those specialized/real time tasks and then use heftier mainboards running .NETMF with more complex control software to orchestrate the satellite modules. For even more complex interactions you use your android device to communicate via (your favorite protocol stack) with the .NETMF board which in turn manages the satellite devices.
Most recently I have been playing with the LPC810 an 8 pin breadboard friendly DIP ARM Cortex-M0+. In my toy scenario it does the work of driving a Ping sensor and the mainboard can ask for the current reading via SPI, just a proof of concept not really for anything real right now, but I consider this type of thing an interesting mix. Dealing with the Ping sensor is challenging** in .NETMF in terms of timing etc. but straight forward in native code.
I want to see how far I get porting the mbed libraries to the LPC810, there are some interesting challenges but it is a super fun little chip.
** I did not say it can’t be done, but it just barely works…