(†) speaker pin 2 output is connected to speaker pin 1 on DevKit hardware
To prevent the IO pins from possible damage, speaker pin 2 should NOT be configured as an output.
(‡) Flash cart support
Flash cart support (original design) :
0 PORTD2 flash cart chip select
14 PORTB3 flash cart data in (MISO)
or
Flash cart support (new design) :
2 PORTD1/SDA flash cart chip select
14 PORTB3 flash cart data in (MISO)
(§) When using serial flash with the Pro Micro standard wiring, OLED_CS (chip select) cannot be grounded (always active)
In this case a simple circuit with a general purpose PNP transistor and two resistors or a single inverter chip like the 74LVC1G04 can be used to deactive OLED_CS while CART_CS is active.
When using an I2C display the SDA pin should be connected to pin 4 PORTD4 and the SCL pin to pin 6 PORTD7 unless you’re using a Pro Micro with the alternate wiring scherme. In that case SCL pin should be connected to pin 1/TXO PORTD3.
Note that updating a I2C display is slower than a SPI display. To get the most out of an I2C display, the display update code is optimized using assembly and bitbangs the display at 2 Mbps or 2,66 Mbps (uses more progmem).
At 2 Mbps the display update will be 4.3 times slower than when a SPI display is used and 3.1 times slower at 2.66 Mbps. Games will still run smootly at 60 FPS when the main program requires less than %70 (2Mbps) or 78% (2.66Mbps) of MCU power.
It looks like you decided not to put a capacitor on AREF, as I had suggested. To bad
You should consider releasing the schematics for the DevKit as well, since the Tindie site has said for a very long time (emphasis mine):
We still owe you documentation, schematics, board files, drivers… everything you need to fully realize the Arudboy game system. Please pardon our construction as we work to quickly fill these gaps!
All the pins have test pads so you can fairly easily add any components you like. They are under the battery unfortunately due to layout constraints but if you’re adding these kinds of functions it shouldn’t stop you.
For sure, we did release the original schematic and board file for the prototype in the first youtube video. The dev kit isn’t much different but sure I will post it!
Sure, skilled people can add a capacitor. I could probably do it even without pads. But, If it turns out we are able to do battery level monitoring using the ADC, and add functions for it in the Arduboy library, shipping with an AREF capacitor installed may have improved this capability for everyone.
The number of people who can’t add a capacitor but want to have fine precision on their ADC readouts on the arduboy is probably so close to 0 it might as well be. But that’s why we are proud to introduce Arduboy Plus! It’s got all the features we intentionally left out of our first product in order to force obsolescence!
Its not a cost issue but complexity/footprint/aesthetics issue.
The positive thing to look at here, is in the future I do actually want to break pinouts to external connectors so at that point it actually makes a ton of sense to put the component there. And if anything thats the lesson is to make sure its easier for people to do more things with it that I haven’t planned. So in that regard, yeah it’s a little closed and limited on the I/O right now, but thats just to make it more simple and easier to produce for now.
I do always appreciate the input but I’m also balancing a lot of different issues so it’s never personal the decisions I make with the product. As illustrated in the image above I’m just trying to have a good time and would love to add all sorts of cool features in the future.
We should talk, something like a 3-4 wire serial cable and a simple port (or even header - male or female) would be amazing. Then just plug two Arduboys together for 2 player gaming and we can figure out the protocol later…
If you’re lazy you could wire out the serial RX and TX ports or something… other wise we’d have to build our own software SPI, but that’s not the end of the world.
Yes, it’s just to improve noise immunity. From the datasheet (emphasis mine):
AV CC is connected to the ADC through a passive switch. The internal 2.56V reference is generated from the internal bandgap reference (V BG ) through an internal amplifier. In either case, the external AREF pin is directly connected to the ADC, and the reference voltage can be made more immune to noise by connecting a capacitor between the AREF pin and ground.
So it’s just a “nice to have” addition that would have been easy to implement and inexpensive. And for such a small component, I can’t see that board space or aesthetics would have been an issue.
As far as software filtering goes, it depends on how much noise is picked up. The battery readings between charged and discharged will only cover a small portion of the total ADC range, so the more accurate the readings are, the better, for determining charge level, time remaining, etc.
I’m not sure that a capacitor is any more accurate than software smoothing… they are both taking the exactly SAME raw output and filtering it. Now obviously a capacitor has the benefit of being hardware vs software, but I think we can model the exact same behavior in software without much effort. The simplest smoother would start the the initial value (or get two) and then just loop check current vs previous and restrict movement of the artificial value by either a fixed amount of a portion of the actual move. Fixed amount produces the steadiest signal.
I was already playing with this idea just the other night.
I’m not saying that that exactly models a capacitor, only that such a thing would be doable… I don’t know enough of the electronics to do it exactly. Someone who did could probably give you some math though.
Even if software filtering work as well as a capacitor, it take extra code to do it. That space would be lost to a sketch if it used a battery check function.
No use crying over spilt milk. The fun all comes in seeing how little software builds a great battery sensor… I read the problem with these nice rechargables though is the voltage doesn’t really drop until the end and then it just falls off, so without access to the charging circuitry it’s not really all that useful to just know the raw voltage. We should make a thread of just this topic.
It is possible to use the bandgap in software to read the system voltage. However in order to be accurate, each unit would need a calibration figure adjusted to it. You can of course run this calibration yourself. But I figure that even with a default value you’d be able to get at least 20% accurate which should be sufficient to give you a 4 segment battery readout or at the very least a low power indication.
I do regret not putting in a battery charging IC that has another leg for a fuel gage, they exist and I basically just got busy/ran out of time/patience with the design for kickstarter. This is almost certainly something that will get added.
Maybe not. The voltage range that the battery covers between full and low is so narrow, compared to the full range of the ADC, that without calibration, the error in some units may be to much to accurately determine a low level.
Without full schematics available, to look at all the components and implementation of the power circuitry, it’s hard to say for sure.
