*** tpb has joined #timvideos | 00:00 | |
*** Bertl_oO is now known as Bertl_zZ | 03:55 | |
mithro | CarlFK: The VGA board is mainly designed for VGA in rather then VGA in + VGA out | 04:49 |
---|---|---|
CarlFK | mithro: shucks | 04:49 |
CarlFK | but I can work around it. | 04:50 |
mithro | Not enough spare pins I'm afraid | 04:53 |
mithro | btw I'll be spending next week working on the HDMI2USB firmware full time in preparation for the Opsis | 04:58 |
mithro | ysionneau: ping? | 05:41 |
*** jamesh has quit IRC | 05:56 | |
*** se6astian has joined #timvideos | 07:52 | |
ysionneau | pong! | 10:15 |
ysionneau | mithro | 10:15 |
mithro | ysionneau: heyo! Did you get to the bottom of what is going on with the I2C stuff? | 10:16 |
ysionneau | hi! I'm still in London (was in 0xford yesterday) and I didn't get the time to work again on it | 10:16 |
mithro | ysionneau: No worries | 10:16 |
ysionneau | I'm wondering what's your deadline for this | 10:16 |
mithro | ysionneau: I'll be spending the time period from the 14th till 22nd working full time on building a production Opsis firmware (taking time off from work) | 10:17 |
ysionneau | Ok, for this week (starting tuesday) I don't have anything planned, so I will be available to work | 10:18 |
mithro | CarlFK / tumbleweed: BTW That includes making it so that the Opsis boots up with the firmware without having to flash | 10:18 |
ysionneau | so I will most likely update you on Tuesday about the stuff we talked about | 10:18 |
mithro | ysionneau: Your modified EDID part is a fallback option regarding getting booting working | 10:19 |
ysionneau | ok | 10:19 |
mithro | ysionneau: I also need to figure out a communication method between the Opsis and FX2 for transferring things like resolution settings | 10:19 |
ysionneau | because this needs to be in the USB descriptor? | 10:20 |
ysionneau | or something? | 10:20 |
mithro | ysionneau: I have 3 pins to work with on the Atlys<->FX2, have a lot more on the Opsis<->FX2 | 10:20 |
mithro | ysionneau: yeah | 10:20 |
ysionneau | 3 pins, can do something like SPI or I2C | 10:21 |
mithro | ysionneau: Yeah - but it'll have to be bitbanged :) | 10:21 |
ysionneau | \o/ | 10:21 |
mithro | ysionneau: The FX2 is pretty slow | 10:21 |
mithro | about ~12MHz | 10:21 |
ysionneau | ok | 10:21 |
ysionneau | so it'll be best if the FX2 is the master of such a communication then? | 10:22 |
ysionneau | it'll be bitbang on both sides? fx2 pins are regular gpios? | 10:22 |
mithro | I can do roughly ~500kHz bit banging if doing nothing else | 10:22 |
ysionneau | ok | 10:23 |
mithro | the FX2 has a bunch of interrupts it needs to service, so I think it'll need to be the master | 10:23 |
mithro | this is separate from the I2C bus used for the firmware loading | 10:23 |
mithro | The big problem is the Atlys board | 10:23 |
mithro | On the Opsis I can use the I2C hardware, the hardware UARTs or an ~12 GPIO pins | 10:24 |
ysionneau | yes ok so it'll need to be soem bitbanged protocole with fx2 as master for the Atlys board then | 10:25 |
ysionneau | some* | 10:25 |
mithro | yeah | 10:25 |
ysionneau | still have "plenty" of code space for the fx2? | 10:25 |
seaLne | mithro: should the i2c bus for the ad9984 be seperate from the eeprom? the eeprom on the vmod is on the same bus | 10:25 |
mithro | not a huge amount, but definately few 4-5kb | 10:26 |
mithro | seaLne: nah, they can be the same as they are on different addresses | 10:26 |
mithro | seaLne: but make sure they are :) | 10:26 |
mithro | ysionneau: I already have some highly optimised bitbanging code for doing JTAG programming using the FX2 | 10:26 |
ysionneau | hehe ok | 10:27 |
mithro | ysionneau: another option is the trying to use the USB FIFO buffers to transfer data | 10:27 |
seaLne | mithro: ok and yep. just wondered from an architecture point of view of tofe | 10:27 |
ysionneau | mithro: hmm ok I don't know much about that | 10:27 |
mithro | ysionneau: I think it could work, but haven't had a chance to test it yet | 10:28 |
ysionneau | those buffers can be used for something else than USB? | 10:28 |
mithro | ysionneau: I can effectively "veto" the buffers going to/from the USB bus | 10:28 |
mithro | It's unclear if I can totally generate a buffer though | 10:28 |
mithro | ysionneau: We use sdcc for compiling the fx2 code | 10:29 |
ysionneau | it does not seem to be in the default ubuntu repositories but I guess it's easy to install | 10:30 |
ysionneau | ? | 10:30 |
mithro | ysionneau: apt-get install sdcc | 10:30 |
mithro | ysionneau: we also have a newer version in conda | 10:30 |
mithro | ysionneau: It kinds of feels like there should be a kind of generic "i2c library" that we could share between the fx2/lm32/etc | 10:31 |
ysionneau | that would make sense yes | 10:31 |
mithro | I'm kind of surprised something like that does already exist | 10:31 |
ysionneau | Linux kernel has an i2c bitbanged driver | 10:31 |
ysionneau | but don't know if it's easy to strip all the kernel specific calls | 10:32 |
mithro | ysionneau: Thinking at the levels, first we have the low level "I2C UART" bits - which is either bitbanging or hardware assisted | 10:33 |
ysionneau | I think it's this one http://lxr.free-electrons.com/source/drivers/i2c/algos/i2c-algo-bit.c | 10:34 |
tpb | Title: Linux/drivers/i2c/algos/i2c-algo-bit.c - Linux Cross Reference - Free Electrons (at lxr.free-electrons.com) | 10:34 |
mithro | ysionneau: the next level above that is kind of the protocol level, IE what to based on i2c bytes (IE only respond to things matching your address, etc) | 10:34 |
ysionneau | yes | 10:34 |
mithro | ysionneau: then the next level up is the high level "eeprom reading protocol" and "ad9984 protocol" etc | 10:34 |
mithro | I wondered if we could steal anything from sigrok - http://sigrok.org/wiki/Protocol_decoders | 10:38 |
tpb | Title: Protocol decoders - sigrok (at sigrok.org) | 10:38 |
ysionneau | from a decoder, hmm | 10:44 |
mithro | ysionneau: anyway - I just wanted to mentioned where I was at | 10:55 |
ysionneau | ok, good to know! | 10:57 |
mithro | Bertl_zZ: could you generate me a BOMs (parts list) for the HDMI adapter, 3 x PMOD and PMOD test thingy? I don't have Eagle to open the schematic and I couldn't find PDFs for them at http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ ? | 10:58 |
tpb | Title: Index of /Stuff/AXIOM/BETA (at vserver.13thfloor.at) | 10:58 |
ysionneau | have to go for lunch, see you! | 11:02 |
mithro | ysionneau: It would be good to know what is happening regarding the lm32 gpio bitbanging by Friday | 11:04 |
ysionneau | should be good | 11:06 |
*** Bertl_zZ is now known as Bertl | 11:21 | |
seaLne | mithro: if the ad8944 uses the same i2c bus as the tofe eeprom won't then the tofe-vga and vmod-vga be incompatible as it uses IO20 for the i2c? | 11:29 |
seaLne | which on the tofe is B33 and B34 | 11:30 |
mithro | seaLne: just a very small software change | 11:30 |
mithro | seaLne: but there might be no reason to change it | 11:30 |
mithro | seaLne: you using https://docs.google.com/spreadsheets/d/15rivtOcSG4kqKf0AUK_OwBfs67XQtW8byr8kc5FUTgE/edit#gid=574892795 ? | 11:30 |
tpb | Title: Tims Open FPGA Expansion (TOFE) board connector interface - Google Sheets (at docs.google.com) | 11:30 |
seaLne | yes | 11:31 |
mithro | seaLne: ahh cool | 11:31 |
seaLne | just keeping it the same seems like the easiest solution? | 11:31 |
Bertl | mithro: http://pastebin.com/raw.php?i=SzxJEqbU | 11:51 |
mithro | seaLne: sgtm | 11:51 |
Bertl | I'll see what I can do for the triple PMOD and PMOD debug | 11:51 |
Bertl | (will take a little though) | 11:52 |
mithro | Bertl: just need a part list, not a farnell order number stuff | 12:14 |
Bertl | http://pastebin.com/raw.php?i=rBTwgu1i (3xPMOD) | 12:31 |
mithro | Bertl: I don't quite understand what I should be looking for regarding the 2.54mm socket strip? It seems to be surface mounted in some way? | 12:34 |
mithro | Everything else looks good | 12:35 |
Bertl | http://pastebin.com/raw.php?i=1vkD7cp7 | 12:35 |
Bertl | it is just stuck to the PCB and soldered on both sides | 12:36 |
Bertl | i.e. you get a normal header or socket strip with 2x6 pins/holes | 12:36 |
Bertl | then stick it on the PCB edge, align it and solder it | 12:37 |
Bertl | se6astian: do we have a close up of the PMOD debug module somewhere? google doesn't find anything | 12:39 |
Bertl | se6astian: same for the triple PMOD | 12:39 |
se6astian | do you mean this: https://apertus.org/pmod-debug ? | 12:49 |
tpb | Title: PMOD Debug Board | apertusĀ° - open source cinema (at apertus.org) | 12:49 |
mithro | Bertl: ahh I understand | 12:50 |
mithro | Bertl: that is the same for the 3xPMOD stuff | 12:51 |
Bertl | se6astian: well, I was hoping for a close up picture | 12:51 |
Bertl | it seems we do not have any of either | 12:51 |
seaLne | mithro: i think keeping the same pinout between the vmod and tofe vga may not be possible as on the tofe the RGB buses from the ad9984 would be criss-crossing all over the place making length matching a bit of a nightmare. the pins seemed to have been picked on the vmod as they were next to each other | 12:52 |
Bertl | mithro: yes, triple PMOD is the same just the opposite gender | 12:52 |
mithro | Bertl: okay great | 12:52 |
mithro | Bertl: I just realised they aren't that much use without something to connect to them :P | 12:53 |
mithro | seaLne: yes, feel free to swap LVDS pairs as needed | 12:53 |
mithro | My brain always reads MURATA as 'MURRICA | 12:54 |
Bertl | mithro: that's what the PMOD debug module is for, i.e. you can plug in all three of them into the triple PMOD dual slot plugin | 12:55 |
Bertl | (which in turn plugs into the mithro special TOFE-AXIOM adapter :) | 12:55 |
mithro | Bertl: yeah, but I need to finish that adapter first :) | 12:55 |
mithro | Bertl: the reason I was thinking about parts is I need to order the mDP connectors to test your theory about only fitting 3 of them on a board | 12:56 |
mithro | Bertl: If we can somehow fit 4, we end up with a nice feature that you can use 2 for a single width board | 12:56 |
Bertl | yep, but won't work | 12:57 |
mithro | Bertl: so you could do a HDMI connector and a "half size link" | 12:57 |
mithro | Bertl: I assume everything need to be facing "upwards", IE we can't have things facing off to the sides? | 12:58 |
Bertl | https://www.apertus.org/sites/default/files/PCB-Stack-Concept-V03-022b-transp.png | 13:00 |
Bertl | so in theory, you can have something stick out to the (out)side as well, but that's not how it is designed | 13:00 |
mithro | we are also 1 pin short with 3xmDP :/ | 13:03 |
Bertl | how so? | 13:04 |
Bertl | or you mean, we have one spare low speed I/O? if so, then yes, we can leave that one unused or attach an LED | 13:05 |
mithro | Bertl: with 3xDP we can't connect one low speed I/O from TOFE<->AXIOM | 13:14 |
Bertl | because the TOFE has only 2 DP with "low speed" connections, I know | 13:14 |
Bertl | but I wouldn't worry too much about that | 13:15 |
seaLne | mithro: on the opsis is it only individual pairs that are length matched to the tofe connector? the ad9984 doesn't use pairs it has 3x 10 signals so i'm not sure how much use length matching on the vga board will be if they aren't then between the connector and fpga on the opsis? | 13:26 |
mithro | seaLne: yes, they are all length matched IIRC | 13:26 |
mithro | seaLne: but pairs are length matched and routed as a couple | 13:27 |
seaLne | so between pairs they won't be the same lenght? | 13:27 |
mithro | seaLne: they should be | 13:27 |
mithro | seaLne: just tighter tolerances for matching a pair rather than the whole group | 13:27 |
seaLne | mithro: ok, thanks | 13:28 |
mithro | seaLne: we can also delay tune the IO in the FPGA if we can get the ad9984 to produce a known bit pattern | 13:28 |
seaLne | thanks just trying to sort this out in my head | 13:30 |
mithro | seaLne: I think we could basically fix almost any issue in the FPGA if you had the connections working - but some take more effort then others | 13:31 |
mithro | Bertl: the latest thoughts are in the TOFE spreadsheet - I was hoping to figure out a way to do the 3xmDP for AXIOM in a way that the 4xmDP would still make sense for TOFE<->TOFE but don't see a way to make that'll end up working | 13:42 |
mithro | anyway bed time for me! | 13:42 |
mithro | gnight! | 13:42 |
Bertl | seaLne: at 170MHz, the wavelength is about 1.5 meter (~60 inch), so the pair length is not _that_ critical :) | 13:48 |
Bertl | mithro: no worries, just handle the TOFE-TOFE and we'll be fine | 13:49 |
Bertl | mithro: and sleep well | 13:49 |
seaLne | Bertl: good point :) | 13:53 |
Bertl | what I would avoid though is having different clock domains on the same pair, as the crosstalk will be significant on an impedance controlled pair | 14:03 |
seaLne | Bertl: will the RGB (10bit) not all be sent out at the same time? or were you more meaning don't share with the other things? | 14:12 |
Bertl | yes, all the AD9984 outputs will probably be synchronous | 14:13 |
Bertl | but don't mix them with "other" clock or data lanes on the same pair | 14:15 |
seaLne | yep, thanks | 14:15 |
Bertl | np | 14:15 |
seaLne | do i need to worry about where on the fpga the pairs go to? | 14:16 |
Bertl | probably not, but if you want to play it extra safe, I'd put them in direct vicinity (i.e. on the same bank(s)) | 14:47 |
CarlFK | left my atlys runing over night. I have fuzzy line on top of the test pattern | 15:20 |
*** CarlFK has quit IRC | 15:33 | |
*** CarlFK has joined #timvideos | 15:34 | |
*** ChanServ sets mode: +v CarlFK | 15:34 | |
seaLne | that doesn't sound good | 15:42 |
Bertl | GTX tranceivers or normal output? | 15:44 |
Bertl | (might be a problem with the timing closure under higher temperature) | 15:44 |
Bertl | anyway, off for a nap ... bbl | 15:44 |
*** Bertl is now known as Bertl_zZ | 15:44 | |
CarlFK | seaLne: bringing up a console now... | 15:52 |
CarlFK | seaLne: hmm.. something odd is going on... | 15:54 |
CarlFK | [FLTERM] Starting... | 15:54 |
CarlFK | DIUB | 15:54 |
CarlFK | it's like there is still a connection somewhere... | 15:54 |
CarlFK | oh right, there is :) | 15:55 |
seaLne | i guess things to test: does switching encoder on/off fix it. does power cycling fix it. does leaving it to cool down fix it? | 15:57 |
CarlFK | output0: 1280x720@60Hz from pattern | 15:58 |
CarlFK | I started it about 9 hours ago, observed it for maybe 10 min and went to bed | 15:59 |
CarlFK | woke up, see fuzzy line. which I have seen before, it is very distinctive, ... um.. know what I mean? | 16:00 |
seaLne | hang over? :) | 16:01 |
CarlFK | lol | 16:01 |
CarlFK | I mean the line that shows up now and then | 16:02 |
CarlFK | it runs down the middle of the white bar of the pattern | 16:02 |
CarlFK | seaLne: ^^^ have you seen that before? | 16:11 |
seaLne | CarlFK: nope sorry, not seen the atlys in use | 16:12 |
CarlFK | seaLne: I would think it is a firmware thing, not hardware | 16:13 |
CarlFK | but im not sure what you have or do | 16:13 |
seaLne | my first 2 suggestions to test would probably point at firmware if they fix it. if it needs to cool down or never works again would suggest overheating. these are just some guesses i'm sure there are others with much more knowledge | 16:15 |
seaLne | could also be problems with the uvc driver on the pc? | 16:16 |
seaLne | so possibly the first test could be unplugging the usb cables? | 16:17 |
CarlFK | it is showing up on the hdmi display | 16:18 |
CarlFK | output0: 1280x720@60Hz from pattern | 16:18 |
seaLne | well ruled one thing out now | 16:19 |
CarlFK | I have seen it on a black screen when there is no hdmi on the source, like if nothing was hooked up to input0, and output0: 1280x720@60Hz from inpurt0 | 16:20 |
CarlFK | the explanation was "nothing is writing to the ram, so it is whatever data happens to be in ram" | 16:20 |
*** se6astian is now known as se6astian|away | 16:23 | |
*** Bertl_zZ is now known as Bertl | 17:41 | |
*** se6astian|away is now known as se6astian | 17:50 | |
*** se6astian is now known as se6astian|away | 23:08 | |
*** CarlFK has quit IRC | 23:35 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!