Azure RTOS?

Just saw this announcement from Microsoft and was wondering where this might fit in the GHI/TinyCLR world in the future. Any thought been put into it?

Ian

It is interesting to see Microsoft and Amazon running head long into the true embedded world to feed their respective IoT cloud services. Microsoft purchased ThreadX which give them a closed proprietary embedded RTOS. ThreadX was quite expensive for the licensing if I recall. I was hoping Microsoft would open it up as open source but the press release @ianlee74 shared indicates that it will be a paid license. Microsoft’s Sphere hardware is a nifty little multi-core linux solder-on module, but with very limited I/O support. Unlike GHI SITCore that has everything you could need, including the kitchen sink!

AWS on the other hand is using FreeRTOS which is open source.

I am hoping for more SitCore examples featuring Azure IoT and device provisioning. Everytime I start down the Azure IoT road map I get a little overwhelmed. Just when I think I have their ecosystem figured out they add something new.

You can fight it or just use TinyCLR that already works with azure, AWS, Google cloud, iftt, adafruit io…

With debugging and C# :nerd_face:

But sure I want to hear about other options

2 Likes

Azure RTOS is an answer to Amazon FreeRTOS and even without those two os’s you can use other os for example mbedos,even arduino too …

and from GHI we have already TinyCLR OS capable to connect to Azure,Amazon supported services (network,mqtt,tcp…) included latest security (tls 1.2,1.3 …) also code security too…

so i am not an big manufactory that i can benefits from Azure RTOS (complex c++,threadx way of work …) so in this case maybe GHI have any benefits to create TinyCLR on top of this but (they already have better version on bare metal which include everything) and only missing part was an vscode extension for crossplatform development and debug .

so in my opinion i do not show any benefits for us from Azure RTOS

I agree, I see TinyCLR 2.0 as a much better option for me vs Azure RTOS. At least for the projects I am currently working on for the forseeable future.

Thinking about this some more, this rtos is a perfect fit for small sensors if your want to run on a sub dollar chips

I thought in Amurica bigger is better - if it does go fast enough give it more cc’s :rofl:

In

Yep Amurica choose SITCore and everyone wanting it bigger and better :wink: once you go SITCore you can’t go back!!!

use TinyCLR that already works with azure, AWS, Google cloud, iftt, adafruit io…

I’m kinda playing catch-up here and not speaking as an expert in either TinyCLR or Azure so feel free to educate me. But, what I was thinking when I saw this was that TinyCLR on top of an Azure Sphere certified chip would be a match made in heaven.

It’s one thing to say that TinyCLR supports encryption and any developer can then take that capability and build a good security solution that could then authenticate to Azure or AWS. However, there’s a totally different level of trust that comes with saying the chip itself has Azure Sphere certified security (authentication, OTA updates, etc.) baked into it before the developer even has a chance to screw things up… I think we know by now that very few people can actually build security solutions correctly and the more that we can leave to experts to do for us the better the entire IoT ecosphere will be.

Unfortunately(?), my current gig keeps me away from the cloud but my software (literally) runs in the clouds and security is always a first thought. So, that’s where my head goes these days before any whizbang features. I think if anyone is saying that just because a chip supports SSL that it is comparable to an Azure Sphere certified chip then that’s like saying this…

…has the same capability to be secure as this…


because they both shoot bullets.

As I said, I don’t have any practical experience with Azure Sphere or TinyCLR in production but this is the way I read it. I certainly do not intend to belittle GHI or TinyCLR in any way. They are both top-notch. I just see the IoT world evolving in a (much needed) direction that requires end-to-end security baked in and from what I’ve looked at so far Azure Sphere in combination with the other Azure IoT services is where I’d lean at least from “the edge” to the cloud. Simpler solutions such as bare TinyCLR chips still have plenty of good ways to be integrated into this.

My thoughts…
Ian

Nothing is 100% secure. That said, we want to build SITCore to be secure enough for most applications. Secure that there is no need for sphere for most. Yes there will be applications where sphere or more is needed but for our customers we already have secure it’s updates and and system completely runs on internal memory.

Yeah yeah we do not have the security experts that Microsoft has but we have long experience and wide range of customer base from every sector, including military!

I don’t mean to imply in any way that what you have isn’t secure. I’m sure all the building blocks that SITCore provides are great. But, that doesn’t do anything to ensure that the developer puts them all together correctly or that the infrastructure that they connect to can recognize that they are legitimate. That’s where I see the gap that Azure Sphere fills in nicely. I have no idea what’s involved in becoming a “certified” chip but it seems a .NET chip such as TinyCLR would do very well in that environment. Just thought it might be something for you to think about.

1 Like

One thing that this doesn’t change is the economic equation behind TinyCLR. TinyCLR may require a bit more hardware to support its runtime needs, but you can do more with it with less engineering effort. So for small unit counts or where you will need to make frequent code changes, TinyCLR is more economical to develop for and reduces time-to-market.

In situations where you will be shipping thousands of units, then you are multiplying that bump in BOM cost across more units and that accumulated cost will overwhelm the savings in front-end sw engineering cost. The economics change in favor using native code and cheaper MCU BOM components. The higher front end cost will be amortized over more units and the more you ship the more this works in your favor.

The exact tipping point in that equation is something I hope everyone in the commercial space takes the time to work out as part of their project planning.

I’ve lived an example of this over just this past week. I have put in a total of 3.5 working days on my front-panel app and I estimate I would have put in on around 3+ weeks of work in native code. The deployment target for this app is in the hundreds.

BTW, both Azure RTOS and TinyCLR are both free to ship into productions, so long as you use chips from their authorized vendors: STMicroelectronics, Renesas, NXP, Microchip, and Qualcomm for Azure RTOS, and GHI for TinyCLR. You only pay for Azure RTOS if you taken the open source to another hw platform.

@mcalsyn - I don’t disagree with any of that. However, I wasn’t really thinking Azure RTOS vs TinyCLR but more asking the question of is Azure RTOS + TinyCLR (on one chip) something that’s possible or worthwhile so that there could be an Azure Sphere certified TinyCLR chip (SITCore 2.0?)?

I do not see it as a “+”. They replace each other.

Yeah - agree with Gus - that would be a weird blend with a lot of duplicated functionality. Building the scheduler for TinyCLR would be a bit of a nightmare too. I could see maybe a dual-core system with one core running a native-code RTOS and the other running TinyCLR for UI and networking if you really need a native-speed/RTOS co-processor.

I think Azure RTOS is ok for those folks that must develop native code - gives them a leg up. But except for deterministic execution time, we have everything else already in TinyCLR - even the ability to include native code.

1 Like

But except for deterministic execution time, we have everything else already in TinyCLR - even the ability to include native code.

I’m going to stop here because I don’t feel I’ve done enough research to be confident that what I’m suggesting is 100% accurate. But, what I think I understand about Azure Sphere and certified chips is that they have native baked-in authentication, chip & program validation, and a root of trust that extends from the factory floor all the way to the cloud. The key here that I’m emphasizing (as I understand it) is that this entire root of trust exists without the developer doing anything (and despite any poor developer engineering?). This is getting muddied by the fact that I was suggesting that an easy way to get certification might be to put TinyCLR on an already certified chip. I suppose the easier way if it was something of interest would be to just get the SITCore chips in a state they could be certified. It was just an idea…

Great minds think alike! Can I let you in on a secret, under NDA? A year ago, we had multiple calls directly with the people in charge of azure sphere. What we want is to use azure sphere as a base micro and put TinyCLR on top. They are very interested. C# is the #1 requested feature on azure sphere. I am not going to say more before you buy me some alcohol!

Also, the reason SITCore and TinyCLR are separate is because SITCore can run other software, like python. And TinyCLR can run other hardware, like azure sphere.

6 Likes

Great minds think alike!

Indeed! This is exactly what I was hoping to hear :smiley: Once I can leave the house again, we’ll have to go get that drink!

1 Like