Hi Terry.. sorry if this thread is too old and you're on to other things.. no worries if you're not avail for this. I'm working to get sACN using the W6100 using a dsPIC33E and am having some trouble. I'm using the the SPI interface which seems fine. (I can read the ID & Version). I'm clocking the SPI fast and can send/recv 8bytes every 16.67usec (plenty of bandwidth I think). I think my trouble has to do when reading Sn_RX_RSR twice (for no more changes) , and then reading the Sn_RX_RD value to point into the RX Buffer. I saw where you were reading Sn_RX_RSR twice.. did you also do the Wiznet thing where when you're done reading, you add the Sn_RX_RSR to Sn_RX_RD and then issue the "READ" Command to Sn_CR (command 0x40) to update the internal registers (Sn_RX_RD) for the next time? This is returning the correct DMX values for the 1st & 2nd packets.. but the 3rd one returns zeros.. coincidentally that's when the Sn_RX_RD pointer rolls over (I'm using 2K buffers sizes). Thanks in advance for any help with this.. DougJ.
@dj41354 Hey Doug, I had similar issues with that 3rd DMX universe and I determined the issue was because we can't get data out of the Wiznet fast enough before the Wiznet buffer was filled. At 100Mbps, it is drinking from the firehose. My workaround was to simply set the Ethernet interface to 10Base-T. I use managed switches and set the interfaces to 10Base-T as well. That solved it for me. I am in the process of doing a new layout to attempt to achieve the rated SPI clock speed, which should reveal if that is indeed the issue. There were a lot of complaints about UDP performance in the Wiznet forums with the 6100, and I think this is why. If they had designed it with the size buffers available in the W5300, it wouldn't be a problem.
@dj41354 PS, to answer your question, I do increment the buffer pointer RX_RD with the new RX_RXR address and then send Sn_CR update the receive registers and Sn_IRCLR to clear the interrupt register.
Comments
Hi Terry.. sorry if this thread is too old and you're on to other things.. no worries if you're not avail for this. I'm working to get sACN using the W6100 using a dsPIC33E and am having some trouble. I'm using the the SPI interface which seems fine. (I can read the ID & Version). I'm clocking the SPI fast and can send/recv 8bytes every 16.67usec (plenty of bandwidth I think). I think my trouble has to do when reading Sn_RX_RSR twice (for no more changes) , and then reading the Sn_RX_RD value to point into the RX Buffer. I saw where you were reading Sn_RX_RSR twice.. did you also do the Wiznet thing where when you're done reading, you add the Sn_RX_RSR to Sn_RX_RD and then issue the "READ" Command to Sn_CR (command 0x40) to update the internal registers (Sn_RX_RD) for the next time? This is returning the correct DMX values for the 1st & 2nd packets.. but the 3rd one returns zeros.. coincidentally that's when the Sn_RX_RD pointer rolls over (I'm using 2K buffers sizes). Thanks in advance for any help with this.. DougJ.
@dj41354 Hey Doug, I had similar issues with that 3rd DMX universe and I determined the issue was because we can't get data out of the Wiznet fast enough before the Wiznet buffer was filled. At 100Mbps, it is drinking from the firehose. My workaround was to simply set the Ethernet interface to 10Base-T. I use managed switches and set the interfaces to 10Base-T as well. That solved it for me. I am in the process of doing a new layout to attempt to achieve the rated SPI clock speed, which should reveal if that is indeed the issue. There were a lot of complaints about UDP performance in the Wiznet forums with the 6100, and I think this is why. If they had designed it with the size buffers available in the W5300, it wouldn't be a problem.
@dj41354 PS, to answer your question, I do increment the buffer pointer RX_RD with the new RX_RXR address and then send Sn_CR update the receive registers and Sn_IRCLR to clear the interrupt register.