Strategic change

[JavaLaurence]

I seriously frowned when I read these words: "in a three year time frame."

 

Three years sounds unrealistically long. Three years is an eternity in politics and in technology. Such a strategy implies that you impose upon your customers a transition period that is that long. I think 3 years is huge, and a completely wrong period for the kind of products we're talking about, and the kind of company you are. To be frank, it's just plain weird. If, as an alternative, you said "By the end of 2017 we'll have all bricklets converted to the new design".. I for one would be happy to continue thinking of Tinkerforge as a viable ecosystem for current and future projects. But three years? Sorry.. not me.

 

I'll also add that I question why such a massive earthquake is needed? You mentioned the event counter use case.. that's one use case. Have you been inundated by other use case requests from customers that justifies such a major undertaking? What about all your existing customers who are perfectly happy with the current approach, including the fragile connectors? Your proposal means complete backwards and forwards incompatibility. I currently can't see the crystal clear business case for putting yourselves and us (customers) through such a huge change.

 

My 2 cents..

[borg]

I think you may have misunderstood the changes.

 

There is a complete compatibility between the old and new generation of Bricklets during the three years.

 

There are also two different things: There is the switch from "dumb Bricklets" to "Bricklets with co-processor" and there is the switch from 10-pole to 7-pole.

 

The switch from dumb to co-processor Bricklets is necessary, there is really no other viable option. But from a user perspective you won't even notice this. The API and how it is used etc stays the same. If we don't change the connector you won't even notice a difference.

 

The connector change is something for better usability and it is a difference that the user will notice (albeit a small difference). That is why we asked about it.

 

Edit: I added the sentence "In both scenarios the old Bricklets and the Bricklets of the new generation are completely compatible to each other and the old Bricks." to the blog entry and poll to make it more clear !

[JavaLaurence]

Thanks for the clarification. I then have a second question: can the addition of a co-processor and more robust connectors be done without changing the price levels that TF users have grown accustomed to?

 

It looks to me as if this co-processor will need to be really, really cheap for it not to have an end-user price impact..

[borg]

The microcontrollers are indeed a little bit more expensive then the EEPROM (which they replace). We currently plan to use the XMC1X00 series industrial MCUs from Infinion for most Bricklets.

 

Modern cortex-m0 micros are probably less expensive then you expect, see here for an idea about the price: http://www.mouser.de/ProductDetail/Infineon-Technologies/XMC1100Q024F0064ABXUMA1/?qs=sGAEpiMZZMuoKKEcg8mMKKywyJ6nXWno8US%2fnU9Cn6GgzMDTUpM3rw%3d%3d