GPIO Madness??

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

GPIO Madness??

Jump to solution
1,212 Views
mjbcswitzerland
Specialist V

Hi All

I have only recently started working with the Vybrid-F and am having sleepless nights about how best to handle GPIOs.

There are IOMUXC registers, PORTx and GPIOx registers that all match up perfectly (each bit in the GPIO registers corresponds to each register in the correct order in the port controls).

But then there are the port pins themselves that are seeminly randomly mapped to these controls:

- eg. PTD31 needs to be controlled in GPIO1 by bit 0x80000000

but PTD30 needs to be controlled in GPIO2 by bit 0x00000001

- PTA6 is controlled in GPIO0 by bit 0x00000001

but PTA7 is controlled in GPIO4 by bit 0x00000040

I would usually expect to be able to write to (say) PTA and change multiple bits at the same time using a single write but this is obviously not possible since writes to different registers are involved and also a complete pin to bit remapping is required as well. Generally the HAL interface which is normally trivial and efficient needs to use a complicated algorithm with look-ups and remapping with no obvious reasons for why it was chosen to be like this.

Why aren't the pins simply named as PTA0, PTA1, PTA0 being GPIO0 bits 0x00000001, 0x00000002, 0x00000004 and then the GPIO registers could also be named GPIOA as is the case on the Kinetis parts and pretty much any other proessor?

In fact, if the ports pins were just renamed it seems it would solve many hours of unnecessary SW development and debugging time (due to simple mistakes resulting from the present naming strategy).

My question is whether there is some reason for the GPIO pin naming which gives is some meaning or whether it is just a documentation convention to give some seemingly backward compatibility to older parts (similar to the 8 bit naming convention in the Kinetis-KE range, although they are actually 32 bit ports, which also results in misleading and overcomplicated SW solutions which would otherwise be completely trivial) ?

At the moment I am also seriously considering creating a new part pinout and mux table where the GPIO pin names are renamed and then used for real work because it may in fact be a better solution for real software developments.

Any comments?

Regards

Mark

Kinetis: µTasker Kinetis support

Labels (1)
0 Kudos
1 Solution
900 Views
CommunityBot
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

View solution in original post

0 Kudos
5 Replies
901 Views
CommunityBot
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!
0 Kudos
901 Views
timesyssupport
Senior Contributor II

Hello Mark,

While Timesys provides support for the Freescale Vybrid, design decisions such as these were not our doing. karinavalencia​ is the Freescale Vybrid team able to comment on why these naming conventions are used?

Thank you,

Timesys Support

0 Kudos
901 Views
karina_valencia
NXP Apps Support
NXP Apps Support

cyborgnegotiator​ can you comment please?

0 Kudos
901 Views
karina_valencia
NXP Apps Support
NXP Apps Support

alejandrolozano​ are you able to help here?

0 Kudos
901 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi Mark,

I do not know the reason of the naming conventions used in the Vybrid RM. But as you can see in table RGPIO versus Pins (continued)

Each RGPIO is continuous in memory corresponding to a direct iomux register. Which from the SW perspective it should be easy to handle. The hard part would be to match the pad name to the RGPIO.

Best Regards,

Alejandro