re-order GPIO lines sequentially so they can be set in parallel

[garlick]

The parport-gpio driver calls gpiod_set_raw_array_value() to set all the GPIO lines in a port (data, control) at once. The docs say that one should put the GPIO lines in numerical order in the array in order to allow for the lower level code to optimize I/O. I didn't do that because I wasn't sure it would matter, and it would complicate board layout.

Do an experiment to see if that's worth it.

Issue data port writes of 0xff, 0x00, 0xff, 0x00, ... in a tight loop and measure timing on the staggering of bit transitions with MSO. Then try again with the bits in the device tree overlay sorted numerically (ignoring the incorrect bit mapping).

If it produces better timing, lay out v2 of the board differently.

[andrewtubbiolo]

Oh thank goodness I was not nuts. I'm going to use this on a SBIG ST-8, or try to, and I wanted to free up GPIO's 2 and 3 to install a hardware RTC for accurate time stamps. It was then that I noticed that the GPIO pins were set out to allow for a "almost" single layer board layout. I went looking for the 'data mangle' code that would take sequential data for the Data, Control, and Status words/nibbles and translate them to the layout order. I never found it. Did I miss something, or was it up to the user to do that themselves in their application?

[garlick]

Actually you can specify any GPIO to function mapping you like in the device tree overlay file.

The driver just uses whatever is presented by the device tree.

This issue was questioning the generic kernel GPIO code just did one I/O operation per bit no matter what, or if it could do better if bits could be packed into one GPIO register (say). Ultimately I didn't get around to testing this because my particular application (same as yours, albeit with smaller CCDs, yay!) "just worked" reliably.

Anyway, if you want to change the pin assignments on your board, just tweak the DTS file. Good luck and please let me know how it goes!

BTW, a revision of this board with an RTC and battery on it would be pretty neat for working in the field!

[andrewtubbiolo]

Hello Mr Garlick: Thanks for the fast reply! And thanks for the pointer to the device tree. I was brute force going thru the C flies looking for the bit shifts and masks to deal with the layout. I don't suppose you've tried TDI (Time Delay Integration) aka sidereal strip scanning, where each CCD row is read out at the rate the night sky walks across the imaging array while the tracking is turned off? I was afraid I'd have to use a FPGA or maybe an arduino to get the timing, but then a friend came across your project, and I'm going to give it a try. I'd be happy to add a RTC enabled board to your project. Thanks. Andrew

…

On Thu, Apr 25, 2019 at 2:42 PM Jim Garlick ***@***.***> wrote: Actually you can specify any GPIO to function mapping you like in the device tree overlay file <https://github.com/garlick/pi-parport/blob/master/dts/parport-gpio.dts>. The driver <https://github.com/garlick/pi-parport/blob/master/driver/parport_gpio.c> just uses whatever is presented by the device tree. This issue was questioning the generic kernel GPIO code just did one I/O operation per bit no matter what, or if it could do better if bits could be packed into one GPIO register (say). Ultimately I didn't get around to testing this because my particular application (same as yours, albeit with smaller CCDs, yay!) "just worked" reliably. Anyway, if you want to change the pin assignments on your board, just tweak the DTS file. Good luck and please let me know how it goes! BTW, a revision of this board with an RTC and battery on it would be pretty neat for working in the field! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/garlick/pi-parport/issues/4#issuecomment-486848371>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABJINSSPWBHVOA4UEUYUAQTPSIQTNANCNFSM4DV3CRNQ> .

[garlick]

I haven't tried it (yet) but don't the SBIG cameras support TDI natively (they call it "drift scan imaging")?

I seem to recall that their SDK offers a way to clock the CCD row by row in support of TDI....

[garlick]

See also garlick/sbig-util#17. There are some SBIG references there.

[andrewtubbiolo]

CCD OPS in windows does indeed allow you to do TDI. I'll use it for surveying, and I've tested it a few nights with very good results. However, I'm not sure if the PC does the sidereal rate shifting and readout, or if it's done on camera. Part of this long term project will be to make a hand wired board to allow my logic analyser test points to probe waveforms. Andrew

…

On Thu, Apr 25, 2019 at 5:09 PM Jim Garlick ***@***.***> wrote: See also garlick/sbig-util#17 <https://github.com/garlick/sbig-util/issues/17>. There are some SBIG references there. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/garlick/pi-parport/issues/4#issuecomment-486880517>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABJINSV34RGMDJ52WNJYX7LPSJB4NANCNFSM4DV3CRNQ> .

[garlick]

I think the older cameras have very little brain between the analog board and the PC and possibly CCD OPS could do TDI by just keeping the shutter open and requesting a line at a time from the camera with appropriate delays depending on pixel size and focal length. In other words the older digital board may not even try to get a uniform integration by reading out the whole image quickly and buffering it.

According to the SDK manual some support was added to disable buffering in the USB cameras to support TDI. Later, support was also added for TDI on the interline CCDs which I think have a whole different readout strategy compared to full frame.

Finally the SDK manual mentions something about "biorad TDI acquisition mode" which is a queryable camera feature, though I don't know what it means or if it's required for all cameras in order to do TDI (my guess is not - maybe it has to do with interline support).

[garlick]

Closing as I don't think the original issue is a thing. Reopen if it is.

[quorten]

Just wanted to comment, I also really like the idea of an board variant with an RTC on it too. Probably the best way to do this is with a single AVR microcontroller on the ID EEPROM I2C bus that acts as both an ID EEPROM and a RTC: you simply access the proper memory address to read/write the current time register. The 32.768kHz watch crystal clocks an asynchronous timer in the AVR. There would also be a 1-second interrupt pin too... that's important but unfortunately missing from some other Raspberry Pi RTC HATs because the SoC 19.2MHz oscillator has considerable long-term timing instability.