Re: [libopenstm32-devel] Requirements V0.1 release?

[Gareth M. <ga...@bl...>]

> We currently have quite good support of the stm32 I think we should try to wrap that one up and make it the first officially supported chip of libopencm3 for V0.1 release.

I think this is a great idea!

> Based on the status page we are still missing support for three subsystems of the stm32:
> - DAC
> - DebugMCU
> - SDIO

I've done a partial register map for the DAC.  I'll find it and it can
be included.
DebugMCU is only 2 registers.  I'll do this one too.
The generic Cortex-M3 Core debug / FPB / DWT would also be useful.

> I think we should also have convenience functions for at least part of subsystems. The ones still missing or partly missing are:
> - Flash (50% I think we should work on finishing that up. I think Uwe wanted to work on this?)
> - ADC (I will work on that one soon)
> - Timer (it is by now 50% as the functions support Output Compare but not Input Capture yet)
> - CRC
> - DAC (as the subsystem is not supported yet)
> - BKP
> - DebugMCU (I think this one is quite important so that we can properly debug the stm32?)
> - DMA
> - FSMC
> - IWDG
> - PWR
> - SDIO (as the subsystem is not supported yet)
> - WWDG
> - Ethernet
>
> I would say that we should have convenience functions for at least the following subsystems:
> - Flash
> - ADC
> - Timer (finish that one up so that Input Compare is easy to use)
> - DebugMCU
> - DMA

What is missing for the Flash.  I've been using the current routines
with no problem.

What convenience functions do you have in mind for the DebugMCU?
The bits in the DBGMCU_CR may be useful to set while debugging,
but I would think that you would be more likely do to this from the
external debugger than from the application.

In the back of my mind has been a plan for a GDB stub, I don't
know how interested anyone would be in this.

> Other tasks:
> - We should have examples for all subsystems that have convenience functions. For the STM32-H103 eval board as this one is very common out there. Maybe also the discovery board should get all the examples that exist for STM32-H103 ported?
> - Generalize USB implementation? (I am not an expert on that I think Gareth and Uwe should comment on that one?)
> - Generalize core clock setup routine? (rcc_clock_setup_in_hse_8mhz_out_24mhz discussion?)
> - Anything I missed? :)

I think USB is as general as it's likely to get.  There is a problem
with the USB HID
example on the STM32-H103 board, Uwe and I were trying to solve this on Monday.
I would like the USB to be working reliably for a stable release.

> What do you think? Is anyone willing to take a stab at any of these parts? What did I miss? Do you have a different take on that? I just think that coordinating a little and giving us a target of a release may focus our efforts a little and make it easier going forward? I already see that we are getting more and more momentum as more people are contributing to libopencm3 what is really great! Thanks to everyone! :)

I think some level of documentation would be really great for newcomers.
Doxygen, perhaps?  I've neglected to keep the usb api documented, as
I'm still expecting it to change as things develop.

This is another important concern.  If we provide a stable release users
will expect the api to remain consistent with future versions.  I don't think
that we are ready to freeze the api.

Regards,
Gareth

-- 
Black Sphere Technologies Ltd.

Web: www.blacksphere.co.nz
Mobile: +64 27 777 2182
Tel: +64 9 478 8885
Skype: gareth.mcmullin
LinkedIn: http://nz.linkedin.com/in/gsmcmullin