chipKit UNO32 & mcufriend

[domTheQuaker]

Hello David, I've download the uno32 version, here is the repport with the chipkit : reg(0x0000) 00 00 ID: ILI9320, ILI9325, ILI9335, ... reg(0x0004) 00 00 00 00 Manufacturer ID reg(0x0009) 00 00 00 00 00 Status Register reg(0x000A) 00 00 Get Power Mode reg(0x000C) 00 00 Get Pixel Format reg(0x0061) 00 00 RDID1 HX8347-G reg(0x0062) 00 00 RDID2 HX8347-G reg(0x0063) 00 00 RDID3 HX8347-G reg(0x0064) 00 00 RDID1 HX8347-A reg(0x0065) 00 00 RDID2 HX8347-A reg(0x0066) 00 00 RDID3 HX8347-A reg(0x0067) 00 00 RDID Himax HX8347-A reg(0x0070) 00 00 Panel Himax HX8347-A reg(0x00A1) 00 00 00 00 00 RD_DDB SSD1963 reg(0x00B0) 00 00 RGB Interface Signal Control reg(0x00B4) 00 00 Inversion Control reg(0x00B6) 02 02 02 3B 00 Display Control reg(0x00B7) 06 06 Entry Mode Set reg(0x00BF) FF FF 68 14 00 FF ILI9481, HX8357-B reg(0x00C0) 00 00 00 00 00 00 00 00 00 Panel Control reg(0x00C8) 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA reg(0x00CC) 66 66 Panel Control reg(0x00D0) 00 00 00 Power Control reg(0x00D2) 00 00 00 00 00 NVM Read reg(0x00D3) 00 00 00 00 ILI9341, ILI9488 reg(0x00D4) 00 00 00 00 Novatek ID reg(0x00DA) 00 00 RDID1 reg(0x00DB) 00 00 RDID2 reg(0x00DC) 00 00 RDID3 reg(0x00E0) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA-P reg(0x00E1) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA-N reg(0x00EF) 00 00 00 00 00 00 ILI9327 reg(0x00F2) 00 00 00 00 00 00 00 00 00 00 00 00 Adjust Control 2 reg(0x00F6) 00 00 00 00 Interface Control

[domTheQuaker]

here is the mega's one (a bit different ! o_O ) Read Registers on MCUFRIEND UNO shield controllers either read as single 16-bit e.g. the ID is at readReg(0) or as a sequence of 8-bit values in special locations (first is dummy)

reg(0x0000) 00 00 ID: ILI9320, ILI9325, ILI9335, ... reg(0x0004) 54 54 80 66 Manufacturer ID reg(0x0009) 00 00 61 00 00 Status Register reg(0x000A) 08 08 Get Power Mode reg(0x000C) 66 66 Get Pixel Format reg(0x0061) 00 00 RDID1 HX8347-G reg(0x0062) 00 00 RDID2 HX8347-G reg(0x0063) 00 00 RDID3 HX8347-G reg(0x0064) 00 00 RDID1 HX8347-A reg(0x0065) 00 00 RDID2 HX8347-A reg(0x0066) 00 00 RDID3 HX8347-A reg(0x0067) 00 00 RDID Himax HX8347-A reg(0x0070) 00 00 Panel Himax HX8347-A reg(0x00A1) 00 00 00 00 00 RD_DDB SSD1963 reg(0x00B0) 00 00 RGB Interface Signal Control reg(0x00B4) 00 00 Inversion Control reg(0x00B6) 02 02 02 3B 00 Display Control reg(0x00B7) 06 06 Entry Mode Set reg(0x00BF) FF FF 68 14 00 FF ILI9481, HX8357-B reg(0x00C0) 0E 0E 0E 00 00 00 00 00 00 Panel Control reg(0x00C8) 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA reg(0x00CC) 00 00 Panel Control reg(0x00D0) 00 00 00 Power Control reg(0x00D2) 00 00 00 00 00 NVM Read reg(0x00D3) 00 00 94 86 ILI9341, ILI9488 reg(0x00D4) 00 00 00 00 Novatek ID reg(0x00DA) 54 54 RDID1 reg(0x00DB) 80 80 RDID2 reg(0x00DC) 66 66 RDID3 reg(0x00E0) 00 00 54 07 44 05 08 00 54 07 44 05 08 44 44 00 GAMMA-P reg(0x00E1) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA-N reg(0x00EF) 00 00 00 00 00 00 ILI9327 reg(0x00F2) 00 00 00 00 00 00 00 00 00 00 00 00 Adjust Control 2 reg(0x00F6) 00 00 00 00 Interface Control

[prenticedavid]

I would expect the readreg sketch to be identical on Chipkit and on Mega. It only uses pinMode() and digitalWrite() calls. It does not need any libraries.

Looking at the PIC32 datasheet, there is a ADxPCFG register. (search PDF for "PCFG") It is possible that the Arduino code does not set the pins correctly with pinMode(). And perhaps the library should set the ADPCFG bits for the control pins in PIN_OUTPUT().

Likewise, the PIC32 has SET and CLR registers. These would be faster than manipulating the LATx register with |= and &=~ However, the operation should be the same.

I can only suggest that you experiment with ADPCFG. It is important that the readreg sketch works correctly before you attempt the library.

You could experiment with the SET and CLR registers e.g.

#define PASTE(x, y) x ## y
#define PIN_LOW(port, pin) PASTE(port, CLR) = (1<<(pin))
#define PIN_HIGH(port, pin) PASTE(port, SET) = (1<<(pin))

This is becoming painful. Life is easier for me when I have the target on my desk. Googling "Arduino Uno32" does not create many recent hits. I suspect that this was never a popular product.

David.

[domTheQuaker]

Unfortunately, i have already tested AD1PCFG, it is not better :( I will try with SET/CLR I understand that it is paintfull, i will continue, and if it works i will tell you here! Thanks again for all ;) Dominique

[prenticedavid]

I am a little suspicious of

reg(0x00B6) 02 02 02 3B 00 Display Control
reg(0x00B7) 06 06 Entry Mode Set
reg(0x00BF) FF FF 68 14 00 FF ILI9481, HX8357-B

being the only registers that agree. I would see if some data bits are "stuck". i.e. by un-commenting the for (reg = 0; reg < 255 statement. And seeing whether the 0xBF report appears for any other reg values.

I did a swift Google. There are no cheap Uno32 boards available. So I am not going to buy a board. And I suspect you are the only active Uno32 owner in the world.

David.

[domTheQuaker]

I tried to disable pull-up resistors (but i am not sure there some... )

Oh please don't try to buy a one, you have already done a lot for me ! i want to use that board because it is in my stock, but if no one else use it, i will give up... i will buy an uno (the mega is not suitable because i want to use the sd card port to ) (i will try again others things before give up, just for fun ! but i do not want that your waste your time anymore, thanks again for all the time you spent ! )

I suspect you are the only active Uno32 owner in the world.

LOL :) i am sorry about that :p

here is the response, i deleted the lines where there are only '00' reg(0x0044) 54 54 80 66 00 00 00 f.k reg(0x0049) 00 00 61 00 00 00 00 f.k reg(0x004A) 08 08 08 08 08 08 08 f.k reg(0x004C) 66 66 66 66 66 66 66 f.k reg(0x006A) 00 00 00 01 3F 00 00 f.k reg(0x006B) 00 00 00 01 DF 00 00 f.k reg(0x006E) 80 B8 E8 74 4C C0 20 f.k reg(0x0070) 00 00 00 01 DF 00 00 f.k reg(0x0073) 00 00 00 01 E0 00 00 f.k reg(0x007A) 66 66 66 66 66 66 66 f.k reg(0x007E) 28 B8 E8 74 B8 E8 74 f.k reg(0x00B1) B0 B0 11 00 00 00 00 f.k reg(0x00B2) 00 00 11 00 00 00 00 f.k reg(0x00B3) 00 00 11 00 00 00 00 f.k reg(0x00B5) 02 02 02 0A 04 00 00 f.k reg(0x00B6) 02 02 02 3B 00 00 00 f.k reg(0x00B7) 06 06 06 06 06 06 06 f.k reg(0x00BF) FF FF 68 14 00 FF 00 f.k reg(0x00C4) 54 54 80 66 00 00 00 f.k reg(0x00C9) 00 00 61 00 00 00 00 f.k reg(0x00CA) 08 08 08 08 08 08 08 f.k reg(0x00CC) 66 66 66 66 66 66 66 f.k reg(0x00EA) 00 00 00 01 3F 00 00 f.k reg(0x00EB) 00 00 00 01 DF 00 00 f.k reg(0x00EE) 20 B8 E8 74 4C C0 20 f.k reg(0x00F0) 00 00 00 01 DF 00 00 f.k reg(0x00F3) 00 00 00 01 E0 00 00 f.k reg(0x00FA) 66 66 66 66 66 66 66 f.k reg(0x00FE) 28 B8 E8 74 B8 E8 74 f.k

[domTheQuaker]

I think you are right about stuck bit, because there are very stange things between that version and the mega's one ! maybe 1 or 2 bits to configure correctly or disfunctionning... I am trying to be sure that PWM is disabled (OCxCON reg)

[prenticedavid]

reg(04) should be 54 54 80 66 00 00 00

but you don't get reg(04) but reg(0x44) , reg(0xC4) give this report instead. likewise, what I would expect for reg(0x09), reg(0x0A), reg(0x0C) appears at 4x and Cx instead. 0x2A is shown at 6A, EA 0x2B is shown at 6B, EB 0x30 is shown at 70, F0 ...

Which means stuck bits or that the pin documentation is wrong. I downloaded the Uno32 PDF which agrees with your mapping. It looks like D5 (PD1) is misbehaving. e.g. if it is Open-Drain.

You can just put an active-high LED on D5 pin and test digitalWrite() An active-low LED will work with Open-Drain or Push-Pull. (active-low means anode=VCC, cathode=D5)

Note that you can use LATDINV register to invert a pin. Is there a PORTDINV register?

David.

[prenticedavid]

I am looking at PDF

chiipKIIT™ Uno32™ Board Reference Manuall Revision: July 17, 2012 Note: This document applies to REV C of the board.

Is your board rev C ?

Note that LCD_D6 and LCD_D7 are generally shared with XP, YM from the Touch Panel. Which can cause D6, D7 to read wrong. VERY unlikely to write wrong from a Push-Pull driver. Obviously risky with an Open-Drain driver.

I am intrigued by this problem. I would like to solve it. As you have noticed, the whole library is independent of Target chip or architecture. It just needs write_8(), read_8(), setWriteDir() for the target.

David.

[domTheQuaker]

My board is a rev B and i can not find the rev b Manuel... I tried to light an 8 led line + low active led that i move where i need to see, and all works fine :/ There is a PORTDINV reg but i do not think it changes something, what i understood is that reading is on PORT and writing on LAT, but maybe you right, i wil try somthing

[prenticedavid]

It reads reg(0xBF) correctly i.e. bits are not inverted. so PORTxINV is 0 If it writes D5 "inverted" then it would not return correct values for reg(0xBF)

[domTheQuaker]

I tried to init many registers: (port inverters (PORT & LAT) OCxXX (PWM registers) Pull up resistors registers, Open drain ... :/ nothing went better. i agree with you, some bits seem misfunctionning but it does not seem to be the same one at different times :/ tomorow -> i will try to go to work, and get my scope. There is a 8 bits logic analyzer integrated, and i will have better point of view (it is a 40€ board, but i do not like when something does not work :p )

[prenticedavid]

I have an 8x1 active-low LED and an 8x1 active-high LED. So it is easy to test the Arduino Digital pins and the Arduino Analog pins with a rotate sketch. This verifies any Protoshield Adapter that I make.

And verifies the specific variant board in any Core Release. The initial Nano-Every was wrong. Zero clones might be M0 clones...

Of course you can wire up scopes, logic analysers etc. But my simple stack of 8 LEDs that can plug into Arduino headers works well.

I suggest that you verify the REV C pin-mapping with digitalWrite() And see whether direct LATDINV or ODCD calls are overwritten by digitalWrite(). Likewise, if you can write inverted but read non-inverted. i.e. LATDINV vs PORTDINV

Arduino init() functionis called before setup(). It configures PWM, ADC , Timers, ... As a general rule, a subsequent pinMode() will revert a pin to GPIO mode. But chipKit Core might not behave the same way.

David.

[domTheQuaker]

I have a 8x1 active-high easily changeable in active low (it is on a test-lab) , i have added some delays in the sketch to see what happens, and... all is ok :/ but i would like to use the scope to test with the screen plugged in . Maybe i will see differents things :/ Ok, i'll test if LATDINV and ODCD are overwritten :) let's go!

[domTheQuaker]

I've made a few tests with scope, I wrote a small sketch which counts from 0 to 255 : lcdSetWriteDir(); for (uint16_t i = 0; i<256;i++){ lcdWrite8(i); delayMicroseconds(10); }

All goes very well (as expected) And when i put that code: for (uint16_t i = 0; i<256;i++){ lcdSetReadDir(); lcdSetWriteDir(); lcdWrite8(i); delayMicroseconds(10); }

we got that result : (!!)

Sometimes, the value which must be writen is not, here the right one was F6h and not 00h We can see stange small signals changes .. I will try again with a small delay bitween dir change.

[domTheQuaker]

IT seems that all works fine from 00 to 0x49, the 0x4A does not work, only very shorts pulse until the counter reach 0xF8... i do not understand, all bits seem affected. And when it comes back to normal function, all bots are active at same time: it is not the program...

[prenticedavid]

I have not studied the datasheet. It is quite possible that the Port "steering" registers require some timing constraints. I would expect the LATxSET and LATxCLR to work very fast. But a Read-Modify-Write sequence may be less happy.

Likewise, ODCx and TRISx may require some time. Are there TRISxCLR and TRISxSET registers? (I call these write-only registers "steering registers")

I would expect any Arduino Core to cope with this sort of issue in pinMode() and digitalWrite() It is MY error in the Shield macros. I can re-write the macros for SET and CLR. e.g. like the ARM and XMEGA.

David.

[domTheQuaker]

i had a look to the whole counting, and the counting always stops at value 0x48, i've added some different delays, and it always stops at that value. it cames back at different moment, depending the delays... it seems there is about 5.5ms "blocking" but it may be not very significant... I tried modify the macro to use LATxCLR en LATxSET, maybe i made a mistake, but i can not get the 0x6814 tft ref, i get 0xd2d2 ...
But i agree that LATx and its registers would work very fast. For TRIS, the delay i had to TRISx had no effect Dominique

[domTheQuaker]

I just tried another test, i kept that loop, but it starts at 0x50: No problem anymore ! ??? It works correctly ...

[domTheQuaker]

It seems that the problem is not specfic to 0x48 but with bit D6 because, when D6 must change DIR, the value is still at value 1 ... I commented the line 'digitalWrite(LCD_D6, ... )' in normal counting and it works fine :/ On the screenshot, (0x40 to 0x4F was disabled in the sketch) we can see that when TRISx is in read mode, that the value 0x40 still there, is this the touch screen ?

[domTheQuaker]

I kept the same sketch, but without the screen, all is ok ... it seems that i will have to put the ChipKit in a box... it seems it is not compatible with that screen :(

[domTheQuaker]

You were right about the touch screen ... i unsoldered it... (i had to cut the double sided tape) it is fine, the screen works... ! the macros are just fine, don't need to init other regs. i do not have the schematics of that screen, do you know where i can find them? Thank you very much for your precious help !!!

[prenticedavid]

There is something wrong. Even wimpy ARM push-pull drivers can work with the shared Touch pins. But at least you have got the TFT working.

I have posted SET, CLR versions of the macros on GitHub. They should work faster than the Read-Modify-Write macros.

Please run graphictest_kbv.ino Check that every graphic, colour, direction is 100% correct. Then adjust the WRITE_DELAY macro until you start to get glitches in graphics. Make a note of the Total Time reported in the Adafruit Tests screen.

Measure the Touch Panel resistances on your disconnected ribbon. I would expect about 300R and 500R. Buy some double-sided foam tape for securing the screen. Never pull the screen apart. Use an Xacto knife to cut through the foam. Replace with fresh foam tape.

David.

[domTheQuaker]

here is the macro code, with no delays, I suppressed all delays (WR_DELAY and IDLE_DELAY) There was no glitch et works fine. SET/CLR version is much more efficient, the time was 9.5s before, and then passed to 2.28 secs. The nodelay version gives 1.97 secs. Still no glitch. I will measure the touch screen tomorrow :)

`#define setReadDir() { TRISF |= FMASK; TRISD |= DMASK; }

define setWriteDir() { TRISF &= ~FMASK; TRISD &= ~DMASK; }

define WRITE_DELAY { WR_ACTIVE; } //80MHz M4 needs 2, 5, 0

define READ_DELAY { RD_ACTIVE4; } //

define IDLE_DELAY { WR_IDLE; } //

// delay2: 2.44, delay: 2.28, no delay: 2.11, no_idle: 1.97

define write8(x) { write_8(x); WR_STROBE; }

define write16(x) { uint8_t h = (x)>>8, l = x; write8(h); write8(l); }

define READ_8(dst) { RD_STROBE; READ_DELAY; dst = read_8(); RD_IDLE2; }

define READ_16(dst) { uint8_t hi; READ_8(hi); READ_8(dst); dst |= (hi << 8); }

define PASTE(x, y) x ## y

//CLR SET version : 9.5s -> 2.28s !

define PIN_LOW(port, pin) PASTE(port, CLR) = (1<<(pin))

define PIN_HIGH(port, pin) PASTE(port, SET) = (1<<(pin))

define PIN_OUTPUT(p, b) { ODCB &= ~(1<<(b)); TRISB &= ~(1<<(b)); } //if all ctl on LATB

`

[prenticedavid]

Please only alter

#define WRITE_DELAY   {  }   //80MHz PIC32 needs 0, 4, 0
#define READ_DELAY    { RD_ACTIVE4; }   //
#define IDLE_DELAY    {  }      //

do not touch the other macros. You can try changing READ_DELAY. Force tft.begin(0x6814); Observe the ID reported on Adafruit Tests screen. Observe the Software Scroll for glitches.

I am impressed by 2.28s for a 320x480 screen. PIC32 must have a barrel shifter. There are still a lot of shifts in the write_8() macro. 1.5s is probably the fastest that the controller could do (if the data bus was on consecutive port pins)

David.

[domTheQuaker]

Ok for macros :) Here is what i tested : WRITE_DELAY :2 -> 2.44; 1 -> 2.28 ; 0-> 2.11 ; no_idle: 1.97 READ_DELAY : 4 -> 1.97 ; 3-> 1.96 ; 2 -> 1.97 + Software Scroll does not appear! So i kept the READ_DELAY at 3

define setReadDir() { TRISF |= FMASK; TRISD |= DMASK; }

define setWriteDir() { TRISF &= ~FMASK; TRISD &= ~DMASK; }

define WRITE_DELAY { } //80MHz M4 needs 0, 4, 0

define READ_DELAY { RD_ACTIVE2; RD_ACTIVE; } //

define IDLE_DELAY { } //

define write8(x) { write_8(x); WRITE_DELAY; WR_STROBE; IDLE_DELAY;}

define write16(x) { uint8_t h = (x)>>8, l = x; write8(h); write8(l); }

define READ_8(dst) { RD_STROBE; READ_DELAY; dst = read_8(); RD_IDLE2; }

define READ_16(dst) { uint8_t hi; READ_8(hi); READ_8(dst); dst |= (hi << 8); }

Yes it seems that shifters are efficients! do you need i do some others tests?

[prenticedavid]

Thanks for the feedback. I will settle on 0, 4, 0 to be on the safe side. 1.97s is a healthy result for writing the graphics. The read time is never measured. But 4 should give a reasonable performance.

If you ever get hold of another Mcufriend display, you can see whether those Touch pins are a problem.

I have just received a letter from Boris through my Front Door. Has President Macron written a letter to you?

David.

[domTheQuaker]

Thanks a lot again for your help, Maybe i will get another one mcufriend display, but i don't know if it will come from china soon :( President Macron did not write to me :/ , but it seems that Boris does not look in great shape :/ Dominique