The TileMCU Coldfire version completed its first set of tests, completing the integration of the USB stack from Freescale/NXP to the RTOS.
Using POSIX-style drivers (or any standard way of interfacing) we were able to replace the Serial input of the Command Line Interpreter (CLI) with the USB one.
The code change was a very simple one, replacing just the name of the driver.
Code Excerpt of Selectable Driver
So essentially we define a preprocessor macro with the name of the required driver. As both the USB-CDC and the Serial driver have the same API, they can be interchanged at will.
Here we do this on compile time. Another option would be to mirror both interfaces and have at the same time either USB or Serial I/O. For now, we decided to keep it simple as we have to test the rest of the boards to complete our hydrophone system.
USB Enumeration
At first, the USB enumeration was checked to see if the basics worked. Then we opened with our terminal the respective virtual serial port and start testing the CLI.
CLI Test Example
The CLI was tested to ensure that there were no problems using it and testing some other functions like the SD Card mounting and FAT access.
As we have completed the first phase of testing we can move on to the next boards for testing. We will return back to this board to test the Mini-FlexBus interface with the FPGA.
The concept of a flexible and scalable system is a usual requirement for many applications. We initially started this flexibility by integrating MCUs with FPGAs on the same board. These created the initial Perseus Family Platform boards that we used for the development of applications.
Later on, during the MARI-Sense project, it was evident that the form factor should be more compact while features should be more selectable. In that spirit, we created the TileCubeTM System. Toward implementation of the platform, we designed boards for a complete hydrophone system, including microcontroller boards, FPGAs, and analog front-ends.
Due to component shortages, we were forced to design and use existing parts that we had in stock for the boards. Some boards are already designed with higher-performance microcontrollers waiting to have the new parts in hand. The flexibility of the system allows using different MCU boards in a backward-compatible manner.
The first board of the Tile System is the microcontroller. This version is based on Coldfire MCF52258.
CAD Model of TileMCU_CF
Soon the boards arrived to our lab and we started the board bring-up process and testing.
Actual TileMCU_CF Sample
We confirmed the firmware configuration changes to support the new I/O assignment and installed COFILOS to test the system. Soon we had a system working with serial communications, command line interface (CLI), etc.
First Light (Blinking) of Firmware
Next steps were to verify the SDCard interface and we tried the first time the Digilent Digital Discovery tool for capturing SPI data.
SDCard SPI Checks
Finally, we confirmed the proper operation of the SDCard and through the CLI we sneaked into the first sector of the device.
SDCard First Sector
Initially, the same board was designed with another microcontroller in mind, but due to component shortages, we had to re-spin the board with Coldfire. It was a fast race to quickly redesign the board, build it and make it work, within our deadlines. This gave us the motivation to complete the rest of the boards with the same speed, so we can see the full system ready and explore the potential of the system.
If you are interested in this platform feel free to contact us.
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.
Compact Heterogeneous Computing Platforms
We hope that you will enjoy this talk and the small demonstration of integration between MCUs and FPGAs.
In May 2020, we presented a compact heterogeneous computing embedded platform.
The platform is based on a coldfire Microcontroller and a Spartan6 LX9 device all put on a two layer board. Simple and effective. We also demonstrated two of the prototype systems live showing the configuration of the FPGA from the microcontroller and then the seamless register mapping into the microcontroller memory space.
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:
KeyFeatures
Simple 2 or 4 layer PCB, which is within a medium skilled engineer to modify
32-bit microcontroller
Programmable Hardware to create custom peripherals and interfaces
A firmware framework that allows fast development in C language
A compact and extensible platform
Support of External Hardware parts for specific interfaces (motors, servos etc)
First Generation Specs
Wide range DC 9-36V ac/dc supply voltage
MCF52258 Coldfire @48MHz, 512KB Flash, 64KB RAM
Spartan XC6S-9LT FPGA @48MHz
24MB/sec Link between MCU-FPGA, memory mapped
RTOS based design framework
Developed with and supporting TDD or Unit Testing
Olimex UEXT Connectors for external modules
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 DriveDVI 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
Wide range DC 9-36V ac/dc supply voltage
Kinetis K66 up to 180MHz, 2MB Flash, 256KB RAM
Spartan XC7S series FPGA
24MB/sec Link between MCU-FPGA, memory mapped
RTOS based design framework
Developed with and supporting TDD or Unit Testing
Olimex UEXT Connectors for external modules
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
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.
Example:
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
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.
Applications
This platform can be used very effectively for the following
applications.
Embedded Tile System for Hydrophone Processing with Chassis
Drones/UAV
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.