Thursday, 2017-08-24

*** tpb has joined #timvideos00:00
*** sb0 has joined #timvideos02:46
*** rohitksingh_work has joined #timvideos03:23
*** sb0 has quit IRC03:55
mithropaddatrapper: Are we doing a meeting today? IIRC You said that your new timetable conflicted with it?04:54
paddatrappermithro: yeah, I'm available the hour after our normal time though04:59
mithropaddatrapper: Okay that works04:59
paddatrappermithro: cool04:59
paddatrappermithro: my project report has some content now. There is still a couple of things I want to add (the TODO parts), but the bulk is there05:48
John_Kmithro: did you happen to look at the CypressFX module today?06:56
mithroJohn_K: sorry, not yet06:59
John_Kno worries06:59
mithroJohn_K: Any chance you could look at integrating it into our HDMI2USB-mode-switch tool? The current code which calls fxload on the command line is at ->
tpbTitle: HDMI2USB-mode-switch/ at master · timvideos/HDMI2USB-mode-switch · GitHub (at
mithropaddatrapper: I guess your looking at ?07:05
tpbTitle: HDMI2USB FX2 Interface - Google Docs (at
paddatrappermithro: yup. Busy wiring/writing FIFO audio firmware07:10
cr1901_modernmithro: Writing SFL receiver now. I will be gone most of the upcoming day today (10 EDT to at least 5 EDT). I'll take a look if you're busy later, but could you take a look at the QEMU timer if I don't get to it by 10 EDT?07:22
mithroI'll try but my weekend next couple of days is looking pretty busy07:23
cr1901_modernWell I'll take a look after SFL receiver then.07:24
cr1901_modernmithro: I want to get mimasv2, qemu, and opsis working before I add a "size hint" for PIC and FX207:24
mithrocr1901_modern: SGTM07:24
*** karltheawesome has joined #timvideos07:34
mithroHi karltheawesome!07:35
mithrokarltheawesome: I'm hoping to get to merging all your stuff tonight07:35
karltheawesomeHi Tim07:36
karltheawesomesorry it's taken me a while to get on07:36
karltheawesomeit's been pretty hectic at work07:36
mithrokarltheawesome: Nah, I'm been slack with merging your stuff - I normally want to try and do it within 2-3 days07:36
karltheawesomeI have made some good progress with the 7seg display though!07:36
mithrokarltheawesome: Cool!07:37
karltheawesometurns out I was switching between segments too fast and getting aliasing, once I made the period more like 10000ns it worked07:37
mithrokarltheawesome: I was looking at how to better generate names / labels for the LEDs and Switches07:37
karltheawesomeyeah I'm not too happy with the changes I made there tbh07:38
mithrokarltheawesome: Hrm?07:38
karltheawesomeI made some changes so it makes a new object every time you do something like litex.Led()07:39
karltheawesomebut it dosen't really make sense07:39
karltheawesomesince it's tied to a physical thing07:39
karltheawesomeif you do something like:07:40
karltheawesome>>> led1 = litex.Led(1)07:40
karltheawesome>>>led2 = litex.Led(1)07:40
karltheawesomethen you have two objects sharing the same state07:40
mithrokarltheawesome: It would be nice if they are statically allocated07:48
karltheawesomeI agree07:49
mithrokarltheawesome: We should have the number of LEDs / switches being exposed now07:49
karltheawesomeI'm wondering if you could actually generate some of the C micropython code using python templates as part of the build process07:49
mithrokarltheawesome: we discussed a bunch of stuff around that during the sprints07:51
mithrokarltheawesome: If you take a look at you can find some code which generates micropython stuff based on .csv files for the different stm based boards...07:52
tpbTitle: micropython/stmhal/boards at master · upy-fpga/micropython · GitHub (at
mithrokarltheawesome: I'm guessing we might want to do something similar07:53
karltheawesomecool, I'll try to take a look at that soon07:56
mithrokarltheawesome: No hurry, we tend to be more slow & steady style progress08:03
paddatrappermithro: do you have any suggestions for writing half an array as a byte? I need to split the EP8FIFOBUF data, which is stored as an 4 byte array and I need the first byte08:29
paddatrapperactually it is the first quater of the array08:30
mithropaddatrapper: Hrm?08:31
mithropaddatrapper: If you have an int32 array and you want to access it as bytes?08:31
paddatrappermithro: unsigned char array08:32
paddatrapperI need the first byte08:33
mithrochar == bytes08:33
cr1901_modernint * my_array_base;08:33
cr1901_modernsize_t int_offset, char_offset;08:33
cr1901_modernunsigned char * byte_offset = ((unsigned char *) (my_array_base + int_offset)) + char_offset;08:33
mithrounsigned char a[4];   a[0] == first byte?08:33
paddatrappermithro: ah yes thanks08:33
mithropaddatrapper: So that is just how arrays work? -- was the confusion that "unsigned char" == "byte" ?08:35
paddatrappermithro: My confusion was a misunderstanding what I was writing. Essentially I need to write the buffer two bytes at a time, and not half of it (256 bytes) at a time. Explaining it made me realise the error08:37
mithropaddatrapper: there is a write hi and write low macros08:38
paddatrappermithro: I'm using them. I'm writing from the FIFO buffer to two ports to drive the slave FIFO08:39
mithroPut the code some where and I'll look at it?08:41
paddatrappersure. I'll commit it now08:42
tpbTitle: HDMI2USB-fx2-firmware/app.c at audio-out · paddatrapper/HDMI2USB-fx2-firmware · GitHub (at
paddatrappermithro: haven't tested it yet08:45
cr1901_modernmithro: Are you familiar with the SFL protocol?08:50
mithrocr1901_modern: Nope!08:52
mithropaddatrapper: are FDL and FDH FX2 special registers?08:53
mithropaddatrapper: Oh they are defines at the top08:54
mithropaddatrapper: BTW The FIFO can operate in both 8 and 16bit modes08:54
cr1901_modernmithro: So SFL protocol embeds the address that it wants to write to into the protocol itself (and looking at flterm.c, in practice will use discontiguous regions), and additionally expects the receiver to reboot immediately upon receiving the firmware. Both these contradict your requirements of writing to an intermediate buffer :(08:54
cr1901_modernI.e. SFL is an "all-or-nothing" thing, unless I implement the receiver _reaaaaaally_ stretching how it's supposed to behave (which I can do, but the SFL impl isn't useful outside of hdmi2usb)08:56
mithropaddatrapper: So it looks like you are "bit-banging" the FIFO master?08:57
paddatrappermithro: yup. Figured it would be easier to do 16 bit. If I run into issues I'll switch to 8bit08:57
paddatrappermithro: where?08:57
mithropaddatrapper: Well, you manually reading from the endpoint buffer ram and writing it out to the FIFO checking the flags?08:58
paddatrappermithro: no, I'm manually reading from FIFO buffer and writing to the FD output pins that drive the slave08:59
mithropaddatrapper: Your manually (IE CPU controlled) reading the data coming from the computer and writing to the output pins09:01
paddatrappermithro: somewhat. The data from the PC is automatically being placed in the FIFO buffer from the endpoint, and it's manual from the buffer the the output pin09:02
paddatrappermithro: ready for the hangout call when you are09:04
mithropaddatrapper: What you really want is the "2.3 GPIF Mode-Auto" where the data foes computer->FIFO->pins without the 8051 processor being involved at all09:05
paddatrappermithro: I definitely would much prefer that09:06
mithroWhen the GPIF is activated, the interface pins function as a master device to control external peripherals such as a RAM, FIFO, or external processor. The GPIF operates in two sub-modes, Automatic and Manual. In Auto mode, the data flows directly from the endpoint FIFOs to the external interface. The 8051 processor configures and monitors this interface, but does not directly access the FIFO data09:06
paddatrappermithro: is this from the datasheet or the TRM?09:06
mithropaddatrapper: From the -- "Getting Started with EZ-USB® FX2LP™ GPIF"09:07
paddatrappermithro: ah ok cool. I shall use that then09:08
mithroOkay, I'm heading to the VC room now, will be on the call in a second09:09
tpbTitle: HDMI2USB-litex-firmware/fx2_fw_hdmi2usb.c at master · timvideos/HDMI2USB-litex-firmware · GitHub (at
tpbTitle: HDMI2USB-litex-firmware/firmware at b50566518c649eec8f79c1b9e4ceecaa5dbf08a9 · timvideos/HDMI2USB-litex-firmware · GitHub (at
tpbTitle: HDMI2USB-litex-firmware/ at b50566518c649eec8f79c1b9e4ceecaa5dbf08a9 · timvideos/HDMI2USB-litex-firmware · GitHub (at
tpbTitle: HDMI2USB FX2 Interface - Google Docs (at
mithropaddatrapper: Random VHDL ->
tpbTitle: HDMI2USB-litex-firmware/fx2_jpeg_streamer.vhd at master · timvideos/HDMI2USB-litex-firmware · GitHub (at
tpbTitle: HDMI2USB-litex-firmware/ at master · timvideos/HDMI2USB-litex-firmware · GitHub (at
tpbTitle: Teams/DebConf/Video/VideoTeamDocs/NewVideoTeamHardware - Debian Wiki (at
tpbTitle: Google Drawings - create diagrams and charts, for free. (at
*** tangrs has quit IRC09:55
*** tangrs has joined #timvideos10:08
mithroIshan_Bansal: ping?10:23
Ishan_Bansalmithro : pong11:24
mithroIshan_Bansal: how goes your final report11:24
Ishan_Bansalmithro : I am currently working on that only.11:25
mithroIshan_Bansal: Okay - could you share it so we know you are going in the right direction11:25
Ishan_Bansalmithro :
tpbTitle: GSOC Final Project Report - Google Docs (at
Ishan_Bansalmithro: Are the heading given are suitable ?11:29
mithroIshan_Bansal: Yes, they are a good start11:29
mithroIshan_Bansal: Until you have content its a bit hard to tell11:29
Ishan_Bansalmithro : Also apart from this is their a need of making an another documentation describing every module of the JPEG encoder  ?11:30
mithroIshan_Bansal: You should have a doc describing the make up at a high level with diagrams showing the data flow and descriptions of how the data is transformed11:31
mithroIshan_Bansal: All the low level details should be in the doc strings and stuff inside the code11:31
Ishan_Bansalmithro : Should I create a doc containing high level with diagrams in this doc itself or should I create a separate doc for the same ?11:33
mithroIshan_Bansal: The high level doc be a separate doc, but it is okay to reuse some of that doc in your end of GSoC report11:34
Ishan_Bansalmithro : If possible, where am I able to find the previous years final reports >11:38
Ishan_BansalTo get a brief overview of how it should be :)11:39
tpbTitle: GSoC Project Report: VGA capture expansion board for HDMI2USB on Digilent Atlys | Dreams eXtrinsic (at
Ishan_Bansalmithro : cool, that helps. Also finally I do not have to submit the doc ?11:41
mithroIshan_Bansal: Hrm?11:41
Ishan_Bansalmithro : The above links which you have given none of them is on google docs, so what I thought of is that I should first write it in the google docs and than put it onto some other stuff such as wordpress etc. Isn't it ?11:43
mithroYes, both of them wrote their doc in Google Docs and we reviewed them, putting comments on them and such11:44
mithroThen published them on their blog11:44
Ishan_Bansalmithro : May be by tomorrow I am able to show you a considerable progress on the Final Report . :)11:46
mithroIshan_Bansal: Great!11:47
Ishan_Bansalmithro : In btw, I made the changes on the RLE so whenever you are free just review it once.11:48
mithroOkay, send a pull request for it?12:01
cr1901_modernmithro: Ping if you're still around (sorry I fell back to sleep)12:14
mithrocr1901_modern: I'm kinda still here...12:15
cr1901_modernmithro: I slept on it, so I just wanted to run something by you.12:16
cr1901_modernmithro: I think SFL should be implemented as-intended, where the data is written immediately, and the address to write is embedded in the protocol12:17
cr1901_modernmithro: This contradicts your requirements (write the entire payload to a temporary buffer and check it before writing to flash), but the alternate solution is to ignore the address embedded in SFL packets (which requires no changes to my libmodem), ignore the JMP_TO_PAYLOAD packet.12:21
cr1901_modernThen my SFL implementation in libmodem isn't implemented to spec, and has no real advantages over xmodem other than "flterm supports it".12:21
Ishan_Bansalmithro : The changes are been made on the previous pull request only. I am talking about this :
tpbTitle: Adding RLE-core module for JPEG encoder by ishan98 · Pull Request #2 · timvideos/litejpeg · GitHub (at
cr1901_modernmithro: I'll do what you want me to do, but I feel more comfortable with the former solution (implement as-intended).12:28
mithrocr1901_modern: you got some docs to back up your claim?12:28
cr1901_modernmithro: Just reading the source of flterm and
tpbTitle: milkymist/flterm.c at master · m-labs/milkymist · GitHub (at
tpbTitle: milkymist/flterm.c at master · m-labs/milkymist · GitHub (at
cr1901_moderncmdline_address is the first 4 bytes of the payload (CRC is added in send_frame), this is sent to a receiver, and the receiver must write the payload starting at the address sent in the first 4 bytes of the payload12:33
cr1901_modernmithro: SFL_CMD_JUMP has a frame length of 4. It's an address to jump to, based on the printf statement12:40
tpbTitle: milkymist/flterm.c at master · m-labs/milkymist · GitHub (at
cr1901_modernSLF_CMD_JUMP, SFL_CMD_LOAD and SFL_CMD_ABORT are all I have to support; the remaining commands don't make sense for HDMI2USB12:40
mithroI'll take a closer look tomorrow12:42
*** rohitksingh_work has quit IRC12:43
cr1901_modernmithro: All I can ask for, thanks. In the meantime, I'll take a look at QEMU's timer12:43
*** rohitksingh has joined #timvideos13:44
*** rohitksingh has quit IRC19:37
*** nueces has joined #timvideos20:55
*** sb0 has joined #timvideos22:48
*** nueces has quit IRC23:31
*** CarlFK has quit IRC23:51

Generated by 2.13.1 by Marius Gedminas - find it at!