Ok, changing the receive buffer back to 1024 hides the issue with running out of memory in the httpd server.
in SSCP.h
#define SSCP_RX_BUFFER_MAX 1024
The reason I had changed this value is I make a webservice call that returns 14k of data and with it set to 1024 I lost 90% of the return information. 1024 is too small.
The way I see it for the P2 is not make any changes to the firmware on the ESP unit.
The loadp2 program needs to be enhanced to send a 'cgiPropReset' web request followed by using a telent connection to load the program just like it does today.
It would need to either be provided with the IP address of the P2 on the command line or have UDP functions added to it so it can find the WX module.
If the FlexProp code was modified to do the UDP request to get the IP address of the WX module it could then send the IP address to the loadP2 program and it would be off and running since the program would follow that request with the terminal request so the person could see the Hello World being return from the P2.
Sorry, I didn't mean to be critical of your work. I just wanted to point out a possible downside to that approach. Another is that the current filesystem code doesn't reclaim the space used by files that are overwritten. You eventually have to empty the filesystem and start over if you keep rewriting the same file over and over. It would be better to find a more robust flash filesystem to use but the other options I found at the time used too much SRAM.
None taken- I'm glad you raised it, and thanks for all your support and ideas.
What do you think would be involved in implementing a streaming solution ? Does the existing P1 programming code already buffer and stream ?
Ok, changing the receive buffer back to 1024 hides the issue with running out of memory in the httpd server.
in SSCP.h
#define SSCP_RX_BUFFER_MAX 1024
The reason I had changed this value is I make a webservice call that returns 14k of data and with it set to 1024 I lost 90% of the return information. 1024 is too small.
Mike
Good find! I'll adjust that and report back over the weekend.
Sorry, I didn't mean to be critical of your work. I just wanted to point out a possible downside to that approach. Another is that the current filesystem code doesn't reclaim the space used by files that are overwritten. You eventually have to empty the filesystem and start over if you keep rewriting the same file over and over. It would be better to find a more robust flash filesystem to use but the other options I found at the time used too much SRAM.
None taken- I'm glad you raised it, and thanks for all your support and ideas.
What do you think would be involved in implementing a streaming solution ? Does the existing P1 programming code already buffer and stream ?
Sounds like Mike thinks it can be done by just changing the loadp2 loader and not changing the WX firmware. I'm afraid I haven't looked at the P2 loader protocol closely enough to comment.
The reset pulse will be different. I'll add an api call for P2 reset whilst I'm recompiling. Then if someone smarter can add the reprogramming as-is, that will be fab!
The reset pulse will be different. I'll add an api call for P2 reset whilst I'm recompiling. Then if someone smarter can add the reprogramming as-is, that will be fab!
Question, why would the reset be different if it already just pulses the reset pin like the P1. I use a prop plug on both my P1 and my P2 and it works just fine. So the WX module should do the same right?
Well, I just built some C# test code and hooked up my ESP WX unit to the P2 port and using a manual reset for now was able to load a program onto the P2 without to much trouble.
Even better. Can you share the Visual Studio/Code solution ?
I'm thinking I could ask Jeff if he is able to add something like that to the Propeller Tool. Would improve the chances to show an example.
Every time I dive into this I end up with some SDK problem to resolve. Any idea how to get around this? I did a "git pull" to make sure I had the latest code from the repository.
CC espfs/heatshrink_decoder.c
In file included from ./include/esp8266.h:33:0,
from espfs/heatshrink_decoder.c:9:
/Users/dbetz/Dropbox/parallax/Parallax-ESP/ESP8266_NONOS_SDK/include/mem.h:47:40: error: expected declaration specifiers or '...' before string constant
#define os_free(s) vPortFree(s, "", 0)
^
/Users/dbetz/Dropbox/parallax/Parallax-ESP/ESP8266_NONOS_SDK/include/mem.h:47:44: error: expected declaration specifiers or '...' before numeric constant
#define os_free(s) vPortFree(s, "", 0)
^
/Users/dbetz/Dropbox/parallax/Parallax-ESP/ESP8266_NONOS_SDK/include/mem.h:48:43: error: expected declaration specifiers or '...' before string constant
#define os_malloc(s) pvPortMalloc(s, "", 0)
^
/Users/dbetz/Dropbox/parallax/Parallax-ESP/ESP8266_NONOS_SDK/include/mem.h:48:47: error: expected declaration specifiers or '...' before numeric constant
#define os_malloc(s) pvPortMalloc(s, "", 0)
^
make[1]: *** [build/espfs/heatshrink_decoder.o] Error 1
make: *** [libesphttpd] Error 2
I need to cleanup the build process. Maybe it would be best to pull the http server code into the Parallax project so it's easier to maintain. The original author seems to have abandoned it anyway.
I agree. Especially as we have some edits in those files. At my git fork I added a copy of the libesphttpd module to preserve the local changes during this experimental process.
1. Issue reset to board.
2. Send "> Prop_Chk 0 0 0 0 " which will return "\r\nProp_Ver G\r\n". A - Rev A, G - Current P2
3. Send "> Prop_Hex 0 0 0 0" followed by program to load data in space Hex Format " 01"
4. Send "~" All data has been sent run code
This is much simpler than the P1 which required special data to be sent first.
The current P2 loader just loads a small bootloader program that allows for faster loading and for following the program load with data files or more code that can be loaded at different addresses in memory which the simple loader does not provide.
Since the load data for the simple loader does not send any special characters, commands on the ESP WX module don't need to be turned off.
I was just looking at the Espressif GitHub repository for the ESP8266 SDK and it seems that the ESP8266_NONOS_SDK is no longer being developed. They recommend using the ESP8266_RTOS_SDK gong forward. Has anyone tried that SDK?
The reset logic for the P1 works just fine for the P2.
It might do marginally, or in certain dipswitch settings. The hard coded delay is 100ms, which happens to match the timeout of the P2 serial mode in certain settings. In the version of Parallax-ESP in my repo, that was reduced to 35ms for the P2, to ensure compatibility in as many modes as possible, and to keep away from the theoretical 100ms limit.
Thanks for posting the P2 programming steps. Clearly I'm aware of those, as I just published a P2-Loader
A good reference for the forum though.
I was just looking at the Espressif GitHub repository for the ESP8266 SDK and it seems that the ESP8266_NONOS_SDK is no longer being developed. They recommend using the ESP8266_RTOS_SDK gong forward. Has anyone tried that SDK?
I just downloaded the ESP8266_RTOS_SDK and tried a few of the example programs. It seems to have its own HTTP server so we might be able to move the WX firmware over to it pretty easily and be done with the unsupported server we're using now. It also has a flash filesystem. Not sure how much SRAM all this needs though.
The believe the ESP32 uses the OS and when I ported all the stuff over to the ESP32 I did use the http server and loaded the file system with all the web pages so that part should be easy enough to move over.
I did however change some of the web pages so they took advantage of some of the new features such as file listings.
I seem to remember having to change a lot of the code because the NON OS model is based on call backs and hooks and the OS version is based on events and routing or something.
The believe the ESP32 uses the OS and when I ported all the stuff over to the ESP32 I did use the http server and loaded the file system with all the web pages so that part should be easy enough to move over.
I did however change some of the web pages so they took advantage of some of the new features such as file listings.
I seem to remember having to change a lot of the code because the NON OS model is based on call backs and hooks and the OS version is based on events and routing or something.
Mike
Are your modifications on GitHub somewhere? Did you actually get it working on the ESP32? I still think it would be nice if Parallax could make a new WX module with the ESP32 in place of the ESP8266.
I had a problem with the loader code not working because the way the HTTP server works on the ESP32 unit caused the loader program to fail and could not get past that issue.
It turns out the Prop loader does not wait for all of the tcp packet to arrive and hence only has part of the data and fails there. The ESP32 sends a packet even if it's not complete.
Here is a link to the ESP32 unit running on my desktop flashed some time ago.
Comments
Ok, changing the receive buffer back to 1024 hides the issue with running out of memory in the httpd server.
in SSCP.h
#define SSCP_RX_BUFFER_MAX 1024
The reason I had changed this value is I make a webservice call that returns 14k of data and with it set to 1024 I lost 90% of the return information. 1024 is too small.
Mike
The way I see it for the P2 is not make any changes to the firmware on the ESP unit.
The loadp2 program needs to be enhanced to send a 'cgiPropReset' web request followed by using a telent connection to load the program just like it does today.
It would need to either be provided with the IP address of the P2 on the command line or have UDP functions added to it so it can find the WX module.
If the FlexProp code was modified to do the UDP request to get the IP address of the WX module it could then send the IP address to the loadP2 program and it would be off and running since the program would follow that request with the terminal request so the person could see the Hello World being return from the P2.
Mike
None taken- I'm glad you raised it, and thanks for all your support and ideas.
What do you think would be involved in implementing a streaming solution ? Does the existing P1 programming code already buffer and stream ?
Good find! I'll adjust that and report back over the weekend.
Mike
Well, I just built some C# test code and hooked up my ESP WX unit to the P2 port and using a manual reset for now was able to load a program onto the P2 without to much trouble.
Now I have to investigate the reset function.
Mike
The reset logic for the P1 works just fine for the P2.
I now have code to load a program on the P2 using the ESP WX module with no modes to the unit.
Mike
I'm thinking I could ask Jeff if he is able to add something like that to the Propeller Tool. Would improve the chances to show an example.
CC espfs/heatshrink_decoder.c In file included from ./include/esp8266.h:33:0, from espfs/heatshrink_decoder.c:9: /Users/dbetz/Dropbox/parallax/Parallax-ESP/ESP8266_NONOS_SDK/include/mem.h:47:40: error: expected declaration specifiers or '...' before string constant #define os_free(s) vPortFree(s, "", 0) ^ /Users/dbetz/Dropbox/parallax/Parallax-ESP/ESP8266_NONOS_SDK/include/mem.h:47:44: error: expected declaration specifiers or '...' before numeric constant #define os_free(s) vPortFree(s, "", 0) ^ /Users/dbetz/Dropbox/parallax/Parallax-ESP/ESP8266_NONOS_SDK/include/mem.h:48:43: error: expected declaration specifiers or '...' before string constant #define os_malloc(s) pvPortMalloc(s, "", 0) ^ /Users/dbetz/Dropbox/parallax/Parallax-ESP/ESP8266_NONOS_SDK/include/mem.h:48:47: error: expected declaration specifiers or '...' before numeric constant #define os_malloc(s) pvPortMalloc(s, "", 0) ^ make[1]: *** [build/espfs/heatshrink_decoder.o] Error 1 make: *** [libesphttpd] Error 2maybe ?
1. Issue reset to board.
2. Send "> Prop_Chk 0 0 0 0 " which will return "\r\nProp_Ver G\r\n". A - Rev A, G - Current P2
3. Send "> Prop_Hex 0 0 0 0" followed by program to load data in space Hex Format " 01"
4. Send "~" All data has been sent run code
This is much simpler than the P1 which required special data to be sent first.
The current P2 loader just loads a small bootloader program that allows for faster loading and for following the program load with data files or more code that can be loaded at different addresses in memory which the simple loader does not provide.
Since the load data for the simple loader does not send any special characters, commands on the ESP WX module don't need to be turned off.
Mike
Everything there building now uses that OS in their product. That's why porting the code over to the ESP32 module is more complicated.
There are however some advantages in that the OS version has an HTTP server and scheduler with a TCP/IP stack.
Mike
It might do marginally, or in certain dipswitch settings. The hard coded delay is 100ms, which happens to match the timeout of the P2 serial mode in certain settings. In the version of Parallax-ESP in my repo, that was reduced to 35ms for the P2, to ensure compatibility in as many modes as possible, and to keep away from the theoretical 100ms limit.
Thanks for posting the P2 programming steps. Clearly I'm aware of those, as I just published a P2-Loader
A good reference for the forum though.
Not me.
I did however change some of the web pages so they took advantage of some of the new features such as file listings.
I seem to remember having to change a lot of the code because the NON OS model is based on call backs and hooks and the OS version is based on events and routing or something.
Mike
Parallax-ESP32
Mike
I guess I could hook it up and put it on the web and you could take a look at.
I had a problem with the loader code not working because the way the HTTP server works on the ESP32 unit caused the loader program to fail and could not get past that issue.
It turns out the Prop loader does not wait for all of the tcp packet to arrive and hence only has part of the data and fails there. The ESP32 sends a packet even if it's not complete.
Here is a link to the ESP32 unit running on my desktop flashed some time ago.
ESP32
Mike
Mike