| *** tpb has joined #timvideos | 00:00 | |
| Bertl_oO | they are also using a zynq based system and the cameras are FOSS/OH | 00:00 |
|---|---|---|
| mithro | Bertl_oO: I think last time I looked at them, the price and performance didn't really stand up to commercial alternatives and the project kind of looked dead? | 00:01 |
| Bertl_oO | nah, andrey is quite active and they recently finished the design for the new nc393 camera | 00:01 |
| mithro | But I didn't look too closely | 00:01 |
| Bertl_oO | I cannot judge the price but FOSS/OH often has a higher price because of lower volumes | 00:02 |
| Bertl_oO | the advantage is that you have the freedom to do what you want :) | 00:03 |
| Bertl_oO | http://blog.elphel.com/category/model-393/ (here some updates) | 00:03 |
| mithro | _florent_: have you see https://github.com/Elphel/gtxe2_gpl before? | 00:08 |
| tpb | Title: Elphel/gtxe2_gpl · GitHub (at github.com) | 00:08 |
| mithro | Bertl_oO: at some point we are all going to have to get together and write a WebM encoder | 00:14 |
| Bertl_oO | you mean VP8/VP9? | 00:21 |
| mithro | Bertl_oO: yes I do | 00:21 |
| Bertl_oO | yeah, might be interesting at some point | 00:23 |
| mithro | xfxf / CarlFK: https://github.com/timvideos/HDMI2USB/wiki/Cameras | 00:26 |
| tpb | Title: Cameras · timvideos/HDMI2USB Wiki · GitHub (at github.com) | 00:26 |
| *** CarlFK has quit IRC | 01:29 | |
| mithro | https://docs.google.com/drawings/d/10EcVibQ5kgFalb5jBtNVIvFMmhcDTTXMb-WPmijWkrg/edit | 02:12 |
| tpb | Title: Options - Google Drawings (at docs.google.com) | 02:12 |
| *** Bertl_oO is now known as Bertl_zZ | 02:18 | |
| *** CarlFK has joined #timvideos | 04:53 | |
| *** ChanServ sets mode: +v CarlFK | 04:53 | |
| mithro | CarlFK: https://docs.google.com/drawings/d/10EcVibQ5kgFalb5jBtNVIvFMmhcDTTXMb-WPmijWkrg/edit | 06:04 |
| tpb | Title: Options - Google Drawings (at docs.google.com) | 06:04 |
| CarlFK | mithro: lol @ venue equipment | 06:13 |
| CarlFK | did you see vocto was used just in production ? | 06:14 |
| CarlFK | http://youtu.be/l3glAcoW5OM (not vocto. recorded to raw files, veyepar made the .mlt cutlist, including the pic-in-pic. ... and see a bug in the encoder | 06:19 |
| mithro | what is going on in that video when the PIP is up? | 06:21 |
| mithro | There is a kind of solarised component store | 06:22 |
| mithro | CarlFK: yes - I did hear that had happened | 06:22 |
| mithro | CarlFK: I'm interesting to hear how MaZderMind thinks it went | 06:22 |
| mithro | CarlFK: sadly, I can't read the German discussion :P | 06:23 |
| CarlFK | mithro: what is going on is a bug/artifact in the encoder | 06:23 |
| CarlFK | if you look in the background of the PIP, you will see the "stuff" that is somehow glowing | 06:24 |
| mithro | CarlFK: I've wondered if we should just capture the raw files using a gstreamer pipeline and then mux them together side-by-side using veyepar mlt | 06:24 |
| CarlFK | 4:3 pres, so I moved it over to the left, and the area that opened up.. found some data to fill in? :D | 06:24 |
| mithro | CarlFK: was that a HDMI2USB capture? | 06:25 |
| CarlFK | yep | 06:25 |
| mithro | CarlFK: there are some weird artifacts on some of the text edges which we should investigate | 06:25 |
| mithro | CarlFK: actually there are quite a few weird artifacts which can be seen if you turn on 720p mode | 06:26 |
| mithro | CarlFK: was your Atlys overheating? | 06:26 |
| CarlFK | mithro: um.. heck if I know :) | 06:26 |
| mithro | CarlFK: can you send me the raw video you captured from the hdmi2usb? | 06:27 |
| CarlFK | sure | 06:27 |
| mithro | CarlFK: I think to figure out what is going on with your video, we will need https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/130 | 06:27 |
| tpb | Title: Calculate CRC code on pixels during frame transfer · Issue #130 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 06:27 |
| CarlFK | mithro: 400mb... 16% | 06:38 |
| mithro | CarlFK: oh that is the upload progress | 06:39 |
| CarlFK | mithro: yes | 06:39 |
| CarlFK | Upload: 22% ||||||||| | Time: 0:04:51 376.13 kB/s | 06:39 |
| CarlFK | look familiar :) | 06:39 |
| mithro | CarlFK: I have a feeling I wrote something for you around that? | 06:41 |
| CarlFK | that's the patched file.read or something like that progress bar | 06:42 |
| mithro | ha yeah | 06:43 |
| CarlFK | mithro: http://5cda49ca88af98bf1f1e-b4c3b47b38bb1b572e0805ecabeeb59c.r76.cf2.rackcdn.com/21_06_36.mkv | 07:20 |
| CarlFK | 65k http://5cda49ca88af98bf1f1e-b4c3b47b38bb1b572e0805ecabeeb59c.r76.cf2.rackcdn.com/20_42_44.mkv | 07:24 |
| *** se6astian|away is now known as se6astian | 08:07 | |
| xfxf | CarlFK: oh wow, vocto works? | 08:17 |
| xfxf | holy shit that's awesome, well done | 08:18 |
| xfxf | vid obv isn't perfect but man, that's a huge step forward | 08:18 |
| xfxf | CarlFK: what camera are you using? | 08:19 |
| *** CarlFK has quit IRC | 08:20 | |
| mithro | xfxf: that video isn't from voctomix from what I understand | 08:27 |
| xfxf | oh | 08:27 |
| xfxf | is that a veyepar job? | 08:27 |
| mithro | xfxf: yes | 08:28 |
| mithro | 5:17 PM <+CarlFK> http://youtu.be/l3glAcoW5OM (not vocto. recorded to raw files, veyepar made the .mlt cutlist, including the pic-in-pic. ... and see a bug in the encoder | 08:28 |
| *** CarlFK has joined #timvideos | 08:35 | |
| *** ChanServ sets mode: +v CarlFK | 08:35 | |
| _florent_ | CarlFK: can you give the revision of the firmware you used for the video with artifacts? | 08:53 |
| CarlFK | _florent_: it is what is in testing :) | 08:53 |
| CarlFK | no clue how easy it will be to trace that to what you need | 08:54 |
| CarlFK | the machines are all packed right now and I need to get to bed | 08:54 |
| mithro | CarlFK: I can get you that | 09:04 |
| mithro | _florent_: I can get you that | 09:04 |
| mithro | _florent_: be back in an hour | 09:04 |
| ysionneau | mithro ping! | 10:08 |
| mithro | ysionneau: pong? | 10:08 |
| ysionneau | mithro: does the new code seems more flexible to you? | 10:10 |
| ysionneau | the C code makes sense? | 10:10 |
| mithro | ysionneau: I haven't yet had a chance to look at it on anything apart from my phone | 10:14 |
| mithro | ysionneau: which isn't the greatest for understanding what is going on :P | 10:14 |
| ysionneau | ahah ok no pb | 10:14 |
| ysionneau | I need to refactor a bit anyway, to add some higher level layer | 10:15 |
| mithro | _florent_: https://github.com/timvideos/HDMI2USB-firmware-prebuilt/blob/master/atlys/firmware/testing | 10:16 |
| tpb | Title: HDMI2USB-firmware-prebuilt/testing at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at github.com) | 10:16 |
| mithro | _florent_: git revision v0.0.0-453-g4f2aac2 | 10:16 |
| seaLne | mithro: the problem i found when having a look for cameras was the lack of 720p | 10:17 |
| mithro | seaLne: _florent_ refactored the code so we can enable 1080p30 now | 10:18 |
| mithro | seaLne: Did you see https://github.com/timvideos/HDMI2USB/wiki/Cameras ? | 10:19 |
| tpb | Title: Cameras · timvideos/HDMI2USB Wiki · GitHub (at github.com) | 10:19 |
| seaLne | i was just reading backlog | 10:19 |
| mithro | seaLne: ahh cool | 10:20 |
| seaLne | been looking at what was available on ebay the last few weeks | 10:20 |
| mithro | seaLne: please do add things there if you find interesting stuff | 10:21 |
| _florent_ | mithro: OK thanks, it seems the changes I did on the buffer before the encoder are not yet ready to be used in production | 10:28 |
| mithro | _florent_: I think I've seen this before your changes | 10:29 |
| _florent_ | what? the artifacts or the issues with colors? | 10:30 |
| mithro | _florent_: no the white lines and pixel offsets | 10:30 |
| _florent_ | OK | 10:30 |
| _florent_ | I'll try to look at that soon | 10:31 |
| mithro | http://5cda49ca88af98bf1f1e-b4c3b47b38bb1b572e0805ecabeeb59c.r76.cf2.rackcdn.com/20_42_44.mkv | 10:31 |
| mithro | opps | 10:31 |
| mithro | _florent_: https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/134 | 10:31 |
| mithro | I think I see some similar artifacts in my recording at https://www.youtube.com/watch?v=Bxkz6XSiB3Y | 10:32 |
| _florent_ | thanks, this seems really related to my last changes | 10:33 |
| mithro | _florent_: but it is hard to tell with the h264 encoding that hangouts did | 10:33 |
| _florent_ | I think I should revert my changes for now (or you should use an older version) | 10:34 |
| _florent_ | the artifacts we see in CarlFK video are clearly related to my last changes | 10:34 |
| mithro | possible artifact in SyPy video https://usercontent.irccloud-cdn.com/file/L9QbzXiF/sypy1 | 10:34 |
| _florent_ | ah yes, that's similar | 10:35 |
| mithro | _florent_: that is *well* before your FIFO change | 10:35 |
| mithro | _florent_: those issues look more like issues in the HDMI sampler then the JPEG encoder? | 10:36 |
| mithro | Here is another one from the SyPy video -> https://usercontent.irccloud-cdn.com/file/0ggDsY1K/sypy2 | 10:37 |
| _florent_ | ok interesting | 10:37 |
| _florent_ | can you also log these captures in the issue? | 10:37 |
| mithro | _florent_: done! | 10:39 |
| mithro | _florent_: they do look like pixels "slipping" to me - but I might just be jumping to conclusions | 10:40 |
| _florent_ | mithro: thanks, I will investigate on that | 10:46 |
| *** Bertl_zZ is now known as Bertl | 11:38 | |
| ysionneau | mithro: some documentation https://github.com/fallen/i2cslave/blob/shift_register_complex/documentation.md | 12:55 |
| tpb | Title: i2cslave/documentation.md at shift_register_complex · fallen/i2cslave · GitHub (at github.com) | 12:55 |
| ysionneau | some pics of the setup https://framapic.org/CNPw3MEcGYfU/1QqdA19V https://framapic.org/YMi15nSL9jua/pRpbxl6L https://framapic.org/SaWVXNn3bMsq/cG4nXtSV https://framapic.org/MWGtbRL8uWW3/YNQzopNm https://framapic.org/ZicmiBRoBCuf/pgy5Xh0D | 13:02 |
| mithro | ysionneau: Did you mean to write up this documentation on the shift register when I was after this for the GPIO delay experiments? | 13:03 |
| ysionneau | nop I still have in my head to write the doc for the gpio delay stuff | 13:04 |
| ysionneau | but I felt also like to write this one | 13:04 |
| mithro | Okay | 13:05 |
| ysionneau | I'll do that now | 13:05 |
| mithro | I feel like this is written from the wrong side? | 13:05 |
| ysionneau | what do you mean? | 13:05 |
| mithro | It's written from the person accessing the emulated device, rather then the person doing the emulation? | 13:05 |
| ysionneau | ah, the narration | 13:06 |
| ysionneau | maybe yes | 13:06 |
| ysionneau | I'll add a small paragraph to explain the main.c then | 13:06 |
| ysionneau | but there are some explanations in the documentation already for it | 13:06 |
| mithro | I don't quite understand what is going on in main.c | 13:08 |
| ysionneau | basically I'm polling for something to happen on the I2C bus, when there's a read the shift reg becomes "empty" and I see it with a status flag, I can then refill the shift reg | 13:09 |
| ysionneau | when there's a write, the shift reg becomes "full" so I also detect that, and I can then do some protocol business (i.e. update the "addr" variable) | 13:10 |
| ysionneau | i2c_shift_reg_read() / i2c_shift_reg_write() are used to read from/write to the shift reg | 13:11 |
| ysionneau | i2c_status_read() / i2c_status_write() are used to read the status bits (FULL/EMPTY conditions) and for clearing them | 13:11 |
| ysionneau | I clear them by writing the READY value which is 0 | 13:12 |
| ysionneau | oh, and i2c_slave_addr_write() at the beginning is to set the slave address | 13:13 |
| ysionneau | fake_fw contains dummy data, just for the testing purposes | 13:13 |
| ysionneau | don't know if that's clear enough :o | 13:14 |
| *** thaytan_ has joined #timvideos | 13:16 | |
| ysionneau | basically i2c_status_read() returns the value of the shift_reg_empty / shift_reg_full bits you can see on the logic analyzer screenshots | 13:17 |
| ysionneau | and i2c_status_write() writes to them (usually just to clear them) | 13:17 |
| *** thaytan has quit IRC | 13:17 | |
| mithro | ysionneau: so, looking at https://cdn.sparkfun.com/assets/6/4/7/1/e/51ae0000ce395f645d000000.png | 13:24 |
| mithro | There is the initial address frame | 13:25 |
| mithro | and then n data frames after it | 13:25 |
| ysionneau | yes | 13:26 |
| mithro | so say, I have an I2C protocol, where the I2C master sends two datagrams as the first request (a 16bit address) | 13:29 |
| ysionneau | yes, 2 subsequent writes | 13:30 |
| mithro | I call i2c_shift_reg_read twice? | 13:31 |
| ysionneau | you can't initiate anything as you are the slave | 13:32 |
| ysionneau | so you need to "wait" for the master to do those 2 writes | 13:32 |
| ysionneau | so you wait for the first time the shift reg is "full", you call i2c_shift_reg_read() | 13:32 |
| ysionneau | you clear the flag, you wait again for it to become full again | 13:32 |
| ysionneau | and you call i2c_shift_reg_read() a second time | 13:33 |
| mithro | What is happening on line 25? | 13:34 |
| ysionneau | on line 25, I pre-load the shift reg with fake_fw[0] | 13:34 |
| mithro | why? | 13:34 |
| ysionneau | because I can't know if the master will start with a read or a write | 13:35 |
| ysionneau | if it starts with a write to ask some address, then this will be overwritten | 13:35 |
| ysionneau | if it starts with a read, to sequentially read (from address 0) then it will get this first byte | 13:35 |
| ysionneau | if the master always do write(address) read(data); then this line 25 is for nothing and can be removed | 13:36 |
| mithro | ysionneau: so, you then wait until the shift register is empty and load it with the next value on line 29? | 13:37 |
| ysionneau | the actual reloading is done line 32 | 13:37 |
| ysionneau | but yes | 13:37 |
| mithro | So, if you have I2C master reading two datagram bytes, you need to make sure the next value is in the register by the time it starts shifting it out? | 13:38 |
| ysionneau | (+ address auto increment) | 13:38 |
| ysionneau | mithro: yes, that's why I use clock stretching (aka PAUSE) when shift reg is empty | 13:38 |
| ysionneau | so that the master waits for the software reload | 13:38 |
| ysionneau | that's what's happening in the first "scenario" of the documentation | 13:39 |
| ysionneau | several reads in a row | 13:39 |
| ysionneau | basically, until the software clears the "shift reg empty" flag (line 33), the master cannot issue another read | 13:40 |
| mithro | ysionneau: can this work without needing to do clock stretching? | 13:40 |
| ysionneau | maybe, we would have to test | 13:40 |
| ysionneau | but that would be open the "race conditions" | 13:41 |
| ysionneau | if I can call it that way | 13:41 |
| ysionneau | not all masters support clock stretching though, I hope the FX2 does. If it really supports I2C (and not Two Wire Interface) it should | 13:42 |
| ysionneau | http://www.cypress.com/knowledge-base-article/i2c-clock-stretching-fx2lp-kba84113 <= | 13:45 |
| tpb | Title: I2C Clock Stretching in FX2LP - KBA84113 | Cypress (at www.cypress.com) | 13:45 |
| ysionneau | it seems it does o/ | 13:45 |
| mithro | ysionneau: the only difference between the first address byte and the subsequent data bytes is if we know at the start if we should ack them? | 13:46 |
| mithro | IE we don't know to ack the first address byte until we know it matches our address? | 13:47 |
| ysionneau | hmmm | 13:47 |
| ysionneau | not sure I understand the question | 13:48 |
| ysionneau | aren't you mixing "slave address" and "byte address"? | 13:48 |
| mithro | I2C address | 13:48 |
| ysionneau | ah ok | 13:48 |
| ysionneau | yes, if the I2C slave address is not ourself, we don't ack | 13:48 |
| ysionneau | we let someone else ack (or no-one and this is a NACK) | 13:49 |
| ysionneau | I don't know if that answers your question | 13:49 |
| * ysionneau not a native speaker here | 13:49 | |
| mithro | I2C is effectively, Start Bit, 8 bits, ack, 8 bits, ack, 8 bits, ack, Stop bit | 13:50 |
| ysionneau | yes, or you can also replace the stop bit with a "restart bit" (which AFAIK is just a start bit) | 13:51 |
| mithro | The "first" 8 bits are specially because they are the address + r/w direction of the I2C device | 13:51 |
| ysionneau | yes | 13:51 |
| ysionneau | those are handled by the gateware (the I2C slave addr matching) | 13:51 |
| mithro | ysionneau: yes, but it means we can only pretend to be a single I2C slave at once, right? | 13:52 |
| mithro | After the 8 bits, how long do we have to perform an "ack"? | 13:52 |
| ysionneau | yes, but if the requests are not too mixy, you can change your I2C slave addr on the fly using the i2c_slave_addr_write() function | 13:52 |
| ysionneau | and you could multiplex several slaves | 13:52 |
| ysionneau | if you know the spatial (or temporal) access pattern | 13:53 |
| ysionneau | but it does not cover all the cases indeed | 13:53 |
| ysionneau | 14:49 <@mithro> After the 8 bits, how long do we have to perform an "ack"? < I think we should drive SDA low upon SCL going low from previous bit | 13:54 |
| ysionneau | so that it's ready when SCL goes up again | 13:54 |
| ysionneau | I don't know the tolerances | 13:54 |
| mithro | I'm guessing the same problem you ran into with just bit-banging would prevent you servicing an interrupt in time to confirm if you wanted to ack or not | 13:54 |
| ysionneau | I'm guessing also | 13:54 |
| ysionneau | but, maybe clock stretching can be applied here also | 13:54 |
| ysionneau | and I could provide something more adaptable to allow to read the slave addr request and ack or nack by SW | 13:55 |
| ysionneau | I mean, maybe I can hold SCL low before the ACK/NACK bit, to tell the master to wait a bit so that the software makes its mind on whether it wants to ack or nack | 13:56 |
| mithro | That feels very non-standard :) | 13:57 |
| ysionneau | not sure, need to check the places where clock stretching is allowed | 13:58 |
| mithro | ysionneau: for now, I think it's good enough without needing that | 13:58 |
| mithro | ysionneau: we can keep the address checking specialization | 13:58 |
| mithro | ysionneau: can we double buffer the register? | 13:59 |
| mithro | ysionneau: so we don't have to do clock stretching? | 13:59 |
| ysionneau | that's what I wanted to avoid :p | 13:59 |
| ysionneau | having a FIFO to handle | 13:59 |
| *** thaytan_ is now known as thaytan | 13:59 | |
| mithro | ysionneau: why? | 13:59 |
| *** ChanServ sets mode: +v thaytan | 13:59 | |
| ysionneau | just because I didn't feel very confortable writing it, I wanted to go for the simplest stuff | 14:00 |
| ysionneau | but I can have a look at it | 14:00 |
| ysionneau | there is a FIFO block in migen | 14:00 |
| mithro | ysionneau: I think we only want a depth of one | 14:00 |
| ysionneau | just need to drive it correctly | 14:00 |
| mithro | rather then a real fifo | 14:00 |
| mithro | actually, if you just make the shift register 16 bits, then it should work, no? | 14:01 |
| ysionneau | yeah I thought of that | 14:01 |
| ysionneau | then you need some mechanism to know which part is real data or not | 14:01 |
| mithro | ysionneau: what do you mean? | 14:01 |
| ysionneau | well, you then have a "data_vailable" bit (on top of the already existing shift_reg_full bit) | 14:02 |
| ysionneau | ah, you can check with data_available and not full. | 14:02 |
| ysionneau | would mean only the lower part is real data | 14:02 |
| ysionneau | hmm then maybe we have issues for atomic update of the register | 14:03 |
| mithro | ysionneau: actually its easier if we have 2 8 bit registers | 14:04 |
| ysionneau | yes | 14:04 |
| mithro | ysionneau: The "ACTIVE" and the "NEXT" | 14:04 |
| mithro | When the "ACTIVE" goes empty, there is a setting which says transfer NEXT into the "ACTIVE" | 14:05 |
| mithro | and you get an interrupt | 14:05 |
| mithro | then you put the next byte into the NEXT | 14:05 |
| ysionneau | that works for sequential reads I would say | 14:05 |
| ysionneau | but not for random reads | 14:05 |
| ysionneau | for sequential reads you can predict two reads in a row and put both active/next values | 14:06 |
| mithro | ysionneau: For random reads you have to write a new address each time? | 14:06 |
| ysionneau | for random read you have a write followed with a read | 14:06 |
| ysionneau | mithro: not sure, i would say once you've written one you can also use auto increment | 14:06 |
| mithro | ysionneau: with auto-increment you'll know what the next byte is, right? | 14:07 |
| ysionneau | yes but for the first read | 14:07 |
| ysionneau | you have WRITE followed by READ | 14:07 |
| ysionneau | you don't know which data to send until the write is completed | 14:07 |
| ysionneau | but you need to be fast because the read is coming right away after the write | 14:08 |
| ysionneau | and since you need to wait for the write to complete, you can't use double buffering tricks | 14:08 |
| mithro | ysionneau: doesn't the read need to resend the address? | 14:08 |
| ysionneau | I was talking about I2C transactions | 14:09 |
| ysionneau | write (for the address) read (for the data) | 14:09 |
| mithro | Each transaction starts with the "address+r/w" byte, right? | 14:09 |
| ysionneau | yes | 14:10 |
| ysionneau | in case of a random read, you have first a Write, then another transaction with a Read | 14:10 |
| ysionneau | (or 2 writes in case of 2 bytes addresses) | 14:10 |
| mithro | So between the "write address EEPROM cmd" and the "get EEPROM data cmd" you'll have a whole byte of I2C data? | 14:10 |
| ysionneau | ah yes, you have the slave address yes | 14:11 |
| mithro | which is the I2C address+r/w byte | 14:11 |
| ysionneau | yes | 14:11 |
| ysionneau | I see, there's time then :o | 14:11 |
| mithro | You have 9bits * 400kHz :) | 14:12 |
| ysionneau | yep that's pretty ok I guess | 14:13 |
| mithro | To get your byte of data into the "ACTIVE" shift register, and also preload "NEXT" with byte+1 data | 14:13 |
| ysionneau | so IIUC I can just remove the clock stretching from the current implementation, and it should work out of the box | 14:14 |
| ysionneau | even without adding extra shift register | 14:14 |
| ysionneau | except for sequential reads I mean | 14:14 |
| mithro | ysionneau: not so, you need the clock stretching for the sequential read right now? | 14:15 |
| ysionneau | yes | 14:15 |
| mithro | ysionneau: the NEXT register just is a way to optimise sequential reads? | 14:15 |
| ysionneau | but I can remove the clock stretching, and test some random reads | 14:15 |
| ysionneau | to see if that works well | 14:15 |
| mithro | ysionneau: yeah, I guess so? | 14:15 |
| mithro | btw I should be home in bed | 14:15 |
| ysionneau | oh you're not home | 14:15 |
| ysionneau | :x | 14:15 |
| ysionneau | so, quickly, do I implement for double buffering stuff or are we good with the current implementation? | 14:16 |
| mithro | ysionneau: btw -> this line has too many magic numbers | 14:16 |
| mithro | ysionneau: Wire.requestFrom(0x50, 9); // request 9 bytes from slave device #8 | 14:16 |
| mithro | why 0x50? | 14:16 |
| ysionneau | the main issue is the comment is wrong :p | 14:17 |
| ysionneau | it's device #0x50 | 14:17 |
| ysionneau | I will replace with a macro DEVICE_ADDRESS | 14:17 |
| mithro | ysionneau: Wire.requestFrom(EEPROM_I2C_ADDR, 9); // request 9 bytes | 14:17 |
| mithro | :) | 14:17 |
| ysionneau | yep :) | 14:17 |
| ysionneau | sorry about that | 14:17 |
| mithro | ysionneau: no worries, I've spent the last 2 weekends removing magic numbers from the FX2 firmware | 14:18 |
| ysionneau | (at first I didn't plan on sharing the Arduino code :p) | 14:18 |
| ysionneau | but I agree all of this needs some cleanup | 14:18 |
| mithro | ysionneau: I assume your FX2 hasn't turned up yet? | 14:19 |
| ysionneau | I finished at more than midnight yesterday I was a bit sleepy:' | 14:19 |
| ysionneau | no :( | 14:19 |
| mithro | _florent_: btw Has a package from digilent turned up for you at all? | 14:19 |
| ysionneau | so I can't test with real HW | 14:19 |
| mithro | ysionneau: I think your arduino emulation will be good enough to get this working | 14:19 |
| ysionneau | either I wait for the package to arrive, or I start the integration work, send you a patch to your own repo, and let you test (but it's not cool for debug) | 14:19 |
| ysionneau | yes I think also | 14:20 |
| mithro | ysionneau: oh, and remember your address is dependent on the EEPROM size emulation you are using | 14:20 |
| ysionneau | ah yes, this is just testing code | 14:20 |
| mithro | http://www.cypress.com/file/43391/download | 14:21 |
| ysionneau | default is 100 kHz o/ | 14:21 |
| ysionneau | cool there's the eeprom layout | 14:23 |
| ysionneau | ah yes I see the A0/A1/A2 pin values | 14:25 |
| mithro | ysionneau: I actually have no idea how that effects the I2C address, I assume that maybe they are just the lower bits of the I2C address? | 14:25 |
| ysionneau | yes, it's not in this document | 14:26 |
| ysionneau | but on another datasheet you went me it explains which bits are these A* | 14:26 |
| ysionneau | LSB or MSB I don't remember | 14:26 |
| ysionneau | ah, got it | 14:26 |
| mithro | ysionneau: so, what we need in the end is a gateware which samples the switch status on "boot" and then provides one of two .hex files | 14:26 |
| ysionneau | http://www.cypress.com/file/138911/download | 14:27 |
| ysionneau | I would make this sampling + the chosing done in sw, is that Ok? | 14:27 |
| mithro | Ideally the .hex files would be stored in the SPI flash, but a temporary/initial solution would be to just bake them into the gateware as ROM data | 14:28 |
| mithro | ysionneau: perfectly fine | 14:28 |
| ysionneau | I think storing both in spi flash is really the easiest solution | 14:29 |
| ysionneau | since sw can easily access it, it's memory mapped etc | 14:29 |
| ysionneau | then you can just sample the switch status, and assign a pointer value to one or the other spi flash region and you're good to go | 14:30 |
| ysionneau | we would also need to make the fw .bin instead of .hex, but I guess it's easy to do | 14:30 |
| ysionneau | ah no I remember now, the meaning of A0/A1/A2 was in the eeprom datasheet, sounds logical now :) | 14:32 |
| ysionneau | ok, page 7 of http://ww1.microchip.com/downloads/en/DeviceDoc/21191s.pdf | 14:33 |
| ysionneau | Figure 5-1 | 14:33 |
| ysionneau | slave address will be 1010 A2 A1 A0 | 14:34 |
| ysionneau | so 0x50 if A[2:0] == 000 for 1 byte addresses | 14:35 |
| ysionneau | for 16 kB eeprom you need A[2:0] == 001 so slave address will be 1010 001 = 0x51 | 14:36 |
| mithro | I'm heading home to bed | 14:38 |
| mithro | gnight | 14:38 |
| ysionneau | gn8! | 14:38 |
| *** se6astian is now known as se6astian|away | 16:20 | |
| *** se6astian|away is now known as se6astian | 19:03 | |
| *** se6astian is now known as se6astian|away | 19:03 | |
| *** se6astian|away is now known as se6astian | 19:04 | |
| *** se6astian is now known as se6astian|away | 21:48 | |
| CarlFK | tumbleweed: you haven't built a box or anything for your atlys right? | 22:46 |
| tumbleweed | no | 22:59 |
| tumbleweed | and I'm getting worried about the ports on it :) | 23:00 |
| CarlFK | tumbleweed: I'll make something for it. I just got the cables | 23:01 |
| tumbleweed | oh, VGA adaptors arrived btw | 23:03 |
| tumbleweed | same ones we used at cambridge | 23:03 |
| CarlFK | thanks | 23:04 |
| CarlFK | did you use your Atlys in Cambridge? | 23:05 |
| tumbleweed | yep | 23:05 |
| CarlFK | using dvswtich? | 23:06 |
| tumbleweed | yep | 23:06 |
| CarlFK | everything 1024x768? | 23:06 |
| CarlFK | so 4:3 | 23:06 |
| tumbleweed | everything 4:3 | 23:06 |
| CarlFK | hmm | 23:06 |
| tumbleweed | atlys was on a 1024x768 mode | 23:07 |
| CarlFK | from what I gather... the 2 rooms we are in are vga only, 4:3 screens | 23:07 |
| tumbleweed | what's the story with recording? did they agree to dvswitch in the end? | 23:07 |
| CarlFK | no .. you haven't been hearing me cry daily? :P | 23:08 |
| tumbleweed | well yes, but I don't have the full picture | 23:08 |
| tumbleweed | you're recording all streams and they'll edit by hand, later? | 23:08 |
| CarlFK | Atlys gst pipeline record to mkv. camera record to SD Card, | 23:09 |
| CarlFK | cp that stuff onto my i7 laptop... | 23:09 |
| CarlFK | do some veyepar things: add, read times, make .mlt | 23:09 |
| CarlFK | then... drumroll | 23:09 |
| CarlFK | Shotcut foo.mlt, find the .mkv in the list of assets, drag it down to the empty video track, save. | 23:10 |
| CarlFK | mv foo.mlt ../custom/mlt | 23:10 |
| CarlFK | go back to normal veyepar encode/post | 23:10 |
| CarlFK | oh wait.. missed a small step | 23:11 |
| CarlFK | write down hms when talk start and end | 23:11 |
| tumbleweed | so, the stuff you get from the camera won't be well timecoded | 23:11 |
| CarlFK | in veyepar, replace the scheduled start with the real star | 23:11 |
| tumbleweed | it'd probably be easier to put the screengrabbed video into veyepar than the camera video | 23:11 |
| tumbleweed | well, I guess that's not dvswitch either, so it's all kind of custom and hacky | 23:12 |
| CarlFK | yep | 23:12 |
| CarlFK | the camera and laptop clocks are synced thanks to daven (long time dc-video guy | 23:12 |
| CarlFK | laptop audio out into that yellow video in | 23:13 |
| CarlFK | play some modem sounding time code stuff | 23:13 |
| CarlFK | sets the cam's clock | 23:13 |
| tumbleweed | o_O | 23:13 |
| CarlFK | right! | 23:13 |
| tumbleweed | so what do we do? hang around and babysit the atlys? | 23:14 |
| CarlFK | and point the camera.. or soemthing | 23:14 |
| CarlFK | not much :( | 23:14 |
| tumbleweed | heh | 23:14 |
| CarlFK | i feel a little bad | 23:14 |
| CarlFK | but you made me go to ZA so that makes up for it :D | 23:15 |
| tumbleweed | lol | 23:15 |
| CarlFK | im not too worried about it | 23:15 |
| tumbleweed | I have things to hack on | 23:15 |
| CarlFK | I figured as much. | 23:15 |
| tumbleweed | better than lying in bed at home, watching TV | 23:15 |
| CarlFK | and there is a little tech to be gleamed from the whole thing | 23:16 |
| CarlFK | and we get to hang out with the PyOhio chair | 23:16 |
| CarlFK | so not 100% disaster | 23:16 |
| tumbleweed | something like this would be a great excuse to muck around with voctomix | 23:16 |
| tumbleweed | but that requires hardware, and an actual separate camera operator | 23:17 |
| tumbleweed | (I mean, someone to take care of things while we fight with voctomix) | 23:17 |
| CarlFK | right | 23:17 |
| CarlFK | and more atlys boards | 23:18 |
| tumbleweed | or, even better, something that captures HDMI + audio | 23:18 |
| CarlFK | oh yeah, that :p | 23:18 |
| CarlFK | do you have some 32g sd cards? | 23:19 |
| tumbleweed | nope | 23:19 |
| CarlFK | k | 23:19 |
| CarlFK | I have 6 new ones. 180 min each | 23:20 |
| tumbleweed | should be enough | 23:20 |
| CarlFK | yeah. | 23:20 |
| CarlFK | the file names are 0000 0001 0002 and it resets when you put a fresh card in | 23:20 |
| CarlFK | I hope I don't step on files | 23:21 |
| tumbleweed | ick | 23:21 |
| tumbleweed | why can't they use nice filenames with the full timestamp in them? | 23:21 |
| CarlFK | dvswich makes so many problems go away | 23:21 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
