SGPIO input wider than 8 bits

[osterwood]

I see the functionality to change the SGPIO system first input pin and bus width, and the note in libgreat about bus width being limited to 8 bits.

Is creating a >8 bit logic analyzer as 'simple' as creating two logic_analyzer instances? But, it seems it's a singleton under device.apis on the host side.

Related question, can a single SGPIO input pin be configured as a clock source for two 8-pin functions? Should a SPGIO clock input pin be outside of the pin_configurations array or part of it?

I'm looking as using GreatFET as a parallel camera input device, and imagers have 8 to 12 bits of pixel data, frame and line sync signals, and a pixel clock. So ideally I'd be able to configure the SGPIO as a 14 bit input with a 15th pin as a clock source.

If that's not possible, I can drop down to 8 bits + clock and have 7 bits of intensity + 1 bit for frame sync (and determine line sync via bit counting and knowledge of the attached imager).

[ktemkin]

 creating a >8 bit logic analyzer as 'simple' as creating two logic_analyzer instances? 

Ideally, the API should be able to handle >8 bits readily, but there's one medium-ish TODO that's blocking this:

https://github.com/greatscottgadgets/libgreat/blob/master/firmware/platform/lpc43xx/drivers/sgpio_data.c#L551

Once this is done, two SGPIO instances can be instantiated, and then used to get e.g. 16-bit LA samples.

[AsFaBw]

I would also love this function and ideally a short corresponding tutorial on how to access parallel ports from the GreatFET. As example atteching an ice40 to GreatFET for parallel Transfer.

[gsigh]

Was looking at this, is more complex than one might assume. [ Sure, otherwise it just had been done before. :) ]

The general case of N pins with N in the 9..16 range is rather complex. SGPIO only allows chaining pins up to eight of them. More than eight pins involves two SGPIO chains, and combining their results in CPU code in the device firmware. While they complete at different times depending on their pin count. And both CPU cycles and RAM space are rather constrained.

A more naive approach of exactly 16 pins might be in reach (no promises though). Running two SGPIO chains with eight pins each, configured identically and started at the same time (in the same register access), should in theory have them complete (signal the "exchange" interrupt) at the same time. One ISR could grab both FIFO sets' results. But that involves more instructions than in all other configurations, thus cannot be done in the one currently used ISR of fixed length that is tuned for 40.8MHz rates and painfully avoiding jumps and other performance degrading issues ... Requires another ISR that is used in the "above 8 pins" case exclusively, will be limited to 20.4MHz samplerate for the 16 channels, yadda yadda ...

Cannot tell whether this approach works out or when I will have a version for public review. Cannot promise it will be acceptable to the firmware project even if it'd exist. Takes quite some trickery and does not combine well with existing firmware approaches.