Open Source Hardware

[Gokkul55]

I have always been a fan and user of open source software. But being a hardware engineer it has always bugged me there need to be open hardware too, just like software.

And there are, like "arduino", "raspberry-pi" etc, but all seem to focus on prototyping. I am looking for some open hardware which can be directly deployed as a product. Complete system with nothing to add.

I couldn't find such, so i started one.

http://sourceforge.net/projects/openaut/

It is still in planning

This is a project for developing industrial hardware for automaton. If any one else any more idea please let it out

Thanks
Regards
Gokkul

 

[IRstuff]

I'm not fully convinced that "open-source hardware" makes sense from a practical perspective. It's one thing to have a software module that needs to be tailored for a specific application, but tailoring for a specific hardware application generally requires more than simply swapping out an ADC.


To maintain generality, I think that you'd wind up with something very similar to an Arduino or Raspberry.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[Gokkul55]

Open Source Hardware is a bit difficult to conceive, i do agree.

The idea is to develop a community based product (just like in software) which is easier said than done in hardware platform.
But some where the initiative has to be taken right ?

There are tools for developing hardware products but my idea is to develop a complete product not just electronics but even mechanical included.

Here the product need not be general (that is what i want to avoid). Develop product to cater specific application only. I have from my experience seen that community developed product are far better that proprietary product (in software), and i wish to harness the same in hardware. I very much believe in the power of the individual


Thanks
Regards
Gokkul

 

[MikeHalloran]

The original IBM-PC was a decent example of open-source hardware.
IBM published source code for the BIOS, schematics from which one could reverse- engineer the timing limits, and anyone could measure the box.
It worked out fairly well for IBM.
And it sort of died with Phil Estridge.

For the successor, the PS/2, IBM published bus timing and envelope dimensions, so less reverse engineering was required, but they refused to relase the bus to the public domain, or to grant licenses to use it, and they declined to manage the assignment of hardware identifier codes, so nobody built it into anything.

My then employer did build a PC into some products.
It worked great until the motherboard industry got really cranked up and started pushing prices down.
Every six months or so, our motherboard supplier would succumb to price competition,
and we'd have to qualify another supplier.
Unfortunately, that process took nine months or so, mostly because we had to test and measure _everything_,
because new suppliers would get a basic design from Intel, then differentiate it with new features, or find a way to include the old features for less money, but none of them had the time or the talent to do it right, including especially timing analysis.
Our product started out with an 8088, which was more than it needed, but when everyone stopped making 8088 motherboards because they couldn't make money selling them for fifty bucks, we were forced to use an 80286, then an 80386, than an 80486, then a Pentium, and then I don't know what, but you could probably do all it had to do with a Raspberry PI or an Arduino or a Propeller now.
I'm glad it's not my problem anymore.

But I have to wonder what your new platform would bring to the party, and how you'd sell it against bloodthirsty competitors, and how long _anyone_ could afford to keep building it. E.g., if I built your stuff into a product, and I were still in that market I left long ago, I'd need an assured source of supply for at least ten years. ... and nowadays, entire industries appear and disappear in that sort of time frame.









Mike Halloran
Pembroke Pines, FL, USA

 

[IRstuff]

" Develop product to cater specific application only."

To what end? Mike's example of the PC worked for what it was intended, but a customized design without the extra fluff will almost always be a cheaper solution from a production perspective. As it was, the original PC design was severely hampered by the memory segmentation issues with the 80x86 family, until, I think, the 386 was built with a purely linear memory. The AT-bus architecture could not handle the higher data rates required in the Pentium class, and video busses in the last decade have come fast and furious to keep up with the demands for graphics rendering speeds.

The Arduinos work for relatively limited scenarios, and at the core really only consist of a microcontroller. Even at that, there are at least 4 variations of the primary processor, so economy of scale is already lost. And while the Arduino has been usefully applied to navigation, it's limited navigation, intended for DIY aircraft. Actual deliverable systems for UAVs for real-world applications need way more horsepower than available in any of the possible Arduino processors. So, something that is open-architecture, and is applicable to navigation/positioning, is not useful for the same application on a bigger platform.

Open source software is unique in that the entry cost is absurdly small, i.e., the cost of a decent compiler. To be efficient at doing something similar for electronics would run easily 1000x higher cost, particularly if the hardware has to meet environmental requirements. Who's going to pay for qualification testing? What requirements should it be qualified to? What tool verifies performance? What tool verifies reliability? When a board is found to have a bug, re-spinning the board is an expensive proposition. A software bug simply requires a patch update, which can be done remotely and autonomously. Dead-bugging an IC or red-wiring a PCB is a manually intensive and non-trivial proposition, particularly if the board has significant surface mount content.



TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[Gokkul55]

You guys are right open hardware is kinda of tough, with all these new processors churning out every day.

May be time will give us a new solution, lets wait and see . I ll keep thinking of new ways to make the world a open place .

Thanks
Regards
Gokkul

 

[LiteYear]

I'm very curious about the potential of this. I think the end goal needs to be well scoped to get any sort of traction. Are you thinking of some sort of generic PLC device? Are you anticipating that once the project reaches maturity, you'll have an open source repository like this:

* schematics and PCB layouts sufficient for contract manufacture
* source code sufficient to build the firmware using a particular compiler?
* enclosure/wiring/terminal block details to produce a useful device?

I suppose you'd need goals to maintain generality:

* functionality in general to be enabled in schematics, optionally disabled by not fitting components
* data types and network protocols to be openly specified
* base speed very high, with real-time support

How would you configure the device? Provide a scripting environment using Python? Or supports hooks for the non-open LabView or SCADA packages?

How do you provide some future-proofing? Perhaps the CPU could be on a daughter board or otherwise very well segregated.

I'd love to see this work. There are lots of challenges to overcome. I think the biggest upfront challenge would be the dramatically long development cycle compared to software - how would you accept patches if it takes another prototype/test cycle to verify the changes? Not being able to automate testing would be another challenge - in software your tests can be as sophisticated as you like and continuous integration can run them autonomously. In hardware you'd at least need an up-to-date test rig and testing, assumedly, would be a manual process.

Not to be discouraging, but the idea does remind me of that modular phone nonsense getting around at the moment:

http://www.phonebloks.com/

Good ideas in one domain don't necessarily translate to another. Unfortunately component hardware isn't as plug-and-play, or as independent as people would like to believe. By the time one platform is designed and sufficiently tested, another must-have hardware development has come along that isn't compatible.

 

[IRstuff]

Yeah, that's a cute phone concept, they've got a long road to pave. If the locks fail when you drop the phone, it'll be fun for the average person to reassemble that phone.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[IRstuff]

Oh, and not to mention that giving every subsystem its own housing generally blows the SWaP all to bits.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[Gokkul55]

The idea here is to have modules for industrial automation. Right now i do not plan to develop a PLC, the idea ids to develop only I/O modules with generic interface like RS485 - MODBUS for example.

This would make it easy to interface with any existing PLC. We can also add other communication protocol as we go on.

Are you anticipating that once the project reaches maturity, you'll have an open source repository like this:

* schematics and PCB layouts sufficient for contract manufacture
* source code sufficient to build the firmware using a particular compiler?
* enclosure/wiring/terminal block details to produce a useful device?

Yes something like that. But i cannot be sure where it might lead us to. I have some code ready for PIC but plan to port it to ATMEGA.

How do you provide some future-proofing? Perhaps the CPU could be on a daughter board or otherwise very well segregated.

That is one way, but looking at the project being open and the only part that might need replacement is the Processor (as all other circuits need not be changed) is kind of future proofed.

The analog system in most projects has not changed, a simple voltage divider is that same and i still see them in top end products. We can not change that. But new processors with better features will make the development a nightmare.

Once we have a large community these might not seem as a huge problem (I hope )

How would you configure the device? Provide a scripting environment using Python? Or supports hooks for the non-open LabView or SCADA packages?

I am not sure i get you.

I'd love to see this work. There are lots of challenges to overcome.

I would love to see this work too. Yes there are challenges, but that is what i love about it, it is when we try to overcome them something new is born.

how would you accept patches if it takes another prototype/test cycle to verify the changes?

This is where i believe the community comes in. I have been a part of this forum for some time and i have solves a few problems with just chatting and posting here.

What i mean to say is that i believe we can avoid most of the problem if the circuit is open, people can point mistakes in design even before we go for prototyping.

There are some hardware simulation tools too which could help.

It is similar to what happens in the forum, just that now people have more resource and so can point out mistakes more effectively.

Bit if we still get hardware bugs after prototyping, then we will have to live with it

We talk about how simple and easy it is for open software development, but was it really this simple when it all began. As i said time will give us a solution, for now i am just gonna keep working on it.

May be at least we will have a repository of tried and tested circuit for someone to use.

Thanks
Regards
Gokkul

 

[MikeHalloran]

Mechanical hardware testing can indeed be automated, provided that your volumes can justify the cost of the test tooling.
Somewhere around 10,000 units/day should make it easy to justify.
Can you sell that many? ... and tomorrow? ... and every day after the distribution pipeline is full?

The other edge of that sword is that the cost of the manufacturing tooling tends to retard evolution of the product itself.

Sure, you can make the tooling modular, flexible, even athletic. BTDT.

I've been involved in several attempts to design modular products or subproducts. What killed every one of them is inability to see into the future with any clarity, so as to provide the proper foundation in the core for future products.
You see it from time to time. Product released in 'modular' pieces that all fit together nicely. The next year, the manufacturer is tearing his hair out because The Next Big Feature that they must have to catch up with the market requires a bit of structure, or a faying surface, or a wire, that's not present in the original release, and can't be retrofitted. So they have to start over with something else.

Example:
I bought a bunch of Craftsman battery powered tools, all powered by the same battery. Then they released a whole new set of tools, all powered by the same motor, and a different battery. The generation prior to that was also powered by a 19.2V battery that interchanges with nothing; I have a few of them, too.

Modularity has another cost; internal interfaces. Long ago my team prototyped a modular electronic system, with a backplane bus and twelve daughterboard connectors, in order to provide the flexibility to add and delete functions so as to provide a range of products at different price points and allow for a little evolution. The cost of those connectors, and the backplane, and the board supports, guides, retainers and ejectors, made the product uncompetitive with an equivalent product from a competitor, which was built on one big board with no 'internal' connectors. So the product died before the design was completed.








Mike Halloran
Pembroke Pines, FL, USA

 

[itsmoked]

Isn't the Arduno stuff open source hardware? There are a zillion shields you can buy and stack on. Motion control, location, comm, video. analog, relays, etc, etc..

Keith Cress
kcress -

http://www.flaminsystems.com

 

[IRstuff]

"the only part that might need replacement is the Processor (as all other circuits need not be changed)"

That assertion is generally incorrect. Every new generation of processor typically requires faster or bigger interfaces, thereby requiring most, if not all, of the processor peripherals to change. Just simply consider the case of upgrading from the 8086 to the 80286. In that particular instance, not only was the processor bus width doubled, the bus was made substantially faster, and floating point processing in hardware was added in the form of the 80287, which required a complete redesign of the processing core of the PC, in additional to increased bus speed. Eventually, the 80386 incorporated the floating point processing directly into the main CPU, thereby incurring another motherboard redesign. memory management was introduced, which incurred another redesign. The 80486 had more I/O, so another core redesign. Somewhere along the way, the AT-bus for peripheral boards was upgraded, and upgraded again to the PCI bus. The 80486 and later architectures incorporated specialized graphics busses to supplement the PCI bus for improved performance.

Meanwhile, any C source code for processing, say, an FFT, could probably still be compiled and run on a PC. In fact, I've got command line DOS programs that still run in the DOS window in Windows 7. For that matter, most DOS programs could still run under W7, particularly if there are no graphical interfacing required.

Admittedly, there were 80286 daughter cards that could be inserted into an 8086 socket and some performance improvement could be gained with processor intensive programs, but, the backwards-socketing is extremely inefficient and wasteful of processing performance improvements that could have been gained in a new motherboard.

The Arduino was never intended to be a cutting edge processor family, so there is less pressure to push for performance. Nonetheless, the ATMega series processors are not compatible with the processor on the Uno or Diecimila.

http://en.wikipedia.org/wiki/Arduino#Official_boards

Note the changes to the peripherals as well. Even the USB interface, which is protocol-wise unchanged, has a hardware change from the A to mini-B connector. And those are actually upgraded from the FTDI interfaces on the earlier generation boards.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[LiteYear]

The idea here is to have modules for industrial automation. Right now i do not plan to develop a PLC, the idea ids to develop only I/O modules with generic interface like RS485 - MODBUS for example.

Oh okay, I see. Can't say I can see much room for innovation there, but I'm happy to be educated.

But i cannot be sure where it might lead us to.

Sure, but if you want participation it's important to have a vision at least.

That is one way, but looking at the project being open and the only part that might need replacement is the Processor (as all other circuits need not be changed) is kind of future proofed.

Heed IRstuff's advice well here.

How would you configure the device? Provide a scripting environment using Python? Or supports hooks for the non-open LabView or SCADA packages?

I am not sure i get you.

I was off on the PLC track, so no longer directly relevant. A similar question for the module track though: are the modules going to be configurable? Eg. will you be able to specify the analog input range, or the update rate, or the pre-processing filtering applied? If so, what is the protocol? Will it be PLC agnostic?

I have been a part of this forum for some time and i have solves a few problems with just chatting and posting here.

I think this is a poor analogy. Very rarely is anything solved on this forum, or any other. Suggestions are made, hints are given, answers are provided, but engineering problems are "solved" by spending hours in the lab applying the suggestions, hints and answers, and dealing will all the real-world details.

We talk about how simple and easy it is for open software development, but was it really this simple when it all began.

Not only were the barriers much smaller, they're 20 odd years ahead!

As i said time will give us a solution, for now i am just gonna keep working on it.

That's the spirit! Best of luck.

 

[IRstuff]

I just remembered that there was an 8087 floating point co-processor, so some of the original PCs migrated to the processor/co-processor configuration, even within the reign of the 8086.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[MikeHalloran]

And there was an 80387, because 80386s did not come with numeric hardware.
Most 80486s did, but there was a stripper version, whose name I have forgotten, that lacked numeric hardware, which was available separately.
There was also an 80386 optimized for AutoCAD, now a rare bird indeed.


Mike Halloran
Pembroke Pines, FL, USA

 

[IRstuff]

Yeah, my memory is pretty hazy at this point. I jumped from CP/M 80 on Z80 to 386-based system on the home front. Work computers were 286-based and some people had 8086-based PCs.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[IRstuff]

The nostalgia track threw my line of thinking.

Even if everything else in the modular phone project was to work, there are issues with certain types of upgrades, like larger/smaller screens, different frontside cameras, etc. Given the lack of customization and additional packaging, it can only wind up grossly bulkier and heavier than even the thickest smartphones currently on the market. Moreover, the sell-price would most likely be at least double anything currently on the market.

The diverting to I/O modules makes them simply one of many, so what's the motivation to buy your stuff, particularly since there's going to be no serious user support, since there's no income to pay their salaries? Beyond that, you'd need to develop drivers so that any PLC can interface with your modules, which is likewise going to be hampered by the fact that you'll need to provide software support/upgrades, etc.

There's a huge difference between open-source SW and this idea. There are certain expectations/limitations that most users of open-source SW are aware of and accepting of. Users are willing to put up with missing things. HW, particularly industrial systems are expected to be plug&play, and users are not going to be tolerant of bugs, delays, etc., particularly if it means stopping a production line or killing thousands of dollars of product.

Moreover, I/O modules tend to be connected to something else on the other side, which requires extensive knowledge about sensors, measurements, signal conditioning, etc. None of this is cheap and amenable to people spending their spare time diddling with. Whoever uses these modules will expect prompt and effective problem solving/hand holding.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[MikeHalloran]

You had a Z80? Lucky bastard!
My outfit was very slow to buy computers for engineers.
Secretaries got PCs and ATs, we, ahem, acquired, 8080 Multibus SBCs which were in stock for use in embedded systems, and put CP/M on them.

I graduated to an 8086 SBC, put a V30 on it, and got it to run CP/M-86 natively and CP/M(80) through a lightweight translation layer. Bringing that up was weird, single stepping through 8080 code with DDT-86. I beat on that thing for months, and couldn't find a clean way to make it run Z80 code without modifying the binaries.

I used to be good..




Mike Halloran
Pembroke Pines, FL, USA

 

[IRstuff]

Yeah, CP/M80, an entire operating system in something like 4kB. That, coupled with Turbo Pascal taking up only about 35kB, which included editor, compiler, linker, assembler, and debugger, leaving nearly 30kB for programs; sweet! Yeah, baby!! ;-)

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529