Tag: Coldfire

The Problem

Hardware and Firmware development is essential for the age of the Internet of Things or 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 the 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 a 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 polymorphic 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 often requires a higher processing capacity at a lower power rate.

We created a heterogeneous embedded platform with its firmware ecosystem, that allows fast application development, without compromising the later steps for final production. 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

The two major parts (MCU, FPGA) 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-layer PCB which allows low cost on low production quantities.

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 does not need to change! Using FPGAs moves the programmable barrier lower to the layer stack of a product.

As an 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.

This example demonstrates how a core computing module can drive diverse applications, without requiring power-hungry complicated hardware (ie. high-end processors).

As not all applications require an FPGA, our next generation of embedded platforms is based on a scalable and flexible architecture in which additional elements can be added to the main microcontroller-based processing unit. 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.

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, which is managed to interface without any issues.

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 externally allocated space.

Applications

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

Unmanned Vehicles

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 into high-speed interfaces. The Spartan 6 series can handle these and create video input or output generators (or a combination thereof) 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 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 when 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) that is more compact less power-hungry and within the design reach of a small or medium-sized company. In addition, the platforms are scalable.

What is the advantage of a 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 your heterogeneous embedded platform!