Okay, finally got the chip initialzed and can draw something on it BUT i'm getting reading problems from the chip! I goggled it and someone had the exact same problem. When I issue MREAD, D6 is alway stuck at one.
http://projects.tbmn.org/cgi-bin/trac.c ... d_pitfalls
Quote:
Due to the memory problem (see above) the LCD memory has to be read out. This is done with the wiki:SED1335 MREAD command. The problem is that there a lots of bit-errors which renders the received data completely unuseable. I also tried to read a whole bunch of values and accept the value only, if the bunch of values was the same. (this solution end up in an endless loop)
The cable from the wiki:ATMega16 to the LCD controller PCB is currently pretty long (about 50cm) which might be a reason for the bit-errors. The funny thing is that the LCD controller receives all the data-bytes just fine without errors, so it should work the other way too.
I just had a look at the data-lines with my scope. It turned out that the controller PCB's data pin D6 (Pin8 on the SUB-D25 connector) goes crazy if the wiki:SED1335 controller is in MREAD mode. I even completely disconnected the pin from the circuit by temporarily cutting through a PCB track and the strange signal was still on the pin. I will also verify if the on the AVR controller received data changes in bit6 only. Furthermore I also looked for electronic wiki:suppliers where I could get a new wiki:SED1335 in case it is broken.
I'm pretty sure now, that the SED1335 controller on the controller PCB here is not working properly, at least not in MREAD mode. The PCB was not stored safely and an electrostatic discharge might have done damage to the controllers output-buffer. Since I do have to build up a project PCB (wiki:controller_design) with an ATMega128 (see memory problem above), I am designing a new SED1335 PCB (wiki:lcd_controller_redesign) as well. The ATMega128 controller does support up to 64K external SRAM memory which will be more than I need.
Login
FAQ
Search
