EDID fuzzer, EDID sniffer & Monitor/TV screen i2c addr scanner :) #2777
Replies: 6 comments
-
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-09-18 by @gfwilliams Wow, nice idea! I'd say definitely go for Serial between Espruino and the Arduino - it's nice and easy to wire up, and to debug with a USB-TTL converter. To be honest even the I2C reader & decoder on something like Pixl.js would be a great debug tool - you could plug it into any HDMI device and see what it was capable of. I should really add I2C and SPI slave support to Espruino - the issue really has been how to handle it when the JS takes so long to execute. It could just be a bunch of registers since that's what most I2C devices seem to do - but anyway, that's sidetracking the thread - I guess it should be a GitHub issue. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-09-24 by stephaneAG Hi there ! thanks ;) It indeed seems that Arduino <-serial->Espruino is the quickest & handy path to choose As I get enough time to do so, I'll update the reader/decoder part & start building a lib from those ( nb: it 'd require a whole lot of work additionally to the current one to get all the infos for a particular monitor, though ) As I currently don't own a Pixl.js ( I'd be more interested in a MDBT42Q breakout ;p ), I'll just pack the interesting bits & give that away in the forums ( or try building a canvas pixl.js screen emulator ? ) On the I2C & SPI slave subject, it 'd be really awesome to have, as this is one of the reason I still need to keep an Arduino closeby when messing with stuff ( on a side note, I currently face somewhat close ends as I'm trying to use a custom usb device descriptor different that a HID one ( that's why I'm using a Teensy for now to do the USB talk ;p ). |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-09-24 by @gfwilliams
The Pixl just offers a global variable called
Do you think having the slave implemented as a bunch of registers would actually work in this case? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-09-25 by stephaneAG allright, I'll try to find a screen or make use of that ;) on the i2c subject, did you have something like this in mind http://amitesh-singh.github.io/stm32/2018/01/07/making-i2c-slave-using-stm32f103.html ? I honestly don't have enough skills to tell you if it'd work ( but a huge part of me thinks why not considering my quick & ugly arduino code worked ? ) I also wonder if it' be useful to have a callback called once data has been accessed ? ( or if it would just slow down the entire process .. ) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-10-03 by @gfwilliams For I2C, yes - that's pretty much the idea. The API used in the example looks different to the one I use (eg https://github.com/espruino/Espruino/blob/ab227f54ad5585d5ceaa7cfd6b54634ee0dc609d/targets/stm32/jshardware.c#L2338) but it's the same idea (also I'd have to make sure the code for I2C master still worked :). Having said that, if you're doing it for yourself then yeah, just try it and see :) You could have a callback for a read - the only issue is if you waited for the response. I think a lot of devices wouldn't be willing to wait for long enough so you'd really need to at least offer a solution that just pushed the data ASAP. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-09-14 by stephaneAG
Hi everyone !
I interested in messing with a VGA/HDMI/.. connector & the data exchanged between a device connected to it, read on ! ;p
As a reminder, EDID looks like that:
For a current project, I need to:
The goal is more or less an "HDMI DDC EDID MitM" ( we can change a lot of infos found in the original EDID )^^
Along with the above, it should also act as a "fast hdmi switcher", doing EDID handling & messing with hotplug pins ( since EDID is no longer re-read from the monitor when it's switching to a particular source, but instead read once, when the device connecting to the monitor does so in the background )
my current prototype consists of:
The Espruino listens for a pin rising ( the monitor's hdmi connector's hotplug pin ) before acting as an i2c master to then write & read data a monitor's ( fixed ) i2c adress 0X50.
The Arduino simulates a 'source' device connection by toggling its hdmi connector's hotplug pin before acting as an i2c slave with address 0x50 & provides EDID data whenever being requested to over i2c.
I am currently wondering what'd be the simplest & most robust way to communicate between the Espruino & the Arduino ( knowing that having a 3IN<->1OUT hdmi switch, I plan to use 2 more Arduinos, one for each hdmi IN ).
Every Arduino has only one hdmi device's i2c pins connected to it, and the Espruino is also using different i2c pins to communicate with the screen.
I hesitate between SPI & serial, and the only limitation ( at least those I see for now .. ) is using a pin for each on the Espruino & using a watch to listen for an Arduino's request of the ( modded ) monitor's EDID ( store within the Espruino's program & refreshed on boot ).
Moreover, we have limited memory on both the Espruino & the Arduino & although I did get away with modding the Arduino's "Wire" ( i2c ) lib, it seemed I couldn't get more than 256 bytes out of it at once ( and I couldn't figure out if this was coming from the Espruino side ? .. ) & while increasing the buffer seemed to free memory Arduino-side, I still can't get more than ~253 bytes when reading from an i2c address using Espruino ( I still have to run tests using an Arduino as i2c master to better identify the source of the trouble ).
To bypass this current limitation, I re-wrote the Arduino code to act more like my laptop ( & surely other 'source' devices ) does ( writing a byte to select the portion to be read from i2c, then reading max 128 bytes of data ).
As the EDID is 128 bytes big & so does the Extended one, writing 0x00 then reading 128 bytes gives to EDID, and writing 0x80 then reading 128 bytes gives to Extended data.
Also, writing a byte < 256 & then reading a number of bytes gives the n bytes starting from the previously written one ( seems to be the common way for i2c memory chips ? .. ).
This being said, it seems reading 128 bytes again & again without writing any returns the EDID or the Extended One alternatively in a cycle
I mostly replicated this behavior ( although I have to fix the code handling switching between sending alternatively each & sending only 128 bytes from a previously received one on the Arduino-side - which works but is still not working wip since it doesn't handle cycling without receiving a byte beforehand for now .. and yet it's not-that-bad-enough to work ;) )
Once the above was nearly ok, I decided to try scanning the available i2c devices in the monitor, but sadly none of the i2c scanners I found for Espruino worked :/ ..
.. so I modified a little bit the EDID sniffing code to instead trigger an i2c scan right after sensing a rise on the monitor's hotplog pin & it seems to work, albeit very slow for now
I'll try to mod an existing i2c scanner to do the work faster & give a prettier output, but part of my other code seems needed, at least for my monitor ( compared to other i2c devices I guess ? .. )
Code provided below is for:
Beta Was this translation helpful? Give feedback.
All reactions