On Thu, Sep 17, 2015 at 12:04 PM, Paul Boddie paul@boddie.org.uk wrote:
On Thursday 17. September 2015 01.34.15 Luke Kenneth Casson Leighton wrote:
On Wed, Sep 16, 2015 at 11:49 PM, Paul Boddie paul@boddie.org.uk wrote:
Sure, I understand that. But what worries me a little is that experience isn't being gained to possibly refine the standard
paul, you misunderstand the concept of a simple long-term standard.
Not really. What I meant by "refined" is actually this:
[...]
first revision was to remove SATA and replace it with a 2nd USB2. second revision was to add VREFTTL, add SD/MMC and UART, third (or possibly still part of the 2nd) was to reduce 24-pin RGB/TTL to 18-pin RGB/TTL and use the 4 spare lines for an SPI interface, also USB3 was added at some point. PWM and an extra EINT were also added. the fourth - and almost certainly final revision - has been very recent: removal of Ethernet, upgrading to being able to do USB 3.1, as well as add 2 more EINT lines and 3 more GPIOs.
those interfaces have all been very carefully considered, especially when developing the ICubeCorp IC3128 CPU Card, where, due to its low pincount and being a QFP, there's *literally* only 2 spare unused pins left on the *entire* processor that don't go to the EOMA68 interface or the SD/MMC boot card.
All of this has happened before we get to the point where we call it a final standard, but what worries me is that there may be an application that hasn't yet been considered because the collective experience of trying to make devices using it is not broad enough.
well, as well as the section on the elinux.org web site analysing and tracking half a dozen different standards and their limitations, that's what the section on "interfaces" in the white paper is for, to go through the past (several decades of computing), learn from it, predict where it's going, track that for 4 years, adjust the tracking to make sure it fits, then re-predict, re-confirm, re-track and then at some point say "ok done".
it's precisely the knowledge of prior failed standards, paul, that's kept me from going, like a drunken naive wannab computaa n00b "okaay yeahh i wanna do a standurd now, let's put some inturfaciz in 4 fun, make some lolli y not?" - translating that into english it reads "create something then throw it out the door in under a year and hope it works" *NO*.
i recommend reading the sections on the white paper covering the standard's development and justification (so that i don't have to repeat it here) because i go into some depth to justify each of the decisions that are made, including analysing and demonstrating how long they've each been around, and how long they are likely to stay around.
I must admit that this is coloured by my interests in "retrocomputing" where one can look at products that were made and then consider how they might have been improved, even by a small amount, in a way that might have made them a lot more successful.
well then, you would enjoy the anecdotes that i included in the white paper, which include some historical and hilarious examples of exactly that.
At the time, you'd have some company or other designing and manufacturing their products to a tight schedule (usually to hit the market at the best time of year), but there would be limitations discovered by the customers that would limit the competitive lifetime of the product.
... or in the case of standards, not enough thought went into them, so they cause utter confusion and mental melt-down in the minds of adopters. i am not joking but the only decent standards which do not cause such complete melt-down are COM-Express and PC-104. there's no "optionalitis" in those standards (except COM-Express module sizes, and that's ok).
.... https://en.wikipedia.org/wiki/PC/104#Potential_Compatibility_Issues aaargh noooo, PC-104 is.... arg. of course, because it's based around the IBM PC which of course needs 12v, 5v and 3.3v, it's all gone tits-up thanks to some carrier boards not properly supplying all the required voltages, so the CPU boards themselves provide converters to compensate... .which of course fucks everything up because the difference between the I/O levels is enough to draw current one way or the other and burn out components.
this is *EXACTLY* why the Certification Mark is so damn important, so as to be able to stomp from a Great Height on anyone not properly following the EOMA68 standard.
In any case, from what you've written, I guess we'll find out for ourselves soon enough about how successful the refinement process has been. Not that I think that it hasn't been successful enough, however.
[...]
Still, I wonder what those of us reading this list might be able to do to move the effort forward in our own way.
that would be great.
Any suggestions? :-)
a couple which were in my reply (two product ideas), whilst as you hint at most stuff now has to wait until i've got the prototypes for the jz4775 and a20 cpu cards and the two products microdesktop and laptop_15in done.
l.