I think you are worrying about things you don't have to worry about at all. None of that is actually a problem.
Those requirements just means my mom can't do it. My mom can't compile a c program either. So what? It's a non-issue. That still leaves a lot of people in the world who can do all of that no problem, with perhaps somewhat fewer able to really understand and develop the firmware code itself just because of how tied to the host computer it is. But even that is only *helped* by having the code there for new people to look at. Even if it's meaningless code at first, little bit at a time over time, it can be commented and understood and explained. But everything else is getting less and less rare every day, and some of that could be improved by users who encounter it as a difficulty. For instance, lots of people have rework stations and ovens and magnifiers and can physically assemble these parts no problem at all. I had a set of boards made up from oshpark and I can see the board in my hand now. I know I could assemble this with nothing but $5 plastic magnyfying glasses and a $30 hot air gun. Not even a real mask and oven. BUT, even if it really needed a mask and oven, people have those these days. There are tons of youtube videos showing how to do everything to assemble boards just like that even. Filing down the edges of the board is beyond trivial. It doesn't even warrant talking about. Just because you make a spacer by sawing thin slabs of wood doesn't mean I have to. I have used a few differend kinds of spacer on the figtronix boards already, and doubtless I'll continue trying different things to figure out simpler and simpler methods. This is another "too trivial to even talk about" non-issue. Programming a cpld or fpga poses 3 issues: 1 - Writing/developing: It's not as rare a skill as it used to be. People do it. 2 - Loading: But you don't have to be able to write the verilog or whatever, to merely install it. The usb blaster adapters to flash fpga's and do other jtag work are cheap today, and a lot of people are perfectly comfortable using them. I update stuff all the time that I couldn't have written. I have purchased several cottage electronics products like this where it's a normal end-user operation to get a usb blaster and flash new fpga code or firmware. 3 - Physical connection: If the existing board design doesn't provide a very convenient method for connecting up the pins to program the cpld or fpga, and you need some exotic jig or clip: 3A - So what? For some people, that will be no problem. 3B - That's just *today*. People can hack on the design and figure out some way to make (re)programming easier. None of this is remotely a reason not to publicize the designs and code. Don't try to say what a potential end-user could or couldn't do. Even if you are right and you are the only person in the world who can make use of the info to produce a working unit, it's still valuable as reference. But, you can't possibly think that anyway. Whatever the difficulties or arcanities are, it's ok. It's nothing you actually have to worry about. Is arcanities a word? :) -- bkw On Jan 9, 2017 8:52 PM, "Stephen Adolph" <[email protected]> wrote: > Doug, thanks for your note - read on...let's discuss. > > I'd be happy to put the board files on Oshpark, and place the > software, firmware, test applications in a git, but that isn't enough. > One needs to install the firmware and test the hardware afterwards.. > and that assumes you can assemble a REX in the first place. Plus you > need test jigs to do all that. Feasible, but a significant investment > in time and learning. > > The biggest issues I see- > > * fine pitch soldering > * grinding the PCBs down so that they can be plugged > * sourcing spacers - I slab cedar strips using my table saw.... 0.050 > inches > * firmware - it is stable now, but in general you must understand > RTL,VHDL and CPLD programming > * REX software is quite complicated. it gets right in to the OS via 4 > separate hooks and significantly affects boot up. it can be a real > challenge to debug. > * Keeping ahead of changes and how they work in all 5 supported models > is a bit of work also. One needs to have hardware examples of all 5 > models to do the testing. > > > The equipment I rely on in general includes > > 1) a bench grinder/sander > 2) a 15x binocular microscope > 3) a Tek scope > 4) a logic analyzer > 5) my hardware jig(s) for installing firmware and testing the hardware > (M100, PC8201 variant) > 6) xilinx CPLD toolset (easy to get but you have to learn to compile > and install CPLD code > 7) a basic weller temp controlled iron + solder paste in a syringe > > If there were zero design changes, here are the steps to assemble a > working REX. > > 1) assemble REX - grind PCB, hand solder CPLD, Flash, power supply, clean. > 2) install firmware - using Xilinx tools and known good firmware > binary, install binary image into CPLD. REX mounted in test jig. > There are 3 firmware versions. M100, T200, NEC. > 3) test REX - run stand alone test software on appropriate Model T / > rework failed units. > 4) install application > 5) final test > > Further development of REX is more involved obviously. Maybe at this > point future development is limited to software only, and it may be > safe to assume the hardware and firmware are fixed. > > Anyhow, as I said, it is feasible to transfer this to someone, but I > feel like it is a fair bit of work to transfer as well! > > Steve > > On Mon, Jan 9, 2017 at 8:26 PM, John R. Hogerhuis <[email protected]> > wrote: > > I think the only fundamental problem right now is availability, since > Steve > > has been busy with real life. Rex is not something you can just git clone > > and make. Part of it could be, of course. > > > > Component ordering, fabrication, assembly, test, order taking, shipping > is > > the current issue. > > > > -- John. >
