Code generator details¶

JeeH includes a code generation phase, built into PIO's build process via its Python scripting functionality. The generated code ends up inside your own source files and lets JeeH adjust itself to different build requirements. This is somewhat like STM's STM32CubeIDE build environment, but far, fár less intrusive.

Syntax¶

The code generator in JeeH runs as part of PIO's build process. It looks for files with extension .hpp in the project source folder and scans these for lines starting with //CG (files in subfolders are not considered).

Each line starting with //CG is treated as a code generator directive. There are a few variations of this directive:

The //CG lines can be indented as needed to fit the rest of the code. All generated text will be indented by the same amount, for consistency. Only tabs and spaces are recognised as indentation.

Build options¶

Pre-defined macros¶

The following macros are pre-defined in JeeH's include/jee.hpp header:

PIO¶

If a line "//CG pio" is present in a *.hpp header, it will be expanded using the name of the build environment. If the current build is [env:myapp] for example, then the generated code will be:

//CG2 pio
#define PIO_MYAPP 1
#define PIOENV "myapp"

LEDs¶

With a line such as "build_leds = C13" in the INI file, the following code can be generated:

//CG1 build leds
#define LED  "C13"

Additional LEDs can also be defined, e.g. build_leds = C13 A5 D2 B11 generates this:

//CG[ build leds
#define LED  "C13"
#define LED1 "C13"
#define LED2 "A5"
#define LED3 "D2"
#define LED4 "B11"
//CG]

Hardware peripherals¶

Hardware configuration choices can be complicated since STM32 peripherals only support certain features on certain pins, with certain peripherals, and using certain DMA channels. All this information needs to be obtained from the Reference Manual, and this will be different for different µC versions.

JeeH's code generator has built-in code expansions for I2C, SPI, and UART peripherals in STM32 µCs. The parameters are defined in the project INI file.

I2C¶

Code generation for I2C is based on build_i2c = ... and build_i2c<suffix> = ... settings in the INI file. The are four different methods to handle I2C communication: bit-banged (i2c::Gpio), polled (i2c::Poll), synchronous DMA (i2c::Sync), and event-based DMA (i2c::Trig).

Each of these may require a different amount of configuration, with corresponding definitions in the project INI file:

Each definition is compatible with methods above it, i.e. you can specify DMA settings even if the app ends up using polled mode. Unused details will simply be ignored.

These build settings summarise the pin and hardware choices made for a specific build. With GPIO, all you need is the pin choices, whereas the other need at least the hardware peripheral's name and the frequency of the bus it's tied to. For the DMA-based SYNC and TRIG methods, additional information is needed to specify which DMA channels and streams are used.

SPI¶

Code generation for SPI is based on build_spi = ... and build_spi<suffix> = ... settings in the INI file. The are four different methods to handle SPI communication: bit-banged (spi::Gpio), polled (spi::Poll), synchronous DMA (spi::Sync), and event-based DMA (spi::Trig).

Each of these may require a different amount of configuration, with corresponding definitions in the project INI file:

Each definition is compatible with methods above it, i.e. you can specify DMA settings even if the app ends up using polled mode. Unused details will simply be ignored.

These build settings summarise the pin and hardware choices made for a specific build. With GPIO, all you need is the pin choices, whereas the other need at least the hardware peripheral's name and the frequency of the bus it's tied to. For the DMA-based SYNC and TRIG methods, additional information is needed to specify which DMA channels and streams are used.

UART¶

Code generation for UART is based on build_uart = ... and build_uart<suffix> = ... settings in the INI file. The are three different methods to handle UART communication: polled (uart::Poll), synchronous DMA (uart::Sync), and event-based DMA (uart::Trig).

Each of these may require a different amount of configuration, with corresponding definitions in the project INI file:

Each definition is compatible with methods above it, i.e. you can specify DMA settings even if the app ends up using polled mode. Unused details will simply be ignored.

These build settings summarise the pin and hardware choices made for a specific build. The UART needs at least the hardware peripheral's name and the frequency of the bus it's tied to. For the DMA-based SYNC and TRIG methods, additional information is needed to specify which DMA channels and streams are used.

Implementation¶

Custom code generation¶