| *** tpb has joined #tomu | 00:00 | |
| xobs | I noticed something super interesting. The litex event system is interacting with it somehow. | 00:57 |
|---|---|---|
| xobs | If I enable some of the ep1/ep2 event sources, then I get extra bits in ep0. | 01:00 |
| xobs | That would seem to mesh with the fact that it works fine in simulation, and the debug bridge works fine, but in real hardware it does n't. | 01:00 |
| xobs | The litex event system isn't properly simulated. | 01:01 |
| *** ptotter[m] has quit IRC | 01:30 | |
| *** shalzz has quit IRC | 01:30 | |
| *** xobs has quit IRC | 01:30 | |
| *** nrossi has quit IRC | 01:30 | |
| *** alexhw[m] has quit IRC | 01:31 | |
| *** synaption[m] has quit IRC | 01:31 | |
| *** dwg has quit IRC | 01:32 | |
| *** dwg has joined #tomu | 01:32 | |
| *** Vercas_ has joined #tomu | 01:49 | |
| *** jeroud has quit IRC | 01:50 | |
| *** imdeni has quit IRC | 01:51 | |
| *** imdeni has joined #tomu | 01:53 | |
| *** jeroud has joined #tomu | 01:54 | |
| *** Vercas has quit IRC | 01:56 | |
| *** buZz has quit IRC | 01:56 | |
| *** hegemoOn has quit IRC | 01:56 | |
| *** shalzz has joined #tomu | 02:15 | |
| *** ptotter[m] has joined #tomu | 02:19 | |
| *** nrossi has joined #tomu | 02:29 | |
| *** alexhw[m] has joined #tomu | 02:31 | |
| *** xobs has joined #tomu | 02:31 | |
| *** buZz has joined #tomu | 02:34 | |
| *** buZz has joined #tomu | 02:34 | |
| *** synaption[m] has joined #tomu | 02:35 | |
| *** hegemoOn has joined #tomu | 02:53 | |
| *** futarisIRCcloud has joined #tomu | 07:11 | |
| *** cdmatter has quit IRC | 08:10 | |
| xobs | One of the problems I'm discovering is that we include the CRC16 in the FIFO, which means that there are two extra bytes. | 09:17 |
| xobs | That's fine normally, but in a SETUP packet, it's essentially an OUT/IN/OUT, so if you have two SETUP packets that follow each other it's OUT/IN/OUT/OUT, and the second OUT will have two 0 bytes tacked on to the front. | 09:18 |
| *** futarisIRCcloud has quit IRC | 09:21 | |
| tnt | Mm ? I mean having the CRC being received is not uncommon afaik, you can simply ignore it if you know the data you get is always 2 bytes longer. | 09:27 |
| tnt | I'm pretty sure I saw the doc of some uc that stated the CRC would be received and written to memory as well. | 09:27 |
| xobs | tnt: true, but for a SETUP (IN) transaction, the host sends SETUP, then DATA, then expects data to be read. It sends IN, then the device sends data. Finally, the host sents OUT, followed by DATA. This last data is two bytes of 00. | 09:28 |
| xobs | If a second transaction is immediately started, then the host will send SETUP, followed by DATA. | 09:29 |
| xobs | Because of the Fomu's FIFO architecture, if the last two bytes of 00 aren't removed from the FIFO, they will be prefixed to the first SETUP packet. | 09:29 |
| tnt | Oh you mean you don't know the packet boundaries inside the FIFO ? | 09:33 |
| xobs | Yeah, that information isn't kept anywhere. | 09:33 |
| tnt | In the case where all goes well, you _know_ that you just finished the previous transfer and you're waiting for the 00 from the ZLP of the status stage. | 09:36 |
| tnt | but handling all the cases where things don't go perfectly in a spec compliant fashion would be tricky ... | 09:37 |
| tnt | Also even above this, some usb protocol require you to know when you get a shorter than max length packet to mark boundaries between transfers, so this seems like an annoying limitation. | 09:39 |
| xobs | tnt: I don't think I've seen anything that is spec-compliant to all the errors. It's _hard_. | 09:45 |
| xobs | We don't even properly support retransmission right now. | 09:45 |
| tnt | xobs: oh I know it's hard, I discover new stuff every time I re-read the spec :p But at least recover somewhat gracefully and not complete any transfer with corrupt data. | 09:48 |
| tnt | The usb compliance tester sw doesn't ever really test error cases AFAICT. | 09:48 |
| xobs | I got the compliance tester, but wasn't sure how to run it, because apparently it takes over the root hub (?) in order to do its thing, which would make it somewhat difficult to use the machine. | 09:49 |
| *** AmosSam has left #tomu | 09:50 | |
| tnt | Yes, it takes over the USB controller. so either you need multiple USB controllers or you need to have mouse/keyboard that don't use USB. | 09:50 |
| *** AmosSam has joined #tomu | 09:50 | |
| *** AmosSam has left #tomu | 09:59 | |
| *** AmosSam has joined #tomu | 10:01 | |
| ToxicFrog | Does using the USB controller also make use of some of the hardware that reads the buttons or something? I'm having weird issues when trying to make something that emulates a USB keyboard and sends keystrokes on button press. | 12:28 |
| ToxicFrog | "send keystrokes on boot" works fine, and "react to button presses by lighting one of the lights" works fine | 12:28 |
| ToxicFrog | But when I write "react to button presses by sending keystrokes", I start getting phantom button inputs where gpio_get(...) is returning nonzero even if no-one is touching the device. | 12:29 |
| *** futarisIRCcloud has joined #tomu | 12:29 | |
| xobs | ToxicFrog: the captouch on Tomu is a hardware block. I seem to remember there's a value you can tune somewhere. | 12:29 |
| xobs | Though captouch is hard :-/ | 12:29 |
| jerith | I can't seem to get my buttons to respond, currently. :-( | 12:30 |
| jerith | ToxicFrog: Maybe USB traffic is triggering the captouch? Everything's quite close together. | 12:31 |
| ToxicFrog | That's my best guess, yeah...presumably it's tunable so that doesn't happen, or no-one would be able to use it for U2F? | 12:32 |
| ToxicFrog | Eurgh, I'm going to have to read up on how the captouch stuff works. | 12:32 |
| ToxicFrog | I'm used to buttons that are just "this pin is connected to Vcc/GND depending on whether it's pressed or not" :/ | 12:32 |
| jerith | Likewise. | 12:33 |
| jerith | (Even that needs debouncing, but a simple delay before checking again is generally good enough.) | 12:33 |
| ToxicFrog | (yeah, IME debouncing is a lot easier to deal with than "USB is haunted and the ghosts are messing with your other GPIO pins") | 12:37 |
| ToxicFrog | There's the tomu-samples blinky-usb program, but that looks like it's using a completely different API for GPIO and whatnot... | 12:46 |
| *** emeb has joined #tomu | 14:37 | |
| *** futarisIRCcloud has quit IRC | 14:49 | |
| *** rohitksingh has joined #tomu | 15:58 | |
| *** rohitksingh has quit IRC | 16:24 | |
| *** rohitksingh has joined #tomu | 16:26 | |
| *** rohitksingh has quit IRC | 17:39 | |
| *** dwg has quit IRC | 17:40 | |
| *** dwg has joined #tomu | 17:40 | |
| *** rohitksingh has joined #tomu | 17:47 | |
| *** Vercas_ is now known as Vercas | 18:07 | |
| *** rohitksingh has quit IRC | 18:25 | |
| *** rohitksingh has joined #tomu | 18:46 | |
| *** rohitksingh has quit IRC | 19:02 | |
| *** rohitksingh has joined #tomu | 19:58 | |
| *** rohitksingh has quit IRC | 21:01 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!