Posted: February 24 2004 at 17:01 | IP Logged

Consider adding a new serial device class - a "Generic" device that can have arbitrary strings sent to, and read from, it.

The way I envision the function of the generic serial device is through a series of functions that would do, at a minimum:

• Send a arbitrary string/data stream to the designated COM port.
• Read the data stream coming from the serial port.
• Functions to read the status of the RS232 input control signals (e.g. CTS, DSR, DCD, RI).
• Functions to read and set the status of the RS232 output control signals (RTS, DTR).
• A function to transmit a 'break' signal (continuous space) for a user-specified number of milliseconds.

The read-data function could support optional parameters that would control when it terminates - either upon matching a specified string in the incoming data stream, or after having read a specified number of bytes, or after a specified timeout (in milliseconds), or after the receive line is idle (e.g. no more incoming data) for a specified timeout.

It might also be useful to be able to define a trigger event that is activated when data is received on the port, or perhaps when a specified string or regex is sensed in the incoming data stream.  Perhaps even a trigger that is activated when a change of status is detected on any of the RS232 input signals, or a break/continuous space is detected on the receive line.

Parameters that would be defined for the generic device (in the "Powerhome Explorer") would be: Baud rate, wordsize/parity/stopbits, and perhaps handshaking method for both transmit and receive (none, xon/xoff, RTS/CTS, etc.)

The reason for making this request in my particular case is that I have built a microcontroller-based device that interfaces with a computer via a serial port (and USB, although I don't know enough about windows programming to make a host-side device driver for it).  This device is capable of controlling and programmatically changing the intensity of up to 8 incandescent lights - the original intent was to create a device that could run christmas tree lights, either under host control or independently using macros stored on the device.

I would imagine that if the idea I proposed here is implemented, it could be used by PH users to provide low-level support for RS232-interfaced devices that PH currently does not provide support for.

Assuming that the Windows environment allows it, it might also be beneficial to provide a "generic" LPT-port driver that would allow the various LPT port digital signals to be read and controlled.  It is relatively easy to homebrew hardware that is driven by simple digital I/O signals, thus having a means to gain low-level control over the LPT port signals would be useful for such applications.

Thank you for considering my ideas.

Posted: February 24 2004 at 19:15 | IP Logged

Awww...you guys are going to make me spoil the surprise.

Version 1.03.2 (due out days upon days ago, but might make it out tonight) has this functionality.  You can declare up to 5 generic serial ports all through functions.  Instead of a trigger being fired, you assign a Macro ID to the port when you open it and that macro is called when data is received.  You have control over the BPS, RTS, DTR, thresholds, etc.  There are a total of 11 new functions to support the generic serial port.  I don't have ALL of the functionality you've requested, but I would say most of it is there.  There's always the next version .

Another package due out shortly after the 1.03.2 release will be a plug-in interface.  This will provide yet another way to interface your device as well as give third party developers the opportunity to create interfaces for devices not internally supported by PowerHome.  You could actually acheive this now by using the Socket Server Interface or the Windows Messaging Interface.  This would allow you to write a specific interface in something such as VB and then have two-way communication between PowerHome and your VB interface via either messaging or sockets (both trigger supported).

Ive considered a generic driver for the LPT port but kind of discounted it since it would only work on Windows 95/98 and not NT/2000/XP.  If there is still interest in this, I can look at adding the necessary routines.

Dave.

Posted: February 24 2004 at 20:03 | IP Logged

Very cool!  This will be great for CID, remote displays, and, many other things. I can't wait!

Posted: February 25 2004 at 21:04 | IP Logged

That's great!  Thanks.

WRT the parport stuff, I guess I can see why you've opted not to include a generic parport driver - if Win2K/XP won't let you take direct control of the parport I/O's, there's not much point in including it.

Maybe, for my next project, I should look into methods for receiving and transmitting IR codes - all of the solutions I've seen so far are either unattractive or waaay too expensive.

Posted: February 26 2004 at 09:35 | IP Logged

Mark,

No problem.  Im curious about your microcontroller project.  Ive delved into this myself and even created my own IR controller with a CM11A passthru interface.  I used an older 8051 microcontroller with a separate 32K RAM chip and 8K EEPROM chip with the whole thing using point to point wiring.  What a monster.  I'll have to get back into it with the newer microcontrollers including onboard RAM and EEPROM.

Dave.

Posted: February 26 2004 at 14:44 | IP Logged

The device I referred to in my original post is called the "vTree" - "Virtual (christmas) Tree", because the original concept was to come up with a controller that could run christmas tree lights strung on a string frame in a tree-like shape - in the dark, the lights would look like they had been strung on a 'real' tree, hence the "virtual" part

My vTree prototypes are based around a ST Micro ST7263 device - a 32-pin 8-bit microcontroller that has integrated SCI (UART), I2C, USB (low speed), ADC, timers, 16K EPROM, and 512 bytes RAM.  To this I add a 64K (8 x 8Kx8) I2C serial EEPROM array for macro storage, some analog circuitry for powerline zero-cross detection, thermal (fan) control and analog interfacing, and a "power board" which has 8 opto-triac-coupled power triacs for light control.  I used the ST7263 for several reasons, one of the most important being that I had a nifty little board from a work-related project that had most of the device's I/O lines run out to a 26-pin header, and USB and serial port connectors on-board and cabinet-mountable.  This allowed me to easily integrate the uC into my mostly wire-wrapped (with some point-to-point for the power section) design.  Another reason for using the ST7263 was the fact that it had integrated USB support - an important feature for some of my Mac-user-only friends

Recently, ST introduced a FLASH ROM version of the ST7263, but I don't have the dev tools for it, so can't use it as of yet :(

Anyway, my light controller design allows one to independently control the brightness of up to 8 medium-power (<= 150W each) incandescent lights.  It also has some built-in firmware support for smoothly ramping the light brightness up and down (either linearly or using various alinear mathematic formula, such as a log(n) or sinusoidal ramp) independently of the control host, along with full macro/sequencer/interpreter that can run programs stored in a simple filesystem in the serial EEPROM.  There are two 'command interpreters' that can be selected for host-control use; a terminal-friendly shell-like interface, or a more 'computer friendly' terse command set.

The firmware, written entirely in assembly language, occupies almost all of the available 16K ROM space, and could have easily been considerably larger if I had a larger on-chip (E)EPROM to work with

I am working on the docs for it now, and can certainly appreciate one of your eariler comments on the difficulty of writing good technical documentation.  Some of the intended users of my little toy are only marginally computer-literate, and the vTree includes a lot of fairly complex functionality.  Writing documentation that accurately describes the vTree's features while being comprehensible by non-technical types is a bit of a challenge.

I have given some thought to attempting to commercialize the design, and I could probably design my own PCB and sell at least the core electronics as a kit or pre-built PCB, but I do not have the know-how or means to do the necessary mechanical design or have the tooling made for a suitable enclosure.  My prototypes are enclosed in off-the-shelf project boxes, with various holes for connectors, displays, buttons, etc. cut/drilled by myself.

I could probably post a picture of my prototype here if you'd like to see it.

For rolling your own microcontroller projects, I would suggest looking at the following devices, all of which have free or low-cost development tools available for them:

• Microchip PIC family (archetecture stinks, but dev tools are good and readily available)
• Atmel AVR family (somewhat minimalistic RISC-like instruction set, but well thought out, and very fast for a 8-bitter)
• Cypress EZ-USB family (8051-like, integrated USB port, code is stored in SRAM and uploaded via a USB bootloader.  Can be programmed on-the-fly by the USB host).

Other projects I have in mind to build:

USB- and/or RS232-interfaced IR sender/receiver, similar to the RedRat (but hopefully less expensive!)

The "USBIO" - A USB- (and maybe RS232) interfaced device that provides digital I/O, analog (ADC) inputs, and a I2C bus, intended to provide a easy way to interface user-built control hardware to a computer - similar in principle to the CPU-XA/Ocelot.  Maybe include a X10 powerline transciever too, with all the powerline electronics integrated (no external interface needed).

Enough rambling, hope you enjoyed it

Posted: February 26 2004 at 15:06 | IP Logged

Oh, forgot to mention - you asked about how I go about building my microcontroller-based projects.  I personally swear by the wire-wrap method of point-to-point wiring of most of my prototypes, at least the non-trivial ones.  I try to select microcontroller devices that come in DIP or PLCC packages.  DIP packages, of course, can be incorporated into a wire-wrap proto with a basic wire-wrap IC socket.  PLCC packages can be accomodated if one uses a PLCC socket (which usually has it's pins spaced out on .100 centers) in conjunction with WW socket pins.  The PLCC socket can be plugged into a properly-arranged array of wire-wrap socket pins, which I either buy as individual socket pins or (less expensive in some cases, ironically) by cutting up open-frame DIP wire-wrap sockets and super-gluing or solder-tacking the socket segments into the appropriate PLCC socket footprint on my perfboard.  I use perfboards with solder pads on both sides, and in some cases, integrated ground planes (for high speed and/or noise-critical applications).  These sorts of perfboards are made by Vector Electronics and sold by Digi-Key (and others), or can be had from a good electronics shop.  I use Vector T49 (or similar) wire-wrap push-pins for mounting passive components, or (when space is tight) I use careful, well-laid-out point-to-point soldering for passive component mounting.  I often use the extra lead length of resistors and caps in my routing, along with bits of wire-wrap wire when needed.  I secure wire-wrap sockets to my boards by tacking the corner pins down with a bit of solder (remember, I use perfboards with solder pads on them in part for this reason) or, alternatively, secure the corner pins with a bit of super glue.  I sometimes use "Wrap-IDs" - plastic tags that identify IC socket pin numbers that slip on the "solder side" of the wire-wrap IC socket - to help me ID IC pin numbers and minimize wiring mistakes.

All of these techniques and methods are enough subject material for a small book, but I'd be happy to discuss them in greater detail if you like.  I have been building homebrew (and even work-related prototype) electronic projects for over 20 years, and would enjoy passing along my experiences.

Posted: February 26 2004 at 21:32 | IP Logged

Mark,

Very interesting.  Its been awhile since Ive really sat down and played with some good old digital circuits and your post brings back some memories.

Yes, I think it would be great for you to post a picture of your project.

I think if you were to market it, you would probably garner a LOT of interest.  Ive visited several companies websites that market similar controllers for visual lighting effects and they seem to be doing well.  I know a lot of people would be interested just so they could have the coolest Christmas light display on the block .

I was going to play with the PIC's but never got started and decided that I would probably try to make my next project using an AVR.  Course' I think that the latest 8051 micros now have onboard RAM and EEPROM or flash.

Ive only put together a couple of microcontroller projects myself.  The afore mentioned IR interface and an EEPROM reader/writer so I could write the firmware for the IR interface.

Never played with wire-wrapping.  Im fairly accomplished at soldering so will do like you and use single clad perfboard and the extra lead length of the resistors and capacitors in my wiring.

Thanks for the rambling and I definately enjoyed it.

BTW, let me know how the new version works for you with the COM port functionality.  If something comes up short, I can probably add to it in an interim release.

Dave.

Posted: February 29 2004 at 02:38 | IP Logged

One of the reasons I've not taken my 'vtree' project any further is that I don't know enough about programming in Windows to write the serial (or USB) drivers for the project.  Can one do basic USB endpoint I/O directly from a application without having a device-specific driver present?  (note: the vtree is not a HID-compliant device).

I recently found some sample code for the Mac that gave me enough information so I can perform raw data I/O on a USB device w/o needing a specific device driver for it.  There is some hope that, with the help of a friend, I might be able to write something for the Mac to control the vtree via USB.  This will make my Macolyte friends happy (some of whom already posess vtree prototypes).

I need two other software items to complete the tool suite needed to make the vtree a viable, marketable device - a compiler/assembler for the sequencer/macro processor language, and a utility that can 'build' a filesystem image for the EEPROM storage on the vtree (this is where the macros, device setups, and optional data files readable from within macro programs reside).  I'd be willing to donate a hand-built vtree prototype to anyone who could write (windows based) utilities that would accomplish these tasks.

In any event, I'll be testing out the vtree w/PH as soon as I get the new version set up and become adept enough at writing macros to write a meaningful application.

Need to borrow a friend's digital camera so I can get decent images for posting.

Posted: March 03 2004 at 21:46 | IP Logged

FWIW, my building preference is point-to-point soldering with wire wrap wire. Not as flexible as wire wrapping, but, takes up much less space.

Tony