How much memory do I need?

[Nrets]

Was thinking about this last night when I was falling asleep:

I have a project where I need to control 64 LEDs, serially (using latches), all from one just a few pins. All the data is sent via a single pin, shifted with another pin, and latched with a third pin. The problem is, these 64 LEDs will have maybe 360 different unique configurations that will be cycled through repeatedly. Just to do this, how much memory would I need for the code? So, 64 bitsx360? Maybe there are tricks in the programming though that would cut down on space...

Maybe the 16F628a won't have enough space. I may have to redesign the project using external eeprom.

 

[dknguyen]

Assuming each LED has only two states (on/off), that's 1 bit per LED. 64 LEDs means 64 bits to describe one configuration. Multiplied by 360 works out to 2.82KB of memory required plus code.

COde is really dependent on how you type it...I could make a program 1GB big that does nothing...it's hard to say.

You say you are going to have hardware external to the PIC that accepts a bit stream and allocates each bit based on the order in which it was received to set the state of a corresponding LED? If that is what you are saying, the PIC is doing nothing more than just setting an IO pin's value up and down based on a variable in memory- that's about the simplest thing to do in a microcontroller. I would guess that if you allocated 2.8K to the code you would have more than enough space...but I don't know what else you plan to do or the details of your system.

With the 16F628a's 3.5K, I think you should be able to pull it off. In my mind I don't see the code itself being more than two pages (at most). I'd hard-program produce an array for each configuration. Write a small function that spits out each array element over a pin sequentially and accepts the array as a variable. Then you just reuse the array in whatever sequence you want (plus some control logic to reset the latches, but those are realy only a few lines of code).

 

[Nrets]

Assuming each LED has only two states (on/off), that's 1 bit per LED. 64 LEDs means 64 bits to describe one configuration. Multiplied by 360 works out to 2.82KB of memory required plus code.

COde is really dependent on how you type it...I could make a program 1GB big that does nothing...it's hard to say. You say you are going to have hardware to read every stream of 64 bits sent to it and allocate each one based on order to a corresponding LED? That to me seems like really simple code if that's all it is...it's just setting an IO pin over time according to a bit stream stored in memory.

That's what I thought The code will probably not be too long, but the 3K for just the image data is pushing the limits of the PIC. I should probably consider using external memory.

Sorry, you edited your post while I was replying. The PIC16F628 cannot store 3K on its own, can it?


Nevermind, the 16f628 has 2K bytes? not bits, right?

 

[dknguyen]

3.5Kbytes, it has.
PIC16F628A

It'd be easiest to define all configurations into the source code and just hard program them into the PIC during programming.

 

[Leftyretro]

Was thinking about this last night when I was falling asleep:

I have a project where I need to control 64 LEDs, serially (using latches), all from one just a few pins. All the data is sent via a single pin, shifted with another pin, and latched with a third pin. The problem is, these 64 LEDs will have maybe 360 different unique configurations that will be cycled through repeatedly. Just to do this, how much memory would I need for the code? So, 64 bitsx360? Maybe there are tricks in the programming though that would cut down on space...

Maybe the 16F628a won't have enough space. I may have to redesign the project using external eeprom.

The desired status of 64 standard LEDs can be stored in just 8 byte variables in the program. Now how you control and manipulate the 64 single bit values is up to the programming algorithum you use.

Worst case where you want to have prestored constants of the 360 configurations would require 2,880 bytes of either program or data memory storage, which is more then the 16F628a and would have to be stored in an external EEPROM memory.

So is using pre-stored constants the only method of controlling the 64 LEDs that you can think of. What is the program suppose to do?

Lefty

 

[nickelflippr]

Build your code and compile with one pattern, then two patterns. You should be able to calculate code memory according to the difference. I would think a 16f648A would do it for sure with 4k of flash?

 

[Nigel Goodwin]

3.5Kbytes, it has.
PIC16F628A

But it's only 2K words - which is the important bit - you're confusing the issue by looking at the 14 bit words converted to 8 bit bytes.

As suggested, moving to the 648 with 4K would be the easiest way to solve the issue.

 

[Pommie]

You will probably have more success getting hold of a 16F88 rather than a 16F648. I have never seen a 648 but use the more modern equivalent (16F88) daily.

You could use the 628 by storing each pattern in 5 words but the code gets a little messy. <edit> No you can't as the 628 doesn't have writable flash.</edit>

Mike.

 

[blueroomelectronics]

Or any 18f PIC has 16 bit wide RAM (2 bytes) and easy to use tables.

 

[Nigel Goodwin]

You will probably have more success getting hold of a 16F88 rather than a 16F648. I have never seen a 648 but use the more modern equivalent (16F88) daily.

Is the 16F88 more modern that the 16F648?, I thought it was the other way round?.

 

[Pommie]

Is the 16F88 more modern that the 16F648?, I thought it was the other way round?.

I'm pretty sure it is. If I remember right, the 16f818 came out around the same time as the 16f628 and then the 16f88 came out much later. I designed a project about 5 years ago and used an 818 as the 88 wasn't available.

I just checked and revision A of the 16F88 data sheet was released Nov 2003. (weird thing is Rev B is dated Aug 2003!)

Mike.

 

[Nigel Goodwin]

Just checked the 16F648a and it's dated 2007 (latest update), but the Chinese datasheet is 2005, so presumably that's when it was released?

 

[Pommie]

I was looking at the revision history. The 16F88 data sheet has appendix A which has a revision history. The 16F648a data sheet doesn't have dates in the revision history section.

<edit> I remember now why I think the 88 is the newer chip. Writable flash and on chip debug facilities.</edit>

Mike.