Pins tool: change pin function during runtime

[danielholala]

Hello everybody,

I'm developing firmware for a custom LPC55xx based board.

Using Pins Tool, I've configured Flexcomm3 to communicate via SPI interface with several slaves (SSEL0 - SSEL2).

Now to reset the SPI slaves, I've to pull all SPI signals to LOW (aka. GND). Otherwise, they are powered from the SPI signals (due to internal diodes that connect SPI signals to VCC) and cannot be reset.

Therefore, I'd need to provide a second configuration set for the device pins that I switch to during runtime. The second configuration set would define all pins used in the first configuration set as GPIOs with default to LOW.

How do I configure this using Pins tool?

Thanks.

Best regards,
Dan

[ErichStyger · Accepted solution]

The tool has the concept of 'functional groups':

Basically you can group your pins or 'functionalities' into such a group, and configure with the settings (buttons on the right) if the configuration is called during startup from main or not. So you can create to groups, for example 'useAsSPI' and 'useAsGPIO'. 'useAsSPI would be called by default, and 'useAsGPIO' would be something called at runtime.

I'm doing this kind of things for example with the I2C bus, where for a bus reset you have to use the pins in GPIO mode too. One thing you might consider is taking the code generated and use it native in your application, especially if you need to do other 'special' things.

I hope this helps,

Erich

[danielholala]

Hi Erich,

Thanks, your note regarding "functional groups" was very helpful. I tried it immediately and it worked. I can now switch the SPI pins to GPIO (and back to SPI) during runtime. Great.

What do you mean by "taking the code generated and use it native in your application"?

Bye
Dan

[joeatrainamp]

Glad you solved the problem.  A sample code snippet would be great.

[ErichStyger]

I mean let the tool generate the code, then copy it into my application code so I have full control over it. After that I delete the settings of the config tool.

The reasons are that I can much easier keep things in a version control system, and I had issues in the past with new config tool versions changing the code, or causing side effects. Having it 'native' in the application code let me keep in control for it. Plus I can keep the same code/module for many different MCUs supported.

If you want to see how this looks, see the code in https://github.com/ErichStyger/McuOnEclipseLibrary/blob/master/lib/src/McuShellUart.c which does the UART muxing and configuration, based on the config tools. BTW, this allows to use MCUs from different vendors too, as you see in above example.

I hope this helps.