Shop OBEX P1 Docs P2 Docs Learn Events
fitting 35 bits into a long — Parallax Forums

fitting 35 bits into a long

CassLanCassLan Posts: 586
edited 2009-12-02 07:20 in Propeller 1
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)

·

Comments

  • heaterheater Posts: 3,370
    edited 2009-12-01 16:07
    Multiplex the long so as to make it look like it holds all the bits at once[noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • mctriviamctrivia Posts: 3,772
    edited 2009-12-01 16:09
    Not possible without compression.

    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.
  • AleAle Posts: 2,363
    edited 2009-12-01 16:11
    I can think of:

    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
  • heaterheater Posts: 3,370
    edited 2009-12-01 16:18
    Not possible with compression.
    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.
  • BaggersBaggers Posts: 3,019
    edited 2009-12-01 16:30
    If you're wanting to animate stuff onto it, you could possibly use some kind of delta rle.

    any more details on exactly what you want out of it?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • Mike GreenMike Green Posts: 23,101
    edited 2009-12-01 16:53
    There's no magic way to shoehorn 35 bits into a 32 bit LONG. All of the discussion about compression really assumes that you can, on average, make assumptions about which bits are on and which bits are off and the various compression schemes themselves take some bits, so you have to have even more assumptions so that you need to save more than 3 bits to account for the compression description information itself.

    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.
  • CassLanCassLan Posts: 586
    edited 2009-12-01 16:57
    Well, I wrote the routine that only lights up one of these LEDs at a time in rapid succesion giving the impression that all of the neccesary LEDs are lit at the same time.

    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)

    ·
  • jazzedjazzed Posts: 11,803
    edited 2009-12-01 17:12
    Can you use an array of bytes for the LED states? That would be just as fast as decoding the bit states in a long.
  • Nick MuellerNick Mueller Posts: 815
    edited 2009-12-01 17:46
    I googled for "RAM stretching" but found nothing usefull!
    But "bit stretching" found nice pictures. wink.gif


    Nick

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Never use force, just go for a bigger hammer!

    The DIY Digital-Readout for mills, lathes etc.:
    YADRO
  • kwinnkwinn Posts: 8,697
    edited 2009-12-01 17:59
    "IF" the bit patterns you want to display can be grouped so that one row or column in the group has all the leds on or off then it could be done. It might not be worth the extra code, time, and effort, but it is possible. Probably easier to pack all the bits in multiple longs.
  • BaggersBaggers Posts: 3,019
    edited 2009-12-01 18:02
    rofl Nick.

    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

    ·
  • rokickirokicki Posts: 1,000
    edited 2009-12-01 18:08
    Let's see; two bits make a quarter, and four quarters make a whole, and a hole is a charge carrier for one bits, so I think there's got to be a way.
    Just keep trying. Remember, invention is 99% perspiration.
  • Clock LoopClock Loop Posts: 2,069
    edited 2009-12-01 18:17
    Nick Mueller said...
    "bit stretching"


    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.
  • WurlitzerWurlitzer Posts: 237
    edited 2009-12-01 18:22
    Rick, if you don't mind off loading to an external chip, I use a ton of Allegro Micro UCN 5832A (there is a new version of this but the number escapes me) which are 32 bit shift register with latches with an open collector output good for 100ma ea. I use them in groups of 3's to control 96 outputs each.

    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.
  • Nick MuellerNick Mueller Posts: 815
    edited 2009-12-01 18:39
    > BTW no one mentioned just using a hammer to fit those extra bits into that word.

    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
  • Nick McClickNick McClick Posts: 1,003
    edited 2009-12-01 18:43
    How I think about it:
    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
  • rokickirokicki Posts: 1,000
    edited 2009-12-01 19:21
    There are other possibilities. You can pick up some additional bits from, for instance, the CNT register, or an external RTC. If you do this
    you can generate all 4B possibilities, just at different times.
  • JonnyMacJonnyMac Posts: 9,208
    edited 2009-12-01 19:41
    Keep in simple: define each animation cell as five bytes instead of a byte and a long. Yes, you're using extra bits but you'll make up for this in simplicity and speed of execution.
  • CounterRotatingPropsCounterRotatingProps Posts: 1,132
    edited 2009-12-01 19:50
    [noparse][[/noparse]EDIT - well Jon beat me to the punch [noparse]:)[/noparse] ... but note the vibes all on the same wavelenth! [noparse]:)[/noparse] ]

    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

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • VIRANDVIRAND Posts: 656
    edited 2009-12-01 21:14
    My first preference is to encode it as

    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
  • rokickirokicki Posts: 1,000
    edited 2009-12-01 21:38
    I concur with CounterRotatingProps; by the time you factor in instructions, just doing it the silly/stupid way (five bytes per)
    almost certainly beats anything else.
  • CassLanCassLan Posts: 586
    edited 2009-12-01 22:15
    hehe, wow this thread has really grown a bit since I last looked.

    Yeah I'm just gonna go ahead with the 5 bytes, no biggie : )

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    NYC Area Prop Club

    Prop Forum Search (Via Google)

    ·
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-12-02 00:28
    It seems a shame that it won't fit, but 'you cannae change the laws of physics'.

    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
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-12-02 01:45
    Drac: You have too much time on your hands. Isn't that someone on the floor waiting to be "jumped started". smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Beau SchwabeBeau Schwabe Posts: 6,568
    edited 2009-12-02 03:10
    CassLan,

    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.

    
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBB
    BBBBBBBBBBBBBBBBBBBBBBBBBBBBBAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBB
    BBBBBBBBBBBBBBBBBBBBBBBAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBB
    BBBBBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB
    BBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBB
    BBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBA
    
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBB
    BBBBBBBBBBBBBBBBBBBBBBBBBBBBAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBB
    BBBBBBBBBBBBBBBBBBBBBBAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB
    BBBBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBB
    BBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBB
    BBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    
    ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBB
    BBBBBBBBBBBBBBBBBBBBBBBBBBBAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBB
    BBBBBBBBBBBBBBBBBBBBBAAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBB
    BBBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAA
    AAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBB
    BBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBB
    BBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    
    
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Beau Schwabe

    IC Layout Engineer
    Parallax, Inc.
  • Nick McClickNick McClick Posts: 1,003
    edited 2009-12-02 07:20
    Obviously, this is an intellectual exercise - but it's an interesting one!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Forums RSS Feed!

    Gadget Gangster - Share your Electronic Projects
Sign In or Register to comment.