AMMDK Overview
Without further ado, and on behalf of the entire AMM engineering team - I'd like everybody to meet Big.Little.TINY - our BLT Sandwich Architecture.
Big.Little (Thanks ARM!)
Hardware overview
Embedded Linux (Debian 9) running on top of an ARM64 processor (we don't care which but we are currently using Snapdragons because they happen to be easily available) We are very interested in the iMX.8 and it will likely be what we use long term - however in the short term to get the ball rolling we use what we can get our hands on.
With this change in mind - our stack is designed to make it as easy as possible to swap processors/vendors (as long as they are within the armv8/aarch64 platform) .
Software overview
- DDS/RTPS as our middleware layer
- Higher level module business logic services
- Communications service to talk to TINY
- Physiology engine service (optional as needed)
- Sim state manager/engine (optional as needed)
Hardware
Generally - a lower powered micro controller with the necessary peripherals to run our real time stuff. We have decided that we will use the ARM Coretex M4 family of processors because that is easily available now but are keeping an eye on the M7 and M33 families as they develop.
We are currently using the NXP K66 . We are supporting debug/firmware uploading to Tiny (via a NXP K26 uC that is connected to Big.Little via a USB interface)
The Tiny(s) communicate with Big.Little via a serial interface (currently a 50 MHz SPI channel for each Tiny). We are running a serial communications protocol on top of SPI that should do all the things you would expect said serial protocol do (error correction codes/serialization/checksums/standardized message(s) etc - the usual fun stuff ).
Fun Fact: I selected the K66 because it meets all our feature requirements and there is a huge library of software out there for it as it is part of several other open source hardware projects (the biggest is likely Paul and his Teensy 3.5/3.6). Also Paul is an awesome person and open sources almost all his stuff.
Software
The TINY(s) run FreeRTOS that has services that do things like :
- Communications library to talk with Big.Little
- Any real time control loop stuff
- Sensor/actuator/peripheral handling
- Future - we are investigating special versions of DDS that runs on TINY directly for very simple modules to drive down overall cost
Final Side Note : The NXP iMX8 would include the entire BLT stack on one chip as opposed to needing to house TINY on the carrier board - for this reason I am very excited to use it ASAP.
Definition : SoM + Carrier Board = AMM Development Kit (AMMDK)
Since we are running DDS as our middleware layer and RTPS as our wire protocol we need an ethernet connection. Conveniently PoE handles power for us as well. We intend on adopting the PoE 802.3bt (50-100W) standard that is coming along very nicely. In the mean time we will default to using "normal" 802.3at (20-30W) unless a module has significant power demands at which point we might use some of the newer 802.3bt stuff.
An arm64 processor with the usual fun stuff (memory/gps/wifi/bt/flash etc). Purchased from vendor.
Notably - some SoM vendors have committed to the same physical connector pinout for their family of products (and there are emerging standards that we like) - we are very strongly considering these as an option since that would make future updates to the carrier board much easier and again follows one of our key goals which is to be agile and to not bet on any one vendor/vendors.
With regards to long term support and parts life span - I have adopted a mission statement : "The only thing we can trust, is that we can't trust anybody"
We are designing a carrier board to house and run our BLT Sandwich.
The carrier board will have the necessary peripherals and interconnects such as : USB, PoE and Ethernet, Serial Interfaces, TTL serial debug terminal, and Application Board Interconnect (see below)
Additionally, an (optionally fitted) "development/testing" breakout header is present on the carrier board that will expose all the fun stuff for folks who are developing on it as well as an (optionally fitted) HDMI port so that if they want - folks can just plug in a monitor and keyboard/mouse and develop directly on the device.
This will enable the same design (with slightly different SKUs - thanks Altium for making this easy!) to be used for design/prototyping and if folks so desire - direct module integration.
Bonus Round! We intend to also use the development header pads in conjunction with testing jigs) as part of our manufacturing / programming/ test + commissioning process (and the Tiny uC(s) will help us too!) - will also open source this design for folks as well!
AMMDK will consistent of the hardware and a series of libraries to abstract away the plumbing and make it easy for new folks to develop modules.
We will provide a wrapper around DDS and a wrapper around the Big.Little<->TINY communications layer in order to make life easy. We will also provide developer tools (like the build + programming) toolchain for both the SoM and TINY as well as lots of examples in order to ensure folks can boot up AMMDK, write some code and easily make with the DER BLINKENLICHTEN .
Choice 1) Application Board + AMMDK
This will be a simple board with just the necessary electronics for the module (e.g drivers/signal filters/DC/DC converters to generate any specific voltage rails) that will plug into the Carrier Board via an interconnect.
We envision this being a lower cost and simpler board (e.g a simple 2 layer job) for module vendors that are producing smaller quantities, simple modules, or lack the engineering budget/capability to customize the carrier board .
Choice 2) Customize Carrier Board + SoM
Since all the designs for the carrier board will be released open source - we anticipate high volume folks / those tight physical envelope designs (and the resources to back it) may want to customize their own carrier board.
Choice 3) Build your own (sandwich bar ; - P )
Since we open source all our software and hardware (and are making it deliberately not too dependent on any specific vendor) - a manufacturer could use a different SoM or design their own embedded computing solution and compile our code + stack for it.
They would loose the benefit of the tools we develop to make AMMDK easy to use - but would have full control. We also suspect that since everything is C++ , you wouldn't necessarily even have to stay on ARM and with some tweaks here and there - get it to compile on pretty much whatever you wanted.