ATmega32U4 Differential Output!? Hooking Displayport AUX

[TnF]

Hello. I started a personal project where i design a device that includes these 2 functions:

1) Read/sniff the EDID data of a Displayport downsteam device (i.e. a PC monitor)
2) Emulate the EDID data to the upstream device (i.e. a GPU)

I plan on using an Arduino Micro for several reasons:
- Cheap, readily available and easy to program
- Built-in USB so a PC can be used to read/write data to without any extra components
- Has ADC0/ADC1 pins exposed unlike Pro Micro explained below

From what i understand so far EDID data on Displayport are transmitted via the AUX Differential Pair of which has 2 available modes for operation (page 329):
- 1Mbps Manchester-II code
- 720Mbps FAUX 8B10B encoding

Now consider the standard link:

GPU<----Monitor

For snooping, i just hook the AUX pair from the Monitor to the Arduino using the dedicated differential pair input available on: ADC0/ADC1 negative, ADC4..13 positive (that's why i need ADC0/1 exposed, page 298).

This should work fine (at least for the 1Mbps mode). No idea how the ADC input impedance will affect the signal however.

For the EDID emulation, i place a USB switch IC (USB3740B, just what i have in hand and should work for this) in order to modify the topology to:

GPU<----Switch<----Monitor
                   ^--------Arduino

This is so i can switch the EDID data the GPU receives between the Monitor and the Arduino.

However, i am unsure which output pins are the most suitable to be used successfully with the Arduino in order to generate a differential output signal. I cannot find any info about it. I'll probably have to write to the output registers directly at the same time and do tricks to get the timing right?

Also i'll need a level shifter in between to drop to 3.3V signaling (i think), consider any bias voltage, and use the correct termination.
Maybe i need to use some kind of converter/driver instead.

As for the actual data being transmitted it looks like they are essentially I2C encoded SCL+SDA data but transferred over using the AUX differential pair link. It's called "I2C-over-AUX" in the documentation.
I am lost on this but since it's just software it can be done anytime. I just need to get the hardware right first (in fact i am preparing a 4-layer pcb as we speak).

Datasheets:

Displayport v1.2 standard:
https://glenwing.github.io/docs/DP-1.2.pdf

ATmega32U4:
https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf

USB3740B:
http://ww1.microchip.com/downloads/en/DeviceDoc/00001725D.pdf

Arduino Micro:
https://content.arduino.cc/assets/Pinout-Micro_latest.pdf
https://content.arduino.cc/assets/arduino_micro_schematic.pdf

[Yansi]

And the purpose of such device is... ?
Just wondering...

[TnF]

And the purpose of such device is... ?
Just wondering...

It's a kind of hack box for Displayport connections. Personally is to fix the whole issue with Displayport hotdetect-Windows monitor handling-GPU drivers-Monitor firmware chain mess since no-one else cares. But since there are many configurations with different behaviors i need to account for all cases, plus since i have the micro on there either way i can add extra features to increase the flexibility for reverse-engineering/development.

[Yansi]

I've expected a bit more technical explanation, rather than "Displayport hotdetect-Windows monitor handling-GPU drivers-Monitor firmware chain mess".

Displayport is usually the least troublesome video port one can find on a computer these days. So I was wondering what are you trying to fix by this.

[TnF]

I've expected a bit more technical explanation, rather than "Displayport hotdetect-Windows monitor handling-GPU drivers-Monitor firmware chain mess".

Displayport is usually the least troublesome video port one can find on a computer these days. So I was wondering what are you trying to fix by this.

That doesn't matter to go into details. What matters is that i provided all the info needed for someone with more experience to answer my question..

[janoc]

I've expected a bit more technical explanation, rather than "Displayport hotdetect-Windows monitor handling-GPU drivers-Monitor firmware chain mess".

Displayport is usually the least troublesome video port one can find on a computer these days. So I was wondering what are you trying to fix by this.

That doesn't matter to go into details. What matters is that i provided all the info needed for someone with more experience to answer my question..

I guess you don't understand that providing such context is essential if you want a meaningful answer. Otherwise it is akin "I just want to build a square wheel, why is everyone telling me it is dumb idea? Just tell me what is the best material for a square wheel!" 

More specifically - if you hope to run 1Mbps (I really hope you are not planning on decoding the 720Mbps stream) Manchester encoded differential signal out of an 8bit ATMega without any hardware support for it (you have read the datasheet already haven't you?), you are a wee bit optimistic ...

While it can be done (e.g. the V-USB bitbanged USB hack does something very similar for low speed USB at 1.5Mbps) if you try doing it while handling USB and other things, you are in for a rude surprise. V-USB uses hand-optimized assembler and skirts the USB timing requirements in many places to be able to do it. And while that micro is doing it, it is not able to do anything else.

Worse, if you want to "sniff" the data you are going to need to oversample the input, so you need to be able to run quite a bit faster than 1Mbps to have a stable input (and recover the clock and what not).

[Nominal Animal]

In Linux, the EDID data is available in /sys/class/drm/*/edid pseudofiles (generated by the kernel whenever accessed), and can be overridden using kernel parameter drm.edid_firmware=filename.bin , or drm modprobe parameter edid_firmware=filename.bin , where /lib/firmware/filename.bin contains the raw binary EDID data.

To dump the EDID data of all connected displays in hexadecimal format, run
    bash -c 'for N in /sys/class/drm/*/edid ; do echo "$N:" ; od -An -tx1 "$N" ; echo "" ; done'
To copy the EDID data to raw binary files, run
    bash -c 'for N in /sys/class/drm/*/edid ; do F="${N%/edid}" ; F="${F##*/}" ; cat "$N" > "$F.bin" ; echo "$F.bin"; done'

[TnF]

In Linux, the EDID data is available in /sys/class/drm/*/edid pseudofiles (generated by the kernel whenever accessed), and can be overridden using kernel parameter drm.edid_firmware=filename.bin , or drm modprobe parameter edid_firmware=filename.bin , where /lib/firmware/filename.bin contains the raw binary EDID data.

To dump the EDID data of all connected displays in hexadecimal format, run
    bash -c 'for N in /sys/class/drm/*/edid ; do echo "$N:" ; od -An -tx1 "$N" ; echo "" ; done'
To copy the EDID data to raw binary files, run
    bash -c 'for N in /sys/class/drm/*/edid ; do F="${N%/edid}" ; F="${F##*/}" ; cat "$N" > "$F.bin" ; echo "$F.bin"; done'

I can dump them on windows on problems, it's not what i've asked but thanks

I've expected a bit more technical explanation, rather than "Displayport hotdetect-Windows monitor handling-GPU drivers-Monitor firmware chain mess".

Displayport is usually the least troublesome video port one can find on a computer these days. So I was wondering what are you trying to fix by this.

That doesn't matter to go into details. What matters is that i provided all the info needed for someone with more experience to answer my question..

I guess you don't understand that providing such context is essential if you want a meaningful answer. Otherwise it is akin "I just want to build a square wheel, why is everyone telling me it is dumb idea? Just tell me what is the best material for a square wheel!" 

More specifically - if you hope to run 1Mbps (I really hope you are not planning on decoding the 720Mbps stream) Manchester encoded differential signal out of an 8bit ATMega without any hardware support for it (you have read the datasheet already haven't you?), you are a wee bit optimistic ...

While it can be done (e.g. the V-USB bitbanged USB hack does something very similar for low speed USB at 1.5Mbps) if you try doing it while handling USB and other things, you are in for a rude surprise. V-USB uses hand-optimized assembler and skirts the USB timing requirements in many places to be able to do it. And while that micro is doing it, it is not able to do anything else.

Worse, if you want to "sniff" the data you are going to need to oversample the input, so you need to be able to run quite a bit faster than 1Mbps to have a stable input (and recover the clock and what not).

No it's not a square wheel. It clearly says: hardware read and write of edid data through the aux channel. That's a pretty round wheel to me.
If you really want to fix the issue call Bill gates and ask them to fix their shitty code, call all monitor manufacturers and tell them to open source their firmware, and call Nvidia/AMD and tell them to stop locking basic features behind their workstation GPUs.

So back to the topic. No, i didn't plan on reading the 720Mbps stream. 1Mbps is doable i think. Worst case i just swap to teensy 3.2/teensy-lc/blackpill or even a teensy 4.0. That's where i need your input. I am mostly concerned about the Differential Output.

Reading can always be done anytime through the PC.

[Yansi]

You should be much more concerned, as obviously, you are missing a lot of things, like voltage signalling levels on the AUX line, handling the 720mbps stream, etc.

It is impossible to give any better suggestions, as you obviously won't share what are you trying to solve will your square wheel. So then don't be surprised we can't give any suitable recommendations.

And btw, you can override EDID data even on windows quite easily. Sometimes, Intel even provides means for creating custom resolutions regardless of EDID. (But not saying that Intel tools work particularly well - they did not work for me - due to having a bug calculating the timing incorrectly).

[TnF]

You should be much more concerned, as obviously, you are missing a lot of things, like voltage signalling levels on the AUX line, handling the 720mbps stream, etc.

It is impossible to give any better suggestions, as you obviously won't share what are you trying to solve will your square wheel. So then don't be surprised we can't give any suitable recommendations.

And btw, you can override EDID data even on windows quite easily. Sometimes, Intel even provides means for creating custom resolutions regardless of EDID. (But not saying that Intel tools work particularly well - they did not work for me - due to having a bug calculating the timing incorrectly).

You can use CRU utility to write any EDID you want into windows registry and bypass intel's bug. Obviously you don't know your stuff well that's why you see a square wheel. Maybe you want a pair of glasses too since you keep insisting on going out of TOPIC.

I've asked if it's possible to sniff and generate a 1Mbps Manchester-II code differential stream with a ATmega32U4.

IF THE DATA CONTAINED IS EDID DATA, PEPE MEMES OR NUCLEAR LAUNCH CODES IS IRRELEVANT TO THE QUESTION!

[Halcyon]

Holy giant font Batman, is that really necessary?

[Nominal Animal]

I know nothing, but if I was playing with the DisplayPort AUX channel, I'd use something like an SN65LVDS049 or SN65LVDS050 differential LVDS transceiver here, and have the microcontroller operate at 3.3V.

[janoc]

You can use CRU utility to write any EDID you want into windows registry and bypass intel's bug. Obviously you don't know your stuff well that's why you see a square wheel. Maybe you want a pair of glasses too since you keep insisting on going out of TOPIC.

I've asked if it's possible to sniff and generate a 1Mbps Manchester-II code differential stream with a ATmega32U4.

I suggest that you:

a) Take a chill pill. Screaming your lungs out and being an arrogant jerk throwing tantrums because you aren't getting what you want right away while you are asking others to solve your ill-specified problem is not exactly an attitude that will get you answers.

b) Download the f..g datasheet and start to read? And maybe do a few ballpark calculations? And google, so that you actually understand what Manchester is?

I wrote you already that it is maybe doable but it is going to be really marginal on the ATMega at best - and most likely beyond what you are able to program anyway.

Now you have brought out a Teensy - who knows, maybe? Blackpill certainly doesn't have differential outputs but maybe it can be bitbanged, those STM32s are fast. And anyway, you can always use an external transceiver. Do you really want us to do the timing calculations for you or tell you how to implement Manchester coding so that you don't need to google? There are even ready made parts that can send/receive Display Port  signals and encode/decode the EDID data (among other things), e.g. interfacing it to I2C. GPUs and monitors/TVs tend to use these ...

c) Stop trying to save the world from bad EDID data using your Arduino and maybe step back and think for a bit. I am not sure where are you getting the idea that when you generate some random EDID data it will be respected by Windows any better than the original EDID from your monitor?

[amyk]

I've asked if it's possible to sniff and generate a 1Mbps Manchester-II code differential stream with a ATmega32U4.

Possibly. 10M Ethernet is doable...

https://hackaday.com/2014/08/29/bit-banging-ethernet-on-an-attiny85/

[ajb]

There's a certain amount of X/Y problem to be expected on forum posts here, but the OP has pretty clearly explained what they're trying to do, and there's really no need to demand every last bit about the application to answer the technical question at hand.  Nor is there a need for everyone to get all pissy with each other about it. 

In any case, EDID management is a real issue in situations where display connections are critical in a system.  For example in the event production world, video content is huge and typically relies on media servers connected to projection and video wall systems via (at least somewhere in the chain) DP/HDMI/DVI.  Media servers tend to be off-the-shelf PC hardware, including off-the-shelf GPUs, running standard OSes, with all the potential for problems when managing displays that come with those things.  Having to shuffle your screen settings on your PC because of a cabling or other issue is annoying, having to do that on a media server during an event can literally be a show-stopper.  I know that at least one company, Avolites, builds a displayport interposer board into their media servers that provides hardware EDID management for exactly this reason.  It does exactly what the OP here has described, passing the display data through while intercepting and optionally manipulating the EDID stream to ensure that the video keeps running regardless of what is or isn't hooked up to the port.  These media servers cost something like $50-100k and the additional reliability and quality of life that EDID management provides to operators is a legitimate selling point.  They've even included the same feature on their latest lighting control consoles, because having an outboard monitor that you're relying on for real-time control crap out in the middle of a production would be A Problem.  Obviously EDID/display detection issues aren't the only thing that affects the reliability of these connections, but it is significant enough that they chose to address it by doing exactly what the OP here describes, albeit not with an arduino 

[TnF]

There's a certain amount of X/Y problem to be expected on forum posts here, but the OP has pretty clearly explained what they're trying to do, and there's really no need to demand every last bit about the application to answer the technical question at hand.  Nor is there a need for everyone to get all pissy with each other about it. 

In any case, EDID management is a real issue in situations where display connections are critical in a system.  For example in the event production world, video content is huge and typically relies on media servers connected to projection and video wall systems via (at least somewhere in the chain) DP/HDMI/DVI.  Media servers tend to be off-the-shelf PC hardware, including off-the-shelf GPUs, running standard OSes, with all the potential for problems when managing displays that come with those things.  Having to shuffle your screen settings on your PC because of a cabling or other issue is annoying, having to do that on a media server during an event can literally be a show-stopper.  I know that at least one company, Avolites, builds a displayport interposer board into their media servers that provides hardware EDID management for exactly this reason.  It does exactly what the OP here has described, passing the display data through while intercepting and optionally manipulating the EDID stream to ensure that the video keeps running regardless of what is or isn't hooked up to the port.  These media servers cost something like $50-100k and the additional reliability and quality of life that EDID management provides to operators is a legitimate selling point.  They've even included the same feature on their latest lighting control consoles, because having an outboard monitor that you're relying on for real-time control crap out in the middle of a production would be A Problem.  Obviously EDID/display detection issues aren't the only thing that affects the reliability of these connections, but it is significant enough that they chose to address it by doing exactly what the OP here describes, albeit not with an arduino 

THANK YOU!

This guy totally understands me. While i am not making any kind of commercial system like this the functionality is similar. My core question had nothing to do with the application usage and i thought i was kind to include more information.
It's like i was asking "Can a Honda Civic do a 10s drag pass?" and i was expecting an answer like "Well it can't do it even if you spend 100k in mods" or "Well it can do it with a few mods but it's necessary that you run nitrous".
I wasn't expecting to hear: "Oh which drag event are you going to?", "Are you competing for cash?", "Ohh your shittybox won't even finish the race"

Get me?

Saying it's a kind of hackbox is more than enough since that's it's the actual usage; i'm not trying to solve a specific problem and wanted suggestions of how to solve it, but wanted to know about the feasibility of the hardware.

I've asked if it's possible to sniff and generate a 1Mbps Manchester-II code differential stream with a ATmega32U4.

Possibly. 10M Ethernet is doable...

https://hackaday.com/2014/08/29/bit-banging-ethernet-on-an-attiny85/

That's crazi...ly awesome

You can use CRU utility to write any EDID you want into windows registry and bypass intel's bug. Obviously you don't know your stuff well that's why you see a square wheel. Maybe you want a pair of glasses too since you keep insisting on going out of TOPIC.

I've asked if it's possible to sniff and generate a 1Mbps Manchester-II code differential stream with a ATmega32U4.

I suggest that you:

a) Take a chill pill. Screaming your lungs out and being an arrogant jerk throwing tantrums because you aren't getting what you want right away while you are asking others to solve your ill-specified problem is not exactly an attitude that will get you answers.

b) Download the f..g datasheet and start to read? And maybe do a few ballpark calculations? And google, so that you actually understand what Manchester is?

I wrote you already that it is maybe doable but it is going to be really marginal on the ATMega at best - and most likely beyond what you are able to program anyway.

Now you have brought out a Teensy - who knows, maybe? Blackpill certainly doesn't have differential outputs but maybe it can be bitbanged, those STM32s are fast. And anyway, you can always use an external transceiver. Do you really want us to do the timing calculations for you or tell you how to implement Manchester coding so that you don't need to google? There are even ready made parts that can send/receive Display Port  signals and encode/decode the EDID data (among other things), e.g. interfacing it to I2C. GPUs and monitors/TVs tend to use these ...

c) Stop trying to save the world from bad EDID data using your Arduino and maybe step back and think for a bit. I am not sure where are you getting the idea that when you generate some random EDID data it will be respected by Windows any better than the original EDID from your monitor?

a) I only take red pills and black pills. Don't know of any chill pills.

b) Started reading before you told me, but i don't call myself an expert, especially when it's not my profession..otherwise i wouldn't be writing here

The rest you wrote is clearly the answer i wanted all along, thank you. Teensy 3.2 should definitely not have issues in terms of processing speed but i might as well throw a Teensy 4.0 in there since they are the same price.

c) Where did i said the data generated is random?! of course not. If only EDID data would be bad the world would be a better place..however there are problems EVERY. SINGLE. STEP of the way

I know nothing, but if I was playing with the DisplayPort AUX channel, I'd use something like an SN65LVDS049 or SN65LVDS050 differential LVDS transceiver here, and have the microcontroller operate at 3.3V.

This will definitely be needed!! Thank you a lot!

Holy giant font Batman, is that really necessary?

[AnONeamus]

Necro-ing this thread as it's the only result that comes up for searching DP-AUX emulators on the 'net. 

There are none (outside of expensive lab equipment), and unless the OP actually made one, there's no one that's (publicly) made one either. So, I made my own, using RP2040 and 2x SN65MLVD200ADR. It works, gets the job done and life goes on.

Ask questions other than "why?" if you like.

[wpunkts]

Hi, I very much like to ask a question: would you share more details about your build? This might just solve a huge problem we are having, and if it doesn't, it will solve some fresh new problem that will certainly show up sometime in the future.

Thanks, Wolfgang

[TnF]

Necro-ing this thread as it's the only result that comes up for searching DP-AUX emulators on the 'net. 

There are none (outside of expensive lab equipment), and unless the OP actually made one, there's no one that's (publicly) made one either. So, I made my own, using RP2040 and 2x SN65MLVD200ADR. It works, gets the job done and life goes on.

Ask questions other than "why?" if you like.

Hi, I very much like to ask a question: would you share more details about your build? This might just solve a huge problem we are having, and if it doesn't, it will solve some fresh new problem that will certainly show up sometime in the future.

Thanks, Wolfgang

Well, i have the simple version up and running for 2 years? now which controls HPD only, it does the job that i want it to do, except when the monitors are turned off and you reboot the PC, the GPU won't be able to detect the displays since no EDID information is present. This is the only downside (usually when i am remotely connecting to the PC when i am away from home a long time); there are some workarounds with software emulated displays but not ideal.

The EDID version is still sitting there with the prototype pcb's and all the components needed, still on my desk for sometime when i finally finish some other long standing projects of mine, i have all that i need to do on my mind, just not the time to spend on it yet. If i get to it, i think i can get it working in a week. Sorry i don't have it ready yet.

@AnONeamus great that you've managed to do it, you should make a thread about it. Mine is using some SN65MLVD transceiver but i was planning on using some Teensy's i have laying around. RP2040 is a better choice now, much cheaper and bigger opensource info, i should order some;p