[Dprglist] STM32F4xx progress

David Anderson davida at smu.edu
Wed Jan 18 19:46:41 PST 2017


Howdy,

I've made some progress on the little ST Micros ARM controller boards 
that Dave so kindly gave me.   Had a rather lengthy detour getting the 
gnu cross compiler tool chain installed and happy.   And I'm not happy 
until I have it on several machines, which I now do. Just in case.  But 
anyway...

The LMX RTOS is installed and running blazingly fast, and I've learned 
how to use the Timers, A/D, UARTS, DMA, and other nifty goodies that 
this amazing little ARM processor has to offer.   I'm using the 
STMCube32 Hardware Abstraction Library (HAL) which turns out to be 
nicely designed and very useful, even without the associated mBed front end.

The current port is for the SMT32F411RE running at 100 MHz, with 512k 
FLASH and 128K SRAM.   I fired up a bunch of RTOS tasks to flash leds 
and send status strings to the console port and to a serial LCD, and 
read a bunch of buttons and a knob, a switch debouncer, and a N-X low 
pass filter on a couple of channels of the A/D.

Then ran the LMX system log profiler and looked at the CPU stats. There 
was almost nothing there:

xBot V.0182
18 Jan 2017 20:02
Howdy!
# ----------------------------------
# xBot-0182 CPU USEAGE
# Total CPU 0.0930%     IDLE 312880 Hz
# PID   NAME    CPU%    AVG_MS
# ----------------------------------
# 01    PRINT   0.0282  0.071
# 03    IDLE    0.0004  0.004
# 04    LEDCTL  0.0008  0.038
# 05    LED2    0.0001  0.000
# 06    LED3    0.0005  0.003
# 08    UBUTTON 0.0021  0.001
# 09    GUI     0.0602  0.120
# 14    [exit]  0.0003  0.001
# 15    [exit]  0.0004  0.001


Also noted that the system idle time, which was on the order of 10k Hz 
on the  MC68332 and about 60k on the Arduino Mega2560, is hovering 
around 300K.  Nice.

So, convinced that the cpu stats were not being calculated correctly, I 
wrote a task to eat 50% of all available processor cycles to test the 
calculations, like this:

void hogg(ASIZE delay)
{
     TSIZE t;

     while(1) {
         t = sysclock + delay;
         while (sysclock < t);        /* hog processor */
         wake_after(delay);           /* release processor, like a 
square wave */
     }
}

This task just spins until "delay" ms have passed, and then releases the 
processor for "delay" ms.   So it should show 50% cpu usage and an 
average of "delay" ms execution time.   Running it with a delay of 10 
ms,  here's what I got:

xBot V.0182
18 Jan 2017 20:02
Howdy!
# ----------------------------------
# xBot-0182 CPU USEAGE
# Total CPU 50.0841%    IDLE 126804 Hz
# PID   NAME    CPU%    AVG_MS
# ----------------------------------
# 01    PRINT   0.0291  0.071
# 03    IDLE    0.0001  0.001
# 04    LEDCTL  0.0008  0.035
# 05    LED2    0.0000  0.000
# 06    LED3    0.0001  0.001
# 08    UBUTTON 0.0001  0.000
# 09    GUI     0.0586  0.117
# 11    HOGG    49.9933 9.999
# 35    [exit]  0.0012  0.005
# 36    LED1    0.0008  0.005

Sure enough, the hogg stats look correct: 49.98% cpu and 9.99 ms 
execution.   It really is that fast!   Here's a plot of about 1 seconds 
worth of the syslog file showing the context switches and dwell time for 
each task:

http://geology.heroy.smu.edu/dpa-www/robo/stm32/stm32411-01.png

Note that the HOGG task really does look like a square wave.   The 
logger uses a 100k Hz clock and so has a resolution of 10 micro 
seconds.   Any tasks that take less than that to execute will show up as 
a vertical line, essentially signing on and off before the clock 
changed.  Here's the same plot zoomed in around 6.25 mark with some 
metrics added to show the timing:

http://geology.heroy.smu.edu/dpa-www/robo/stm32/stm32411-02.png

It shows that the "PRINT" task is taking 70 usecs, which matches the 
calculated stats,  with the LED3 and IDLE tasks running 10 usecs apart, 
and each executing in less than 10 usecs.   Considering that the PRINT 
task is doing a printf(), a bunch of maths, and writing to a UART FIFO, 
that's very cool.

So I'm pretty inspired.  Getting close to mounting this thing on a 
robot.   There are some hardware issues to be addressed.   Hopefully 
I'll have something to show off by the next meeting.

cheers!
dpa



More information about the DPRGlist mailing list