STM32, ghetto style

[dannyf]

I have been a staunch critic of ST's i2c implementation.

However, not all is lost. It can be made to work, with some hardware.

Here is a STM32F3 reading acceleration data from a LSM303 (accel + mag) over i2c, @ 100Khz.

[Koepi]

A little off-topic, but this fits the Ghetto Style theme: My neighbour likes fishing a lot. So I ordered some mpu6050s, some piezo buzzers / transducers and built up an Arduino Pro Mini board (don't worry, I use Eclipse/avr-gcc to program it; thus it's more like a comfortable built up ATmega board). Works like charme, though I'm too lazy to implement power saving stuff. Tonight I started the minimizing process - replace dupont wiring with enameled copper wires, isolating with capton tape, using shrink wrap.
Only thing missing is mobile 3.3V power supply.

This thing starts beeping with the slightest movement, really nerve wasting. Thus if a fish bites when he has taped this to his fishing pole, he'll be aware of it. Looks ghetto, too!

[Koepi]

dannyf, I totally agree that I2C with STM32F0 is PITA. I tried (succesfully!) communicating with a RDA5807M FM tuner chip (idea: decoding RDS to fetch time information for the RTC of STM32). It was quite some tuning in the I2C parameters for timing and signal processing necessary, but eventually I got it right.

I guess this works with a lot of I2C chips:

Code: [Select]

GPIO_InitTypeDef GPIO_InitStructure;
I2C_InitTypeDef I2C_InitStructure;

// Initialize I2C (PB6 = SCL, PB7 =SDA)
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE);
RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE);
RCC_I2CCLKConfig(RCC_I2C1CLK_SYSCLK);
GPIO_PinAFConfig(GPIOB, GPIO_PinSource6, GPIO_AF_1);
GPIO_PinAFConfig(GPIOB, GPIO_PinSource7, GPIO_AF_1);

// I2C Configure pins: SCL and SDA
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_InitStructure.GPIO_OType = GPIO_OType_OD;
GPIO_Init(GPIOB, &GPIO_InitStructure);

I2C_DeInit(I2C1);
I2C_Cmd(I2C1, DISABLE);
I2C_InitStructure.I2C_AnalogFilter = I2C_AnalogFilter_Enable;
I2C_InitStructure.I2C_DigitalFilter = 0x00;
I2C_InitStructure.I2C_OwnAddress1 = 0x00;
I2C_InitStructure.I2C_Mode = I2C_Mode_I2C;
I2C_InitStructure.I2C_Ack = I2C_Ack_Enable;
I2C_InitStructure.I2C_Timing = 0xB0420F13;  // magic!
I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit;
I2C_Init(I2C1, &I2C_InitStructure);
I2C_Cmd(I2C1, ENABLE);
Edit: Added the LA graph as well.

[dannyf]

I failed to attach the waveform in the earlier post so here it is:

[dannyf]

I guess this works with a lot of I2C chips:

That's what I do as well.

The frustrating part for me is in the block read/write routines where exception handling varies from family to family - they the NXP approach and "scattered" it randomly.

The Atmel / PIC approach works really well, in comparison.

[dannyf]

This thing starts beeping with the slightest movement, really nerve wasting.

Looks like an interesting project.

Two ways to control sensitivity:

1) use the motion driver library from invensense. It has a double tap function built-in. You have to register with them, however.

2) if you don't care about energy consumption, you can think of the fishing pole as an "airplane" and you just need to calculate sudden changes in its "flight" parameters. Look into the various IMU algorithms floating around and it is not difficult to adapt it to your application.

A harder approach is to go naked - fuse the accelerometer + gyro data yourself. The difficulty here is drifting: the parametres will drift back and forth by itself so some kind of filtering, with all 6 parameters preferably, would be helpful.

The mpu6050 is an incredible sensor: very sensitive and yet stable. In comparison, the LSM303 / L3GD20 from ST are lacking.

[Koepi]

Hehe  I use a 'moving' average from the last ten samples and if the new sample is above a threshold - which is used as sensitivity tuning parameter - from the average I start the buzzer. Works very well!
The nerve wasting part starts when you are still coding and every key pressed is causing the noise 

[dannyf]

I prefer LEDs,

On moving average, not sure if you read from fifo or not but a simple way to perform a moving average is this:

Code: [Select]

  avg += (new_data - avg) >> n;

it is essentially the binary implementation of this:

Code: [Select]

  avg = avg * (1-weight) + new_data * weight;

where "weight" is 1/2^n.

It requires little data and can be done quickly, even on lowly 8-bitters.

n effectively controls the memory of the filter: the higher the n, the longer it remembers the past and the slower its output changes with new data.

Hope it helps.

[dannyf]

wavefrom of reading DS3231 using a ghetto board's I2C1 running at 100Khz.

The i2c address is 0xd0 / 0x68, depending on your notational system.

edit: needed to point out there there is no device on the bus when this picture was taken -> thus no ack for the address sent.

[dannyf]

Incomplete without showing the ghetto connection:

The ds3231 is an ebay knock-off: it is off about 1 minute per month -> 20ppm actual vs. 2ppm spec,

[Koepi]

Funny that you mention it, today I did some research on fixing my cheap DS1307 boards which are 30 minutes off after half a year now. That was one of my first µC projects, to build a watch using I2C communication, controlling a 4digit 7segment LCD, measuring Vcc as well as temperature with the built-in peripherals, using power-save modes and run that on a 18650 LiIon cell - runs a month straight with one charge!
I have the same DS3231 PCB still waiting in it's ESD protection pouch. Wanted to fix the DS1307 with soldering the crystal to the GND area and maybe replace it with a better suiting one (next to solder an additional 10µF tantal + 0.1µF ceramic capacitor to Vcc; also shortening the jumping wires from 8" to way less length for the SDA/SCL lines) as first attempt before throwing those parts into trash.

On a sidenote, I use the "Pin13" (PinB5) LED on the Arduino board for feedback as well, so it's an "audio visual bite indicator".

[dannyf]

"audio visual bite indicator"

It wouldn't suprise me if there is a market for something like that: use a pot / button to adjust sensitivity + button to adjust chirping pattern.

A cheaper version for regular fishermen and a more expensive, multi-sensor version for sea fishermen.

[paulie]

Wanted to fix the DS1307 with soldering the crystal to the GND area and maybe replace it with a better suiting one (next to solder an additional 10µF tantal + 0.1µF ceramic capacitor to Vcc; also shortening the jumping wires from 8" to way less length for the SDA/SCL lines) as first attempt before throwing those parts into trash.

I can tell you from experience there is no hope for 1307 accuracy in a typical environment. The only way to adjust frequency is changing the caps on each end or write complicated auto-correct software which needs to be updated periodically from an atomic reference. Then there's that temperature thing which needs a sensor somewhere in the system.

The only thing going for it is low cost. Not worth it. In my opinion pay a little more for the compensated one or just hook a 32khz crystal up to the MCU. A buddy of mine built a RTC with 7 segment similar to you but with STM32F103C only. Same battery too. After 4 months less than 3 seconds off. Cheaper and more accurate than either of those chips.

ps. I should have listened to his sales pitch when he was trying to convince me back then but thought the tools were nasty just like the architecture. Little did I know...

[Kjelt]

Darn is that 1307 that bad? I am just using the 1337 probably the same?
The AN58 states that the crystal should be matched and that the accuracy is between 0 and 40 degrees C <10ppm?
Maybe you have the wrong crystal match?

[paulie]

Yes, they really are that bad. Compounded by one of those rare cases where the cheap Chinese IC and crystal knockoffs may be making things worse. It's true that using bona fide source and specific crystal part number may help but then you end up paying an arm and a leg.

IMO using the built-in RTC feature specifically designed into STM32 for this purpose is the best path. Not good for Arduino enthusiasts with their ready to go "sketches" and "shields" but great for the new generation of ARMduinos.

[dannyf]

Maybe you have the wrong crystal match?

Likely. The 1307 requires a stable crystal, and matched capacitance to work. 323x assures the matching and on top of it provides temperature compensation.

Feeding the 32Khz output from the 323x to the 1307 will get you equally good results.

Plus, there are ways to compensate for timing errors in 1307, with a mcu.

[Koepi]

Damn, I have several RTCs around. My clock was off 30 minutes after half a year - which has to be considered quite good when asking around; many RTCs are that bad in less than a month.
When I returned from work and took a look at the board I used, I had to laugh: It's a DS1302. And what do you guess, as if I knew about this thread back then, that China board is real ghetto style. The DS1302 as DIP version, a 32.768kHz crystal (unclear whether it is matched to suite 6pF) and a battery. That's all, no additional components. According to the data sheet, that should work. But it doesn't (properly).

What I did now is: Add 100nF+1µF ceramic capacitor to Vcc2 (-> power from µC). Added 100nF for Vcc1 (battery). Put a big solder blob below the crystal. As GND is the plane on the other PCB side, used an enameled copper wire connection to contact that blob to GND.
Additionally replaced some dupont wires with enameled copper wires so the distance is reduced; in fact, I isolated the backside of the Arduino board and taped the RTC board against it. Now only the 4-digit 7-segment has 8 dupont wires left; the common cathodes are connected with enameled copper wire now, too.

For now the result looks good. Set the time around 7P.M., now three hours later there is no noticable drift from the 12-13 seconds I set it too late. Have to watch it a few days though. Edit: 12 hours later, I see 1-2s drift again; would sum up to ~4s/day, 2 minutes/month, 12 minutes/half year and thus be an improvement at least. I'll keep on monitoring and probably will update this post later again
Took the time to clean up the code I used back then. I had it nearly right, doing stuff between several timestamps (milliseconds) - but did that in the ISR instead of the mainloop. A few more volatile variables later, this is close to proper code now

[dannyf]

would sum up to ~4s/day

If it is consistently off 4s/day, you can compensate for it quite easily: for example, set up a daily alarm and retard timing by 4s once it goes off; or (my preferred way), write the last time you retarded timing in the ram and ever N seconds later (N being sufficiently large, like 1 million), you retard or advance timing by a set amount, and write the time you altered the timing into the ram.

It allows accurate timing down to sub ppm levels.

Useful however only if the rtc works in a stable (temperature wise) environment. Otherwise, the temperature drift will overwhelm.

[Koepi]

Just implemented that now - added a write routine for the DS1302 and set the CLK_HLT bit at 18:10:00 and clear it at 18:10:03. I think that those modifications led to a more stable and correct timing. The DS1302 is a pure timekeeper and offers no alarms, though, so I needed to do that in my huge if..then..elseif.. construct which I use as main loop.
I need to play with STM's built-in RTC though. When I try tweaking powersave, refreshing/lighting up the 4digit 7segment every ms, thus using timer2 (which is available in powersave mode), I can't get clear frequencies like 1ms. I get 778Hz, 1.11 kHz, 3.34kHz and similar, but nothing even. I hope with the F030 RTC for example, I can put the µC to sleep and wake it via RTC interrupt every ms. Which would once more beat the sh** out of old and much more expensive ATmega.

[dannyf]

STM's built-in RTC

ST implemented RTC modules fairly inconsistently - almost purposefully inconsistently. Some of them are full featured, but the one in F030 is bare minimum - it is simply a counter. No second isr, for example.

[Koepi]

Hm, the data sheet doesn't imply it's not available on the F030:

Code: [Select]

6.3.6 RTC wakeup from low-power mode
The RTC can be used to wakeup the MCU from low-power mode by means of the RTC
alarm. For this purpose, two of the three alternative RTC clock sources can be selected by
programming the RTCSEL[1:0] bits in the RTC domain control register (RCC_BDCR):
? Low-power 32.768 kHz external crystal oscillator (LSE OSC)
This clock source provides a precise time base with very low-power consumption (less
than 1µA added consumption in typical conditions)
? Low-power internal RC Oscillator (LSI)
This clock source has the advantage of saving the cost of the 32.768 kHz crystal. This
internal RC Oscillator is designed to add minimum power consumption.
To wakeup from Stop mode with an RTC alarm event, it is necessary to:
? Configure the EXTI Line 17 to be sensitive to rising edge
? Configure the RTC to generate the RTC alarm
To wakeup from Standby mode, there is no need to configure the EXTI Line 17.
Source: STM32F030 Reference Manual, Page 73/655 at the bottom.

You'd need to set an alarm for every next second though, to have a "every second ISR". Not really elegantly solved.

[dannyf]

The give-away is in the interrupt section: no second overflow interrupt for the rtc.

Yes, setting up the alarm is the only way to go.

Because of that, I don't think the rtc on F030 is much useful.

[dannyf]

I wrote in a separate thread that with a timer you could fairly easily constitute a multi-channel pwm generator on a PIC.

The same can be done on a stm32f as well - normally, there are more than sufficient hardware pwm channels on a stm32f - 12 on a puny STM32F030F4 for example.

There are timers on STM32F that don't have output compare capabilities - typically on TIM6/7. With the help of software, those timers can be easily turned into pwm generators as well:

1) set up timer to trigger isr periodically;
2) in the isr, increment a counter;
3) on each increment, test for pins where the desired duty cycle is the same as the counter's current value and set/clear the corresponding output pin.

Here is its implementation on the ghetto board (STM32F030), two channel 50Hz pwm.

[dannyf]

Here, two channel pwm at 400Hz.

[dannyf]

As the implementation is entirely done in the isr, it is fully transparent to the user. From that perspective, it behaves just like a hardware pwm generator.

Unlike a hardware pwm generator, however, it does take a way the mcu's processing power. And the smaller the timing steps, the more processing power it consumes. As such, this approach is more suited for low frequency pwm.