@ke4pjw Thanks. Does sound better when you put it like that.
Wireshark is pretty handy for getting actual download times.
Turned the inline assembly for block SPI transfers back to C and download time increased to 0.67 seconds.
So, inline assembly does help SPI a little...
Added "volatile" to that inline assembly and time decreased to 0.350 seconds.
~ 7 Mbps.
That was with 250 MHz P2 clock.
Increased P2 clock to 300 MHz.
Now at 0.317 seconds.
7.8 Mbps. Guess that's good enough for now...
A dedicated SPI cog could probably improve bulk transfer speed, but don't want to do that...
@rayman I don't use a dedicated cog to communicate with the W6100. I just use locks and it works fine, even when streaming multi-megabit UDP data to the light controller, the webserver is peppy.
Figured out how to use the fetch API to send commands & receive data from Propeller2.
Maybe it's a hack, but the button uses fetch to get the file "P56.txt".
Added some C code to check if that filename is requested and if so to toggle P56.
You can do background-image: linear-gradient(90deg, #9FCFFF, white 90px); to replace background-image: url(blegtext.gif); background-repeat: repeat-y; and get rid of the image file. (well, it's slightly smoother and the ramp is different, but who cares?)
@Wuerfel_21 That does work, thanks. But, having the file there is good for testing...
Looking at adding in ftp. Example looks like it needs 3 sockets, but I only have two left...
Think I'll try taking one away from http, giving it just 3 and see how it does.
I'm thinking the ftp server would be nice for uploading/downloading from uSD card...
Ok, there was a pretty bad bug in nearly all previous versions. Amazing it worked at all...
Seems I called DNS_init() after using DNS instead of before.
This probably made the code use random addresses for the buffer.
Effect was that it wouldn't work on P2 Eval when clock was above 160 MHz. Very strange effect, but all better now.
This version has Platform.h setting for P2 Eval board with basepin=16.
The HTTP server can now serve files from uSD card.
I think bad things might happen if you try to ftp and http large uSD files at the same time though...
Think I'm about done here now. Just need to clean up and remove a lot of the embedded web content that is eating up HUB RAM. Can put all that on uSD now...
No dice with the current version of FlexProp. This may be beyond my ability.
"C:/flexprop/bin/flexspin" -2 -l --tabs=8 -D_BAUD=230400 -O1 -Wall --charset=utf8 -I "C:/flexprop/include" "C:/Wiznet/Wiznet.c"
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2023 Total Spectrum Software Inc. and contributors
Version 6.0.1 Compiled on: Mar 15 2023
Wiznet.c
w5x00_spi.h:39: error: Internal error, unknown type 69 passed to IsArrayType
w5x00_spi.h:39: error: Internal error, unknown type 69 passed to IsArrayType
w5x00_spi.h:48: error: Internal error, unknown type 69 passed to IsArrayType
w5x00_spi.h:48: error: Internal error, unknown type 69 passed to IsArrayType
child process exited abnormally
Finished at Thu Mar 16 18:24:07 2023
@ke4pjw said:
No dice with the current version of FlexProp. This may be beyond my ability.
"C:/flexprop/bin/flexspin" -2 -l --tabs=8 -D_BAUD=230400 -O1 -Wall --charset=utf8 -I "C:/flexprop/include" "C:/Wiznet/Wiznet.c"
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2023 Total Spectrum Software Inc. and contributors
Version 6.0.1 Compiled on: Mar 15 2023
Wiznet.c
w5x00_spi.h:39: error: Internal error, unknown type 69 passed to IsArrayType
w5x00_spi.h:39: error: Internal error, unknown type 69 passed to IsArrayType
w5x00_spi.h:48: error: Internal error, unknown type 69 passed to IsArrayType
w5x00_spi.h:48: error: Internal error, unknown type 69 passed to IsArrayType
child process exited abnormally
Finished at Thu Mar 16 18:24:07 2023
You should tag @ersmith on bugs like this to make sure he sees them.
@ke4pjw : those internal errors should be fixed in 6.0.2, which I've just put up for download.
@Electrodude : thanks, yes, it's helpful to tag me on any FlexProp bugs, particularly in the 6.0.x series. I really want to make 6.0.x stable, so I'm going to focus on bug fixes there.
Thank you @ersmith and @Electrodude. I am too ignorant of FlexProp to know that was not an error I caused, somehow. That was the exact file I had edited the pins in and even when replacing it with one I downloaded, it still errored. I wasn't sure if something was cached or I was doing something wrong. I usually blame myself before blaming the tool.
I was able to get it to compile and it does not complain about anything when loaded, however it does not appear to support the W6100. It just stops after the initialization.
There is a RP2040 package for the W6100. I might see if I can get it to work.
Well, I have made my way though much of it. Thanks for placing your initials in the things that needed commenting out. That helped a lot. It's starting to make sense what is where. But now I have come to one of those problems that just makes me want to cry. Getting errors on line numbers that don't exist in the file. I feel as though I am close.
@ke4pjw : maybe there's more than one file named "spi.c" (maybe in different directories)? Have you tried clicking on the blue hyperlink next to the error message? That should take you to the file and line where the error happened.
@ke4pjw : Hmmm, it looks like the errors are probably actually in w5x00_spi.c. It seems like perhaps you re-enabled some stuff that @Rayman had commented out that didn't work on the P2? the gpio_xxx functions in particular sound more like Arduino functions.
@ersmith said:
maybe there's more than one file named "spi.c" (maybe in different directories)? Have you tried clicking on the blue hyperlink next to the error message? That should take you to the file and line where the error happened.
Yes, clicking the hyperlink results in what you see in the screenshot. I am sure this is because of something weird I have done. I just don't know what it could be. I looked in the library path for an spi.c, but found none.
@ersmith said:
@ke4pjw : Hmmm, it looks like the errors are probably actually in w5x00_spi.c. It seems like perhaps you re-enabled some stuff that @Rayman had commented out that didn't work on the P2? the gpio_xxx functions in particular sound more like Arduino functions.
I will dig around this evening and look. Thank you!
Oh, wow there is regular C code for W6100. Good find. I have an interest in that too.
Maybe I'll try to buy a W6100 module so I can help. Was none available last time I looked though...
The incorrect file name reported for the bugs is a very bizarre special case error which I had a really hard time reproducing -- it only happens if the name of the #included file exactly matches the last part of the original file. In this particular case it was complicated because the original file was named "SPI.c" but it was included as "spi.c", which appears at the end of "w5x00_spi.c". Sorry you've had such bad luck in hitting bizarre edge case bugs, @ke4pjw ! I have uploaded a new flexprop release (6.0.4) which fixes this.
@Rayman Awesome! Thank you sir! I have verified that my board does work in SPI mode and updated my own driver in the repo. It will go out in the morning post. The pinout to the board is available in the Operation Manual. Again, thank you!
@ersmith Thanks for looking into this. I will download 6.0.4 and take another swing at it. I always seem to find the weird bugs! BTW, I noticed my Patreon payment method needed to be updated. I got that squared away. Thank you for all you do!
Comments
@ke4pjw Thanks. Does sound better when you put it like that.
Wireshark is pretty handy for getting actual download times.
Turned the inline assembly for block SPI transfers back to C and download time increased to 0.67 seconds.
So, inline assembly does help SPI a little...
Added "volatile" to that inline assembly and time decreased to 0.350 seconds.
~ 7 Mbps.
That was with 250 MHz P2 clock.
Increased P2 clock to 300 MHz.
Now at 0.317 seconds.
7.8 Mbps. Guess that's good enough for now...
A dedicated SPI cog could probably improve bulk transfer speed, but don't want to do that...
@rayman I don't use a dedicated cog to communicate with the W6100. I just use locks and it works fine, even when streaming multi-megabit UDP data to the light controller, the webserver is peppy.
Figured out how to use the fetch API to send commands & receive data from Propeller2.
Maybe it's a hack, but the button uses fetch to get the file "P56.txt".
Added some C code to check if that filename is requested and if so to toggle P56.
Here's some fun...
Created this interactive web page that displays all P2 pin status and toggles the pin (_drvnot) when clicked.
You can do
background-image: linear-gradient(90deg, #9FCFFF, white 90px);to replacebackground-image: url(blegtext.gif); background-repeat: repeat-y;and get rid of the image file. (well, it's slightly smoother and the ramp is different, but who cares?)@Wuerfel_21 That does work, thanks. But, having the file there is good for testing...
Looking at adding in ftp. Example looks like it needs 3 sockets, but I only have two left...
Think I'll try taking one away from http, giving it just 3 and see how it does.
I'm thinking the ftp server would be nice for uploading/downloading from uSD card...
FTP server seems to be working now, well sorta.
It seems it can't really do much without a file system...
Was surprised it asked for username and password.
Had to look up: user=wiznet, pw=wiznet54321
Guess I have to add in uSD support before it can do anything interesting...
FTP is now working with uSD card (note: you probably need to change pin definitions for uSD in Platfrom.h, I'm using different ones than Eval board).
get, put, and dir work. That's all I use, so not sure what else may or may not work.
Next, want to add uSD support to the HTTP part, so don't have to store files in RAM.
Here it is configured for P2 Eval board.
Remembered that I have this IDC extension cord for Eval that let me use this too wide adapter...
Had to drop the clock from 250 MHz to 160 MHz to make it work, have to check on that...
BTW: username and pw are both "w" now (because I got tired of typing long ones)
Ok, there was a pretty bad bug in nearly all previous versions. Amazing it worked at all...
Seems I called DNS_init() after using DNS instead of before.
This probably made the code use random addresses for the buffer.
Effect was that it wouldn't work on P2 Eval when clock was above 160 MHz. Very strange effect, but all better now.
This version has Platform.h setting for P2 Eval board with basepin=16.
The HTTP server can now serve files from uSD card.
I think bad things might happen if you try to ftp and http large uSD files at the same time though...
Think I'm about done here now. Just need to clean up and remove a lot of the embedded web content that is eating up HUB RAM. Can put all that on uSD now...
@Rayman I am going to use your code to validate that SPI works on my boards. Thank you for your work on this!!
This should work with the latest version of FlexProp, correct?
Hope so. Good luck!
No dice with the current version of FlexProp. This may be beyond my ability.
You should tag @ersmith on bugs like this to make sure he sees them.
@ke4pjw : those internal errors should be fixed in 6.0.2, which I've just put up for download.
@Electrodude : thanks, yes, it's helpful to tag me on any FlexProp bugs, particularly in the 6.0.x series. I really want to make 6.0.x stable, so I'm going to focus on bug fixes there.
Thank you @ersmith and @Electrodude. I am too ignorant of FlexProp to know that was not an error I caused, somehow. That was the exact file I had edited the pins in and even when replacing it with one I downloaded, it still errored. I wasn't sure if something was cached or I was doing something wrong. I usually blame myself before blaming the tool.
Again, Thanks!
I was able to get it to compile and it does not complain about anything when loaded, however it does not appear to support the W6100. It just stops after the initialization.
There is a RP2040 package for the W6100. I might see if I can get it to work.
https://github.com/Wiznet/RP2040-v6-HAT-C
My C chops are not good, but I will take a swing at it. Thank you for your work on this @Rayman.
I was looking into that but think all the code I found was C++
Well, I have made my way though much of it. Thanks for placing your initials in the things that needed commenting out. That helped a lot. It's starting to make sense what is where. But now I have come to one of those problems that just makes me want to cry. Getting errors on line numbers that don't exist in the file. I feel as though I am close.
Any ideas why this is happening?
@ke4pjw : maybe there's more than one file named "spi.c" (maybe in different directories)? Have you tried clicking on the blue hyperlink next to the error message? That should take you to the file and line where the error happened.
@ke4pjw : Hmmm, it looks like the errors are probably actually in w5x00_spi.c. It seems like perhaps you re-enabled some stuff that @Rayman had commented out that didn't work on the P2? the gpio_xxx functions in particular sound more like Arduino functions.
Yes, clicking the hyperlink results in what you see in the screenshot. I am sure this is because of something weird I have done. I just don't know what it could be. I looked in the library path for an spi.c, but found none.
I will dig around this evening and look. Thank you!
Oh, wow there is regular C code for W6100. Good find. I have an interest in that too.
Maybe I'll try to buy a W6100 module so I can help. Was none available last time I looked though...
Or, I guess I could buy one of your boards if can't find module. Don't need 8-bit now, but might in the future...
I still can't find a WIZ610io anywhere and the official store gives me "Forbidden".
@ke4pjw Just ordered one of your boards!
The incorrect file name reported for the bugs is a very bizarre special case error which I had a really hard time reproducing -- it only happens if the name of the #included file exactly matches the last part of the original file. In this particular case it was complicated because the original file was named "SPI.c" but it was included as "spi.c", which appears at the end of "w5x00_spi.c". Sorry you've had such bad luck in hitting bizarre edge case bugs, @ke4pjw ! I have uploaded a new flexprop release (6.0.4) which fixes this.
@Rayman Awesome! Thank you sir! I have verified that my board does work in SPI mode and updated my own driver in the repo. It will go out in the morning post. The pinout to the board is available in the Operation Manual. Again, thank you!
@ersmith Thanks for looking into this. I will download 6.0.4 and take another swing at it. I always seem to find the weird bugs! BTW, I noticed my Patreon payment method needed to be updated. I got that squared away. Thank you for all you do!
Yep, that has me going in the right direction!