Multi-player linked Arduboys via a USB host (PC)

I just had a thought. Others have likely though of it as well, and maybe even implemented it, but anyway…

Serial is a standard Arduino library which would allow Arduboy sketches to send and receive data to a PC via the USB port. An extremely simple program could be written for a PC (any O/S) that just relays serial data between two or more USB ports. This way, two or more Arduboys could be connected to a PC and communicate with each other.

So, who’s going to be the first to write a multi-player Arduboy game :question:


This would require a user to solder a cable for micro usb to micro usb, right?
I guess that would be the first step in this process.

well the original post mentions a computer being the hub of sorts, but of course it would be awesome to be direct to another arduboy =]

1 Like

Why not also implement multiplayer over internet to connect arduboys all over?

Yeah if you can communicate with Arduboy over USB from a central PC, there is no reason that it can’t then connect to another PC. At this point we might as well play a PC game though right?

1 Like

It doesn’t have to be a large comuputer. A Raspberry Pi, or other similar small machine with at least 2 USB host ports would do. Even something really tiny, like a Domino Pi with the 3 port USB tile, would work. A small benefit of connecting to a computer is that the attached Arduboys would be powered via USB, instead of draining their batteries.

Directly connecting two Arduboys would be difficult because the USB port can only be a slave, not a master.


I don’t know enough about USB low-level but I spent some time looking into this. There is an incoming pin you can detect that gets voltage applied to it when USB is plugged in. You can read it’s bit value (if its current has voltage applied) as well as get interrupted if it changes. The idea is to detect USB devices but you could also use it with a custom USB cable as an input “pin”.

What I wondered was if we could build a custom USB cable to plug two Arduboys together. Unfortunately I could find no similar loophole in the USB specs for an “outgoing” pin. IE, something you could flip HIGH or LOW at a whim - and not as part of some larger USB protocol. If there were such a USB pinout we could try and build a serial cable and then have a simple 2 wire serial communication channel at an agree upon baud rate.

Anyone know anything here I"m missing?

I don’t believe that the Arduboy’s current design uses Arduino pins Rx (D0) and Tx (D1). It would be nice if these pins, possibly along with power and ground, were brought out to a tiny connector on the edge of the case, similar to the USB connector. This would allow Arduboys to be linked using the built in UART and the same Serial library that I mentioned in the original post.

Yep, I already suggested an audio cable but was told that’d be too large. Maybe USB C connector?

I don’t think USB C connectors will be easily obtainable for general use for quite some time. I wouldn’t use any standard connector designed for a specific use. Someone might get the idea that that’s what it’s for, then plug in such a device, possibly causing damage.

I think just a right angle header strip such as this one would be fine. With this particular six pin verson, you could bring out Rx, Tx, Power, Ground, and the two I2C pins SDA (D2) and SCL (D3).

With I2C connectivity, a great number of possibilities opens up. If you used a strip with more that 6 pins, you could bring out more unused GPIO pins.

Could we talk directly over the i2C bus then?

Do you mean between two Arduboys? If so, the answer is: possibly. I2C is really only meant for chip to chip communications on a circuit board or within a single chassis.

If you kept the wires fairly short, say under 2 meters (6 feet), and ran at a slow I2C clock speed, it would probably work.

One issue might be mismatched voltages, like when one Arduboy has a full battery and the other has a fairly low battery, or when one Arduboy is powered by USB and the other’s on battery. In this case you may need level shifters or clamping circuitry to prevent damaged inputs due to overvoltage. If power and ground was provided on the connector, it might be possible to switch off the battery of one Arduboy and power both of them from the other, thus guaranteeing that the voltages would be matched. This would be true for Rx/Tx serial connections as well.

Another thing is that I2C uses open collector/drain drivers, so you need pull up resistors on each signal. This means that power and ground would have to be available on the connector.

I don’t think there would be any advantage to using I2C instead of just serial using Rx and Tx (which wouldn’t need pull ups), unless you wanted to connect more than 2 Arduboys together.

1 Like

I think with i2c you get the protocol timing and stuff for “free”, or is that all done in software not hardware? Most of the hardware stuff you mentioned there is over my head. :smile:

1 Like

Something that would get around the problem of mismatched signal voltages, and allow much longer cable lengths, for an Rx/Tx serial link, would be to put RS232 converters at each end of the cable. It would be simple but would require that power was available on the Arduboy connector.

Something like the one shown in the following picture is what I had in mind. They’re small and cheap and easy to obtain. You could wire one to each end of a cable and enclose it in heat shrink tubing.

Of course, all this depends on having a connector added to the production Arduboy that includes at least Rx, Tx, Power and Ground, or having people hack the Arduboy to bring out these signals.

It’s good that at least @bateske said in a comment on Kickstarter:

Extra Pinouts for Hacking: Yes any of the unused pins from the microcontroller will be brought out to test pads so you can open the device and hack it.

I think a Raspberry Pi would be a good idea and stick a battery on it and it can be a 4 player portable server.

Is it possible for an external device to write directly to the Arduboy RAM or EEPROM whilst it is switched on? At that point, we could even be considering the possibility of storing some slow large data on a raspberry pi like maps and only needs to be on the device

The built in I2C capabilities just give you the ability to connect multiple devices over just two wires (plus a ground wire) and easily address them. You still have to define the protocol for what you’re going to send and receive.

If you only want to talk back and forth between two Arduboys, using the UART on the Rx and Tx pins is probably easier. Also, as I posted previously, solving signal voltage mismatches and achieving long cable lengths would be quite easy using Rx/Tx.

If you want to talk between more that two Arduboys, using a small PC with USB connections, as I proposed in the original post, would probably be easier than coming up with some kind of multi-way I2C cable with the proper pull ups and signal protection.

No. You would have to have your sketch receive serial commands and data, then this sketch would have decode them and write to RAM or EEPROM itself.

I started a topic today about this here.

I don’t know if it would be that difficult. What you thinking of already exists - it’s called USB On The Go, usually USB OTG.

My phone (now nearly two years old) has this, and it means I can either plug it into a computer as a mass storage device OR I can plug a mass storage device into it. I can also plug a keyboard or a sound card into my phone.

The key seems to be that fifth pin on the Micro B connector. There are Micro B to Micro B cables (I have several) but they have one key difference – one end has the ID pin grounded, the other lets it float. Thus, the cable determines which device is client and which is host. They are usually called “Micro B to Micro B HOST” cables. The USB shell on both ends is identical, with the only difference being the ID pin as described above.

All this would be meaningless except that I have seen application notes indicating that the ATmega32 can actually do USB OTG. Perhaps the ID pin connection needs to be somewhat standard (and I have NO IDEA what standard is for this platform), and then it could be possible that two Arduboys could be connected with a cable for head to head games. I do know that the Arduboy is somewhat “USB flexible” since they show the idea of using it as a custom keyboard.

Perhaps someone with more background on the Arduino platform can chime in. I think this is a key item, and I have been looking for info before I finalize my backing. More particularly, I was actually looking for circuit diagrams, but (not surprising) did not find them. If the simple connection of one pin in the USB connector is all that is needed to make this work, then it would be worth letting Kevin and his team know about this possibility.

You are probably mistaken in you interpretation of said application notes. OTG requires one device configure itself as a USB host and the other to act as a USB device. Both devices must be able to handle both host and device modes. The ID pin just tells each device which mode it should use.

Unfortunately, the ATmega32U4 used by the Arduboy only supports device mode. It cannot go into host mode, so OTG can’t be supported.

It’s probable (though I don’t know for sure) that the ATmega32U4 could connect with an OTG capable device as long as that device is put in to host mode by inserting the correct end of the cable. However, with two Arduboys connected together neither would be able to assume the host role. I don’t think you even could connect two Arduboys together with a standard OTG cable because the ends are supposed to be different and only the “B” end could be plugged into the “B” type connector on the Arduboy.

There’s nothing exotic about the ID pin. It’s left unconnected on the “B” end of the cable and tied to ground on the “A” end.

Ah - too concise there, I guess. It can do USB OTG Client, but not USB OTG Host. Hmmm. Ok. Thank you for the clarification!

My final question then (and it’s a real newbie question) is regarding how the USB protocol is implemented on the ATmega32? Is it all buried in locked in device firmware, just exposed through I/O type calls? Or is the ATmega implementation exposing the lowest hardware level, and the sketch brings in most of the code to make a particular type of USB client device happen?

What I would want to check next is whether the data communication capabilities are completely hidden in the lower layers, or can you use the hardware to communicate ATmega to ATmega over a USB cable, but having to invent some on-the-wire protocol that can use the existing hardware?

It’s been a while since I’ve cracked open a 400 page datasheet, but I could use some engrossing reading on the subway!