Arduboy Hat Idea

A discussion about the idea of creating a hat with similar specs to the Arduboy to be able to run Arduboy games natively and use the Pokitto as a peripheral.


Migrated from here:


Here is latest revision of this board. This is not final yet. If there is a problem please report under this post. I appreciate any suggestion (@NullMember) :slight_smile:

Schematic:

PCB Top:

PCB Bottom:

PCB dimensions are 60x24mm

Edit: Here is OSHPark link. OSHPark donā€™t like oval holes. I will fix it final version.

2 Likes

Had a thought that it would be neat to add automatic ā€˜colourisationā€™ to the Pokitto port of the Arduboy2 library (could have at least two mono palettes on screen - one for any sprites used, and one for everything else). The same way that original GameBoy games could be automatically colourised on the GameBoy Color :

Another idea could be to create a Pokitto ā€˜hatā€™ with an ATmega32U4 onboard - would be sort of like having Arduboy games on a ā€˜cartridgeā€™, and send the screen buffer to the Pokitto over SPI?

3 Likes

Good point about the GBC, Iā€™d forgotten it did that.

Regarding the 32u4 hat route, you could make the Pokitto program emulate the screen that the Arduboy uses, making it accept all the proper screen commands.

That way any Arduboy game would work with the Pokitto, even the compiled ones. All youā€™d have to do is map the pins up properly.

1 Like

This sounds like an excellent idea. Iā€™m not sure what map the pins up properly means though?

Also, any stand out games, like castleboy, the community could put extra time into coloring them artistically and/or upscale/expand to fit the pokitto screen.

Basically the 32u4 processor (the kind used by an Arduboy) has a certain number of connections with different names (each connection is called a ā€˜pinā€™) and those would have to be connected to the PEX (the group of pins at the top of the Pokitto) in a way thatā€™s suitable for using the SPI protocol and so that the other pins can do their jobs properly (e.g. 6 pins for the buttons, some pins for sound and some pins for the LED).

Effectively the hat route would mean that the hat itself is an Arduboy without the buttons, screen, speaker etc (i.e. itā€™s literally just the processor) and the Pokitto would be reading and writing to the pins to pretend to be the buttons, screen, speaker etc.

That might be a bit difficult because the Arduboy screen is 128x64 amd the Pokitto screen is 220 x176, so itā€™s probably going to be a bit awkward to upscale without looking stretched or uneven.


As for colouring, the hat approach would be different to the approach we were discussing on the other thread that introduces colour.

For the hat approach, you can do stuff like displaying lit pixels as green instead of white, but more than two colours would be difficult.

With the approach weā€™re discussing in the other thread, the gameā€™s original source code would be needed because the game would be recompiled to run directly on the Pokitto, which also gives us more freedom with other things because the Pokittoā€™s processor is more powerful.

1 Like

Since the Pokitto doesnā€™t have an RGB LED, and reading the PWM output from an LED pin in analog mode would be difficult, it would probably be better to put an RGB LED on the hat.

Iā€™m not sure how you would program the 32u4 chip. You could have a dedicated USB port on the hat but it would be better to have a custom bootloader in the 32u4 that talks to the Pokitto through the PEX, in place of the USB interface.

The same issue as the RGB LED applies to the Arduboyā€™s speaker. Some libraries (e.g. ATMlib and ArdVoice) use PWM to control the speaker. Unless you use an ADC on the Pokitto side and then convert back to analog for the Pokittoā€™s speaker, it could be hard to read the speaker output properly. You also have the issue of detecting if the Auduboy sketch is controling the speaker with PWM or square waves, to determine how to handle it appropriately. So, It may be better to put a piezo speaker in the hat, as well.

Would it?

Someoneā€™s written a class for it, PwmIn.

Thatā€™s a fair point, I think that would probably give a better effect anyway, and wouldnā€™t add too much to the cost.

Wouldnā€™t it be possible to just directly connect to the pins that would normally be connected to the USB port?

As far as Iā€™m aware USB is just 4 pins, the actual shape of the connector isnā€™t special other than being a standardised shape thatā€™s distinguishable from other ports.

(Not that a custom bootloader would be much of an issue given that the Pokitto would be responsible for flashing the chip anyway.)

Assuming for a moment that the afforementioned PwmIn wouldnā€™t work, wouldnā€™t it be possible to simply include a hardware ADC in the hat instead of a full speaker?

wait are we looking into emulating the arduboy so we load in the hex files?

Weā€™re looking into a hat that actually runs the hex files with a real 32u4,
and then making the Pokitto emulate the screen and other bits.

So basically the hat is an Arduboy without a screen.

Iā€™m not sure if this is crazy or not but it would work and would cover the last 0.01% of Arduboy games that arenā€™t open source (i.e. Circuit Dude, and maybe one or two others).

couldent we emulate on the esp32 board?

The Pokitto doesnā€™t have an ESP32 board built in,
the ESP32 thing is another (still hypothetical) hat.

Itā€™s possible that it could be emulated by the ESP32 but writing an emulator is hard work and Iā€™m not sure how easy it will be to get an Arduino emulator working on the ESP32.

There is already a web-browser-based Arduboy emulator but youā€™d need to ask permission to port that and find something that can turn javascript into the appropriate machine code.

Basically the 32u4 hat approach is probably the approach that uses least effort: build a hat, emulate a screen and a few pins -> run every Arduboy game ever compiled.

At the risk of not having thoroughly researched Pwmin:

Note that the functions in that class all say current. Iā€™m assuming itā€™s meant to measure the characteristics of a PWM signal that doesnā€™t change over a number of cycles. Since an audio PWM signal is constantly changing, I donā€™t think these functions would be able to ā€œlatch onā€ to take a reading. Even if they could, it would probably be fairly CPU intensive.

What would you attach them to? Is there a host capable USB port brought out to the PEX?

You might be able to add filtering in the hat, to bandwidth limit the speaker outputs, then feed them into ADC capable pins on the PEX. You could then mix the two speaker signals and send it to the Pokittoā€™s speaker DAC.

would like to mention that the wifi hat has been an early concept and there was consideration of incorporating it into future pokitto models.

From what I can tell, they track the rising and falling edges of the pins using interrupts, so itā€™s possible they would be more processor intensive.

It might be an issue for the speaker,
though I doubā€™t it would be as much of an issue for the LED given how infrequently itā€™s used.

Barring the issue with USB usually being 5V,
would normal PEX pins not suffice if there was a suitable system for acting as a host?

Is the protocol not the same even if you use unadorned pins instead of a standard port?

I found a few mbed classes for controlling USB, but none listed the Pokittoā€™s MCU as being supported unfortunately.
Though that isnā€™t to say itā€™s not possible that one does work for the Pokitto or that there arenā€™t alternatives.


If thereā€™s evidence to suggest that there will definitely be an official ESP32 hat or there will definately be an ESP32 chip added to the Pokitto, or if thereā€™s evidence to suggest it would be cheaper than the 32u4 approach then itā€™s worth consideration.

Even with those taken into account, I think a full scale emulator that would be compilable for ESP32 might be a bit difficult to find/create.

USB power is 5V but the signals are 3.3V

The USB pins on the 32u4 are dedicated to USB only. Theyā€™re not usable as general purpose I/O. You need a USB host to talk to it. Since the standard Caterina bootloader used in the Arduboy expects to talk over the USB pins using USB protocol, thatā€™s what you need to provide.

A custom bootloader could be made to use any pins and any protocol.

If I were tasked with writing a custom bootloader for an Arduboy hat, Iā€™d probably use the 32u4 RX and TX UART pins (0 and 1). Iā€™d use asynchronous serial protocol and ether the standard AVR programming commands or something more suitable for control by the Pokitto.

I was going by Wikipedia, there was no mention of 3.3V.
In that case itā€™s probably even easier.


So essentially if it were possible to make the Pokitto act as a USB host then the USB connection could be done over plain pins, without an actual USB port, yes?

By ā€œplain pinsā€ do you mean ones that swing from GND to 3.3V? If so yes.

Or, do you mean over general purpose I/O pins? If so, I donā€™t think so. You would need dedicated USB hardware. Iā€™ve never heard of anyone ā€œbit bangingā€ a USB host controller.

EDIT: After some research, it looks like bit banging USB may be possible. However, I donā€™t see what the problem would be with making a custom bootloader. You have to burn some kind of bootloader into the 32u4 on the hat anyway, and the hat is dedicated to connecting to the Pokitto. You could probably hack the one used on the Arduino UNO, that uses a serial interface, pretty quickly. You could then wire the 32u4ā€™s USB port to a microUSB connector, so you could use it with Arduboy sketches that emulate a mouse, keyboard, etc.

Aparently it has been done:

And oddly enough a Cortex M0+ is involved.

Unfortunately the link in the article appears to be a dead end.

Thereā€™s a surprising number of results for ā€œbit banging usbā€.

Thereā€™s even a Dr Dobbā€™s article about it, which is especially relevant

Thereā€™s even a line saying:

What I mean is using software in a microprocessor to convert a few general-purpose I/O pins into a USB port.

Caterina is a LUFA CDC derivative using an AVR serial protocol. Just drop the virtual USB port part of the bootloader and recompile to read directly from uart (shouldnā€™t be too hard, and has been done with 8-bit Caterina versions)

If youā€™re sure itā€™ll be easier than getting the Pokitto doing USB over the PEX then I guess Iā€™ll drop that idea.


If we do end up going down that route though,
it might be best to wait for a bit.

Someone on the Arduboy forums called Mr.Blinky (who I assume is the same one with an account here) has been working on an improved version of the caterina bootloader (which can be found here on his github), and it might be worth asking him if we could use that as a base.

Itā€™s mostly done but he recently mentioned a few more things he had in mind for it.