STM32, ghetto style

[paulie]

Hey, what's with this F0 stuff. I thought everybody here was over that. Maybe not everybody rolls up their sleeves and builds a $1 DIY but surely at least the Ebay 103 "blue boards" are starting to arrive.

Just kidding. I know some of us do enjoy playing with these oddball parts and I certainly look forward to it when mine arrive sometime in the next couple days. Back to the ghetto, here we go (went?). Haha.

[dannyf]

I'm getting closer to understand this thing a bit better:

Learning by doing,

[dannyf]

The little bugger that could:

Just wanted to see how far I could push the envelope.

STM32F030F (rated maximum speed of 48Mhz), ghetto board, 8Mhz crystal. 0 wait state. GCC + CoIDE.

Flipping a pin (unloaded), 50Mhz drive on the pin.

The main loop is just a bunch of pin flip instructions.

I then measured the frequency on the pin, under various PLLx settings and compiler settings (O0 and O1):

Code: [Select]

//pin frequency in Khz, Cpu frequency in Mhz.

PLLx F_CPU O0 O1
2 16 1595 3982
3 24 2393 5973
4 32 3191 7984
8 64 6383 15928
9 72 7181 17919
10 80 7979 19921
11 88 8777 21901
12 96 9575 23856

I stopped at 12x/96Mhz.

I have to say that for a chip rated at 48Mhz, costing 32 cents (official price) apiece, that's very remarkable.

[dannyf]

I am still a bit stuck on it since I need the 32kB free Cosmic compiler for my projects, 8k does not cut it.

you may want to search stm8 usb on github.

Use at your own risk.

[dannyf]

A little bit more testing on wait states and their impact on performance.

Again, the same STM32F030F ghetto style, running on 8Mhz crystal, PLL'd to 96Mhz, flipping an led.

The frequency under WS0 vs. WS1:

Code: [Select]

PLLx F_CPU WS O0 O1
2 16 0 1595 3982
3 24 0 2393 5973
4 32 0 3191 7984
8 64 0 6383 15928
9 72 0 7181 17919
10 80 0 7979 19921
11 88 0 8777 21901
12 96 0 9575 23856


PLLx F_CPU WS O0 O1
2 16 1 1587 3935
3 24 1 2380 5903
4 32 1 3174 7871
8 64 1 6348 15742
9 72 1 7142 17710
10 80 1 7936 19678
11 88 1 8729 21645
12 96 1 9523 23613

The loss is about 1%.

[westfw]

I wonder how ST defines/implements a "wait state" on flash.  Even the benchmarks I did on 103 (which showed about 10% per wait-state using more pessimal code) show that it has to be something different than the full clock tick it meant back in the Z80 days.

[dannyf]

Not quite the ghetto style, STM32F100RB running on WS0 and WS2:

Code: [Select]

PLLx F_CPU WS O0 O1
2 16 0 571 888
3 24 0 857 1333
4 32 0 1142 1777
6 48 0 1714 2666
8 64 0
10 80 0
11 88 0
12 96 0


PLLx F_CPU WS O0 O1
2 16 2 571 888
3 24 2 857 1333
4 32 2 1142 1777
6 48 2 1714 2666
8 64 2
10 80 2
11 88 2
12 96 2

The chip doesn't run at PLLx8 or over (64Mhz or over). But it runs fine up to 48Mhz, for a chip that's rated 24Mhz.

2x over its rated max clock rate. Not bad.

[Koepi]

The test is nice, but there is a .. but

The flash latency only comes into play when there is code read from the flash. Next to a latency flag there is a flag for a cacheing mechanism. The code for flipping a pin obviously fits very nicely into this cache. I find modern techniques mentioned for the ST-µCs like branch cache, instruction prefetch and so on.
http://www.st.com/web/en/press/en/t2477

Thus more complex and unpredictable code flow will show the worst case performance, while pin toggling should be very close to "run from RAM" performance. Which is the case, as your tests show.

Calculating the first 1000 digits of Pi for let's say 1000 times and measuring the time needed would be a more suitable test for flash latency and ALU performance, I think.

[Kjelt]

The flash latency only comes into play when there is code read from the flash. Next to a latency flag there is a flag for a cacheing mechanism. The code for flipping a pin obviously fits very nicely into this cache. I find modern techniques mentioned for the ST-µCs like branch cache, instruction prefetch and so on.
http://www.st.com/web/en/press/en/t2477

That is for the F2 series they have a branch cache, the F1 series only has a prefetch queue.

[dannyf]

Thus more complex and unpredictable code flow will show the worst case performance,

Houston, we have a winner!

You are absolutely correct. The unbelievably good performance under WS>0 is ******entirely****** due to the predictable nature of the code -> so that they can be stored in the pipeline and flash latency settings are entirely irrelevant.

If you put entirely unpredictable code in there, there will be significant penalty for WS>0.

[dannyf]

Tried the following test on my STM32F030F ghetto board.

The code tests a random number (generated from the adc module) and branches out to one of two identical routines that blink the same led.

We then measure the frequency of the LED blinking.

0WS: 360Khz;
1WS: 247Khz, or ~2/3 of the speed with 0WS.

[westfw]

What about just a short loop?  Your original version had a bunch of unrolled bitflip sequences, right?
A short loop:
   while (1) { bitflip(LED); }
defeats both the internal pipeline and the flash prefetcher, I think (but would do better with a smarter "flash accelerator."  Probably.)
1/3 slower sounds more like a traditional wait state, after all, since other indications show that writing to gpio is a two-cycle operation.

[neslekkim]

How long until we get an similar guide for the stm32f7?

[dannyf]

stm32f7

If and when that chip is made,

[Koepi]

There you are, here it is: http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1858
http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1858?icmp=ss1858_pron_pr-stm32f7_sep2014 (only a few hours old)

Not yet listed at Farnell, no Cortex M7 as choice ...
http://www.newark.com/webapp/wcs/stores/servlet/Search?st=stm32&catalogId=15003&categoryId=800000028003&langId=-1&storeId=10194

But I fear that's nothing for ghetto style.

[Kjelt]

Interesting this Tightly-Coupled Data/Instruction Memory, any idea what that is about, is it fast mem 0WS or something like that or??

Found it:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0338g/Chdhbjjb.html

The purpose of the Tightly-Coupled Memory (TCM) is to provide low-latency memory that the processor can use without the unpredictability that is a feature of caches.

[dannyf]

It looks more like a processor with lots of pins than a microcontroller - I guess that's where everything is going.

But I fear that's nothing for ghetto style.

It does come in LQFP packages so ghetto'g is still possible.

As it is just announced it will be months if not a year+ before it is available. It took STM32F030F quite sometime to be available in limited quantities.

[dannyf]

The likely target for the M7 chip is the proprietary 32-bit chips (Freescale / Renesas), or the dsp chips (TI).

Interestingly, Freescale is one of the three launch customers for M7. ST being one makes a lot of sense to me. Atmel being one doesn't quite - maybe the days of AVR32 are really numbered.

It will be interesting to see if ARM takes a high-performance single core or a medium performance multi-core approach for microcontrollers. NXP took the later route and wasn't terribly successful. The single core approach would bring down market many of the tools and approaches used by micro-processors in the handset market.

Time to really check out DS-5 I guess.

[dannyf]

STM8S003F, doing pwm on tim1, ch3 (PC3).

The picture on the left was taken when the led as going from fluctuating from 0->100% duty cycle.

The picture on the right was taken when the led is fixed to 1% duty cycle.

TIM1 has 4 pwm channels and TIM2 has three pwm channels.

So TIM1 configured into pwm generation + sensors + algorithm is essentially your flight controller for a quadcopter;

Do the same to TIM2 and you have a tricopter.

Coding is super easy.

[paulie]

Afraid not danny. More than a dim LED does multicopter make. PID, Kalman, waypoint sequencing, GUI interface, complementary filters, and lots more. Neither STM8 nor F0 is up to the task. Not even close. In fact 103 even overloaded to 128k is considered old school by some and pushing for F4. Me thinks you have stepped a little too far outside your area of expertise this time.

[Koepi]

paulie, I think you're looking at this from the wrong angle.

You can setup a _cheap_ working controller unit for a quad wiith a STM8 or an F0.

What you're describing is from the "development front".
And there you could say, wow, F4xx is even too small: Ask a Boing engineer what he thinks about a single F4xx

dannyf didn't claim that you can build the non-plus-ultra-blowing-all-away quad; he wrote that you can build a controller for it (even if it's just a very simplistic one, without GPS, autonomous pathfinder, POV video, ...).

[paulie]

Yes, but can one create software that will fly and not careen off in random directions or flip?

Multicopter firmware is what lured me into ARM world in the first place.  Very familiar with AVR projects like Multiwii and Ardupilot or even ARM based ones including Timecop's Baseflight and Harakiri. I know there are low end projects too like KK and some of the toy copters but never encountered anything that might be compatible with 003 type MCU. I have quite some stock of MPU6050 and other mems sensors and recently purchased over a hundred of these 003 at bargain price so would love to take advantage in this area. It would be very much appreciated if you could direct me to any image files for this chip such as are published for the other MCUs.

[dannyf]

STM8S003F, doing pwm on tim1, ch3 (PC3).

In comparison, this is STM32L152, doing pwm on tim3, ch3 (PC8).

Vastly different chips, totally different implementation (one via library and another via direct register access). The user code however is identical.

That's the power of middleware.

[Koepi]

paulie,

to my knowledge there is no such project public available. You'd need to port a project yourself or take the know-how/documentation of those and completely implement it from scratch for a new MCU.
With some experience in development not a too hard task. But that experience is definatly needed.

dannyf: the class library/middleware makes the coding a breeze. I think the problem for these memory limited cheap MCUs is that these libraries bloat the resulting binary way too much. So it would be better to take the reference data sheet and do more of a bare-metal coding directly with using the registers. Without question you can do that, but there the disadvantage of the many peripherals and complexity shows - compared to a ATmega datasheet, you have way more to read

[paulie]

to my knowledge there is no such project public available. You'd need to port a project yourself

How did I know you were going to say that?

First of all I'm the fellow insisting this is not possible. It don't sound reasonable to ask me to do something I'm saying can't be done.  If FC firmware were successfully implemented on a 25 cent chip like 003 it would be big news rippling across the globe. Not only the main subject on sites I frequent like multiwii.com and diydrones.com but probably make front page NY Times.

This is not "developmental" or a niche market. Between commercial entities like Syma, WLT, Hubsan, etc. and hobby grade products from the DJI, Hobbyking, bangood, and others we are talking billion dollar sales. These have been the top playthings every year for at least the past six years starting with the low cost IMU sensor revolution. First the heli phenomenon with cheap murata piezo clones then widespread availability of mems devices. Big sales, big money, big news.

Secondly I do have some experience in this area. After experimenting with the top dozen or so DIY platforms and more than one failed attempt at "bare metal" I have a pretty good idea of what's involved. Both in terms of effort and MPU resources. So I have to laugh at the way danny tucks in the word "algorithm" as though it's another blinky and:

Coding is super easy.

LOL. I'm not as impressed by all the photos of an LED with keyboard backdrop as apparently everybody else. Why bother? They all look the same and could be just wired directly to VCC under the board. IMO links to functional toolsets and actual working programs would be far more helpful than cryptic code snippets and unbacked claims. More so than all this "look how smart I am" stuff. Not that I mind that but maybe reinforced with a little hard evidence.