Monitor three or more footswitches over RS-232

Here's a hack suggestion: find a 3-button serial mouse and wire the footswitches in parallel with the mouse switches! :)

You get an old hardware UART, ie one that wasn't designed to be connected to a computer bus, set the pins for the desired number of bits, stop bits, and parity. Then you connect the foot switches to it. One foot switch could send "A", and other "B" and another "C". Then all you have to do is watch the serial port for that. No intelligence needed, though someone is bound to suggest a PIC.

Is the serial port the only port available? Because if there's USB, you could open a three button mouse, wire the footswitches to it instead of the buttons, and then each press of a footswitch would be like pressing the mouse button.

If there's a parallel port, one can wire the switches to the status pins (or if the parallel port can be programmed for input, use the data lines).

If there's a keyboard port, as in PS/2, one could get a cheap keyboard, extract the encoder, and then wire the footswitches to keyboard contacts so pressing a footswitch would be like pressing a key on the keyboard.

Michael

"Michael Black" wrote

bits,

You kinda glossed over the part about actually generating an "A", "B", or "C" and strobing it in didn't you? Not to mention setting the baud, parity etc. ;-) Even the old 82C50A UART is fairly complex, it's a bit harder than just presetting some pins. You have to store data in internal registers to set the baud rate and other goodies. IOW, a fair amount of intelligence really is needed.

Since the OP already knows how to program, perhaps a PIC would be a good idea to drive the UART. Of course with a PIC the OP could just skip the

An 8250 is the last thing he wants, it being one of those designed for a computer bus. I was referring to a UART like the AY-3-1015 that was indeed set by pins. The only data lines were for data going in and out of the UART, not for controlling it. YOu set the baud by the external clock.

If you want something more recent, the CMOS 6402 is similar.

My comment was no more vague than "use a PIC". He's got a pointer, he follows it to the datasheet, and either grasps the details, or asks further questions based on the pointer to a UART.

The old UARTs were indeed useful for this because they required no computer. Put the right data lines to ground, and strobe the UART, and it will send that character. Hence you have various means to turn the footswitch signals into the "A", "B" and "C". Those may not even be the best combinations, because when someone looks at the ASCII code table, they likely will find characters that require the least bit of encoding. And that encoding can be something as fancy as an eprom, or just some gates, or even a few diodes.

Michael

Thanks for your suggestions. I like the suggestion of hacking a serial mouse - at least for a one-off solution. But once I've got a workable solution, I need to make a few of these. So I need a cheap solution that is easily reproducible.

Wiring the switches directly to the control lines is an idea, but implies that my software on the PDA will have to poll the interface to determine if a switch is shut. This would be disastrous for battery life so is not possible.

Which leaves a UART. I haven't worked with these before - can this be done for a few $$s, and would I need some kind of RS232 interface chip between the UART and the 9-pin socket?

Potentially I could need 100 of these... but let's start with one to prove the concept!

As for polling the interface... well, I code in C# using the .NET compact framework, and the serial API has events that fire when data is received, and I can trap the events in my code. How they do that, I don't know, or care... but it has to be more efficient than me having code running in a tight receive loop. One thing I know from years of handheld device programming, is you never miss a chance to save battery power :-).

The target PDAs are Windows Mobile devices (Pocket PCs) so the serial port behaviour is pretty similar to a desktop PC. You can use software or hardware flow control and the port characteristics are pretty configurable.

I've written an RS232 driver for a PIC12F683 microcontroller. Works reliably up to 9600, and controls the 'modem signals' for flow control. The PICs themselves cost around a buck. The PC card, switch setup, and that sort of thing would run a few more bucks in volumes of 100, but a prototype would be quick and easy. The device could be powered from a PC serial port, or just use a battery or wall-wart for power. Powering it from a PDA would probably not be a good idea...

Email me for more info.

No IC required: Wire your 3 switches between TX and RX, DSR and DTR, RTS and CTS.

If what you send out is received back on each corresponding signal, the switch is shut.

Don...

Thanks, Guys. The footpedal/interface will be powered sparately from a 9v battery, or a mains 9v transformer. I like the idea of the interface raising RTS. The code on the PDA can just sit hibernating, then the OS's serial port middleware (the .NET Compact Framework runtime) will raise a 'RTS raised' event that will wake up my software and I can act on the data. I don't see a need for a continuous steam of data over the serial link - only when a button is pressed on the footpedal.

Thanks for the offers of commercial solutions. I will want that if this thing is a success - but now I'm only a hobbyist who has had an idea that *might* fly commercially, but I'm really not sure yet. Here's hoping...! I have to think how much of an investment I want to make in this, but right now I want a proof-of-concept prototype. I'd like to understand how this is done anyway from an intellectual interest point of view, as I studied electroniucs at Uni - but that was over 20 years ago and I never used what I learnt (went into software) - until now!

well in that case you need a simple micro with a simple uart built in.

have a good read through:

you can even build it free from the info supplied.

Cheers Don...

get an old 3 button serial port mouse and take the ball out :) the line proticol protocol is 1200,N,8,1 I think.

if you want to choose which serial data each switch will cause that's a little more complex :)

Bye. Jasen

you can make a "send-only UART" usiing a decade counter, a clock source and a bunch of diodes

decade 1n914 counter diodes switches outputs Q0 ------>|-----------------------+ _- | Q1 ------>|-------o~ o-----------+ _- | Q2 ------>|-------o~ o-----------+ _- | Q3 ------>|-------o~ o-----------o----> to serial line driver _- | Q4 ------>|-------o~ o-----------+ _- | Q5 ------>|-------o~ o-----------+ _- | Q6 ------>|-------o~ o-----------+ _- | Q7 ------>|-------o~ o-----------o---[10K]-- OV _- | Q8 ------>|-------o~ o-----------+ Q9 output 0 gives the start bit, outputs 1 to 8 control the data bits and output 9 "produces" the stop bit. the switches give control of the 8 data bits and the unconnected output '9' gives the stop bit,

AIUI you need to be fairly close to the correct bitrate for it to work, but the fewer bits you use the less critical it becomes. A 555 might be accurate enough for sending 3 bits.

On the other hand a typical serial port has 5 input pins... RXD CD DSR CTS and RI

he could wire switches to three of them, possibly scavenging the bias voltage from the three output pins.

???

a UART isn'r needed just a serial-encoder of some sort... and a power source to run the whole thing...

if you can score a microcontroller that designed to get power from, and interface directly with a serial port that'd be a start. my old genius GM-6 mouse had a 26? pin chip from intel in it - some sort of microcontroller...

Othewise your foot pedal is going to need a power source and that'll use batteries faster than directly interfacing with the serial port pins.

Also (assuming your PDA has a 8250 compatible UART or similar) all 5 input pins can generate interrupts (but Rxd is delayed and only triggers on one edge) the other 4 trigger on both edges. don't re-enable interrups too soon or contact bounce can overflow your stack.