Monitor three or more footswitches over RS-232

I have a footpedal fitted with three footswitches. I want to wire these
up to a suitable IC to transmit data (different data for each switch)
over an RS-232 serial cable which is connected to a computer (actually
a PDA but that's irrelevant to the solution). I will have software
running on the computer to read incoming data on the RS-232 line to
identify which footswitch has been pressed.

I can handle the software on the computer no probs but don't know how
to build this 'intelligent' footswitch. Please help!

 

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

 

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

 

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
8250.

 

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

 

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...



--
Don McKenzie
E-Mail Contact Page: http://www.dontronics.com/e-mail.html

Micro,TTL,USB to 1.5" color LCD http://www.dontronics.com/micro-lcd.html
USB,RS232 or TTL to VGA Monitor http://www.dontronics.com/micro-vga.html
World's smallest USB 2 TTL Conv http://www.dontronics.com/micro-usb.html

 

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.

 

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

have a good read through:
http://www.dontronics.com/dt006.html
uses an avr2313.

you can even build it free from the info supplied.

Cheers Don...



--
Don McKenzie
E-Mail Contact Page: http://www.dontronics.com/e-mail.html

Micro,TTL,USB to 1.5" color LCD http://www.dontronics.com/micro-lcd.html
USB,RS232 or TTL to VGA Monitor http://www.dontronics.com/micro-vga.html
World's smallest USB 2 TTL Conv http://www.dontronics.com/micro-usb.html

 

---
Let's iron out the spec's first...
---

---
Well, the point really is that unless you make arrangements to the
contrary, data will _always_ be coming in so you'll have to sample
it periodically in order to determine whether any of the switches
was closed or not.

Another way to do it would be to have the interface assert one of
the control lines, say RTS, when data chenged, use that as an
interrupt and then have the PDA send CTS when it was ready for the
data. The interface would then send the 10 bit (start bit, 8 data
bits, stop bit) data word and wind up waiting for the next change in
the switches' status to send another RTS.
---

---
Are you planning on running the interface from the same battery
supply you'll be using for the PDA, or what?
---

---
OK.

I can show you how to build a cheap, very low power asynchronous
transmitter using hardware handshaking with either glue logic or a
microcontroller, but if you're going to use it commercially I can't
do it for free.

What next?

 

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.

---
Regards,
Bob Monsen

Even the greatest of creations start from small seeds.
- Unknown

 

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.

 

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!

 

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.