STM32, ghetto style

[westfw]

[be modular]
#define ADCx            ADC1                  //adc1 module used

It is expecting that when you create your adc2 module, you can simply redefine ADCx to ADC2, and other changes, and the new adc2.c will recompile flawlessly.

One of the annoying things about most of these 32bit chips is that a peripheral will be dependent on other registers of other peripherals that you can not easily derive, algorithmically (RCC[ADC1] |= ClkEnaBit[ADC1] nor symbolically (RCC_ADC1 |= ADC1_CLOCKBIT;)   The clock distribution registers are the most obvious example, but also things like:

Code: [Select]

   if (GPIOx == GPIOA ) RCC_APB2PeriphResetCmd(RCC_APB2Periph_GPIOA, ENABLE);
else if (GPIOx == GPIOB) RCC_APB2PeriphResetCmd(RCC_APB2Periph_GPIOB, ENABLE);
else if (GPIOx == GPIOC) RCC_APB2PeriphResetCmd(RCC_APB2Periph_GPIOC, ENABLE);
else if (GPIOx == GPIOD) RCC_APB2PeriphResetCmd(RCC_APB2Periph_GPIOD, ENABLE);
are really ugly.  And code-bloating.  (And the ST peripheral library contains similar code, so it's not dannyf's fault.)  It wouldn't be so bad if these were set up as inline, or templates, so that the compiler would eliminate unneeded code, but that's certainly NOT the case when the code is off in the external peripheral library.)

[Koepi]

A friend of mine is electronics engineer and he showed me to "staple" the capacitors. This is quite logical as the paths are way shorter this way for the 10µF capacitor. The ferrite beads didn't arrive yet, still I wanted to correct that now already.

As I'm now playing with i2c, the pins PA9 and PA10 are used for that. Thus for flashing I need to use SWD via st-link. I put UART output via AF to PA3+PA4. And now something really weird happend: texane/st-link _works every single time_.  No need to press reset or BOOT0. It just works. 
Edit: I just verified, it's the proper decoupling! Without UART connection, st-link still works!

I don't know whether the proper decoupling is to blame or the "rewired" UART. Anyhow, I'm really happy now.

The UART output module would look like this in my case, by the way:

Code: [Select]

static char text[255];

// init stuff
USART_InitTypeDef USART_InitStruct;
RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE);

// UART1: Configure PA2 and PA3
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2 | GPIO_Pin_3;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOA, &GPIO_InitStructure);

GPIO_PinAFConfig(GPIOA, GPIO_PinSource2, GPIO_AF_1);
GPIO_PinAFConfig(GPIOA, GPIO_PinSource3, GPIO_AF_1);

USART_InitStruct.USART_BaudRate = 57600;
USART_InitStruct.USART_WordLength = USART_WordLength_8b;
USART_InitStruct.USART_StopBits = USART_StopBits_1;
USART_InitStruct.USART_Parity = USART_Parity_No;
USART_InitStruct.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
USART_InitStruct.USART_Mode = USART_Mode_Tx | USART_Mode_Rx;
USART_Init(USART1, &USART_InitStruct);
USART_Cmd(USART1, ENABLE);
// end of init


void uart_tx(char *out) {
while (*out) {
while(!(USART1->ISR & USART_FLAG_TXE)) {
// Nothing, really.;
}
USART1->TDR = *out++;
}
}

Usage example:

Code: [Select]

        RCC_ClocksTypeDef Clocks;
RCC_GetClocksFreq(&Clocks);

sprintf(text, "STM32F030-Test begins.\r\nHCLK is %d MHz, PCLK %d MHz, System %d MHz, ADC %d MHz.\n", (Clocks.HCLK_Frequency/1000000), (Clocks.PCLK_Frequency/1000000), (Clocks.SYSCLK_Frequency/1000000), (Clocks.ADCCLK_Frequency/1000000));
uart_tx(text);


[dannyf]

I would try to do uart transmission via interrupts so it doesn't tie down the mcu. If you have tons to send, DMA would be better.

[dannyf]

What doesn't STM32F030F have?

Well, it does not have TIM6, nor does it have TIM15, consistent with the datasheet.

[Koepi]

My Mac OS X flash tool even suggest 64kByte of flash:

Code: [Select]

MacBook-Air:Release koepi$ ./flash.sh
stm32flash 0.3

http://stm32flash.googlecode.com/

Using Parser : Intel HEX
Serial Config: 57600 8E1
Version      : 0x31
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0444 (STM32F030/F031)
- RAM        : 8KiB  (4096b reserved by bootloader)
- Flash      : 64KiB (sector size: 4x1024)
- Option RAM : 12b
- System RAM : 3KiB

Wrote and verified address 0x080014f0 (100.00%) Done.
I don't know how reliable these values are, though. Some of my minimum stm32f103c8 boards are shown as having 128kByte flash, too.
Edit: Just found it in the versioning system: https://gitorious.org/stm32flash/stm32flash/commit/0255c1cf4bcc4412c4cdd1e60be35ab2aedcffa8
"The values for RAM, flash location and size etc are deducted from the chip ID and not reported explicitly by the device. They are also not always true."

On a sidenote, I "assembled" a useful table of AF pinout, find it attached.

[westfw]

On a sidenote, I "assembled" a useful table

Nice.  Why can't datasheets contain such concise info.

Would you be willing to make this a shareable google spreadsheet?  Then you can re-sort on assorted columns, which I find to be useful, sometimes (I have a docs for Arduino pinouts: https://docs.google.com/spreadsheet/ccc?key=0AqdMB5dovDUZckNXSnNQa0FiWldNMFhWcHV1ODFzR0E&usp=sharing )

[enz]

On a sidenote, I "assembled" a useful table

Nice.  Why can't datasheets contain such concise info.

Well, they do:

[dannyf]

stm32f103c8 boards are shown as having 128kByte flash

F103C8s definitely have more than 64KB of flash -> they are actually CBs?

There are also examples where non-USB STM32F were found to have USB capabilities. I think ST is marking down higher spec chips so they can occupy a wider spectrum of the market. Actually making those lower spec chips is more expensive for them.

The downside with this approach is that programmers like ST-link cannot access those "excess flash" -> unless you to the higher spec versions. Instead, you have to use IAP.

The values for RAM, flash location and size etc are deducted from the chip ID and not reported explicitly by the device. They are also not always true.

That has not been my experience -> the reported numbers are always correct.

[Koepi]

Well, they do:
<kinetis datasheet screenshot>

Well, Kinetis is a different µC

It's all there in the STM32F03xxx datasheet as well. But it is split up in two bigger tables, for all pinout versions, so you have to jump back and forth to combine them to your actual µC incarnation pinout.

Is there a way to put a google spreadsheet up "anonymous"? I dislike the idea of strangers sniffing in my Google account I think as a single image it is already as useful as it can be, sorting around with 15 usable pins is not really necessary

@dannyf: That makes sense and usually is what processor manufacturers do; known from Intel since the early days, back where you could use a drill to activate the FPU of "crippled down" 486sx ( https://en.wikipedia.org/wiki/Intel_80486SX ). Edit: Uh, actally that was an April Fool's joke from Andreas, that hole drilling didn't turn out well http://dictionary.reference.com/browse/intel+486sx

[dannyf]

I have a compaq laptop that uses those crippled SX chips. It is kind like today's notebook running Atom with a mono STN lcd display. It is still somewhere in the house,

[Koepi]

Nice Couldn't afford a laptop back then - my first PC was a 486DX50 (yes, that wonder-thing _without_ the 25MHz x2 bus. But still with a Turbo switch ).

But back to topic: I wonder why your ghetto style works without problems without any additional part. Well, maybe it's just the blinking of the LED at the default 8 MHz, that doesn't put much stress on the power lines.

I now finally have:
- the stm32f030f4 µC,
- 2 100 nF block capacitors,
- 1 10µF additional block capacitor,
- 1 250kOhm pulldown resistor for BOOT0,
- 1 ferrite bead

Fading (thus fast switching noise on the power lines) the LED, using a higher frequency, using the ADC - that all sums up that you need a few more parts to make the µC work stable and properly.

Now I'm still finetuning the result. Enamelled copper wire seems to suffice as it makes no difference when I connect the VDDA with thin "normal" wire. I think an additional 1µF capacitor next to the 100nF at VDDA (as suggested by the ST AppNotes and the datasheet) may stableize the ADC even more. Though for first tests the 1-2 LSB precision is already very nice.

[dannyf]

I wonder why your ghetto style works without problems without any additional part.

Those things are pretty robust - in that regard, the STM32 isn't that unique, as I have done similar things with other chips.

Well, maybe it's just the blinking of the LED at the default 8 MHz, that doesn't put much stress on the power lines.

The fastest "blinky" I have done on this very setup is 64Mhz (1ws) and 48Mhz (0ws). zero problem whatsoever. The chip is powered via a st-link clone over a 5-6 inch wire. VDDA connected to VDD via another 5-6 inch wire. Absolutely no additional part.

The little thing just keeps going.

[Koepi]

You're right, that "just blinking" isn't too much to ask from a µC. That also works with ATtiny13/85 without 100nF block capacitor

For the st-link to work properly the additional parts were necessary, and for a proper precision when measuring with the ADC. If you don't need that, it should be ok to use the µC "ghetto style". It's just that it's not reliable in all conditions (other than room temperature and mediocre air humidity, for example.) I guess.

[dannyf]

it's not reliable in all conditions

For sure. It is appropriate to do good decoupling and layout, especially for demanding applications.

The goal of going "ghetto" is to show how little it takes to get the chip running.

[paulie]

Good to see we are finally gravitating here to what is really the best choice, not only for STM, but ARM in general. No point in those STM8 which can't even begin to compete with old 8 bits like PIC and AVR. F0 no competition in terms of popularity/availability. Maybe someday, maybe never, but not at this time.

ps. Regarding 64/128k a quick peek at the RCGroups link I posted here answers that in the first posts. Those who have bothered to fire up the ST flash demo utility also find out quickly that the default 64k setting can be over-ridden on the next page and tested with "fill" functions there.

[Koepi]

Heh, those stm8 ... I saw those boards for 2 bucks for two pieces, so I ordered them. And a third one for another 3 bucks which hd some more GPIO and memory. But then the problems start: SDCC can work with Eclipse, but where to finde the equivalent of ST Standard Peripheral Lib? As the small stm8s don't have a bootloader, where is the program to upload the binary via SWIM?
I just gave up on them.

These stm32f030 are what I was looking for in terms of building my first own development board. Ok, I put a ATtiny13 SOIC8 on a DIP adapter, used a socket and some RGB LED, tactile switches and stuff for testing that out, but the way too little memory was limiting everything.

Thus cheap 32bit power, combined with my own hands, is what makes me really happy

[dannyf]

where to finde the equivalent of ST Standard Peripheral Lib?

st.com

As the small stm8s don't have a bootloader, where is the program to upload the binary via SWIM?

I use IAR-STM8 and the embedded programming via st-link does all the work for me. It was a breeze.

I also got it work on STVD/Cosmic through swim. Fully supports debugging and programming.

Their beauty is in the incredibly low prices - I got mine for 15 cents delivered. Tough to beat that.

I have not done much extensive testing but I think those 003s are actually 103s marked down.

They are a lot more feature limited vs. the 32F030 chips.

[dannyf]

combined with my own hands

Someone could have made an adaptor, with the chip + decoupling gaps + power connectors + pins soldered on, like they did with the 003 chips.

[dannyf]

Actually I posted a piece of the ghetto code for STM8S003 earlier in the thread. It realizes on the STM8S standard peripheral library and should work on all STM8S chips.

[paulie]

Thus cheap 32bit power, combined with my own hands, is what makes me really happy

I agree there is nothing more fun than DIY specially considering how cheap these things are. I also ordered both STM8 and F0 parts but only after getting hooked by the 103c. Basically out of scientific curiosity since I am one also of those geeks that likes to poke into a new chip every day.

Ok, I put a ATtiny13 SOIC8 on a DIP adapter, used a socket and some RGB LED, tactile switches and stuff for testing that out, but the way too little memory was limiting everything.py

Not if you shuffle off the C shackles and open yourself to asm tools. Tiny13 has proven very powerful on sites like RCGroups and Arduino forum.

Even though i'm mostly a PIC fanboy I must admit AVR is king of the mountain due to Arduino and ridiculously easy programming. AVRdude with  UASBasp or even just 4 wires to a parallel port. But more performance, memory, more IO and UARTS of these F1 chips are hard to beat. Built in boot clinches it. There's a reason this particular chip, like all the good ones, floats to the top.

[dannyf]

To continue the ghetto tradition, here is a stm32f030f running at 8Mhz on a 4Mhz crystal.

Total part count: 3 (stm32f030f, an led, a 4Mhz crystal).

[westfw]

On a sidenote, I "assembled" a useful table [of Alternate Function Register values]

Huh.  That's interesting.  I went to put together a similar table for the f103, and discovered that it apparently has a MUCH different way of configuring the "alternate functions"!

(now, does the ST peripheral library HIDE that for you, or do you end up with different initialization procedures for, say, an I2C peripheral depending on which chip you use?)

[Koepi]

There are tiny differences in the Standard Peripheral Lib setup for periphery. Among others, GPIO is different between all families, a STM32F0 setup throws compiler warnings with STM32F4.
The differences are small. You can get past them very easy by searching for example code for the µC family, for example "stm32f0 i2c example".

[dannyf]

Running on an 8Mhz crystal, no PLL.

A word of warning: for crystals less than 2Mhz (or 4Mhz to be safe), you may need a parallel resistor or both load capacitors to get the oscillator starting. I guess the drive power isn't that big (to save current consumption).

Or you can put your fingers on the leads to get it going.

[dannyf]

We talked about using adc to generate random bits.

Here is the STM32F030 ghetto board generating a few of those random bits.

The code is fairly simple:

Code: [Select]

  if (rand1_adc()) {PIN_FLP(LED_PORT, LED_A | LED_C);} //flip led