The linked blog post misses the interesting bits. Yes, it boots Ubuntu (slowly) via an ARM emulator written for AVR. That's just software.
What struck me is that he wrote a controller for an 8 bit FPM DRAM bus instead of just using a big SRAM. That's surprising, and not at all trivial to do over a bunch of GPIO pins.
You have to periodically refresh DRAM. That's what the dynamic means in DRAM. If you don't, the memory will "forget" what it's holding. This is because the memory cell is essentially a capacitor.
SRAM would be easier because it's set and forget. It needs a more complex internal circuit, and therefore more expensive.
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.
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.
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!
Yeah, that is actually a pretty awesome bit of engineering. I would never have thought of this, and it is exceptionally clever in some exciting hacker way.
Comments
The linked blog post misses the interesting bits. Yes, it boots Ubuntu (slowly) via an ARM emulator written for AVR. That's just software.
What struck me is that he wrote a controller for an 8 bit FPM DRAM bus instead of just using a big SRAM. That's surprising, and not at all trivial to do over a bunch of GPIO pins.
Would love a more extended explanation of what this means and why it's surprising, for a this software geek who dabbles in hardware.
You have to periodically refresh DRAM. That's what the dynamic means in DRAM. If you don't, the memory will "forget" what it's holding. This is because the memory cell is essentially a capacitor.
SRAM would be easier because it's set and forget. It needs a more complex internal circuit, and therefore more expensive.
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.
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!
Yeah, that is actually a pretty awesome bit of engineering. I would never have thought of this, and it is exceptionally clever in some exciting hacker way.