I'm designing a headphone/line DAC box with an internal raspberry pi/odroid USB streamer. I've built an ODoid C2-based telescope control platform, including completing ubuntu and the services in 64bit arm, that controls the mount, star tracking, telescope autofocus (arduno & DRV8824 servo control) and cameras.
I'd like to put a small screen capable of basic controls but also be able to pass through the HDMI out from the pi/odroid and stream the USB/i2s.
I'm thinking starting with a CPLD to monitor power supplies, power up/down soft start etc using optocouple sensing. The CPLD would then provide the control logic from power on and if/when the pi/droid is powered up and booted switch over control the screen and controls to Plex for example to stream audio.
The benefit is that the CPLD is instant start compared to an FGPA and can process parallel streams of data vs a small microcontroller.
All the digital noise will be behind shielding, although it's likely to add some noise. All the power will operate without needing the CPLD for safety.
Was thinking of this CPLD: http://www.farnell.com/datasheets/1...eRI4JRDExFurrllGReUag1Ybwj2M2PcxoCHnIQAvD_BwE
Thoughts?
I'd like to put a small screen capable of basic controls but also be able to pass through the HDMI out from the pi/odroid and stream the USB/i2s.
I'm thinking starting with a CPLD to monitor power supplies, power up/down soft start etc using optocouple sensing. The CPLD would then provide the control logic from power on and if/when the pi/droid is powered up and booted switch over control the screen and controls to Plex for example to stream audio.
The benefit is that the CPLD is instant start compared to an FGPA and can process parallel streams of data vs a small microcontroller.
All the digital noise will be behind shielding, although it's likely to add some noise. All the power will operate without needing the CPLD for safety.
Was thinking of this CPLD: http://www.farnell.com/datasheets/1...eRI4JRDExFurrllGReUag1Ybwj2M2PcxoCHnIQAvD_BwE
Thoughts?
Last edited:
Researching this:
A CPLD would be fast enough to pass through HDMI however there's not enough resources to provide a screen buffer style interface. It could act as a switch of display. There's instances of people doing HDMI passthrough with these and 1-1 conversion.
If the screen was a SPI style plot-command - then this could be possible, simply hard code the SPI pins for operations to redraw the screen. However this would not allow HDMI passthrough at a the needed bit rate.
Dilgent do an Artix 7A with 512K SRAM, which could be interesting - a write could be made into the SRAM and then rendered to HDMI. However a screen 640x480 8bit = 308Kb, so we can't double buffer unless we compress the bit depth to something smaller. HDMI renderering can simply use a colour palette for rendering a few colours (say 8) which makes it faster updating, can separate draw and display buffers for smoother redraw. Doing this could make the screen image 75Kb and acts to reduce impact on the bus but still looks good (it could even do fills based on maths!).
It sounds a bit overkill considering the Soekris R2R DAC uses a Spartan 6 - which is smaller than the Artix, but the HDMI needs that speed.
Once the PI ubuntu is booted then it can simply switch to HDMI passthrough.
In theory the FGPA should be booted very quickly (for those scenarios when you simply want to start and play rather than stream). The FGPA can continue to monitor the rest of the things and allowing the controls and switching to be routed to PI control.
Given the DAC case will be about 90cm tall max - it means the HDMI screens available that have a decent framerate is quite small - however it would mean I could stream TV or audio (naturally this would not bypass HDMI protection but that's not a problem as Ubunti doesn't support that). It could also stream the audio from the HDMI as well.
The ODroid C2 I have simply runs headless (no HDMI attached), but does have a SPI GPIO low res TFT screen for simple in field diagnostics with about 1 fps. If I want the desktop I'll VPN into it anyway.
Hmmm...
A CPLD would be fast enough to pass through HDMI however there's not enough resources to provide a screen buffer style interface. It could act as a switch of display. There's instances of people doing HDMI passthrough with these and 1-1 conversion.
If the screen was a SPI style plot-command - then this could be possible, simply hard code the SPI pins for operations to redraw the screen. However this would not allow HDMI passthrough at a the needed bit rate.
Dilgent do an Artix 7A with 512K SRAM, which could be interesting - a write could be made into the SRAM and then rendered to HDMI. However a screen 640x480 8bit = 308Kb, so we can't double buffer unless we compress the bit depth to something smaller. HDMI renderering can simply use a colour palette for rendering a few colours (say 8) which makes it faster updating, can separate draw and display buffers for smoother redraw. Doing this could make the screen image 75Kb and acts to reduce impact on the bus but still looks good (it could even do fills based on maths!).
It sounds a bit overkill considering the Soekris R2R DAC uses a Spartan 6 - which is smaller than the Artix, but the HDMI needs that speed.
Once the PI ubuntu is booted then it can simply switch to HDMI passthrough.
In theory the FGPA should be booted very quickly (for those scenarios when you simply want to start and play rather than stream). The FGPA can continue to monitor the rest of the things and allowing the controls and switching to be routed to PI control.
Given the DAC case will be about 90cm tall max - it means the HDMI screens available that have a decent framerate is quite small - however it would mean I could stream TV or audio (naturally this would not bypass HDMI protection but that's not a problem as Ubunti doesn't support that). It could also stream the audio from the HDMI as well.
The ODroid C2 I have simply runs headless (no HDMI attached), but does have a SPI GPIO low res TFT screen for simple in field diagnostics with about 1 fps. If I want the desktop I'll VPN into it anyway.
Hmmm...
Last edited:
Ok, so...
this 4.3" screen can be driven at 60Hz and can be addressed by either parallel or SPI
It's 20ms response time means it can do 50Hz (so how successful 60Hz would be is another thing).
The data sheet for this screen (built into the glass): https://cdn.displaytech-us.com/sites/default/files/driver-ic-data-sheet/Himax-HX8257-A01.pdf
RGB parallel interface is 24bit (colour is 6bits/channel) at 9MHz. This means it would be possible to attach it to the FPGA - no HDMI connection required - then it is a case of HDMI -> RGB conversion for the RPi HDMI connection or a direct render from the FPGA for the standard DAC/HPA interface depending on mode.
The RPi/ODroid can then still benefit from it's GPU acceleration.
This is getting into breadboard territory (hoping the BB lines don't result in too much capacitance).
this 4.3" screen can be driven at 60Hz and can be addressed by either parallel or SPI
It's 20ms response time means it can do 50Hz (so how successful 60Hz would be is another thing).
The data sheet for this screen (built into the glass): https://cdn.displaytech-us.com/sites/default/files/driver-ic-data-sheet/Himax-HX8257-A01.pdf
RGB parallel interface is 24bit (colour is 6bits/channel) at 9MHz. This means it would be possible to attach it to the FPGA - no HDMI connection required - then it is a case of HDMI -> RGB conversion for the RPi HDMI connection or a direct render from the FPGA for the standard DAC/HPA interface depending on mode.
The RPi/ODroid can then still benefit from it's GPU acceleration.
This is getting into breadboard territory (hoping the BB lines don't result in too much capacitance).
Last edited:
Hmm - just researching Artiix start up times - it's measured in seconds (5-13 seconds) configuration time - it's configuration is volatile vs the CPLD that is non-volatile.
Using systemd-analyze command on my C2 with ubuntu (this is a 4 core ARM + 2GB) running Kde running a eMMC card rather than SD card for storage with a few start time things:
So that is rivalling an FPGA with only a CPLD being faster.
Using systemd-analyze has a great command "blame" that means I can see that most if this is fine - a few optimisations but most of the time is the desktop service/VNC server I use by the looks of it.
Perhaps just use a CPLD to operate the soft start etc and as a controls router so mute/volume still works whilst the RPi is loading. Given the minimum sizes of screens with HDMI sockets - it may still need an something to convert HDMI->RGB and a FPGA could do that and so could a CPLD..
So it looks like without the need for an on-screen menu- a CPLD (£20) can do what is required whilst the RPi/ODroid would boot and act as a control mix & HDMI-RGB converter.
Using systemd-analyze command on my C2 with ubuntu (this is a 4 core ARM + 2GB) running Kde running a eMMC card rather than SD card for storage with a few start time things:
Code:
Startup finished in 4.960s (kernel) + 6.986 (user space) = 11.946s.So that is rivalling an FPGA with only a CPLD being faster.
Using systemd-analyze has a great command "blame" that means I can see that most if this is fine - a few optimisations but most of the time is the desktop service/VNC server I use by the looks of it.
Perhaps just use a CPLD to operate the soft start etc and as a controls router so mute/volume still works whilst the RPi is loading. Given the minimum sizes of screens with HDMI sockets - it may still need an something to convert HDMI->RGB and a FPGA could do that and so could a CPLD..
So it looks like without the need for an on-screen menu- a CPLD (£20) can do what is required whilst the RPi/ODroid would boot and act as a control mix & HDMI-RGB converter.
Last edited:
Looking at this in detail - it may be able to perform a basic conversion but it will not be able todo the other services with the 40 pin CPLD I had planned. It's only just possible if we drop the SPI bus to the screen.
HDMI has;
* 4x differential pairs for the channels (8 pins) - processing these ahead of the CPLD using an opamp would be mean 4 pins
* 2 pins for EDID
The panel has;
* 24 pins for RGB data lines
* 4 pins for clocking (clock, data input enable, hsync and sync)
Total 38 pins (opamp 24 pins).
However CPLDs have function groups - so I'm not sure if we could process SPI on a bus at a different rate on the same without dividing clock rates and needing more pins anyway.. a second CPLD for everything else including implementing volume i2s and i2c routing for example.
This would mean the system works regardless of streaming board status for channel select, volume and mute etc immediately power is hit (assuming the DAC FPGA times don't cause a problem).
HDMI has;
* 4x differential pairs for the channels (8 pins) - processing these ahead of the CPLD using an opamp would be mean 4 pins
* 2 pins for EDID
The panel has;
* 24 pins for RGB data lines
* 4 pins for clocking (clock, data input enable, hsync and sync)
Total 38 pins (opamp 24 pins).
However CPLDs have function groups - so I'm not sure if we could process SPI on a bus at a different rate on the same without dividing clock rates and needing more pins anyway.. a second CPLD for everything else including implementing volume i2s and i2c routing for example.
This would mean the system works regardless of streaming board status for channel select, volume and mute etc immediately power is hit (assuming the DAC FPGA times don't cause a problem).
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.