These are chat archives for SmingHub/Sming

6th
Jul 2017
frankdownunder
@frankdownunder
Jul 06 2017 11:23

I have stuff building on Windows, latest Sming, latest SDK, but it would be more correct to say "limping".
I changed over to Windows 10 a couple of weeks ago; I had been developing under Ubuntu, but it is annoying , I have to start a virtual machine, and work in with an OS that is not in my comfort zone..

So I took the plunge and initially got stung by MinGW 64 bit - a dead-end that took time.
Got things going using chocolatey, only to discover that my code didnt compile anymore as I am using
functions from the latest Sming which chocolatey didnt install.
Being up for the challenge I thought I would update to the latest Sming, so did a git clone , but things went pear shaped big time. In for a penny in for a pound . . . I got the latest SDK (2.2.1) and started out on a long journey trying to understand why everything is so temperamental.
I had to hack a lot of stuff, but I can now build Basic_Blink, and my own projects as well.

Here is a summary of what I did - whether it is all necessary or not, I do not know.

Environment
c:/Espressif
Changelog.txt says I am at v2.2.1 (I only recently read Slaffs message that "We don't support SDK 2.1.0 [or higher]" )
c:/Espressif/xtensa-lx106-elf/bin/xtensa-lx106-elf-g++ -v --> 5.2.0
c:\tools\sming:
Readme.md --> Latest Stable Release Sming V3.2.0
PATH - I have C:\MinGW\bin;C:\MinGW\msys\1.0\bin at the end of my path, but I have noticed that make.exe sometimes changes it to
. . ./C/MinGW/bin:/usr/bin and that is not ideal since /usr/bin doesnt seem to be right to me.
Occasionally I found I got better results with mingw32-make.exe instead of make.exe

git status -->
Sming/Makefile:
I found that $(shell find SmingCore -type d) caused grief so I made it SmingCore SmingCore/Network SmingCore/Platform SmingCore/Network/Http SmingCore/Network/Http/Websocket instead
Within the makefile the PATH gets reset somehow,
so to hack that I set
AR := c:\Espressif\xtensa-lx106-elf\bin\xtensa-lx106-elf-ar
Sming/Makefile-project.mk:
I took these lines out
SMING_HOME := $(subst \,/,$(addprefix /,$(subst :,,$(SMING_HOME))))
ESP_HOME := $(subst \,/,$(addprefix /,$(subst :,,$(ESP_HOME))))
export PATH := $(ESP_HOME)/xtensa-lx106-elf/bin:$(PATH) ( seemed to
I took the -Werror away from the CFLAGS
Sming/Makefile-windows.mk:
I changed python to py -3
Sming/spiffy/Makefile:
I changed gcc to C:\Espressif\xtensa-lx106-elf\bin\xtensa-lx106-elf-gcc
I changed
INCDIR := -I../Services/SpifFS -I../third-party/spiffs/src
to
INCDIR := -IC:\MinGW\msys\1.0\include\sys -I../Services/SpifFS -I../third-party/spiffs/src

Finally I set ENABLE_CUSTOM_PWM=0 everywhere I could. eg in Makefile-user.mk, since I gave up on PWM
As for esptool2.exe I cant remember how i got that. I may have built it from Visual Studio.

My observation is that 90% of developers who are tempted like me to use sming are not that fussed about recompiling sming. They are more interested in wanting to get on fiddling with their gadgets, and the last thing we want to see them do is go back to the dark side and use the Arduino IDE !
Is it unreasonable to just share a copy of libsming.a by including a copy in the repository? (and any others bits and bobs). Alternatively, can we make the build system less fragile?
By "we" I mean also me, but I know nothing about chocolately, only a little about makefiles,
and not much confidence, so I would need a lot of help.

Gabriel
@gbl08ma
Jul 06 2017 11:57
is it just me or are the custom pwm and umm malloc submodules broken?

```Fetching third-party/pwm/ ...

error: pathspec 'Sming/third-party/pwm/' did not match any file(s) known to git.

Did you forget to 'git add'?

make: * [third-party/pwm/pwm.c] Error 1```

slaff
@slaff
Jul 06 2017 11:58
cd $SMING_HOME; make dist-clean; make
Gabriel
@gbl08ma
Jul 06 2017 11:59
oh, it happened in a fresh clone of my fork but not of upstream
I guess I need dist-clean then. I had no idea it existed
submodule configuration must have become messed up in one of the merges, so bad it affects even fresh clones
slaff
@slaff
Jul 06 2017 12:02
cd $SMING_HOME/../; git checkout .gitmodules
Of course you have to make sure that you have clean repo. If there are merge conflicts, etc issues you have to solve them before doing anything else
Gabriel
@gbl08ma
Jul 06 2017 12:03
there are no merge conflicts
slaff
@slaff
Jul 06 2017 12:04
type git status to see the current state.
all submodules are correctly fetched until pwm
I don't think there are any diff between the gitmodules in my fork and the one in upstream, but let me check
there are no differences, it must have been something else
it's likely this was already broken many merges ago, and it's only manifesting itself now because custom PWM became default
Gabriel
@gbl08ma
Jul 06 2017 12:10
I wonder if git version has anything to do with this. mine is still on 1.9.1, this is an old linux mint install.
It wouldn't work on upstream if that was the case, though
I might have found the culpirit, gbl08ma/Sming@c23b1f6
apparently my "fix" consisted of deleting submodules, but I can't remember why I did that. I should have used a better commit message...
slaff
@slaff
Jul 06 2017 12:13
Ok, then remove that commit and you should be able to work on your fork.
Gabriel
@gbl08ma
Jul 06 2017 12:13
I reverted that commit, it appears to work now, of course.
at least it fetched all submodules and it's compiling now
now, to find out why my program only has 9000 bytes free heap when many moons ago in much older sming versions it had over 20000...
it doesn't help that when browsers load the web page, they open like 5 simultaneous connections, making the esp crash almost instantly due to lack of ram
I suppose I can use a script or something to merge all the JS, CSS and images into one file. then the browser only only need to load the index.html and the websocket connection
fun fact: that JS file always fails to load when the page is fully refreshed (i.e. without cache). unless I open it directly
CONNECTION DROPPED (3856) appears in the serial debug output, so I guess that's why
slaff
@slaff
Jul 06 2017 13:13
@gbl08ma On one side merging Js and CSS will help a lot. On the other side I can think of adding HTTP caching rules that instruct the browser to keep the files in cache for longer time ( at the moment it seems to fetch them over and over again. )
Gabriel
@gbl08ma
Jul 06 2017 13:13
actually, browser caching is working fine
the problem is that at times (for example, on first use...) all files must be loaded
and I don't have enough free RAM for that even
I'm trying to understand where the RAM went. it's true my software has grown a bit, but not so much as to lose over 10 KB of heap over time
I'm now trying to understand where the RAM is used
there are 23376 bytes of heap free at boot; after all things are initialized and servers are started, only ~14000 bytes remain
slaff
@slaff
Jul 06 2017 13:16
Are you using the SSL build? If yes - then the RAM went there. I will be happy also if you can find other places that can be optimized.
Gabriel
@gbl08ma
Jul 06 2017 13:16
I recall that on earlier (like, one or two years ago) versions of sming, I had like 40000 bytes of free heap on boot
I suppose the static ram usage has grown a lot. but for the most part, it's not my code
the command processor also takes like 2KB of ram. it's always been like this (command descriptions are probably stored in RAM and they are quite lengthy, I wonder if it could be modified to take const pointers so the strings never leave flash)
I'm not using the SSL build, as I didn't enable it explicitly and supposedly it's disabled by default?
slaff
@slaff
Jul 06 2017 13:18
If you don't use CommandHandler/Executor that you can try this:
cd $SMING_HOME
export ENABLE_CMD_EXECUTOR=0
make dist-clean
make
Gabriel
@gbl08ma
Jul 06 2017 13:19
the problem is, that I use it quite heavily ;)
well, time to start listing symbols and stuff like that to understand where static ram is used...
slaff
@slaff
Jul 06 2017 13:24
xtensa-lx106-elf-readelf -s app.out | grep OBJECT | grep ': 3' | sort -k3 -n | tail
Gabriel
@gbl08ma
Jul 06 2017 13:25
thank you
I see http_strerror_tab from the 3rd-party http_parser apparently goes to RAM
isn't this just a map of constant strings?
slaff
@slaff
Jul 06 2017 13:49

isn't this just a map of constant strings?

Yes, it is. You can send a PR that stores them on FLASH.

I believe it's a matter of adding 'const' to that line
however, how would one go about patching this on a 3rd-party component?
I suppose a diff needs to be made?
slaff
@slaff
Jul 06 2017 13:57

I believe it's a matter of adding 'const' to that line

Unfortunately that is not the only thing that needs to be done. Other "normal" compilers will optimize that part and put it in FLASH but with the current compiler you should also add an attribute to store it in FLASH.

What you can do is collect a list of valid global objects that can be optimized and give me a list of them. Then I can take care to instruct the compiler to put them in FLASH.

Gabriel
@gbl08ma
Jul 06 2017 14:13
it's probably best that I open a new issue...
Gabriel
@gbl08ma
Jul 06 2017 14:32
there's a 1648 bytes switch table, but I'm not sure what it corresponds to nor if it could be put in flash
laurentppol
@laurentppol
Jul 06 2017 20:07
Hello there,
I am getting crazy error:
after changing my app a bit, but only at "virtual" layer, in does not start anymore, I am getting:
Fatal exception (28):
epc1=0x4000228b, epc2=0x00000000, epc3=0x00000000, excvaddr=0x000000b5, depc=0x00000000
any ideas? What is this code meaning?
laurentppol
@laurentppol
Jul 06 2017 20:24
NodeMCU, 4M flash
laurentppol
@laurentppol
Jul 06 2017 20:45
SDK 2.0.0
Sming NoNos develop @ 15.02.2017
laurentppol
@laurentppol
Jul 06 2017 21:09
no changes in network-related code
laurentppol
@laurentppol
Jul 06 2017 21:21

```// DEBUG

if defined(AVR)

    #if defined(I2C_IO)
                            if (pwm_output == 100) { i2c_output &= ~_BV(LCD_BACKLIGHT); }
                                else { if (pwm_output != 0) {
                                    if (pwm_output >= 10) {
                                        if ((pwm_timer % 10) < (pwm_output / 10)) { i2c_output &= ~_BV(LCD_BACKLIGHT); }
                                            else                              { i2c_output |= _BV(LCD_BACKLIGHT); }
                                                          }
                                    else    {
                                        if (pwm_timer  < pwm_output) { i2c_output &= ~_BV(LCD_BACKLIGHT); }
                                            else                     { i2c_output |= _BV(LCD_BACKLIGHT); }
                                            }
                                                            }
                                     }
    #endif
     /* I2C_IO */

endif

// /DEBUG```

if I remove #if / endif I got crash, program compiles and works on AVR
laurentppol
@laurentppol
Jul 06 2017 21:36
just moved the code outside HARDWARE timer int, looks working :|