Clocks and Interrupts
Today I moved a few steps closer to completion of the initial hardware design. First, I verified that BMOW’s interrupt mechanism actually works. My previous experiments with the keyboard and USB employed busy loops to continuously poll for new values. Although I had built in support for an interrupt line from the beginning, I never actually tested it until today. Luckily, it works fine. When interrupts are enabled, and a device signals an interrupt request, the next time an instruction is fetched from memory it will read zero instead of the instruction opcode. Opcode zero is the “break” instruction, which saves the current register contents and jumps to an interrupt service routine whose address is stored in a dedicated trap vector. The ISR then queries each device to determine which one generated the interrupt, and handles whatever work needs to be done. Finally, an RTI (return from interrupt) instruction restores the register contents and re-fetches the instruction that was interrupted.
As a simple test, I rewrote my earlier keyboard editor demo to use interrupts for the keyboard rather than polling. I had the main program print a continuous series of dots to the LCD, while the interrupt service routine decoded keyboard input and echoed the key to the LCD. It worked as you’d expect: a continuous series of dots that got intermixed with other letters if you typed at the keyboard.
The second task of the afternoon was to add BMOW’s real-time clock. I’d previously planned for the RTC and incorporated it into the design schematics, but hadn’t actually connected the hardware until now. I’m using a Texas Instruments BQ4847 integrated RTC module with a built-in battery. The RTC enables BMOW to know what date and time it is, which is nice, but its more important use is as a programmable interrupt timer. I plan to use a repeating RTC timer interrupt with a period of 1ms or so as the basis for multi-tasking in the OS. Each time the interrupt hits, the ISR will suspend whatever program was running, restore the state of another previously suspended program, and return. As long as programs are time-sliced rapidly enough, and all the relevant machine state is preserved when a program is swapped in and out, it should appear as if all the programs are running simultaneously.
To test both functions of the real-time clock, I configued an interrupt to trigger every 1 second, and an interrupt service routine to print the current date and time.
One other interesting feature of the RTC module is its ability to turn a separate static RAM into a battery-backed SRAM. The RTC’s Vout pin can be used to provide power to an SRAM from the clock battery when the system power is off, preserving the SRAM contents. The RTC will also write-protect the SRAM by forcing its chip-enable input to false when the system power is in transition or off. It would be pretty easy to convert BMOW’s existing 512K SRAM to a battery-backed RAM this way, or to add a second 512K battery-backed SRAM. A second battery-backed RAM would be a simple way to add a small “disk” to the machine, instead of specialized hardware to connect to a compact flash or SD card, or a real hard disk.
In other news, I updated the “Technical Info” page with more details, so check it out.
Edit: I just noticed that I set the RTC for “Saturday May 30, 2008”, which is a non-date given that today is actually Saturday May 31. It’s interesting that the RTC didn’t barf on it. It must take the day of the week as an input along with date and time, rather than determining the day of the week from the date.
Read 8 comments and join the conversation8 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
What an interesting project. I keep toying with building something broadly similar myself, but haven’t actually got as far as a buildable design yet.
Battery-backed RAM is very handy if you haven’t any other form of secondary storage. You have to be careful with it, though. The main problems arise during the transitions between the powered and battery-backed states. What if your software is in the process of writing a block of data when the power goes?
A previous 68008-based design of mine had a small bootstrap in ROM, and the main program plus some other parameters in battery-backed RAM. In this case, I added a input so the processor could detect when the voltage on the power supply smoothing capacitors was below a certain threshold. When I wanted to write to the RAM, I would check this input. If the voltage was high enough, there was sufficient energy to complete the block write operation regardless of whether or not the external power supply were removed. I didn’t have any corruptions despite the power supply being switched off unpredictably.
If you have a simple power supply with linear regulators, this sort of thing is easy. I just used an NPN transistor and some resistors. It’s a bit trickier if you are using a mains switching suppy. You can measure the 5V supply, but by the time this starts to drop, you’ll not have very long. You can buy fancy power supply monitoring chips for this sort of thing if you like. Most are surface-mounted, so for hobby projects a simple discrete design has certain advantages.
Good luck with the project!
Merlin
Hi Merlin, thanks for your ideas!
I see the potential for problems with the battery-backed RAM that you describe, but is that unique in some way to battery-backed RAM? It seems that you’d have the same problem if you lost power during a write to a standard disk, or flash card.
My simple answer is to not turn off the machine in the middle of a write to the RAM-disk. Possibly the machine would need to terminate to the “halt” state before it would be safe to power-off. This seems to be how Windows machines work: you can’t just kill the power, but instead you have to cleanly shutdown to avoid data corruption.
To protect against corruption due to accidental power loss, the BQ4847 does have the kind of voltage-sensing circuitry that you described. When the supply voltage drops below about 4.4 volts, it waits for any in-progress access to the RAM-disk to complete, and then disables the RAM’s chip-enable so it can’t be written to. So the write of a single byte should be atomic, and will either occur or not occur, but you’ll never see a corrupted byte written.
It should be possible to write some kind of file system that avoids data loss by relying on the atomicity of writes. For example, when writing a new version of an existing file, it would write it to a new area of the RAM disk rather than overwriting the existing area. Then it would update the entry in the file table containing the offset to the start of the file (assuming this were a single byte). So if the power failed, you’d end up with either the old or new version of the file, but not some garbled version of both. Does that sound workable?
You are quite right in that this problem affects any kind of non-volatile storage. I believe hard disks have some protection against this – they won’t start a sector write unless they can complete it. Hence the “atom size” becomes a sector.
It might be tricky to construct a filesystem that is completely resistant to being stopped at any time. File pointers etc. are likely to be more than one byte, which means the writes are no longer atomic. Also, if you overwrite an existing file, you can’t re-use the space occupied by the original version until the new one is complete. An interesting idea, though.
You could implement a “shutdown” command or similar that would perform any pending writes before asking you to switch it off. My project ran in a car, where power may disappear at any time. Of course you might have a power cut, or knock the plug out of the wall, but the probability of that is probably low enough to ignore.
well, depends on how quickly you lose power, with enough backup, you could safely have enough time to determine that you are losing power (10% or so drop), and then save everything and/or halt the system before it drops below 50%
Think large capacitors! (btw, nice RTC + interrupts!)
Thanks HL-SDK. Yes, I think you and Merlin are suggesting something similar. That would give you atomic writes at a per-block level, instead of per-byte. But either way, you’re going to have to deal with the problem of losing power before a file write is finished.
I think I’ll take a stab at designing a file-system specification that is tolerant of power loss during writes, all the way down to the one byte level. Then I’ll post it up here for comments.
I think someone already suggested this, why not have a capacitor that can power the writing system for however long is needed, in case of a shutdown. Maybe some battery powered circuit detects if power is cut off, and then it allows the capacitor to dump power, which was charged up while the power was flowing.
Detecting a power drop and doing something smart during the few milliseconds (?) before there’s not enough power makes good sense to me. By “something smart” I mean making sure that any pending write operation either completes, or doesn’t, but doesn’t leave the disk in some half-way, bad state.
I’m not too excited about using a battery or capacitor as an alternate power source to keep the machine running until the file is fully written. It’s more hardware that shouldn’t be needed with a well-designed file system, and I’m not sure it’s even possible, really. Making sure that a pending write operation completes is far different from making sure that the entire file being written is finished. There’s no bound on how long it might take to write the entire file: imagine if each byte being written required some difficult calculation. And if the power can fail any time while that file is being written out, then you still need to design the filesystem to be tolerant of such errors, which is what you’d need to have done anyway if you didn’t have a backup battery or capacitor.
The only significant difference a backup power source might make, I think, is that you could guarantee a larger size of atomic write, like maybe 256 bytes instead of 1 byte. That would make the design of the filesystem easier, but I don’t think it’s a huge difference either way.
I looked into the idea of a fault-tolerant filesystem further, and even got it half-way implemented, before I convinced myself that it wasn’t worth it. From what I’ve been able to determine, none of the common filesystems for Windows or Linux are fault-tolerant, and nobody seems to be upset about it. You can use special journaling filesystems to get fault-tolerance, but they sacrifice some performance, and even then they aren’t 100% guaranteed. So I think I’m going back to the original plan of simply requiring a clean shutdown. If power is lost in the middle of a file write, you might still be OK, but you’ll need to keep backups on hand to be sure.