Tickless scheduling latency

I did some rough measurements using my picoscope on EMW3165 (ie. STM32F411CE) module to find out how deep sleeping during tickless idle affects system scheduling latency. I connected logic analyzer to four GPIO signals to get timings for SysTick, RTC wakeup, HSE oscillator startup time and application task activity. GPIO pins are driven by a simple test application on STM32, which initializes a pico]OS timer to fire each 150 ms. To find out differences between normal and tickless mode it also toggles power saving mode each pass.


First timings for case where systick is always active and CPU does not sleep:


SysTick interrupt handler seems to execute under 5 microseconds and PendSV handler that does the context switch in this case takes 3.5 microseconds. So, after interrupt is raised it seems to take a little more than 8 microseconds to application task serving it to be activated.

Next the case with tickless mode. More latency is to be expected because HSE oscillator is stopped and must be restarted before application continues.


In the worst case latency is a lot bigger. It seems to take 80 µs for CPU to start up from sleep and 720 µs for HSE oscillator to restart. Context switch to application task takes 6.6 µs, which is a little bit longer than in previous case (this is because context switch is delayed after HSE startup, needing an extra SVCall interrupt to handle it). Summing all these up it seems that the worst case latency is about 807 µs, which is 100 times more than in previous case.

The extra scheduling latency doesn’t hurt timer operations much, because pico]OS uses “safety margin” for tickless sleep – it always wakes up a few ticks too early, giving HSE oscillator time to startup correctly before it is needed. But extra latency is present on other interrupts, because there is no way to predict them.

If application cannot tolerate bigger latency, it is advisable either to leave tickless mode disabled or use posPowerDisableSleep in critical places to enforce smaller latency.


Thermometer with EMW3165

Old thermometer broken by the Cat

This project started when our cat decided that playing with our thermometer is a good idea. Obviously, the thing looks enough like mouse with tail, at least when looked with cat’s eyes. The play with it ended very quickly and result was broken cable between display and sensor.The easiest way to fix this would obviously be buying a new 10€ device from local hardware store. But as I already have a weather station running on top of garage roof I started thinking that it would be nice just to display temperature from there.

Continue reading “Thermometer with EMW3165”

MXCHIP EMW3162 (Wiced Wifi) with Pico]OS

Just about every summer I have been thinking about building a sensor, which measures water temperature from the lake at our summer cottage. So I would need a board with few gpio ports to connect a DS1820 sensor and some radio communications to send data to my database server. As I already have Wifi access point installed it would nice be able to use it directly.

MXCHIP_EMW3162When I was researching for suitable parts for the system, I bumped into small module called EMW3162. The module has a STM32 Cortex-M3 microcontroller and Broadcom Cypress Wiced-compatible Wifi chip. The module costs less than $10 at Seeedstudio.com – more than popular ESP8266, but STM32 cpu has more memory and peripherals. For first module, a ~$20 development board is needed (either EMB-380-S2 or EMB-WICED-S).

To program the system, there are two alternatives: SDK provided by module maker MXCHIP and Wiced SDK provided by Broadcom. I ended experimenting with Wiced SDK, as Broadcom provides it for free (registration required, however) along with nice support community. SDK needs some patching for EMW3162, but required changes are available from github.

Wiced SDK provides multiple choices for network stack and RTOS. I ended trying FreeRTOS + LwIP combination, mostly those components being open source. Examples seem to work OK, so it is pretty easy to get things up and running.

But I have always been using Pico]OS for my embedded hobby projects. As Wiced SDK has clean api to add support for any RTOS, I couldn’t resist to start writing such layer for Pico]OS. It was actually quite easy task, all that was needed were ~15 functions to wrap Pico]OS services (threads, semaphores and queues mainly).

Pico]OS approach to building embedded systems is a little bit different than Wiced SDK, however. Wiced SDK seems like a one-stop service for about everything you’ll need to build a Wifi-enabled embedded system: it contains network stack, rtos and API functions for GPIO, ADC etc. Pico]OS on the contrary has quite powerful Makefile system which makes it easy to build separate module libraries for different needs.

I wanted to build a Pico]OS library module containing LwIP driver which I could use with existing picoos-lwip library (it uses currently HEAD revision from LwIP project). Luckily, Wiced SDK is pretty well organized and it was quite easy to find out which files I would need to compile for complete driver. There are rougly two layers in SDK: “WICED” – the full SDM and “WWD” – driver layer. I needed mostly files from WWD-layer only.

WICED SDK and Pico]OS have overlapping functionality when it comes to console serial port output/input. I wanted to use Pico]OS stuff also here, because I have a quite complete newlib syscall support layer in picoos-micro library, allowing me to use standard C stuff to print log messages and read/write files. I couldn’t find a way to fully disable USART support in WICED, so I ended up in patching SDK sources for that part.

Another, equally working approach would have been to disable console input/output api from Pico]OS nano layer and use it from Wiced SDK.

Wifi chip needs firmware before it actually works. I solved this a little bit differently than in Wiced SDK by putting the firmware file into filesystem (/firmware/CHIPNAME.bin) and serving it from there using pretty much standard C stuff.

The resulting wiced-driver library is available at Github, along with simple wiced-test application, which does nothing more than connects to access point and brings LwIP up so you can ping it.

I can now continue with my lake temperature sensor development, hopefully getting something up and running for next summer.