Thanks for your comments. Yes, you are right. Writing S/W abstractions to do register twiggling for all the AT commands or for other devices can make any body question their existence :-))
Indeed HW abstractions seem to be accepted so widely and profilerate while same cannot be said for S/W drivers.
I wish major IP vendors can agree on low-level driver abstractions for set of device-class and they deliver this implementation with the IP. Imagine the benefit it will open for folks who deal with firmware or OS-layer or for verification folks.
Few weeks back we were talking to a senior folks in networking switch company and they mentioned that they have stopped asking S/W team to deliver low-level drivers. It is now the responsibility of verification folks to deliver them. So someone at SoC level, who has to deliver S/W with H/W down the chain, has already started thinking in this direction. Imagine if IP vendors can think in the same manner and deliver this S/W abstraction with IP.
I think we are at the curve and things will turn around.
It's great to see this topic addressed! I am sick of having to deal with badly designed low-level abstractions - like a driver for a GSM M2M module I am currently writing. AT commands in the 21st century? We should be able to do better than that...
Modern embedded systems often contain multiple microprocessors, so they are basically distributed systems (meaning partial failures are a key design challenge). SoCs may have multiple cores, usually specialized for specific tasks. Thus we might learn from robust distributed system architectures like the Internet. One approach thus could be to use a RESTful architecture approach (idempotent operations that can be repeated after an error, without danger of creating inconsistent state). Obviously, we don't want heavyweight protocols and formats like HTTP and XML just for communicating between subsystems of a device, or within a chip. But maybe an even further stripped-down version of CoAP might make sense?
Another approach would be to define a USB-like plug-and-play standard for use within devices, rather than to connect different devices. Here again, we would need something more lightweight than real USB. I know of one approach at defining such a protocol called Go Bus, but the creator seems to have overreached and appears unable to evolve it into a mature technology (http://forums.netduino.com/index.php?app=core&module=attach§ion=attach&attach_id=2139).
I am sure there are other candidates, but what exactly are reasonable requirements (e.g., easy to deal with partical failures, what degree of plug-and-play for easier integration of IP blocks, maximum cost in terms of transistors or code size, etc.)? What problems really need to be solved, and which ones should not be solved in order to keep complexity as low as possible? Just adding SPI or what-have-you low-level interfaces has proven to be too little, but what more is truly needed?
And then how could such a technology be turned into a widely used standard, without having its complexity increased by the various bells and whistles that different vendors might be tempted to add?
I have no solution, but hope to see a fruitful discussion and further coverage of the topic here...
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.