New STM32F0 devices (Cortex-M0)

[Badger]

I'm very interested to see a comparator on these chips, something I've been missing on the other STM32 devices. I want to try and do video sync detection, so it should be very helpful. Perhaps we should have a Chibios Comparator driver!

[Giovanni]

That would be easy to do but very STM32-specific, if I remember well also the L1 have comparators.

Giovanni

[colin]

The operation of MCU-integrated comparators is probably pretty architecture-specific, so having a HAL driver might not be a big advantage, but there are other MCUs with comparators too, so it is possible a HAL driver could be useful. See MSP430 for instance. Maybe others.

[Giovanni]

From may point of view the comp driver would be just a configuration structure containing the content of the COMP_CSR register, the comparators output go to timers inputs that can be captured by the ICU driver or to EXTI inputs that can be handler by the EXT driver. Basically the support is mostly already there.

There is no clock activation needed so compStart() and compStop() would just write that register. I think that an STM32-specific "helper" driver could be sufficient.

It is hard to abstract it without overlapping the EXT driver role.

Giovanni

[Badger]

From may point of view the comp driver would be just a configuration structure containing the content of the COMP_CSR register, the comparators output go to timers inputs that can be captured by the ICU driver or to EXTI inputs that can be handler by the EXT driver. Basically the support is mostly already there.

Very true, it would be a simple driver.

I received 3 of the STM32F0 discovery kits today, I ordered a few to get free postage, so I have a spare if anyone wants it? I will send for free to anyone who wants to work on the I2C driver for it (maybe king of I2C barthess??!)

[colin]

Is the STM32F0 I2C peripheral different from the STM32F1 version? I thought its I2C was pretty well fully functional already.

[Giovanni]

It is very different, they fixed a couple of important issues with the old I2C, Barthess had a lot of trouble in writing the driver because that.

The new I2C looks much better but the driver is not compatible yet. In general all the F0 peripherals received upgrades: ADC, SPI, USARTs, I2C and probably more. Small changes but very significant, STM32 peripherals all went through a careful review apparently.

Giovanni

[Badger]

Now it would be nice if they released a new F4 with all the new peripherals!

Anyway, I will extend my offer of the discovery kit to anyone who can contribute something useful to the chibios STM32F0 port with it.

[8bitgeek]

Hi Giovanni,
That's good to hear. Although I'm confused and saddened why the STM32F0 chips are hardly cheaper than the STM32F100 series.

E.g., Mouser prices:
STM32F051K8U6 US$3.17 (64K/8K, cheapest F0 on Mouser).
STM32F100C6T6B US$2.55 (32K/4K, cheapest F1 on Mouser).
STM32F100C6T6B US$3.76 (64K/8K, comparable to the F0 above).
I was hoping for a device to compete with LPC1000 series like
LPC1111FHN33/202,5 US$1.40 (8K/2K)
LPC1114FHN33/202,5 US$1.90 (32K/4K)

Maybe try Arrow Electronics for the good prices - STM32F051K8U6 US$1.77

-- 8bitgeek

[Jacon]

Hi Giovanni,

1. Answering my own previous question:

How about size limitations in this new Atollic GDB?

I may confirm your opinion - GDB server is in full, PRO version, without any restrictions.
But "TrueStudio Lite" as a whole is totally crap from version 3.0 on - 32 kB code size limitation for STM32F1's and up,
and 8kB only for STM32F0's ! Compilation of our makefile projects proceed OK, but starting debug
session ended up immediately with a.m. size limitation message
So, this quote from your http://www.chibios.org/dokuwiki/doku.ph ... nk_eclipse :

Note that less expert users could just use TrueSTUDIO as-is

deserved to rejection, as it's not valid anymore...
TrueStudio rel 2.3.0 worked perfectly well with new server, but you may use it till next
reinstall of your PC only - Atollic rejects every attempt to register new installation of it
I, for one, moved definitely to fully FOSS Eclipse solution

2. You apparently missed my first post from 26'th May in this topic - "stm32f0xx.h" file in trunk
is not consistent with: its equivalent in STD-Lib, RM0091(description, not register chapter!),
STM32F051 Datasheet and my xml file in RTC area - RTC_TAMP3 Input doesn't really exist,
so every reference to it in RTC registers bit definitions should be deleted (as they are in actual STD-Lib file)
It was typical ST's documentation bug...

Regards
Jacek