View previous topic :: View next topic |
Author |
Message |
Ttelmah
Joined: 11 Mar 2010 Posts: 19545
|
Anyone played with the EVE screen controller?. (solved) |
Posted: Wed Oct 30, 2019 4:31 am |
|
|
Hi,
Using the FT815 EVE TFT LCD controller being driven by a PIC24, and trying
to use interrupt driven code to handle touch screen events. Having an 'oddity', and wondering if anyone else has used this controller?.
The controller is a 'smart' screen controller. Allows you to send commands
to draw lines from x,y to x2,y2, draw text, rectangles, circles etc..
Some of the commands are quite sophisticated, but some are quite
annoying!. Anyway as well as the screen itself, the unit can control a
touch panel, and automatically return a 'tag' number when a programmed
button is touched. One of the options is to enable an interrupt output to
automatically trigger when the detected 'tag' changes.
Have it all programmed up, and actually working, but it currently will
only work if I explicitly read the interrupt flag register in the main code loop.
Reading the register is what resets it.
My interrupt code is:
Code: |
#INT_EXT0 LEVEL=2
void touch(void)
{ //handler for a touch interrupt - since at same level as interpreter and
//disabled while list is open, can simply execute fetch here.
//Every button returns it's ASCII value to use. However
//buttons supporting a position return (so slider etc.) return ASCII>127
//These then need a position read as well.
//Using tags>127 for position tracked buttons or
//time based buttons. Mode controls which.
unsigned int8 keyval, flags;
int len;
//Read tag.
keyval=EVE_MemRead8(REG_TOUCH_TAG); //
flags=EVE_MemRead8(REG_INT_FLAGS); //Now read interrupt flag register to reset
if (input_mode==HANDLE_SCROLL)
{
//Here we do the actual value using timer3. keyval==0, released.
if (keyval==0)
{
//Here released
disable_interrupts(INT_TIMER3); //turn off repeat handling
return; //and exit
}
if (keyval>127)
{
//here a time based button has been pressed.
action=keyval; //save for timer code
set_timer3(0);
clear_interrupt(int_timer3);
enable_interrupts(INT_TIMER3);
return; //and exit
}
if (keyval==13)
{
//exit
//send to system
fprintf(SERIAL,"%dX\n",value);
input_mode=NOTHING; //finish touch handling
return; //and exit
}
}
if ((input_mode==HANDLE_BOARD) || (input_mode==HANDLE_PAD) || (input_mode==HANDLE_SLIDE))
{
if (keyval>127)
{
TrackerVal=EVE_MemRead32(REG_TRACKER);
//Remember position is upper 16bits
TMR5IF=TRUE;
return; //and exit
}
else
{
//Here I have an ASCII key so store this into message
len=strlen(message);
if (len>30)
len=30;
if (keyval==8)
{
if (len>0)
message[len-1]='\0';
TMR5IF=TRUE; //interpret again
return;
}
else
{
if (keyval==14) //shift key handling
{
shift=!shift;
TMR5IF=TRUE; //and update display
return;
}
else
{
if (keyval!=13)
message[len]=keyval;
else
{
//send to system
fprintf(SERIAL,"%s\n",message);
input_mode=NOTHING; //finish touch handling
return; //and exit
}
}
}
message[len+1]='\0';
//Now trigger timer 5 interrupt to interpret
TMR5IF=TRUE;
}
}
}
|
It uses a timer to give a 'repeat' on certain buttons when held, and
TMR5 to handle a command interpreter that has to be triggered. Data
from input messages is sent via serial when the message is complete
or the button is held. This automatically redraws the display.
This all works, but _only_ if I read the flag register in my main code.
So:
Code: |
//Minimum loop for demo:
while (TRUE)
{
//Tick to master system
if (tick==0)
{
fputc('A',SERIAL);
tick=61;
}
delay_us(5);
temp=EVE_MemRead8(REG_INT_FLAGS); //Now read interrupt flag register to reset
//remove this stops working....
}
|
If I have the read of the flag register, the interrupt triggers and works.
However if I don't have this, the touch interrupt does not trigger.
Now the read of the flag register, resets any triggered flag. However if
you look at the interrupt code, I read the flag register in this.
So it should be a case of interrupt happens, reads register, resets, and
exits. However this is not working....
I'm wondering if the read in the interrupt does not work because of
a latency issue (so the interrupt can't be cleared for a few uSec
after it has set), but there is no mention in the data sheet of this. It
simply says the register can be read at any time to reset the flags.
The interrupt I'm using is 'tag changed', which does also trigger when
a button is released (returning a tag of 0 in this case).
The serial is interrupt driven bot on transmit and receive. The RX interrupt
has a higher priority than the touch handling to ensure characters are
not missed.
Timer5 is used as a dummy interrupt to trigger a screen command
interpreter that is called by code driven by the hardware events.
So, a case of has anyone else tried programming this controller, and
particularly tried to use the interrupts?.
Last edited by Ttelmah on Wed Oct 30, 2019 7:41 am; edited 1 time in total |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19545
|
|
Posted: Wed Oct 30, 2019 4:41 am |
|
|
Having posted, I've just proved it is a latency problem.
Moved the clear to the exit point of the interrupt. Had to put a different
version at every return used in the code. With this it works.
So a caveat to anyone. If you are using this controller, it looks as if you
need a couple of uSec between arriving in the interrupt handler and
trying to clear the interrupt flags. I'm running at 120MHz, so the time
to actually enter the interrupt is only perhaps 0.5uSec. The SPI is clocked
at 30MHz. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Wed Oct 30, 2019 8:08 am |
|
|
Previous job, I used the 813. Nice chip but definitely had some quirks. Biggest issue was with graphic artifacts (bugs) regarding graphics with transparency (and the automatic dithering applied to text has transparency) hitting other graphics objects with transparency. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19545
|
|
Posted: Wed Oct 30, 2019 8:47 am |
|
|
Yes, I've already met some of the artifact problems. Generating rotated text
(which is terribly complex to do - you have to apply a bitmap rotation to
each individual character in turn, and handle the display positioning all
yourself), it insists on displaying odd bit patterns in the overlap areas of the
characters. This is because of the dithering as you found. Turn this off
and all displays fine. One of these 90% great products, but with 'oddities'. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Wed Oct 30, 2019 11:57 am |
|
|
I had great success with negating most issues by applying a mask which covered only the area I was updating, then drawing what I wanted within that mask. Repeat as necessary. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19545
|
|
Posted: Thu Oct 31, 2019 1:16 am |
|
|
Thanks, will experiment. |
|
|
handixx
Joined: 01 Jul 2010 Posts: 12
|
|
Posted: Fri Aug 28, 2020 3:43 am |
|
|
Hi guys,
I am starting with the BT815. I would like to know if someone already has a library to drive it ? or maybe a little project to share to see how it works.
Thanks |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19545
|
|
Posted: Fri Aug 28, 2020 10:09 am |
|
|
Look here:
<https://www.ftdichip.com/Support/SoftwareExamples/FT800_Projects.htm>
Right hand side 'Creating a simple EVE library for a PIC MCU'.
Download the sources. Then replace the MCU section to suit your PIC.
Code: |
#ifndef MCU_IF
#define MCU_IF //ensure only loads once
// ########################### GPIO CONTROL ####################################
// --------------------- Chip Select line low ----------------------------------
#inline
void MCU_CSlow(void)
{
output_low(DISP_CS);
disable_interrupts(INT_EXT0); //delay_cycles(1);
//output_drive(PIN_B0);
}
// --------------------- Chip Select line high ---------------------------------
#inline
void MCU_CShigh(void)
{
delay_cycles(1);
output_high(DISP_CS); // CS# line high
//output_float(PIN_B0);
enable_interrupts(INT_EXT0);
}
// -------------------------- PD line low --------------------------------------
void MCU_PDlow(void)
{
OUTPUT_LOW(disp_pd); // PD# line low
}
// ------------------------- PD line high --------------------------------------
void MCU_PDhigh(void)
{
output_high(disp_pd); // PD# line high
}
// ################################# SPI #######################################
// --------------------- SPI Send and Receive ----------------------------------
/*byte spi_readmy(byte DataToWrite)
{
byte rval;
rval=spi_read2(DataToWrite);
delay_cycles(4);
return rval;
}*/
#byte SPI2BUF =GETENV("SFR:SPI2BUF")
#byte SPI2STAT=GETENV("SFR:SPI2STAT")
#bit SPI2TBF=SPI2STAT.1
#bit SPI2RBF=SPI2STAT.0
#word IFS2=getenv("SFR:IFS2")
#bit SPI2IF=IFS2.1
//#inline
/*byte spi_readmy(byte data)
{
//byte val;
SPI2BUF=data;
delay_cycles(6);
while (SPI2TBF==1)
; //wait for byte to start send
while (SPI2RBF==0)
; //wait for byte to receive
return SPI2BUF; //return data
}*/
spi_readmy(byte data)
{
//byte val;
SPI2IF=FALSE; //clear interrupt
SPI2BUF=data;
delay_cycles(2);
//while (SPI2TBF==1)
// ; //wait for byte to start send
while (SPI2IF==0)
; //wait for byte to receive
return SPI2BUF; //return data
}
#DEFINE MCU_SPIReadWrite(DataToWrite) spi_readmy(DataToWrite)
//Problem. SPI on the 33FJ has an errata if bytes are written quickly
//need to either delay for 0.125uSec or poll the RBF bit.
//Polling
#endif
|
This is mine for SPI2 on a DSPIC33. Has a timing issue (fix at the end of
this). |
|
|
handixx
Joined: 01 Jul 2010 Posts: 12
|
|
Posted: Mon Aug 31, 2020 2:35 am |
|
|
thanks for your help, I will try that !! |
|
|
handixx
Joined: 01 Jul 2010 Posts: 12
|
|
Posted: Mon Aug 31, 2020 10:53 am |
|
|
Well After a day on it.. my display still not working. and I don't know why, I have the com but that all..
By the way, is't normal to recive data from the BT when I am writting a adress (like 32000 to get the 7C ) ? |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9244 Location: Greensville,Ontario
|
|
Posted: Mon Aug 31, 2020 11:00 am |
|
|
We need more information...
The 'BT815' is just a chip and I assume you're using some kind of 'module' ? If so , post a link to it. Also which PIC are you using AND compiler version !!
This is criitcal as not all compilers work for all PICs and some 'defaults' will make life 'interesting'....
Details like VDD for PIC and display......most peripherals today are 3 volt devices and NOT 100% compatible with 5 volt PICs. |
|
|
handixx
Joined: 01 Jul 2010 Posts: 12
|
|
Posted: Tue Sep 01, 2020 1:07 am |
|
|
good morning,
I am using the evaluation board, VM816C50A-D powered in 5v ( regulator 3.3 on the board)
https://brtchip.com/m-eve3/
My PIC is the DSPIC33FJ64GS608 powered in 3.3V I am using the SPI1
I use MPlabX 5.10 and the compilator PCD version 5.074 |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19545
|
|
Posted: Tue Sep 01, 2020 2:02 am |
|
|
Yes. SPI is always a bi-directional bus. Every time you send a byte,
you receive a byte back. These can in some cases (depending on the slave
device), have significance, but are often just garbage.
So you are receiving the 7C correctly?.
The most likely problem is getting the settings right for the display.
Getting the settings right for the HSYNC, VSYNC, line length etc., is a real pain.
The manufacturers data seems often to be wrong (I had to run with different
clock settings to those 'recommended').
Does this display have a crystal?. I had two displays with the same part
number, and one came with a crystal, and the other without!....
Worth trying with the EVE_HAS_CRYSTAL not defined, and see if the
display then wakes. Remember it is not going to display anything at
first, till you send something, and you need to execute the display list
before it'll show. |
|
|
handixx
Joined: 01 Jul 2010 Posts: 12
|
|
Posted: Tue Sep 01, 2020 4:25 am |
|
|
Well I have a productive morning !! the spi is working well, I control the backlight the output frequency is good so I suppose the setting of my crystal is correct (12Mhz =>60Mhz) so I am in the good way.. I will check the parameter of the display.. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9244 Location: Greensville,Ontario
|
|
Posted: Tue Sep 01, 2020 5:12 am |
|
|
just a comment...
I looked at the datasheet from the 'link'...
While it's 'working' now... be sure the power supply is good for at least 2 amps or more depending on what else the PIC controls.
I saw the backlight alone can draw up to 100ma. If you switch from zero to 100%, you could get a 'huge' current spike, that drops VDD, and resets the PIC. Worse is it randomly causes some bytes of RAM to have bad values.
Jay |
|
|
|