Jazzed, when I try to build your example I get an error that says "Font.h: no such file or directory." I'm using the latest freshly downloaded SimpleIDE v0.9.64 on Windows XP. Any ideas?
Jazzed, when I try to build your example I get an error that says "Font.h: no such file or directory." I'm using the latest freshly downloaded SimpleIDE v0.9.64 on Windows XP. Any ideas?
Thank yo so much for asking that!
I thought I was just too stupid to make it work.
And for your perusal, a Spin version of the driver. This is translated more or less directly from the Arduino source and it's very slow; obviously the low bit banging needs to be done in PASM. But all the functions work, and it's very striking how much simpler it is than the sketch.
And for your perusal, a Spin version of the driver. This is translated more or less directly from the Arduino source and it's very slow; obviously the low bit banging needs to be done in PASM. But all the functions work, and it's very striking how much simpler it is than the sketch.
Well I'm flummoxed. After banging my head against it for a couple of days I finally got a PASM enabled version to mostly work.
The only problem is it doesn't position the cursor properly past Y=255. I have tried everything I can think of to no avail. The slower Spin version of the same thing works perfectly, and I can't find any differences. Timing does not seem to be an issue for this board.
I suppose there could be something wonky about the writing of the high byte of 16-bit data, but the high byte is written FIRST and the low is obviously working. Major screwing with the high byte -- changing the shift to place to 13 or 15 for example -- leaves the display kindasortaworking, but I can't figure out what is getting lost here.
The thing is almost impossible to debug since the prototype code is almost completely undocumented and starts off by spraying a string of unexplained magic numbers at the display.
With what would have been very little translation work if there was proper docs for debugging, this is very noticeably faster than even the LMM C version. And that's without even putting the CLS code in PASM too where it could be made almost instantaneous with very little effort. But what's with Y > 255?
The only problem is it doesn't position the cursor properly past Y=255. I have tried everything I can think of to no avail. The slower Spin version of the same thing works perfectly, and I can't find any differences. Timing does not seem to be an issue for this board.
Sending a command is definitely different. In SPIN you send 0 and the LSB of the command, in PASM only the LSB. Could that become an issue (not sure how it's related to the position problem)?
Sending a command is definitely different. In SPIN you send 0 and the LSB of the command, in PASM only the LSB. Could that become an issue (not sure how it's related to the position problem)?
kuroneko-san,
I picked up another one of these displays on sale the other day.
Would you like to have one to play with?
Sending a command is definitely different. In SPIN you send 0 and the LSB of the command, in PASM only the LSB. Could that become an issue (not sure how it's related to the position problem)?
THANK YOU kuroneko, I looked at that routine 20 times and was convinced it was signal for signal the same -- my eyes somehow glanced past that pushdata(0) every time. Now I need to add a high speed repeat and I'll repost it.
It's a very impressive piece of work, localroger!
Thank you for doing it.
It's also most frustrating.
Your drivers and demo work fine.
But I can't follow what's going on in there.
Ive been trying to figure out what goes where from the data sheet.
Even the TFT.CPP file just pumps numbers through with no clue of why or what they do.
I thought maybe for a first try at something simple I'd see if I could turn the display to letterbox.
That's supposed to be the low 4 bits of Register 3h (Entry mode pp93?)
But I'm still lost in translation from 8 bits to 18 bits - and which register is which.
I blame Arduino! Bad attitude!
"You don't have to know anything - just load the sketch"
Oh my!
I forgot to thank Jazzed for his work.
Awesome stuff.
And thanks.
I wasn't complaining ;-)
Free fish was a reference to the thought about teaching verses giving. Copy/paste of Arduino or Spin is free if it works; if not, well, you know. I guess actually learning to fish is harder now because you need to know where there is no mercury poisoning to catch edible fish (in the US at least).
Sorry, Jazzed. Didn't mean to imply that.
I'm familiar with the "free fish" issue. Teach a man to fish and he'll sit on a boat and drink beer all day.
I just wanted to offer thanks for getting this project off the ground.
I admit to being completely overwhelmed by the Arduino sketch.
Maybe no big deal for an experienced C guy,
but that I am not.
Current status:
The bounds checking seems to have cured the display crash problems quite well.
I haven't been able to smash it again at all. Looking good.
I found out how to "rotate" the character direction, and that works in all four directions.
That means portrait mode (default), protrait mode inverted, and landscape both ways.
It's a bit of a mind game though, because the original x-y axis orientation doesn't change.
So the characters change directions but (if I have it coded right) the direction of print doesn't.
There is probably a simple work around by swapping poX and poY, with a small gotcha to
deal with since he font look like 5x8 ratio, and not a square. Positioning and erasing for instance.
con
'Macro definitions for char display direction
LEFT2RIGHT = 0
DOWN2UP = 1
RIGHT2LEFT = 2
UP2DOWN = 3
var
byte atX, atY, a, b, atSize
pub main
init
setOrientation(0) ' 0 or 1 - haven't seen anything from this guy at all!
setDisplayDirect(0) ' 0, 1, 2, 3 work correctly! Turns character directions
atX := 0
atY := 100
atSize := 4
b:= -8*atSize
repeat a FROM 65 to 72
b+= 8*atSize
drawChar(a, atX+b , atY, 4, yellow)
' drawChar(ascii, poX, poY, size, fgcolor)
The only real problem now is the DrawString() routine doesn;t want to work when the direction is changes.
Works perfectly with DrawDirection(0), but is stuck in a single spot for directions 1, 2, and 3.
I'm (wild) guessing that there is either a sign misdirection, or we are getting stuck on a boundary?
pub drawString(ptr, poX, poY, size, fgcolor) | c
repeat
c := byte[ptr++]
if c == 0
return
drawChar(c, poX, poY, size, fgcolor)
if (DisplayDirect == LEFT2RIGHT)
if(poX < MAX_X)
poX += 8*size 'Move cursor right
elseif (DisplayDirect == DOWN2UP)
if(poY > 0)
poY -= 8*size 'Move cursor right
elseif (DisplayDirect == RIGHT2LEFT)
if(poX > 0)
poX -= 8*size 'Move cursor right
elseif (DisplayDirect == UP2DOWN)
if(poY < MAX_Y)
poY += 8*size 'Move cursor right
'from arduino library in arduino verion
Does anyone know the pinout for these? I've been googling but haven't found one. I thought I figured out the pins correctly from the schematic but I fear I may have reversed the polarity for power and fried it. All I'm seeing is a blank white screen
Does anyone know the pinout for these? I've been googling but haven't found one. I thought I figured out the pins correctly from the schematic but I fear I may have reversed the polarity for power and fried it. All I'm seeing is a blank white screen
Dude,
Now that you ask, no, not for the display itself. The only pin-out I've seen is for the controller chip
But since it plugs directly into the ASC board, would the pin-out for that help?
Unfortunately that doesn't help much. I have an Arduino Leonardo and checked with that (after frying it) but the problem is.... as far as I can tell.... the controller hooks to +5V and reset!? I'm terribly confused. Of course - this just going off memory now. I'll check again when I get home.
Well, if the display plugs into your Leonardo then the power, reset etc are all in the same place.
That's the deal with the ASC board. Martin Hodge designed it to be pin compatible with the Arduino.
Looks like Leo has some extra pins there, but the Arduino pins are still in the same place.
Figures... I'm not the first one to try this. The very first post of this thread says the v1.0 shield isn't compatible with Leonardo for some reason. Good news is, I guess that means I probably have two working LCDs now.
I'm sure the pinout is the same, I have no question about that. But the code has a bunch of preprocessor macros that bybass the typical arduino stuff and directly reference port/pin numbers. My guess is that port/pin numbers changed from Uno to Leonardo (even though "Arduino pin 1" might be in the same location, it refers to a different port or hardware pin).
If anyone is still trying to get the touchscreen working I think I've found the problem. Looking at the touchscreen datasheet http://www.adafruit.com/datasheets/AVR341.pdf we find this informative table:
What that means is that the touchscreen pins need to be asserted as outputs in order to excite the screen so that each coordinate can be read. And you only assert those voltages when you're reading, because the screen draws power.
Unfortunately, the Prop ASC "ADC" pins are connected straight to the MCP3208, which can't assert them as outputs. This means a modification will have to be made to either the ASC or the shield to provide switchable excitation voltage to the touchscreen. It would of course make more sense to modify the shield, except that only two of the "Arduino" I/O pins on its connectors are unused, and those are through 2.2K protective resistors which won't work for supplying excitation to the resistive screen. The simplest thing will probably be to solder some jumpers between the "ADC" connector pins and unused Prop I/O pins on the non-Arduino expansion connector on the back of the ASC, where the thru-hole connector pins are accessible.
I've played with the TFT demo for a while now.
It's rearranged from LocalRoger's version, with test routines added to investigate the text functions.
It works beautifully in Portrait mode (DisplayDirect = 0).
But there are some gotchas in the other three orientations that are over my head.
Frankly, I suspect the original Arduino code may have the same problems...
I almost have the first landscape mode (DisplayDirect = 1) working, but there is a byte biting on it somewhere.
It's Trippy.
X is used for Y and Y is used for X, but runs backwards.
But it fails for any Y values over 255.
The 255 limit of 320 max leaves some left margin unavailable (left margin in Landscape,mind you!)
It would be really nice if this display could be used in Landscape as well.
But it's not happening yet..
Comments
Ooops. Here it is.
Thank yo so much for asking that!
I thought I was just too stupid to make it work.
SS_TFT.spin
Nice.
Looking forward to the PASM "send*" code.
I don't have time to write it.
The only problem is it doesn't position the cursor properly past Y=255. I have tried everything I can think of to no avail. The slower Spin version of the same thing works perfectly, and I can't find any differences. Timing does not seem to be an issue for this board.
I suppose there could be something wonky about the writing of the high byte of 16-bit data, but the high byte is written FIRST and the low is obviously working. Major screwing with the high byte -- changing the shift to place to 13 or 15 for example -- leaves the display kindasortaworking, but I can't figure out what is getting lost here.
The thing is almost impossible to debug since the prototype code is almost completely undocumented and starts off by spraying a string of unexplained magic numbers at the display.
With what would have been very little translation work if there was proper docs for debugging, this is very noticeably faster than even the LMM C version. And that's without even putting the CLS code in PASM too where it could be made almost instantaneous with very little effort. But what's with Y > 255?
kuroneko-san,
I picked up another one of these displays on sale the other day.
Would you like to have one to play with?
THANK YOU kuroneko, I looked at that routine 20 times and was convinced it was signal for signal the same -- my eyes somehow glanced past that pushdata(0) every time. Now I need to add a high speed repeat and I'll repost it.
SS_TFT_PASM.spin
Thank you for doing it.
It's also most frustrating.
Your drivers and demo work fine.
But I can't follow what's going on in there.
Ive been trying to figure out what goes where from the data sheet.
Even the TFT.CPP file just pumps numbers through with no clue of why or what they do.
I thought maybe for a first try at something simple I'd see if I could turn the display to letterbox.
That's supposed to be the low 4 bits of Register 3h (Entry mode pp93?)
But I'm still lost in translation from 8 bits to 18 bits - and which register is which.
I blame Arduino! Bad attitude!
"You don't have to know anything - just load the sketch"
Free fish.
I forgot to thank Jazzed for his work.
Awesome stuff.
And thanks.
I wasn't complaining ;-)
Free fish was a reference to the thought about teaching verses giving. Copy/paste of Arduino or Spin is free if it works; if not, well, you know. I guess actually learning to fish is harder now because you need to know where there is no mercury poisoning to catch edible fish (in the US at least).
I'm familiar with the "free fish" issue.
Teach a man to fish and he'll sit on a boat and drink beer all day.
I just wanted to offer thanks for getting this project off the ground.
I admit to being completely overwhelmed by the Arduino sketch.
Maybe no big deal for an experienced C guy,
but that I am not.
The bounds checking seems to have cured the display crash problems quite well.
I haven't been able to smash it again at all. Looking good.
I found out how to "rotate" the character direction, and that works in all four directions.
That means portrait mode (default), protrait mode inverted, and landscape both ways.
It's a bit of a mind game though, because the original x-y axis orientation doesn't change.
So the characters change directions but (if I have it coded right) the direction of print doesn't.
There is probably a simple work around by swapping poX and poY, with a small gotcha to
deal with since he font look like 5x8 ratio, and not a square. Positioning and erasing for instance.
con 'Macro definitions for char display direction LEFT2RIGHT = 0 DOWN2UP = 1 RIGHT2LEFT = 2 UP2DOWN = 3 var byte atX, atY, a, b, atSize pub main init setOrientation(0) ' 0 or 1 - haven't seen anything from this guy at all! setDisplayDirect(0) ' 0, 1, 2, 3 work correctly! Turns character directions atX := 0 atY := 100 atSize := 4 b:= -8*atSize repeat a FROM 65 to 72 b+= 8*atSize drawChar(a, atX+b , atY, 4, yellow) ' drawChar(ascii, poX, poY, size, fgcolor)The only real problem now is the DrawString() routine doesn;t want to work when the direction is changes.
Works perfectly with DrawDirection(0), but is stuck in a single spot for directions 1, 2, and 3.
I'm (wild) guessing that there is either a sign misdirection, or we are getting stuck on a boundary?
pub drawString(ptr, poX, poY, size, fgcolor) | c repeat c := byte[ptr++] if c == 0 return drawChar(c, poX, poY, size, fgcolor) if (DisplayDirect == LEFT2RIGHT) if(poX < MAX_X) poX += 8*size 'Move cursor right elseif (DisplayDirect == DOWN2UP) if(poY > 0) poY -= 8*size 'Move cursor right elseif (DisplayDirect == RIGHT2LEFT) if(poX > 0) poX -= 8*size 'Move cursor right elseif (DisplayDirect == UP2DOWN) if(poY < MAX_Y) poY += 8*size 'Move cursor right 'from arduino library in arduino verionDude,
Now that you ask, no, not for the display itself. The only pin-out I've seen is for the controller chip
But since it plugs directly into the ASC board, would the pin-out for that help?
That's the deal with the ASC board. Martin Hodge designed it to be pin compatible with the Arduino.
Looks like Leo has some extra pins there, but the Arduino pins are still in the same place.
Try this one and compare?
http://forum.arduino.cc/index.php/topic,148308.0.html
http://forums.parallax.com/showthread.php/154288-2.8-TFT-Touch-Shield-V1.0-amp-Propeller-ASC
David
But the basic signal and pin arrangements match.
It was my understanding that the Leo is backwards compatible with the Arduino
Compare the ASC drawing to that Leo diagram.
What that means is that the touchscreen pins need to be asserted as outputs in order to excite the screen so that each coordinate can be read. And you only assert those voltages when you're reading, because the screen draws power.
Unfortunately, the Prop ASC "ADC" pins are connected straight to the MCP3208, which can't assert them as outputs. This means a modification will have to be made to either the ASC or the shield to provide switchable excitation voltage to the touchscreen. It would of course make more sense to modify the shield, except that only two of the "Arduino" I/O pins on its connectors are unused, and those are through 2.2K protective resistors which won't work for supplying excitation to the resistive screen. The simplest thing will probably be to solder some jumpers between the "ADC" connector pins and unused Prop I/O pins on the non-Arduino expansion connector on the back of the ASC, where the thru-hole connector pins are accessible.
It's rearranged from LocalRoger's version, with test routines added to investigate the text functions.
It works beautifully in Portrait mode (DisplayDirect = 0).
But there are some gotchas in the other three orientations that are over my head.
Frankly, I suspect the original Arduino code may have the same problems...
I almost have the first landscape mode (DisplayDirect = 1) working, but there is a byte biting on it somewhere.
It's Trippy.
X is used for Y and Y is used for X, but runs backwards.
But it fails for any Y values over 255.
The 255 limit of 320 max leaves some left margin unavailable (left margin in Landscape,mind you!)
It would be really nice if this display could be used in Landscape as well.
But it's not happening yet..
the heart of itL
' draw some ASCII letters according to DisplayDirect ' uses the entire display! atX := 0 atY := 0 atSize := 1 ' setDisplayDirect(0) 'Portrait0 '' 30 x 34 repeat lin from 0 to 34 ' lines repeat col FROM 0 to 9 ' columns 30 characters ch := col + "0" 'create an ASCII character drawChar( ch, atX+col*8*atSize, atY+lin*9*atSize, atsize, YELLOW) drawChar( ch, 80 + atX+col*8*atSize, atY+lin*9*atSize, atsize, BRIGHTRED) drawChar( ch, 160 + atX+col*8*atSize, atY+lin*9*atSize, atsize, GREEN)But it allows full screen access.
Just gotta use pointers.
I didn't realize you'd written a whitespace interpreter for the propeller! Good job!