Setting the speed of GPIO ports on F10x

[Aslund]

Hello fellow Chibis

I finally working on an implementation of ChibiOS for a real, but small, test application.
One part involves switching a port from input to output and back regularly. Might sound strange but needed to communicate with an inhouse made chip.

Building up the application and using google I found the function "PAL_STM32_OSPEED_HIGHEST" but the compiler didnt recognise the definition.
Searching around the ChibiOS structure I found that there are two GPIO folders for PAL. One is a limited version for F10x but I dont understand it as the F10x chip should allow changing the slewrate of the port.
Why is it not a part of F10x?

Best regards
Sebastian Aslund

[Giovanni]

Hi,

I don't remember the F1 allowing for slew rate control, there is not a register for that in GPIO.

Giovanni

[Aslund]

Damn, then I must gotten something mixed up in the process.
Recalled that one of our senior developers talked about problems with the SPI due to too low slew rate. Must have been a different chip then.

Edit:
What about table 20 and 21 on page 161 in the reference manual?
http://www.st.com/web/en/resource/technical/document/reference_manual/CD00171190.pdf

Edit 2:
In section 9.2 on page 171 there is an option to set the output speed in the port configuration register.

[Giovanni]

Yes, I remember now.

The PAL driver does not allow to setup slew rate at runtime, it would require a change. You can setup slew rates in board.h however.

Giovanni

[Aslund]

Goodmorning Giovanni

Is this a limitation of the STM32F10x or the PAL driver?
If the STM32F10x support changing the a GPIO port to output at runtime and its slew rate I cant see why the PAL driver doesnt support it.

I am already using the board.h file but the system has to periodically change the input to output and vise versa.

[Giovanni]

It is a limitation in the PAL driver. Being GPIOv1 obsolete that driver has never been improved.

Giovanni

[Aslund]

Any easy way to switch to GPIOv2 or would that also pose some problems?

Alternatively I could just update the GPIOv1 with the defines I need.

[Giovanni]

GPIOv2 is not just a different driver, newer STM32s have an entirely different GPIO organization that fixes some of the limitations present on F1 devices.

Adding more "modes" to the GPIOv1 driver should be very simple, there is a single function to modify in pal_lld.c, it contains a table with some reserved entries, you just need to associate those entries to the new modes.

BTW, for new designs I would consider newer devices, the F3 is meant to be the F1 replacement and includes a lot of improvements, not just GPIO.

Giovanni

[Aslund]

Hello Giovanni

That STM32F3 looks very promising. The DSP instructions are a very nice addition to STM32 family.
I can also find various papers saying the F3 has a new design on various components but I cant find any details on exactly what the differences are.

Do you know any resources explaining the differences in between the F1 and F3 regarding the GPIO, SPI etc?

[Giovanni]

I can make a list quickly:

- Improved core with FPU and DSP.
- New I2C (this one works correctly, the old one was "quirky").
- New SPI with FIFOs and variable frame length.
- New GPIO incorporanting AFIO allow multiple remapping (remapping on F1 was very buggy, see all the erratas).
- Improved USARTs, old one were very critical in ISRs, it was easy to have race conditions because how flags were handled.
- MUCH improved ADCs.
- Added DACs.
- Added analog comparators and programmable OPs.

In general it is the logical successor to the F103 with all small issues addressed, it is also very well equipped on the analog side.

Giovanni