Has anyone tried running the GSL16880 capacitive touchscreen controller with Teensy3?

Status
Not open for further replies.
pgm_read_byte_far doesn't work as it should because GCC compiler uses 16 bit addressing for pgm by default and cannot be changed. The only way to go beyond 64K is to use the GET_FAR_ADDRESS routine I found on the internet and keep track of indexes in case of arrays, because indexing won't work with this routine.

#define GET_FAR_ADDRESS(var) \
({ \
uint_farptr_t tmp; \
\
__asm__ __volatile__( \
\
"ldi %A0, lo8(%1)" "\n\t" \
"ldi %B0, hi8(%1)" "\n\t" \
"ldi %C0, hh8(%1)" "\n\t" \
"clr %D0" "\n\t" \
: \
"=d" (tmp) \
: \
"p" (&(var)) \
); \
tmp; \
})

The code above retrieves the 24-bit address in flash where your array's beginning is stored. Then you combine this with pgm_read like this:

pgm_read_byte_far(GET_FAR_ADDRESS(GSLX680_FW[0].offset)+source_line*5);
F_byte = pgm_read_dword_far(GET_FAR_ADDRESS(GSLX680_FW[0].val)+source_line*5);

and you get the constants from the array. Number 5 is the struct size: 1uchar(1 byte) + 1 long int (4 bytes) = 5 bytes total

It was hard to get it right but I'm proud I sorted it out in the end :)
 
I've tried to run wolfmanjm code on an Arduino Mega (1280). I ran without BIGFLASH.
I get the following output:
Starting
Toggle Wake
clr reg
i2c write error: 4 E0
reset_chip
i2c write error: 4 E0
load_fw
Firmware length: 21414
reset_chip2
i2c write error: 4 E0
startup_chip
init done

Then nothing more happens.
Can it be related to CosR1 addressing issue ?
CosR1: I didn't get exactly what you have done. Did you modify the code?
 
Yea it is related, you need to make the mods he has suggested, as reading from Flash is not as straight forward as I had thought. It runs on teensy as there is no special program needed to read flash.
 
I'm not sure I understand the modifications he suggested...
Is it in the actual .ino file ?
I'm using the compressed version.
The code CosR1 suggests refers to GSLX680_FW which seems to be related to gslX680firmware.h...which is not compressed ?
I'm a bit confused...
Can you clarify ?
 
yea one is compressed the other is not compressed, you can use the uncompressed one as the 1280 has more flash available.

The issue is that the standard routine to read flash can not handle 24 bit addresses, so the hack he suggests will fix that. I have not tried it as I switched to using an arm board instead of an AVR based Arduino and that doesn't have this issue.

I think there is an alternative solution too, send the firmware in blocks and increment the base address each time using the FAR macro so it never has to read more than 256 bytes of flash at a time.
 
Hi,

I'm using the uncompressed version. I'm not familiar with the arduino so I can't help. If you are using GCC to compile for the arduino platform then 16-bit addressing is going to the a problem for you, too. You have to use the code I published here or it won't work. Use the GET_FAR_ADDRESS routine and then use the lines below to access the flash correctly and read the firmware.
 
_GSLX680_load_fw routine is where the changes are to be made. Find addr and F_byte and change these lines to

addr = pgm_read_byte_far(GET_FAR_ADDRESS(GSLX680_FW[0].offset)+source_line*5);
F_byte = pgm_read_dword_far(GET_FAR_ADDRESS(GSLX680_FW[0].val)+source_line*5);
 
Thanks,
Guess I have some reading to do. Need to understand a bit more how the memory stuff works on the Arduino.
I'll let you know if I manage to sort things out :)
 
I've now done some testing.
I'm using the compressed version. On Arduino MEGA (1280).
28860 bytes of flash verified.

It fails when trying to write to the GSL_STATUS_REG.
I get:
i2c write error: 4 E0
This indicates that I get error code 4 back when trying to write 0x88 to 0xe0 (which is GSL_STATUS_REG)
This happens in the clr_reg and reset_chip.

The firmware write sequence seems to be ok.

Is this really related to the 64K thing ? Sounds strange...
 
no that is unrelated, I think you can ignore those errors as they follow a reset and probably the chip is not ready yet.
 
no I never got it to work, which is why I suggest you use the uncompressed version. I did write a verifier for it though and it compares byte to byte with the original.
 
When using the uncompressed version on the Mega (1280) I get the message:
Global variables use 28.083 bytes (342%) of dynamic memory....
Any rewrite tricks to avoid this use of dynamic memory ?

BTW: I've ordered a Teensy 3.1 to see if I can make it work on that one first.
 
Last edited:
With that magic incantation the sketch was successfully uploaded to the Mega :)
I now use the uncompressed firmware, so I'll dig into that FAR memory issue...
 
Last edited:
While playing with the touch I found out 2 issues:

1) Start-up delay was not enough, so after power-up allow around 1 sec before flashing the firmware to the touch controller. Then, after you get it to work you can decrease the delay. <-- this also led to errors when sending commands

2) When the firmware was not loaded properly I got the same behavior you mention, i.e. some commands would fail (and in particular the clr_reg & reset_chip), so this is directly linked to the 64K thing.
 
Ok, but the sequence in the code seems to be:
Wake high
wake low
wake high
clr_reg (where I get the 4 E0 write error)
reset_chip (where I get the 4 E0 write error)
load_fw (no errors here!)
:
:

The 1 second delay you mention. Where should that be ? After wake high or after reset_chip ?
 
...and if I enable serial.print in the i2c_write function I get the following when loading firmware:
i2c write: F0
3,0,0,0,
i2c write: 0
C0,FF,A5,A5,
i2c write: 4
0,0,0,0,
i2c write: 8
E1,C4,10,E8
:
:
:

Can anyone confirm that this is correct ?

Update: A closer look shows that it stops firmware update when at firmware line 119... Interesting!...
the sizeof(GSLX680_FW)/sizeof(struct fw_data) gives me: 102. That is wrong. How stupid can I be... I have an 8 bit counter there... argh !!!
 
Last edited:
helgelangehaug said:
Ok, but the sequence in the code seems to be:
Wake high
wake low
wake high
clr_reg (where I get the 4 E0 write error)
reset_chip (where I get the 4 E0 write error)
load_fw (no errors here!)
:
:

The 1 second delay you mention. Where should that be ? After wake high or after reset_chip ?
Click to expand...

The 1 second delay should be right after uC and touch power-up - before the first wake high
 
YES !!!!
It now works with the Arduino MEGA !

I still get the 4 E0 errors, so I don't think that is related to the 64K issue.
And I didn't need the 1 second delay...

Now it's time to see if I can get the compressed version to work.
 
Last edited:
Yes it is fine with me, can you send me a pull request so i can update my version with the version that works? thanks
 
Status
Not open for further replies.
Back
Top