Go Down

Topic: Coin Counter (Read 11192 times) previous topic - next topic


May 17, 2011, 04:51 pm Last Edit: May 17, 2011, 04:55 pm by Graynomad Reason: 1
it doesn't even need to be an true LCD it can just be a digit counter, that is just used for numbers.

You can get 7-segment LCDs like in a multi meter, I haven't seen them around for years but there must be driver chips for them (we used to use XOR gates).

Or you could use 7-segment LEDs, no speed issues with them.

Or "serial" displays where you just spit out serial data with the numbers.

Rob Gray aka the GRAYnomad www.robgray.com


Yeah that is what I was thinking of, How many of those can I run off of arduino mega (7 segment LED), with 30 of the digital ports taken? I will need to run atleast 8...


Maybe something like this?


If you use LED driver chips like the AS1108 (this does 4 7seg displays) you can run as many displays as you like with 3 pins.

MAXIM also make chips (like the MAX7219) that will run these displays, some go up to 8 displays per chip.

Rob Gray aka the GRAYnomad www.robgray.com


Awesome, if I happen to get this job, do you guys think it can be done? If it can I would be willing to hire your help, but I will have to build that cost into the prototype, so if anyone can do it, let me know. Thanks!


This can be done, it just needs some deep thought.

I'm not sure a method of counting the 30 coins was proposed yet. I was going to suggest PCINTS but there are only 24 of them.

I do have an idea but it's late here, if nobody has come up with something by tomorrow morning I'll post it.

Rob Gray aka the GRAYnomad www.robgray.com


Awesome, thanks a lot!


May 18, 2011, 04:29 am Last Edit: May 18, 2011, 04:33 am by Graynomad Reason: 1
It's morning and no other takers so here is a rough start. As I see it you need to read 30 inputs fast and although the signals should be pretty clean from the opto sensors (depends on the sensor) they probably still need debouncing.

The debounce library may do this I haven't looked at it.

Done for 32 coins, will need slight adjustments for 30

Off the top of my head, thoroughly untested, not compiled, probably has bugs and maybe even logic errors. I think the basic idea is sound, but then I'm not the one putting the tender in for the job :)

Code: [Select]
// Wiring must be organised such that the sensors are connected
// in groups of 8 to to procesor ports
// Assumes
//    4-digit coin counters, ie 9999 coins max
//    digital input goes HIGH when coin over sensor

#define TRANSITION_TIME 50  // # of mS it takes a coin to pass the sensor
#define N_COINS 32

byte ports [4] = {PORTC, PORTD, PORTF, PORTG};
byte debounce_counters [N_COINS];
boolean coin_passing [N_COINS];
int coin_counters[N_COINS];
int display_timer;

void setup () {
// do some stuff here
SPI.begin(...); // etc
for (int i = 0; i < N_COINS; i++) {
coin_passing[i] = false;  // shouldn't really need this

void loop () {
static display_counter = 0;
byte group = 0;

for (int port = 0, port < 4; port++) {
byte portval = ports[port];  // get 8 sensor bits
// now test each sensor bit
// increment the sensor's counter if the bit is 1
//      and we didn't just do so,
//      ie the coin is still passing from the last count
// clear the sensor's counter if 0
for (int sens = 0; sens < 8 sens++) {
if (portval & B00000001 == 1) {
if (coin_passing[i]) {
coin_passing[i]--;  // coin is still passing from last count, dec counter
} else {
debounce_counters[port + sens]++;  // one more closer to being a valid coin
} else {
debounce_counters[port + sens] = 0; // any 0 value and we start again
portval >>= 1; // move next bit into position 0

// now we have an updated array of 32 counters
// test to see if any have reached the debounce value
for (int i = 0; i < N_COINS; i++) {
if (debounce_counters[i] > DEBOUNCE_TIME) {
// we have a new coin
debounce_counters[i] = 0;
coin_passing[i] = TRANSITION_TIME;

// every 100mS send the counters out to the displays,
// assumes a string of N_COINS AS1108 shift regs or similar and 4-digit counters
// for 32 displays we need to shift 32*4*7 bits
// at 8mMHz this will take 112uS plus some overhead
static temp_array[4];

if (display_timer >= 100) {
display_timer = 0;
for (int i = 0; i < N_COINS; i++) {
func_to_convert_bin_to_BCD (temp_array, coin_counters[i]); // there may be a library func for this
SPI.transfer (temp_array[0]);
SPI.transfer (temp_array[1]);
SPI.transfer (temp_array[2]);
SPI.transfer (temp_array[3]);
delay (1); // 1mS delay added to the time it takes to do the above

Rob Gray aka the GRAYnomad www.robgray.com


Thanks Graynomad! I think I am going to order a few of those sensors to test to see if I can get it to work. Do you think I can hit you up sometime outside of forum if I need a little help? Okay well a lot of help?



No guarantees but I'm happy to help.

As there are much better coders than me here I take some comfort from the fact that no one has pinged me on the code yet, or maybe they just haven't noticed the thread :)

Rob Gray aka the GRAYnomad www.robgray.com


... I take some comfort from the fact that no one has pinged me on the code yet

Rob, I don't see anything non-functional. Perhaps there is a certain down-under accent to your declarations but even an old Yankee can understand them.



No matter how hard I try I just can't get that Aussie twang out of my variable names :)

Rob Gray aka the GRAYnomad www.robgray.com


You are asking quite a lot here especially given your current state of knowledge.

Are the light sensors only detecting the presence of the coins? If so then you need a digital one. You should not rely on ambient light you should shade the system and use only the lights under your control.
How are you detecting the difference between these coins?

I made a coin counter many years ago that used light sensors to detect the diameter of coins as they rolled down a slot.
Are you planning to build this yourself?

Hi. I am interested in what you said about using light sensors to detect the diameter of the coin. Could you maybe send me a personal message about how you built it.


I wrote an article to do thin in the July 94 issue of the Micro User Magazine.
PM me your email address and I will send you a copy.
The software is written in BBC basic but the hardware should translate. However it does use a TSL214 CCD sensor that you might have trouble getting hold of these days.

Go Up