EULER bus question...

[ealbers]

I'm trying to figure out how many GPIO pins I can use on the EULER bus, from the schematic I see some which look like they may be usable as GPIO so long as I don't need their 'primary' functions....

For example PB3,PB5,PB6 are labeled as I2S_MCLK,I2S_BCLK and I2S_DOUT, can I use the as gpio??

If so, I see the following pins available for GPIO (please correct me if any of these won't work as GPIO)

PB3,PB5,PB6,PD2,PD3,PD1,PB2,PB8 on one side (assuming I don't use the uart for uart stuff)

And PH8,PB4,PB7,PD4,PD5,PD0,PD6,PD7 AND PB9 on the 'right side of the schematic'

Total: 8 + 9 = 17 GPIO available on EULER??

My project needs as many GPIO as possible, communications etc will all be by ethernet once data is collected into ram)
Thanks!

[martinayotte]

Right !
You probably need to disable the UART in the DT if it is enabled.

[MarkHaysHarris777]

I'm trying to figure out how many GPIO pins I can use on the EULER bus, from the schematic I see some which look like they may be usable as GPIO so long as I don't need their 'primary' functions....

GPIO (general purpose input output) can be used for anything;  this is completely arbitrary.  As Martinayotte has said, you may need to disable the alternate functions in the dts|dtb, and you may need to disable a driver or two;

... I do not follow that plan.  If you need more gpio pins, expand the bus with serial to parallel arrangements ( you can control any number of pins [eight per 74hc595] with five lines )  data, shift clock, stor clock, OE, and MR.  Cascade as many 595 chips as you need.  Look into SPI;  however, SPI does require disabling uart(3) and uart(4). (both on the euler bus)

The secondary advantage of expanding the bus with shift registers ( SPI or i2c ) is that the there is some buffering between your pine board and your project.  Its fine for experimenting to go directly to the gpio pins (LED labs and the like) but real projects should have a well designed interface ; particularly where inductive loads are employed. 

gpio concept is the same for most SoC(s) including the pyboard, raspberry pi, arduino, PineA64, etc... arrangement and use is completely arbitrary depending upon needs and your own imagination.

[ealbers]

I'm hooking up 4 8bit A/D converters, they are high speed units which do 800,000 samples per second, They output 8 full bits, not serial, I don't know that spi or other serial protocols could keep up with 4 A/D converters....
I wish the address lines were output directly, then I could memory map the A/D's into the memory of the cpu directly.

Sampling for about 4 seconds of each gives 800K * 4 = 3.2Million 8 bit samples per second, 3.2 megabytes per second for 4 seconds (maybe upto 10 seconds)  I think the GPIO can handle reading this fast, but don't think putting shift registers/SPI, I2C in the mix would keep up. PLEASE correct me if I'm wrong!
 
I'm actually using 3 pine boards to read 12 A/D channels, then using a 4th pine to aggregate the data for display

---

Another concern, since my 4 a-d converters do 800K samples/second 8 bits per sample....that 3.2megabytes per second data rate needs to be done for say 10 seconds max, or 32 megabytes.

Does anyone know if I can write a little assembly routine to malloc 32megs, then completely disable all interrupts for 10 seconds while the samples are gathered, then re-enable interrupts and throw the 32 megs out the ethernet port?

I don't want any 'interruptions' during the 10 second sample period, they would cause issues with the data collected

[MarkHaysHarris777]

Use multiplexing;

... the 74hc165 is a parallel in serial out chip; you multiplex and latch the ADC of choice and then use SPI to bring the ADC bits into the pine via serial. The 74hc595 reverses that. A combination of 165 and 595 is generally used to scan a keyboard matrix, for instance.

Basically each ADC has its own parallel to serial setup. Your software should use multiplexing to select the parallel to serial setup (for the particular ADC) and then SPI is used to read it. This can be done with i2c as well.

Heck yeah your pine and SPI can keep up with your ADC chips;

[ealbers]

Use multiplexing;

... the 74hc165 is a parallel in serial out chip;  you multiplex and latch the ADC of choice and then use SPI to bring the ADC bits into the pine via serial.  The 74hc595 reverses that.  A combination of 165 and 595 is generally used to scan a keyboard matrix, for instance.

Basically  each ADC has its own parallel to serial setup.  Your software should use multiplexing to select the parallel to serial setup (for the particular ADC) and then SPI is used to read it.  This can be done with i2c as well.

Heck yeah your pine and SPI can keep up with your ADC chips;

How many bps can SPI do on the pine?  What clock rate is a SPI channel clocked at???  The processor frequency or the external oscillator freq?
I know the main processor is at 1100 mhz, which would be plenty given SPI's single bit per cycle, but does the SPI run at that clock rate?
800K 8 bit samples is 6.4megabits per second for 1 a/d channel, with framing bits say 8 megabits/channel
with 4 channels its 32 megabits/channel, which would need a 32 mhz clock rate on a SPI bus...within spi specs of 20-100 mbps, but I start to worry about the 74165, its specs say 28mhz top freq, could 2 74165's do 2 spi channels?
Perhaps just keeping the circuit simple even if it needs 8*4=32+8(control) 40 gpio signals?  Though its a lot of wiring...
Thanks!
E

[MarkHaysHarris777]

Hi,  I edited your last to take the words out of my mouth that you put there...  


... make sure when you quote someone that you don't place your text 'between' their start and end quote markers; otherwise, it looks like they said it all , and everyone is wondering what your point was. 

I reject the premise of this discussion;.  With an 8bit ADC  I doubt seriously that you need to take 800,000 samples per second.  That might be another discussion.

Have you considered using the MCP3208 eight channel 12bit ADC.  ( see mcp320x pdf datasheet )

The mcp320x ( x is the number of channels ) is a 12bit SPI ADC.  You might only need the mcp3204.  I think 12bit is the minimum I would use ( many applications need 20bit or more ).  I have used the mcp3202 many times , and have had great results on both the Raspberry PI , and the PineA64.  The mcp320x simplifies the application interface considerably, because it combines the ADC with the parallel to serial conversion for SPI.

[pfeerick]

How many bps can SPI do on the pine?  What clock rate is a SPI channel clocked at???  The processor frequency or the external oscillator freq?

I can't answer your question simply as I haven't played with the SPI stuff on the pine64 much, but @martinayotte may be able to.

However, what I can say is that if you look on p110 of the A64 user manual it appears that SPI can be clocked from one of three different sources, and then you've got the pre-divide ratio and clock divider ratio to deal with. And there is no functional difference between the registers for the SPI0 or SPI1 clock. Since this stuff is set by the registers, the device tree should hold the magic numbers. Fast forward to ln 2034 of the pine64 DTS, and you get the SPI register settings... and I think lines 2041 and 2042 are the ones of interest. I'll leave that up to you to work out out now, or someone else to explain... time for me to go back to the law textbooks and read up on commercial trusts and defeasible transactions...

[martinayotte]

According to the DTS mentioned above by @pfeerick, it shows "clock-frequency" at 100MHz.
Personally, I've never use SPI at such speed, I usually use 10MHz or 25MHz.

The mentioned project doesn't seems to be simple or trivial !
Also, I'm not sure is SPI DMA is present in longsleep kernel and this is probably an absolute requirement to do such capture.
Another solution would be to have it done using a FPGA with a DualPort SRAM, but this would be completely different approach ...

[pfeerick]

According to the DTS mentioned above by @pfeerick, it shows "clock-frequency" at 100MHz.

Thanks for that... a back of the napkin conversion indicated that it was 100Mhz... but it just didn't seem right to my poor confused brain.