| *** tpb has joined #timvideos | 00:00 | |
| *** sb0 has joined #timvideos | 02:46 | |
| *** rohitksingh_work has joined #timvideos | 03:23 | |
| *** sb0 has quit IRC | 03:55 | |
| mithro | paddatrapper: Are we doing a meeting today? IIRC You said that your new timetable conflicted with it? | 04:54 |
|---|---|---|
| paddatrapper | mithro: yeah, I'm available the hour after our normal time though | 04:59 |
| mithro | paddatrapper: Okay that works | 04:59 |
| paddatrapper | mithro: cool | 04:59 |
| paddatrapper | mithro: 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 there | 05:48 |
| John_K | mithro: did you happen to look at the CypressFX module today? | 06:56 |
| mithro | John_K: sorry, not yet | 06:59 |
| John_K | no worries | 06:59 |
| mithro | John_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 -> https://github.com/timvideos/HDMI2USB-mode-switch/blob/master/hdmi2usb/modeswitch/boards.py#L109-L145 | 07:01 |
| tpb | Title: HDMI2USB-mode-switch/boards.py at master · timvideos/HDMI2USB-mode-switch · GitHub (at github.com) | 07:01 |
| mithro | paddatrapper: I guess your looking at https://docs.google.com/document/d/15oMrgGfgziHL9kqiRNEF34UaUKkOw0XkG7-D83iEM1s/edit?ts=599e7638 ? | 07:05 |
| tpb | Title: HDMI2USB FX2 Interface - Google Docs (at docs.google.com) | 07:05 |
| paddatrapper | mithro: yup. Busy wiring/writing FIFO audio firmware | 07:10 |
| cr1901_modern | mithro: 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 |
| mithro | I'll try but my weekend next couple of days is looking pretty busy | 07:23 |
| cr1901_modern | Well I'll take a look after SFL receiver then. | 07:24 |
| cr1901_modern | mithro: I want to get mimasv2, qemu, and opsis working before I add a "size hint" for PIC and FX2 | 07:24 |
| mithro | cr1901_modern: SGTM | 07:24 |
| *** karltheawesome has joined #timvideos | 07:34 | |
| mithro | Hi karltheawesome! | 07:35 |
| mithro | karltheawesome: I'm hoping to get to merging all your stuff tonight | 07:35 |
| karltheawesome | Hi Tim | 07:36 |
| karltheawesome | sorry it's taken me a while to get on | 07:36 |
| karltheawesome | it's been pretty hectic at work | 07:36 |
| mithro | karltheawesome: Nah, I'm been slack with merging your stuff - I normally want to try and do it within 2-3 days | 07:36 |
| karltheawesome | I have made some good progress with the 7seg display though! | 07:36 |
| mithro | karltheawesome: Cool! | 07:37 |
| karltheawesome | turns out I was switching between segments too fast and getting aliasing, once I made the period more like 10000ns it worked | 07:37 |
| mithro | karltheawesome: I was looking at how to better generate names / labels for the LEDs and Switches | 07:37 |
| karltheawesome | yeah I'm not too happy with the changes I made there tbh | 07:38 |
| mithro | karltheawesome: Hrm? | 07:38 |
| karltheawesome | I made some changes so it makes a new object every time you do something like litex.Led() | 07:39 |
| karltheawesome | but it dosen't really make sense | 07:39 |
| karltheawesome | since it's tied to a physical thing | 07:39 |
| karltheawesome | if you do something like: | 07:40 |
| karltheawesome | >>> led1 = litex.Led(1) | 07:40 |
| karltheawesome | >>>led2 = litex.Led(1) | 07:40 |
| karltheawesome | then you have two objects sharing the same state | 07:40 |
| mithro | Yeah | 07:47 |
| mithro | karltheawesome: It would be nice if they are statically allocated | 07:48 |
| karltheawesome | I agree | 07:49 |
| mithro | karltheawesome: We should have the number of LEDs / switches being exposed now | 07:49 |
| karltheawesome | I'm wondering if you could actually generate some of the C micropython code using python templates as part of the build process | 07:49 |
| mithro | karltheawesome: we discussed a bunch of stuff around that during the sprints | 07:51 |
| mithro | karltheawesome: If you take a look at https://github.com/upy-fpga/micropython/tree/master/stmhal/boards you can find some code which generates micropython stuff based on .csv files for the different stm based boards... | 07:52 |
| tpb | Title: micropython/stmhal/boards at master · upy-fpga/micropython · GitHub (at github.com) | 07:52 |
| mithro | karltheawesome: I'm guessing we might want to do something similar | 07:53 |
| karltheawesome | cool, I'll try to take a look at that soon | 07:56 |
| mithro | karltheawesome: No hurry, we tend to be more slow & steady style progress | 08:03 |
| paddatrapper | mithro: 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 byte | 08:29 |
| paddatrapper | actually it is the first quater of the array | 08:30 |
| mithro | paddatrapper: Hrm? | 08:31 |
| mithro | paddatrapper: If you have an int32 array and you want to access it as bytes? | 08:31 |
| paddatrapper | mithro: unsigned char array | 08:32 |
| paddatrapper | I need the first byte | 08:33 |
| mithro | char == bytes | 08:33 |
| cr1901_modern | int * my_array_base; | 08:33 |
| cr1901_modern | size_t int_offset, char_offset; | 08:33 |
| cr1901_modern | unsigned char * byte_offset = ((unsigned char *) (my_array_base + int_offset)) + char_offset; | 08:33 |
| mithro | unsigned char a[4]; a[0] == first byte? | 08:33 |
| paddatrapper | mithro: ah yes thanks | 08:33 |
| mithro | paddatrapper: So that is just how arrays work? -- was the confusion that "unsigned char" == "byte" ? | 08:35 |
| paddatrapper | mithro: 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 error | 08:37 |
| mithro | paddatrapper: there is a write hi and write low macros | 08:38 |
| paddatrapper | mithro: I'm using them. I'm writing from the FIFO buffer to two ports to drive the slave FIFO | 08:39 |
| mithro | Put the code some where and I'll look at it? | 08:41 |
| paddatrapper | sure. I'll commit it now | 08:42 |
| paddatrapper | mithro: https://github.com/paddatrapper/HDMI2USB-fx2-firmware/blob/audio-out/audio/out/app.c#L121 | 08:45 |
| tpb | Title: HDMI2USB-fx2-firmware/app.c at audio-out · paddatrapper/HDMI2USB-fx2-firmware · GitHub (at github.com) | 08:45 |
| paddatrapper | mithro: haven't tested it yet | 08:45 |
| cr1901_modern | mithro: Are you familiar with the SFL protocol? | 08:50 |
| mithro | cr1901_modern: Nope! | 08:52 |
| mithro | paddatrapper: are FDL and FDH FX2 special registers? | 08:53 |
| mithro | paddatrapper: Oh they are defines at the top | 08:54 |
| mithro | paddatrapper: BTW The FIFO can operate in both 8 and 16bit modes | 08:54 |
| cr1901_modern | mithro: 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_modern | I.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 |
| mithro | paddatrapper: So it looks like you are "bit-banging" the FIFO master? | 08:57 |
| paddatrapper | mithro: yup. Figured it would be easier to do 16 bit. If I run into issues I'll switch to 8bit | 08:57 |
| paddatrapper | mithro: where? | 08:57 |
| mithro | paddatrapper: Well, you manually reading from the endpoint buffer ram and writing it out to the FIFO checking the flags? | 08:58 |
| paddatrapper | mithro: no, I'm manually reading from FIFO buffer and writing to the FD output pins that drive the slave | 08:59 |
| mithro | paddatrapper: Your manually (IE CPU controlled) reading the data coming from the computer and writing to the output pins | 09:01 |
| paddatrapper | mithro: 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 pin | 09:02 |
| paddatrapper | mithro: ready for the hangout call when you are | 09:04 |
| mithro | paddatrapper: 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 all | 09:05 |
| paddatrapper | mithro: I definitely would much prefer that | 09:06 |
| mithro | When 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 data | 09:06 |
| paddatrapper | mithro: is this from the datasheet or the TRM? | 09:06 |
| mithro | paddatrapper: From the http://www.cypress.com/file/124536/download -- "Getting Started with EZ-USB® FX2LP™ GPIF" | 09:07 |
| paddatrapper | mithro: ah ok cool. I shall use that then | 09:08 |
| mithro | Okay, I'm heading to the VC room now, will be on the call in a second | 09:09 |
| mithro | paddatrapper: https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/firmware/fx2_fw_hdmi2usb.c | 09:23 |
| tpb | Title: HDMI2USB-litex-firmware/fx2_fw_hdmi2usb.c at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 09:23 |
| mithro | paddatrapper: https://github.com/timvideos/HDMI2USB-litex-firmware/tree/b50566518c649eec8f79c1b9e4ceecaa5dbf08a9/firmware | 09:25 |
| tpb | Title: HDMI2USB-litex-firmware/firmware at b50566518c649eec8f79c1b9e4ceecaa5dbf08a9 · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 09:25 |
| mithro | paddatrapper: https://github.com/timvideos/HDMI2USB-litex-firmware/blob/b50566518c649eec8f79c1b9e4ceecaa5dbf08a9/firmware/fx2/generate_fx2_microboot.py | 09:26 |
| tpb | Title: HDMI2USB-litex-firmware/generate_fx2_microboot.py at b50566518c649eec8f79c1b9e4ceecaa5dbf08a9 · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 09:26 |
| paddatrapper | mithro: https://docs.google.com/document/d/15oMrgGfgziHL9kqiRNEF34UaUKkOw0XkG7-D83iEM1s/edit#heading=h.iu3vz1p0u6k2 | 09:30 |
| tpb | Title: HDMI2USB FX2 Interface - Google Docs (at docs.google.com) | 09:30 |
| mithro | paddatrapper: Random VHDL -> https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/gateware/streamer/vhdl/fx2_jpeg_streamer.vhd | 09:33 |
| tpb | Title: HDMI2USB-litex-firmware/fx2_jpeg_streamer.vhd at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 09:34 |
| mithro | paddatrapper: https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/gateware/streamer/core.py#L7 | 09:34 |
| tpb | Title: HDMI2USB-litex-firmware/core.py at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 09:34 |
| paddatrapper | mithro: https://wiki.debian.org/Teams/DebConf/Video/VideoTeamDocs/NewVideoTeamHardware | 09:45 |
| tpb | Title: Teams/DebConf/Video/VideoTeamDocs/NewVideoTeamHardware - Debian Wiki (at wiki.debian.org) | 09:45 |
| mithro | paddatrapper: https://docs.google.com/drawings/d/1Rh614rAjMRT26e7i_79w6fem9ovUlgIZUD0SyDb0Hbg/edit | 09:45 |
| tpb | Title: Google Drawings - create diagrams and charts, for free. (at docs.google.com) | 09:45 |
| *** tangrs has quit IRC | 09:55 | |
| *** tangrs has joined #timvideos | 10:08 | |
| mithro | Ishan_Bansal: ping? | 10:23 |
| Ishan_Bansal | mithro : pong | 11:24 |
| mithro | Ishan_Bansal: how goes your final report | 11:24 |
| Ishan_Bansal | mithro : I am currently working on that only. | 11:25 |
| mithro | Ishan_Bansal: Okay - could you share it so we know you are going in the right direction | 11:25 |
| Ishan_Bansal | mithro : https://docs.google.com/document/d/1hXhApH3lDt4gT7ULloFavc0kUgBTPp0yphXEUjW9RKo/edit?usp=sharing | 11:26 |
| tpb | Title: GSOC Final Project Report - Google Docs (at docs.google.com) | 11:26 |
| Ishan_Bansal | mithro: Are the heading given are suitable ? | 11:29 |
| mithro | Ishan_Bansal: Yes, they are a good start | 11:29 |
| mithro | Ishan_Bansal: Until you have content its a bit hard to tell | 11:29 |
| Ishan_Bansal | mithro : Also apart from this is their a need of making an another documentation describing every module of the JPEG encoder ? | 11:30 |
| mithro | Ishan_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 transformed | 11:31 |
| mithro | Ishan_Bansal: All the low level details should be in the doc strings and stuff inside the code | 11:31 |
| Ishan_Bansal | mithro : 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 |
| mithro | Ishan_Bansal: The high level doc be a separate doc, but it is okay to reuse some of that doc in your end of GSoC report | 11:34 |
| Ishan_Bansal | mithro : If possible, where am I able to find the previous years final reports > | 11:38 |
| mithro | Ishan_Bansal: http://dreamsxtrinsic.blogspot.com.au/2014/08/gsoc-project-report-vga-capture.html | 11:39 |
| Ishan_Bansal | To get a brief overview of how it should be :) | 11:39 |
| tpb | Title: GSoC Project Report: VGA capture expansion board for HDMI2USB on Digilent Atlys | Dreams eXtrinsic (at dreamsxtrinsic.blogspot.com.au) | 11:39 |
| mithro | https://shashankgangrade.wordpress.com/gsoc-final/ | 11:39 |
| Ishan_Bansal | mithro : cool, that helps. Also finally I do not have to submit the doc ? | 11:41 |
| mithro | Ishan_Bansal: Hrm? | 11:41 |
| Ishan_Bansal | mithro : 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 |
| mithro | Yes, both of them wrote their doc in Google Docs and we reviewed them, putting comments on them and such | 11:44 |
| mithro | Then published them on their blog | 11:44 |
| Ishan_Bansal | mithro : May be by tomorrow I am able to show you a considerable progress on the Final Report . :) | 11:46 |
| mithro | Ishan_Bansal: Great! | 11:47 |
| Ishan_Bansal | mithro : In btw, I made the changes on the RLE so whenever you are free just review it once. | 11:48 |
| mithro | Okay, send a pull request for it? | 12:01 |
| cr1901_modern | mithro: Ping if you're still around (sorry I fell back to sleep) | 12:14 |
| mithro | cr1901_modern: I'm kinda still here... | 12:15 |
| cr1901_modern | mithro: I slept on it, so I just wanted to run something by you. | 12:16 |
| cr1901_modern | mithro: I think SFL should be implemented as-intended, where the data is written immediately, and the address to write is embedded in the protocol | 12:17 |
| cr1901_modern | mithro: 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_modern | Then 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_Bansal | mithro : The changes are been made on the previous pull request only. I am talking about this : https://github.com/timvideos/litejpeg/pull/2 | 12:27 |
| tpb | Title: Adding RLE-core module for JPEG encoder by ishan98 · Pull Request #2 · timvideos/litejpeg · GitHub (at github.com) | 12:27 |
| cr1901_modern | mithro: I'll do what you want me to do, but I feel more comfortable with the former solution (implement as-intended). | 12:28 |
| mithro | cr1901_modern: you got some docs to back up your claim? | 12:28 |
| cr1901_modern | mithro: Just reading the source of flterm https://github.com/m-labs/milkymist/blob/master/tools/flterm.c and https://github.com/m-labs/milkymist/blob/master/tools/sfl.h | 12:32 |
| tpb | Title: milkymist/flterm.c at master · m-labs/milkymist · GitHub (at github.com) | 12:32 |
| cr1901_modern | https://github.com/m-labs/milkymist/blob/master/tools/flterm.c#L241-L245 | 12:32 |
| tpb | Title: milkymist/flterm.c at master · m-labs/milkymist · GitHub (at github.com) | 12:32 |
| cr1901_modern | cmdline_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 payload | 12:33 |
| cr1901_modern | mithro: https://github.com/m-labs/milkymist/blob/master/tools/flterm.c#L282-L288 SFL_CMD_JUMP has a frame length of 4. It's an address to jump to, based on the printf statement | 12:40 |
| tpb | Title: milkymist/flterm.c at master · m-labs/milkymist · GitHub (at github.com) | 12:40 |
| cr1901_modern | SLF_CMD_JUMP, SFL_CMD_LOAD and SFL_CMD_ABORT are all I have to support; the remaining commands don't make sense for HDMI2USB | 12:40 |
| mithro | I'll take a closer look tomorrow | 12:42 |
| *** rohitksingh_work has quit IRC | 12:43 | |
| cr1901_modern | mithro: All I can ask for, thanks. In the meantime, I'll take a look at QEMU's timer | 12:43 |
| *** rohitksingh has joined #timvideos | 13:44 | |
| *** rohitksingh has quit IRC | 19:37 | |
| *** nueces has joined #timvideos | 20:55 | |
| *** sb0 has joined #timvideos | 22:48 | |
| *** nueces has quit IRC | 23:31 | |
| *** CarlFK has quit IRC | 23:51 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!