fitting 35 bits into a long
CassLan
Posts: 586
I know it sounds like a silly question..but,
I have a 7x5 led matrix (35 leds) and it would be sooo sweet to fit that info (which leds are on/off)·into one long.
Anyone have an idea how to do this? I'm only short 3 bits.
Thanks,
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
I have a 7x5 led matrix (35 leds) and it would be sooo sweet to fit that info (which leds are on/off)·into one long.
Anyone have an idea how to do this? I'm only short 3 bits.
Thanks,
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If you limit number of leds on to 5 then you could use 6x5 bits to show what is on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
RLE
maybe there are some combinations that are not possible so you may code for special cases only like: ** mean **..., *. = ***.. and so on...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Unless... you know that you are only ever going to display a limited subset of the possible patterns the thing can display.
Say for example you only used a set of characters and numbers from some font and maybe some graphical icons. Then you could probably number all the possibilities in a BYTE or a word say. Then use those numbers to look up what the patten should be. Or some other way of inferring the correct display pattern for each symbol.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
any more details on exactly what you want out of it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
If you really have arbitrary 35 bit information, why not split it into 32 bits and 3 bits and store the 3 bits separately. You could easily have one table of 32 bits and three tables of single bits. With the Propeller's barrel shifter, it's just as easy to shift 30 bits as it is to shift 1 bit. You'll spend almost as much time breaking out the 7 bit groups (or 5 bit groups) for multiplexing.
I would like to make some animations consisting of static "screens", then create some animations with formulas that pack the data into the proper format of what the display driver likes to deal with. This would then lead to reading font info out of the ROM and some transition effects from one screen to another.
Its not too big a deal to have the info in a 35 bit length of memory instead of one long, I can re-write it.
I just figured I would ask.
Thanks,
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
But "bit stretching" found nice pictures.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Casslan, even if you stored it in two longs, yes, I know it's wasteful, but hey, when you have just over 8000 of them [noparse]:)[/noparse] 2 longs per frame isn't much, and 600 longs at 10fps gives you a minute of animation. is an ok frame rate for animation also.
Especially if you have SD, the worlds your oyster [noparse]:)[/noparse]
Or just use 40bits ( 5 bytes ) and read bytes rather than longs from hub-ram
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Just keep trying. Remember, invention is 99% perspiration.
Isn't that just PWM?
My XI input regularly gets bit stretched.
BTW no one mentioned just using a hammer to fit those extra bits into that word.
My latest Prop project controls over 1200 outputs with one cog dedicated to read data from a circular queue and sending the data out to the UCN 5832s. I does not even break a sweat.
I simply clock the data in, set the strobe input high for one clock cycle then my program can go off to do other things until new data arrives.
That's already in my signature!
And despite what others say: That works! You can scram more bits into a byte with a very tricky hardware-technique. Chip invented that (but never told you so).
There is only one problem: Bit stuffing is already used on the Prop. In fact, its only a 24 bit processor with 30% stuffing.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
32 bits can represent 4 billion different combinations. But your LED Display has 35 elements, or 34 billion combinations. So, the only way to get it to work is to eliminate some of the combinations, and this will involve some lookup / translation.
Or just use 35 bits...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Gadget Gangster - Share your Electronic Projects
you can generate all 4B possibilities, just at different times.
Hi CassLan
is there a real reason to have to do it this way? Sure, having each bit act as a one-to-one flag with the state of the LED's is convenient. Actually, it only *seems* convenient when looking at holding this state info in one catch-all place.
As Steve mentions, by the time you've encoded and decoded those state bits, you've gobbled up instructions and cycles. Maybe you learn some coding techniques, which is good ... but usually brute force is the cleanest, fastest --- and easiest to *understand* later.
Loop through an array of bytes, each byte element is ether 1 or 0 - test for that and you're done !
cheers,
Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Y:=number of bits ON
X:=order in which that many bits CAN be on.
LONG:=X + (35 * Y)
The problems with this method is that I don't know how to find the counting order quickly,
and I'd need to know that before being able figure out how to fold the excess orders of many
bits into the lack of orders for few bits. The properties of the method include knowing the
states that there are not enough bits to store, so the loss of 3 bits can be recovered by the
knowledge of how many bits are on and the infinitesimal meaning of bits that can be chosen
to be discarded if there is an overflow in the combinatoric order.
Think about this: For only 10 bits,
The best case values are Y=1 to 10 when X=1; we can store this without using all 10 bits.
The worst case values are Y=1 to 252 when X=5 ; we lack only one bit to store the 5,
but can recover from stealing a bit from Y since knowing the number of one bits is more important.
And this problem vanishes with more bits and turns into lossless (but not very compact) compression.
A similar idea that might work is using LOG.
Even if I am wrong, 35 bits CAN STILL be losslessly compressed into 32 bits.
Or else, lossy compressions can have the loss spread so thin that visible glitches are rare.
If anyone knows how to quickly find the lexic index order X of a Number N with Y one bits,
and the inverse function, please share! But the slow method is simple enough to dedicate a Cog
to do reasonably fast. Simply start with Y low bits as ones, and repeat X times the process of
moving from right to left until you encounter 01, then change that to 10, and move all passed
one bits together on the right (squeezing out the zero bits). There is an arithmetic-logic function
called snoob or "same number of one bits" that counts that way, which I do not recall at the moment.
If you are using an alpha font then there are redundancies and overlaps that can be exploited.
Capital letters and numbers can be reversibly changed from 5x7 to 5x5, and they can overlap
when the tops and bottoms are the same, and also, 5x5=25 bits. I once posted a demo of an
80 column font which could not fit in Hub Ram with the video buffer and the Spin without those
tricks. Reversibly changing 5x7 to 5x5 is based on rows 2 and 3, and rows 5 and 6, almost always
being identical. Also the 5x5 alphas can be reused as lower case without using any more memory.
It may be a headache but arranging the bits in groups of 35 is still a useful option if you have room for them;
it is not so hard to calculate which bit represents which pixel in which character.
Post Edited (VIRAND) : 12/1/2009 9:51:31 PM GMT
almost certainly beats anything else.
Yeah I'm just gonna go ahead with the 5 bytes, no biggie : )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
I've been pondering matrix displays. 7x5 is neat for capitals, but small p and q look better with the descenders and so really you need 9x5. Hmm - 45 into 64 still doesn't go. I guess for text you would have a text driver with a lookup table and then instead of needing 35 bits you really only need 8 bits to store an ascii byte. But for graphics, there are some neat 8x8 displays around www.futurlec.com/LEDMatrix.shtml and that does fit very neatly into two longs. So Order is returned to the Cosmos.
I ordered some 8x8 displays the other day and I reckon a prop would be just perfect as a driver chip.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
It might be a bit of a programming exercise, but why not send/store it in continuous bitstream packets? (similar to how I 'appended' additional Bytes in the CRC program)
For the bits to properly wrap back around and fit evenly into the longs, each data packet would need to be 35 longs representing 1120 bits of data.
Someone mentioned speed, if you look at the data as a huge bit stream and just drop it in place as it comes in, the impact of program overhead would be minimal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!
Gadget Gangster - Share your Electronic Projects