Hi Steve, I agree that transferring would be work. I feel that separating the hardware and software may be the path forward, especially if the hardware design is proven.
My clocks use a 240mm square PCB that I source from Pcbcart. Experience has shown that they are cheaper than OSH part for volume. I normally order boards as 60 to 100 units at a time to take advantage of volume discounts. Same for parts, I have oearnt that volume discounts make sense in small scale manufacturing. After surface reflow, all of my boards go through a test and firmware loading jig. I published the design for one of the jigs on Instructables.com http://www.instructables.com/id/A-Programming-Jig-for-our-DougsWordClockcom-DeskC/ this radicaly simplifies the firmware load. I am confident that I could devel op something to do the CPLD load as well. From the perspective of manufacturing capacity, my workshop has microscopes and logic analysers and grinders etc etc.. but it woud be worthwhile figuring out how to modify the design so that there was no need to rip spacers from wood, or grind boards and remove as many manual handling steps as possible. Doug On 10 January 2017 12:52:26 pm AEDT, Stephen Adolph <twospru...@gmail.com> 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 <jho...@pobox.com> >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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
