Constantin
Well-known member
I hear you, Paul. I too have been involved with product releases ranging from the successful (helping Sub Zero build the Wolf manufacturing facility in Madison, WI and transitioning multiple product lines from drawing board to pilot production) to the not so successful (co-developing the first US outdoor gas water heater, exceeding every performance measure, costing far less than projected, etc) only to watch the client struggle on how to and eventually fail to sell the thing in appreciable quantities. There is pride in the process of creation and commercial success validates the time and energy one had invested in a given project.
That said, the Arduino project is in many ways its own worst enemy. As best as I can tell (and the analogy of the three blindfolded wise men describing an elephant to the king comes to mind here), the Arduino management team continues to largely isolate itself from the community instead of leveraging it. Management presence in the forums tends to be sparse to non-existent, as is feedback to the community when people have asked openly why, for example, your fixes to malloc.c were never implemented fully. Similarly, basic libraries continue to be buggy and people generally have better luck following their noses to experts like yourself, fatlib, gammon, etc. to find libraries that work.
So while I totally understand your point of view, Massimo and the rest of the team would do well to focus on fixing long-standing bugs in standard libraries. For example, that Strings are an official library but totally unstable is simply unacceptable. Similarly, they would have done well to follow your lead re: the ARM platform and focus on smaller chips before tackling a 100+ pin TQFP monster that was shoehorned into a Mega form factor and for whom many core hardware functionalities (such as external RAM) have been disabled by a (IMO) bungled hardware design.
For me, the 100+ pin Due platform should have been a clean sheet, new beginning - i.e. no compatibility by design with pre-existing shields to limit issues with voltage mismatches, etc. Such a clean break allows designers the freedom to create a core PCB that allows users to access all pins on the chip and take advantage of the many possibilities that such powerful chips offer. Board designs, hardware requirements, etc. have evolved - why shoehorn a current processor into an old Arduino form factor unless absolutely necessary?
I love your design because it is so compact that it is easy to breadboard, yet very powerful and embeddable. And stacking up the capabilities of the Due vs. the Teensy makes it very apparent that while the Due has some interesting features, that the Teensy runs virtual circles around it in most respects. For the price point of a due one could daisy chain multiple Teensies for the same or superior performance. My posts may have been too blunt in their assessments of the Due for Massimos taste, but I stand by those comments and he would do well to reflect on such comparisons instead of accusing me of trying to market a rivals product.
Your development of the Teensy 3.0 may very well have forced the hand of the Arduino team to release their own version of an ARM processor-based unit sooner than they were ready to. I hope the Arduino team rethinks their ARM strategy and also releases a smaller 32-bit board at a UNO price point instead of going for the largest processor that one could fit on a Mega.
That said, the Arduino project is in many ways its own worst enemy. As best as I can tell (and the analogy of the three blindfolded wise men describing an elephant to the king comes to mind here), the Arduino management team continues to largely isolate itself from the community instead of leveraging it. Management presence in the forums tends to be sparse to non-existent, as is feedback to the community when people have asked openly why, for example, your fixes to malloc.c were never implemented fully. Similarly, basic libraries continue to be buggy and people generally have better luck following their noses to experts like yourself, fatlib, gammon, etc. to find libraries that work.
So while I totally understand your point of view, Massimo and the rest of the team would do well to focus on fixing long-standing bugs in standard libraries. For example, that Strings are an official library but totally unstable is simply unacceptable. Similarly, they would have done well to follow your lead re: the ARM platform and focus on smaller chips before tackling a 100+ pin TQFP monster that was shoehorned into a Mega form factor and for whom many core hardware functionalities (such as external RAM) have been disabled by a (IMO) bungled hardware design.
For me, the 100+ pin Due platform should have been a clean sheet, new beginning - i.e. no compatibility by design with pre-existing shields to limit issues with voltage mismatches, etc. Such a clean break allows designers the freedom to create a core PCB that allows users to access all pins on the chip and take advantage of the many possibilities that such powerful chips offer. Board designs, hardware requirements, etc. have evolved - why shoehorn a current processor into an old Arduino form factor unless absolutely necessary?
I love your design because it is so compact that it is easy to breadboard, yet very powerful and embeddable. And stacking up the capabilities of the Due vs. the Teensy makes it very apparent that while the Due has some interesting features, that the Teensy runs virtual circles around it in most respects. For the price point of a due one could daisy chain multiple Teensies for the same or superior performance. My posts may have been too blunt in their assessments of the Due for Massimos taste, but I stand by those comments and he would do well to reflect on such comparisons instead of accusing me of trying to market a rivals product.
Your development of the Teensy 3.0 may very well have forced the hand of the Arduino team to release their own version of an ARM processor-based unit sooner than they were ready to. I hope the Arduino team rethinks their ARM strategy and also releases a smaller 32-bit board at a UNO price point instead of going for the largest processor that one could fit on a Mega.
