This page serves as documentation for a 2014-2015 Master of Engineering capstone project.
Authors: Kevin Albers, Robert Bui, Jose Oyola, Naren Vasanad
Background
Original Project Description
Model-Based Embedded Software (advisors Profs. Edward Lee and Sanjit Seshia)
Recently, a plethora of small, open-source embedded computing platforms such as Rasberry PI and Arduino have emerged, competing with more proprietary designs. A rich ecosystem of applications and add-on hardware have emerged that enable hobbyists and serious designers to quickly prototype designs, and even to design and deploy commercial products. The software development environments for such processors are fairly conventional IDEs and C programming environments, with libraries provided for peripheral devices. The purpose of this project to design and construct a model-based design environment for software for such devices. Instead of constructing C programs, application designers will build graphical models representing state machines, dataflow diagrams, and discrete-event systems, that describe the application, and a code generator will produce the embedded C code. The goals of the project are:
- To understand the market for such low-level devices and identify the most lively ecosystems and best opportunities for having an impact on the market.
- To assess the risk factors in a code generation approach, including inefficient code, excessive energy consumption, steep learning curves, and extensibility and and adaptability.
- To assess opportunities provided by model-based design, such as more reliable programs, opportunities for formal verification, opportunities for optimization of energy consumption, testability, determinism, and ease of design and/or adaptation.
- To design and build prototypes for experiments that can measure key risk factors and opportunities.
- To devise one or more compelling demonstrations that illustrate one or more of of the opportunities that can be realized with the approach.
Good software skills and experience with embedded systems are a definite plus for this project.
Project Overview
The primary objective of this project is to extend the model-based design environment within Ptolemy II to generate C/C++ code for mbed platforms, specifically the FRDM - KL25Z. This was later extended and developed further with the FRDM-K64F mbed.
IoT Application
As part of a project in EECS 249A, C/C++ code was written for an IoT application using the target mbed platform. The application is the control of an LED cube based on gestures measured from a data glove. Information about the application, titled "CubicHand" can be found in the links below:
Graphical Environment
Ptolemy II was used to create an environment to graphically represent the models and generate code to run on the embedded platform. The goal was to generate code similar to the code used for the embedded application example.
- Ptolemy workspace: /ptII/ptolemy/cg/adapter/generic/program/procedural/c/mbed
- Ptolemy Demos: /ptII/ptolemy/cg/adapter/generic/program/procedural/c/mbed/adapters/ptolemy/vergil/actor/lib/demo/mbed
Code Generation (CG)
The most updated support is for the FRDM-K64F mbed board, but there is some minor support for the FRDM-KL25Z which we worked on the first semester. See the setup guides to get started!
Project Setup Guides
If you are using the Freescale FRDM boards, here are the setup instructions:
Development Guides
Development Resources
Resources that our team has created, to help new user to develop a new code generator for their own platforms. Currently under development
Things to do
- Useful note! __MBED__ is defined in the online compiler, this means you can do the following to exclude pieces of code (the error will not be generated):
#ifndef __MBED__
#error
#endif
- Code Generation
- Figure out how to make mbed actor code into .cpp files.
- Display_Display.c needs to be cpp.
- Remove extra main file from CG
- Issues using Modal Models and EmbeddedCodeActor for mbed code generation. multiple structs are being created.
- There is a generic code generator problem where some models will generate code correctly once, then subsequently continue declaring the same variables more than once each time the code generation is run. See example
/ptII/ptolemy/cg/adapter/generic/program/procedural/c/mbed/adapters/ptolemy/vergil/actor/lib/demo/mbed/SimpleFSM.xml
- NOTE: This problem appears if code generating on Vergil, but doesn't arise when running the code generation from the command line.
- Document the way the .c files work to replace and add in code, specifically the different token types to replace.
- Add #define symbols in makefile for gcc4mbed, PT_DOES_NOT_HAVE_MALLOC_H and PT_DOES_NOT_HAVE_MEMORY_H need to be defined at compilation.
- Memory leak issues at the following locations
- commons/_CompositeActor.c:128
- commons/_Receiver.c:75
- commons/_SDFDirector.c:146
- commons/_SDFReceiver.c:78
- commons/_SDFReceiver.c:86
- commons/pblList.c:1301
Fixes:
- Fixed malloc.h and memory.h and one other .h include not available on mbed
- for all of the *.c files in /Users/robertbui/Documents/workspacePtII/ptII/ptolemy/cg/kernel/generic/program/procedural/c/structures
- added #ifndef __MBED___ so that they do not require malloc.h and memory.h
- Temporary fix for "multiply defined" error when code generating and pushing into online compiler. For every "multiply defined" error,
- There are two files which both declare a struct. Open both of the files'
.h files.
- At least one of the
.h files should #include the other. In that file (the one that includes the other), comment out/delete the line where the struct is declared.
- Then, open the
.c file that corresponds to the .h file you just worked on, and comment out/delete the line where the struct is declared.
- That should fix the issue.
Misc Notes
open models with vergil from command line:
ln -s "/Users/Kevin/Documents/workspace/ptII/bin/vergil" /usr/local/bin/vergil
Code generate from the command line:
$PTII/bin/ptcg -generatorPackageList generic.program.procedural.c.mbed.K64F /path/to/file.xml
FRDM-KL25Z
(Updated in 2017)
We have a number of circa 2012 Freescale FRDM-KL25Z Boards.
- MKL25Z128VLK4 - Main chip
- nxp datasheet
- 128K Flash, 16 SRAM - too small for accessors, which are failing at 64K in the hail.
- Cortex-M0+
Resources
