STM32 - I/O pullup and EXTI issues, plus new SPI driver.

STM32 - I/O pullup and EXTI issues, plus new SPI driver.

[Chris Holgate]

Hi folks,

I came across a couple of HAL issues while putting together my new SPI
driver for the STM32.  I appreciate that the maintainers are overloaded
with eCos 3.0 work at the moment, so I'll defer to them as to whether
any of this needs fixing now and can provide more information/patches on
request.

1) It's not possible to set pullups on I/Os using the provided
functions.  This is a trivial one-line fix to stm32-misc.c.

2) External interrupts don't work as they stand.  This requires a few
changes to the STM32 var_intr.h.  If required I can tidy up my changes
there and provide a patch which I've tested using a single I/O
(EXTINT0), but which would probably benefit from a bit more testing
using other I/O configurations.

3) I've now got full register maps for the AFIO, DMA and SPI blocks.
For development purposes I've kept these in a separate file from the
STM32 var_io.h, but can provide the file for merging if required.

FYI, I now have a DMA-based SPI driver that is fully functional in
kernel mode, but will need one or two changes (and some testing!) to
make it play nicely in non-kernel mode.  Probably best to leave that
until the 3.0 release is done, though.

Chris.

Re: STM32 - I/O pullup and EXTI issues, plus new SPI driver.

[Simon Kallweit]

Chris Holgate wrote:
> Hi folks,
>
> I came across a couple of HAL issues while putting together my new SPI
> driver for the STM32.  I appreciate that the maintainers are overloaded
> with eCos 3.0 work at the moment, so I'll defer to them as to whether
> any of this needs fixing now and can provide more information/patches on
> request.
>
> 1) It's not possible to set pullups on I/Os using the provided
> functions.  This is a trivial one-line fix to stm32-misc.c.
>   

If you don't have the time to wrap this up in a little patch, send the 
changes to me so I can do it.

> 2) External interrupts don't work as they stand.  This requires a few
> changes to the STM32 var_intr.h.  If required I can tidy up my changes
> there and provide a patch which I've tested using a single I/O
> (EXTINT0), but which would probably benefit from a bit more testing
> using other I/O configurations.
>   

I can review your changes if you want, I have done some work with EXTIs 
on my own obsolete port.

> 3) I've now got full register maps for the AFIO, DMA and SPI blocks.
> For development purposes I've kept these in a separate file from the
> STM32 var_io.h, but can provide the file for merging if required.
>   

Make a patch for the register definitions, I think this can go in the 
tree without the driver, register definitions are always welcome :)

> FYI, I now have a DMA-based SPI driver that is fully functional in
> kernel mode, but will need one or two changes (and some testing!) to
> make it play nicely in non-kernel mode.  Probably best to leave that
> until the 3.0 release is done, though.
>   

I can do a review and prepare patches if that helps. Otherwise, I wait 
until it's done.

Simon

Re: STM32 - I/O pullup and EXTI issues, plus new SPI driver.

[Jonathan Larmour]

Chris Holgate wrote:
> Hi folks,
> 
> I came across a couple of HAL issues while putting together my new SPI
> driver for the STM32.  I appreciate that the maintainers are overloaded
> with eCos 3.0 work at the moment, so I'll defer to them as to whether
> any of this needs fixing now and can provide more information/patches on
> request.

It would be nice to have the choice, in which case it's worth sorting out a
copyright assignment to the FSF for you so we can check in anything from
you. To do this, you need to request an assignment form by filling in this:
http://cvs.savannah.gnu.org/viewvc/gnulib/doc/Copyright/request-assign.future?revision=1&root=gnulib

and emailing it to assign@gnu.org

Thanks in advance!

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

Re: STM32 - I/O pullup and EXTI issues, plus new SPI driver.

[Nick Garnett]

Chris Holgate <chris@zynaptic.com> writes:

> Hi folks,
> 
> I came across a couple of HAL issues while putting together my new SPI
> driver for the STM32.  I appreciate that the maintainers are overloaded
> with eCos 3.0 work at the moment, so I'll defer to them as to whether
> any of this needs fixing now and can provide more information/patches on
> request.
> 
> 1) It's not possible to set pullups on I/Os using the provided
> functions.  This is a trivial one-line fix to stm32-misc.c.
> 
> 2) External interrupts don't work as they stand.  This requires a few
> changes to the STM32 var_intr.h.  If required I can tidy up my changes
> there and provide a patch which I've tested using a single I/O
> (EXTINT0), but which would probably benefit from a bit more testing
> using other I/O configurations.

I can easily believe that both of these don't quite work. I didn't do
much testing in this area, so any changes to make it work are appreciated.


> 3) I've now got full register maps for the AFIO, DMA and SPI blocks.
> For development purposes I've kept these in a separate file from the
> STM32 var_io.h, but can provide the file for merging if required.

So long as they match the existing naming and layout conventions these
can be added to var_io.h very easily.

> 
> FYI, I now have a DMA-based SPI driver that is fully functional in
> kernel mode, but will need one or two changes (and some testing!) to
> make it play nicely in non-kernel mode.  Probably best to leave that
> until the 3.0 release is done, though.

You can mainly test polled operation in the kernel just by temporarily
forcing the polled parameter to true.


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071

Re: STM32 - I/O pullup and EXTI issues, plus new SPI driver.

[Chris Holgate]

On Fri, 2008-11-21 at 15:52 +0000, Nick Garnett wrote:
> Chris Holgate <chris@zynaptic.com> writes:
> > 
> > 1) It's not possible to set pullups on I/Os using the provided
> > functions.  This is a trivial one-line fix to stm32-misc.c.
> > 
> > 2) External interrupts don't work as they stand.  This requires a few
> > changes to the STM32 var_intr.h.  If required I can tidy up my changes
> > there and provide a patch which I've tested using a single I/O
> > (EXTINT0), but which would probably benefit from a bit more testing
> > using other I/O configurations.
> 
> I can easily believe that both of these don't quite work. I didn't do
> much testing in this area, so any changes to make it work are appreciated.

OK - Simon has offered to review the changes, so I'll let him look them
over and once the copyright assignment is through you can decide what to
do with them.
 
> > FYI, I now have a DMA-based SPI driver that is fully functional in
> > kernel mode, but will need one or two changes (and some testing!) to
> > make it play nicely in non-kernel mode.  Probably best to leave that
> > until the 3.0 release is done, though.
> 
> You can mainly test polled operation in the kernel just by temporarily
> forcing the polled parameter to true.

Polled operation works, but I'm going to have to sprinkle a few
preprocessor directives in there to get rid of my calls to the kernel
flags API.  Is there any reason why flags support didn't make it into
the standard driver API?  I find that it's much more elegant than using
condition variables in a lot of cases.

Chris.

Re: STM32 - I/O pullup and EXTI issues, plus new SPI driver.

[Nick Garnett]

Chris Holgate <chris@zynaptic.com> writes:

> 
> Polled operation works, but I'm going to have to sprinkle a few
> preprocessor directives in there to get rid of my calls to the kernel
> flags API.  Is there any reason why flags support didn't make it into
> the standard driver API?  I find that it's much more elegant than using
> condition variables in a lot of cases.

The driver API is meant to be simple and reflect how drivers should
be used. Each driver is responsible for managing its own concurrency
so it needs to use mutexes anyway. When a thread in the driver must
wait for an interrupt it must release the mutex, a condition variable
provides exactly the necessary functionality.

Flags are too complicated to be used at driver level, and too prone to
errors and race conditions.

I suggest you take a look at the AT91 driver for an example of how an
SPI driver should work.


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071

Re: STM32 - I/O pullup and EXTI issues, plus new SPI driver.

[Chris Holgate]

On Fri, 2008-11-21 at 17:34 +0000, Nick Garnett wrote:
> Chris Holgate <chris@zynaptic.com> writes:
> 
> > 
> > Polled operation works, but I'm going to have to sprinkle a few
> > preprocessor directives in there to get rid of my calls to the kernel
> > flags API.  Is there any reason why flags support didn't make it into
> > the standard driver API?  I find that it's much more elegant than using
> > condition variables in a lot of cases.
> 
> The driver API is meant to be simple and reflect how drivers should
> be used. Each driver is responsible for managing its own concurrency
> so it needs to use mutexes anyway. When a thread in the driver must
> wait for an interrupt it must release the mutex, a condition variable
> provides exactly the necessary functionality.
> 
> Flags are too complicated to be used at driver level, and too prone to
> errors and race conditions.

Ok - I can see the point about keeping the driver API as simple as
possible, especially given that the flags functionality can easily be
emulated using the existing driver primitives.  Flags now expunged.

> I suggest you take a look at the AT91 driver for an example of how an
> SPI driver should work.

I think it's fair to say that there are already quite a few similarities
between the two drivers!

Chris.