Shop Learn
Parallax-ESP Module Latest Hack - Page 8 — Parallax Forums

Parallax-ESP Module Latest Hack

15681011

Comments

  • @VonSzarvas, @"David Betz" ,

    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

  • @VonSzarvas ,

    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
  • David Betz wrote: »

    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 ?

  • iseries wrote: »
    @VonSzarvas, @"David Betz" ,

    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.
  • David BetzDavid Betz Posts: 14,366
    edited 2020-12-11 15:56
    VonSzarvas wrote: »
    David Betz wrote: »

    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!
  • VonSzarvas wrote: »
    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!
    That sounds like a good solution.

  • 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?

    Mike
  • @VonSzarvas , @"David Betz" ,

    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
  • @VonSzarvas , @"David Betz" ,

    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
  • 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
    
  • Espmissingincludes.h
    maybe ?
  • VonSzarvas wrote: »
    Espmissingincludes.h
    maybe ?
    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.
  • Steps to load code on a P2.

    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
  • One thing we might want to look into is whether the newer versions of the SDK use more SRAM than the one we used when we first wrote the WX firmware.
  • 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?
  • It's been several years since they did any work on the NON OS SDK. I can't believe that an operating system takes up less memory.

    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
  • iseries wrote: »

    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.

  • David Betz wrote: »
    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?

    Not me.
  • 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.

    Mike
  • David BetzDavid Betz Posts: 14,366
    edited 2020-12-12 16:13
    iseries wrote: »
    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.

  • Yep, I haven't look at in a while though.

    Parallax-ESP32

    Mike

    I guess I could hook it up and put it on the web and you could take a look at.
  • It looks like you have far fewer files than the original firmware. Did you combine some files? I don't even see the loader code.
  • @"David Betz" ,

    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
  • Seems to work well. What is implemented and what is missing? Anything besides the loader?
  • Can't remember, I think just the loader code is missing and some of the cgi stuff.

    Mike
  • iseries wrote: »
    Can't remember, I think just the loader code is missing and some of the cgi stuff.

    Mike
    Well, I guess you must have completely reorganized the code because none of the filenames match the original code.
Sign In or Register to comment.