[WIP] Simon Merrett's Arduboy Clone

I have a 3D printer which I use for mechanical prototyping but the 2D version was waaay faster and easier for this purpose.

1 Like

I have added the kicad to Github and published it under the MIT license (so you can do pretty much what you want with it). Happy to share any footprints etc individually.

Why aren’t you using an STM H7 or a PIC32?

Overall it is a fantastic design and looks wonderful. Looks like art so far.

1 Like

@Seegson thanks for the compliment! The reason I’m using the SAMD21 is because I want to move on from the ATMEGA and ATtiny chips that I am familiar with from the arduino world. Moving to PIC would seem like more of a leap in one go than necessary. The H7 seems overpowered in the sense that I couldn’t see myself using it in my work designs, so learning it might be inefficient. I do want to get into stm32 development but more around the M0 and M4 end of things.

You are most welcome. I understand where you are coming from. I am excited to see how it all turns out.

1 Like

Ha wrong topic so i’ll Just leave this here for a reply

@Keyboard_Camper I have looked at those displays for other applications. Great for low power, daylight readability and reasonable refresh rate. But the price is too high for the size. I think the increasing availability is going to keep them as a niche product (you still need to provide a voltage toggle to maintain the display, even in low power mode).

Well, it seems like Ardugirl is in a race to not get made but the first run of PCBs went off to the fab last night. I hope to get them to the point where I have:

  • Bootloader loaded on the SAMD21
  • Direction + A&B buttons detected
  • Screen is writeable (mainly the HW as I know the software will need extensive work in this area to be suitable for games - plan to use u8g2lib or similar for a test)

Stretch target (at this early stage) is

  • RGB LED works
  • to read/write to SPI flash
  • get some sound out of the headphone jack
  • Backlight dimming

Will leave until later:

  • IR link between devices
  • Battery integration

If I get the first stage done in qty > 1, I hope those kind offers to help develop the software/port are still out there.

1 Like

What is the screen like?
Is it SPI driven?
If so, is there a datasheet detailing the commands it responds to?

It’s this one.
This code works to put an image on the screen, using u8glib from a pro mini:

/* HelloWorld.pde
"Hello World!" example code.

  >>> Before compiling: Please remove comment from the constructor of the
  >>> connected graphics display (see below).

  Universal 8bit Graphics Library, http://code.google.com/p/u8glib/

  Copyright (c) 2012, olikraus@gmail.com
  All rights reserved.

  Redistribution and use in source and binary forms, with or without modification,
  are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, this list
of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or other
materials provided with the distribution.

  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
  CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
  INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
  CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
  NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

*/

#include "U8glib.h"

// setup u8g object, please remove comment from one of the following constructor calls
// IMPORTANT NOTE: The following list is incomplete. The complete list of supported
// devices with all constructor calls is here: http://code.google.com/p/u8glib/wiki/device

//u8g_dev_uc1701_mini12864_hw_spi
U8GLIB_MINI12864 u8g(10, 8, 9);
const uint8_t  logo104x64 [] U8G_PROGMEM = {
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
  ..............................................................................................
  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
};

uint8_t contrast = 220;

void draw(void) {
  // graphic commands to redraw the complete screen should be placed here
  u8g.setFont(u8g_font_unifont);
  //u8g.setFont(u8g_font_osb21);
  u8g.drawStr( 0, 22, "Hello World!");
}

void drawbmp(void) {
  // graphic commands to redraw the complete screen should be placed here
  u8g.drawBitmapP( 0, 0, 16, 64, hundenlogo104x64);
}

void setup(void) {
  Serial.begin(9600);
  // set SPI backup if required
  //u8g.setHardwareBackup(u8g_backup_avr_spi);

  // assign default color value

  u8g.setColorIndex(1);         // pixel on
  u8g.setContrast(contrast);
}

void loop(void) {
  // picture loop
  u8g.firstPage();
  do {
drawbmp();
  } while ( u8g.nextPage() );

  // rebuild the picture after some delay
  delay(1000);
}

This is probably going to bite me in the bottom but here’s where soldering got to tonight:



Notes to self:

  • Buttons are rubbish. Select better ones for the next one.
  • Buttons feel like they could easily be closer together.
  • A & B feel like they should be higher up and perhaps shifted further into the PCB (moving screen towards direction buttons).
  • Joystick feels nice.
  • Footprints need resizing in many cases (mainly caps)
  • Silkscreen part codes clash - annoying to read during assembly
  • Headphone connector needs to be nearer board edge, or have the edge recessed towards it (can’t sit flush). Headphone connector unlikely to be soldered at this stage anyway
  • Power switch probably needs to be recessed away from the main board edge, to protect it - very delicate slide switch.
  • Micro USB connector should probably move back slightly from the board edge, unless this moves towards getting an enclosure in a future revision.
  • LCD backlight and volume variable pots sit nicely in their footprints - they were a bit of a footprint-generation gamble. May not solder them in at this stage
  • Consider mounting the variable pots on the rear, and maybe even the USB connector.
  • Add a SOICbite connector footprint for SWD.

I need to order the voltage regulator and caps, and the crystal and caps before I can finish the bare-minimum board population and move on to attempting to power up and burn a bootloader.

2 Likes

Oh, here’s the screen just placed (not soldered until I get the bootloader working and buttons recognised).


Here’s a footprint mistake I made for the mounting pins - can’t insert flush as a result! Shifting the main row by 1.27mm should fix that, and I also need to rotate the slots for the backlight terminals 90 degrees:

5 Likes

Here’s a simple test to check all the buttons work. I found that the 32kHz crystals and caps are relatively expensive and, despite having ordered a few to build this board with, I thought I’d chance a crystalless bootloader.

I opted for the adafruit itsybitsy M0 and this works nicely. I uploaded using the adafruit instructions for uf2 bootloader, along with Atmel Studio 7 and an Atmel ICE. The ICE header on this board was well worth it for the ease of burning the bootloader!

Despite my comment earlier that these buttons are rubbish, they are quite sensitive. The real problem with them is the lack of feedback - you can’t even sense the deflection, let alone a click.

You may notice that the power LED isn’t working. I’ve tried it in both orientations, so I don’t know what’s going on there - but who cares if you can get your RGB LED dancing to the tune of your buttons!

The joystick is a bit disappointing. I need to check if I have soldered it in the wrong way round - the connections are certainly wrong - up is down and down is up. That’s my problem, not the joystick’s - the problem I think the joystick may have is that it seems that you need to be depressing the centre button to register the direction pushes. Difficult to explain but there’s a small chance the likely-wrong orientation is to blame for this.

Attempting the screen next week. I need to plan a few devices for Arduboy SW ninjas to help with a SAMD21 port of the relevant libraries. Any takers, in principle? Preferably UK based, just to keep the shipping costs reasonable. BTW, if you know that I’m wasting my time because a SAMD21 port is done, please shout and link to where it is!

1 Like

Someone stole your screen!

Hah! That’s the most expensive part of the BOM and isn’t getting soldered until the critical cheap parts are verified functional. Next week hopefully.

1 Like

Might not be helpful, but Adafruit has a port for their SAMD51 handhelds, to be used in conjunction with their ‘Arcada’ library:



2 Likes

Well that does sound helpful, thanks. I’d definitely like advice from the SW ninjas on whether it’s better to adapt the arcada library to support the samd21 and the large lcd or whether it’s better to do something else. The key differences I think might cause issues with adapting the arcada lib are:

  • the buttons are either analogue or via a shift register.
  • The adafruit boards all have adafruit screen libraries written
  • samd51 vs samd21.

I could change the buttons (but prefer not to need a shift register in the BoM) and upgrade to the samd51 fairly easily but I would imagine the more people will have a samd21 based board at home / for cheap, for anyone who wants to diy this before making their own.

@Pharap, @MLXXXp and others, what do you think is the best way forward?

1 Like

Asking for me by name is of course an excellent way to curry favour. :P
(Fun fact: originally the idiom was ‘curry Fauvel’. Fauvel was a horse.)

The SAMD21’s spec is just slightly off the LPC11U68 (also a Cortex M0+) used in the Pokitto.

The main difference being the '21 has 32KB of RAM and the 'U68 has 36KB of RAM.

Unfortunately that doesn’t mean you could just reuse the Pokitto version of the Arduboy2 library because it’s based on the PokittoLib, which is in turn using mbed’s libraries which possibly wouldn’t work with the '21 and you’d need a particular environment to use them anyway.

What it does mean though is that an Arduboy2 port is completely realistic.

The '51 is a much more complex piece of hardware.
It’s got an FPU, twice the progmem, 6 times the RAM, a crypto engine and loads of other features.

Honestly I think @uXe’s suggestion of reusing Adafruit’s version is probably somewhat viable.
At the very least it’s a good starting point for replacing the assembly portions of the Arduboy2 library with some equivalent C++ code.

The remaining issues would be differences in pinouts and whether the '21 is fast enough to not need to drop to assembly.
It should be if you’re sticking with a black and white screen.
If you’re moving up to a colour TFT then it’s going to be more of a challenge.

I’ll admit it’s tempting (not least because I’m close enough to stop over, filch all your cream teas and be back before sundown if I didn’t hang about), but I probably shouldn’t add more things to my backlog.

I could probably help out later down the line,
but I’m of little use for the hardware side of things anyway.
When the hardware’s been decided on I might be of more use.

I’m going to be completely shameless and point out this commit. :P

The code was indeed borrowed from the Pokitto Arduboy2 port (or at least the older version of it).

Definitely - that’s really starting to stand out as a defining feature of an Arduboy-derivative. This project will stick with monochrome. If this LCD doesn’t work out, I’ll look at other monochrome options, so we can focus libraries only on BW.

Excellent. This is enough for me to stick with the SAMD21G18A

Yes, I’m not far off nailing that down. In fact, having looked a little at the Arduboy2 repo this morning (for the first time - can you tell I’m more into the HW than SW? :laughing: ) I don’t think keeping the buttons as digital inputs is an issue now.

@Pharap (now I know how to summon you!) what info would you want from the HW spec to make porting easier? I presume a schematic is ideal for EEs but the embedded dev would probably prefer some pinout / port tables rather than having to search a schematic matching up net labels.

1 Like

Speaking purely for myself, though I presume others might agree…

  • The CPU pinouts, including whether they’re digital, analogue, PWM capable and what they’re actually connected to. Specifically with descriptive names - don’t use strange symbols like ∅ or abbreviations like RDY specify ‘clock’ or ‘ready’.
    • Doesn’t need to be all the pinouts per se, but at least all the important ones and one or two unconnected pins - for seeding the PRNG.
  • The datasheet for the screen specifying which commands it accepts (assuming it’s one of those screens that has a chip controlling it that takes commands over I2C or SPI). I doubt you’ll find them listed outside the datasheet anywhere unfortunately.
  • Info about the sound hardware (though I’m still pretty useless at sound so it probably won’t be me handling that one).

Essentially whatever’s needed to know how to interface and control the hardware.

You presume right. I can’t even read half the board schematics I see.

Datasheets I can just about manage to skim relevant information from,
but it usually takes quite a bit of searching to separate the wheat from the chaff.

1 Like