KL25Z PORTC manipulation

[tomasmickus]

I bit banged PORTs on FRDM-KL25Z using FGPIO and GPIO commands.

Frequency measured on pins with GPIOC_PDOR = 4MHz, with FGPIO = 6MHz. ( MCU core 24MHZ, peripheral 24MHz)

Nice. I found that PORTC have 16 pins, so i can use entire 16 pins at once, at 6MHz, that very usefull for LCD TFT 16 bit data application !!!

BUT. PORTC sequence is not in series, PTB[0~13,16,17], so every time i push binary RGB565 color code in port i need to do:

#define LCD_color(a) FGPIOC_PDOR = ((a & 0xC000)<<2) | (a & 0x3FFF) (equation 1 )

AND. Frequency dropped from 6MHz to 4MHz (due to math operation for shifting i think). When LCD has 76800 pixels and i need to redraw it all it means a delay 76800*0.5us=38.4ms.

QUESTION. Is there a more effective way to do shiffting than equation 1.

[Kan_Li]

Hi Tomas,

Actually I couldn't agree more with Mark's solution, and as a supplement, I think maybe you can use FGPIO_PTOR as the input, you may XOR the data with the previous one to determine which bit/pin is going to be changed, and input the result to PTOR register, so that would allow there can be some pin of this port used for some purpose other than RGB565.

Hope that helps,

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mjbcswitzerland · Accepted solution]

Tomas

Change the RGB565 macro and then the shift will be done at compile time and not at run time.

Eg. if the macro is presently something like:

#define RGB565(r, g, b)  (((r & 0x1f) << 11) | ((g & 0x3f) << 5) | (b & 0x1f))

#define RED RGB565(31, 0, 0)

#define GREEN RGB565(0, 63, 0)

#define BLUE RGB565(0, 0, 31)

it can be changed to

#define RGB565(r, g, b)  (((r & 0x18) << 13) | ((r & 0x07) << 11) | ((g & 0x3f) << 5) | (b & 0x1f))

RED, GREEN and BLUE etc. remain the same

If using images, the image pixels will need to be saved using the macro manipulation but they can then be written directly without any need for bit shifting.

Note that the unused bits of the port can't be used for other outputs since that would also require masking, and associated overhead.

Regards

Mark