My Preliminary Schematic

Development
1

Goal: It is open source, and aims to be functionally equivalent to the official hardware. Because it strives to reflect the state-of-the-art, it can serve as a reference design to other people in the community. From my perspective this is very important, since the “official” hardware remains proprietary at this time, and a proper “open” version does not yet exist. (maybe? let me know.)

My design uses slightly cheaper components (with the exception of the MCU itself; I hope to port to a cheaper Arduino-supported microcontroller in the future, namely an STM32 clone or the ESP32).

In this particular implementation I also made some specific changes to tailor to my need, since I will be teaching a high school class using this hardware. Some changes/improvements are explained below:

  1. For student handling safety, the battery was chosen to be a hard casing 14500 cylindrical cell instead of the original pouch cell. Furthermore, it has been determined that the protection circuitry (sometimes referred to as the BMS strip) must be an inherent part of the battery itself. For this reason, protection circuitry on the PCB has been omitted.

  2. A charge pump regulator has been added to produce a steady 3.3V at high efficiency. This charge pump device has minimalistic circuitry, and will maintain 3.3V no matter whether the input is above or below 3.3V. This is expected to make the device behave consistently over the full range of battery voltages, and shall avoid putting any component under stress.

  3. Type-C USB port. This Type-C connector is of the common 16-pin variety and can be soldered either by hand or by stencil.

  4. Charging IC has been replaced with 4056. 4056 was chosen for its larger physical size (for easy soldering). Charging current is still fixed at 500mA. Note that the underbelly of the 4056 does not need to make electrical contact for the chip to function; as such, the IC can be comfortably soldered by a beginner.

  5. Option to use either the on-board OLED (1.3’’) or an add-on mezzanine 2.42’’ module. This allows students to purchase the larger screen separately off the shelf and “upgrade” their devices with their own money and in their own time. Using a COTS module is appropriate, as the larger screen requires dedicated components, which are already fitted on the module, so this add-on module approach eliminates redundancy.

  6. SPI flash is of the traditional wide-body type in order to reduce cost and to ensure interoperability with commercially available flash sockets (flash sockets which use the same footprint as the flash itself). Note that a flash socket is not necessary.

  7. Oversized slider switches to ensure low contact resistance and good durability. (not shown in sch)

  8. Low battery indicator. Since there is no way to implement it system-wide in software (partially due to how the software is architected), I have included a hardware low battery indicator, which is just an LED that will autonomously flash under low battery conditions. It makes use of the MCU’s exposed AREF voltage. The effectiveness and desirability of this remains to be seen.

  9. How display detection is proposed to work (in theory): The 2.42’’ module has two 4.7k pullup resistors hard-wired to the data pins whereas the on-board hardware does not. These resistors should be detectable by the MCU and will help determine the presence of an add-on display module. Software (namely, the bootloader) handles the automatic detection and switching. That’s the gist of it. But if you can think of a better way, please advise.

    Arduboy EDU
    Arduboy EDU1920×1358 149 KB

So I present to you a preliminary schematic. Please do not hesitate to point out any errors and let me know your thoughts about this design.
Arduboy EDU.pdf (452.1 KB)

1 Like
2

Looks good to me. Great job.

I may be porting the Arduboy2 library (and a few games) to the ESP32 in the near future, maybe on the weekend (two days’ time). Going to be using a 240x240 display though.

3

Thanks for your contribution to the software!

P. S. Just noticed the comparator inputs may need swapping.

1 Like
4

The design would require a SSD1306 display then as the CH1116/SH1106 do not support the Horizontal addressing mode that is used by the official Arduboy.

Using any other display means the games need to recompiled and some game sources are not available or do not support the use of other displays (Games that use an SSD1309 display can be patched though)

I’m curious to know what detection method you have in mind. Those pins are digital only and the MCU only has built in pull up resistors.

Maybe easier to use one of the unused GPIO pins as a display select pin or put a (1K) resistor in series with the internal OLED CS and add a ‘disable internal display jumper’ that is connected between VCC and the OLED CS pin to disable it. or a switch to select internal / external display (with pullups on each displays CS pin)

Switching must be done with hardware as it is not supported by games (just like the sound switch)

  • The pullup resistor on flash_cs is missing.

  • I’d choose larger resistors for the VBATT measurement so a smaller constant current running through the resistors and add a small capacitor between r14/r15 junction and GND for a more stable voltage measurement.

1 Like
5

I have been wanting to make a cheaper version for education for a while that’s kind of where I ended up on the Mini, but it’s still not a solder together kit. Considered it before but the customer support might be a bit much!

The schematics are open, do you mean the board files? It’s too risky to release them to have it copied unfortunately.

If you are looking at cheaper microcontrollers I suggest looking at the RP2040

There are also some battery charge controllers that include a low power notification led too so you might look into that.

Interested to see the results!

6

Thank you for shedding light on this matter. I really appreciate it.

So my lazy ass assumed the AVR had a weak pull down or something on the IO. That is apparently not available unlike modern 32 bit MCUs. But you seem to suggest that is beside the point as you said any attempt to deal with this in software won’t work. I will keep that in mind and revise my schematic accordingly.

You also pointed out that some displays are not interchangeable. I must get myself familiarized with the Arduboy software ecosystem before I can decide whether the reduced cost of CH1116 displays is worth the hassle. As I understand it, the status quo distribution model is basically users sharing hardware-dependent HEX files over the internet, and that is not desirable.

Lastly, the comment on the resistor divider is on point. It is also what I would do, had this been a more serious design. I was trying to perhaps reuse some resistor values and reduce component count. Design choices do also get a bit discretional at this level. But good point.

The one thing I’m curious about in your comment is the pullup resistor on flash_cs. Why would a pullup be necessary if the micro is driving it? Thanks.

7

5 posts were split to a new topic: What does open source mean?

8

As would the planned ‘port to a cheaper Arduino-supported microcontroller’:

In which case that’s quite a few things that would have to provided by a custom library fork:

  • Replacement of the display control code
    • E.g. display and boot
  • Replacement of all AVR assembly code
    • Probably a bigger issue for the FX library than the base library, but still an issue
  • Replicating the avr-libc functions that Arduboy2 and the actual Arduboy games rely on
    • E.g. srandom, _BV, PROGMEM, pgm_read_byte
    • Arduboy2 doesn’t use it, but various games will be using the zero-argument overload of random, a few will be using pgm_read_ptr or pgm_read_word. Still others will be using memcpy_P, and probably others I can’t think off offhand.
  • Replacing the relevant pin definitions and possibly the pin-manipulation code

(It’s possibly worth mentioning that a handful of games rely on GCC compiler extensions. Clang could probably still manage due to being fairly GCC-compatible, but some other compilers might choke.)

While not strictly incorrect (.hex file sharing is incredibly common) that’s a slightly deceptive way to describe the situation because it omits an important detail:

The overwhelming majority of users share their source code, and out of those the vast majority release their code under open source licences.

To memory, there’s only been one game shared on the forum that never had its source code released, and only a handful that were either released under a licence that doesn’t meet the OSI’s ‘open source definition’ (a few WTFPLs and at least one user who insists on writing their own ‘licences’) or without a licence of any kind.

But ultimately what you have to bear in mind is that a lot of people who use Arduboy aren’t actually programmers. The majority of people who buy the console don’t ever join the forum or learn how to program, they just want free games with minimal effort, and providing precompiled games is the most efficient way of achieving that.

People who aren’t technologically-inclined are used to being able to just download an executable and run it, they don’t know what compiling and source code are and most probably don’t even care. Whether that’s a ‘good thing’ or a ‘bad thing’ isn’t really relevant because Arduboy has to adapt to people’s behaviour rather than trying to force a new behaviour upon them.

For those people, distributing .hex files is desirable.

In addition, when you factor in the fact the FX chip basically has to store precompiled machine code, expecting users to individually compile 200-odd games themselves would be both inefficient and unrealistic. (It was enough of a difficulty for the people who had to gather them all together in one place.) Providing a tool to allow users to download cartridges preloaded with precompiled games of their choosing is a far more efficient and user-friendly way of doing things.

Those who want to download source code and compile it themselves still can, (I am one of those people - I like having a copy of the source,) but the fact is that such people are in the minority. Those who want to fork and modify other people’s games are in an even smaller minority, but that too is fine for the vast majority of games.

2 Likes
9

Thank you for your great insights. In my opinion an automated build system could be configured to compile game code, produce flash images, and account for all the variations in hardware in the wild. I suppose this could be feasible? If implemented it would place an emphasis on the code itself as the single source of truth rather than hex files, while people who want to enjoy it as a regular handheld can still use it with ease.

It is also my wish to see the library decoupled from AVR. 32 bit hardware would have enough headroom to run the games without code hacks and is significantly cheaper.

1 Like
10

It’s certainly possible thanks to the release of Arduino CLI, but for the people who are using official Arduboys and happy with loading precompiled .hex files there’s little incentive to do so.

Homemade spec-unconforming devices are still the minority and support for devices isn’t guaranteed. The ‘homemade package’ provides support for a few commonly used configurational differences (mostly screen type and pin layout differences), but is maintained more or less entirely by a single forum user (@Mr.Blinky) and it doesn’t support non-AVR processors (likely due to the cost of maintenance).

Some people have made their own Arduboy2 forks for different devices - again, that’s entirely permitted - but those forks will inevitably get less coverage here, either because they’re developed for devices people have made for their own enjoyment (in which case you might get one or two threads announcing the development and/or existence of such a fork, but not a lot of coverage) or because they’re for competing devices that have their own forum (in which case, they’ll be discussed on that other forum).

That’s not to say people wouldn’t help you if you wanted to go ahead and develop such a system, just that it doesn’t already exist because there hasn’t really been a demand for it. (Or at least not from anyone who has the skill to produce it.)

To be honest, I doubt it would make much difference.

The overall effect of such a build system would be essentially the same as what the existing ‘flashcart builder’ provides, with the difference being that the user would have to manually collect all the games’ source code as opposed to the current system of having all published games collected in a single place.

(Just to mention it: there is a Python script for building and uploading ‘cartridges’ to the FX ‘offline’ is someone wants to add an unpublished game to their FX chip.)

At any rate, even out of the people who are programmers, many aren’t here as open source advocates, they’re just here to produce games or tools for people to use and don’t care whether people compile from source or just download a precompiled executable.

@MLXXXp has stated in the past that the intent of the Arduboy2 library is to support the official device, not to support other hardware configurations because it would require too much additional maintenance. I doubt that stance has changed.

Again, if someone wants to take up such a project that’s up to them. The fact it hasn’t been done is a reflection of either lack of general interest or at least a lack of interest from people with the skills to do so.

It probably would, and some day there may be a ‘new Arduboy’ that uses different hardware, but those things take time, and it would be costly to produce. Discounting the people who actually manufacture the hardware, Arduboy Inc only has one official employee (@bateske), the rest of us just give up our time voluntarily.

I should point out though that for some programmers the limited resources are part of the appeal - they limit a game’s scope, prevent feature creep, and offer a challenge that devices with ‘better’ spec don’t provide.

1 Like
11

without the pullup the flash cs pin will be floating during ISP programming and with games that do not configure the pin. Noise may cause the flash chip to be activated in which case any ISP data and / or display data on the SPI bus will cause unexpected behaviour of the flash chip.

1 Like
12

That’s me!

3 Likes
13

For an ESP32 based system, you may wish to look into using the ESPboy as a base (though it uses an ESP8266, not an ESP32). Most of the Arduboy libraries have been ported to it by Roman S. (@ESPboy), its creator, as well as a large number of Arduboy sketches. As well as supporting native development, code for a number of other small gaming consoles has also been ported to it.

It has a hardware expansion port and Roman has developed a number of plug-in modules that do many things.

It is entirely open source. A version that uses only through-hole parts has recently been introduced (though not tested/verified yet).

1 Like
14

Great info guys, thanks to all for helping out

15

I’d check the power/current output of the charge pump/switched cap converter you’ve selected, they generally are more suitable for reference/signalling rather than powering circuitry that can draw more than 100mA or so (not sure what the worst case draw of an arduboy is, but I know the larger oleds displaying all lit pixels can draw quite a bit of current). Best to teach designing in safety margins for these things.

1 Like
16

The PW5410B, shown in the schematic, has a rated 250mA output.

https://www.pwchip.com/en/product/PW5410B-156.mhtml

1 Like
17

It’s a bit complicated due to architecture, but 150mA minimum will be available at all times. That should be more than enough for even the 2.42 screen. Counterintuitively it gets better as the battery drains.

18

Just to point it out: Technically your schematic isn’t “open source for real” either, because you haven’t specified how the schematic is licensed, and without a licence nobody has permission to copy or modify it.

1 Like
19

You are right😂 it’s preliminary. I haven’t included the KiCAD design file either. I will address all the technicalities properly as my project goes along.