Tag Archives: software

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
Zeidman Technologies

SynthOS Callback Solution

Yes, I know this title is somewhat confusing, since a SynthOS-generated system is not based on a typical callback architecture. You may think the title should actually be “SynthOS vs. a Callback solution.” But in fact, SynthOS can create an application that in many respects will work the same way, and have the same capabilities, as a callback architecture. Callback architecture is commonly used when a system requires asynchronous operation. Depending on the application, a task can request a callback (or a message) when a specific asynchronous operation ends, or a specific event is detected. The typical callback architecture uses a function pointer to specify the target for the callback. This is very powerful in C/C++ programing where you can use pointers to a structure or object that includes the function pointers and the data or status information.

SynthOS doesn’t specifically support a callback architecture, but given the flexibility of SynthOS and the way it analyzes the SynthOS primitives within the specific context in the program, it can give you comparable performance to a callback implementation. We will start by reviewing the SynthOS_wait(<condition>) primitive in a simple timer implementation. In a callback system, the user has to send a request to a timer service. The request specifies a time delta or an absolute time and the function pointer to be called-back once the time elapses. Using SynthOS_wait() you can directly wait on a global clock variable or encapsulate it in a function returning the time and wait for that task. The calling task will be suspended and put into the task queue by the scheduler. The timing condition will be tested every time the timer is updated. Once the wait condition is valid, the task will be activated and put into the execution queue based on its priority or system scheduling. The system will return to the command following the SynthOS_wait() primitive in the code.

void loopTask (void) {
    printf ("loopTask1 %dn", clk);
    wait (400);
    printf ("loopTask1: Donen");
void wait (unsigned t) {
    unsigned sv_clk = clk;
    SynthOS_wait (clk - sv_clk >= t);
void clock_interrupt (void) {
    clk ++;

This example shows the use of SynthOS_wait() primitive, but we can get the same behavior by using the SynthOS_call() primitive and calling the function that you would like to call the task back once it is done. Both those options provide the capability for blocking callback, where the execution of the calling task is suspended until the callback happens. SynthOS can also support non-blocking callback functionality by using the SynthOS_start() primitive. This option is very useful in the case of asynchronous communication or an interrupt based system. The main task can initiate another task that will send a callback message once it is done, but the main task operation is not suspended; it can continue processing in parallel until it is ready to wait for the callback.

void loopTask(void) {
    unsigned data = 1;
    printf("Loop task.n");

    printf("Loop task continues.n");

    // Show that other tasks
    // can also run in parallel
    printf("Loop task waits for callback.n");

    // Wait for callback
    printf("Loop task got callback & continues.n");
void startTask(int Data) {
     printf("Start task is running.n");


     printf("Start task is done.n");
     printf("Terminate and send callback.n");

These examples show the way you can use SynthOS primitives and their behavior to support different system architectures. The power of the SynthOS-generated system is the support for embedded systems’ diverse requirements while delivering tested and reliable software that is highly efficient.

Jacob Harel
VP of Product Management
Zeidman Technologies

Zeidman Technologies and Codasip Collaborate to Improve Efficiency of IoT Designs

Application-specific processors and operating systems will help joint customers optimize the design and performance of Internet of Things (IoT) devices

CUPERTINO, Calif. and BRNO, Czech Republic – Oct. 20, 2015
Zeidman Technologies, a leading provider of tools enabling developers to quickly build custom operating systems, and Codasip, a leading provider of application specific instruction-set processor (ASIPs) design tools and IP, today announced that Zeidman Technologies had joined the ASIP Design Network. This collaboration will allow joint customers to benefit from complementary processor and operating system design tools that help drive efficient performance of IoT devices. Combining application specific processors and application specific OSes can drastically improve performance as well as reduce hardware resource and memory requirements.

“Together, Zeidman Technologies and Codasip will help customers meet the need for lean, customized and highly efficient embedded systems to drive billions of IoT devices,” said Bob Zeidman, president of Zeidman Technologies. “Developers need the application-specific processor and operating system design resources that our companies provide to optimize the performance of their products.”

The ASIP Design Network (ADN) brings together a rich ecosystem of companies spanning service providers, IP companies and embedded software suppliers. ADN member companies are working together to accelerate adoption of ASIPs for IoT and system-on-chip (SoC) designs. The two organizations will provide introductions to their respective customers, who are providers of IoT devices that perform specific tasks as efficiently as possible while occupying the smallest possible footprint.

“Codasip is delighted to welcome Zeidman Technologies to the Codasip ASIP Design Network,” said Neil Hand, VP of Marketing at Codasip. “Application Specific OSs are a natural extension to and enabler for ASIPs and what they deliver to our customers. Together we believe that success in IoT requires an application-centric focus across the whole system design.”

About Zeidman Technologies

Zeidman Technologies is a leading developer of hardware and software tools enabling developers to navigate the increasingly complex issues of building custom operating systems. Its signature SynthOS® tool streamlines the process of creating optimized application-specific operating systems that businesses need to ensure that embedded systems run efficiently and effectively. The company was founded by Bob Zeidman, an industry-renowned expert in software and hardware design, and is headquartered in Cupertino, California.

SynthOS and Zeidman Technologies are registered trademarks of Zeidman Technologies, Inc.

About Codasip

Codasip delivers leading-edge tools and IP that enable Application Specific Instruction-set Processors (ASIPs). ASIPs utilize dedicated instructions and architecture to create the optimal processor for a specific application or class of applications, and are at the heart of devices that require the best combination of performance and power for the complete hardware and software solution. Codasip’s unique technology makes ASIP adoption easy and non-disruptive for both hardware and software developers alike.

More information on Codasip’s products and services is available at www.codasip.com. Codasip was Formed in 2006 and is headquartered in Brno, Czech Republic, with offices in Europe and the US, and representation globally.

Codasip is the trademark Codasip Ltd and is registered in the United States.

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.


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