The Nucleo boards are like the Discovery boards in that they come with an
attached STLINK-V2 programmer. The MCU's UART2 is routed through the
programmer's USB connection and it appears as a VCP device on the host.
So far, this has only been tested to the extent that the elua shell and
lua prompt appear to be functioning as expected.
Before, it was possible for the system timer counter to wrap from high to low
after its value had been read but before the value of cmn_systimer_counter
was read and so the resulting sum of those values would be too large.
By reordering the assignments, we can now detect if cmn_systimer_counter has
been advanced while reading the system timer counter value and, if so, repeat
the assignments to ensure consistent values.
The values used produce sampling points around 65-70% which is similar
to the original set of values.
Values courtesy of http://www.bittiming.can-wiki.info/
It was being set to ( ( 1LL << 31 ) - 2 ) which only used 31 bits when 32
are available. By setting it to ( ( 1LL << 32 ) - 2 ) the range of the timer
is doubled to around 4295 seconds. Note that time values greater than
approx 2147 seconds will have the top bit (1 << 31) set and so will appear
to be negative as all numbers are considered to be signed.
Setting cmn_systimer_counter to zero when the systimer exceeded
PLATFORM_TIMER_SYS_MAX would cause time to jump backwards if
cmn_systimer_counter was already greater than PLATFORM_TIMER_SYS_MAX.
So now, instead of zeroing it, we subtract PLATFORM_TIMER_SYS_MAX.
This fixes a problem whereby outputting to the USB UART when the host is
connected but the USB UART is not open would cause the interrupt
handler to be called continuously so it would consume 100% of the CPU.
This is copied from the stm32f2 code with some #if's added so that you can
select the MCU pins used for the CAN signals at compile time. Four configurations
are supported.
For example, the board config file can contain this:
macros = { 'ELUA_BOARD_STM32F4_CAN_PIN_CONFIG_2' }
Now, can.send() returns a boolean result to indicate whether the message
was successfully sent or not. The various platform functions differ in how
they handled the situation where all CAN transmitters are occupied. In
particular, the STM32x and STR9 implementations ignored the status returns
from the underlying libraries and so if all the CAN transmitters were busy,
the latest message simply got thrown away. Now, can.send() returns true/false
to indicate if the message really did get queued for transmission. All
platforms should behave the same as before.
- includes docs for enc module for stm32 and stm32f4
- migrates platform specific enc module from stm32 to stm32f4
- enables enc module on stm32f4 boards
- adds adjustment to modules build system to still include platform specific modules if some have
guards and others do not when a guard fails
