Monday, 2020-10-12

« Sunday, 2020-10-11 Index Tuesday, 2020-10-13 »
*** tpb has joined #tomu00:00
*** Toba has quit IRC02:16
*** Toba has joined #tomu02:17
*** Toba is now known as Guest41102:17
*** wrtlprnft has quit IRC03:29
*** wrtlprnft has joined #tomu03:30
im-tomu[tcal-x] Has anyone seen the following behavior in a Fomu -- the normal output from `dfu-util -l` looks like04:20
im-tomu```04:20
im-tomuFound DFU: [1209:5bf0] ver=0101, devnum=12, cfg=1, intf=0, path="1-2.1", alt=0, name="Fomu PVT running DFU Bootloader v2.0.3", serial="UNKNOWN"04:20
im-tomu```04:20
im-tomubut with the one I'm using now, about 25% of the time I get04:20
im-tomu```04:20
im-tomuFailed to retrieve string descriptor 204:20
im-tomuFound DFU: [1209:5bf0] ver=0101, devnum=12, cfg=1, intf=0, path="1-2.1", alt=0, name="UNKNOWN", serial="UNKNOWN"04:20
im-tomu```04:20
im-tomuand 1% of the time I get04:20
im-tomu```04:20
im-tomuPatching string descriptor 2 length (was 4, received 0)04:20
im-tomu[umarcor] @tcal-x, I can confirm the behaviour on Windows 10.04:29
im-tomu[umarcor] Not consistent at all, tho. Most of the time it works. That's something I get if I plug the Fomu and I try to "read" it too fast.04:30
im-tomu[umarcor] Just need to wait a few seconds for the OS and the board to communicate properly.04:31
im-tomu[umarcor] ```04:32
im-tomu$ dfu-utl -l04:32
im-tomu...04:32
im-tomuString descriptor 2 too short04:32
im-tomuFound DFU: [1209:5bf0] ver=0101, devnum=12, cfg=1, intf=0, path="1-8", alt=0, name="UNKNOWN", serial="UNKNOWN"04:32
im-tomu$ dfu-utl -l04:32
im-tomu...04:32
im-tomuFound DFU: [1209:5bf0] ver=0101, devnum=12, cfg=1, intf=0, path="1-8", alt=0, name="Fomu PVT running DFU Bootloader v2.0.3", serial="UNKNOWN"04:32
im-tomu```04:32
im-tomu[tcal-x] Yes, it did seem to be a timing thing.04:32
im-tomu[umarcor] We are dealing with a very low power device after all (considering it needs to handle USB).04:33
im-tomu[tcal-x] But I'm seeing this with repeated `dfu-util -l`, without unplugging or anything like that.   Actually, I have a Fomu that seems to be behaving better in this regard.   Let me to a few hundred `dfu-util -l` on that one and see what happens...04:34
im-tomu[umarcor] Just in case, do clean the USB pads and ensure that the board fits well in the port.04:35
im-tomu[tcal-x] Ok, I just did 100 queries on the **other** Fomu, and -no- cases of "Failed to retrieve...".04:39
*** Guest411 is now known as Toba05:44
*** Toba has joined #tomu05:44
*** mtretter has joined #tomu07:25
*** alexhw_ has quit IRC10:30
*** alexhw has joined #tomu10:30
*** im-tomu has left #tomu11:03
*** im-tomu has joined #tomu11:03
mithroDo we know any VHDL supporters who could review https://github.com/im-tomu/fomu-workshop/pull/338 ?11:19
tpbTitle: Add Mixed HDL Blink example by umarcor · Pull Request #338 · im-tomu/fomu-workshop · GitHub (at github.com)11:19
mithroumarcor: Looks like you have been smashing out the pull requests over the weekend!11:23
im-tomu[umarcor] I was :blush:. It's a bank holiday in spain today, so it was a longer weekend :D11:57
im-tomu[umarcor] I'll ping some users from the GHDL and VUnit camps.11:59
acathlaHi. What kind of mem (SPRAM) speed can we expect on the fomu with litex/vexriscv? Does 39KiB/s seems reasonable or way too slow?15:04
keesjwhat is this Connect to system clock (with buffering) part doing ? https://github.com/im-tomu/fomu-workshop/pull/338/files#diff-a43d63be270b33b4498d86fef447c8b3R2115:09
tpbTitle: Add Mixed HDL Blink example by umarcor · Pull Request #338 · im-tomu/fomu-workshop · GitHub (at github.com)15:09
*** jesse_m[m] has joined #tomu15:09
daveshahit's redundant, as nextpnr infers global buffers automatically15:10
daveshahbut equally, it makes the intent clear that it is a global clock so it isn't doing any harm, either15:10
im-tomu[umarcor] @keesj, that's directly copied from the existing Verilog example: https://github.com/im-tomu/fomu-workshop/blob/master/verilog/blink/blink.v#L44-L4915:13
tpbTitle: fomu-workshop/blink.v at master · im-tomu/fomu-workshop · GitHub (at github.com)15:13
im-tomu[umarcor] I agree that it's redundant, but my guess is that it's included for didactic purposes. It shows how to instantiate the most simple hard core. As an introduction to the RGBA driver instantiated later.15:14
keesjI was indeed also looking at that part. (still searching for the actual blink)15:14
im-tomu[umarcor] If you compare the VHDL example in #334, you will find that it's an equivalent to the Verilog only example.15:15
im-tomu[umarcor] In #338 I created a submodule containing the global buffer instantiation and a counter.15:15
daveshahYes, it is definitely a good example of using a hard core15:15
im-tomu[umarcor] But it's exactly the same code, copy pasted and moved to a separated file.15:16
im-tomu[umarcor] Again, only for didactic purposes.15:16
keesjIt is pretty cool (I did not know how to make custom stuff) but also perhaps .... when I think of blink.. I think of hello world but this indeed applies to the verilog examples aswell (hence not fair to talk about it now)15:16
keesjbut.. where is the logic to assing rgb0?15:18
im-tomu[umarcor] It comes from the RGBA driver.15:19
daveshahyeah, rgb0 is an output to the actual RGB pin15:19
im-tomu[umarcor] So, there is a counter, and 3 bits from the counter are used for driving the inputs of the RGBA driver.15:19
daveshahyeah15:19
im-tomu[umarcor] Then, the driver drives the actual pins (top-level outputs).15:19
keesjthe pwn inputs?15:19
daveshahyeah, that's a misnomer as they don't actually have to be PWM15:20
daveshahlattice just call them that because that is the expected use case15:20
daveshahRGB0IN would probably have been a better name15:20
keesjthanks I see15:43
*** mtretter has quit IRC16:23
*** lucab has quit IRC19:16
*** darkharmony9999[ has quit IRC19:16
*** psydroid has quit IRC19:16
*** promach3 has quit IRC19:16
*** xobs has quit IRC19:16
*** jimt[m] has quit IRC19:16
*** alexhw[m] has quit IRC19:16
*** leons has quit IRC19:16
*** js has quit IRC19:16
*** jesse_m[m] has quit IRC19:16
*** js has joined #tomu19:22
*** xobs has joined #tomu19:28
*** promach3 has joined #tomu19:28
*** leons has joined #tomu19:28
*** psydroid has joined #tomu19:28
*** darkharmony9999[ has joined #tomu19:28
*** jimt[m] has joined #tomu19:28
*** lucab has joined #tomu19:28
*** alexhw[m] has joined #tomu19:28
*** jesse_m[m] has joined #tomu19:28
*** mwalle has joined #tomu19:36
mithromwalle: Hi!19:36
mwallemithro: hi :p19:37
mwalledunni where in which channel i was previously19:37
mwalle*dunno19:37
mwalleso what does write protection mean? I saw there is a "booster"19:37
mithromwalle: No idea, ask xobs :-)19:41
mithromwalle: Updating the bootloader is a multi-stage process which tries very hard to not brick your device19:43
mwallemithro: yeah i read the doc on the booster, but that doesn't mean its write protected ;)19:43
mithromwalle: I thought xobs set the write protect in the SPI registers...19:44
mwallemithro: we'll see what xobs says. but I guess it is good enough, I was just worried to have it destroyed easily19:46
mwallewell.. you could flash it with the TPs19:46
mwallebut not that not so easily done at home ;)19:46
*** wrtlprnft has quit IRC22:16
*** wrtlprnft has joined #tomu22:17
*** deltab has quit IRC22:21
*** deltab has joined #tomu22:28
« Sunday, 2020-10-11 Index Tuesday, 2020-10-13 »

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!