??? 02/24/05 23:01 Read: times |
#88401 - Oops! |
Hi,
Well ... I can't! In order to use the nice serial method mentioned by Eric which beautifully bypasses the need for paralell to serial conversion and it's overload I have to re-arrange the bits sent from PC to 8051, so that the uC can send this data to a SRAM and then to the display, but this rearrangement puts some implications in my design that makes it impossible to implement. I don't even know how to explain these problems ... it's rather complicated or something. It even made me down to some extent :-( Boosts required! Let me start with a don't-know-where-to-start-from description: Since the display is only dedicated to text, there is no "frame" or something to be displayed some 20 times every second, so only a copy of the text(converted to pixels of course) is stored in SRAM and the scroll is done by displaying different portions of this memory thus there is no need to have duplications of bit patterns in the SRAM and smaller SRAMs can be used. For the time being only SCROLL, HOLD and FLASH effects will be implemented and then FADE probabely. In my previous signs these bit patterns used to be stored in consecutive locations from address say 0000H to FFFFH, hence SCROLLing and HOLDing was just as easy as playing with addresses, but now in the new 8-segmented serial approach the bytes which where placed consequtively in the SRAM are to be cut in pieces(bits) and distributed like 8 single bits each located 32 "location"s farther from it's neighbour. To be continued! Best. |
Topic | Author | Date |
Oops! | 01/01/70 00:00 | |
storing bit maps | 01/01/70 00:00 | |
time constraints? | 01/01/70 00:00 | |
serial out | 01/01/70 00:00 | |
8x(4x256)? | 01/01/70 00:00 | |
Here is how bits relat to rows | 01/01/70 00:00 | |
sign data | 01/01/70 00:00 | |
if you can | 01/01/70 00:00 | |
Well I couldn't.![]() | 01/01/70 00:00 | |
What time constraints? | 01/01/70 00:00 | |
300us | 01/01/70 00:00 | |
Not again!! | 01/01/70 00:00 |