Archive for April, 2010

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.

Posted in Nerd Stuff | Comments Off on A PIC Forth Compiler/IDE

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.

Posted in Nerd Stuff, RainDance | Comments Off on RainDance – So Much Anger!