rework hardware in KiCAD

[garlick]

This is an updated version of the pi-parport hardware, with design files redone in KiCAD. It was partly an excuse to learn KiCAD, now that Eagle has moved to a subscription pricing model and scared off much of the DIY community. Wow KiCAD has come a long way!

Starting with the KiCAD Raspberry pi hat template, I was able to include the ID EEPROM that makes this version compliant with the HAT spec, although the EEPROM isn't all that useful without drivers/device tree overlay upstream. In fact as of this PR it's untested.

The first board I soldered didn't work so I spent some time on the test programs. Now there are two loopback plugs that completely cover the basic connectivity and a "strobe" utility that outputs a 250khz (ish) signal on a single pin for debugging. The second board works. Apparently I'm just bad at soldering.

I also added some clarity about hardware licensing per #23 (I went with CERN's license).

[andrewtubbiolo]

Hi Jim:

This new IO board looks really nice. The EPROM should give a tie in to allow for a GPS interface as well no?

Andrew

On Wed, Jan 1, 2020 at 8:35 PM Jim Garlick notifications@github.com wrote:

Merged #24 https://github.com/worlickwerx/pi-parport/pull/24 into master.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/worlickwerx/pi-parport/pull/24?email_source=notifications&email_token=ABJINSTOJJZOANWFQTMLJ6DQ3VOIPA5CNFSM4KB6GHX2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOVXOD2JQ#event-2916891942, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJINSTRVQOO3Y7WFHK4XI3Q3VOIPANCNFSM4KB6GHXQ .

[garlick]

Thanks!

The EEPROM is fairly specialized to just carry the board info for "HAT" identification, and in fact that I2c bus is supposed to be dedicated to that. Its mainly useful if someone wanted to mass produce the boards, get all the bits included in the upstream kernel, and then have the board be more plug and play for end users. So probably not helpful for whatever you were thinking?

I'm hoping people will fork the repo and re-spin the board for whatever nefarious purposes they come up with. I was thinking a soft shutdown button would be handy (not having to ssh in to shutdown to avoid corrupting sdcard image). Maybe an RTC module and coin cell and/or a GPS module would be another idea. There's plenty of board real estate available.

[andrewtubbiolo]

Just to tickle your thoughts from my operating with the pi-port so far.

As an observer I'd love to have a GPS interface so that data could be shunted right into the FITS header. I've given up on INDI for now, but have been using the sbig-util utils and while they work there are some issues I'm hunting down. Such as .... I can't seem to command a set temp on my ST-8 below 2 deg C. I'm ready to believe it's my home-brewed v2 like board. I need to make another with some test points so I can capture the data going to and from the camera. I also can't command a 'bias' frame less than .2 seconds. With DOS based CCD Ops I can go down to .1 sec.

My long term goal with this architecture is to put in a GPS capability and use an FPGA to make a real hardware parallel port, with the addition of a fifo memory. That way you just send data to the GPIO pins then command a read from a FIFO memory that's being fed by hardware state machines. We talked about doing sidereal strip scanning with astronomical cameras and I still want to get to that. But I've been enjoying this project for the past 9 months. When I get some time to put into it. It's going to be a big part of my backyard observatory as I have two ST-8's to deploy.

Andrew

On Fri, Jan 3, 2020 at 9:37 AM Jim Garlick notifications@github.com wrote:

Thanks!

The EEPROM is fairly specialized to just carry the board info for "HAT" identification, and in fact that I2c bus is supposed to be dedicated to that. Its mainly useful if someone wanted to mass produce the boards, get all the bits included in the upstream kernel, and then have the board be more plug and play for end users. So probably not helpful for whatever you were thinking?

I'm hoping people will fork the repo and respin the board for whatever nefarious purposes they come up with. I was thinking a soft shutdown button would be handy (not having to ssh in to shutdown to avoid corrupting sdcard image). Maybe an RTC module and coin cell and/or a GPS module would be another idea. There's plenty of board real estate evailable.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/worlickwerx/pi-parport/pull/24?email_source=notifications&email_token=ABJINSVQHAHAWT5HLJ3CMKLQ35SWNA5CNFSM4KB6GHX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIBQ57Y#issuecomment-570625791, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJINSSEBVOG36OPDJ7W5ULQ35SWNANCNFSM4KB6GHXQ .

[garlick]

Any reason not to plug a GPS receiver into the Pi USB? Oh yeah, you are a glutton for punishment like me, so maybe that's just a rhetorical question :-)

Hey these parallel port ST series cameras contain two boards connected together with dual SIP headers. The "bottom" one has the analog CCD interface and mechanical interface to the CCD. The top one is an 8053 based microprocessor with a PLD and some other stuff to clock the CCD and respond to the parallel port commands. The protocol between parallel port and kernel driver is proprietary. The kernel driver is proprietary (though available as source). The user space sbigudrv.so is proprietary (and problematic to get DL to build for every OS/arch).

A really great project IMHO would be to replace the top digital board with a new open hardware/software one. It shouldn't be too hard to discern the signals on the dual SIPs. As I recall from my own poking around with it a while ago, the throughput of the whole camera is limited by the ADC sample rate (on the analog board). This means the digital board throughput ought to be easily achievable with off an off the shelf microprocessor like a low end STM32, and from there adding ethernet or USB is easy.

Any interest in that project?

I'd rather do that than make an uber parallel port for this - which has many challenges not least of which is sbig invented their own bulk data transfer protocol, so all the "standard" parallel port kernel code and the proprietary sbig kernel driver would need hacking. And in the end it's still a damn parallel port that should remain in the dustbin of history.

[garlick]

Maybe with my new KiCAD skills I'll make a D-shaped proto board that fits in the case with SIP connectors and bulkhead connectors for power, ethernet and USB, and we can go from there.

[andrewtubbiolo]

Hi Jim:

Yes, I'm a glutton for punishment and love to service my ADHD doing PCB

traces in layout.

Your assessment of the overall IP situation makes perfect sense. I

agree having had to hunt down and set symbolic links like spaghetti (ok it was not that bad), but hunting down the right .so or compiling it was not fun and not clean. Esp when I found a long sequence of emails on the INDI blog showing how flaky SBIG was about releasing new re compiles. It seems from my flawed memory that they're not going to work on the Pi-4. So your suggestion makes perfect sense. We should focus on that. Let me finish my little CCD OPS like python program so I can start observing. And I also want to make a board with 3d printed case so I can hang it on a telescope. Then yes, let's dust off and nuke the problem from orbit.

Andrew

On Fri, Jan 3, 2020 at 11:05 AM Jim Garlick notifications@github.com wrote:

Any reason not to plug a GPS receiver into the Pi USB? Oh yeah, you are a glutton for punishment like me, so maybe that's just a rhetorical question :-)

Hey these parallel port ST series cameras contain two boards connected together with dual SIP headers. The "bottom" one has the analog CCD interface and mechanical interface to the CCD. The top one is an 8053 based microprocessor with a PLD and some other stuff to clock the CCD and respond to the parallel port commands. The protocol between parallel port and kernel driver is proprietary. The kernel driver is proprietary (though available as source). The user space sbigudrv.so is proprietary (and problematic to get DL to build for every OS/arch).

A really great project IMHO would be to replace the top digital board with a new open hardware/software one. It shouldn't be too hard to discern the signals on the dual SIPs. As I recall from my own poking around with it a while ago, the throughput of the whole camera is limited by the ADC sample rate (on the analog board). This means the digital board throughput ought to be easily achievable with off an off the shelf microprocessor like a low end STM32, and from there adding ethernet or USB is easy.

Any interest in that project?

I'd rather do that than make an uber parallel port for this - which has many challenges not least of which is sbig invented their own bulk data transfer protocol, so all the "standard" parallel port kernel code and the proprietary sbig kernel driver would need hacking. And in the end it's still a damn parallel port that should remain in the dustbin of history.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/worlickwerx/pi-parport/pull/24?email_source=notifications&email_token=ABJINSTH2OGGAS46BEWPDDDQ3547BA5CNFSM4KB6GHX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIBXABA#issuecomment-570650628, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJINSXK6KNZ3S3NV3GAJOLQ3547BANCNFSM4KB6GHXQ .