Category Archives: Uncategorized

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

How SynthOS Can Prevent an IoT-based Internet Outage

Last Friday, massive sections of the Internet were brought to a halt by malware introduced by hackers into DVRs and other Internet-connected devices. The Internet of Things (IoT) promises to connect more and more devices, introducing many more vulnerability points throughout the world. What happens when nearly every devices is connected? Can we stop even more damage from being done? At Zeidman Technologies, we believe that SynthOS is part of the answer.

On October 21, a Distributed Denial-of-Service (DDOS) attack caused outages and network congestion for a large number of major websites including Twitter, GitHub, PayPal, Amazon, Reddit, Netflix, and Spotify.  According to reports, the attack was accomplished by guessing at the default passwords for Internet-connected DVRs and cameras. At least one company, Chinese electronics component manufacturer Hangzhou Xiongmai Technology, admitted that security vulnerabilities involving weak default passwords in its products were partly to blame. Internet backbone provider Level 3 Communications said that at least 500,000 devices were infected with the Mirai malware. The Mirai malware was able to load itself into these IoT machines and then start deluging websites with messages, overloading them and bringing them down.

As bad as this was, what will happen when the IoT dream of billions of devices from thermostats to light bulbs to toasters and refrigerators are all online? A Mirai-type malware could shut down the entire Internet making repair virtually impossible.

One of the problems that led to this situation is that IoT devices are being based on operating systems like Linux that are intended for desktop computers or other systems where the user can install and uninstall programs. So adding a malware program only requires that the malware “act legitimate.”

Another problem is that most of these operating systems have source code that’s easily available. Hackers can download the code, search for vulnerabilities, and test them extensively before ever unleashing their malware.

The SynthOS Process
The SynthOS Process

We believe that OS synthesis is the future for IoT devices because it creates a much more secure system and here is why.

  1. Hackers can’t examine source code. SynthOS creates a custom application specific operating system (ASOS) for each device. This means that while the developer has full access to the source code that is created, that source code is unique to the system and cannot be downloaded anywhere. Hackers can’t easily find, test, and exploit vulnerabilities.
  2. Every synthesized system is custom. SynthOS creates a custom operating system for each device. This means that a vulnerability in one device will not be in another device. So an attack against multiple devices would require malware to understand each device it is attacking.
  3. Reduced attack surface. The SynthOS-generated OS code is so compact and optimized, it is difficult if at all possible to add malware. For example, if a device has 5 applications running on it, the OS will support exactly 5 applications. Adding a 6th application will not be supported and will likely cause the system to crash.
  4. Difficult to add apps to the closed system. SynthOS creates a closed system where new applications cannot be added dynamically. This means that to add a new function, the entire system must be wiped and reloaded, something that malware cannot typically do.
  5. Automatic synthesis of memory checking routines. We are now adding a feature that allows memory checking routines to be synthesized automatically and run periodically. If the routine determines that memory has been changed, it can send out a warning or shut itself down.

OS synthesis and SynthOS is not a cure-all for all IoT security. There will always be the human factor where coding mistakes are made and passwords are emailed on unsecure servers, but OS synthesis in general and SynthOS in particular will go a long way toward protecting against future attacks like the one we just experienced.

Learn more about SynthOS here.

Use SynthOS for free here.

Bob Zeidman
President
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");

    SynthOS_start(startTask(data));
    printf("Loop task continues.n");

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

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

     SynthOS_sleep();

     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

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

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.

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