JavaLaurence Posted May 19, 2014 at 07:30 PM Posted May 19, 2014 at 07:30 PM 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)? Quote
Loetkolben Posted May 19, 2014 at 08:45 PM Posted May 19, 2014 at 08:45 PM 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 Quote
Java8Laurence Posted May 20, 2014 at 10:45 AM Posted May 20, 2014 at 10:45 AM 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? Quote
Nic Posted May 20, 2014 at 11:36 AM Posted May 20, 2014 at 11:36 AM 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 Quote
raphael_vogel Posted May 20, 2014 at 12:46 PM Posted May 20, 2014 at 12:46 PM Afaik they are 4 guys http://www.tinkerunity.org/forum/index.php/topic,2052.msg13381.html#msg13381 Quote
Nic Posted May 20, 2014 at 01:31 PM Posted May 20, 2014 at 01:31 PM Hmh, y right., but is he still alive, its long time ago when he post sth. Quote
borg Posted May 20, 2014 at 02:39 PM Posted May 20, 2014 at 02:39 PM 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. Quote
Java8Laurence Posted May 21, 2014 at 07:27 AM Posted May 21, 2014 at 07:27 AM 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). Quote
borg Posted May 21, 2014 at 07:38 AM Posted May 21, 2014 at 07:38 AM 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. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.