Archive for the ‘Nerd Stuff’ Category

A PIC Forth Compiler/IDE

Monday, April 26th, 2010

In light of all the PIC18F Assembler I’ve been writing (for RainDance and other stuff), I’ve been thinking about a simple FORTH compiler to make things a little bit easier.

Here’s what I’m envisioning: A PC environment, basically a forth shell, that allows the definition of new words (using the ‘:’ word), but instead of adding it to the current dictionary, it compiles the new word to PIC code, outputs the ASM and machine code (like you would see in a .LST file) and adds it to an “output” dictionary. An extra command, “compile”, puts all the words in the dictionary together, fills in addresses etc., and outputs a PIC object file that can be linked against other files using standard tools to make a complete PIC binary.

Of course, the current output dictionary could be stored also, for later editing/resumption of work.

The whole thing could be implemented on top of a standard FORTH (gforth or similar) by redefining words so that when you type

: add5 5 add ;

it actually checks if ‘add’ is a word defined in the “output” dictionary, checks if it’s a macro or a callable function (things like add would be implemented directly as one or two assembly instructions, so it would be easier to treat it as a macro), expands/calls the macro/function, and puts the resulting headers/code into the output dictionary.

I’m sure there’s a ton of stuff I haven’t thought about here, but it could work, and it could be neat. It’s questionable whether this is a better approach than just using, say, C, but I think FORTH is a very nice language to make some of the ugliness of assembly go away without sacrificing much in the way of transparency.

RainDance – So Much Anger!

Wednesday, April 21st, 2010

I finally got the raindance project (see posts below) to a more-or-less complete state. The custom board (including the PIC, programming header, SitePlayer headers, ethernet transformer/jack, PSU, relay drivers and back-up battery was finished and stuffed, and slowly everything was taking shape. A lot of debugging was done to make everything work – the website, plain as it is, allowed configuration of all valves and device parameters, and the relay drivers themselves would activate at the scheduled times. Beautiful.

And then the f’ing SitePlayer up and died. I’m not sure what happened, though I suspect something went wrong with the power supply, but I can’t talk to the damn thing anymore – neither by UART nor by the network interface. As far as I can tell, the voltage supplied by the regulator (a simple full bridge rectifier, some caps, and a LM312-style device) is supplying 5V, but it also gets hot – hotter than it should, I think. But either way, ding, dong, the SitePlayer is dead. My dad (who designed and stuffed the hardware) has one more of the units in California, so we can try to swap it out. The problem, of course, is that now the longevity of the device isn’t really guaranteed.

After all the poking and prodding and comparatively poor documentation, my faith in the SitePlayer’s reliability was already shaken, but for it to just up and die for no reason really makes me think this was the wrong way to go for this project.

So, I’m using this as an opportunity to sketch out the hardware for the next revision of the device. Some features that I wanted on this device but was not able to implement:

  1. E-mail notification after power outages, weekly summaries, etc.
  2. Time Server communication to avoid having to set the time manually
  3. Larger web site space
  4. Communication with external sensors (soil moisture sensors, irrigation sensor)
  5. SSL support

1 and 2 can be achieved if the device has a full TCP/IP stack available. Basically, it means that the next system should have a full ethernet interface, rather than just a limited web server as in the case of the SitePlayer.

3 can be achieved by adding sufficient amounts of nonvolatile storage, either permanent or removable.

4 requires external interfaces – preferrably some sort of wireless chip to communicate with remote sensors, along with the extra complexity in code and web site to configure such a system.

5 requires a beefy processor, or one with hardware support for cryptographic functions.

So far the mental sketch of this system leans on the NetBurner development kit. On this dev board is a Freescale ColdFire MFC5270 chip, which is a 32-bit 68000 core with an external memory bus as well as internal SRAM, an integrated ethernet MAC, and miscellaneous other features. Its big brother, the MFC5271, includes a cryptographic engine on-board. In addition, the following parts would be required:

  1. SDRAM
  2. Non-Volatile Storage with a NOR-like interface
  3. RTC controller
  4. Ethernet PHY

Obviously, the complexity of this system far exceeds that of the initial version of the hardware. Unfortunately, the price to pay for a full-fledged TCP/IP stack + webserver is a fairly beefy processor underneath, and those come with the necessity for external RAM etc.

On the other hand, since this processor has an external data bus, adding a second NV storage like a CF card would be quite doable! This means that the available storage size would be limited only by software constraints. Also, any I/O device with a standard NOR-like interface could be addressed, in particular wireless chipsets of various types. This would allow for some very advanced functionality in the future, for example:

  • remote nodes that control extra valves
  • remote rain sensors
  • remote soil moisture sensors
  • 802.11 wireless support (unlikely, but possible!)
  • logical interconnection of these features, e.g. only turn on valve when it hasn’t rained in 3 days, only turn on valve if the soil moisture is less than some threshold, send notification when the soil moisture does not increase when a valve is opened (indicating a bad valve or blocked hose), etc.

One issue with this approach is the handling of power-down scenarios. The processor itself consumes much more power than a PIC, and the associated peripherals must be turned off in an intelligent way so as not to ruin the battery life in the event of a power loss. Furthermore, relevant data must be stored either in the internal SRAM or on non-volatile storage, unless the SDRAM should also remain powered during power loss. There are many potential pitfalls in this scenario, so it will require careful planning.

Of course, the software effort in such a system could be very significant, depending exponentially on the number of features and their interactions. On the other hand, the flexibility is enormous, and the device might serve substantially different functions depending on the software used.

Looking for a new project

Sunday, November 29th, 2009

Like the title says, I’d like to hop on a new project. A few thoughts:

  • I don’t think I’m going to continue with the stack processor. Mainly, I don’t think I will learn much, other than how to get really frustrated at very little functionality. So I’ll pass up on that.
  • The RainDance/Sprinkler controller is still asking for a last few hours of wrap-up/polish, and I will do that before I really sink my teeth into a new project.

Now, to the new project… I’m a student now, so I don’t want to spend a lot on building a hardware prototype or anything. But here’s what I have at my disposal right now:

  • NetBurner dev board (a ColdFire controller with an ethernet port and a bunch of peripherals)
  • PIC Dem2 Plus dev board
  • SitePlayer dev board
  • Xilinx FPGA dev board
  • A laptop with a CUDA-capable NVIDIA GPU
  • Student version of Matlab and LabVIEW

So, some thoughts about the actual project:

  • I COULD re-implement the RainDance stuff on the NetBurner, just for fun. But mainly that would consist of slapping together existing RTOS, TCP/IP, Webserver, etc. packages for this processor. I may do it yet, but I’m not sold on it, really.
  • I was considering implementing a system from the ground up on the ColdFire using FORTH. Basically, write a low-level boot loader thing and a basic interrupt handler in assembly, and on top of that do everything in FORTH, all the way up to … well, realistically, up to the point I get bored, but in theory up to a working TCP/IP stack and webserver.
  • I’ve been studying control theory this semester, and something in that realm might be interesting, but I can’t think of a good application. Maybe something with a dsPIC (which I don’t have, but if there’s a really interesting application, I’m sure I could scrounge up a dev board somewhere). One thought was a regulated power supply of some sort.
  • Some sort of DSP application – I have labview/matlab and the NVIDIA CUDA (massively parallel processing) available, so something where I can process large amounts of data (video/image processing, for example) might be neat. But it would definitely require a lot of reading/learning on my side. But still, something I’d like to get into.

So, thoughts? suggestions?

RainDance – Sprinkler Controller

Wednesday, November 4th, 2009


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.

Stack Processor, Pt. 4

Thursday, September 10th, 2009

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.

Stack Processor – Boot Strap done

Monday, September 7th, 2009

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…

Stack Processor, Pt. 2 (cont.)

Sunday, September 6th, 2009

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.

Stack Processor, Pt. 2

Saturday, September 5th, 2009

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.

A Stack Processor In Hardware

Thursday, September 3rd, 2009

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.