Hacker News Reader

Comment by joe_bleau | Hacker News Reader

It can't be that hard; I once bitbanged a 30 pin SIMM on a PIC with an interrupt to trigger the refresh.

The 30 pin SIMM is 16MB and easy to wire (0.1" pitch). 16 MB of SRAM is probably going to be TSOP or worse, and probably in multiple packages. The multiplexed DRAM bus would also help with the pin count, but it's not clear to me that was a concern.

View on HN

The point was more than you can wire the SRAM to the address bus of the CPU with maybe a little GPIO logic for bank switching to expand the address space. The DRAM has to be done over GPIO (my count is 22 data signals) solely, with attention to timings and refresh.

And sure, I can see how it's done and announce it's "easy". But I'd be hesitant to try it. So if you've actually done it, bravo.

(edit: Among other things, how did you handle the case of your refresh ISR firing in the middle of a read cycle? Certainly can be done correctly, but it's a non-trivial (albeit software-side) problem to solve.)

I handled it thusly: while reading or writing RAM, interrupts are off. Between bytes read they are re-enabled. This means that the longest refresh delay is the length of a ram read/write. This is why my refreshes happen every 62ms and not every 64ms as the DRAM datasheet specifies - to allow me this leeway to be a bit late with the refresh.

Hm... sounds wrong to me. What if the software ends up spinning on the DRAM? You'll run with interrupts disabled pretty much all the time and miss your next refresh. You need to guarantee the timer, but not clobber a transaction in progress. You need to check a flag out of the DRAM access routine or something that tells you a refresh was missed and do it synchronously I guess.

The point being: it's non-trivial.

Please note what I said. I release interrupts after every byte READ/WRITTEN, so that the maximal delay to a refresh is the length of a single byte read/write. In case it wasn't clear, the only interrupt in use is the ram refresh interrupt. If it is masked, and triggers, it will execute the handler when it is unmasked. This means that even a loop on RAM read/write will not starve RAM of refreshes

[also, why do I keep being told I am submitting too fast, please slow down. I just posted 2 comments here, that is all. Had to make a new username :(]

> [also, why do I keep being told I am submitting too fast, please slow down. I just posted 2 comments here, that is all. Had to make a new username :(]

I think there is extra throttling on brand-new accounts, to help keep spam under control. Once your account is a little older it will be less restricted.

Also: welcome, and thanks for joining the discussion!

It's a microcontroller with no external bus, so you're bitbanging it either way.

I'm very impressed with his project!

Reply on news.ycombinator.com