@Simonius said:
yes probably the IP address changed.
it worked fine here on my end, too, on an android phone.
As far as i know, you can, after you sent the HTTP response, just close the connection. in the old days you could just telnet to any http server (not many around anymore due to httpS) and request a page. after answering the host would shut down the connection, as was common practise. keep alive to do multiple requests on one socket and ,,push" messages came after that
Chrome and Edge are not honoring the "Connection: close" header. After the connection is closed, they immediately open a new connection and let it sit idle, which is fine if you have a bunch of threads listening on a given port. But with limited resources like the Wiznet, that's not good. It worked just fine so long as no one else was attempting to connect, other than that one browser.
on a Mac, running the latest OS, Google Chrome & Firefox bring up the page without issue. At first, Safari fails to bring up the page. States: Cannot connect to server "71.203.214.57" when the link is clicked. Copying the link and pasting it into Safari, now brings up the page, correctly!
I think we may be close to the limit of what can be done with a single socket. On the LAN, it appears to be stable. I have not had to reset since I added the additional timeout handler.
Do not be surprised if you have to refresh. I may need to tweek the timeout when it is in the read data mode. That was the magic sauce to prevent blocking by a single browser.
I will let it sit out there a bake on the Internet for a little while.
All good in Poland too. Opera on a PC. Opens up in a split second.
It just works.
And please, do not underestimate that humble status. It' s the one I'm usually after. Past that is a "fancy feature".
I promised code this weekend. There was much code cleanup. I know what everyone is interested in is a "webserver". I need to find a good SD card filesystem driver that I can marry with the code I have to make a more proper webserver. It will be Real Soon Now.
I promised code this weekend. There was much code cleanup. I know what everyone is interested in is a "webserver". I need to find a good SD card filesystem driver that I can marry with the code I have to make a more proper webserver. It will be Real Soon Now.
It might be possible down the track with the new PSRAM capable Edge board to setup a 32MB filesystem in PSRAM (or at least use it as a cache) for systems that need to serve web pages faster than an SD card can be read or for commonly accessed pages etc. We just need a simple wrapper layer that can make an external memory with (say) 512 byte block reads look like a filesystem and copy the needed files off an SD card for example. It may be moot if the SD card can always keep up with the Ethernet throughput via SPI but for lots of small random accesses it still might be handy sourcing these from PSRAM, or if you use multple sockets or other COGs that would otherwise all have to share the SD card for example.
I promised code this weekend. There was much code cleanup. I know what everyone is interested in is a "webserver". I need to find a good SD card filesystem driver that I can marry with the code I have to make a more proper webserver. It will be Real Soon Now.
It might be possible down the track with the new PSRAM capable Edge board to setup a 32MB filesystem in PSRAM (or at least use it as a cache) for systems that need to serve web pages faster than an SD card can be read or for commonly accessed pages etc. We just need a simple wrapper layer that can make an external memory with (say) 512 byte block reads look like a filesystem and copy the needed files off an SD card for example. It may be moot if the SD card can always keep up with the Ethernet throughput via SPI but for lots of small random accesses it still might be handy sourcing these from PSRAM, or if you use multple sockets or other COGs that would otherwise all have to share the SD card for example.
I like the idea of having a cache available. Right now, the bottleneck is ethernet. I am going to have to figure out inline PASM to improve performance. Throughput chokes at about 200kbits/s. This appears to be the case with both the UDP/E1.31 and TCP "webserver".
SD card latency (on a decent card, that is) is on the order of maybe 250 (?) or so µs between command and response (don't have the exact numbers in my head anymore, but I destinctly know that a single random block transfer on P1 takes ~7 NTSC scanlines and about half of that is latency).
It should be enough to cache only the directory/FAT for really fast performance.
Incidentally, I thought the whole point of the parallel interface on the WIZ 610 was to better use the speed of the Ethernet chip, preferably direct to RAM.
Trading SPIs seems to be missing the point a little. (And that's why I want the parallel interface - so I can dump 'not very much' data into (and out of) the RAM 'as fast as possible'. I may have an odd use case here.). S.
PS - if it helps to put A0 / A1 on a byte boundary, please let me know! Even if we have to stick the entire data bus onto the other connector... (erf).
PS - if it helps to put A0 / A1 on a byte boundary, please let me know! Even if we have to stick the entire data bus onto the other connector... (erf).
Actually I just dug up the data sheet for the 6100 chip and took a look. When the frame is sent for the parallel bus transfer protocol, it looks like A0,A1 go through a simple pattern of 0,1,2,3,3,3,3,3,3,3..., with the address bits only changing during the 3 byte header portion then remaining static after that. You could probably still bit bang these bits and keep the streamer used only for the data portion. So in that case the pin mapping is probably less of an issue here. You might choose to put them both into a nibble along with the read and write strobes on a 4 bit boundary just so you could choose to directly write to them with fast instructions that can change multiple bits like "setnib outa, #xx, #y" etc but it's not that big of a deal either way, as you could still OR/XOR with different mask etc to change these bits in a single instruction, so they can probably still be anywhere. It's just nice in general to be able to take advantage of any handy P2 capabilities when you can. You'd have to decide in software whether to automate the read and write strobe pins with a smartpin counter mode or bit bang yourself. If you automate with smartpins you can free instructions and/or you can do other things in the meantime while the transfer is occurring.
You'd have to decide in software whether to automate the read and write strobe pins with a smartpin counter mode or bit bang yourself. If you automate with smartpins you can free instructions and/or you can do other things in the meantime while the transfer is occurring.
Which is exactly the point. If it's faster to use a smartpin counter mode, you need to use specific pins, right? I've got some board layouts on a different thread, and if it makes a code speed difference to have specific pins, then I'd cheerfully change the board layouts to match. Saving just a few cycles would be worth it!
But I don't know! So I went off and asked all of y'all about it. Suggestions cheerfully considered... S.
You'd have to decide in software whether to automate the read and write strobe pins with a smartpin counter mode or bit bang yourself. If you automate with smartpins you can free instructions and/or you can do other things in the meantime while the transfer is occurring.
Which is exactly the point. If it's faster to use a smartpin counter mode, you need to use specific pins, right? I've got some board layouts on a different thread, and if it makes a code speed difference to have specific pins, then I'd cheerfully change the board layouts to match. Saving just a few cycles would be worth it!
But I don't know! So I went off and asked all of y'all about it. Suggestions cheerfully considered... S.
When going through the phases of setting up the process, it is convenient to have A0 and A1 on a nibble boundry. You set those ADDR line (A0 and A1) depending on if you are setting the high byte register(00), low byte register(01) , block select register (10), or data register (11). Here is my code for reading data from the chip. This is the first code I want to convert to PASM. I need to look through my code to see if I actually do anything with the returned value, as that code may not be needed.
looks very cool. But can you please give us a short summary how everything works together? So you have a high speed (100Mb/s) ethernet connection with the WZ6100 wired in parallel bus mode. Why do you need such a high data rates to blink some LEDs? And for what do you need the SD card? Do you plan to transfer and store whole images?
I ask because I might also need ethernet connectivity but not TCP/IP or UDP but raw packet transfers. I know the WZ6100 has also a "raw" mode on socket 0. It may be overkill for my application. In the past and with the P1 I used the ENC28J60. If I had to do it on the P2 from scratch I'd probably try to stram data directly to a PHY with RMII interface. But that's much work and saves only $1 per unit.
Thanks @ManAtWork The setup here is using jinx LED matrix control to send E1.31 data over ethernet to the P2. I want to blink thousands of pixels, at a rate of about 24 frames per second, as well as have a couple of traditional DMX outputs. My current Christmas display contains a little over 2,000 pixels and receives E1.31 pixel data at a rate of about 7Mb/s. The SD card will be used to contain the network configuration and DMX Universe mappings. The file with this configuration would be manipulated by the web interface, to make it user friendly.
I have considered using the raw mode and just building a TCP/IP stack in the prop, rather than allowing the W6100 to do that heavy lifting. But that is much more complicated than using what is available. That's my option of last resort.
I have found the challenge I am having now is one of latency rather than speed, and I think I can get around that problem by writing a special "fast receiver" that uses the Interrupt, rather than repeatedly polling the interrupt registers. It will contain all of the code to get pixel data into the correct hubRAM locations. I am attempting to not have a dedicated cog just to talk to the W6100, because I don't want data to pass though multiple places in the hub before getting to the correct spot. I am thinking of using locks to solve this problem.
Hmm, 2000 pixels @ 24fps is 144000 bytes/s with 24bit color/pixel. That shoudn't be a problem over 100Mb/s ethernet even if you have a slow PHY connected via SPI unless the protocol has a lot of overhead.
I have considered using the raw mode and just building a TCP/IP stack in the prop
That would be really hard to get it right. I have designed my own protocol 10 years ago and I recently discovered a bug that shows up very rarely when packets arrive out of order. It never happened on older PCs and older Windows versions but you never know what goes wrong after the next Windows update...
@ManAtWork said:
Hmm, 2000 pixels @ 24fps is 144000 bytes/s with 24bit color/pixel. That shoudn't be a problem over 100Mb/s ethernet even if you have a slow PHY connected via SPI unless the protocol has a lot of overhead.
I have considered using the raw mode and just building a TCP/IP stack in the prop
That would be really hard to get it right. I have designed my own protocol 10 years ago and I recently discovered a bug that shows up very rarely when packets arrive out of order. It never happened on older PCs and older Windows versions but you never know what goes wrong after the next Windows update...
This should be easy work, but I am not the brightest crayon in the box
There is about 130 bytes of overhead per 512 bytes of pixel data. The battle I am having now is latency. The buffer on the W6100 fills up before I can pull data out.
Luckily for this application, there is a sequence number attached to each packet and you can easily determine if packets arrive out of order.
But yeah, the lift to write a full TCP/IP stack is big, and I don't want to try that.
@ke4pjw not to stomp too badly on your design, but this is solved already (and brilliantly!) by the Falcon Christmas Player project. There's source and disk images available for Beaglebone Black and Green. Parsing and driving 16+ universes of data to 8-40 (48?) separate outputs @ 50fps is trivial. I've pushed terabytes of lighting data to a big network of these for many years now. At one point, my ethernet backbone throughput was ~30MB/second with no issues at all.
@JohnC said:
@ke4pjw not to stomp too badly on your design, but this is solved already (and brilliantly!) by the Falcon Christmas Player project. There's source and disk images available for Beaglebone Black and Green. Parsing and driving 16+ universes of data to 8-40 (48?) separate outputs @ 50fps is trivial. I've pushed terabytes of lighting data to a big network of these for many years now. At one point, my ethernet backbone throughput was ~30MB/second with no issues at all.
Take a look if you haven't already.
I am familiar with the Falcon controllers and Falcon Player. I have ran a Christmas display for over decade now. I have a HinksPix Pro controller and a few long range receivers. I want to replace that with a controller of my own design. All of my AC dimmers (16 at last count) are of my own design. This is fun for me.
Comments
Chrome and Edge are not honoring the "Connection: close" header. After the connection is closed, they immediately open a new connection and let it sit idle, which is fine if you have a bunch of threads listening on a given port. But with limited resources like the Wiznet, that's not good. It worked just fine so long as no one else was attempting to connect, other than that one browser.
I found an unhandled timeout condition. I have applied a small fix, with fingers crossed
IP is still the same.
http://71.203.214.57:6809/
on a Mac, running the latest OS, Google Chrome & Firefox bring up the page without issue. At first, Safari fails to bring up the page. States: Cannot connect to server "71.203.214.57" when the link is clicked. Copying the link and pasting it into Safari, now brings up the page, correctly!
OK here
I think we may be close to the limit of what can be done with a single socket. On the LAN, it appears to be stable. I have not had to reset since I added the additional timeout handler.
Do not be surprised if you have to refresh. I may need to tweek the timeout when it is in the read data mode. That was the magic sauce to prevent blocking by a single browser.
I will let it sit out there a bake on the Internet for a little while.
Thanks guys!
--Terry
+1 OK from Italy, Firefox, and Edge browsers
All good in Poland too. Opera on a PC. Opens up in a split second.
It just works.
And please, do not underestimate that humble status. It' s the one I'm usually after. Past that is a "fancy feature".
Hi
Still working super fast, win 10, edge, uk
Dave
Still working well Windows10 Edge and Chrome! Good work.
Excellent work, congratulations!
Checked OK from Brazil (Firefox, under W8.1).
Also checked (thru free VPN) from Japan, Netherlands and USA (a bit redundant, as there are more than enough forum users in the States).
Addit: Chrome (under Android) also got it right on my smartphone.
Thanks to everyone checking it out! I am going to power it down and finish my code refactor.
I started a new thread over at:
https://forums.parallax.com/discussion/174246/wiznet-wiz6100-actually-wiz610ml-board-layouts#latest
about a few board layouts I put together. See what y'all think? S.
@ke4pjw I was going to order one of those WIZ610MJ boards to try out your code but the shipping on that jewel is more than the board.
Well, I have dasblinkin lights via E1.31.
https://youtube.com/watch?v=hMrVC5T001o
I promised code this weekend. There was much code cleanup. I know what everyone is interested in is a "webserver". I need to find a good SD card filesystem driver that I can marry with the code I have to make a more proper webserver. It will be Real Soon Now.
@CJMJ Yea, I paid for 2day shipping, so my shipping was 3x cost of the board. It is a great little chip.
The parallel bus is not in demand, so I think availability of these boards is going to be limited.
This place has them, but I don't know if the shipping is better.
https://tme.com/us/en-us/details/wiz610mj/ethernet-modules/wiznet/
$11 is not bad for a base price. That shipping is a pain for sure.
It might be possible down the track with the new PSRAM capable Edge board to setup a 32MB filesystem in PSRAM (or at least use it as a cache) for systems that need to serve web pages faster than an SD card can be read or for commonly accessed pages etc. We just need a simple wrapper layer that can make an external memory with (say) 512 byte block reads look like a filesystem and copy the needed files off an SD card for example. It may be moot if the SD card can always keep up with the Ethernet throughput via SPI but for lots of small random accesses it still might be handy sourcing these from PSRAM, or if you use multple sockets or other COGs that would otherwise all have to share the SD card for example.
I like the idea of having a cache available. Right now, the bottleneck is ethernet. I am going to have to figure out inline PASM to improve performance. Throughput chokes at about 200kbits/s. This appears to be the case with both the UDP/E1.31 and TCP "webserver".
SD card latency (on a decent card, that is) is on the order of maybe 250 (?) or so µs between command and response (don't have the exact numbers in my head anymore, but I destinctly know that a single random block transfer on P1 takes ~7 NTSC scanlines and about half of that is latency).
It should be enough to cache only the directory/FAT for really fast performance.
Incidentally, I thought the whole point of the parallel interface on the WIZ 610 was to better use the speed of the Ethernet chip, preferably direct to RAM.
Trading SPIs seems to be missing the point a little. (And that's why I want the parallel interface - so I can dump 'not very much' data into (and out of) the RAM 'as fast as possible'. I may have an odd use case here.). S.
PS - if it helps to put A0 / A1 on a byte boundary, please let me know! Even if we have to stick the entire data bus onto the other connector... (erf).
Actually I just dug up the data sheet for the 6100 chip and took a look. When the frame is sent for the parallel bus transfer protocol, it looks like A0,A1 go through a simple pattern of 0,1,2,3,3,3,3,3,3,3..., with the address bits only changing during the 3 byte header portion then remaining static after that. You could probably still bit bang these bits and keep the streamer used only for the data portion. So in that case the pin mapping is probably less of an issue here. You might choose to put them both into a nibble along with the read and write strobes on a 4 bit boundary just so you could choose to directly write to them with fast instructions that can change multiple bits like "setnib outa, #xx, #y" etc but it's not that big of a deal either way, as you could still OR/XOR with different mask etc to change these bits in a single instruction, so they can probably still be anywhere. It's just nice in general to be able to take advantage of any handy P2 capabilities when you can. You'd have to decide in software whether to automate the read and write strobe pins with a smartpin counter mode or bit bang yourself. If you automate with smartpins you can free instructions and/or you can do other things in the meantime while the transfer is occurring.
Which is exactly the point. If it's faster to use a smartpin counter mode, you need to use specific pins, right? I've got some board layouts on a different thread, and if it makes a code speed difference to have specific pins, then I'd cheerfully change the board layouts to match. Saving just a few cycles would be worth it!
But I don't know! So I went off and asked all of y'all about it. Suggestions cheerfully considered...
S.
When going through the phases of setting up the process, it is convenient to have A0 and A1 on a nibble boundry. You set those ADDR line (A0 and A1) depending on if you are setting the high byte register(00), low byte register(01) , block select register (10), or data register (11). Here is my code for reading data from the chip. This is the first code I want to convert to PASM. I need to look through my code to see if I actually do anything with the returned value, as that code may not be needed.
`PUB readreg(REGISTER,BS,BLEN,RB) : r | i , LADDRL, LADDRH
' Parse register address
LADDRL := REGISTER
LADDRH := LADDRL
LADDRL &= $FF
LADDRH >>= 8
' Set ADDRH
PINL(CSn)
PINWRITE (ADDR , IDM_ARH)
PINWRITE (DATA , LADDRH)
pintoggle(WRn)
pintoggle(WRn)
'PINL(WRn)
'PINH(WRn)
'Set ADDRL
PINWRITE (ADDR , IDM_ARL)
PINWRITE (DATA , LADDRL)
pintoggle(WRn)
pintoggle(WRn)
'Set BS (This is a common register, therefore set byte data to $00)
PINWRITE (ADDR , IDM_BSR)
PINWRITE (DATA , BS)
pintoggle(WRn)
pintoggle(WRn)
'Read Register
i := 0
REPEAT BLEN
PINWRITE (ADDR , IDM_DR)
PINF(DATA )
PINL(RDn)
byte[RB][i] := PINREAD (DATA )
r := PINREAD (DATA )
i++
PINH(RDn)
PINH(CSn)
return r
`
Here is a quick video of this project in use. Still not perfect, but I know more optimizations I can do. Probably going to share the repo real soon.
https://facebook.com/terrytrapp/videos/762334231395590/?t=2
PS: Can't get BBCODE to work anymore and I am not smart enough to understand Markdown.
Hi Terry,
looks very cool. But can you please give us a short summary how everything works together? So you have a high speed (100Mb/s) ethernet connection with the WZ6100 wired in parallel bus mode. Why do you need such a high data rates to blink some LEDs? And for what do you need the SD card? Do you plan to transfer and store whole images?
I ask because I might also need ethernet connectivity but not TCP/IP or UDP but raw packet transfers. I know the WZ6100 has also a "raw" mode on socket 0. It may be overkill for my application. In the past and with the P1 I used the ENC28J60. If I had to do it on the P2 from scratch I'd probably try to stram data directly to a PHY with RMII interface. But that's much work and saves only $1 per unit.
Thanks @ManAtWork The setup here is using jinx LED matrix control to send E1.31 data over ethernet to the P2. I want to blink thousands of pixels, at a rate of about 24 frames per second, as well as have a couple of traditional DMX outputs. My current Christmas display contains a little over 2,000 pixels and receives E1.31 pixel data at a rate of about 7Mb/s. The SD card will be used to contain the network configuration and DMX Universe mappings. The file with this configuration would be manipulated by the web interface, to make it user friendly.
I have considered using the raw mode and just building a TCP/IP stack in the prop, rather than allowing the W6100 to do that heavy lifting. But that is much more complicated than using what is available. That's my option of last resort.
I have found the challenge I am having now is one of latency rather than speed, and I think I can get around that problem by writing a special "fast receiver" that uses the Interrupt, rather than repeatedly polling the interrupt registers. It will contain all of the code to get pixel data into the correct hubRAM locations. I am attempting to not have a dedicated cog just to talk to the W6100, because I don't want data to pass though multiple places in the hub before getting to the correct spot. I am thinking of using locks to solve this problem.
Hmm, 2000 pixels @ 24fps is 144000 bytes/s with 24bit color/pixel. That shoudn't be a problem over 100Mb/s ethernet even if you have a slow PHY connected via SPI unless the protocol has a lot of overhead.
That would be really hard to get it right. I have designed my own protocol 10 years ago and I recently discovered a bug that shows up very rarely when packets arrive out of order. It never happened on older PCs and older Windows versions but you never know what goes wrong after the next Windows update...
This should be easy work, but I am not the brightest crayon in the box
There is about 130 bytes of overhead per 512 bytes of pixel data. The battle I am having now is latency. The buffer on the W6100 fills up before I can pull data out.
Luckily for this application, there is a sequence number attached to each packet and you can easily determine if packets arrive out of order.
But yeah, the lift to write a full TCP/IP stack is big, and I don't want to try that.
@ke4pjw not to stomp too badly on your design, but this is solved already (and brilliantly!) by the Falcon Christmas Player project. There's source and disk images available for Beaglebone Black and Green. Parsing and driving 16+ universes of data to 8-40 (48?) separate outputs @ 50fps is trivial. I've pushed terabytes of lighting data to a big network of these for many years now. At one point, my ethernet backbone throughput was ~30MB/second with no issues at all.
Take a look if you haven't already.
Sounds intriguing JohnC, but could you suggest a demo site for those of us too lazy to find it?
I am familiar with the Falcon controllers and Falcon Player. I have ran a Christmas display for over decade now. I have a HinksPix Pro controller and a few long range receivers. I want to replace that with a controller of my own design. All of my AC dimmers (16 at last count) are of my own design. This is fun for me.