CMUcam5 Pixy

Q to TF team: you're probably aware of the above (the German forum also has a few references to Pixy).. this super-cool camera module supports SPI, I2C, UART, and analog/digital I/O.

What would be the most sensible way to hook this camera up to a TF stack? Would it be via an IO-4 or IO-16?

Given that you guys are I2C experts, what are the chances that the IO-4/16 Bricklets APIs are enhanced to support direct I2C communications (at least the slow speed variety)?

Hello JavaLaurence,

do you want to control a I2C IC with IO-4/16 Bricklet via Software? 

Please follow this link: I2C mit IO16-Bricklet (PortExpander)

Until today i had no time to test it, but i want to control a I2C LCD with this method in future.

Der Loetkolben

Thx for the link.. but I was actually hoping for an official TF reply (hint: borg?).

I suspected that i2c comms ought to be possible with the IO-4 and IO-16, but I'm hoping that the good people at Tinkerforge will help us a little bit by enhancing the bricklets to support "high-level" I2C instead of having to manage the SDA/SCL lines ourselves.

PS. If any TF employee reads this.. I also asked a few other API enhancement questions in earlier posts that none of you have (so far) answered.. hope you guys aren't seeing RED these days? 

Curious y use 2 diff accounts for clarify

They are only 3 guys mainly working @ TF. Many month before lots people have asked for an additional interface bricklet to support I2C, RS232 and others.

But I assume they invest most of the time for the RED, otherwise much more user will ask when this brick is finish finally

Afaik they are 4 guys

http://www.tinkerunity.org/forum/index.php/topic,2052.msg13381.html#msg13381

Hmh, y right., but is he still alive, its long time ago when he post sth.

We have looked at the CMUcam5 Pixy already, it is indeed pretty cool. I could imagine a "Cam Brick" that connects to the CMUcam5 Pixy and translates their API to our system, so you can use it with all of our languages.

A Bricklet that speaks I2C/SPI or API for the IO4 for I2C/SPI is not planned. We discussed that internally and we think it doesn't fit into our system.

I fully understand that there may be a commercial reticence to open up the world of off-the-shelf I2C products by giving us either an explicit I2C Bricklet, or an API on the IO-4/16. But frankly, I don't think it would undermine your sales of existing bricklets.. the beauty of the Tinkerforge product range is its extreme simplicity for non-electronics geeks. Most of these guys don't even know what I2C is. So IMO, providing I2C support is not going to cause people to suddenly not buy the "ready-made" bricklets because they can see ways of achieving the same functionality using I2C components sourced elsewhere.

Personally, I would think a new I2C API on IO-4/16 would be super-cool, and would show that Tinkerforge's philosophy is to allow its clients to truly tinker with whatever is out there, without locking us in to your product catalog. I also think that for Industrial customers, real I2C support would be extremely attractive.

Finally, I don't think it would hurt your marketing efforts if you could showcase a TF-based project that exploits the Pixy (and other I2C components).

There is no commercial reason behind this whatsoever (besides us not wanting to invest the time). It is all about usability. It would absolutely be a pain in the ass to use. It wouldn't be possible to debug it without having a logic analyzer or similar. You can't just add a print to an intermediate state of the I2C communication to see what is going on for example.

It would be a lot harder to use than Arduino, which kind of defeats the purpose.