@chriss Discussion is of course noted 
Mostly, I note that it is impossible to make everyone happy with a circuit board layout but certainly will try! Things won’t be locked down for a week or two more when I get the first batch of PCB made.
@bateske,
I’d be interested in knowing the latest design decisions and specifications. Mainly:
-
You were looking into using a boost regulator, to run at 5V and allow 16MHz operation. Has this been done?
- If not, will you be running at 8MHz or overclocking to 16MHz?
- If so, has the 3.3V maximum for display power and signals been addressed?
-
Is there any capability to indicate and/or measure battery charge/discharge levels?
Publishing a more complete schematic would be nice, though I would understand if you were hesitant to do so.
Good point about the charge feedback. As far as levels and voltages, I’ll ask atmel and arduino this weekend at maker faire and if they tell me I need a boost converter then I guess that will be my answer. ;p
1 Like
Well, if they tell you that it’s OK to run at 16MHz below 4.5V, contrary to section 29.5 of the datasheet, see if you can get it in writing. Also see if they will update the datasheet with this new info. I’m sure that there are a lot of developers out there who would be pleased to hear it.
@stg suggested that we should use pins 6/12 instead of 5/12 for the speaker.
The reason is that mixing two tones in software on pins 6/12 does not take more cycles than mixing in hardware by setting two different timers on pins 5/12. The advantage of pins 6/12 is that their PWM outputs are symmetric (OC4D and _OC4D) which is the perfect solution to produce a louder sound (-5V to 5V instead of 0V to 5V). Timer 4 goes up to 62 kHz, which is plenty for us (31 kHz should be enough).
I also tested connecting CS to ground which works perfectly fine and would be a solution for the Pro Micro. I therefore advise to put CS on pin 13.
Summary:
DC 4, RST 5, SPK+ 6, SPK- 12, CS 13
Although this is one mode of operation, it would limit options, because 6/12 must always use the same comparator. 5/12 gives the benefit of using two different comparators (_OC4D and _OC4A) running on the same high speed timer.
It should be possible to use the core timer, but run two completely different generation patterns on the different comparators, since control of the comparators is what is used to manipulate high-frequency PWM sound generation. The effect at the speaker is to just mix the two signals.
If you instead just want louder, comparator 4D and 4A can be set up almost identically, but with opposing outputs. Although both are inverting outputs, changing the Output Compare Mode on one of them is the key to getting two matched but out of phase signals. There is a slight additional effort to store each “louder mode” comparator change in two places instead of one, but the calculation effort to determine the new comparator level does not need to be repeated.
@MLXXXp did testing on a number of these options; I think he was using some of the core functionality from some of the existing high-frequency PWM music libraries that are already available.
And additionally, Pin 5 can optionally use a totally different timer (OC3A on Timer 3) than Pin 12. This gives even more flexibility.
No, I didn’t do any PWM testing. I only used various combinations of fixed and complimentary square wave tones, for mixing and volume control testing. Posts regarding this are here, here and here.
@bateske,
Did you talk to Atmel and Arduino people at Maker Faire about this? If so, what was their response?
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.
2 Likes
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).
1 Like
Good recap!
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.
@bateske,
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)?
2 Likes
Pins 5/13 for speaker
Pins 9/10/11 for the common anode RGB LED (with opaque lens)
1 Like
Respectfully, I think you mean a diffused not opaque lens. 
An opaque lens wouldn’t let any light through.
1 Like
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.