Arduboy Kickstarter version design discussion

My apologies. I was thinking that the 54mm specified width of the Arduboy was for the board itself. I forgot to account for the fact that this measurement would also include the thickness of the sides of the case. :flushed:

Oh well, using right angle through hole headers should be adequate.

Oh snap, we wanted to put an N channel Mosfet on the Ground of the OLED so we can power it down in software too :open_mouth: almost forgot!

@bateske, Do you think an external Mosfet switch to power off the display is really necessary?

According to the OLED datasheet, with the display in software activated sleep mode it will typically draw only 1uA from Vdd and 2uA from Vcc, for 3uA total. The Atmega32u4 can draw as little as 1uA in power down mode, if the watchdog timer is disabled.

Without factoring in any idle power used by the power supply and other circuitry, let’s say the total would be 5uA. With a fully charged 180mAh battery that had no internal leakage, you could sleep for over 4 years.

Now, if any circuitry beyond the processor and display draws any significant power while the unit is asleep, then the 3uA sleep current drawn by the display is even less of a factor in overall sleep time.

In other words, is saving 3uA of current draw worth the cost of adding external power down circuitry for the display?

Good point, I had thought there was a reason to use the fet.

That breakout pins on the back is going to be so hard, I’ve scrapped it for now.

Maybe I can fiddle with it for later but it’s gonna take too much time.

Would be easier with 4 layers actually…

Could you at least place unconnected pads for the shield headers on the back edges of the board, and also place small pads on the back for each signal (using through hole vias if necessary) in any spot that’s easy?

This way jumper wires could be soldered between these signal and header pads, in essence doing what extra layers would allow. You could still connect any signals on the board itself that didn’t cause routing problems. The user would only have to solder in wires for the missing signals required for the particular shield(s) they wanted to use, plus the headers themselves of course.

The pads you showed for the 3x2 ICSP header aren’t really necessary, since I assume you’ll have pads for these signals somewhere, to allow on board bootloader (re)programming.

Some minor tweaks needed but teasing the copper layers what do you think ;D

3 Likes

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.

Summary:
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.