<Sprite_tm>
We're probably missing transactions >64bytes, tinyusb doesn't stitch them together myself and my code doesn't yet either.
<tnt>
Yeah, that's the next step :p
<tnt>
dcd_edpt_xfer: ep 3 dir in, len 512
<tnt>
obviously that fails and results in bus reset
<Sprite_tm>
Aye.
<tnt>
The other issue I fixed was the 'length - 2' thing I mentionned above. And also the _usb_data_read() needs to be when the Buffer is complete, just before calling dcd_event_xfer_complete and not when setting up the buffer.
<Sprite_tm>
Should be doable, although I'm not sure if we can happily abuse tinyusb memory or if we need to allocate the memory to stitch things ourselves...
<Sprite_tm>
Ah, gotcha. Yeah, WiP :P
<tnt>
I think the buffer that's provided by tinyusb in the xfer setup stays valid until the transfer is complete.
<Sprite_tm>
For in transfers, sure, but do we also have a mechanism for that for in transfers?
<Sprite_tm>
*for out transfers?
<tnt>
Looking at other DCD they keep the pointer to the buffer that was given to dcd_edpt_xfer around until the xfer is complete, for both in/out.
<Sprite_tm>
Ah, we can nak the transfer until it's requested, obviously. Sorry, I need coffee and not to be irc'ing in the middle of a meeting at work :)
<dkozel>
Have either of you tested current max transfer speeds on these implementations?
<Sprite_tm>
Should be pretty close to theoretical max usb1.1 speed methinks, it's not that hard to get there with current tech.
<tnt>
dkozel: I haven't tested with tiny USB, but with my own stack, I tried 2 iso streams of 512 bytes in // without issues.
<tnt>
Sprite_tm: it was really just a quick thing to see if it improved stuff :p
<Sprite_tm>
Check :) I'll copy-paste it (aside from the fact that I really don't want rx and tx buffers on overlapping memory locations, so no single USB_DATA_BASE for me)
<Sprite_tm>
I'll see if I can put in larger transfers this evening; hopefully that makes msc work.
<tnt>
Sprite_tm: yeah, the first bit was just to get it to build in my current ice40 setup.
Asu has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
<tnt>
I was planning to have a quick look at it when I'm done with lunch.
<Sprite_tm>
Check, you're somewhere in the west-EU timezone I assume?
<tnt>
Yeah, CEST.
<tnt>
Its 1320 here :p
<Sprite_tm>
Check. 19.20 here, time to go home.
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined ##openfpga
<GenTooMan>
it was 7:20 here.. .time to wake up
lutsabound has joined ##openfpga
bibor has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 244 seconds]
<Sprite_tm>
Well, I learned something today. Seems it's legal for a device to use 'the same' endpoint for both in and out operations, so 0x82 and 0x02.
rohitksingh_work has quit [Read error: Connection reset by peer]
<ZirconiumX>
Yep, though I don't know how well hosts would handle you trying to do I/O on 16 endpoints at once.
<ZirconiumX>
(which is a thing you can do)
<tnt>
Sprite_tm: btw, I'm almost done updating the xfer logic.
<Sprite_tm>
tnt: Ah, also did that, it should support >64b transfers now.
<Sprite_tm>
Couldn't test it yet because the logic borks before it gets to the 64b transfer stadium, though.
<tnt>
Arf well ... I'll finish and then feel free to cherry-pick if you see anything good in it :p
tlwoerner has quit [Quit: Leaving]
<tnt>
(assuming I ever find wtf I screwed up in that logic :p)
<Sprite_tm>
Ooooh, I'm sooooo close... got Linux to detect the 8K USB device.
<Sprite_tm>
It just throws errors afterwards.
<Sprite_tm>
No, wait, it does read. Linux just is very, very keen on wanting to reset the device for some reason.
<Sprite_tm>
I'll push so you at least have working code :P
<tnt>
Sprite_tm: that's the code I was working on. It gets recognized as a disk and you can mount it and read / write from it.
<Sprite_tm>
tnt: Hehe, you took a quite, but not entirely, similar approach to what I did.
<Sprite_tm>
Will see i I can merge stuff tomorrow. Now is sleepy times.
<tnt>
Sprite_tm: heh yeah, gotta leave too, time to go excercise a bit :p
lutsabound has quit [Quit: Connection closed for inactivity]
dh73 has joined ##openfpga
mumptai has joined ##openfpga
Finde has joined ##openfpga
<Finde>
does yosys set a default verilog macro like YOSYS or __YOSYS__ or something as other tools do?
<daveshah>
Finde: yes, it sets YOSYS and SYNTHESIS or FORMAL (latter with -formal)
dj_pi has joined ##openfpga
<Richard_Simmons3>
something went terribly wrong trying to tin an iron tip for an ok radioshack soldering iron. No amount of flux, solder, or brass sponging has gotten it to wet, using both SAC 307 and leaded solder. I've tried rubbing a solid blob of solder on it as it was heating, and then pure lead. I have no idea what could have gone so terribly wrong at this point.
<Richard_Simmons3>
I decided to just abuse it a bit at this point and see what tinned first, steel or the tip. Steel tinned, tip didn't.
<Hoernchen>
great,so it's easy to clean
dj_pi has quit [Ping timeout: 258 seconds]
<azonenberg>
Richard_Simmons3: tip is probably super oxidized
<Richard_Simmons3>
I've usually been able to rub off oxidation when I missed a spot in the past, it's why I was trying rubbing a solid piece of solder onto it, but I never got even a spot to tin in the first place on this one. I suppose nickel oxides would be pretty tough then?
<azonenberg>
also don't kmow what the tip is made of etc
<Richard_Simmons3>
it's got a silvery flashing over copper. I wouldn't call it a plating, but I have assumed that was nickel.
<Richard_Simmons3>
the other tips that came in the pack have tinned ok, though not as easily as some other brands of irons bundled tips I've had.
<Finde>
thanks daveshah
GenTooMan has quit [Remote host closed the connection]