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.
back
1 comments
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!