[OpenTRV-dev] V0.2-Arduino: getting started

Mon Apr 1 17:47:34 BST 2013

Hi,

Firstly, I think that DECC doesn't bring any particular requirements except probably reasonable physical/operational robustness.

Secondly, I completely agree that trying to do too much will result in little being done well or at all.  Please do comment on the outline timetable.

Third, I don't see V0.2 as being consumer grade, but could be steered close enough to be interesting to manufacturers' R&D bods.

Primarily I think that we should keep this developer-friendly and testable/tunable for V0.2, but avoid doing anything that utterly rules out easy conversion to a retail design (or DECC testing).

It is because of this focus on developer-friendliness that I want to get and keep at least two stacks running (eg PICAXE and Arduino) which should also help keep us honest on practical abstractions and modularisation and not too tied into any one bit of hardware.

Rgds

Damon

On 1 Apr 2013, at 17:38, Philip Canavan wrote:

> I've got a backlog of thoughts I'll try to find a home for on the Wiki, but this discussion chimes with a question I've been asking myself: are we aiming to develop a permissive stack that can be implemented by all OEMs, to get an open environment and a competitive marketplace, or a series of DIY modules than can be easily created and adapted by the hobby community to build an initial userbase? The two aren't exclusive, but have very different priorities in my mind. For the former, we need an abstract, flexible stack and a proof-of-concept implementation, but our implementation is hopefully irrelevant: as soon as anyone of any size gets involved they're going to want to innovate enough to be ahead of a no-brand, low-cost implementor. For the latter, we need a simple stack, top-to-bottom, so that any of the parts can be easily understood, implemented and tinkered with, and a friendly but comprehensive reference implementation with a high WAF. I fear if we go for both we might achieve neither, and bringing in the requirements for DECC adoption will probably introduce a third way...
> 
> 
> 
> From: Stuart Poulton <EMAIL ADDRESS HIDDEN>
> To: Closed list for developer discussions <EMAIL ADDRESS HIDDEN> 
> Sent: Monday, 1 April 2013, 17:30
> Subject: Re: [OpenTRV-dev] V0.2-Arduino: getting started
> 
> Ok, it's mu opinion that we're approaching this the wrong way.
> 
> You start with the 'hacker' community, so make it as simple as possible to develop for, then take the lessons learned, and optimise to reduce size and cost. 
> 
> Whilst in an ideal world we are aiming at an 'off the shelf' product we're some way off that. 
> 
> Stuart
> 
> On 1 Apr 2013, at 17:07, Damon Hart-Davis wrote:
> 
> > Hi,
> > 
> > Mike is right IMHO in that at least one version should be optimised for minimal build cost to ship to end users with a CE stamp under a well-known brand name where the end user is *never* going to reprogram anything.  Every £1 added to factory gate costs is probably £5+VAT extra for the end user.  If we want manufacturers to be able to ship a simple (non-scheduler) unit for (say) £20 per rad including RF components then everything that we can do without should come off, and the easier we make that as a design tweak to our developer-friendly boards and code, the better.
> > 
> > Maybe we should run a V0.2-min-cost-AVR design branch from or alongside the V0.2 PICAXE and Arduino-friendly ones?
> > 
> > Rgds
> > 
> > Damon
> > 
> > 
> > 
> > And we should keep that in mind for our design process
> > 
> > On 1 Apr 2013, at 16:47, Stuart Poulton wrote:
> > 
> >> 
> >>> 
> >>> One thing not being considered here is value to OEMs.  I thought one of the key reasons for choosing a permissive license rather than something like GPL was to encourage manufacturers to use the project in their own products, encouraging interoperability.  If this is the case then there has to be a reference hardware design that is absolute lowest cost.
> >>> 
> >>> Using a hobbyist platform is likely to be off-putting as well, I therefore think that vanilla AVR is a good compromise, especially since the three of us here with AVR experience all prefer to work bare-metal anyway.  There is then nothing stopping us from doing a super-set reference platform with a more capacious AVR and the Arduino bootloader pre-loaded.
> >> 
> >> Not sure I understand the reasoning behind this. why NOT develop around the AVR (Arduino) platform. 
> >> 
> >> It instantly opens up a larger hobbyist audience. Again personal choice, but I'll be going down the arduino IDE route. 
> >> 
> >> Stu
> >> _______________________________________________
> >> OpenTRV-dev mailing list
> >> EMAIL ADDRESS HIDDEN
> >> http://lists.opentrv.org.uk/listinfo/opentrv-dev
> >> 
> > 
> > _______________________________________________
> > OpenTRV-dev mailing list
> > EMAIL ADDRESS HIDDEN
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
> 
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
> 
> 
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev