| View previous topic :: View next topic |
| Author |
Message |
ninoq
Joined: 22 May 2013
Posts: 14
|
|
 |
ninoq
Joined: 22 May 2013
Posts: 14
|
|
 Posted: Sun May 26, 2013 1:18 am |
 |
|
According to the 16 bit mode documentation the demo code is run on an Arduino Pro which outputs 3.3V. As it wasn't clear in the 8 bit mode documentation which Arduino was being used I incorrectly assumed the display inputs were 5V tolerant.
I've now run the PIC at 3.3V but still got: ICID:9393.
Could I have bricked the display? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Sun May 26, 2013 1:43 am |
|
|
Try just delaying the strobes a fraction:
| Code: |
#define RD_STROBE { RD_ACTIVE; delay_cycles(2); RD_IDLE; }
#define WR_STROBE { WR_ACTIVE; delay_cycles(2); WR_IDLE; }
|
If you note the posted code was being run at 20Mhz, versus your 48Mhz. With fast_io selected, the line is updated only a couple of clocks apart. May well be too fast.
I's suspect it is not seeing the read strobe, so is returning the same byte.
Best Wishes |
|
|
ninoq
Joined: 22 May 2013
Posts: 14
|
|
| Posted: Sun May 26, 2013 2:23 am |
|
|
I've tried delaying the strobes by 2 cycles and more but I still get ICID: 9393 every time.
Any other ideas? |
|
|
MikeP
Joined: 07 Sep 2003
Posts: 49
|
|
| Posted: Sun May 26, 2013 11:43 am |
|
|
My full driver for my picUSBtoGLCD runs using
| Code: |
#fuses NOWDT,NOPROTECT,NOLVP,NODEBUG,VREGEN,PUT
#use delay(crystal=20M, clock=48M, USB_FULL)
|
What version of CCS C do you have?
I can put a known working version of a hex file for you that would put a B&W logo on the GLCD. It will do this with out the USB connected to the pic.
https://github.com/snowblind/picUSBtoGLCD
Click the zip button next to the clone in windows button. Inside that zip is a file called picUSBtoGLCD_ILI932X.hex try it. You will have to use PIN_A0 for RST_ACTIVE
The 18F4550 you are using doesn't like using any clock modes below 4.2V looking at the datasheet. It may work 100% or it may just sorta work sometimes.
Now outputting 5V to that GLCD display may have hosed it.
What do you plan to do with this? Will you want to use more then one?
Here is what I would do get you a 18LF4550 then get another one of the displays you used or keep useing the 18F4550 and get the one of the glcd I used from adafruit and skip the 3.3V problems. No sdcard on it.
If you get the afafruit one then get it working. Then you will have a known working base to switch to using the 18LF4550 and a cheaper 3.3V only displays. That was my plan once I get my new GLCD working like my old picUSBtoGLCD does for me now I will make a 3.3V version the runs working code and keep the afafruit one for working on new code.
My picUSBtoGLCD shows me CPU and GPU temps. GPU and CPU usages fan speeds, etc.
I like the one you showed us it has a place to put a SST flash chip on it I want to use one them for a full color logo and maybe some different fonts. I may order one once I pick the 3.3V pic I am gonna use. Maybe PIC18LF45K50. I wouldn't use this chip as my dev one I think it only has a 10k write endurance program memory.
I can think of anything else to try atm. |
|
|
ninoq
Joined: 22 May 2013
Posts: 14
|
|
| Posted: Sun May 26, 2013 2:17 pm |
|
|
| Quote: | | What version of CCS C do you have? |
I have: PCH C Compiler, Version 4.128, 64605.
| Quote: | | What do you plan to do with this? |
Use it in a garden rrigation system I'm developing.
| Quote: | | Will you want to use more then one? |
At this stage I'm just trying to understand how to program a GLCD.
Once I settle on a GLCD I can program, I may get more if there's a need for more control/display points.
If my GLCD is bricked, I'll probably order the iTEAD one you pointed out and a PIC18LF4550.
Thanks MikeP for all the help - much appreciated. |
|
|
ninoq
Joined: 22 May 2013
Posts: 14
|
|
| Posted: Sun May 26, 2013 2:58 pm |
|
|
Loaded your HEX file and got following output on terminal but nothing on the GLCD.
| Quote: | Rm[HpicUSBtoGLCD V0.11 PIC: 18F4550
PICCV: 4.140 COMPILE DATE/TIME: 23-May-13 01:42:31
Rm[HpicUSBtoGLCD V0.11 PIC: 18F4550
PICCV: 4.140 COMPILE DATE/TIME: 23-May-13 01:42:31 |
Does this suggest my GLCD is probably bricked? |
|
|
MikeP
Joined: 07 Sep 2003
Posts: 49
|
|
| Posted: Sun May 26, 2013 5:03 pm |
|
|
| Yes, That would be my guess if your wiring matches my defines I posted in the readid() test. |
|
|
drolleman
Joined: 03 Feb 2011
Posts: 116
|
|
| Posted: Sun May 26, 2013 6:44 pm |
|
|
| read back what you wrote to the registers after you init the device |
|
|
ninoq
Joined: 22 May 2013
Posts: 14
|
|
| Posted: Mon Jun 17, 2013 2:15 am |
|
|
After apparently "bricking" the display I purchased another from the same supplier. However despite ordering the same display as previously I received a different one. The display's pcb (unlike the first one's) had the pin functions silk screened on it - the pin functions didn't accord with the pinout diagram on the supplier's website - for example the flash bus pins where shown as NC. I queried the supplier who initially claimed that the display was not one of theirs despite the fact that their packing slip was enclosed with it. The supplier subsequently apologized and has sent a replacement free of charge.
I was able to read the display's ID which revealed the controller was a Samsung S6D1121. It seems the display is similar to:
http://www.elecfreaks.com/store/24-tft-lcd-tft0124-p-110.html
I've set up the display with PIC 18LF4550 running at 20Mhz - I've checked OSC2 with a logic sniffer and it's outputting 20 Mhz - my code includes:
| Code: |
#fuses NOWDT,NOPROTECT,NOLVP,NODEBUG,VREGEN,PUT, NOMCLR
#use delay(crystal=20M)
|
I'm using "fast io" and have PortD connected to the data bus.
Changing the screen's background takes about 2.5 minutes which at this stage rules out using the PIC 18LF4550 for my application. My code for changing the background boils down to writing 2*240*320bytes of color data to the display's GRAM using a for loop nested within another. Using the same or a similar PIC, are there quicker ways to change the background?
Is it quicker to directly tranfer data from an SD card or solid state memory to the display's GRAM?
Should I instead be using a different microcontroller? Any suggestions?
Any advice or guidance would be much appreciated. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Mon Jun 17, 2013 4:11 am |
|
|
Are you using fast_io, on the port operating the strobe port as well?. Could potentially make a noticeable difference here.
Now, a simple test using fast_io, and clocking 8bit data out as fast as the PIC can manage, just sending fixed bytes to give a colour background, gives a time of under 400mSec to clock out the data needed!...
I'd guess you are doing something to kill the innermost loop performance.
Remember:
1) arrays take a long time to access. To send the same data to repeated locations across the display, make sure the bytes are loaded into simple local variables first. I use 'hi_b', and 'lo_b'. Loaded these with the values wanted, and sent these to every location on the display.
2) Use the smallest counters you can. Row counter only needs an int8. column an int16.
3) Concentrate most on the thing called the most. Innermost part. I #defined the operations to clock a byte out, using no subroutines etc.. Even one extra uSec at the innermost level, corresponds to another 150mSec!....
Best Wishes |
|
|
ninoq
Joined: 22 May 2013
Posts: 14
|
|
| Posted: Mon Jun 17, 2013 6:45 am |
|
|
Thanks for the advice Ttelmah. I went back over my code with your advice in mind. I concentrated on the innermost loop and found the problem - there were 1 msec delays in the strobes which I forgot to remove when I came back to the project. Removing the delays drastically improves the screen refresh rate.
Thanks once again! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Mon Jun 17, 2013 7:16 am |
|
|
Yes, one of the delays being used when trying to get it working. Makes total sense.
Hopefully at least in the right 'order' now, to see reasonable responses. 
Perhaps worth realising, that you could switch to the 18F46J50, which is basically pin compatible with the 4550 (except has a lot more relocatable peripherals that can be enabled), and with the same crystal, go 2.4* faster, have twice the ROM, and nearly twice the RAM....
It is a genuine '3.3v chip' (core processor actually runs at a couple of volts), rather than a low voltage 'version' of a 5v chip.
Best Wishes |
|
|
ninoq
Joined: 22 May 2013
Posts: 14
|
|
| Posted: Mon Jun 17, 2013 3:59 pm |
|
|
| Thanks for the suggestion - will look into using a PIC18F46J50 instead. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
