Hi,
I've got this problem that is already taking too much time and I cannot really figure out what is happening here:
As per datasheet, to read data from T6963C, one needs to bring C/D line to low, then bring down /CE and /RD also down for at least tACC time (specified at 150ns), after that data will be available for reading at D0-D7 lines. When done with reading, bring /CE and /RD up.
MCU in question is ATmega32U4 and although pins used for D0-D7 do not belong to same port due to funky pinout of my board, I've used macros to make code look neat.
Code C - [expand] |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| uint8_t RA6963_Read( )
{
RA6963_Wait();
LCD_DATA_DIR_IN(); // set D0-D7 pin directions
IO_PIN_LOW( LCD_CD ); // we are reading data
__asm("nop"); // 62.5ns delay
IO_PIN_LOW( LCD_CE );
IO_PIN_LOW( LCD_RD );
__asm("nop"); // 62.5ns delay
__asm("nop"); // 62.5ns delay
__asm("nop"); // 62.5ns delay
// that is quite bit more than 150ns
uint8_t ret = LCD_DATA_IN();
IO_PIN_HIGH( LCD_RD );
IO_PIN_HIGH( LCD_CE );
IO_PIN_HIGH( LCD_CD );
return ret;
} |
Now the problem: data returned is correct (for most of the time, as I cannot get it to work 100% reliably) if I have 2 x nop insn between pulling RD line low and reading the data. If I make the delay shorter, I get wrong data. However if I make the delay longer, I ALSO get wrong data? How can this be? It almost looks like data on D0-D7 lines is lost after approximately 200ns.
For the time being I am simply unable to catch this one. I have tried tracing this with scope, and have seen some interference on data lines, but given that I have 2ch scope only (actually 4ch, but only 2 of them are analog.) I couldn't catch D0-D7 change the state during longer /RD times.
Note: I have browsed for too many T6963C code examples, but none really had tackled the problem of reading data from it - most of them said they have implemented it, but never tested it. The thing is, I really need that functionality, since RAM on 32U4 is scarce and I cannot afford to keep the full framebuffer on MCU side, which for any sort of advanced drawing (fonts, bitmaps, fills) is needed.