Biography has not been added


's contributions
    • The entire premise for this tool is incorrect. It is yet another proprietary RTOS claiming to automate system generation. "Disadvantages include the fact that the system is difficult to debug because much is hidden from the user. It is also requires a large memory since it needs to support all possible users with various kinds of applications, and so it incorporates features that each particular system may not be using" This may be true for some RTOS solutions but not for most of the main competitors. Sophisticated tools are provided to diagnose errors and examine timing and scheduling issues and OS status. "Although the RTOS is optimized for the particular processor to which it is ported, that is often not the processor that is ideal for the application and is probably not the most low-power processor for the application. This is because RTOS vendors have an interest in porting their RTOS only to high-end processors so that they can charge more for these tools. " This is also incorrect. Many RTOS solutions port to a broad range of processors focusing on low power (Unison WearableOS for example) and many companies focus on delivering the solutions that customers want. " In particular, off-the-shelf RTOSes need a memory manager to keep tasks from interfering with each other.  " Again this is simply not true. It seems to me that you need to see this as what it is. It is a proprietary RTOS with a system generation tool. Whatever happened to open system concepts?

    • Colin, I agree with all your comments above but feel that the issue of standards is the most important issue but neglected in your analysis. By standardizing on POSIX for example, there is a wealth of software that may be reused in the environment and this is the most effective way to develop an application. Nucleus does support POSIX as does the Unison OS that we produce. The benefits of porting to and from the Linux space are pretty clear. In Unison I know that there is no penalty for adopting the dominate OS standard (POSIX) - could you comment more on this?

    • Well said Bernard. As one of the POSIX or Linux compatible small resource versions on your list (full disclosure), I know that the migration of applications from Linux to Unison OS is generally very simple and gives developers a chance to a reduced footprint, zero boot time version with no cost or risk other than the porting time. Unison has both the IoT protocols and the security solutions today to deliver quickly and easily.

    • The Harmony offering is interesting in that Microchip decided to provide a proprietary offering rather than stick to proven standards like POSIX which would have allowed migration to/from embedded RTOS and Linux solutions on any architecture. Of course, focusing on components which run only on PIC32 family products eliminates portability to other families of processors if you run into limitations (and all processors have their limitations). Although it attempts to address the plethora of "free" Microchip modules that don't work together, it still tries to keep users locked in. Generally, maximum flexibility is essential in today's rapidly changing environment. Disclosure: We offer components for PIC32, ARM, Rx, FPGAs and other processors.

    • This is a great comment Rich because as engineers we ultimately trade off cost, features and performance. An experimental approach is required in this case. In terms of performance, for all these small connected devices, really all you can do is test the performance using tools like iPerf to see if it meets your needs. Compute time performance is generally not the issue - but run time or power consumption is often a key issue. If the power is a concern due to added security, but the computation resource is more than adequate, a reduction in the clock rate might get you back to the place you need to be. In terms of flash and RAM resources, it depends on the system that you have under consideration. In the case of the Unison RTOS, we offer a memory space calculator which estimates the worst csae memory usage in both flash and RAM. In terms of the overhead in bits to encrypt messages, it really depends on the users choice of encryption algorithm. They are typically block ciphers which will add bits to fill a block which means overhead (AES, DES, 3DES). This means the transmission time increases.

    • The compute time goes up as the length of the key increases. There is hardware accelerators included in many chips today to reduce this costs. Typical costs for AES are: +20% for 128 bit to 192bit and +40% for 128 bit to 256 bit keys. Of course, some security features are not nearly as important too. SSH and SFTP are typically used occasionally. while TLS and IPSec are used for each message and are of real concern. It is best to focus your analysis on the message transmission overheads as these will be most commonly incurred. For wireless protocols, all messages are secured across the link if the link is properly set up. In this case, end to end security using TLS or IPSec is a good addition but for wireless routers you may get away with securing the router to cloud link and leaving the wireless security to and from the sensors secured with the wireless security, reducing computation on the sensor nodes. It is really application dependent.

    • It is true that on all systems, filtering should be enabled to exclude incoming messages on any unused ports (think firewall features). One solution to the lack of filtering or firewall capabilities in the embedded stack is the elimination of any incoming messages and polling of the server, so this approach will work. A superior solution is the use of a fully functional tcp stack with filtering or an integrated firewall. This eliminates the need for polling. If the deployment is ten devices, eliminating polling may not matter but if the deployment is ten million devices, or the link is over satellite with quite a few devices, polling is not the best solution. Unison OS offers filtering capabilities which eliminates this restriction. Many other MCU or small MPU TCP stacks do not offer this. Other thoughts and comments Rich? Anyone else?

    • I'm going to play the devils advocate here. I think it is completely possible to have pretty robust connectivity using a variety of connection technologies and they might be non trivial to connect, but you can make them work. The bigger challenge in the Internet of Everything is the scale of the system and data management. "How do I deploy and manage 100K devices in the field, update them and keep customers happy?" is a pretty relevant question. We have technology for this. "How do I manage health devices and keep my data safe at the same time?" is another very good question. "How do I let 100K devices connect and manage the data?" is also a good question. With the correct software reuse strategy all of these problems can be solved and many more and this is the really difficult part - scalability. You can do this today but like any new technology, expect to be on the bleeding edge. You can find more information about these solutions on our web site

    • It seems that this approach is more of an attached processing model when dealing with heterogeneous multiple cores similar to the bios approach. While this works, it does not necessarily provide the best utilization of resource and it is this utilization or load balancing that is key for optimal multicore SoC designs. With all the scheduling pushed to the hardware, how is this load balance achieved? Do we just select the hardware which gives the best schedule depending on the design tradeoffs rather than use software control to hit 100% utilization on all processing elements?

    • I think you've missed the point that customers like choices. If you talk to any of the semiconductor companies, some think that your argument has merit. Many others think that alternatives are a good thing. One size Linux doesn't fit all and although autosar is great for runtime control, telmatics is headed in a different direction.

    • Abstract data types and getting the algorithm right first are well known to new graduates today. Unfortunately the "code first" mentality in many of the "finest" teaching institutions and the lack of software engineering knowledge at the management level persist poor practices.