mr_W
Junior Member level 2
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.
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.
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.