CMUcam5 Pixy

[JavaLaurence]

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)?

[Loetkolben]

 

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

[Java8Laurence]

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? 

[Nic]

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

[raphael_vogel]

Afaik they are 4 guys

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

[Nic]

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

[borg]

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.

[Java8Laurence]

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).

[borg]

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.