Ruffsta:
if you look, there are tons of topics being made about multi coin acceptors because there is no general multi coin acceptor tutorial.
So, write one.
Ruffsta:
tho juma_yetu seemed to find it without even having the unit on hand.
So, why didn't you find it, download it, and post here?
You don't seem to understand that you're the one asking for help here. Why not make it easy for the folks who might volunteer some of their time to help you, for free.
Ruffsta:
why on earth would anyone even try to sell code when you can get it free with contribution and effort?
So, what effort are you making to contribute? Understand, you're not entitled to ANYTHING for free. As I said, someone might volunteer their time to help you, but to demand a tutorial be written because you need one is kind of arrogant. Why don't you look at the datasheets for your device along with the existing code that you can find and take a crack at doing it yourself? Then, when you run into specific problems, post them here and you'll stand a much better chance of getting help.
If you lack the intelligence, skill, or desire to do it yourself then be prepared to pay for it. This project obviously has some value to you. Other peoples' time and effort has value to them.
FWIW this whole software project is a days work at most to do properly - if the unit was on the desk in front of me - with a requirements/spec doc from the OP - which is still being written.
i did not say anything against juma_yetu. infact a ty is in order.. you wanted specific specs for the unit i do not have in yet due to shipping.. so ty juma_yetu but could you post it as i cannot?
secondly, i don't expect anything to be handed to me, i merely asked for a general tutorial to be made for EVERYONE... if you have the experience then you should write one so there does not need to be a thousand topics on it.. and if i could write one i most certainly would!
you know, lot of you have been on my ass since day one no matter how nice i try to be.. and really getting sick of people ganging up on me and turning my words around.. so you know what? fuck off with this anti-Ruffsta shit already.
help or don't help.. but if you're not going to help - then just shut up.. why does everybody have to start shit with every topic i start? i even tried to stay away for a bit but the minute i come back somebody always has to assume shit and throw their 2 cents in to stir up something..
a button infront - this will button will togle 2 portions to see the amt of coins saved.. since there is 6 and can only list 4 at a time.. press once to see the first 4 and press again to see the next 2 this will have a delay to go back to "insert coins" screen
MAIN SCREEN:
blank row
INSERT
COINS
blank row
press button once - screen changes:
Pennies: COUNT
Nickles: COUNT
Dimes: COUNT
Quarters: COUNT
delay if button not pressed to go back to main screen
press button second time:
Half: COUNT
Dollar: Count
blank row
blank row
delay if not pressed to go back to main screen
a reset button inside hidden - this will delete all counts
incase of power outtage, i want to store:
savings in dollar format ie: $1,000.00
save a count for each coin.. pennies, nickles, dimes, quarters, half dollars and dollar coins
Forget you have a coin counter... break the project into pieces.
Get your LCD working first, then throw some functions to display the pages you want.
There are hundreds of complete working examples to get that LCD working, and some with buttons as well.
Reset button is good.
How will you configure the (six) coin denominations (and names) ?
The EEPROM could be used to save your coin reference data.
Power failiure storage is good.
Work on your EEPROM writing & reading skills.
How are you going to detect the power failure?
You only need to save the total tally for the each ‘type’ of coin... the $value can be recalculated when it’s displayed using the coin reference data.
Ok, there’s a couple of days research and coding for you.
Feel free to check in to have your work marked.
Remember, it’ll be a lot easier if you think in code blocks & function()s.
Get each thing working by itself in a test container, then you can tie them all together.
Here’s an idea to help you along...
struct coin_type {
byte index; // the pulse count identifier from the mech’
char [16] name; // the friendly name - nickel, dime, penny etc...
unsigned int tally; // the running tally for this coin type
}
Remember liberal use of serial.print() can help when debugging - try to avoid delay()
J-M-L:
This ”should’ seems a bit of an intellectual shortcut here... not sure why one should....
so there is not a thousand topics on the subject, and should also because they can and know - share the knowledge..
lastchancename
not sure if i want eeprom.. cause this savings is constant and well the eeprom can only write so many times.. there has to be a better way.. right now my focus is coding it to add the coins to savings - saving i can work on later.
If you have TEN power outages a day, and save to EEPROM each time...
It will take around 27 years before you kill the EEPROM.
I reckon you can rest easy on that one.
lastchancename:
Just BTW, in your spec, nothing is displayed when a coin is inserted...?
Think more write less!
yes it will be displayed..
main screen - insert coin.. screen changes as you insert coin
INSERT
COINS
Your savings
$WHATEVER in dollar format including commas.. delay back to main screen INSERT COINS hence the constant saving.. why i'm iffy on the eeprom..
lastchancename:
If you have TEN power outages a day, and save to EEPROM each time...
It will take around 27 years before you kill the EEPROM.
I reckon you can rest easy on that one.
And could be more...
given you have plenty of eeprom -> Assuming 6 coins types - count for each saved on 32 bit uint32_t - this is 24 bytes of eeprom + a 32 bit timeStamp = 28 bytes
Assume a circular rolling write on 30 different areas in sequence (in 1kB EEPROM)
If you save at every coin to not handle power outage, that means you can accept 3 million coins... say 10 coins a day for a big saver = 820 years
If you save at every power outage (a bit of extra hardware needed), say 10 outage a day then that’s again more than 820 years....
Long story short ==> EEPROM is not an issue hardware (and everyone of us) will die before
lol.. i don't get 10 power outages a day.. but yeah, was just thinking of all the constant saving info.. my outages happen maybe 4 times a year.. and that's during the winter and maybe once in the summer due to them working on the lines or a car hits a pole...
k. i will look into the eeprom.. still need help with the coding. i'll do the saving later, right now i just want it working right.. but i still have to wait for the unit to come in..
also, @ lastchancename, i did want to restate that there will be 1 power supply instead of 2.. waiting to see crossroads will draw me up a diagram on that - i know i'll need some kind of 12v/5v regulator for now i can use my pc for the arduino - but in the end i want the bank plugged into the wall.. no pc 1 power supply
What’s all the saving for?
Don’t save to EEPROM for every coin, that’s unnecessary.
If the unit is always powered, detect the falling supply, and use a small electrolytic capacitor tokeep the processor up for a couple of millisecs for the save to EEPROM.
The only odd case is if you sink the hardware reset pin, which will stop immediately before the power-fail / save can be executed.
My own designs implement a soft-reset button & function that I have complete control of (including save to EEPROM!) - which is also called when power fail is detected.
P.S. this also works if the ‘battery’ is pulled or goes flat.
now yer talking outta my league - (capacitors, regulators)..i just want it to save in case.. you never know when an outage will happen.. split second and poof.. no power or if i unplug the unit... not like there is an on/off button. i know what they are, i just never used one.. so i don't know anything about them really
ok, leave the magic out for now.
Get all your coin-counter code working in RAM, and code up your EEPROM functions.
We can decide how & when to tie them together later.
Be happy without ‘saving across power breaks’ for now.
That’s the least of your problems.
The soft-reset trick could be a good idea for your project, as it lets you save before a ‘shut down’. No need to use the WDT, it could simply die gracefully with a message on the display “ ** CLOSED ** then an infinite loop.
Requires a power cycle to restart.
I hope you’re making notes, i want to see some code in the next few days!
well, the major part of the coding for me would be the insert coin and add to savings... which nobody has shown an example of other than mentioning "switch" so all i can come up with atm before bed is:
void loop()
int pulses = pulses(1, 2, 3, 4, 5, 6);
switch (pulses) {
case 0: // add 0.01 to savings
//
break;
case 1: // add 0.05 to savings
//
break;
case 2: // add 0.10 to savings
//
break;
case 3: // add 0.25 to savings
//
break;
case 4: // add 0.50 to savings
//
break;
case 5: // add 1.00 to savings
//
break;
}
delay(1); // delay in between reads for stability
}
which i know isn't right.. but it's 1:45am here and bedtime in a few
It seems that most of the programming is done on the device itself. You train it with some coins, navigate the obscure little internal menu, and in the end it will output a pulse when enough coins have been inserted to match your desired total. That is - the device itself does all the work of adding up the values of different types of coins. That makes sense, because you'd want the thing to be able to drive mechanical devices.
I don't see that programming for this device would be in the least bit difficult - it's no more complicated than detecting a switch, although you'd probably want to use an interrupt to be certain you didn't accidentally miss a pulse. It's 12V, but you can get a ruggedised 12v arduino. The output looks like it's floating or shorted to ground, so a pullup resistor and a common ground would be enough to make it all go.
