Muxing ram between two MCUs for dual framebuffer rendering - Page 1
Forum section: electronics / projects

author: cteffects
author_rank: Newbie
timestamp: January 19, 2016, 05:08:31 pm
content: Hey all,I've been wanting to make a simple rasterizer hardware for fun, and I want it to have two ram ICs (front and back buffer) shared between two between two MCUs (one to draw and the other to generate the video signal).However, I'm unsure how to mux the ram ICs together without compromising the signal (or if that will even be a problem). The ram chips each communicate with a SPI interface.I've included a crappy diagram of what I'm talking about.Thanks in advance

author: kfitch42
author_rank: Frequent Contributor
timestamp: January 19, 2016, 05:52:20 pm
content: One way to solve this is to push the complexity into the RAM chip. You can use "dual port RAM" which will essentially have two sets of data and address lines (one for each micro). Go to digikey, select:Product Index > Integrated Circuits (ICs) > MemoryThen under "Memory Type," scroll down till you see stuff starting with "SRAM - Dual Port." Then have fun digging through data sheets until you find the right one for your project.

author: cteffects
author_rank: Newbie
timestamp: January 19, 2016, 06:48:31 pm
content: Quote from: kfitch42 on January 19, 2016, 05:52:20 pmThat definitely looks to be the proper way to solve the problem.However, looking at the prices for comparable ram ICs, the costs increase by at least an order of magnitude. Plus, I already have a bunch of single port ICs sitting in a drawer and was hoping to use those. Since this is just a one-off hobby prototype, I don't really care about elegance.That's really good to know those exist, though.

author: SebG
author_rank: Regular Contributor
timestamp: January 19, 2016, 07:16:59 pm
content: HiSince you want to use SPI ram devices what you can do is connect them to both MCUs but multiplexing the clock say bu using an OR gate. The data Out (from MCU) and Data In (Out from RAM) should use open collector drivers. Then one MCU should have priority like the Video Driver. So you can use 2 pins between the MCUs to generate permission to use the SPI bus. For example, the Video driver sends pulls high a pin to indicate it is using the bus. If the other MCU needs to use the bus it pulls the other pin high to indicate the Video driver it is next to use the SPI bus so when the Video driver is done using it, it will pull its output pin low and wait till the other MCU is finished before it takes control again.Let me know what you think of this setup.

author: jbix
author_rank: Newbie
timestamp: January 19, 2016, 07:45:00 pm
content: Ran across this on the Microchip forums during a quick google search.http://www.microchip.com/forums/m482096.aspxThis seems to be pretty much in line with what Sebastian says. You need a way for the to MCUs to coordinate who has control. The MCU that is not in control should release the SPI pins if TRI-STATE.

author: FrankBuss
author_rank: Unknown
timestamp: January 19, 2016, 08:22:30 pm
content: If your MCU have 2 SPI buses, which can be configured to tri-state at runtime, it is easy: Connect both SPI RAMs to both SPI buses of one MCU, and the other MCU. The video signal MCU generates a signal which RAM it is using, and the renderer MCU reads this signal to access the other RAM meanwhile.

author: cteffects
author_rank: Newbie
timestamp: January 19, 2016, 08:27:36 pm
content: Quote from: SebG on January 19, 2016, 07:16:59 pmI was hoping to use two independent RAM chips that would alternate roles between read-only and write-only so the video signal generator would have full read access to the finished frame on one chip, while the rasterizer MCU is simultaneously busy drawing to the other framebuffer. Then when the frame is done drawing, the signal lines would swap, and the signal generator MCU would start reading from the other.It seems with this method, there would be a good amount of dead time waiting for ram access on the rasterizer MCU side, because it doesn't seem to fully implement a dual framebuffer.

author: cteffects
author_rank: Newbie
timestamp: January 19, 2016, 08:46:56 pm
content: Quote from: FrankBuss on January 19, 2016, 08:22:30 pmOh my god, that's the perfect solution! Thank you! My MCUs have 2 SPI lines, so this will work perfectly.

author: kfitch42
author_rank: Frequent Contributor
timestamp: January 19, 2016, 09:20:17 pm
content: Quote from: cteffects on January 19, 2016, 08:46:56 pmThat is a reasonable approach, but I would suggest turning around the control of which RAM to use when. When the renderer MCU is done with a frame it should signal the video signal MCU. Remember that after a swap the data in the RAM the renderer is using isn't the data it wrote a moment ago, it is from the previous frame. If the video generator was in charge, then you would need to guarantee the rendering NEVER took more time than the video refresh interval. Otherwise the video signal MCU would be displaying a partially rendered frame, and the renderer MCU would need to give up on the frame it was in the middle of and start over. That just sounds messy on multiple levels.There is still the outstanding question of whether to wait for vertical retrace or just horizontal retrace (or no waiting?) for the swap. In part this will depend on how fast you can switch modes. In either case you probably want the renderer MCU to signal, and the video MCU to acknowledge to prevent any possible bus fighting.

author: cteffects
author_rank: Newbie
timestamp: January 19, 2016, 09:35:19 pm
content: Quote from: kfitch42 on January 19, 2016, 09:20:17 pmI was thinking about having a pin on the rasterizer to signal when it's done with a frame, and a line on the signal gen to go high during vblank. If both are high, then it's safe to swap buffers. The first line would go to any GPIO on the signal gen, and at the end of the vertical retrace, that pin would be sampled. If low, then redraw the same frame. If high, then signal an interrupt to the rasterizer to swap buffers and both would swap at the same time.There would be (relatively) minimal down time for the rasterizer to wait for vblank after drawing, since it's going to be orders of magnitude slower than the signal gen anyway.