Why does the Vybrid retain letter (A-E) port names that don't relate to actual IO ports

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

Why does the Vybrid retain letter (A-E) port names that don't relate to actual IO ports

Jump to solution
851 Views
markwatson
Contributor III

I am puzzled by the existence of Ports A-E when you can't actually do anything with them as ports.  It would be much clearer if the GPIO0 - GPIO4 where presented as the IO ports since they are the entities by which you can read and write data.  Am I missing some method to use the letter ports in a manner similar to the Kinetis?

Labels (5)
1 Solution
615 Views
naoumgitnik
Senior Contributor V

Dear Mark,

Most likely the reason for that is that this is how the internal processor blocks are arranged. It is more or less visible that these ports have groups of pins implementing specific functions, like JTAG, Ethernet, QuadSPI, etc. Naming them only as GPIOs with not show such information.

Regards, Naoum Gitnik.

View solution in original post

0 Kudos
3 Replies
616 Views
naoumgitnik
Senior Contributor V

Dear Mark,

Most likely the reason for that is that this is how the internal processor blocks are arranged. It is more or less visible that these ports have groups of pins implementing specific functions, like JTAG, Ethernet, QuadSPI, etc. Naming them only as GPIOs with not show such information.

Regards, Naoum Gitnik.

0 Kudos
615 Views
markwatson
Contributor III

Thank you Naoum.  I do understand the desire to group like pins together by function.  Unfortunately this has resulted in the letter ports being spread across the GPIO ports with sometimes odd offsets.


So code on the Kinetis that looks like this:

  // This corresponds to the "Index Write" or "Index Out"  timing:

  GPIOC_PDDR = 0X000FFFFF; 

  // Place data (index, cmd) on output lines

  GPIOC_PDOR = (0x0000FFFF & cmd);

Looks like this on the Vybrid:

  uint32_t Port3;

  uint32_t Command;

  // This corresponds to the "Index Write" or "Index Out"  timing:

  // Set data pins for output

  IOMUXC_PTE0 = 0X00000083;

  IOMUXC_PTE1 = 0X00000083;

  IOMUXC_PTE2 = 0X00000083;

  IOMUXC_PTE3 = 0X00000083;

  IOMUXC_PTE4 = 0X00000083;

  IOMUXC_PTE5 = 0X00000083;

  IOMUXC_PTE6 = 0X00000083;

  IOMUXC_PTE7 = 0X00000083;

  IOMUXC_PTE8 = 0X00000083;

  IOMUXC_PTE9 = 0X00000083;

  IOMUXC_PTE10 = 0X00000083;

  IOMUXC_PTE11 = 0X00000083;

  IOMUXC_PTE12 = 0X00000083;

  IOMUXC_PTE13 = 0X00000083;

  IOMUXC_PTE14 = 0X00000083;

  IOMUXC_PTE15 = 0X00000083;

  Port3 = GPIO3_PDIR;

  // Shift data for IO bits 9-24

  Command = (uint32_t)((0x01FFFE00) & (cmd << 9));

  Port3 = GPIO3_PDIR;

  // Mask out all but bits 9-24

  Port3 &= 0xFE0001FF;

  Command |= Port3;

  // Place data (index, cmd) on output lines

  GPIO3_PDOR = Command;

Am I missing an easier way to do this?

615 Views
naoumgitnik
Senior Contributor V

Dear Mark,

The point here is that every time we try to optimize pin names, i.e. signal names on the SoC level (we have tried that in the past), we bump into the fact that related signal names already existing inside the device on the block and sub-block levels start contradicting our desires, and, in order to prevent any possible hassles the IC designers may face, we have to agree to make their lives easier and all the others' more challenging :smileyhappy:... Nobody is perfect :smileyhappy:...

Regards, Naoum Gitnik.

0 Kudos