PhD in 10 minutes

A few weeks ago Ilias Alexopoulos presented part of his PhD work on IoT performance Estimation.

Engineers involved in developing IoT either remote or not, have to deal with key parameters like power consumption, computation speed, or resources, depending on the cost function of each project.

The presenter making the introduction

The problem is to estimate the best performance according to the key project parameters of an implementation and more specifically of an algorithm with respect to different hardware. Each hardware can offer different kinds of optimizations so the combinations of each implementation involving algorithm variants and hardware optimization is unmanageable.

The framework flow
Presenting the Framework Flow

The work of this research is to establish a framework that can estimate this individual performance and provide guidance to the designer of the best hardware without the need of implementing the algorithms on any platform.

Presenting Conclusion and Challenges
Conclusion and Challenges

It is a long shot to achieve this goal, but research and progress are about challenges. Challenging methods, tools, or our limits to achieve more.

Embedded Online Conference 2022

This year we will present how to create heterogeneous embedded platforms using Coldfire or Kinetis microcontrollers and FPGAs. We will touch on some interesting points related to such implementations.

EOC2022 Compact Heterogenous Computing Platforms
Compact Heterogeneous Computing Platforms

We hope that you will enjoy this talk and the small demonstration of integration between MCUs and FPGAs.

Edge Computing for Maritime IoT @BTS

“Breaking The Surface 2021” event was very successful and interesting. Many scientists of all over thw world presented the latest developments in archeology, marine robotics, sensing and other applications.

We were honored to present our maritime IoT platforms and share our knowledge on embedded system design and hardware acceleration.

BTS Tutorial

We discussed things like power management, showcasing the power management board for the MARI-Sense ASV, hardware acceleration, and versatile heterogeneous platforms.

Ready for the Tutorial with all Hardware
Power Management GUI
Power Management GUI

For more details see the following link.

Tutorial 2 Intro – AI Zerocaliber: Edge Computing for Maritime IoT – Breaking the Surface (


For anyone attending the multi-disciplinary conference of “Breaking The Surface 2021” event, I will be giving a tutorial on multiple topics on using embedded computing in maritime applications.

Hydrophone Processing System
Hydrophone Processing System

For more details see the following link.

Tutorial 2 Intro – AI Zerocaliber: Edge Computing for Maritime IoT – Breaking the Surface (


The Problem

Hardware and Firmware development is essential for the age of Internet of Things or for the more traditional term embedded systems. Recently more and more processing is required to be performed closer at the physical locations where the sensory or IoT devices exist, called edge processing. The traditional way of developing such systems is using application processor systems running on Linux.

Development of such products is fast due to the ecosystem using commercially available platforms and proof of concept projects are easy to achieve; However when someone tries to make the necessary modifications to create a custom product, comply with certifications and perform changes required to make it a viable product, soon he/she may fail short, as:

  • There is not much control for customizing the core boards; Design from scratch is the only option if a single board is needed or there are mechanical constraints
  • The base hardware is complicated for the majority of  applications
  • Highly skilled hardware engineers and sophisticated tools are needed
  • Cost for production of a custom featured PCB usually is much higher for individual production
  • Critical parts are hard to source in small quantities
  • Designs may not be efficient from power or performance perspective

We are often obliged to select and change parts because of the limitations of our mainstream microcontrollers to a higher-end one or we need to add external logic and circuits to accommodate richer input-output architecture.

Wouldn’t be great to have a polymorphism platform that could easily scale to work with for the majority of our projects, smaller or bigger?

Another aspect that is considered is design verification. Embedded systems usually need to have real-time performance, thus classic debugging (step-through) under real-time conditions is not always possible or is an additional challenge. Stack checking on RTOS or timings is not easy to observe accurately without the help of hardware otherwise, a performance penalty is taken.

Wouldn’t be great to have a much easier time debugging embedded systems?

our Solution

Microcontrollers offer a small footprint system with a high level of integration (memories, peripherals etc), but sometimes the internal peripherals or the processing capabilities are not adequate to tackle more demanding applications. FPGA on the other side is more flexible and capable but they are not the best option for control flows and require expertise for development. In addition edge processing sometimes requires a higher processing capacity at a lower power rate.

We created an embedded platform with its firmware ecosystem, that allows fast application development, without compromising the later steps for final production. In order to combine the benefits of both microcontrollers and FPGAs the PerseusCLE was built.

This platform provides the following key features:

Key Features

  1. Simple 2 or 4 layer PCB, which is within a medium skilled engineer to modify
  2. 32-bit microcontroller
  3. Programmable Hardware to create custom peripherals and interfaces
  4. A firmware framework that allows fast development in C language
  5. A compact and extensible platform
  6. Support of External Hardware parts for specific interfaces (motors, servos etc)

First Generation Specs

  1. Wide range DC 9-36V ac/dc supply voltage
  2. MCF52258 Coldfire @48MHz, 512KB Flash, 64KB RAM
  3. Spartan XC6S-9LT FPGA @48MHz
  4. 24MB/sec Link between MCU-FPGA, memory mapped
  5. RTOS based design framework
  6. Developed with and supporting TDD or Unit Testing
  7. Olimex UEXT Connectors for external modules
Perseus CLE Board
Perseus CLE Board

For example the flexibility of these platforms is demonstrated next, where the same platform can be used for DC motor control or drive an HDMI monitor, with the use of an adaptor board.

Stepper Motor FPGA Drive
Perseus CLE board driving the DVI signals
DVI Setup, 2nd try

As not all applications require an FPGA, the next generation of embedded platforms is based on a scalable and flexible architecture that additional elements can be added to the main microcontroller-based processing unit.

Second Generation Specs

  1. Wide range DC 9-36V ac/dc supply voltage
  2. Kinetis K66 up to 180MHz, 2MB Flash, 256KB RAM
  3. Spartan XC7S series FPGA
  4. 24MB/sec Link between MCU-FPGA, memory mapped
  5. RTOS based design framework
  6. Developed with and supporting TDD or Unit Testing
  7. Olimex UEXT Connectors for external modules
  8. Modular design with combinations with or without FPGA
TileMCU_CF Platform

The platform allows for companies or individuals to develop prototypes fast, but at the same time provide easier migration to a final product, with parts and designs that can be manipulated by a medium-skilled engineer.

The programmable hardware can provide one more level of expansion thus providing a more reach peripheral set than the ones included in of the shelf microcontrollers.

This is a simple universal design that integrates a microcontroller and an FPGA in order to perform hardware acceleration, functional and I/O expansion, or design verification of an embedded system, using a minimum amount of chips.

PerseusCLE Architecture
PerseusCLE Architecture

The two major parts are interlinked with a high-speed connection to enable FPGA mapping inside the microcontroller’s memory space, giving programming simplicity for the firmware, while achieving high-speed transfers, and allowing the use of internal MCU DMA. Eventually, this provides a two-chip solution and simple two layers PCB which allows low cost on low production quantities. In the next picture, the design of a 2 channel hydrophone acquisition and processing system is shown. Note that the hydrophone analog front-end was a new requirement that the platform was not specifically addressed, however manages to interface without any issues.

Hydrophone System

The hydrophone front-end is in the new form factor of the embedded tile, so it can fit on the mechanical chassis. The box offers a constant volume that can fit any combination of hardware in the same external allocated space.

Tile HydroAFE

To support the potential uses of the hardware a firmware stack is also provided, that enables programming the FPGA configuration from the SD card, and provides the access methods to the FPGA side along with drivers for Serial, USB, SD, FATFS etc. The stack is based on a modified version of FunkOS RTOS, and the extensions provided are developed using TDD to ensure high quality and reliability of the system.

Using FPGAs moves the programmable barrier lower to the layer stacking of a product.


On the left side we see the traditional CPU stack. If we upgrade the CPU we need to change the Driver/OS layer to fit the new CPU/Hardware

On the right side the FPGA device is replaced. We need to “recompile” the FPGA-Logic (Program) to the new device. Driver/OS do not need to change!

MCU vs FPGA Layer Stack Comparison
MCU vs FPGA Layer Stack Comparison

The FPGA VHDL code flow for simulation uses UVVM and OSVVM to support a solid verification strategy. Along with the hardware, we provide source code with examples for the microcontroller and example VHDL interface.


This platform can be used very effectively for the following applications.

Embedded Tile System for Hydrophone Processing with Chassis


As the hardware is flexible, controlling multiple motors and acquiring sensor data from multiple sensors, make this platform ideal. The MCU can be off-loaded from low-level motor driving, while concentrating on the main control system. The FPGA can handle the low level functions along with the sensor fusion for multiple sources (ie. camera).

3D Printers

Having a platform that can handle more motors can create a more capable 3D printer or even a 3D printer in combination with a lathe. Again the high level functions can run on the controller while the FPGA keeps track of the precision in time.

Small Video Applications

The video signals stopped being analog and transformed to high-speed interfaces. The Spartan 6 series can handle these and create video input or output generators (or a combination there-off) while the microcontroller can handle the content (ie. transfer it through the USB). No more complex CPU high-frequency arrangements are required.

Edge Processing

As the FPGA can offer a high degree of parallelization, applications that require a high number of parallel units or hardware acceleration are good candidates for this platform. For example, this platform is going to be used in the MARI-Sense project for signal classification at the edge.

Embedded System Controller

Controlling a divert number of actuators and sensors hasn’t been easier. Controlling Stepper motors, LED arrays, BLDC, or gathering sensor data from different sources can be done easily. The FPGA can include the low-level logic of control and pre-processing while the MCU handles the control and connectivity side of the application.

Embedded Design Verification For many applications the FPGA is an overkill device to have. However, you may be able to test the real-time embedded firmware, without any performance impact if you use the FPGA for capturing processor data. For example, stack checking in hardware is very efficient and accurate. So you can use the combined system to trace events, check stacks, and any other aspects of your embedded system before you deploy it and gain more confidence in the quality of your product. 

Other solutions

Well, why should I use this platform while I can get similar setups from the FPGA vendors? I can get single or dual ARM cores along with a larger set of available logic.

This is true, however, these solutions are micro-processor based and not micro-controller based. The PCB is challenging to accommodate these devices and they still need a lot of external peripherals to make it work (SDRAM, Flash etc). Our solution offers a two-chip solution (MCU and FPGA) which is more compact and less power-hungry and within design reach of a small or medium-sized company. In addition, the platforms are scalable.

What is the advantage over microcontroller-based solution that contains logic?

Using an external FPGA device your solution is not bonded to a specific microcontroller or FPGA device. The split architecture allows more flexibility. You can scale up capacity for example using the same footprint (just replace the FPGA with a higher capacity logic one), or you may decide you need another processor (ie. Coldfire or Kinetis) that supports the same inter-chip interface.

Please contact us for further information on this series of products.

Firmware and Software

In embedded systems, the term firmware is very common and describes the software that runs close to the hardware usually with limited resources and commonly in a deterministic execution time frame. Don’t be fooled, however; Firmware can be many thousands of code lines and be a complete application.

How such a piece of software is debugged? It is often stated that debugging is an art. Debugging embedded systems is even more difficult. Electronics that control physical resources (like motors) cannot freeze while stepping in the code, making the process challenging. It would be really hard to trace a problem in this case. So experts in the field use multiple approaches often not found in usual software development projects to trace intermittent errors or problems that relate to the unpredictable environments in real-time.

Software/firmware quality is something that cannot be easily assessed by non-experts. There are a few guidelines though, which give an indication of the written code quality.

  • How many bugs are revealed during testing?
  • How difficult are these faults to be pinpointed?
  • How easy is to change operation or add features?
  • How fast can you port to other microcontroller architectures?

The first rule of debugging in embedded systems is to avoid creating bugs in the first place. A good architectural design and coding practice are required to achieve a low bug count and reduce debug time. On a medium scale of an embedded project expect a significant amount of time before you see any actual line of code. This time goes for architectural decisions and tests that will pay off later with faster coding and a quality product.

From more than 40 man-years of embedded firmware experience, we have mastered these techniques. Using Test-Driven Development methods, layered architectures, timing evaluations, best coding practices, and system testing we achieve our goals on time. Furthermore, we leave support for debugging in cases these are needed during later phases of the product’s lifecycle. There is also strong experience in production-grade safety-critical systems that can help create such applications or provide consulting on the process.

We use C and Assembly, creating code that can be ported to different microcontroller architectures fast and support development or product with Python and GUI scripting. Our debug strategies include a combination of debuggers, oscilloscopes, and logic analyzers to effectively pinpoint difficult to resolve issues if ever arise.

Hardware Design

As every design process starts from the requirements document, hardware design is no exception. A detailed specification is created from these requirements which drives the schematic drawing phase. An often neglected part is the selection of parts to accomplish an electronic design. Selecting parts with high availability and less lead delivery times is an important task. Another aspect is selecting the components packages as these affect the board (PCB) area and the assembly process. A denser PCB may require a higher manufacturing class and thus increase production costs. A good understanding of the PCBA production phases is required to have an efficient design that can be produced smoothly in quantities without disruptions.

Producing is not the end of the line though. Testing is another major factor that should be considered. There are many test strategies employed depending on the technology used, production quantities, and yield. The board shall have provisions for the selected method(s) of testing, like In-Circuit Test, Functional Test, JTAG/Boundary Scan, or other custom testing.

Understanding the above issues explains why there are many failures in kick-start type projects when it comes to hardware. Taking the wrong decisions may end up well out of the estimated cost and time budget. We use top-of-the-line CAD tools (Altium Designer) to tackle all these aspects of product design and lifecycle maintenance.

Example PCB Design

Our hardware experience with systems that went to production offers many years of experience in embedded systems design, starting from specifications down to product support. Our portfolio of work includes dc motors, sensing, microcontrollers, FPGAs, and mechanical integration. In addition, design tools offer strong collaboration capabilities enhancing documentation, changes, and reviews.