More read-only memory for a small-ish PIC?

[Hippogriff]

Hi,

My PIC of choice, at the moment, is the 16F1825. I am interested in understanding the basics of how I might access more read-only storage for this PIC. I am working with the WS2812B RGB LED rings (and strips) and I am thinking of programming in lots of effects and routines. I've not yet figured out if I would blow the capacity of the PIC, I've always limited myself to what is available before, but I reckon there's a good chance as I build up more and more effects.

I'm asking this question here because I'm positive many of you will have done this before and will know the ins-and-outs, the challenges and hurdles, that come with doing this... what devices have people used in the past to add extra capacity to a PIC? For my purposes, I doubt it needs to be blazing fast, I will not read to write to it once it's set up and it will need to be persistent across power cycles. You might think a little SD card and reader... but I was initially thinking more along the lines of a separate IC. A neat and simple interface between the PIC and the extra offboard storage would be a great boon.

Any thoughts, advice or pointers / guidance will be appreciated.

 

[Ian Rogers]

How much extra storage? You could have a serial EEPROM externally up to 1Mbit.... That's 256k..

Or do you need more.

 

[Hippogriff]

Oh, no - that would be plenty, I'm sure, you've got to have some limit. A serial EEPROM sounds interesting... any IC model number I might take a look at?

 

[Nigel Goodwin]

There are plenty of I2C and SPI EEPROM's available - most I2C ones are numbers like 24L256.

 

[Ian Rogers]

I use I2C bus EEPROM's.... 24c256.. This gives 32k... Another choice... The pic18f2685 has 96k of program memory!

 

[Overclocked]

Just take a quick look on the Microchip Website, They've got plenty. You can even find external flash (512kb and above), but they have EEproms in anywhere from 1kB to 1Mb. They also use a common interface, I2C or SPI. I personally like I2C But it can be a slight pain because you need pull up resistors. SPI is simpler (think shift register) but the command structure varies from manufacturer to manufacturer.

 

[Hippogriff]

Thanks... 96K would be nice, what's the largest capacity PIC with 14 pins? I'd rather avoid a physical beast if possible. Is it 2K? Where I'm at with the 1825?

 

[Ian Rogers]

The pic16f1825 has 8k of memory!.... There is a pic24 but that only has 4k... all the rest have 2k..

 

[Overclocked]

If you go SMD then theres not much difference between a 20 and 28 PIN. According to the Microchip website, the largest program memory a 14 Pin PIC has is 14Kb. The 18F2410 (28 Pin) I have been using has 16Kb of Prog Memory.

 

[Hippogriff]

Apologies, a misreading of the PIC product selector thing... I want to store volumes of byte arrays - chunks of 24-bit colours that I can use as a starting point for an effect, then use code to move them around programmatically.

 

[Pommie]

I used to write computer games and the early machines had 32k storage. We wrote fabulous games in that 32k. If you just want to animate an LED string then you should be able to do it on a pic chip without external storage. If you need to go to external storage then you're doing something wrong.

Mike.

 

[kubeek]

Are such small PICs even capable of executing code from external storage?

 

[Hippogriff]

Hang on... I've maybe placed a red-herring in here... it's data I want to access... well, byte arrays (various, at least, 24 x 3 byte arrays) for starting effect positions. If I have a single "var byte Effect[72]" declared in my program then the Data Usage of my PIC in JALEdit goes up to 81%... doesn't this mean I'll not be able to fit much more in?

I want them to be var byte[] so I can tinker with the values inside the array and then blast them out (24 x 24 bits), in a very tight loop, to the WS2812Bs. If I mess around with the values while blasting out the details, then the timing is off and the LEDs fail to light. Yes, you can easily create some starting positions all in code and go from there... but I definitely think that I'll want access to a number of 24 x 3 byte arrays as good effect / pattern placeholders.

Do excuse me if I'm not explaining things correctly... I'm only just starting to think of all the things I want to do with these LEDs.

 

[Hippogriff]

I used to write computer games and the early machines had 32k storage. We wrote fabulous games in that 32k. If you just want to animate an LED string then you should be able to do it on a pic chip without external storage. If you need to go to external storage then you're doing something wrong.

Mike.

BTW... I also want to investigate how to go to external storage... that's part of it.

 

[Nigel Goodwin]

Are such small PICs even capable of executing code from external storage?

No one has suggested any such thing - and no they aren't

Reading data from an external chip is perfectly fine though, and what's required here.

 

[Gobbledok]

Microchip has up to a 64Mbit flash that I know of (sst25vf064c), you should have plenty of storage.

If you do end up using internal flash you could save space by storing the patterns/colours etc in RGB565 (for example) and then converting them to RGB888 before sending them.

 

[Hippogriff]

OK, I just ordered a few 24LC256s with my Mouser order... got me over the 'free' shipping threshold (with an added big breadboard)... I like bread.

 

[Hippogriff]

I used to write computer games and the early machines had 32k storage. We wrote fabulous games in that 32k. If you just want to animate an LED string then you should be able to do it on a pic chip without external storage. If you need to go to external storage then you're doing something wrong.

Mike.

First off - I've made a crap error with the PIC I'm using - I'm currently working with a 1823 - not a 1825. I do have some 1825s on order but they're not here yet. I had one last week... but I destroyed it (accidentally).

So I would add that with my PIC16F1823 and JAL I have 112 bytes of data space... 32K would be lovely! I'd ideally like to have a variable array of 72 bytes to hold the individual R, G, B values for the 24 LEDs on a WS2812B ring... however, those 72 bytes consume a large proportion of what appears to be available to me, meaning if I add even a few more variables the compiler is giving me an out of data space error. The 16F1825s I have on order, will give me 1,024 bytes of data space. Heady heights!

 

[Ian Rogers]

I'm kinda lost with this thread..... You keep talking about data.... If you need to store bytes, surely you need them in program space.... Are you building your array's dynamically... sort of pseudorandom???

 

[Hippogriff]

Well, um... maybe you tell me?

When I declare the following in my program...

const byte Values[72] = {blah,blah,blah...}

...it uses up program space... so, on my 1823 it uses up some of the 2,048 bytes I have (not much, obviously). But I don't want a const byte array... I want a variable byte array and when I declare...

var byte Values[72] = {blah,blah,blah...}

...it uses up the 128 bytes I have in data space. And by declaring that I am very quickly to the limits of my data space [on the 1823, the 1825 will be different].

I want to be able to have this 72 byte array - initially with some values set - and then change it dynamically within the program. That controls the values sent to my 24 long string of WS2812B LEDs. So I guess I'm not building it dynamically... it's already there, but I'm certainly changing it and it can't be a constant array of bytes.

Does that help? Am I barking up the wrong tree?

Apart from that specific issue, I did want to dig into the idea of using offboard storage as a means of self-educating... hence the reason why I bought some ICs.