*** tpb has joined #timvideos | 00:00 | |
mithro | paddatrapper: awesome! | 00:20 |
---|---|---|
mithro | Ishan_Bansal: you want a special type of thing that I can't recall the name off | 00:21 |
*** ivodd has quit IRC | 01:45 | |
*** ivodd has joined #timvideos | 01:45 | |
*** hyadez has joined #timvideos | 02:11 | |
*** sb0 has joined #timvideos | 02:16 | |
*** CarlFK has quit IRC | 02:18 | |
*** CarlFK has joined #timvideos | 02:21 | |
*** ChanServ sets mode: +v CarlFK | 02:21 | |
*** rohitksingh_work has joined #timvideos | 03:42 | |
*** SamSagaZ has joined #timvideos | 04:22 | |
Ishan_Bansal | This is the code for the respective module dc_rom : https://pastebin.com/6EpU9Jgk | 04:24 |
tpb | Title: [Python] from litex.gen import * from litex.soc.interconnect.stream import * from litej - Pastebin.com (at pastebin.com) | 04:24 |
Ishan_Bansal | and the corresponding value of the address comes from the testbench as https://pastebin.com/v6rUD4cT | 04:27 |
tpb | Title: [Python] def main_generator(dut): yield dut.addr.eq(4) - Pastebin.com (at pastebin.com) | 04:27 |
Ishan_Bansal | CarlFK : ping | 05:00 |
shenki | Ishan_Bansal: can you commit all your code and push it to github? | 05:10 |
shenki | Ishan_Bansal: i would like to reproduce your error here to help you debug | 05:11 |
shenki | put it in a temporary branch if it is not ready to be published | 05:11 |
Ishan_Bansal | shenki : I have added the code for dc_rom.py and new_rom_tb.py | 05:27 |
Ishan_Bansal | https://github.com/ishan98/litejpeg/tree/huffman/litejpeg/core/huffman | 05:28 |
tpb | Title: litejpeg/litejpeg/core/huffman at huffman · ishan98/litejpeg · GitHub (at github.com) | 05:28 |
shenki | $ PYTHONPATH=../ python3 new_rom_tb.py | 05:51 |
shenki | Traceback (most recent call last): | 05:51 |
shenki | File "new_rom_tb.py", line 7, in <module> | 05:51 |
shenki | from litejpeg.core.huffman.dc_rom import dc_rom | 05:51 |
shenki | File "/home/joel/dev/timvideos/litejpeg/litejpeg/core/huffman/dc_rom.py", line 5, in <module> | 05:51 |
shenki | from litejpeg.core.huffman.tablebuilder import build_huffman_rom_tables | 05:51 |
shenki | ImportError: No module named 'litejpeg.core.huffman.tablebuilder' | 05:51 |
shenki | Ishan_Bansal: what am I doing wrong? :) | 05:52 |
mithro | Ishan_Bansal: You want to just use a memory object for what you are doing | 05:52 |
Ishan_Bansal | mithro : I don't want to use memory object in this case, I am currently trying with arrays. | 05:54 |
mithro | Ishan_Bansal: Why don't you want to use a memory object? | 05:55 |
Ishan_Bansal | shenki : can you try to run only dc_rom.py once. | 05:55 |
Ishan_Bansal | mithro : I talked to sb0 regarding this error and he told me that the arrays are specially designed for taking signals as index so thats why I am wondering what is the problem in this. It is not that I don't want to use the memory element just want to try with arrays. :) | 06:00 |
mithro | Ishan_Bansal: But you aren't using an array here at all? | 06:01 |
mithro | You are using a Python List | 06:01 |
mithro | Ishan_Bansal: http://m-labs.hk/migen/manual/reference.html#migen.fhdl.structure.Array | 06:02 |
tpb | Title: API reference Migen 0.5.dev0 documentation (at m-labs.hk) | 06:02 |
Ishan_Bansal | Oh sorry, the above code is the one of the first try. The new code of the dc_rom.py is : https://github.com/ishan98/litejpeg/blob/huffman/litejpeg/core/huffman/dc_rom.py | 06:07 |
tpb | Title: litejpeg/dc_rom.py at huffman · ishan98/litejpeg · GitHub (at github.com) | 06:07 |
Ishan_Bansal | mithro : ping | 06:08 |
Ishan_Bansal | shenki : Is the error while running dc_rom.py is the same ? | 06:09 |
mithro | Ishan_Bansal: What is the error when running dc_rom.py? | 06:09 |
Ishan_Bansal | mithro : https://pastebin.com/20dvdBhj | 06:11 |
tpb | Title: Traceback (most recent call last): File "new_rom_tb.py", line 26, in - Pastebin.com (at pastebin.com) | 06:11 |
mithro | Ishan_Bansal: You are trying to assign a string which contains a single ASCII character 0 to a Signal | 06:12 |
mithro | My guess is that you are not converting the strings to integers when reading them from the source file | 06:12 |
Ishan_Bansal | mithro : That worked. :) | 06:15 |
mithro | Ishan_Bansal: Although, I'm still pretty certain you want to use a Memory object here.... | 06:18 |
Ishan_Bansal | mithro : Is it because the data we want to store is fixed. | 06:26 |
mithro | Ishan_Bansal: Sure, memory objects can be read only | 06:28 |
mithro | Ishan_Bansal: The big question is if you need multiple values from the table at one time | 06:28 |
shenki | Ishan_Bansal: yes, the smae error | 06:29 |
shenki | $ PYTHONPATH=. python3 litejpeg/core/huffman/dc_rom.py | 06:30 |
shenki | Traceback (most recent call last): | 06:30 |
shenki | File "litejpeg/core/huffman/dc_rom.py", line 5, in <module> | 06:30 |
shenki | from litejpeg.core.huffman.tablebuilder import build_huffman_rom_tables | 06:30 |
shenki | ImportError: No module named 'litejpeg.core.huffman.tablebuilder' | 06:30 |
Ishan_Bansal | shenki : just check if the module named tablebuilder is present in the the litejpeg/core/huffman directory | 06:40 |
Ishan_Bansal | shenki : if the module is present you can try after once running the setup.py present along with the litejpeg directory, may be the litejpeg is not added to the pythonpath. | 06:44 |
Ishan_Bansal | mithro : No, I didn't think their is need of the multiple values at a time as the data inside the memory is the one which is for the encoding of the given input from the rle, hence their is a need of a single value per input. | 06:48 |
mithro | Ishan_Bansal: I wonder if it could even be stored in external DDR | 06:50 |
*** CarlFK has quit IRC | 06:51 | |
shenki | $ git grep tablebuilder | 06:57 |
shenki | litejpeg/core/huffman/dc_rom.py:from litejpeg.core.huffman.tablebuilder import build_huffman_rom_tables | 06:57 |
shenki | Ishan_Bansal: it does not exist. did you forget to commit a file? | 06:58 |
shenki | Ishan_Bansal: what does git status show? | 06:58 |
Ishan_Bansal | shenki : I have added the file. Sorry about that. | 07:02 |
Ishan_Bansal | thanks for telling | 07:02 |
shenki | Ishan_Bansal: no worries | 07:03 |
shenki | you should add genearted and temporary files to .gitignore | 07:04 |
shenki | that way, when you type 'git status' you should not see any untracked files | 07:04 |
shenki | it is a good way to ensure you have committed all of your changes | 07:04 |
Ishan_Bansal | shenki : I will take care of that. | 07:06 |
*** CarlFK has joined #timvideos | 07:16 | |
*** ChanServ sets mode: +v CarlFK | 07:16 | |
Ishan_Bansal | mithro : creating the memory element stores the data in the SRAM. | 07:28 |
mithro | SRAM == blockram in the FPGA != Off chip DDR RAM | 07:28 |
shenki | in english | 07:33 |
shenki | SRAM is the BRAM (block RAM) in the FPGA fabric | 07:33 |
shenki | DDR is the off-FPGA memory | 07:33 |
Ishan_Bansal | So DDR must be slow as compared to the SRAM. | 07:36 |
mithro | Ishan_Bansal: depends on how you define slow, SRAM has low latency but is very small in size, DDR has high latency but is megabytes in size | 07:37 |
shenki | Ishan_Bansal: correct, ddr is very very slow compared to sram | 07:39 |
shenki | single clock cycles vs 1000s of clock cycles | 07:39 |
shenki | i did my honours project on this subject :D | 07:40 |
mithro | shenki: Except if you try to have a multiple megabytes of SRAM on the Spartan 6 you maximum cycle rate is going to be like 2Hz | 07:42 |
shenki | yes. there are lots of exceptions | 07:43 |
shenki | https://jms.id.au/~joel/latency.png | 07:43 |
mithro | Also totally depends if this is critical path latency or not | 07:44 |
mithro | paddatrapper: Morning? | 07:59 |
paddatrapper | mithro: morning | 07:59 |
Ishan_Bansal | In this case since the data we need to store is not that large so I think size is not an issue. | 08:00 |
paddatrapper | mithro: trying to join the chat with no success | 08:01 |
mithro | Ishan_Bansal: potentially, however it's something to think about | 08:01 |
mithro | paddatrapper: I'm just trying to get readthedocs working with doxygen | 08:02 |
paddatrapper | mithro: cool no worries | 08:02 |
mithro | https://readthedocs.org/projects/mithro-fx2-firmware/builds/5714585/ | 08:02 |
mithro | doxygenclass: Cannot find file: /home/docs/checkouts/readthedocs.org/user_builds/mithro-fx2-firmware/checkouts/latest/docs/doxyxml/index.xml | 08:03 |
mithro | http://mithro-fx2-firmware.readthedocs.io/en/latest/ | 08:03 |
tpb | Title: HDMI2USB FX2 Firmware HDMI2USB FX2 Firmware 1.0.0 documentation (at mithro-fx2-firmware.readthedocs.io) | 08:03 |
mithro | paddatrapper: Weekly report look okay | 08:04 |
mithro | paddatrapper: Do you want to try to debug your interrupt problem? | 08:05 |
paddatrapper | mithro: Yeah I'm stuck as to what to try next - It's clear the interrupts are an issue, however everything I've done hasn't helped | 08:07 |
mithro | paddatrapper: So first, describe what you are seeing | 08:08 |
paddatrapper | mithro: If ENABLE_USBRESET() and ENABLE_HISPEED() are called, the firmware crashes on EA=1 (allow interrupts) | 08:09 |
mithro | paddatrapper: define "crash"? | 08:09 |
paddatrapper | if they are commented out, so the only enabled interrupt is SUDAV (setup data available), then the firmware runs, but the sudav interrupt is never called | 08:10 |
paddatrapper | mithro: crash meaning the following line is never called, nor are any of the interrupt handlers | 08:10 |
paddatrapper | it also crashes if only one (ENABLE_USBRESET() or ENABLE_HISPEED()) is called | 08:13 |
mithro | What code / branch should I be looking at? | 08:14 |
paddatrapper | mithro: https://github.com/paddatrapper/HDMI2USB-fx2-firmware/blob/audio-data/audio/firmware.c | 08:15 |
tpb | Title: HDMI2USB-fx2-firmware/firmware.c at audio-data · paddatrapper/HDMI2USB-fx2-firmware · GitHub (at github.com) | 08:15 |
mithro | paddatrapper: So, the first thing I would want to check is to see what interrupt handlers you have | 08:19 |
paddatrapper | mithro: sudav_isr, usbreset_isr and hispeed_isr | 08:19 |
mithro | paddatrapper: You want to go lower level than that and see what the compiler is putting at the ISR locations | 08:19 |
paddatrapper | audio.map:C: 00001D5C _sudav_isr firmware | 08:20 |
paddatrapper | firmware.rst: 00006B 02 1D 5C [24] 886 ljmp _sudav_isr | 08:22 |
paddatrapper | mithro: and the _sudav_isr assembly is correct for what is being done | 08:24 |
mithro | paddatrapper: So, is the that in the right location for sudav_isr ? | 08:25 |
mithro | paddatrapper: are any of the other ISR's blank? | 08:27 |
paddatrapper | mithro: not that I can see | 08:30 |
mithro | paddatrapper: So what do you do in your ISR? | 08:30 |
paddatrapper | though should theses be different: | 08:30 |
paddatrapper | firmware.lst: 0008F1 2685 _hispeed_isr | 08:30 |
paddatrapper | audio.map:C: 00001E20 _hispeed_isr firmware | 08:30 |
paddatrapper | firmware.rst: 001E20 2685 _hispeed_isr: | 08:31 |
paddatrapper | mithro: https://github.com/paddatrapper/HDMI2USB-fx2-firmware/blob/audio-data/audio/firmware.c#L96 | 08:31 |
tpb | Title: HDMI2USB-fx2-firmware/firmware.c at audio-data · paddatrapper/HDMI2USB-fx2-firmware · GitHub (at github.com) | 08:31 |
paddatrapper | I haven't changed then from before when they worked, aside to add the printf for debugging | 08:32 |
mithro | paddatrapper: Where they printing before? | 08:32 |
paddatrapper | mithro: I added the printf since then, before they were simply executing | 08:33 |
mithro | paddatrapper: Are you sure? | 08:33 |
mithro | paddatrapper: They shouldn't be executing if you never enabled the interrupt? | 08:33 |
paddatrapper | added here: | 08:33 |
paddatrapper | https://github.com/paddatrapper/HDMI2USB-fx2-firmware/commit/a2161100e9fae591b82c6904c02a31882d967863 | 08:33 |
tpb | Title: audio: Debug interrupts · paddatrapper/HDMI2USB-fx2-firmware@a216110 · GitHub (at github.com) | 08:33 |
paddatrapper | Before I changed the descriptors, the interrupts were enabled and working | 08:34 |
paddatrapper | mithro: it was working as of | 08:35 |
paddatrapper | https://github.com/paddatrapper/HDMI2USB-fx2-firmware/commit/a4f6f29301d7567e3e853f3f12994de6a0f91e16 | 08:35 |
tpb | Title: audio: Make comments compatible with doxygen · paddatrapper/HDMI2USB-fx2-firmware@a4f6f29 · GitHub (at github.com) | 08:35 |
mithro | paddatrapper: Have you tried setting the LEDs in the ISR? | 08:36 |
paddatrapper | mithro: yup, they don't light up | 08:37 |
mithro | paddatrapper: So when you enable the interrupts, any interrupts which are currently pending will fire | 08:38 |
paddatrapper | so either none are pending, or the handlers are not linked correctly | 08:40 |
mithro | paddatrapper: So, if the next command after enabling the interrupts is turning on a light and you don't see that the CPU has obviously jumped into one of the ISRs | 08:40 |
paddatrapper | mithro: then it is a handler implemented in the fx2lib, all three handlers I implement are supposed to light an led | 08:41 |
mithro | paddatrapper: take a look at https://github.com/mithro/fx2lib/tree/master/lib/interrupts | 08:44 |
tpb | Title: fx2lib/lib/interrupts at master · mithro/fx2lib · GitHub (at github.com) | 08:44 |
mithro | paddatrapper: You also want to check that you are putting your interrupts at a valid location | 08:45 |
mithro | paddatrapper: That is what the "check_int2jt" target in the hdmi2usb makefile is doing | 08:45 |
mithro | https://www.irccloud.com/pastebin/oceyxiRB/ | 08:45 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 08:45 |
paddatrapper | mithro: I can find the INT2VEC Value that each vector is supposed to have, but not their memory location | 08:46 |
mithro | paddatrapper: https://github.com/mithro/fx2lib/blob/master/include/autovector.h | 08:46 |
tpb | Title: fx2lib/autovector.h at master · mithro/fx2lib · GitHub (at github.com) | 08:46 |
paddatrapper | mithro: INT2JT at 0x3f3e but requested 0x3f00 | 08:46 |
mithro | paddatrapper: welp, that is not going to work :-P | 08:46 |
mithro | paddatrapper: You have NFI how long it took me to figure out that issue :-P | 08:47 |
paddatrapper | I'm sure! How do I fix it? | 08:47 |
mithro | paddatrapper: you have too much data that needs to fit before the interrupt vector | 08:48 |
paddatrapper | mithro: i.e the descriptors are too big? | 08:48 |
mithro | look at the map file | 08:48 |
mithro | The map file describes where the linker ended up putting everything | 08:50 |
mithro | paddatrapper: You only get 16k of space to store all code and data - so enabling to many printf's can quickly run you out of memory | 08:51 |
paddatrapper | mithro: even building without debug enabled has the issue | 08:51 |
paddatrapper | with exactly the same memory offset | 08:52 |
mithro | paddatrapper: If you try and put multiple things at the location it will go wrong too | 08:52 |
paddatrapper | shouldn't that be a linker error? | 08:53 |
mithro | paddatrapper: For some reason no, it just cats them together | 08:53 |
mithro | paddatrapper: Looking at the audio.lk file | 08:54 |
mithro | you have | 08:54 |
mithro | -X 0x0200 | 08:54 |
mithro | -C 0x3c00 | 08:54 |
mithro | -b HOME = 0x0000 | 08:54 |
mithro | -b XSEG = 0x3c00 | 08:54 |
mithro | -b PSEG = 0x3c00 | 08:54 |
mithro | -b ISEG = 0x0000 | 08:54 |
mithro | -b BSEG = 0x0000 | 08:54 |
mithro | -b INT2JT=0x3f00 | 08:54 |
mithro | It's likely the XSET/PSEG is overflowing... | 08:57 |
mithro | -X says the xdata segment should be 512 bytes | 08:57 |
mithro | Hrm... | 08:58 |
mithro | hex(0x3c00 + 0x0200) == '0x3e00' | 08:58 |
paddatrapper | 00003C00 s_PSEG | 08:59 |
paddatrapper | 00003C00 s_XISEG | 08:59 |
paddatrapper | 00003C00 s_XSEG | 09:00 |
mithro | paddatrapper: Yes, but how big are they? | 09:00 |
paddatrapper | Next thing is 00003F3E s_INT2JT | 09:01 |
paddatrapper | so I guess hex(0x3f3e - 0x3c00) == 0x033e | 09:02 |
mithro | Oh... | 09:02 |
mithro | It's the descriptors... | 09:02 |
paddatrapper | It's always the descriptors :) | 09:02 |
mithro | C: 00003E00 _code_descriptors descriptors | 09:03 |
paddatrapper | mithro: reducing the device strings helped, so I need to reduce the descriptors size | 09:06 |
paddatrapper | hmm... | 09:06 |
mithro | paddatrapper: So, I can't build your committed stuff | 09:07 |
mithro | DMI2USB-fx2-firmware/audio$ make | 09:07 |
mithro | cd ../third_party/fx2lib/lib/ && make -j1 | 09:07 |
mithro | make[1]: Entering directory `/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/fx2/HDMI2USB-fx2-firmware/third_party/fx2lib/lib' | 09:07 |
mithro | make[1]: Nothing to be done for `all'. | 09:07 |
mithro | make[1]: Leaving directory `/usr/local/google/home/tansell/foss/timvideos/hdmi2usb/fx2/HDMI2USB-fx2-firmware/third_party/fx2lib/lib' | 09:07 |
mithro | CC descriptors.rel | 09:07 |
mithro | In file included from descriptors.c:23: | 09:07 |
mithro | descriptors.h:26:25: error: audio-extra.h: No such file or directory | 09:07 |
mithro | ../third_party/fx2lib-linux-headers/audio.h:269: warning 116: left shifting more than size of object changed to zero | 09:07 |
mithro | ../third_party/fx2lib-linux-headers/audio.h:270: warning 116: left shifting more than size of object changed to zero | 09:07 |
mithro | ../third_party/fx2lib-linux-headers/audio.h:353: warning 116: left shifting more than size of object changed to zero | 09:07 |
mithro | ../third_party/fx2lib-linux-headers/audio.h:354: warning 116: left shifting more than size of object changed to zero | 09:07 |
mithro | descriptors.c:91: error 20: Undefined identifier 'UAC_BCD_V10' | 09:07 |
mithro | descriptors.c:122: error 20: Undefined identifier 'UAC_OUTPUT_TERMINAL_STREAMING' | 09:07 |
mithro | descriptors.c:225: error 20: Undefined identifier 'UAC_BCD_V10' | 09:07 |
mithro | descriptors.c:256: error 20: Undefined identifier 'UAC_OUTPUT_TERMINAL_STREAMING' | 09:07 |
mithro | descriptors.c:91: error 2: Initializer element is not constant | 09:07 |
mithro | descriptors.c:122: error 2: Initializer element is not constant | 09:07 |
mithro | descriptors.c:225: error 2: Initializer element is not constant | 09:07 |
mithro | descriptors.c:256: error 2: Initializer element is not constant | 09:07 |
mithro | make: *** [descriptors.rel] Error 1 | 09:07 |
mithro | tansell@tansell:~/foss/timvideos/hdmi2usb/fx2/HDMI2USB-fx2-firmware/audio$ git status -v | 09:07 |
mithro | On branch audio-data | 09:07 |
mithro | Your branch is up-to-date with 'padda/audio-data'. | 09:07 |
mithro | nothing to commit, working tree clean | 09:07 |
mithro | gah | 09:07 |
mithro | That was suppose to go to the pastebin | 09:07 |
paddatrapper | mithro: there's supposed to be a PR against the linux headers for that... | 09:07 |
paddatrapper | Seems I forgot to open it | 09:08 |
mithro | paddatrapper: You can move the descriptors down | 09:09 |
paddatrapper | PR opened https://github.com/mithro/fx2lib-linux-headers/pull/2 | 09:09 |
tpb | Title: Add extra audio defines by paddatrapper · Pull Request #2 · mithro/fx2lib-linux-headers · GitHub (at github.com) | 09:09 |
paddatrapper | mithro: how? | 09:09 |
mithro | paddatrapper: I'll give ya 3 guesses :-P | 09:10 |
paddatrapper | mithro: using a macro in the c? (__at() or something similar) | 09:10 |
paddatrapper | I see we already define DSCR_AREA, so changing that | 09:11 |
mithro | Yeah | 09:12 |
mithro | However, I seem to recall the descriptors have to be within a given section of memory | 09:12 |
mithro | Go check the FX2 datasheet | 09:12 |
* paddatrapper checks... | 09:12 | |
mithro | paddatrapper: IIRC it's in the fine print somewhere really hard to find :-/ | 09:14 |
mithro | paddatrapper: We should document it somewhere.... | 09:14 |
paddatrapper | /descriptors in the TRM | 09:16 |
mithro | paddatrapper: I've found "The start address needs to be word-aligned" | 09:17 |
paddatrapper | mithro: the only descriptor memory location reference I've found was for GPIO waveform descriptors | 09:19 |
mithro | paddatrapper: Ahh ha! | 09:23 |
mithro | paddatrapper: https://github.com/mithro/fx2lib/commit/73ff37eb89ada05e755bec278fbea0c96e534b89 | 09:23 |
mithro | paddatrapper: Turns out past me actually did document it :-P | 09:24 |
paddatrapper | mithro: ok, so sudptr points to the descriptors? And that can be either in Main RAM or scratch RAM? | 09:27 |
mithro | SUDAV (Setup Data Available) | 09:28 |
mithro | SUDPTR (Setup Data Pointer) | 09:28 |
paddatrapper | mithro: I thought that was the initialisation data from the host | 09:28 |
mithro | Take a look at Table 2-2 "How the Firmware Handles USB Device Requests" | 09:29 |
mithro | paddatrapper: And maybe "Figure 2-5. Using Setup Data Pointer (SUDPTR) for Get_Descriptor Requests " | 09:30 |
paddatrapper | mithro: ah I see | 09:31 |
paddatrapper | So I can move descriptors to scratch RAM, at some address that is work aligned? | 09:32 |
mithro | paddatrapper: You should just be able to move the descriptors downwards it seems... | 09:35 |
mithro | Put them starting at 3D00 ? | 09:36 |
paddatrapper | passes the check | 09:38 |
paddatrapper | \o/ it works! | 09:38 |
paddatrapper | thanks for the help | 09:38 |
mithro | paddatrapper: Can you make your audio_extra.h a bit closer to the other xxx_extra.h files? | 09:39 |
paddatrapper | mithro: ure | 09:39 |
paddatrapper | s/ure/sure | 09:39 |
mithro | Hrm... | 09:39 |
mithro | Actually it seems like those files are a bit weird too :-P | 09:40 |
paddatrapper | how would you prefer them? | 09:40 |
paddatrapper | he firmware currently crashes pulse audio, which makes me happy | 09:41 |
paddatrapper | s/^/T/ | 09:42 |
mithro | paddatrapper: So that INT2JT should end up being in a common makefile somewhere | 09:42 |
* paddatrapper cannot type today... | 09:43 | |
paddatrapper | mithro: yeah. I want to re-work the Makefile.fx2, Makefile and {audio/hdmi2usb}/Makefile to simplify it all into a common base | 09:44 |
mithro | paddatrapper: Actually that might just be good to move into a python / shell script which checks things after compiler? | 09:44 |
paddatrapper | mithro: what do you mean? | 09:45 |
mithro | paddatrapper: "sdcc xxx.c; check.py" | 09:45 |
paddatrapper | ah I see. That may work better. Certainly more flexible | 09:46 |
mithro | That code is rather horrific shell :-P | 09:46 |
mithro | paddatrapper: You could also check that the descriptors are in a valid location | 09:46 |
mithro | And that | 09:46 |
mithro | Memory blocks 0xE200-0xE3FF, 0xE480-0xE4FF, 0xE700 0xE73F, and 0xE800-0xEFFF) are reserved; they must not be used for data storage. | 09:47 |
mithro | paddatrapper: One thing that makes sense to do, is remove the "low speed" descriptor -- as the device doesn't really function usefully at 12Mbit/second | 09:48 |
paddatrapper | mithro: the spec requires it | 09:49 |
mithro | paddatrapper: Drivers don't however :-P | 09:49 |
paddatrapper | I'll test that then :) | 09:49 |
mithro | paddatrapper: Actually you might be able to just put a small "does not work" type descriptor there... | 09:50 |
paddatrapper | It certainly doesn't require endpoints, terminals, etc | 09:50 |
mithro | micolous: ping? | 09:51 |
paddatrapper | mithro: I'll be back in a bit | 09:52 |
mithro | paddatrapper: Okay | 09:52 |
xfxf | jea: i'm not intending on reimaging the existing machines; i'm hesitant to move distro immediately before an event + have used the laptop for a handful of other events since. plus I sunk about a day and a half trying to do the ansible stuff and it seems broken for me now. haven't yet tried CarlFK's new installer, it's down the priority list, a million other things to do | 09:55 |
xfxf | that said, if you use the new ansible stuff for your conf successfully, would love to know info | 09:56 |
xfxf | i just noticed a handful of problems with it (i.e. things I'd do differently) and decided not to go down that path given I already have working machines | 09:56 |
xfxf | i'll poke CarlFK at some point and work through it, just again, too many things to juggle, strategically picking what makes sense | 09:57 |
xfxf | my intention for the ansible stuff was to actually not have to ever re-image the machines from a USB stick, just run ansible on them before every event to get the latest toys :/ | 09:58 |
xfxf | (which given can probably still happen, but it means moving away from a known/proven working ubuntu install to a debian one. which probably isn't a big deal, but i'm playing this conservatively given there's other improvements i'm focussing on) | 10:01 |
Ishan_Bansal | Hey I am getting an error while executing the test bench : https://pastebin.com/1tD7jhB8 | 10:19 |
Ishan_Bansal | the error on executing is : https://pastebin.com/GSrn69Cb | 10:19 |
tpb | Title: [Python] from litex.gen import * from litex.soc.interconnect.stream import * from lit - Pastebin.com (at pastebin.com) | 10:19 |
tpb | Title: Traceback (most recent call last): File "new_rom_tb.py", line 29, in - Pastebin.com (at pastebin.com) | 10:19 |
mithro | Ishan_Bansal: I'm guessing that your dc_rom function is returning None | 10:21 |
Ishan_Bansal | I think there is something wrong on how the testBench is been connected to the submodule but I am not able to figure out what ? | 10:21 |
mithro | Ishan_Bansal: I'm guessing it's line 16 -- self.submodules.dc_rom = dc_rom(self,self.addr,self.data,self.data_size) | 10:22 |
mithro | Ishan_Bansal: Infact if it's the code at https://github.com/ishan98/litejpeg/blob/huffman/litejpeg/core/huffman/dc_rom.py then you can't do what you are doing... | 10:23 |
tpb | Title: litejpeg/dc_rom.py at huffman · ishan98/litejpeg · GitHub (at github.com) | 10:23 |
Ishan_Bansal | mithro : No the code is as follows : https://pastebin.com/0z1Sp4hj | 10:24 |
tpb | Title: [Python] from litex.gen import * from litex.soc.interconnect.stream import * from litej - Pastebin.com (at pastebin.com) | 10:24 |
mithro | Ishan_Bansal: That is just a function, not a proper migen module | 10:24 |
Ishan_Bansal | mithro : whats the thing that doesn't make it as a module ? | 10:27 |
mithro | Ishan_Bansal: 'def xxx():' creates a Python function, 'class A(Module):' creates a module | 10:27 |
mithro | Ishan_Bansal: Look at your other code | 10:27 |
Ishan_Bansal | I think getting a lot of confusion due to this previously also. | 10:27 |
mithro | Ishan_Bansal: See https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/gateware/i2c.py#L34-L40 | 10:28 |
tpb | Title: HDMI2USB-litex-firmware/i2c.py at master · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 10:28 |
Ishan_Bansal | mithro : so If I create a class out of this and write all this stuff in the def__init__()so that is sufficient to make it as a module. | 10:36 |
mithro | Ishan_Bansal: Yes, you are creating a Python class | 10:36 |
Ishan_Bansal | Also what is the difference in adding a submodule and calling a function ? | 10:36 |
mithro | Ishan_Bansal: Do you know about Object Oriented Programming? (OOP) | 10:37 |
Ishan_Bansal | mithro : I used python for about two sems. Ok, submodule is like creating an object. | 10:40 |
paddatrapper | mithro: It is now a working audio device that pulse picks up and reads data from | 10:40 |
mithro | Ishan_Bansal: Creating an "instance" of a "class" | 10:42 |
mithro | paddatrapper: BTW Have you seen http://mithro.github.io/fx2lib/eputils_8h.html ? | 10:47 |
tpb | Title: Fx2lib: include/eputils.h File Reference (at mithro.github.io) | 10:47 |
paddatrapper | mithro: I use RESETTOGGLE and RESETFIFO from there, yeah | 11:01 |
mithro | paddatrapper: I mean more the generated docs | 11:01 |
paddatrapper | Ah yes! Awesome | 11:02 |
paddatrapper | mithro: want me to implement the same for the fx2 firmware? | 11:03 |
paddatrapper | mithro: also could you review PR #23, #27 and #32 in the fx2 firmware? | 11:06 |
paddatrapper | https://github.com/timvideos/HDMI2USB-fx2-firmware/pull/23 | 11:06 |
tpb | Title: Audio descriptors by paddatrapper · Pull Request #23 · timvideos/HDMI2USB-fx2-firmware · GitHub (at github.com) | 11:06 |
paddatrapper | https://github.com/timvideos/HDMI2USB-fx2-firmware/pull/27 | 11:06 |
tpb | Title: examples/lights: Add support for other boards by paddatrapper · Pull Request #27 · timvideos/HDMI2USB-fx2-firmware · GitHub (at github.com) | 11:06 |
paddatrapper | https://github.com/timvideos/HDMI2USB-fx2-firmware/pull/32 | 11:06 |
tpb | Title: Move lights header to common directory by paddatrapper · Pull Request #32 · timvideos/HDMI2USB-fx2-firmware · GitHub (at github.com) | 11:06 |
xfxf | jea: that said, i have some new machines, we might try giving those an image on wed night or thu, but will play it by ear. certainly the main mixing machines at least will be based on the LCA install (with a few updates I've added) | 11:17 |
xfxf | i.e. be nice to stick the little embedded x86 boards i have into a opsis case, for under the podiums | 11:17 |
*** rohitksingh_work has quit IRC | 11:59 | |
*** rohitksingh_work has joined #timvideos | 12:05 | |
*** rohitksingh_work has quit IRC | 12:10 | |
Ishan_Bansal | mithro : The rom and the test bench worked, also one silly but great doubt about submodule is now clear. | 12:24 |
Ishan_Bansal | Feeling Amazing :P | 12:24 |
*** rohitksingh has joined #timvideos | 13:30 | |
CarlFK | xfxf: jea: test the damm ansible :p | 14:20 |
CarlFK | and to do that, you need a box you can test on, and maybe brick, which is fine if you have a way to wipe/install the OS. like the usb stick | 14:21 |
CarlFK | you dont *need* the usb stick, but you need something, and that is kinda the obvious choice | 14:22 |
CarlFK | mithro: make symlinks | 14:23 |
*** rohitksingh has quit IRC | 17:55 | |
*** CarlFK has quit IRC | 19:06 | |
*** CarlFK has joined #timvideos | 19:56 | |
*** ChanServ sets mode: +v CarlFK | 19:56 | |
*** CarlFK has quit IRC | 20:54 | |
*** CarlFK has joined #timvideos | 21:16 | |
*** ChanServ sets mode: +v CarlFK | 21:16 | |
*** CarlFK has quit IRC | 22:53 | |
*** CarlFK has joined #timvideos | 22:53 | |
*** ChanServ sets mode: +v CarlFK | 22:53 | |
*** tvCommitBot has joined #timvideos | 23:51 | |
-tvCommitBot- [av-foss-stack] CarlFK created pyohio (+1 new commit): https://git.io/v7J1c | 23:51 | |
-tvCommitBot- av-foss-stack/pyohio f49c7d0 Carl Karsten: A branch for a show let's go | 23:51 | |
*** tvCommitBot has left #timvideos | 23:51 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!