*** tpb has joined #timvideos | 00:00 | |
*** Kripton has quit IRC | 00:45 | |
*** Kripton has joined #timvideos | 00:57 | |
*** Kripton has quit IRC | 02:15 | |
*** Kripton has joined #timvideos | 02:17 | |
*** futarisIRCcloud has joined #timvideos | 02:33 | |
futarisIRCcloud | tinyfpga: https://www.crowdsupply.com/tinyfpga/tinyfpga-ex looks good. When are the first prototypes expected? Happy to help out with the PCIe and/or USB3 bringup. I'm sure mithro, _florent_ and rohitksingh are also interested... | 02:48 |
---|---|---|
tpb | Title: TinyFPGA EX | Crowd Supply (at www.crowdsupply.com) | 02:48 |
*** techman83 has quit IRC | 03:47 | |
*** techman83 has joined #timvideos | 03:49 | |
*** ChanServ sets mode: +v techman83 | 03:49 | |
*** futarisIRCcloud has quit IRC | 05:03 | |
*** CarlFK has joined #timvideos | 06:10 | |
*** ChanServ sets mode: +v CarlFK | 06:10 | |
*** shorne has quit IRC | 08:36 | |
*** shorne has joined #timvideos | 08:38 | |
*** futarisIRCcloud has joined #timvideos | 08:49 | |
*** CarlFK has quit IRC | 09:10 | |
*** futarisIRCcloud has quit IRC | 10:58 | |
*** rohitksingh has joined #timvideos | 12:38 | |
*** rohitksingh has quit IRC | 12:49 | |
*** rohitksingh has joined #timvideos | 13:31 | |
*** futarisIRCcloud has joined #timvideos | 13:45 | |
*** rohitksingh has quit IRC | 14:19 | |
*** rohitksingh has joined #timvideos | 14:46 | |
*** CarlFK has joined #timvideos | 15:06 | |
*** ChanServ sets mode: +v CarlFK | 15:06 | |
*** mauz555 has joined #timvideos | 15:31 | |
*** futarisIRCcloud has quit IRC | 15:55 | |
*** mauz555 has quit IRC | 16:46 | |
*** rohitksingh has quit IRC | 16:52 | |
*** mauz555 has joined #timvideos | 17:09 | |
*** mauz555 has quit IRC | 17:18 | |
*** rohitksingh has joined #timvideos | 17:53 | |
*** mauz555 has joined #timvideos | 18:20 | |
*** mauz555 has quit IRC | 18:25 | |
*** mauz555 has joined #timvideos | 18:25 | |
*** ladyada has joined #timvideos | 18:30 | |
*** mauz555 has quit IRC | 18:48 | |
*** rohitksingh has quit IRC | 19:05 | |
*** mauz555 has joined #timvideos | 19:17 | |
*** rohitksingh has joined #timvideos | 20:18 | |
*** mauz555 has quit IRC | 20:30 | |
mithro | tannewt: so this is the interface so far; | 20:39 |
mithro | There is a 512byte buffer region which is memory mapped | 20:39 |
mithro | Each endpoint has 3 csr registers | 20:39 |
mithro | Pointer into the buffer region | 20:40 |
mithro | Length of packet | 20:40 |
mithro | Status | 20:40 |
mithro | You get an interrupt after a packet is sent or received | 20:41 |
tannewt | there is a shared region because pointer registers are expensive? | 20:41 |
mithro | tannewt: and there is no guarantee that the rest of the memory can respond fast enough | 20:42 |
tannewt | ah, ok | 20:42 |
mithro | That is the bigger problem | 20:42 |
tannewt | because the other memory is spram? | 20:42 |
mithro | I can possible fix that with a FIFO in a future revision | 20:42 |
mithro | tannewt: or external spiflash | 20:43 |
tannewt | I just added a makefile to the tinyusb example: https://github.com/hathach/tinyusb/pull/15 | 20:43 |
tpb | Title: Add Makefile support for the cdc_msc_hid example by tannewt · Pull Request #15 · hathach/tinyusb · GitHub (at github.com) | 20:43 |
tannewt | that sounds like a good start! | 20:43 |
mithro | It should be pretty easy to extend / change in the future | 20:44 |
mithro | My one concern is responding to requests on endpoint 0 | 20:44 |
mithro | As technically you are not suppose to NAK them... | 20:44 |
mithro | The core will NAK any requests on an endpoint until you rearm it after sending / receiving the packet | 20:46 |
tannewt | I think thats why nrf has a dedicated 8 byte buffer for setup packets | 20:50 |
tannewt | since you know the size of those packets | 20:50 |
mithro | The buffering into ram isn't the issue, it's the reaponse | 20:52 |
tannewt | just always write to ram and always ack | 20:55 |
mithro | Now I just need to get all the CDC stuff working | 20:59 |
*** mauz555 has joined #timvideos | 21:03 | |
tannewt | I'm gonna disappear to play games but I can help until then | 21:04 |
tannewt | actually starting to write tinyusb porting instructions now | 21:04 |
mithro | cr1901_modern: Could you take a look at https://github.com/enjoy-digital/litex/pull/128/files#diff-ea2d16df21001b97703890817ea0acb2 ? | 21:06 |
tpb | Title: Two small fixes by mithro · Pull Request #128 · enjoy-digital/litex · GitHub (at github.com) | 21:06 |
*** mauz555 has quit IRC | 21:08 | |
cr1901_modern | mithro: lgtm | 21:24 |
mithro | https://www.irccloud.com/pastebin/UeBvpuIW/ | 21:44 |
tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 21:44 |
mithro | cr1901_modern: Any idea what I'm doing wrong here? | 21:44 |
cr1901_modern | Probably missing a line like the following in your CRG(): https://github.com/timvideos/litex-buildenv/blob/master/targets/tinyfpga_bx/base.py#L31 | 21:51 |
tpb | Title: litex-buildenv/base.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 21:51 |
cr1901_modern | If it's not that, I don't know what's wrong | 21:51 |
mithro | cr1901_modern: It seems to be coming from the UsbDeviceCpuInterface device... | 21:51 |
*** rohitksingh has quit IRC | 21:52 | |
cr1901_modern | I can't know for sure without seeing the code. CRG as a submodule should've taken care of defining the sys clock domain | 21:52 |
mithro | cr1901_modern: Do I need to do a self.clock_domains.cd_sys = ClockDomain() in my module if I have multiple clock domains? | 21:53 |
mithro | In the "available clock domains:" I see the crg_sys and usb_sys... | 21:54 |
cr1901_modern | mithro: Again, I need to see the code | 21:54 |
cr1901_modern | I don't know, clock domain handling is one of the pain points of migen | 21:55 |
mithro | https://github.com/mithro/litex-buildenv/blob/tinyusb-work/targets/tinyfpga_bx/usbtest.py | 21:58 |
tpb | Title: litex-buildenv/usbtest.py at tinyusb-work · mithro/litex-buildenv · GitHub (at github.com) | 21:58 |
cr1901_modern | Yes, you need "self.clock_domains.cd_sys = ClockDomain()" in your top level | 21:58 |
cr1901_modern | Idk if "usb_sys" is because you did "self.clock_domains.cd_sys" in your USB core and migen's auto-naming kicked in, or you explicitly created a clock domain called "usb_sys" | 22:00 |
cr1901_modern | mithro: Are usb_sys and crg_sys intended to be the same clock domain? | 22:02 |
cr1901_modern | If so, take out the "self.clock_domains.cd_sys" in your USB core and see what happens | 22:03 |
mithro | Now I'm getting | 22:04 |
mithro | TypeError: Expression of unrecognized type: 'ClockSignal' | 22:04 |
cr1901_modern | I have no idea then. I would suggest showing sb0 | 22:05 |
*** techman83 has quit IRC | 22:06 | |
*** techman83 has joined #timvideos | 22:07 | |
*** ChanServ sets mode: +v techman83 | 22:07 | |
mithro | The issue seems to be my get_port on a memory | 22:08 |
mithro | <migen.fhdl.specials._MemoryPort object at 0x7fc8eb7842e8> {'duid': 647, 'adr': <Signal adr at 0x7fc8eb777f28>, 'dat_r': <Signal dat_r at 0x7fc8eb784048>, 'we': <Signal we at 0x7fc8eb784128>, 'dat_w': <Signal dat_w at 0x7fc8eb784208>, 'async_read': False, 're': None, 'we_granularity': 0, 'mode': 1, 'clock': <Signal clk at 0x7fc8eb777860>} | 22:10 |
mithro | <migen.fhdl.specials._MemoryPort object at 0x7fc8eb726080> {'duid': 1354, 'adr': <Signal adr at 0x7fc8eb722da0>, 'dat_r': <Signal dat_r at 0x7fc8eb722e48>, 'we': <Signal we at 0x7fc8eb722ef0>, 'dat_w': <Signal dat_w at 0x7fc8eb722f98>, 'async_read': False, 're': None, 'we_granularity': 0, 'mode': 1, 'clock': <migen.fhdl.structure.ClockSignal object at 0x7fc8eb7260b8>} | 22:10 |
cr1901_modern | ClockSignal("sys") | 22:11 |
cr1901_modern | to ge the actual clock signal | 22:11 |
cr1901_modern | get* even | 22:11 |
cr1901_modern | alternatively, self.clock_domains.cd_sys.clk | 22:12 |
mithro | I don't quite understand why one memory port is getting 'clock': Signal and the other one is getting 'clock': ClockSignal | 22:23 |
*** TheAssassin has quit IRC | 22:28 | |
*** TheAssassin has joined #timvideos | 22:42 | |
*** futarisIRCcloud has joined #timvideos | 23:56 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!