Linux Format forums

jimdog · Joined: Fri Oct 02, 2009 4:31 pm Posts: 4

Hi

Iḿ working on a project to receive a pulse signal from an old coin acceptor mechanism and convert it to a usb signal so I can build a new jukebox for an autonomous social centre I am involved with.

To do this I have got hold of a USB experiment board as shown here:

http://www.elexp.com/tst_bkit.htm

It uses the (quite common) CY7C6300A-PC microcontroller to translate input to usb signals on 8 of its pins. There is a driver in the kernel for this chip - cypress_cy7c63 - which I have modprobed in. The problem I am having is that the hardware isn correctly identified and so is not associating with the driver, meaning the endpoints are not exposed in /proc/bus/usb/ (which I have mounted via fstab) and so I cannot read/write any signals to the device.

Is there a way of telling the USB subsytem or HAL to associate the driver when the hardware is inserted? I have searched everywhere to find a solution and am at my wits end :-/

Taking the specific hardware out, it could be a general question as to how to modify hardware idś that lsusb shows and so associate that id with a particular driver.

Hereś some output which will hopefully help with this:

Bazza · Posted: Sat Oct 03, 2009 4:24 pm Post subject:

Hi jimdog...

Sadly I can`t answer your question as it stands,
however had you considered using the current
Arduino Dev Board which is much cheaper AND
versatile.

It mates with USB but has a built in FTDI Serial
IC to convert to to pseudo-RS232 to control
the PIC. It comes complete with SW for usage
on Windows and/or Linux, (I`ll let the bosses on
here point to the LXF mag article on how to
install on Linux). It appears as dev/ttyUSBx
where x is a single digit number.

The board has several analogue and digital
I/Os and is remarkable value for money AND
with a simple home brew discrete component
board will mate easily to an RS232 port also...

The best of both worlds... :D

I`ve already done so to mate with my serial
only AMIGA A1200 AND my USB only notebook...

Just a thought...
_________________
73...

Bazza, G0LCU...

Team AMIGA...

AndyBaxman · LXF regular Joined: Tue Oct 04, 2005 9:47 am Posts: 520

If you don't need it for anything else (and the motherboard has one), you could use one or more of the serial port control lines.
_________________
Bomb #20: "Let there be light"

Bazza · Posted: Mon Oct 05, 2009 6:01 pm Post subject:

Hi AndyBaxman...

The parallel port is probably better as almost complete
control of the data, status and control I/O addresses
are easy. Also they are at TTL level...

This lines in the parallel port are at either logic 1 or
0 at TTL whereas the RS232 serial port is + or - 3 to 12V
NRZ...

Just a thought...
_________________
73...

Bazza, G0LCU...

Team AMIGA...

jimdog · Joined: Fri Oct 02, 2009 4:31 pm Posts: 4

Hiya

I've now sort of split this problem into two approaches which I'll briefly explain. I feel I'm getting a little closer to a solution which is great because I'm hearing distant murmerings of the ability of linux to be adaptable enough to do this, when a proprietary windows device could just be bought and plugged in. The future of Linux at the club depends on me being able to make this jukebox work Smile

Ok so first, regarding the I/O board that appears in lsusb, having hunted around I have found a kernel mode driver for the board at

http://sourceforge.net/projects/delcom-usbio/

which also includes a utility to make and reveal the device nodes. Only problem i, I haven't the foggiest how to compile and use it. If I try using gcc or g++ as I would normally for C projects, it exits with a huge amount of errors and wont compile. If I do manage to solve that with your help, how do I insert the new module into the running kernel or would I need to compile a custom kernel from scratch?

The second approach I have thought of for this is that I have a USB to serial converter which I can use as a serial input. The basic layout of the pins on the coin acceptor is as follows (roughly)

Pin 0 - +12V (Which I will take from the PSU)
Pin 1 - 0V
Pin 2 - emits high on £1 coin being inserted
pin 3 - 50p
pin 4 - 20p
pin 5 - 10p
pin 6 - Inhibit £1 ie rejects that coin if high
pin 7 - inhibit 50p
pin 8 - inhibit 20p
pin 9 - inhibit 10p

So there is a ribbon cable which comes from the mechanism and which I will take into the computer through serial (or usb) input.

So at this stage, I need to work out the following if I am to use serial. Firstly, if I want to receive a pulse from pins 2-5, which pins on the serial port should I use and where would these appear in the filesystem. For example if somebody enters a £1 coin, it would cause /dev/tty? to be high, ie if I did "cat /dev/tty?" it would return 1, else it would be 0.

In the same but reverse way, if I did "echo 1 > /dev/tty?" to one of the pins associated with 6-9 it would inhibi those coins from being accepted.

In a nutshell, the program I want to write is as follows once I get the interface working.

I vaguely know how I would do this wth a bash script, but that seems a bit heavy duty for such a simple task so maybe it could be done with C or Python?

I hope that makes some kind of sense. I'm really grateful for the help already given. Hopefully we can crack this soon Smile

AndyBaxman · LXF regular Joined: Tue Oct 04, 2005 9:47 am Posts: 520

Perhaps a simpler ( and maybe more elegant) solution would be to offload the coin-op management to something like a PIC microcontroller which could be used to emulate a PS/2 keyboard. You could then read the key input to determine coins entered and also double as a custom keyboard to select songs, etc.

PIC developer / prototyping boards are available from Maplin, etc. They are fun to program and there will certainly be a PIC that has the I/O you need.

A quick Google for Pic based keyboard emulator found plenty of hits, including this:

http://www.piclist.com/tecHREF/microchip/picboard.htm

You should be able to modify the circuit and code to implement a device that can read a custom keyboard matrix and read / set your coin mech lines.

The PIC code could just send a keycode on coin insert, or could implement a timer itself and send codes on session start / end.
_________________
Bomb #20: "Let there be light"

Bazza · Posted: Wed Oct 07, 2009 8:35 pm Post subject:

Hi jimdog...

> The second approach I have thought of for this is
> that I have a USB to serial converter which I can
> use as a serial input. The basic layout of the pins
> on the coin acceptor is as follows (roughly)

> Pin 0 - +12V (Which I will take from the PSU)
> Pin 1 - 0V
> Pin 2 - emits high on £1 coin being inserted
> pin 3 - 50p
> pin 4 - 20p
> pin 5 - 10p
> pin 6 - Inhibit £1 ie rejects that coin if high
> pin 7 - inhibit 50p
> pin 8 - inhibit 20p
> pin 9 - inhibit 10p

AT WHAT LEVELS?
TTL or other...

> So there is a ribbon cable which comes from the
> mechanism and which I will take into the computer
> through serial (or usb) input.

> So at this stage, I need to work out the following
> if I am to use serial. Firstly, if I want to receive a
> pulse from pins 2-5, which pins on the serial port
> should I use and where would these appear in
> the filesystem. For example if somebody enters a
> £1 coin, it would cause /dev/tty? to be high, ie if I
> did "cat /dev/tty?" it would return 1, else it would be 0.

Be very aware of USB to <something> adaptors.

Windows is fairly friendly and gives the user/coder
some useful means of accessing them. E.G. a USB to
games port for example.
A USB to serial gives the coder a COMx: port although
it is in fact a USB device and the port can be accessed
from an MS-DOS prompt easily to set it up using MODE.EXE.

However Linux in all its wisdom allocates the dev/tty? NOT
as dev/tty? but dev/ttyUSB? where "?" is a single digit
number. I suspect yours will be ttyUSB0 in the dev/ drawer.

Please note logic 1 on a(n) RS232 style serial port is -3
to -12V NOT +3 to +12V. This is NRZ, (None Return to Zero)
so be VERY AWARE.

You will need some sort conversion HW if the logic on the
coin slot has TTL or any 0 voltage on it or is switching say
greater than 9V to ground etc, etc...

I hope this helps...

BTW AndyBaxman`s PIC method seems a fair alternative
if you have some limited coding experience.
_________________
73...

Bazza, G0LCU...

Team AMIGA...

AndyBaxman · LXF regular Joined: Tue Oct 04, 2005 9:47 am Posts: 520

jimdog · Joined: Fri Oct 02, 2009 4:31 pm Posts: 4

Hi All

Sorry for the late reply, been distracted by other things so just getting back to this project now. Thanks loads for all your replies - I'm very nearly there so just have one more minor problem to solve and it will work perfectly.
So here's the lowdown on where I'm up to starting with the hardware:

Found a really useful site for the specific coin mech (ME111 - 15W) I have here:

http://www.markscotford.com/marscon.html

Which gave me all the info I needed for the pinouts. The main power supply (12V) comes from a drive connector for the PSU of the machine I am using for the jukebox. The +5V is being fed into the 10p and 50p inhibit channels, and 0V is going into the 20p and £1 channels so they don't float. The Vcom (common voltage that comes out of the outputs when a coin is inserted) is receiving 12V. I have attached 2 relays next to the usb interface board, so that when a coin (£1 or 20p) is inserted, the relay is triggered by the +12V that it receives from the Vcom channel and the relevant pin on the microcontroller is set to low (default when switched on is high). Ok, so the hardware is all there and working perfectly, so now on to the receiving end for the USB signal.

I managed to find a C library for this interface board after much searching about here:

http://www.sourcefiles.org/Programming/Libraries/Networking/libdelcom-0.2.tgz

There were some example programs floating about which worked great with my board, so I set about modifying one of these to suit my needs. I also needed to figure out a way of sending the output to the currently focused X-window rather than outputting to the terminal and so settled on using the keysim.h and xtest.h libraries to spoof an x input signal. The upshot of all this bashing about is the following program which works great except for one minor problem which I will explain below.

Bazza · Posted: Thu Nov 19, 2009 10:20 pm Post subject:

Hi jimdog...

Here is an idea...

You could try a simple, (CPU hogging... ;o), while loop as
a temporary addition. See the end for example code.

I think you`ll need it at the point shown in your code below...
(Note my `childish` coding method. ;o)

If there are any typos then I will apologise but I have read
it many times and can`t see any.

It is inelegant and professional coders will snub it, but it is
worth a try however......

jimdog · Joined: Fri Oct 02, 2009 4:31 pm Posts: 4

w00t

I think I might have cracked it (though in a remarkably fudgey way). The answer was in the fact that I was registering both bit0/bit1 and the previous value at bit0old/bit1old. This means, that if a coin is inserted the values might look as follows: Taking bit0 (£1 coin) as an example~