It would be better to have a separate thread (in the homemade section).
However…
I think it would be better to move the existing discussion.
We don’t need the admin, a moderator can do that.
Fortunately I happen to be a moderator, so I’ll do that for you.
(Moderators have a shield icon next to their name.)
You should be able to edit the title of the thread because you’ll technically own it, but if you can’t just let one of the moderators know and we’ll edit it for you.
That makes sense.
Yes please!
Of course, was mentally ticking off what most AVRs would have needed, not SAMDs.
I can definitely understand this and I am unlikely to pursue a new custom enclosure. I’d like to be slightly less constrained for space than the original so will probably look at a layered pcb / sheet plastic enclosure. I also have a 3D printer so can cover most things up!
Thank you.
A couple of games (including mine) use combinations like up and Down to reset high-scores. Not a big issue obviously.
Good example. I wonder if you could put the PCB pads there such that either discrete buttons or the joystick option could be soldered…
@MLXXXp @bateske forgive me if this is obvious but is there a BoM for Arduboy and in particular the dome buttons used? The ones in the KS edition look nice and gold-finish but was there a special extra-thick ENIG finish on the PCB to handle the number of presses without failure or are they “sealed” units?
I should make it clear, for those who aren’t aware, that I don’t work for, or am officially associated with, the Arduboy company/organisation. I’m just a relatively active user.
I’ve never seen a BoM published. There are schematics available. I’m not sure but there may also be Eagle files for the PCB.
I’ve documented the pin mappings in my original topic:
Button debouncing. I see that this has been implemented in SW in an alternative arduboy library. Seems like a 15mS delay is used which should keep up with the frame rate of ~60Hz but does the need to use an alternative library suit most developers and users (in terms of perceived responsiveness of the default SW or the alt library)?
I’m keen to hear from those who have experience with the original / current arduboy hardware if there’s much appetite for hardware debouncing in any new clone design…
I’ve never had a problem with the buttons.
Most of the time they’re only updated once per frame.
But then I spend more time writing code than playing games, so I might not be the best person to answer that.
Button handling functions from the ArduboyExtra library have been incorporated into the Arduboy2 library (with due credit as per the licence agreement).
Here’s a first draft schematic. Please could people comment so I can get a better revision before sending to the PCB house?
Ardugirl_01.pdf (116.8 KB)
Something many people have asked for is the ability to (accurately) monitor the battery voltage, to be able to indicate a low battery condition. A good way to do this is with a resistor divider between the raw battery output and ground, connected to an ADC capable input. (I didn’t do this on my prototype because I just wanted to get something going quickly and a spare analog input wasn’t available on the SparkFun SAMD21 board I used.)
You could use PA05, PB02 or PB03 for this. Here is a description of this technique:
The battery monitor divider is going to VCC. That’s not going to work. it should go to the battery output voltage. Also, you haven’t connected the divider output to an ADC input.
The battery is constantly powering the voltage regulator. Although this chip probably draws very little quiescent power, it will still slowly drain the battery. You should try to switch the battery completely out of everything (except maybe the charge circuit) when not in use.
This should address both those good points!
Are you missing the “Batt_Level” net or are you suggesting that PA05 isn’t an analog input? I was going from your previous post:
Or have I missed your meaning about not connecting to an ADC? Sorry, but some of this was done late at night!
An easy way to measure battery life if your analog reference is on a regulated voltage rail (assuming there is a boost converter to say generate 5V from a lipo whose voltage will always be less) is to tie the adc pin directly to the battery terminal. This way there is no drain from a resistive divider and your calculation is very simple. Alternatively I’ve also used the fixed trimmed internal reference in PICs with the battery voltage as the analog reference and then back calculated the battery voltage from the inversely varying measured value. And if you are set on using a resistive divider an easy trick is to tie the supply rail side of the divider to an output pin and set it high during reads and low or as an input so that there is no drain when not reading battery life (of course for accuracy you’d need to compensate for the tiny output drop caused by the nonzero impedance of the pin’s high side totem switch).
It looks good now. Before, the centre of the divider didn’t go anywhere and wasn’t labelled. However, the way you have it now the battery will always be connected to the divider and draw power even when the switch is off. I’d connect the top of the divider to pin 2 of the switch.
I don’t see any boost circuit in the schematic. The battery voltage is dropped to 3.0V by the MCP1700T regulator.
I was speak generally for different setups, but yes it looks like Simon is using an LDO so he would be limited to using a divider (but like I mentioned driving the high side by an output will solve the problem of current drain).
How is that going to work? An output, when set high, will always be (very close to) 3V since the processor is powered by the output of the 3V regulator. The top (and thus centre) of the divider won’t vary with battery voltage, which is what you want.
