How do I initialize a huge static buffer?

I'm currently working on my first really ambitious propeller project. Ironically, I'm making a propeller clock, like the one linked but larger. The thing is, at least for now, I just want to have one clock design in a buffer of, let me do the math... 5kBytes. How would you get that data into the ram? I don't want to call out a variable of BYTE clockFrameBuff[5160] and then in the main cog, during initialization set those bytes equal to the design of the clock. I'm concerned that would use twice as much space- wouldn't it? I could add a microSD, put the pattern into a file, and read in the data over SPI to fill the buffer on a loop. But that just seems... stupid.

Comments

  • Divide and conquer. You have 12 segments, 8 of which are identical and only have a few leds at the ends lit. That requires only or 2 bytes at most. The 4 positions that have different digits will require small lookup tables to display them. The three hands are an arrow head and line, so one lookup table for the arrow head and three bytes to specify the length of each hand.
  • I'm going to make my clock 96x419 resolution. Each frame is 12 bytes long, there are 419 frames around the entire clock. I want to have a program and toolchain worked out so that I could easily load new clock designs if I feel like it. The same can be said for the clock hands- I don't want to be limited to single lines, I want to be able to have an arrow or a zig zag resistor or just a floating ball, and have a buffer of like 12bytes by 31 frames to store the clock hand designs.
    
                            
  • jonesjones Posts: 281
    edited 2016-01-23 - 00:47:33
    Depending on what board you're using, there might be unused EEPROM space you could store the data in, then read it into ram at startup. I've not used C on the Prop but there's probably I2C routines, or even explicit EEPROM read/write routines that you could use. You might need to write a separate initialization program that does a one-time load of the data into the upper EEPROM, then load your application into lower EEPROM. As long as your data isn't in the first 32k of the EEPROM space it shouldn't be overwritten. If you have the space, you could store multiple clock designs and be able to change clock faces on the fly.

    Some Prop boards have only the minimum 32k EEPROM, others have 64k or larger.

    [edit] Oops. Since this was in the Learn subforum, I assumed you were using C.
  • You're using Spin, right?

    Why don't you just put it in a DAT block, maybe using the file directive?
    DAT
    
    data    file "filename"
    
  • gis667en11 wrote: »
    I'm going to make my clock 96x419 resolution. Each frame is 12 bytes long, there are 419 frames around the entire clock. I want to have a program and toolchain worked out so that I could easily load new clock designs if I feel like it. The same can be said for the clock hands- I don't want to be limited to single lines, I want to be able to have an arrow or a zig zag resistor or just a floating ball, and have a buffer of like 12bytes by 31 frames to store the clock hand designs.
    
    

    No reason that cannot be done while still using much less memory. You do not need to have all 419 frames stored, only enough frames to draw the hands, digits, and other markings needed for the clock face. BTW, how did you decide on 419 frames. I would have expected either 256, 360, 512, or 720. 360/720 because it is divisible by 60 and the display is circular, and 256/512 being an easy to work with binary number.

    Perhaps you could post a more detailed description of how you will be approaching this. Twelve bytes is enough data to control 96 leds unless you are using multiple bits to control the color or intensity of each led. That's a lot of leds to twirl.
  • Hey Jones- That's a good idea! I have a drawer full of 24C512 laying around and I'm working on the professional development board

    Hey Electrodude- I have not yet played with file directives. Is this within the context of an Eeprom data file like Jones suggested?

    Kwinn- You're right. There's a more elegant way to do it. More elegant and harder. There's always time to go back and add some recursive fancy handshaking program, but I need to get this done fast for a competition. I'm running off to dinner, but essentially I'm planning to have one Cog run a spin main program, one speak with a real time chip, one builds the working frame buffer from the base frame buffer design and the real time second minute hoiur registers, one detects the IR phototransistor pulse for 12 o'clock timing and speed calcs, one shifts out bits from working buffer to 595 shift registers.
  • gis667en11 wrote: »
    Hey Electrodude- I have not yet played with file directives. Is this within the context of an Eeprom data file like Jones suggested?

    The data would end up hubram. If you burn it to EEPROM, though, it will also end up in lower EEPROM like the rest of the program.

  • Thanks Electro, that's exactly what I was looking for.
  • gis667en11gis667en11 Posts: 73
    edited 2016-01-25 - 15:17:03
    Oh, and @Kwinn, I chose 420 divisions because it's the largest number less than 512 whose quotient of 60 is an odd integer. And because the 0 degree and 360 degree are the same position, there are 419 frames. I want my clock hands to have center lines for symmetricality, so each second is made up of 7 frames.
  • gis667en11 wrote: »
    Oh, and @Kwinn, I chose 420 divisions because it's the largest number less than 512 whose quotient of 60 is an odd integer. And because the 0 degree and 360 degree are the same position, there are 419 frames. I want my clock hands to have center lines for symmetricality, so each second is made up of 7 frames.

    Good idea. How many pixels are you going to have between the center and circumference of the clock face? Will the leds be rgb or single color?
  • gis667en11gis667en11 Posts: 73
    edited 2016-01-25 - 17:13:51
    @kwinn, they'll all be white LEDs with the very last being a colored LED. I might do single color or an RGB, I haven't decided. And I'm designing the propeller to have LEDs all the way to the center. I'm doing the math right now and realizing that, with 5mm LEDs, having 96 would mean a minimum diameter of almost 40 inches, so as I get closer to putting an order in for the shift register/ 8 LED pcbs (I'm going to panelize them on an order and then just jumper them end to end) I might go with either 64 LEDs or SMD LEDs and an SSOP/TSSOP 595 package to shorten the prop arm length.

    Yeah, I just ordered much smaller, surface mount 595's, 541's, and 100 SMD leds and resistors. It's crazy how cheap surface mount stuff is. I just got 5,000 150 ohm 1% 1206 resistors for $10, free shipping. And it looked like that seller had that kind of deal for every resistance. I will never, EVER need to buy another 150 ohm surface mount resistor for the rest of my life.
  • No wonder that Radio Shack went down. Was in need for a project and got 3 resistors for $1.50.

    Back to the original question. If you use the file directive as shown above you can access your array via byte[@data] and add the index.

    Having your 5k buffer in a separate file might be nice to change designs by simply changing one file and recompile/load.

    The file directive includes the file as a binary, not source. Since you just need 5K I think using the upper EEPROM is overkill.

    Enjoy!

    Mike
  • Yeah, I looked into the file directive- it looks fantastic. For the prototype I can enter hex by hand for 12, 3, 6, and 9, and the clock hands, into a hex editor and save it as a .dat file. In the future, I'd love to make, or find, a program where you can define a pixel space to draw on and have it output a binary file.
  • Can you just use a 420x96 bitmap?

    Use a paint program, like paint.net, and output an 8 bit bitmap. You will get one byte per pixel, and that can be filtered down to bit values pretty easy.

    Older paint programs will output 2 color bitmaps, which contain bit per pixel data. Strip the header, and it's close to ready to use.

  • I've been researching bitmap converter software- it turns out there's a file format called PBM, portable bitmap. There are a few variants, and PBM P1 is a monochrome image file format where black is saved as 1 and white is saved as 0. ImageMagick is a software I saw recommended, but I think any bitmap to PBM P1 converter should do really well. I could even design my clock numbers in photoshop and skew them to compensate for the radial distortion. Widen the base and lower the middle of the top :P Of course, eventually a circular / radial bitmap to pbm converter would be the ultimate, but I can't find anything like that.
  • potatoheadpotatohead Posts: 10,066
    edited 2016-01-25 - 23:09:25
    Paint.net has all that stuff!

    Here is your portable bitmap save plugin, ascii and binary http://forums.getpaint.net/index.php?/topic/27982-portable-anymap-filetype-plugin-pam-pbm-pgm-ppm/

    Get paint.net http://www.getpaint.net/download.html

    Here is a polar transform plugin: http://paint.net.amihotornot.com.au/features/effects/plugins/Distort/Polar_Transormation/

    I would start with your 480x96 bitmap, and drop your graphics in. Then transform that to view it in polar form. When you are happy, save the 480x96 bitmap off in the portable bitmap file, binary or ascii, and use file: directive to get it into the Prop.

    That transform works both ways, so you could also design the clock face and go the other way, resulting in that 480x96 bitmap...

    600 x 600 - 15K
    480 x 96 - 4K
  • Portable bitmap file
  • That looks like a fantastic took, potato. Have you built a propeller clock before? I'll give those tools a look.
  • @gis667en11

    Building the pcb's as 8 led modules is a good idea. At that size making it sturdy and balancing the the propeller will be critical. Placing it behind some protective barrier for testing is also a good idea. Having it fly apart at full speed might be a bit more excitement than you want.
  • potatoheadpotatohead Posts: 10,066
    edited 2016-01-26 - 04:08:42
    I've not, but it would be fun. I do know a lot about pixels and tools. Been doing things with bitmaps, including some automation sequencing if you can believe that, for a very long time.

    Paint.net is a tool Roy mentioned. I had been using a hodge podge of things for years. That one has an insane number of plug-ins and options. Worth learning to use, IMHO.

    Knew I could sort out a tool chain in a few minutes, figured it might save you a bit of time

  • I have a brushless DC motor that I got on eBay with a torque of 0.1N/m. I hope that's enough.

    And thanks again potato, I'll give paint.net a shot.
Sign In or Register to comment.