Does GHI ever leverage this?
We have seen it but I don’t think we have needed it so far
1 Like
ThreadX is more for hard-real-time systems. It’s great quality-wise, but it’s not free (the code is available in source-code format, but it is not free-to-use, and Azure ThreadX comes with some Microsoft/partner tie-ins). It might be great for a PLC or vehicle control-loop running on bare metal, but not sure it fits in anywhere here.
1 Like
Around here, if we want determinism, we’ll use an FPGA or a barrel processor.
1 Like
I think the real value of Azure ThreadX is that Azure IoT is baked into the OS. So if you are going to be doing hard-core Azure IoT on a large scale with 10’s thousands of devices it probably is a good place to start.
The basics of Azure IoT are pretty easy to implement on almost any processor that can handle MQTT and TLS.
That MQTT stuff is expensive to implement. Also, Endpoint supports the entire .net 8 framework anyways. It is potentially much cheaper to have Endopint push data into SQL Azure than to have to route data through MQTT.
I had to do it as a test project for a temp sensor whose data was to be surfaced in PowerBI. It’s much cheaper to use a pocket beagle than MQTT stuff via nanoFramework on an ESP32 (sorry, Gus, I know you don’t like discussing other people’s products on here, but the info might help someone).
1 Like
MQTT is a pretty light binary protocol. Azure IOT makes it heavier because it uses a JSON payload but that isn’t MQTTs fault.
I am running Azure IOT on a SCM20100E which has no external RAM. Azure IoT requires TLS and I am connecting to the internet with a cellular modem using PPP. I have to keep an eye on my RAM usage but I can make it work.
Certainly, Endpoint will make Azure IoT easier because it has more resources. But SITcore running TinyCLR is very capable of working with Azure IoT.
1 Like