More RAM for low-end PIC?

[djulien]

I know there are PIC families with more memory, but part of the DIY fun is trying to squeeze the most possible from lower-end devices ...

Having said that, I'm finding that "just a little" more memory would make things a lot easier. So, I've been trying to think of ways to add some more memory to a low-end PIC (16Fxxxx). Something like around 1/2 - 1K RAM. Does anybody know of some neat tricks or fairly easy-to-use devices that can do this? (I'd like to avoid SMD for now). Or maybe it's not worth the effort, and I should just go ahead and "move up" to a fancier PIC?

just thinking out loud ...

I've read a little about SSRAM chips (but not actually used one). They seem like they are probably the smallest footprint and take the fewest I/O pins, but I'm wondering how much spare time the PIC will have left for other tasks if it has to be reading from memory often (even if a SPI/I2C PIC is used). Even though they use more I/O pins, would a non-serial SRAM chip perform better in the long run?

I've seen some circuits for interfacing to an SD card, but that seems like overkill (at least for now).

Another thought was to connect multiple PICs together, and use some data interchange pins between them. That would work, but the complexity goes high if I ever needed more than 2 of them. OTOH, if I also need a bunch more I/O pins, that would serve both purposes.

For infrequently updated data, I suppose copying the data to the PIC's EEPROM would basically double the amount of memory. Or, if any of the 16F PICs allow self-updates of flash memory (I think I saw one that did, but maybe I was mistaken), it could copy the data to flash memory I guess.

Are there any other good ways, or if anybody has used the above techniques, how hard was it to get them working?

thanks

don

[P. Short]

Make it easy on yourself and move up to a PIC with more internal memory. The cost isn't that much more relative to the overall project cost...

[scorpia]

i agree with phil, moving upto a bigger pic is the easiest way to go . if the money that you would put into any ram chip was added to the cost of the pic i think you would find you will be better off with a larger pic.

Also there are other advantages of the larger pic such as greater speed, more features etc.

In the pic range the 18f series has alot of advantages over the 16f series, and there are even a few dip parts in the 24f range.

although some of the new 16f range of pics are worth looking at as well. Im very happy that phil put me onto the 16f72X range of pics. cheap as chips with lots of features, ram rom etc.

[P. Short]

Insomnia strikes...

There is another possible reason for selecting the most capable processor that you can find. It is possible to use the charlie-plexing scheme at the scale that you've been mentioning and yet keep the number of dimmer levels high (around 128-256). This scheme would require a fast processor, possibly either one of the Atmels or a PIC24-series part (or faster). It also would need buffer transistors similar to those that were referred to in post #29 in this thread:

http://www.doityourselfchristmas.com/forums/showthread.php?t=5456&page=2

The basic idea here is to consider an alternate way of viewing charlie-plexing from the mess of diodes shown in the Microchip app note. This other way of viewing charlie-plexing is to consider a n+1 by n+1 array of diodes, with the diagonal diodes left off. The total number of diodes is then n * (n+1), the same as in charlie-plexing. Each of the n+1 outputs from the micro is connected to one row of the matrix and to one column of the matrix. In this scheme the micro controls n of the diodes at a time, by driving one output low (to enable a column in the array) and setting the other n outputs either high (to turn a diode on) or to the tri-state condtion (to leave the diode off). If each diode is driven for the 2 uS mentioned in the other threads, it takes 2 * (n+1) uS to control all n * (n+1) diodes (34 uS if n=16, for example). This would allow 128 dimmer levels if n=31 or 32 or 256 dimmer levels if n=15 or 16.

The biggest down-side of this scheme (apart from the intricate coding that would be needed) is the huge amount of current needed by the column driver in the above scheme. If there are 32 diodes (LEDs) in each column and each one needs 25mA then you would need up to 800 mA of drive current, well above what a PIC output can do. Thus the need for buffer transistors as mentioned above.

This scheme needs very fast micro-controllers. This may be hard to find, because the parts that can directly drive 25 mA (for driving the rows in the scheme above) are relatively slow (the PIC16F and PIC18F parts).

So, this is another tradeoff - hardware costs versus more levels of dimming.

[scorpia]

phil,

let me start off by saying i dont now much about charlie plexing, I was assuming it meant only turning on 1 led at a time. by using a combination of high and low pins on the micro.

but you mentioned that the micro drives 1 row (800ma) , this to me doesnt make sense. but it is probably just my knowlage of charlie plexing.

peter

[P. Short]

phil,

let me start off by saying i dont now much about charlie plexing, I was assuming it meant only turning on 1 led at a time. by using a combination of high and low pins on the micro.

but you mentioned that the micro drives 1 row (800ma) , this to me doesnt make sense. but it is probably just my knowlage of charlie plexing.

peter

I think that you have been thinking about it the same way as everyone else on the board (myself included), because the Microchip app note doesn't encourage thinking about it any other way.

[djulien]

Insomnia strikes...

Reading specs can be a good cure for that. :)


The basic idea here is to consider an alternate way of viewing charlie-plexing from the mess of diodes shown in the Microchip app note. This other way of viewing charlie-plexing is to consider a n+1 by n+1 array of diodes, with the diagonal diodes left off. The total number of diodes is then n * (n+1), the same as in charlie-plexing. Each of the n+1 outputs from the micro is connected to one row of the matrix and to one column of the matrix. In this scheme the micro controls n of the diodes at a time, by driving one output low (to enable a column in the array) and setting the other n outputs either high (to turn a diode on) or to the tri-state condtion (to leave the diode off). If each diode is driven for the 2 uS mentioned in the other threads, it takes 2 * (n+1) uS to control all n * (n+1) diodes (34 uS if n=16, for example). This would allow 128 dimmer levels if n=31 or 32 or 256 dimmer levels if n=15 or 16.


I think I saw a variant of this - divide the I/O pins into 2 groups. The first group uses charli-plexing to enable a row, and the remaining group drives the columns directly instead of using charlie-plexing (or they could also use charlie-plexing as you described). The row group does not need to be the same size as the column group, so you don't need to use a square matrix, though. There would be fewer controlled cells this way, but it would allow the amount of current that each pin sees to be tuned more easily.


The biggest down-side of this scheme (apart from the intricate coding that would be needed) is the huge amount of current needed by the column driver in the above scheme. If there are 32 diodes (LEDs) in each column and each one needs 25mA then you would need up to 800 mA of drive current, well above what a PIC output can do. Thus the need for buffer transistors as mentioned above.

If there is spare scanning bandwidth available, maybe only turn on some of the columns at a time, to reduce the simultaneous current consumption. But I think that would basically be the same as moving some pins from the "column group" to the "row group".


In the pic range the 18f series has alot of advantages over the 16f series, and there are even a few dip parts in the 24f range.


i agree with phil, moving upto a bigger pic is the easiest way to go . if the money that you would put into any ram chip was added to the cost of the pic i think you would find you will be better off with a larger pic.

I was actually more concerned about the learning curve and cost of programmer + compiler.

I've seen a bunch of docs from Microchip about the other families, but it looks like there is a lot of info to wade thru and I didn't know where to start. Do you know of a simple guide on how to "move up", maybe from the perspective of from PIC16x to PIC18x, which programmer to get, which compiler to use (hopefully a free one), etc?

don

[P. Short]

I'm not sure what you are trying to say here, unless you are just describing the standard LED matrix techniques. Also, both of the last two quotes are from scorpia, not myself.

[P. Short]

I probably should have started a new thread, rather than hi-jacking this one.

Anyway, here is a 3x4 charlie-plex schematic, drawn in such a way as to make the connection with the standard LED matrixing scheme more evident. It may not look the same as the schematics in the wikipedia article http://en.wikipedia.org/wiki/Charlieplexing and the microchip app note http://ww1.microchip.com/downloads/en/AppNotes/00234a.pdf, but it is functionally the same (except that the resistors are connected slightly differently in my schematic).

[djulien]

I'm not sure what you are trying to say here, unless you are just describing the standard LED matrix techniques.

I misunderstood what you were saying. I thought you were saying that the number of rows and columns of the matrix always needed to be equal, so I was trying to say that the matrix doesn't strictly need to be square, and that trading off columns for rows could be used to ease the power requirement on the row drivers since that depends on the row width, basically.


Also, both of the last two quotes are from scorpia, not myself.

I messed up the text during editing, sorry about that.

don