Re: SED1335 Problem
- From: "Richard Phillips" <raphillips@xxxxxxxxxxxx>
- Date: Fri, 17 Mar 2006 22:54:13 GMT
Hello John,
I believe I have solved this problem now and I believe it was due to
spikes/interference, there is a previous thread (SED1335/Densitron...) about
this.
If I find that I am wrong and it's still a problem on Monday, I shall
definately be in touch!
Regards and thanks,
Richard.
"John B" <spamj_baraclough@xxxxxxxxxxxxxxxxxxx> wrote in message
news:441b3d57$0$819$4c56ba96@xxxxxxxxxxxxxxxxxxxxxxxxx
On 17/03/2006 the venerable riph72 etched in runes:
Hello,
I've written some code for an LCD module that uses this controller, and
am
99% there, but I'm experiencing a bit of a problem. I am aware this
could
well be just a driver coding issue of my making, but I've almost
exhausted
all avenues of investigation now so am hoping that the symptoms of my
problem will ring a bell with someone there.
Basically I am drawing a bitmap on screen (approx 50 * 50 pixels), row at
a time, using the "command byte+stream of data bytes" (per row) method.
Rarely, a problem occurs where an additional 8 pixels can be written on
the
end of the row. After investigation it appears that an extra byte has
been
inserted during the row write for some reason, since the first byte of
the
row is always written correctly and the last few bytes seem to have been
pushed along by 8 pixels. I know this looks like a silly coding error,
but bear with me!!
What is extremely confusing though is that this behaviour only occurs
under certain conditions.
It happens far far less frequently if I write my bitmap rows with
"command
byte + data byte + command byte + data byte...", but of course this is
much
less efficient. This could be a coding issue, though I currently don't
think so.
Also, it seems to almost go away completely if the data stream following
the command byte is a good mix of 1s and 0s. However, if I send lots of
0s it happens a lot. This doesn't look like a coding issue though?
My code should in theory work the same regardless of data byte values,
I've
done a quick check for any unusual optimisations etc but can see nothing.
Also, this problem goes away if I disable the screen before the bitmap
write and then re-enable it, but this doesn't explain what is going wrong
and I can't do this in practise anyway due to flicker.
If anyone there can offer any advice about what's going wrong I'd be
grateful!
One other thing worth mentioning, when writing data bytes (following
memory write commands) I synchronise the writes with the status flag on
D6.
Regards,
Richard.
Hi Richard,
I've done a lot of C code with S1D13305 using Atmel mega128 and Imagecraft
C compiler and never
seen this problem. Contact me directly and I may be able to help.
--
John B
Delete 'spam blocker' to reply direct.
.
- References:
- SED1335 Problem
- From: riph72
- Re: SED1335 Problem
- From: John B
- SED1335 Problem
- Prev by Date: Re: SED1335 Problem
- Next by Date: Re: Parallel Slave Port of PIC18F452
- Previous by thread: Re: SED1335 Problem
- Next by thread: problem in accessing microdrive in atmel board
- Index(es):
Relevant Pages
|
