Harold Hallikainen wrote 2012-08-17 16:42:

> Sorry to jump into this thread late, but the comment about shifting a 384
> bit buffer two bits caught my attention. Would it be possible to shift a
> pointer into the buffer by two bits instead? That'd be a whole lot faster=
!

A 384 *byte* buffer rotated 2 *bytes*.

Yes, I put priority in the "other" part of the code, the part
that does the multiplexing to the display. That code runs 100
times for each rotate of the buffer.

That is, TMR0 interrups with 1 ms intervalls and that is
when the multiplexing runs. Then, at 100 ms intervalls, the
buffer is roteted.

I decided that the multiplexing routing could be written more
efficent if it always sent the first 128 bytes of the 384
byte buffer using fixed addresses, no need to save/restore
of the pointerns.

And there is also extra complexity when the "moving window"
"wraps around", there have to be an address check in the middle
of the multiplexing routine to check for "end-of-buffer". That
part will run 128 times each 1 ms and I want as little
code as possible in there.

It will be enough to have 128 data bits sent to the DATA pin
and the CLOCK pin toggled for each pin each 1 ms interrupt.


If I can think out a clever way of checking for end-of-buffer.
Or maybe some calculations to calculate the number of bytes
until end-of-buffer and then reset the FSR register and
read the rest of the bytes from the start-of-buffer.

Anyway, what my code did, was to show the use of the new
indexed addressing modes together with the linear memory.

This is nothing serious, just to put some "text" on a
display I will sell on an auction site... :-)

But yes, you have a valid point!
And I'll give it a second though...


>>From what I understand (and this may not be correct), the idea is to send
> stuff to a multiplexed LED array. An FSR could point to the byte to be
> sent, and a byte of RAM could serve as a bitmask to determine which bits
> to send. I see this as a bit like a FIFO buffer. When we take a byte out
> of a FIFO, we don't shift all the remaining bytes over to fill the now
> empty space. We just move the output pointer.
>

The display only have storage (shift registers) for *one*
64 pixel row (128 red/green bits) at a time. You send
128 bits for the topmost row (as fast as possible) and
enable the ROW_ENABLE, COL_ENABLE, then wait a little and
then send 128 bits for row 2 and so on. By having a 1 ms
interrupt, the frequency of the individual LED dots will
be around 100 Hz, which is just on the edge for beeing OK
without flickering.

There is also a 3 bit ROW_SEL input that select which row
of the eight possible that will be lit. That also have
to be updated together with each 128 bit load.

Another guy write a PIC program some years ago for this
display using a dsPIC30 at full speed (in C). I would like
to see if I could do it with one of the PIC161xxx models.
I think so. :-)

Jan-Erik.



> Good luck!
>
> Harold
>
>
>
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.