Sunday, November 15, 2009
Wednesday, November 4, 2009
RainDance - Sprinkler Controller
I am nearing completion of my first actual brought-to-completion microcontroller project. The application: to control sprinklers and drip hoses in the back yard through a web interface, with multiple timers for each valve and power back-up. This was accomplished by creating a custom electronic platform, along with a dynamic website for the user interface.
Hardware
The hardware consists of a SitePlayer network module, a PIC 18LF2321, a 3V coin cell battery, and glue logic. The valves that control the waterflow are turned on and off with relays that switch 24VAC power. The relays themselves are driven from the PIC I/O pins using driver ICs. Twelve valves in total are in use for this project, the number being limited mainly by the memory of the PIC device selected.
The SitePlayer module implements all the handling of network devices. It includes a flash memory that stores all the web site files. In the files, strings of the form ^foo are replaced by the content of the variable 'foo', which is one of a number of data types, automatically when the website is served by the site player. A UART (RS232) link between the PIC and the SitePlayer allows the PIC to read and write the variables in the SitePlayer's on-board memory.
Additionally, a serial I2C eeprom is available for logging events.
Software & Logical Design
The logical design of the device is as follows: the SitePlayer serves up a website with information regarding the current configuration of the system (current time, day, status of the valves, etc.). Most of the dynamic information is retrieved via AJAX. When the user makes a change to the web interface, a specially formatted string is written to the SitePlayer (again, using AJAX), and the SitePlayer module toggles an I/O pin, raising an interrupt on the PIC. The PIC notices this interrupt, reads the command string out of the SitePlayer, updates its internal parameters, and then updates the SitePlayer's memory, reflecting the changes. Then, the SitePlayer propagates the changes back to the browser.
Furthermore, the PIC reacts to a timer interrupt generated every 2 seconds, and updates its internal clock. On every minute roll-over, it checks whether any valves need to be turned on or off.
There is a back-up battery, which makes sure all the settings (which are stored in PIC RAM) are preserved across power losses. In battery mode, the valves are not being activated, nor is the SitePlayer running. The PIC wakes up every 2 seconds, updates the internal time, and goes back to sleep, so minimal power is consumed. When power is restored, the SitePlayer is re-initialized with data, and can be accessed via the network again.
Thursday, September 10, 2009
Stack Processor, Pt. 4
Since presettable 16-bit up/down counters are impossible to find, maybe the data and return stacks ought to be limited in size, with the high 8 (data stack) or 12 (return stack) bits being in a separate register.
It might be interesting to add some basic security features to the system that would allow implementation of processes. For example:
- only "ring 0" (which could be the code in the lowest 4K for example) can directly modify the data/return stack pointers or else an interrupt would trigger
- a page table that maps, say, 4K worth of memory from anywhere in the 64K ram to 0x0000 - 0x0FFF, and this is the only region the process can access
- By making "ring 0" be the code that executes in the first 4K of RAM (for example), things like UART or I/O functions might be accessed by special mechanism - software interrupts (DOS style) for example. Alternatively, I/O ports (to which the UART would be connected) could be mapped through a paging mechanism also.
It might be interesting to add some basic security features to the system that would allow implementation of processes. For example:
- only "ring 0" (which could be the code in the lowest 4K for example) can directly modify the data/return stack pointers or else an interrupt would trigger
- a page table that maps, say, 4K worth of memory from anywhere in the 64K ram to 0x0000 - 0x0FFF, and this is the only region the process can access
- By making "ring 0" be the code that executes in the first 4K of RAM (for example), things like UART or I/O functions might be accessed by special mechanism - software interrupts (DOS style) for example. Alternatively, I/O ports (to which the UART would be connected) could be mapped through a paging mechanism also.
Monday, September 7, 2009
Stack Processor - Boot Strap done
Eureka! A first draft of the bootstrap circuit that extracts the BIOS from a serial EEPROM and dumps it into the SRAM is done:
It obviously doesn't include other circuitry yet to align it to the rest of the future system (like OR gates on the SRAM /CE for example), and it's untested, and I think I forgot to connect the data counter's /RCO to the BS_DONE flip flop, but other than that...
It obviously doesn't include other circuitry yet to align it to the rest of the future system (like OR gates on the SRAM /CE for example), and it's untested, and I think I forgot to connect the data counter's /RCO to the BS_DONE flip flop, but other than that...
Sunday, September 6, 2009
Stack Processor, Pt. 2 (cont.)
I guess it would be doable to just have a 3-byte instruction that loads a data word from a literal address to the stack? Basically it would be a slightly optimized form that doesn't first put the address onto the stack itself:
1. Decode first byte of instruction, push TOS
2. Move first address byte into the high byte of the SRAM address latch
3. Move the second byte into the low byte of the SRAM address latch
4. Latch the SRAM data bus into the TOS register
Would it make sense to have some sort of paging for literal SRAM access? Basically, have the high N bits of the address be adjustable through a separate register and then have the remaining bits encoded in the instruction.
1. Decode first byte of instruction, push TOS
2. Move first address byte into the high byte of the SRAM address latch
3. Move the second byte into the low byte of the SRAM address latch
4. Latch the SRAM data bus into the TOS register
Would it make sense to have some sort of paging for literal SRAM access? Basically, have the high N bits of the address be adjustable through a separate register and then have the remaining bits encoded in the instruction.
Friday, September 4, 2009
Stack Processor, Pt. 2
On second thought: 8-bit data/instruction bus makes for happier times. From a usage point of view, 16-bit is pretty silly in a microcontroller. Either you can get away with 8 bits (and use software for 16-bit operations), or you need 32 anyway.
So anyway:
Four 16-bit counters.
1) Preloadable, up only - for instruction counter - must be tri-state - its output feeds into the address bus of the 2^16B = 64KB SRAM. This counter is used to fetch the next instruction (or the next byte of a 2-byte instruction)
2,3) Preloadable, up/down - for data and return stack pointers, respectively. Can be re-written on the fly to switch between threads! These are also tri-state, and feed into the address bus of the SRAM.
4) Up only, maybe with prescaler? - used for system counter, to time things etc. Tri-state, connected to data bus.
Also: a boot loader consisting of an 8-bit parallel-output serial-input shift register, connected to a prescaler and a serial EEPROM on the serial side and the SRAM data bus on the parallel side, and a counter connected to the SRAM address bus. When the "chip" comes out of RESET, X bytes (hard-wired? DIP switch configurable? software configurable?) are read from the serial EEPROM and written into the first X bytes of the SRAM. After this is completed, execution starts from location 0 (the reset vector), which is where the boot code was loaded to.
The boot EEPROM would probably also be available to be written via another shift register, but this can sit on the I/O bus (which may or may not be the same as the memory bus).
Not entirely sure how one makes timing work in such a system... I mean, if a few different things are loading down the address bus, for example, and/or there are some things gated into memory, there must be quite some skew between the address bits. So how do you account for that when generating signal timings? I guess for gated things, the address lines are just fanned out and what's actually gated are the chip enable/chip select signals, which can (and probably should) arrive later, anyway.
Target frequency for this whole mess is in the 10MHz range, btw - though I may take that down to 2-4MHz if I feel like it. (Obviously, real world applicability and performance are not huge concerns here.)
The only drawback with an 8-bit data bus is that a memory read will look like:
li[high byte]
li [low byte]
la ; read data
and since the instruction size is only 8 bits, li would have to be a two-byte instruction, meaning it would take 5 cycles to load a byte of data. Maybe a 16-bit instruction size would be better? But that seems excessive, since it will be a pretty small instruction set, and there would be a lot of wasted space with 16 bits.
There COULD of course be an instruction that simply reads the next N bytes out of the program into the data stack. That way, program memory would look like
[read 2 bytes to dsp]
[byte 0]
[byte 1]
[load data]
[...]
Though that would lead to a almost micro-code like execution, which would be more difficult to implement in a LSI circuit.
So anyway:
Four 16-bit counters.
1) Preloadable, up only - for instruction counter - must be tri-state - its output feeds into the address bus of the 2^16B = 64KB SRAM. This counter is used to fetch the next instruction (or the next byte of a 2-byte instruction)
2,3) Preloadable, up/down - for data and return stack pointers, respectively. Can be re-written on the fly to switch between threads! These are also tri-state, and feed into the address bus of the SRAM.
4) Up only, maybe with prescaler? - used for system counter, to time things etc. Tri-state, connected to data bus.
Also: a boot loader consisting of an 8-bit parallel-output serial-input shift register, connected to a prescaler and a serial EEPROM on the serial side and the SRAM data bus on the parallel side, and a counter connected to the SRAM address bus. When the "chip" comes out of RESET, X bytes (hard-wired? DIP switch configurable? software configurable?) are read from the serial EEPROM and written into the first X bytes of the SRAM. After this is completed, execution starts from location 0 (the reset vector), which is where the boot code was loaded to.
The boot EEPROM would probably also be available to be written via another shift register, but this can sit on the I/O bus (which may or may not be the same as the memory bus).
Not entirely sure how one makes timing work in such a system... I mean, if a few different things are loading down the address bus, for example, and/or there are some things gated into memory, there must be quite some skew between the address bits. So how do you account for that when generating signal timings? I guess for gated things, the address lines are just fanned out and what's actually gated are the chip enable/chip select signals, which can (and probably should) arrive later, anyway.
Target frequency for this whole mess is in the 10MHz range, btw - though I may take that down to 2-4MHz if I feel like it. (Obviously, real world applicability and performance are not huge concerns here.)
The only drawback with an 8-bit data bus is that a memory read will look like:
li
li [low byte]
la ; read data
and since the instruction size is only 8 bits, li would have to be a two-byte instruction, meaning it would take 5 cycles to load a byte of data. Maybe a 16-bit instruction size would be better? But that seems excessive, since it will be a pretty small instruction set, and there would be a lot of wasted space with 16 bits.
There COULD of course be an instruction that simply reads the next N bytes out of the program into the data stack. That way, program memory would look like
[read 2 bytes to dsp]
[byte 0]
[byte 1]
[load data]
[...]
Though that would lead to a almost micro-code like execution, which would be more difficult to implement in a LSI circuit.
Thursday, September 3, 2009
A Stack Processor In Hardware
I've been playing with the idea of designing and maybe actually building a stack processor (that is, a processor that, rather than a bunch of registers, has a data stack as its primary local data storage), using 7400-series and similar ICs. Obviously this is not practical in the least, but it could be quite fun.
The idea is to use discrete ICs to implement every aspect of the processor, like so:
- 4x 74181 chips would form a 16-bit ALU
- a 16-bit register would form the top-of-stack (TOS) register
- a 64K dual-port SRAM would be the memory (dual-port so that both data and instructions can be read simultaneously) - this would include instruction memory, the stack itself, and data memory.
- a 16-bit binary counter to implement the PC
- a serial EEPROM for the BIOS
- some random peripherals - some 7-segment LEDs, a UART, maybe an LCD
- a shitload of gates to implement the control unit/address decoding
Madness.
The idea is to use discrete ICs to implement every aspect of the processor, like so:
- 4x 74181 chips would form a 16-bit ALU
- a 16-bit register would form the top-of-stack (TOS) register
- a 64K dual-port SRAM would be the memory (dual-port so that both data and instructions can be read simultaneously) - this would include instruction memory, the stack itself, and data memory.
- a 16-bit binary counter to implement the PC
- a serial EEPROM for the BIOS
- some random peripherals - some 7-segment LEDs, a UART, maybe an LCD
- a shitload of gates to implement the control unit/address decoding
Madness.
Subscribe to:
Posts (Atom)