I don’t think that’s the case. For I2c, you need SDA, SCL and ground For a serial link, you need RX, TX and ground. Serial can have other wires, but these days they tend to be for specialized uses, not simple comms. Either one may need a power line if one of the two ends isn’t getting power from another source.
[quote=“adekto, post:14, topic:619”]
for the other peripherals, like wifi, bluetooth or IR the problem is that the pokitto has to handle these timings, setups and other specifics, the idea there if its over i2c or spi dousnt matter to much just that its all the same[/quote]
The same is true if those devices communicate via serial link. Is it possible that what you thought I was talking SPI? It does require more wires (4 signal + ground) and is intended for communication between devices on a PCB. But that makes it a really bad choice for talking over a link cable.
If you’re thinking about a bit of hardware that plugs into the PEX header and provides communications, then it’s to early to worry about the protocol. You really want to figure out what hardware you’re going to use, and then use a protocol the most suitable hardware uses. Talking to the actual comm device is going to require code specific to that device. If that runs on the Pokitto, then it needs a library specific to the comm device. If you put an µcu in the link device to talk to the comm hardware, it can provide an API specific for this. I think that’s over-engineering the problem, though. But if you think it’d be fun to do - that’s what this is all about, so go for it!
I’m thinking more of something you can toss together with minimal hardware. A scratch setup would connect a pair of pokittos with breadboard jumper cables. You could DIY a cable from a pair of male DIP plugs and a USB cable (the signals use the USB signal lines, the others are wired to ground). Serial is designed for two relatively intelligent devices to talk to each other, which is what you have with that kind of cable,
I think the best protocol will depend on the architecture of the game. I2C has a master controlling a slave with a half-duplex link. A modern serial link is a symmetric, full duplex link. So if your game runs on one Pokitto, and primarily treats the other as a second (third, etc) controller/display, then I2C will be better for you - the link matches the design. In the extreme case, the in-game library could be a Pokittolib-like object, and the second (third, etc.) Pokitto runs a standard app that implements the other end of that object, and is usable with any game that uses the library. The advantage here is that your game is a lot simpler, it’s just one game with multiple controllers. The downside is that you’re not really taking advantage of having multiple cpus.
If you want your game to be a symmetric distributed system, serial would work better. Each Pokitto runs it’s won copy of the game, and deals with what it’s user does and sees. When that causes an event that affects the other player, it spits out a message to the other end - no need to wait to be asked if it’s the slave, or poll the slave if it’s the master. The game can monitor the serial line in whatever fashion best suits it - either letting it generate interrupts, polling it at regular intervals, or some third option. The upside here is that each player gets the full power of a Pokitto to run their game. The downside is that you’ve got a distributed system, which comes with a lot of headaches (believe me, I build distributed systems for a living; and know whereof I speak. Building robots and embedded remote control systems is just a hobby :-).
Of course, either protocol can be made to support either architecture. Picking a protocol that matches the architecture just means it takes less code to get it done.