This is getting very complicated. I'm still wondering about a hardware issue esp with respect to capacitors on the board, and a photo certainly would help.
Data on this is hard to find.
I see this on the website
ITDB02 is work at 3.3v DC, if you need to connect the module with the 5v voltage I/O , you need to add the 30k and 20k resistors to reduce voltage.
Sure the display itself runs on 3V but what do you connect up. 3V or 5V. Two supply pins. On board regulator which looks like it does the SD card but who knows about the display.
We need a schematic. I unzipped the .rar file and there are .pdfs but the one file we need is a .sch format. Who knows what format. Maybe Eagle?
I GOT IT!! I switched the resistor from R2 to R1 to switch to 16 bit mode. Once that was finished, I hooked it up and changed the code back to my second testing code post with the 10px block display code. Powered it up and about 3 seconds later a pretty white square showed up on the screen
I thought you already had tried 16 bit mode? What was different?
Have a play with this code and see if you can get some text on the screen. Add curx and cury in the VAR section. If you can get text you can then print numbers and that is useful for debugging other code.
PUB Propfont ' use propeller font in the rom for bootup messages when debugging sd cards
curx := 0 ' set cursor to top left of screen (common variable)
cury := 0
Propfont_string(string("Hello World")) ' string to send
PUB Propfont_string(stringptr) 'print at curx,cury
repeat strsize(stringptr)
ILI9325.draw(curx,cury,curx+15,cury+31) ' location to start drawing
Propfont_out(byte[stringptr++])
curx +=16
curx := 0
cury += 32 ' new line at end of string
PUB Propfont_out(ascii) | address,pixels
address := $8000 + (ascii >> 1) << 7 ' get rom address
repeat 32 ' 32 rows per character, split in two parts
pixels := long[address] ' get rom font data
pixels := pixels >> (ascii & 1) ' shift for odd characters
repeat 16 ' 16 columns
if pixels & 1
ILI9325.pixel(%00000111_11100000) ' foreground color RRRRRGGG_GGGBBBBB
else
ILI9325.pixel(%00000000_00000000) ' background color
pixels := pixels >> 2 ' alternate pixels interleaved so shift 2
address += 4 'increment address by 4 bytes
Yep, did that a minute ago and I have Green letters on a black background It was a little slow printing those letters out, but I guess since this is in Spin, it will be slow like that? It took about 1.5 seconds from start to finish. If I plan to update RPM on screen in real time, I will probably need it faster than that.
I tried with expressSCH and ExpressPCB with no luck. If I open it in notepad, this is the first line : "DProtel for Windows - Schematic Capture Binary File Version 1.2 - 2.0t" Not sure if the D on the beginning or the t on the end have anything meaning.
Out of curiosity, can ASM be mixed with spin or does ASM have to be all in one area? Basically, can I convert a function to ASM but leave the PUB there? Hope that makes sense. I have been reading about ASM, but still have quite a ways to go! Since it is faster, I would prefer to use that if I can understand it.
It seems to me that it needs to be split into 2 different parts?
Sorry, my mistake. Yes, that was from my code, but I think you worked it out. Split into two bytes. RRRRRGGG then GGGBBBBB
Try some different colors. White on blue looks good.
And yes there is word wrap. If it gets to the bottom of the screen I had a routine to clear the screen and start at the top. A better text driver has a buffer to store all the characters so you can do scrolling.
Clearscreen is a bit slow in spin. Much faster in asm.
Asm runs in a cog and you have 7 cogs free (spin takes one) so once you load up a cog, you may as well fill it with 2k worth of code. So it often makes sense to put lots of routines in a cog and pass instructions to tell the cog which one to run. Things like 'clearscreen' and 'draw character'. We probably should put the ".draw" routine in asm.
I tend to write things in spin first, then move them over to asm when they are working.
No reason the above font could not be written in asm. It would be an interesting exercise!
Interesting. Never thought of using a cog for just ASM. I will have to look into that tomorrow when I get home from work. I feel a sense of accomplishment for getting the screen working thanks to the help of everyone on here I know very very little of ASM..just enough to be able to read and understand a few things, but I would like to learn how to convert spin to ASM. Calling functions in another cog would be new to me as well. I know how to start a cog and have it do it's thing, but an on demand type function would be interesting.
EDIT : I have the screen clearing with a blue background which takes about 9 seconds. After the screen goes blue, the font begins to show which takes about another 3 to 4 seconds. I made the screen tell my wife I love her Brownie points! +1 me
Glad to hear you got things working. I've had spotty success myself. My screen driver seems stable, if still a bit slow. It uses 2 cogs of asm, one to write the screen, and one to read the propfont from rom. There's plenty of room for improvement. It is sequential, and only processes one character at a time. If done properly, I believe it has potential. Dr A's fonts are way nicer though. I will be exploring the sd card again soon. BTW make sure you change
EDIT : I have the screen clearing with a blue background which takes about 9 seconds.
Converting spin to pasm can drive you batty! Fine if everything is pure pasm, but when some of the code is still in spin and is leaving pins high and thus pasm can't send them low (all cogs are wire-or) it can make things very confusing.
This is the ILI9325 pushed to its ultimate speed limit with the propeller. 16 bit bus. Two ram chips in parallel. 5 lines of pasm per pixel. The text is still Spin but the screen refresh is pasm. Blink and you will miss it. See my recent thread for the full code.
I timed a loop 100x and it is 3 seconds so that is 30milliseconds per full screen refresh.
Bottom line is this is going to be a very fast display if you buffer backgrounds and icons and fonts in ram. Scrolling in particular will be very smooth.
Comments
Data on this is hard to find.
I see this on the website
Sure the display itself runs on 3V but what do you connect up. 3V or 5V. Two supply pins. On board regulator which looks like it does the SD card but who knows about the display.
We need a schematic. I unzipped the .rar file and there are .pdfs but the one file we need is a .sch format. Who knows what format. Maybe Eagle?
I thought you already had tried 16 bit mode? What was different?
Have a play with this code and see if you can get some text on the screen. Add curx and cury in the VAR section. If you can get text you can then print numbers and that is useful for debugging other code.
PUB Propfont ' use propeller font in the rom for bootup messages when debugging sd cards curx := 0 ' set cursor to top left of screen (common variable) cury := 0 Propfont_string(string("Hello World")) ' string to send PUB Propfont_string(stringptr) 'print at curx,cury repeat strsize(stringptr) ILI9325.draw(curx,cury,curx+15,cury+31) ' location to start drawing Propfont_out(byte[stringptr++]) curx +=16 curx := 0 cury += 32 ' new line at end of string PUB Propfont_out(ascii) | address,pixels address := $8000 + (ascii >> 1) << 7 ' get rom address repeat 32 ' 32 rows per character, split in two parts pixels := long[address] ' get rom font data pixels := pixels >> (ascii & 1) ' shift for odd characters repeat 16 ' 16 columns if pixels & 1 ILI9325.pixel(%00000111_11100000) ' foreground color RRRRRGGG_GGGBBBBB else ILI9325.pixel(%00000000_00000000) ' background color pixels := pixels >> 2 ' alternate pixels interleaved so shift 2 address += 4 'increment address by 4 bytesHere is the current Pixel function :
PUB Pixel(VH,VL) ' send out a pixel, high byte then low byte Lcd_Write_Data(VH,VL)It seems to me that it needs to be split into 2 different parts?
PUB Propfont_string(stringptr) 'print at curx,cury repeat strsize(stringptr) ILI9325.Draw(curx,cury,curx+15,cury+31) ' location to start drawing Propfont_out(byte[stringptr++]) curx +=16 if curx => 240 curx := 0 cury += 32 curx := 0 cury += 32Out of curiosity, can ASM be mixed with spin or does ASM have to be all in one area? Basically, can I convert a function to ASM but leave the PUB there? Hope that makes sense. I have been reading about ASM, but still have quite a ways to go! Since it is faster, I would prefer to use that if I can understand it.
Sorry, my mistake. Yes, that was from my code, but I think you worked it out. Split into two bytes. RRRRRGGG then GGGBBBBB
Try some different colors. White on blue looks good.
And yes there is word wrap. If it gets to the bottom of the screen I had a routine to clear the screen and start at the top. A better text driver has a buffer to store all the characters so you can do scrolling.
Clearscreen is a bit slow in spin. Much faster in asm.
Asm runs in a cog and you have 7 cogs free (spin takes one) so once you load up a cog, you may as well fill it with 2k worth of code. So it often makes sense to put lots of routines in a cog and pass instructions to tell the cog which one to run. Things like 'clearscreen' and 'draw character'. We probably should put the ".draw" routine in asm.
I tend to write things in spin first, then move them over to asm when they are working.
No reason the above font could not be written in asm. It would be an interesting exercise!
EDIT : I have the screen clearing with a blue background which takes about 9 seconds. After the screen goes blue, the font begins to show which takes about another 3 to 4 seconds. I made the screen tell my wife I love her
Converting spin to pasm can drive you batty! Fine if everything is pure pasm, but when some of the code is still in spin and is leaving pins high and thus pasm can't send them low (all cogs are wire-or) it can make things very confusing.
This is the ILI9325 pushed to its ultimate speed limit with the propeller. 16 bit bus. Two ram chips in parallel. 5 lines of pasm per pixel. The text is still Spin but the screen refresh is pasm. Blink and you will miss it. See my recent thread for the full code.
I timed a loop 100x and it is 3 seconds so that is 30milliseconds per full screen refresh.
Bottom line is this is going to be a very fast display if you buffer backgrounds and icons and fonts in ram. Scrolling in particular will be very smooth.
[video=youtube_share;cu8HJPWWDDw]