SERIN with uLCD-32PTU
Hi All,
I'm communicating between a uLCD-32PTU display module (4D systems) via serial with a bs2p24.
The issue I'm having is when zero's are part of the incoming serial data stream; they are not recognized or skipped over and thus my SERIN command times out.
For example:
SEROUT LCD_Tx, 240, [$FF,$37] 'touch get
SEROUT LCD_Tx, 240, [$00,$01] 'get x value
SERIN LCD_Rx, 240, 2000, timeout, [ack, x1, x2]
The x value returned is word size, so x1 (the high byte of x) will be 00 unless the users finger is on the far side of the screen (length of screen is 320 or 1,64).
How do I get SERIN to fill the x1 variable even if the incoming data are zeros? I have tried various input formatters to no avail.
Thanks for the help.
Henry
I'm communicating between a uLCD-32PTU display module (4D systems) via serial with a bs2p24.
The issue I'm having is when zero's are part of the incoming serial data stream; they are not recognized or skipped over and thus my SERIN command times out.
For example:
SEROUT LCD_Tx, 240, [$FF,$37] 'touch get
SEROUT LCD_Tx, 240, [$00,$01] 'get x value
SERIN LCD_Rx, 240, 2000, timeout, [ack, x1, x2]
The x value returned is word size, so x1 (the high byte of x) will be 00 unless the users finger is on the far side of the screen (length of screen is 320 or 1,64).
How do I get SERIN to fill the x1 variable even if the incoming data are zeros? I have tried various input formatters to no avail.
Thanks for the help.
Henry
Comments
IF ack = 80 THEN
x = x + 256
ENDIF
And the correct x value can now be used from here. This is just a way around this but something is clearly going wrong here with how I'm using SERIN (ack should always be 06).
Any help is greatly appreciated.
[COLOR=#333333]SERIN LCD_Rx, 240, 2000, timeout, [ack, x.HIGHBYTE, x.LOWBYTE] [/COLOR]
This will in effect, automatically combine the two byte into the word variable 'x'.
I'm curious if you have tried using the "Serial Commander - Picaso" as a debug tool as an interactive way to see the commands?
Here are some notes used when writing code for the Propeller and this display...
Enable Touch Screen:
Command BYTEs: $FF $38 {mode} ... return ACK (BYTE) ** Note: mode is sent as a WORD variable (2 BYTEs) ** mode = 0 : Enable Touch Screen Enables and initializes Touch Screen hardware mode = 1 : Disable Touch Screen Disables the Touch Screen. Note: Touch Screen task runs in the background and disabling it when not in use will free up extra resources for 4DGL CPU cycles. mode = 2 : Default Touch Region This will reset the current active region to default which is the full screen area
Define Touch area:
Command BYTEs: $FF $39 {x1 y1 x2 y2} ... return ACK (BYTE) ** Note: x1,y1,x2,y2 are sent as a WORD variables (2 BYTEs each ; 8 BYTES total) ** Specifies a new touch detect region on the screen. This setting will filter out any touch activity outside the region and only touch activity within that region will be reported by the status poll touch_Get(0); function.
Get touch:
Command BYTEs: $FF $37 {mode} ... return ACK (BYTE) + 2 BYTES (1 WORD) ** Note: mode is sent as a WORD variable (2 BYTEs) ** mode = 0 Returns the various states of the touch screen 0 = INVALID/NOTOUCH 1 = PRESS 2 = RELEASE 3 = MOVING mode = 1 : Returns the X coordinates of the touch mode = 2 : Returns the Y coordinates of the touch
I've attached my code above.
Chris - the above code uses x as a word variable and x.HIGHBYTE, x.LOWBYTE in the SERIN command. The SERIN command times out, even if the touch is in the x>256 area. I still this something fishy is going on with the ack (first byte received) - why would it change from 16 to 80?
Beau - I have used the serial commander and the display responds as expected. My code initializes the touch hardware (mode = 0), resets the touch area to be the full screen (mode = 2), then goes in to a loop that grabs the x value if a touch is detected.
Henry
Not sure why that would happen. The most likely causes are that you're not getting three bytes back or that the baud rate parameters are incorrect. Are other command working (doing what you command)? ou indicated earlier that your ack byte seemed to change from one value to another. I'll have to look at the documentation and see what you should be expecting.