I would like to design a POT for the PINE64 that requires a lot of I/O. For example, I would like to design a board that has 4 stereo (or even 8) channels of high-quality audio output. What resources of the PINE64[+] would be appropriate for this endeavor? Can some of the existing interfaces (like display or camera) be re-purposed, and is there information available about how to do this?
(01-13-2017, 12:23 PM)richw42 Wrote: [ -> ]I would like to design a POT for the PINE64 that requires a lot of I/O. For example, I would like to design a board that has 4 stereo (or even 8) channels of high-quality audio output. What resources of the PINE64[+] would be appropriate for this endeavor? Can some of the existing interfaces (like display or camera) be re-purposed, and is there information available about how to do this?
With the right firmware and drivers ( of your own design ) this is theoretically possible. Audio is just a special purpose GPIO pin ( register ) in the SoC; gpu. The problem(s) that you are going to run into is that the gpu is closed hardware protected by NDA(s) and is very poorly documented.
You would have to provide the device tree dts|dtb for the ports ( registers ) and you would have to provide the kernel interface(s) -- drivers. I am pretty certain no one has done this yet.
Most people have some trouble setting up the audio-jack for stereo output ( rather than hdmi output ) and something like four or eight channel output is very much "out there" on the edge. Best of luck, but I have no hope for your project ( none ).
The integrated audio codec does not have that many channels so you will have to basically make a soundcard based on an external audiocodec with a supported interface, here I would say USB or SPI are things to look at, not sure about the status of I2S.
(01-13-2017, 05:51 PM)xalius Wrote: [ -> ]The integrated audio codec does not have that many channels so you will have to basically make a soundcard based on an external audiocodec with a supported interface, here I would say USB or SPI are things to look at, not sure about the status of I2S.
It looks like SPI might be fast enough. I would just have to cram all the data through the byte-wide interface, and figure it all out on the other end with an FPGA. The next research project will be what Linux can do for me.