Tag Archives: embedded system

Zeidman Technologies Releases Free Version of SynthOS

SynthOS-LT, a free version of SynthOS, can be used for noncommercial purposes

 CUPERTINO, Calif. – January 26, 2017Zeidman Technologies, a leading developer of hardware and software tools enabling developers to quickly build custom systems for the Internet of Things, today announced that it was releasing a free version of SynthOS®, its flagship software tool.

SynthOS streamlines the process of creating optimized application-specific software for the Internet of Things and other embedded systems. Requiring little knowledge of real-time systems, developers can focus on their unique control routines, device drivers, and algorithms. SynthOS automatically ties them all together in a single real-time system that meets timing requirements, avoids hazards like deadlocks and race conditions, and that is hardened against security breaches from malware. This new version, SynthOS-LT, is fully functional and free for noncommercial use, though it is limited in the number of tasks that it can support. Those limits should not be a problem for hackers and hobbyists wanting to develop their own systems without needing to understand the complexities of real-time operating systems. SynthOS-LT can be downloaded here.

“While we have a free online version of SynthOS, we got feedback that uploading code and downloading code was tedious and could break anything but the simplest systems. So we decided to offer a limited but fully functional tool for free,” said Bob Zeidman, president of Zeidman Technologies. “We want hackers and hobbyists to try it out and see how easy it is to make optimized, secure, working systems at the push of a button. As computers get smarter, programming languages have become more complex. We think programming should get simpler. Rather than the hundreds of APIs that a developer must know to work with an existing operating system like Linux, SynthOS has only six primitives. SynthOS uses artificial intelligence to figure out what you want to do from analyzing your code. And for most applications, it makes the system smaller, faster, and more secure.”

Learn more about SynthOS here.

Bob Zeidman
President
Zeidman Technologies

Task Synchronization with SynthOS

One of the key features for a real time OS is the capability to synchronize and schedule tasks in the system. Traditional systems would use semaphores or mutexes for synchronizing task access to resources and message queues for synchronizing between tasks. SynthOS uses the primitive SynthOS_wait(condition), where condition can be an expression or a task name. The running task will halt and wait for the condition to be valid or for the specified task to block or terminate. There is another way to synchronize tasks by using the SynthOS_sleep() primitive and a simple while or if statement. Using this method, the task will be scheduled based on the system architecture, repeatedly checking the condition. It is a simple implementation but not efficient in terms of processor utilization and power consumption compared to using SynthOS_wait(), but we can utilize the implicit SynthOS_sleep() at the end of every task, which is more efficient in terms of code size.

In a SynthOS generated ASOS system, a function that is defined as a Loop Task is run continuously by the scheduler; once the function terminates, the task control block (TCB) is not released. The system will put the TCB at the end of the task queue (for round-robin scheduling) or reevaluate the scheduling according to the task priority (for priority scheduling), effectively introducing an implicit SynthOS_sleep() primitive at the end of the task. Both of the methods for synchronizing tasks will enable other tasks to run before the scheduler gets back to checking the condition and continuing with the execution of the task. Option 1, without using the SynthOS primitives will save memory and simplify the code compared to option 2, using the SynthOS_wait() primitive. It also makes it easier to check multiple conditions using an if() or a case() statement. The benefit of using the SynthOS_wait() primitive is that the system can be put into sleep mode and woken up from an interrupt. Figure 1 shows the two options the user has.

Figure 1

Figure 1 Implementing task synchronization with SynthOS

These two options show the flexibility the developer has when using SynthOS to develop a real-time embedded system, by using the basic five primitives and the different configurations as defined in the system configuration file. These options are also available in many of the other RTOSes on the market today, but they are implemented by using a large number, sometimes hundreds, of unique APIs. SynthOS achieves the same capabilities by using only five primitives and a configuration file, but the system analysis process will automatically generate the appropriate code to support the required functionality.

Jacob Harel
VP of Product Management
Zeidman Technologies

Multicore RTOS implementation using SynthOS

For those who did not notice yet, Moore’s law is not working anymore, at least in the context of single core CPU architectures. Increasing the speed of the CPU is not happening every 18 months. To get better performance for devices, developers need to look for other system-level solutions. The most common way to increase system performance today is to increase the number of CPU cores in a device and do parallel processing.

The move to a multicore architecture holds great promise for improving system performance, but it requires very careful attention to the software architecture. The great challenge for achieving this potential for system performance improvement from a multicore architecture is the correct and efficient scheduling of threads to the different cores and minimizing the serialized processing in the system. Amdahl’s law predicts the relationship between the percentage of serial processing and the speedup in processing. For example, this law shows that with 50% of the code being serialized, the speedup will be limited to a factor of two, independent of the number of cores used.

Amdahls Law

The problem facing the software developers and especially for embedded system, is how to build an efficient software that will take advantage of the multicore architecture. The most common way for developers to generate an efficient system is to write their own kernel and scheduler.  SynthOS and the process of software synthesis can present a new methodology and tool for creating the software architecture to support multicore and multiprocessors systems.  SynthOS is a revolutionary tool, allowing a programmer to synthesize an application-specific real-time operating system (ASOS). The programmer writes code in C and adds simple SynthOS statements to the code to specify inter-task communications and operating system parameters. The output code, after synthesis, is still C code.

SynthOS can be used to develop an ASOS that will run efficiently on each of the cores in a multicore system and help get the system performance needed to take advantage of a multicore architecture.  Using SynthOS you can build an application-specific operating system (“ASOS”) for each of the cores. This is very efficient, especially when dealing with asymmetric core architectures consisting of different types of cores in the same system. This method allows you to build a specific ASOS for each of the cores in a way to support specific capabilities of the core such as a power management or trusted boot loader. Using a separately developed ASOS for each of the cores will require you to define a communication mechanism between the cores. One simple and efficient option is to use a shared memory block with a semaphore. Another way is to use a dedicated communication protocol such as SPI, I2C, or USB to manage the communications, using a SynthOS Call task for synchronized communication or a SynthOS Start task for un-synchronized communication.

The approach of developing an individual custom ASOS for each of the cores can be especially efficient in a multicore environment where every core is expected to do specific tasks, whether in a symmetric or asymmetric architecture. For example, you can have some of the cores run an ASOS created by SynthOS that is built specifically to perform fixed tasks, particularly those that are closely tied to the hardware other cores in the system can run an off-the-shelf OS when the ability to add applications dynamically is required.

In the future, there are plans for SynthOS to support multicore systems more automatically. In a first step toward this goal, Zeidman Technologies is working on a multicore version of SynthOS that allows the user to specify in the SynthOS project file which tasks run on which cores. The user will also be able to specify the shared memory area so that SynthOS can create the semaphore in the code automatically as it does for communication between threads running on a single processor. Eventually, SynthOS will also be able to allocate tasks to different cores depending on parameters set by the user in the SynthOS project file. Also, SynthOS will be able to allocate tasks to cores using a load balancing algorithm that takes into account performance requirements such that each core roughly utilizes the same memory and/or CPU cycles, creating a significantly well-balanced and efficient system without the need for manual experimentation.

Jacob Harel
VP of Product Management
Zeidman Technologies

Make Old New Again

At one of the Internet of Things conferences I attended last month (and there are many of those these days), I was sitting in on a presentation from one of the leading CPU suppliers for the IoT and M2M markets. The presentation was about the recommended architecture for the future of the IoT and the way the endpoints are going to be connected to the overall system. One of the most surprising comments in the presentation was that 80% of all devices connected to the IoT in the next few years are going to be legacy devices. From trucks to trains to HVAC, and all kinds of other industrial machines that have already been installed in the field. They have been running reliably for a number of years, but still have many years for service in them. All those devices can benefit from connecting to an intelligent backend system. This can increase efficiencies, improve safety, and extend the useful life span of those systems. The financial benefits by themselves should be a big enough reason for the upgrade; adding the safety and efficiency will make it a no-brainer investment.

I realized that I should not have been surprised by this fact, given my own history with embedded and control systems. In fact, none of us should have been surprised by this. IoT is not a new technology; most of the basic technologies have been used successfully in many designs for years. I have worked on the development of a number of connected devices over the last 25 years. From a digital fax using a Z80 processor to a number of industrial control systems using 386/486, devices that included displays, robot control, and communication. And those are not unique examples. A large number of our manufacturing systems, transportation systems, and medical devices are based on designs that are more than a decade old, and in many cases are still in production. And just as an interesting side note, the last time I checked, I found more than half a dozen companies that are still making versions of the 8051 processor, a design that is more than 25 years old at his point (and if you do not know what it is, you should definitely check it out).

All those legacy designs can and should be upgraded to be part of this new revolution. Connecting legacy devices to the IoT ecosystem will expedite the adoption of the concepts of a connected world and will spread its benefits. Connecting a legacy system could require adding a whole new control system that will include a newer MCU/CPU and communication hardware, but in many cases this is not feasible due to the high level of integration and the sensor monitoring that is typical of embedded systems. In those cases, the best solution is to upgrade the legacy system with new software and possibly adding a communication module. A number of companies provide modules that can be connected to legacy designs via serial communication ports (most likely RS232 or I2C) to provide Bluetooth, Wi-Fi, or Internet capability. Adding these modules will enable the connection of that legacy system to the backend server that will support advanced services like remote monitoring, predictive maintenance, and performance analysis.

When upgrading an older design, you should consider the limitation of the device such as small memory, slow CPU clock, and limited capabilities of the original development system at the time the product was designed. To upgrade a system and get a new level of performance out of it, you may need to change some of the basic design architecture. Many legacy system software architectures use serial execution. Changing this to a parallel multitasking architecture can resolve timing problems with the CPU speed limitation. This limitation can be significant, especially when considering the extra tasks required for collecting data and communicating over the Internet with the backend system. Running these activities in parallel with the original tasks of the system can resolve this problem. However, moving to a multitasking architecture in many cases is limited by the available memory in the design. This is where SynthOS can help.

By using SynthOS to create an application specific operation system (ASOS) you will get a very efficient system–one that is optimized for the system-specific needs and with the smallest memory footprint possible. One of the great benefits of SynthOS is the fact that you can start with the existing source code (assuming it is still available). You can take the original code and break it into functional tasks, then define the relations and communication between them using SynthOS primitives. The results will be a highly efficient system that will be able to optimize performance by limiting delay loops, waiting for events and I/O input, and especially waiting on slow communication peripherals and sensors. All of those with a very small penalty in terms of memory overhead. And SynthOS allows you to do all this without requiring any knowledge of RTOS mechanisms like message queues, context blocks, mutexes, or semaphores.

This approach of updating systems that are already used in the field can bring great savings for both service providers and end users. For the service providers, it can bring the system up to the connectivity level that is equivalent to new equipment, and can generate substantial saving in maintenance and service calls. For the user, it will result in reduced downtime and increased efficiency. The key for a successful transition is the low cost and low effort for the upgrade without a significant redesign of the hardware.IoT

Jacob Harel
VP of Product Management
Zeidman Technologies

Multitasking in Modern Embedded System Designs

On Feb 9, Electronic Design published an article titled “Multitasking – Essential to Any RTOS” by John Carbone. This article was based on an article published 17 years ago. The processor used in the examples in the original article was a Motorola 68000, and the fact that I am very familiar with the command set for this processor and its predecessor the 6800 shows my age (some people will call it experience). However, on a more serious side, I think that the concepts and the Ideas presented in the article, regarding the use of an RTOS, and moreover a multitasking architecture in the embedded system is even more relevant today.

In this blog, I would like to reflect on some of the comments in the original article, especially as it applies to the application specific operating system (ASOS), generated by our tool SynthOS. When you look at the history of embedded development—at some level it is the same today—the market was divided among the companies making embedded real-time systems without an OS and those relying on a real-time OS. The typical solution of the first group is the “big loop,” which will cycle between tasks that make up the system, and will wait for events and I/O exchange before it moves to the next task. The main benefit of the “big loop” approach is its simplicity, in development and moreover in debugging and maintenance.

On the other side of the spectrum are the companies that use a multi-tasking RTOS. Those systems are designed using a number of tasks for controlling different aspects of the system; those tasks are activated by the scheduler of the RTOS in a very efficient way to maximize the performance. The main system tasks can also spawn other tasks for handling specific “slower” activities. Those tasks will run in parallel as background tasks, with the RTOS scheduling other higher-priority activities, to achieve very high efficiency of the CPU and resource utilization.

When evaluating an RTOS, according to John Carbone’s article, some of the benefits you should look for are responsiveness (definitely compared to the big loop), ease of development, and portability and maintenance. However, at the same time, you should also be careful to look for a number of pitfalls that relate to memory requirement and access, priority, and excessive overhead. When I think of the ASOS in light of those comments, it is interesting to point out that the SynthOS tool can provide all of those benefits while limiting exposure to the pitfalls, with the added benefit of supporting the old “big loop” simplicity.

SynthOS supports two basic architectures for the creation the ASOS. The first architecture is the round robin scheduler. This is in fact the same concept as the “big loop” with the added benefit of a multitasking capability. In this architecture, the system will go through the list of tasks, but those tasks will release the CPU if it is not used, thus enabling the system to increase its efficiency. Those tasks can also spawn ad-hoc tasks for specific operations that will terminate once they complete. The other architecture is the priority scheduler. This is the typical RTOS approach of running tasks based on their priorities, switching between them to get optimal performers out of the system.

When you look at the benefits an RTOS or an ASOS brings to the users, the system generated by SynthOS will provide all of them and more:

  • Responsiveness: the ASOS supports interrupts with almost zero latency. Moreover, the system is a cooperative OS, giving the user complete control over the context switching.
  • Ease of Development: the SynthOS system uses only five primitives to manage the ASOS and the system. SynthOS will generate reliable and commented C code that is bug free (at the OS level).
  • Portability and Maintenance: SynthOS will generate new application C code for you, which is clearly commented, thus effectively supporting any processor with a C compiler.

As for the potential pitfalls, SynthOS will generate very efficient code in terms of memory usage (improvements of up to 30% on ROM and 50% on flash compared to the market-leading RTOS). SynthOS-synthesized code is correct by design, so the likelihood priority-related deadlocks are greatly diminished, and given that the ASOS generated is a cooperative RTOS and not a preemptive one, the overhead in code and CPU time for context switching is minimal.

In summary, I definitely agree with the article’s point that an RTOS today, maybe even more than in the past, is a critical part of a successful embedded system design, especially given the connected world in which we are living and the massive amounts of data being transferred and processed. The level of complexity for embedded systems is only going to grow. SynthOS presents a unique solution that retains the simplicity and ease of use, while at the same time provides some very powerful capabilities that enable the development of even the most complicated and demanding embedded systems.

Jacob Harel
VP of Product Management
Zeidman Technologies

Emulating Your Hardware System with SynthOS

SynthOS enables you to entirely change the way you develop your embedded system. With current methods of development, users typically start the development with a demo board that emulates the final hardware. Another option is to wait for the actual hardware platform to be designed and manufactured before completing development and starting the testing of the software. With SynthOS, the development can start before any hardware is available, by writing the software modules that include the core algorithms and control routines and replacing the hardware-dependent functions with emulation code, which can be as simple as print routines or key inputs, to emulate low-level hardware signals and communication messages.

One of the great benefits of using SynthOS for creating your application specific operating system (“ASOS”) is the fact that you are getting a simple C source code implementation that can be used to emulate your final system on any computer. At least any computer that has a C compiler, which is just about any computer. Unlike other RTOSes, SynthOS generates an optimized ASOS that stands on its own and is not dependent on the particular hardware. You must write the hardware-specific code that interfaces between the software and the system hardware and wrap that code in C. This means it is relatively easy to run the software on a wide variety of hardware systems by substituting other C routines for the hardware-specific routines. You can even modify the system easily to run on a PC, and since the code is pure C, it is also easy to run in any of the integrated development environments (IDEs) available on the market.

A simple example of a “Hello World” multitask application using SynthOS can be found at www.github.com/ZeidmanTechnologies/SynthOS-hello-world. This example contains two basic SynthOS loop tasks with another SynthOS call task that is used to synchronize the two loop tasks. This code can be compiled with the GCC compiler and run on virtually any system. We have also run this demo code in the QT-Creator IDE, which has a graphic user interface and advanced debugging capabilities. Running the significant part of the system code as an emulation on a PC and using an IDE, will enable you to debug a significant part of the system before even selecting the final hardware.

One of the concerns developers sometimes have when using SynthOS-generated applications on a PC is the continuous operation of the ASOS. Since SynthOS is generating an ASOS for an embedded system, this code will run continuously forever. The developer does not have to create an idle loop (or task) using the while(1) or the for(;;) commands. The SynthOS ASOS will manage the idle operation and the sleep mode for the system, but when rujnning it on a PC for emulation, you may want to stop the system without having to kill the task. To terminate the ASOS at any time, you can add the following command in your code:

SynthOS_abort = 1;        // Exit SynthOS

Then simply create a task that waits for some particular input or timeout to abort the entire system and return to the PC operating system gracefully.

Jacob Harel
VP of Product Management
Zeidman Technologies

Nothing Like a Good Sleep

It’s been known in the embedded systems community that one of the best ways to save power is to not do anything. Getting a system into various levels of sleep mode, and managing it correctly, is one of the key factors to low power system design. The ability of many of the controllers on the market to get specific subsystems into sleep mode or to even shut power off completely to those modules, takes power management on new embedded systems to a new level of complexity that keeps many developers up at night until the wee hours.

Power management is going to be a key factor for the success of new products in the Internet of Things market. Especially when it comes to wearable devices where charging the devices on a daily bases is unacceptable to the user. Battery technology is developing at an amazing rate, and the new processors and programmable devices that are coming on the market are also reducing power consumption in a significant way. But both of those technologies are coming at a premium cost for now. There is another way to reduce power consumption–use a smaller CPU with less on-chip memory. When it comes to power consumption, an 8-bit processor will be much more efficient that a 32-bit one, and the memory size will directly contribute to the power consumption profile of the MCU (especial RAM).

SynthOS is a tool for the development of an Application-Specific Operation System. SynthOS is taking the customer’s basic code and a configuration file as input, and it generates an optimized and highly efficient operation system. This ASOS reduces the memory utilization on both flash and RAM, and the source code that it generates has effectively zero latency for interrupts. SynthOS also has internal support for system level sleep more. Starting with version 1.7, a new SynthOS function call, setMaskAndSleep() will set the interrupt mask and put the system into sleep. This will further improve the power consumption in embedded systems developed with SynthOS.

At this point you are probably thinking that you are going to look into SynthOS for your next product design. But the real beauty of using SynthOS is that it can help older designs too. Since SynthOS generates source code in ANS C, it is compatible with any processor that has a C compiler (virtually all MCUs). By using SynthOS, you can reduce the program and the data size compared to other RTOSes or schedulers. This will not only help you improve the legacy system but will also let you add new functionality within the same memory footprint. And it will also allow you a good night’s sleep.

Jacob Harel
VP of Product Management
Zeidman Technologies

Building Libraries with SynthOS

Over the last few months, we have reintroduced SynthOS to the market, and our CEO, Bob Zeidman, has been meeting with potential customers, partners, and developers. We’ve heard some great comments and got many questions about the tool and the ASOS it is generating. One of the questions that came up in almost all of the presentations is “How does SynthOS work with existing libraries?” We explain that users can call any library from within a SynthOS task, and the tool will not change the library or its functionality. However, the interesting question is why not use SynthOS to build your libraries? Using SynthOS to build your library will give the unique capability of creating a multi-task/multi-thread library that is completely OS independent. And since SynthOS is generating ANSI-C source code, you can compile it and run it on any CPU/MCU that has a C compiler.  Moreover, most languages and development environments today are built to interface with C code even when you’re developing in a higher-level language like Java or JavaScript.

The SynthOS tool will take your source code plus a project configuration file and generate source code that incorporates your source code with the functionality of a multi-thread cooperative operating system. The code that SynthOS generates is pure ANSI-C code, and it is free from any OS dependencies. In cases that the system needs to connect to physical hardware, it can be encapsulated in specific hardware-related functions or can be part of the abstraction layer from the board support package. This independence from the OS gives the developer a unique capability for simulating and testing the software on any system (in my case, I am testing SynthOS generated code on a Windows system). However, this code, after being debugged for functional correctness, can be deployed on any system with an OS or without.

When we consider the case of building and deploying complicated libraries, like in the case of a TCP/IP stack or SSL encryption, the library could be made smaller, more efficient, and reliable if it is designed using a multi-thread architecture. The problem that developers are facing is adopting the libraries to the specific OS architecture and APIs. This work, in many cases, is left to the system developer who needs to build the interface to the OS (if one is not supplied with the library). This is time-consuming and in many cases requires a deep understandings of both the OS and the specific library being used.

Developing code using the SynthOS tool is straightforward. After defining the main tasks in the libraries (transmit, receive, monitor, acknowledge, etc.), the system will generate the scheduler, message queues, semaphores, and mutexes as needed. The system is then available for the developer in ANSI C and can be distributed as source code or object code. Once a library task is called, it will run in parallel as a separate task in the system. The communication with the other tasks can be done by using shared memory (which can also be OS independent) or any other inter-task communication mechanism available.

Jacob Harel
VP of Product Management
Zeidman Technologies

Roll Your Own Real-Time OS

A real-time OS is essential for most embedded applications.  However, those who buy a commercial one are often quite disappointed.  A typical system is like a creaky antique car, awkward to use and difficult to learn.  Furthermore, the cost is high and frequently involves royalties on each product sold.  Embedded Linux is an obvious alternative, but it consists of extensions to a non-real-time system and its documentation is frequently obscure.  In cases where only limited features are needed, one can use an automated tool to generate a real-time OS.  The cost is minimal, the time required is small, and the performance is high.  Similar tools have long been used to generate minimal systems software for new or specialized computers.

A typical example is SynthOS from Zeidman Technologies.  It allows a programmer to synthesize a real-time OS. The programmer writes code in standard C. He or she adds simple SynthOS statements to the C code to specify task and operating system parameters. The output code, after synthesis, is completely written in standard C. SynthOS allows programmers to use all their current tools, such as compilers, debuggers, interpreters, and emulators, to execute and debug the resulting code. SynthOS also optimizes code and checks to ensure that race conditions cannot occur and that tasks have the correct priorities and frequencies. It works with the GNU toolset and with other popular development environments.

Making SynthOS Work

When one task needs to call another, or wait for another to complete, the programmer inserts a special SynthOS primitive that looks like a function call. The programmer also uses SynthOS to specify the parameters of each task, such as its priority and period, and to specify the requirements of the operating system such as the scheduling mechanism to use. SynthOS is then run on all the task code. It creates semaphores and message queues for each task and inserts the code at the appropriate points. SynthOS also creates management code to manage the tasks and their associated message queues and semaphores.

Because SynthOS’ output is in standard C, users can see everything that is going on in the operating system. All the tools used to compile and debug the tasks can also be used on the OS. The OS code can also be easily modified manually, if necessary, giving the user complete control over it.

SynthOS is very easy to set up and use via a simple command line interface. A graphical user interface is currently under development. SynthOS has been used successfully to create an operating system for a self-contained, multitasking web server running on an Altera 32-bit Nios processor.

Conclusion

The code produced by SynthOS is completely royalty free.  Also, the OS’s memory requirements are small because SynthOS only creates the code required for the various tasks. SynthOS fulfills the promise of automatic code generation for low cost, small footprint task management. It gives designers flexibility and control that no off-the-shelf RTOS or program development tool can offer.

Jacob Harel
VP of Product Management
Zeidman Technologies