Why is it that the community who helped launch the Netduino Go! is not able to participate in the formalization of this spec based on use cases and requirements and our collective experience with Go! so far? We, the module-builder community, will have to comply to that specification when the time comes, yet, we have no say as to what goes into it?Once we feel comfortable with the performance of virtual i/o on the Shield Base, we'll formalize that into a spec. You're welcome to join with us in implementing that for STM8S if you'd like...Netduino is community.
we're determined to use the go!bus interoperability logo program and virtual i/o to ensure that doesn't happen with the go!bus ecosystem. It's all balance...hopefully we can all come up with the best balance.
That's a great goal and I fully support it but right now, I don't understand where the notion of 'balance' enters the equation when the definition of the logo is happening behind closed doors.
The STM8S-Discovery can be a pretty intimiating thing to look at, so having a simpler starting point to work with (such as ItsDan and Arron's Prototype module) is really valuable.
As long as the value-added firmware is there to support the simplicity claim, I would agree. At the moment, the barrier to entry is lower on the STM8SDiscovery side.
-Fabien.
