Open source plug-in project for IoT
It is very convenient to do all your developments on the same family of microcontrollers. And it is even more convenient to do them on the same embedded module with a microcontroller. But then the module should be as versatile as possible. Here is an example of such a module.
The module can be used in a variety of devices, from programmable logic controllers, robots, machine tools, security systems, loggers, intercoms to Christmas tree garlands with special effects and remote control fobs.
Distinctive features are a large number of configurable inputs and outputs, including analog ones, relatively small dimensions (63 × 26 × 6 mm) and autonomous power supply with a built-in charger and an additional battery for real-time clocks.
The module is a continuation of the development line that began with the open source project K66BLEZ
The new module now has even more interfaces, more memory and better performance.
Functions and interfaces on the external terminals of the module:
-
There are 83 inputs and outputs in total. From the bottom 81 can be configured as both an input and an output.
-
Including 21 inputs with 12-bit analog conversion
-
Including 6 inputs with synchronous analog-to-digital conversion (used for precision motor control or for analyzers of 3-phase power networks).
-
Including 6 dedicated outputs for controlling BLDC and BLAC motors
-
RS-485 or RS-232 interface
-
CAN interface up to 1 Mbit
-
I2C interface
-
SPI interface up to 30Mbps
-
USB HS interface
-
USB FS interface
circuit diagram
The most interesting thing is the external connectors. Therefore, more about them here.
Most pins have alternative functions. But the names of the circuits on the connectors have names consonant with a specific single functionality. This is because the modules were originally created as a replacement for the previous generation of modules with already established functions. However, this does not mean that the conclusions cannot be applied for other purposes. It remains at the discretion of the developer how many different interfaces and functions he will receive in a particular configuration. But let’s name some absolute values achieved with different configurations:
-
Number of independent I2C interfaces – 4
-
Number of independent SPI interfaces – 3
-
Number of independent interfaces UART- 3
-
Number of independent CAN interfaces -1
-
Number of channels for touch capacitive buttons – 6
-
Number of independent PWM channels – 17
-
Number of independent ADCs – 4 (channels 21)
-
Number of independent DACs – 2
The list above does not take into account interfaces occupied by peripherals on the module itself.
Sometimes module manufacturers output signals already occupied by the periphery of their modules to external connectors, for example, SDRAM or SDIO signals. Apparently counting on some kind of multiplexing organized on the motherboard. Not so in our case. Only those signals that are not used on the module itself are output to the external connector. The only exception is the SPI8 interface, which is connected on the module to the real-time clock chip and an external ADC.
To make it easier to find output functions and configure, an interactive spreadsheet was created in Excel. The table allows you to identify the output on the microcontroller and vice versa by the pin number on the connector, as well as find out the entire list of possible output functions.
There may be questions about strange resistors in the R12, R17, R25 circuit. In the full version of the board, they are not soldered, but they are needed when a budget version of the board is made. The schema looks like this:
Module design
The board is 6-layer with a minimum gap of 0.1 mm and a track width of 0.1 mm in the upper layers and 0.075 mm in the inner layers.
The board can be placed in a standard case 1551CTSKtherefore, it has such a somewhat non-typical form
Module programming
There are two ways to bootstrap firmware into the Flash microcontroller.
The first way is to use the standard bootloader located in the ROM of the microcontroller. The bootloader can work via UART9 interfaces (X6.13 – RX, X40.50 – TX) and via USB FS interface (X4.58 – USB N, X4.59 – USB P). For programming, the utilities provided on the Renesas website are used.
The second way is programming via SWD/JTAG interface organized on connector X6
In both cases, special adapter boards are used. Adapter boards are good because they allow you to replace one module with another without losing functionality. For example, the adapter board S7V30_K66BLEZ shown below, together with the S7V30 module, completely replaces the K66BLEZ module and adds more functionality. There is a standard SWD/JTAG connector on the adapter board, to which you can already connect standard JTAG cables from JLink type adapters.
The adapter board project is also in the repository.
Creation of the first program
For microcontrollers of the Synergy families, the chip manufacturer provides a software package called Synergy Software Package (SSP). There will be an IDE called e2studio based Eclipse. In this IDE, full configuration of peripherals, pins and middleware such as file systems, RTOS, TCP stack, USB stack and so on is done. SSP is updated about a couple of times a year, so you need to keep track of the current version.
Work begins with configuring the clocking system on the chip:
The clocking configuration in Synergy chips is surprisingly simple, unlike, for example, the STM32H series.
Then we configure the pins
The next step is to configure the HAL drivers and work task
Almost everything is ready here. Be aware that tasks in SSP are created using Azure RTOS. This may not be immediately clear, since in the generated sources the RTOS itself will be hidden in the libtx.a library. But you can also generate a project with RTOS sources. True, this will be a little different from the version that is presented in the Azure RTOS repositories.
It remains to fill in the body of the task. As usual, we will blink the LEDs. There are three of them on the board: blue, red. green. The text of our task will look like this:
* @brief Blinky example application
*
* Blinks all leds at a rate of 1 second using the the threadx sleep function.
* Only references two other modules including the BSP, IOPORT.
*
**********************************************************************************************************************/
void blinky_thread_entry(void)
{
/* Define the units to be used with the threadx sleep function */
const uint32_t threadx_tick_rate_Hz = 100; // @suppress("Type cannot be resolved")
/* Set the blink frequency (must be <= threadx_tick_rate_Hz */
const uint32_t freq_in_hz = 2; // @suppress("Type cannot be resolved")
/* Calculate the delay in terms of the threadx tick rate */
const uint32_t delay = threadx_tick_rate_Hz/freq_in_hz; // @suppress("Type cannot be resolved")
/* LED type structure */
bsp_leds_t leds;
/* LED state variable */
ioport_level_t level = IOPORT_LEVEL_HIGH;
/* Get LED information for this board */
R_BSP_LedsGet(&leds);
/* If this board has no leds then trap here */
if (0 == leds.led_count)
{
while(1); // There are no leds on this board
}
while (1)
{
/* Determine the next state of the LEDs */
if(IOPORT_LEVEL_LOW == level)
{
level = IOPORT_LEVEL_HIGH;
}
else
{
level = IOPORT_LEVEL_LOW;
}
/* Update all board LEDs */
for(uint32_t i = 0; i < leds.led_count; i++) // @suppress("Type cannot be resolved")
{
g_ioport.p_api->pinWrite(leds.p_leds[i], level);
}
/* Delay */
tx_thread_sleep (delay);
}
}
This text, with the exception of a few lines, was automatically generated by the SSP environment using the Blink template. That’s why it has so many unusual comments.
And the result will be like this:
The entire hardware and software project is located in repositories. I must say that after generating the project in e2studio using Azure RTOS creates about 4 thousand files, so the project in the repository is zipped. In the following, we will demonstrate how to simplify the project and get rid of the HAL.
