Home

---

format: Markdown categories: sensors sensor devkit Workbenches toc: yes title: Welcome to Eeeh-Weee - The Embedded Hardware Emulator ...

Welcome to ehwe - Embedded Workbench

Embedded Workbench or ehwe, which is short for Embedded HW Emulator, allows you to code using deeply embedded API on a Linux machine using HW-interfaces like BusPirate and the likes and mapping them to embedded-HAL API like STM32F10x StdPeriph

The main idea is simply:

• Many HW-interfaces to be accessed by
• Many embedded-HAL API:s
• Mapping is soft and binding API:s to HW is done in runtime using command line options.
• All embedded code is in a separate gitmodule in the directory src/embedded which should compile and run without any change on either ehwe or target.

Currently supported HAL APIs

STM32F10x_StdPeriph_Lib (V3.5.0)

After downloading and unpacking, StdPerf examples can be found in the following directory:

STM32F10x_StdPeriph_Lib_V3.5.0/Project/STM32F10x_StdPeriph_Examples/

They are however not very well written to serve as examples of how to use the API. Better reference examples are listed below:

SPI:

• Read/write

I2C:

• EEPROM
• Corvius

Currently supported HW-interfaces

Bus Pirate v3a / v5.10

Firmware v5.10 (r559)  Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)

Sub-pages

Note: Some of the sub-pages are links to the workbench. If links don't work you may need to upgrade/tweak your installation of gitit

Workbenches

• The workbench page
• All Workbenches by category

Some internal pages

• View/edit man-page (LINK)
• This level README (LINK)
• Project README (LINK)

External copies hosted here:

• BusPirate binary modes:
  • Bitbang
  • I2C
  • [SPI](external/SPI (binary))
• Dangerous prototype's bus-pirate schematics & boards:
  • Cct-BusPirate-v3.5
  • Cct-BusPirate-v3.5b
  • Brd-BusPirate-v3.5
  • Brd-BusPirate-v3.5-SOIC
  • Brd-BusPirate-v3.5b

External (but relevant) pages

• Good read about embedded buses courtesy Sparkfun.
• BusPirate schematics
• BusPirate binary modes:
  • Bitbang
  • I2C
  • SPI

Build

ehwe build-system is based on CMake, with all it's blessings and flaws.

• For a local build (recommended method):

mkdir BUILD_local
cd BUILD_local
cmake ../
ccmake .         #Adjust settings. Optional
make -j$(cat /proc/cpuinfo | grep processor | wc -l)

The name of the build-directory is not important, just make sure it differs from other buld-directories if you have more than one builds, which for this project you'd typically have.

For cross-compiling you need so called tool-chain files. In this project there is one such available Android.cmake, but normally these are external components.

Android.cmake is generic and can be used for any ARM-based Linux system. Actually any Linux-system if you also tweak the TRIPLET_PREFIX in the file. What you need to take special note about is the CMAKE_SYSROOT variable. This expands to SYSROOT and need to correspond to where your systems headers and library-files are stored on your build-host. For the simple case the X-tools have a default. But or Android, this is the part of the NDK and must defined explicitly. It usually looks something like the following:

$SOME_NDK_PATH/platforms/android-NN/arch-arm

• For an Android build (recommended method):

mkdir BUILD_android
cd BUILD_android
cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/toolchains/Android.cmake  ../
ccmake .         #Adjust settings. Optional but do verify SYSROOT
make -j$(cat /proc/cpuinfo | grep processor | wc -l)