Anyone working on a faster ENC29J60 driver?
scanlime
Posts: 106
So, PropTCP is cool, but from my testing so far it looks to be really slow. I'm having trouble getting more than about 1 KB/sec of throughput.
I'm interested in streaming audio over ethernet in real-time. Basically, I want to see if I can glue my SPDIF output object to an ENC29J60 in order to make a networked audio bridge. Stream decoded MP3s (or any other PCM audio) over 10baseT, into the Propeller, then into the optical input on my stereo. Kind of a super-simple Squeezebox [noparse];)[/noparse]
Anyway, I was thinking about writing a simple ENC29J60 driver (perhaps just with ARP and UDP) in assembly. I suspect it's possible to write a fast SPI driver using many of the same tricks that fsrw uses, combine it with a really basic ARP and UDP implementation, and stuff that all into a single cog. Hopefully it will be fast enough to stream PCM data at 1.5 MBit or so.
Is anyone already working on this? I'd hate to duplicate effort.
Thanks,
--Micah
I'm interested in streaming audio over ethernet in real-time. Basically, I want to see if I can glue my SPDIF output object to an ENC29J60 in order to make a networked audio bridge. Stream decoded MP3s (or any other PCM audio) over 10baseT, into the Propeller, then into the optical input on my stereo. Kind of a super-simple Squeezebox [noparse];)[/noparse]
Anyway, I was thinking about writing a simple ENC29J60 driver (perhaps just with ARP and UDP) in assembly. I suspect it's possible to write a fast SPI driver using many of the same tricks that fsrw uses, combine it with a really basic ARP and UDP implementation, and stuff that all into a single cog. Hopefully it will be fast enough to stream PCM data at 1.5 MBit or so.
Is anyone already working on this? I'd hate to duplicate effort.
Thanks,
--Micah
Comments
I am not sure you can get 1 cog to stream continously though. what you may need is 2 cogs both with a packet burst spi driver but each alternating between loading a packet from hub and bursting it into the enc28j60, i.e. when 1 cog is loading the next packet from hub memory, the other cog is sending the last packet to the ethernet chip, while a 3 cog is loading the next music packet into hub memory. Or the reverse if you are receiving from ethernet.
How about putting the SPDIF output on the 10bT? People are always doing things the hard ways for no reason.
You'll likely be better off using UDP and assembly. The hardest thing will likely be checksum generation, which you can offload to the enc28j60 if you are using B4 and lower silicon revisions.
The enc28j60 driver's spi clock currently runs at ~2.2MHz if I recall correctly. I believe Jasper_M was working on a faster version, but encountered some issues with the spi clock.
VIRAND, I want something Ethernet-compatible so that I can route the packets over Wifi and HomePNA, but it doesn't necessarily need TCP. UDP packets would be fine. The main advantage of TCP support would be compatibility with existing software like esound or SlimServer, but that is a secondary goal.
Like I said, I'm just curious if anyone is already working on this. I already know how I would implement it, and it sounds like a fun piece of software to write. I just don't want to step on anyone's toes [noparse];)[/noparse]
The B5 errata can be found here: ww1.microchip.com/downloads/en/DeviceDoc/80264d.pdf
Anyways, sounds like a really cool project. It would be really cool to have a Prop receive a music stream over ethernet. Perhaps you could even throw on a mp3 decoder chip to reduce the network utilization. The tcp stack should be able to receive much faster if you modify it to copy incoming packet contents directly to a large buffer.
Thanks. I'll keep folks posted with my results after I've had some time to hack on this.
I might try adding an MP3 decoder later on. That might let me build something which is compatible with an unmodified copy of SlimServer, since it assumes that the device can, at minimum, decode MP3 and PCM.
For the network cog, I've been thinking about a scheme where, during initialization, you set up simple filters (like "all TCP packets", or "UDP port 123") and bind those filters to buffers in hub memory. This way you could have the fast low-level cog route audio UDP packets to the very same hub buffer used by the SPDIF engine, while other packets could go to slower Spin code that handles higher-level protocols like TCP, HTTP, various service discovery protocols... The filter setup stage could even generate small fragments of machine code that reside in the network cog, so the cog spends only a minimal amount of time reading and writing hub memory.