0
\$\begingroup\$

Suppose I have 512 leds in a 16 by 32 grid. I want to control what is displayed on the grid.

To do this suppose I have a timer counter that is constantly counting between 0 and 31 in binary. This timer is hooked up to 2 things. The first is a decoder so that one column of the LEDs is "activated".

The second is a kind or RAM (I don't know what to call it), which has 16 bit words and 64 addresses. The timer is hooked up to the bottom 5 bits of the addressing system of the ram, and the LED grid is hooked up to the outputs.

The Micro controller is then hooked up to the top address bit so that this system can have two separate memories to grab data. One is active while the micro writes to the other memory locations.

Here is a simplified schematic (obviously I will have transistors and what not where needed):

Led controller circuit

My question is: What can I use for the RAM memory? And what is it called?

Some requirements:

  • Can be read at 32kHz
  • Has at least 64 words with a word size of at least 16 bits
  • Can be writable while still reading other memory addresses
\$\endgroup\$
1
  • \$\begingroup\$ SRAM (Static Random Access Memory). Specifically some dual-port variety. Google will find you something (e.g. "dual-port SRAM") \$\endgroup\$ May 21 '16 at 15:09
1
\$\begingroup\$

You will need some SRAM. You could use DRAM, but that would require additional controllers and be way overkill as you don't need all that much capacity. SRAM on the other hand is much simpler but with lower density (less memory per chip), but again as you only need 128bytes of RAM, that is tiny.

If you want to read while writing, you need a dual-port variant. These have basically two address buses so you can access two different values at the same time. For simple dual-port memories, one is a read address, the other is a write address - so you can read from one port and write to the other port independently. There is such a thing called a true dual-port memory, which has two completely independent read/write ports, but you probably don't need that, and it will be harder to come by anyway.

Given you are using it as a frame buffer, you'll need it to be parallel (serial SRAM isn't going to cut it). You can either look for 16bit wide memory, or 8bit wide - if it is 8bit wide, you can simply wire up two of them with the same address and control lines and you have a 16bit wide version.

Basically go looking for a 8 or 16bit wide dual-port SRAM memory with sufficient depth for what you need (doesn't matter if it is deeper than you need, you just don't use the extra words). Pick any search engine or distributer website and start looking - shopping questions are off topic, so I'm not going to go looking for you.

\$\endgroup\$
0
\$\begingroup\$

You mention that you will be using a microcontroller. I would abandon the idea of using a dual bank RAM in the LED matrix refresh circuit and instead simply use RAM inside the microcontroller which the software can output one location at a time to a bank of port pins that drive the LED column bits. This also simplifies the design because it is no longer necessary to have an external counter as column address can simply come from another bank of port pins.

If the microcontroller you are currently using has limited resources to support this idea then consider simply adding a second MCU that takes the job of supporting the display refresh. Low end microcontrollers capable of doing this type of job are readily available at less cost that the batch of components that you have already charted out in your diagram. The display data can be sent from the main MCU over to the other one via a TTL UART connection or I2C.

If the idea of using the dedicated logic at low frequency is really a design strategy that you want to keep then I could recommend that you look seriously at implementing all of the logic in a smallish FPGA. There are FPGAs that contain embedded SRAM arrays that can be setup with dual ported behavior just as you describe. I've done some designs like that using a SPI interface to load data into the internal RAM which is then scanned and used for the internal functionality. My designs use a 50MHz clock but there would be no reason that an FPGA could not be clocked at a low frequency rate.

\$\endgroup\$
3
  • \$\begingroup\$ Only problem is that I am trying to do this all at under 9kHz.....which is to avoid FCC testing. That was my original idea when I was running at 16 MHz (which was easy then) \$\endgroup\$
    – DarthRubik
    May 21 '16 at 16:21
  • \$\begingroup\$ @DarthRubik - Well that is your call on the product design philosophy then. Realistically I think that trying to bend a product design around avoidance of agency testing requirements is not a good strategy. The market place just does not support the wide selection of medium complexity components for such types of designs that it may have even 10 or 15 years ago. In addition the increased BOM cost is something you pay for on every unit you produce whereas the cost of agency testing is not a recurring cost. See my added comment to the answer for a viable alternative. \$\endgroup\$ May 21 '16 at 16:51
  • \$\begingroup\$ I only plan to sell under one hundred of them....so at least for the short run it is cheaper this way.... \$\endgroup\$
    – DarthRubik
    May 21 '16 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.