Arduboy Kickstarter version design discussion

I assume the second one is reversed for ease of reading.

I didn’t catch it earlier, but it looks like there is a resistor in the speaker loop. @MLXXXp did testing that established the speaker resistance alone would be sufficient for protection. What value will that resistor be? – and what will the larger speaker be, since it might have a different resistance?

It looks like an “Arduboy” label is sitting where the speaker used to be. I’m figuring that the speaker connects to the two square pad just up and to the right of the ATmega? But where does the speaker sit?

The second one is yeah, reversed to what you would see printed if you actually looked at the board. This is what comes out of OSHPark board rendering, so it looks similar to how it is designed in the EDA layer view of top down.

For the resistor and the speaker, in general when you are using the piezo elements everything ends up sounding the same.

The new plan for the speaker is to use a bare element soldered to the back that is taped down to the battery and pcb. Here is a picture of testing:

Adding pads for a resistor can’t hurt. If it turns out not to be needed then a zero ohm “resistor” (essentially a jumper in a resistor package) could be placed there.

I’d also consider adding pads for a capacitor across the speaker leads. Along with the resistor, this capacitor could form a 1st order low pass filter, which could act as a reconstruction filter to make PWM generated music sound better. If there’s room available for this, there’s really no down-side to adding it because the pads could just be left unpopulated if it was felt it wasn’t necessary or something for the user to experiment with.

1 Like

It appears that the processor output pins are connected directly to the display inputs, with no level shifting. Since the display inputs are specified maximum 3.3V then you must be running the processor at 3.3V as well. If this is true, are you still planning to run at 16MHz, thus overclocking the processor?

Only concern with switching to the circular piezo element is sound quality. They tend to have strong resonant frequencies- I assumed that’s why you selected the original square part? Have you tried running some (chip)tunes / sound effects that sweep over a range of frequencies?

Kevin, have you noted @MLXXXp comments about the interfacing levels to the SSD1306?

Here’s the snippet from the datasheet.

Even with Vdd at the maximum of 4V, the max Vin is 4.3V. If you run the ATmega at 5V, this is well beyond the maximum ratings.

1 Like

And you don’t use absolute maximum ratings for proper design.
From the datasheet:

Maximum ratings are those values beyond which damages to the device may occur. Functional operation should be restricted to the limits in the Electrical Characteristics tables or Pin Description section

Also a reminder that when devices are operated outside specs, past successful results are no guarantee of future performance.

Every device you test in such a non-spec circuit could work fine, but an internal engineering change by the part vendor just before you build 10,000 devices might suddenly give you 100% failure rates, with no recourse because the system operates the device beyond documented limits.

@bateske There seem to be some small errors on your schematic:

  • PB4(ADC11) is D8/A8
  • PB5(ADC12) is D9#/A9
  • PB6(ADC13) is D10#/A10
  • PD6(ADC9) is D12#/A11
  • PB0(SS) is D17/RX LED
  • PB3(MISO) is D14

When @bateske adds a level shifter, I can see that there are five signal lines between the ATmega32 and the SSD1306 that need this conditioning. In one of the other threads, you referenced a bi-directional level shifter to handle this.

Now, this is most definitely not my strongest area, but I thought all the signals were uni-directional – from the ATmega32, towards the display module. Am I misunderstanding something here, or is there a possible cost-saving if the level handling only needs to go one way?

You are correct; you only need uni-directional level shifting. The question is, is there another design (perhaps using an IC) that would be cheaper? It’s something that would have to be investigated and costed out.

Note that since you don’t need bi-directional capability, you can eliminate the resistor on the input side of each shifter in the design of the MOSFET based module that I referenced. Also, for the lower speed signals, (RESET, D/C, CS) you can get away with a level shifter consisting of just a diode and a resistor, as implemented in this design (where you also wouldn’t need R6 and R8).

I would advise against putting DC on pin 13 as it is an essential pin and it is not available on the Pro Micro. Instead, RST could be moved to pin 13 as it is non-essential (it can be generated with a 4.7k resistor and a 100nF capacitor).

Therefore I would suggest either:

  • CS 4, DC 6, RST 13
  • DC 4, CS 6, RST 13

The later one has the advantage of being nearly the same as the first Dev Kit (DC 4, CS 6, RST 12).

If you don’t put anything else on the SPI interface then you don’t need to control CS. You can just ground it to leave the display selected at all times.

So, perhaps it would be even better to put CS on pin 11 and put the blue (or other color) LED on pin 6. This way, a Pro Micro based version would have full control of a RGB LED.

DC 4, CS 11, RST 13,
RGB LED 6 9 10 (any color order)

For a Pro Micro, pins 11 and 13 aren’t available, so you would use a resistor and capacitor for display RST and tie display CS to ground.

A Pro Micro also doesn’t have pin 12 available, so you would have to tie one lead of the speaker to ground. Hopefully this would have a fairly low impact for most sketches.

I am afraid PWM for pin 6 is on Timer 4 so it would be better to avoid for the same reasons you gave yourself for pin 13. Losing the blue LED on the Pro Micro is not a big problem in my opinion.

I had not thought about tying CS to ground. I have read that it is not recommended to do that as some chips use the CS signal to synchronize with the clock signal in case the controller misses a bit. In the SSD1306 datasheet nothing is mentioned about that so to be sure we would need to do tests with a noisy SCLK signal.

You’re right. I hadn’t looked into that kind of conflict.

Unless someone designs a game where the color of the LED is an important indicator for game play.

The OLED module that I used for my breadboarded system only has 6 pins:

CS is tied internally to ground. I haven’t noticed any problems with it.

As interesting as this is - no sarcasm there, it is interesting - I’d really like an occasional update from @bateske that this discussion is at least noted. That last circuit diagram is great evidence of progress, but there still appear to be some necessary tweaks to get to a “worth 10000 copies” version.

@chriss Discussion is of course noted :slight_smile:

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.

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.