it's so funny to me that a normal, understandable, two page sized python program can implement a real hardware NIC driver that someone can use for realtime work like typing in an SSH session, under concurrent heavy load, and it gives you single ms digit latency
this is the entire transmit queue code. you can look at it in its entirety on one editor screen and understand it. it uses normal python idioms and doesn't even touch USB directly
@whitequark this is the kind of black magic written in Python that made me interested in programming in the first place, yet I never came even close to do something remotely similarly unhinged :breadpeek:
usb_iface is a complex abstraction the glasgow framework provides to you that lets you intersperse 1-byte writes with 1 kbyte writes without it thrashing the USB interface with tiny requests
i benchmarked the driver with and without that abstraction (using the USB interface directly). no measurable difference in throughput! i put a lot of effort into making it as-little-copy-as-possible and it pays off
you can treat complex USB hardware as just a byte oriented stream, and not suffer for it
so, smoltcp, the no-alloc embedded TCP/IP stack that i wrote, compiles perfecty to webassembly. and i have lots of experience embedding webassembly in python
so, potentially, i could add this to the Python NIC, meaning it would have a high-performance TCP/IP implementation right next to it :D
an entire network stack running on an ice40, transferring data using an FX2 with a 8051, and in a Python process (with some JIT involved)
Add comment