microbuilder / LPC11U_LPC13U_CodeBase

Open source code base for ARM Cortex M3 LPC1347 or Cortex M0 LPC11U37/LPC11U24 MCUs
Other
55 stars 38 forks source link

Status of HX8347 driver #18

Closed tummychow closed 10 years ago

tummychow commented 10 years ago

I'm curious about the situation of the HX8347 driver. I'm working on an ILI9325 version of the driver, and I don't have an HX8347 to test the original driver against. However, I know that my driver, in its current state, does not work. You can see it here. It's mostly derived from the LPC1343 codebase.

However, the GPIO block of the LPC1347 is different, so I'm not sure about all the low level routines. I'm particularly interested in the comments seen in this function. Looks like the driver can set bits of the command/data, but it's not clearing them, right?

I personally suspect a similar issue applies to the ILI9325 driver I'm working on. My plan is to use the GPIO masking features to set the data port instead, something along these lines. For example, if it was the HX8347 driver, it might look like this:

// set data pin mask bits to zero so that the mask allows them to be manipulated
LPC_GPIO->MASK[HX8347_DATA_PORT] = ~HX8347_DATA_MASK;

// write directly to masked register - only pins with a mask of zero will be affected
LPC_GPIO->MPIN[HX8347_DATA_PORT] = (command & 0xFF) << HX8347_DATA_OFFSET;

I'm still testing this (I have code but it's not ready), and I'm just looking for thoughts or advice so I know where to direct my testing efforts, or what you think I should try. Any past experiences with the HX8347 driver seen in this codebase would be appreciated.

tummychow commented 10 years ago

Okay, I hacked at it some more and pushed up a few commits demonstrating what I had in mind, notably this. The driver now uses 16-bit commands and 16-bit data, and it's using the GPIO masking functionality (but I don't know if I'm using it correctly).

My driver still doesn't work, so I'm gonna have to sit and think about it a little more. It's still structurally similar to the hx8347 driver, thoughts and suggestions welcome.

tummychow commented 10 years ago

Hahaha, there was a silly typo in the header macros for setting/clearing reset and backlight pins (see commit 38ab0d3). Fixing that typo caused the init sequence to behave a bit better. I'm still working on it, but at least I'm making progress!

I wasted several commits fixing other things before noticing this mistake so now I feel pretty dumb, but I'm glad I'm getting there.

tummychow commented 10 years ago

It works! I have colors! I'm going to spend some time cleaning up the driver, hopefully submit a PR.

As I mentioned earlier, it is using the GPIO masking feature, so there are some definite design flaws if other applications touch the mask register (ie in an interrupt). For my application that won't be a problem, but I am open to suggestions if that's a concern. Once I get my code together I'll open a proper PR to discuss it. I guess that's all for this issue, sequel coming soon!