They said I should see no problems at all, that they run it outside of spec all the time. They just need to cover their asses in their data sheet so there is a considerable margin applied. Basically since we are operating outside of the range, they would not support the chip if there was problems. But we haven’t and shouldn’t see any problems with it.
I’ve been running over 9 prototypes fairly consistently charging and discharging non-stop for the past 3 months and have no issues. The only failures I’ve ever had throughout this project were failed solder joints on stuff I put together myself
But we will be doing production in batches, so the first 200 units go out to developers if we have any problems then we will be happy to replace units and we can make a change for the next run.
A discussion in the Music library brainstorm thread, as well as in this thread and on IRC, has come to the conclusion that Arduino pins 5 and 13 are desirable to use for the two speaker leads.
@davidperrenoud has proposed the creation of a DIY Arduboy Kit, possibly using a Pro Micro board. Based on his observations, in order to best accommodate the limitations of the Pro Micro, I’ll summarise the desired pin mappings for the production Arduboy as follows:
- Speaker leads: 5 (PC6) and 13 (PC7)
- Display DC: 4 (PD4)
- Display CS: 6 (PD7)
- Display RST: 12 (PD6)
- Button A: 7 (PE6)
- Button B: 8 (PB4)
- D-Pad buttons: A0 (PF7), A1 (PF6), A2 (PF5), A3 (PF4)
- RGB LED: 9 (PB5), 10 (PB6), 11 (PB7)
- Battery monitor (if implemented): A4 (PF1) or A5 (PF0)
Note that all the display control pins are mapped the same as the current Dev Kit, making it a bit easier for a common library.
The order of the assignment of the three RGB LED colors to pins 9, 10 and 11 is arbitrary but if one color is considered less important than the other two, it should be put on Pin 11, because Pin 11 isn’t available on a Pro Micro.
I’d suggest blue on Pin 11. Blue generally doesn’t have much meaning but red/green can indicate stop/go, no/yes, bad/good, etc. Also, a two color red/green LED could be shifted from red, through various shades of orange and yellow, to green to indicate, for instance, a character’s health or weapon’s power level.
I myself have full color vision so I can’t speak for those with a red/green color deficiency, who might argue that having green/blue or red/blue is more desirable. However, I’d suggest that a kit that could only support two colors have spots for both a bi-color LED and two single color LEDs to better accommodate those people with color vision deficiencies.
I’m still not sure which button is A and which is B but note that the one we want to be capable of generating a standard Arduino int.4 interrupt should go on Pin 7 (PE6).
For the Pro Micro, I would prefer RST 6 and CS 12, as CS can just be connected to ground.
Note that the Caterina bootloader will need some small modifications in order to map TX/RX/LED to the RGB LED. With the actual bootloader, the action of uploading generates a cool sound on the speaker which might get annoying after a while.
Of course, that would be fine as well. But note that with CS grounded it wouldn’t allow hackers to add additional devices to the SPI interface along with the display.
RST on the other hand, can be done in hardware on boot up with a resistor/capacitor circuit (as you’ve mentioned), provided that there’s no need to reset the display after its initial power up.
I guess another option would be to follow your suggestion of RST 6 and CS 12 for the Arduboy but for the Pro Micro kit have solder jumpers so that CS could be grounded or tied to one of pins 0, 1, 2 or 3. Hackers would then have to re-map the display CS pin in the library, though.
In your Nov. 6 update on Kickstarter you stated:
We’ve completed all the DFM and all of the files are submitted.
So can you tell us what the final I/O pin designations will be?
Is it as shown in the schematic in this post above, with the speaker on pins 5 (PC6) and 12 (PD6), or did you change it to put the speaker on pins 5 (PC6) and 13 (PC7) (which the discussion determined was probably best)?
Which 3 pins are used for the RGB LED and what color is on each? Is it common anode to Vcc (i. e. a low on the pin will turn the LED on)?
Pins 5/13 for speaker
Pins 9/10/11 for the common anode RGB LED (with opaque lens)
Respectfully, I think you mean a diffused not opaque lens.
An opaque lens wouldn’t let any light through.
Black LED light muahaha ;D
I’m confused here, what is causing this sound on the speaker? I don’t think we ever hooked up the speaker to the RX/TX Leds?
The bootloader on my Arduino Micro also toggles pin 13 while downloading, which we’re using for one of the speaker leads. Pin 13 commonly has an LED attached to it, as is used for the standard “blink” sketch. However, I believe pin 5, which is the other speaker lead, is left as an input, so the speaker should remain silent.
When I wire the speaker to pins 5 and 13 on my breadboarded system, it remains silent while downloading.
If I wire the speaker between pin 13 and GND, I get the sound that @davidperrenoud describes (but the production Arduboy won’t have the speaker wired to GND like this).
Damn it blinks the pin 13 led too huh I thought it was just the rx/tx lights. We have individual leds for the rx/tx lines and also charge indicator. So we have 3 discreet LEDs and the rgb on board.
I’ve got to go in and double check the factory sources the DIFFUSED led for the indicator lights too to try and cut down on the annoying glow when constantly plugged in.
They are also placed at the bottom of the board near the USB connector so also won’t be in your eyes looking at the screen.
@davidperrenoud suggested switching dc and cs pins to maintain arduino micro compatibility. We might be able to sneak this in.
I’ll post a schematic shortly
Like I said, as long as the other lead of the speaker is on pin 5 (not tied to ground or Vcc), the speaker should remain silent even if the bootloader toggles pin 13. While the bootloader is running, pin 5 will be a high impedance input, so the speaker is essentially disconnected.
However if it turns out to be a problem, a simple change to the bootloader can be made so that pin 13 isn’t used. Likewise, the bootloader should leave the TX and RX LEDs off when not actually downloading a sketch. Presumably, you’ll be using your own USB vendor and product IDs, so you won’t be using an entirely “off the shelf” bootloader anyway.
The TX and RX LEDs will also blink when using the standard serial functions to send and receive serial data over USB. If this is a problem, a custom serial library, that doesn’t control the LEDs, would have to be used.
Additionally, sketches will be able to directly control the TX and RX LEDs, if it’s desired, which is actually a feature, not a disadvantage.
Actually, if you’re referring to his most recent post in this topic, he would like CS and RST (not DC) swapped.
So the suggested pins for display control are:
DC: 4 (PD4)
RST: 6 (PD7)
CS: 12 (PD6)
We’ve been talking offline the concern is that 12 is CS, because 12 is not on the micro but its OK because it can be tied to ground.
If you’re going to sneak in some last minute changes, would you put a decoupling capacitor (100nF/0.1uF is commonly used) between AREF and ground, if you haven’t got one already?
This is to improve the noise performance of the ADC. I think we’ll be able to use the ADC to compare Vcc with the bandgap, to determine the battery voltage (assuming Vcc is powered directly from the battery), so the cleaner the conversions are, the better. It would also benefit any hacks using analog inputs.
Even if you decide not to populate the capacitor, having the pads there would be nice.
I know it’s late in the game to be proposing design changes but…
This assumes that we end up using a piezo speaker directly attached to the I/O pin(s), not through an amplifier circuit. More discussion on this here.
My proposal is that we move the piezo speaker from pins 5 (PC6) and 13 (PC7) to pins 6 (PD7) and 12 (PD6). The reason is that pins 6 and 12 can be used as ADC inputs while 5 and 13 can’t.
A piezo element can be used to generate sound when you apply a varying voltage to it but it will also generate a voltage when pressure is applied to it. By setting a speaker pin as an analog input, we could possibly detect taps on the case of the Arduboy, which could be used as another control. The Arduino Knock tutorial gives an example.
I’ve tried this with my home made Arduboy equivalent system and it works well, even with (or without) a 10K resistor in series with the speaker, that I’ve used to reduce volume. I added the 1M resistor in parallel with the speaker, required to make detection work properly, and found that has no noticeable affect on the volume when outputting sound.
Since pins 6 and 12 can provide complimentary PWM output (OC4D), the same as pins 5 and 13 (OC4A), we would still retain the multi-channel music capabilities that have been developed. The current functions assigned to pins 6 and 12 (display CS and RST) could be moved to 5 and 13 without much issue.
Pressing a button might falsely be detected as a “tap” but this could be filtered out by testing if a button was pressed at the time that the tap was detected.
I don’t know how well this would work on the production Arduboy, or if it would actually be useful, but I can’t see that it would hurt to make the change “just in case”.
The downsides :
- Is there time to make the changes?
- A 1 Meg ohm resistor would have to be added in parallel with the speaker.
- We would lose the possibility of a second separate PWM channel using OC3A on pin 5, but I believe it’s been determined that there isn’t much call for this.
- The pins used to control the display’s CS and RST pins would have to be different from the Dev Kit but the library should take care of this, as it should for the buttons since they’re all changing to different pins.
Please no more HW changes! Features stated for KS simply need to ship. Enhancements can be provided in v1.1, v2, etc… Also, IMHO, this feature is of limited use.
I thought there was some sort of “voltage leak” issue or something if you “slept” the display (turn it off, try to get it to use as little power as possible) without powering it down completely… I thought it was
bateske that said that originally… like it could be harmful long-term… obviously for deep sleep it’s nicer to completely power-off the screen, but if we can’t have that then 3uA ain’t bad.
Honestly we need to tweak the standard bootloader to use the right pins… (if we can re-flash the bootloader on all the chips)… so whatever pins we decide are for LED we can use for LED. And we can make sure these is no audio… but yeah the default bootloader blinks 2-3 different LEDS IIRC… 13 and TX/RX. Been a while since I looked.