yes
belongs to first question? 😀
hello folks, having a weird behaviour in mos
tool while trying to add a library to my project.
The library is https://github.com/ellavas/mongoose-lib-hlw8012
, when I checkout the project and build it by itself it works fine (it returns a nice Lib saved to build/lib.a
)
Although, when I add the dependency to my project with
libs:
- origin: https://github.com/ellavas/mongoose-lib-hlw8012
I get the following error:
CC /home/leo/dev/mos/app-demo/build/gen/build_info.c
LD /home/leo/dev/mos/app-demo/build/objs/app-demo.elf
/opt/Espressif/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/9.2.0/../../../../xtensa-lx106-elf/bin/ld: /home/leo/dev/mos/app-demo/build/objs/mgos_deps_init.c.o:(.rodata.mgos_libs_info+0x104): undefined reference to `mgos_mongoose_lib_hlw8012_init'
collect2: error: ld returned 1 exit status
/home/leo/dev/mos/app-demo/deps/modules/mongoose-os/platforms/esp8266/Makefile.build:360: recipe for target '/home/leo/dev/mos/app-demo/build/objs/app-demo.elf' failed
make: Leaving directory '/app'
make: *** [/home/leo/dev/mos/app-demo/build/objs/app-demo.elf] Error 1
Error: exit status 2
any ideas or workaround? I'd be happy to use directly the lib.a
file if there's a way to do so (though is not ideal)
answering my own question for other people benefit, I could either use
binary_libs:
- mylib/mylib.a
as per documentation, or override lib name (the init method apparently is built conventionally using lib name) via
- origin: https://github.com/ellavas/mongoose-lib-hlw8012
name: hlw8012 # this makes the trick
Hello guys, please, how to use correctly TLS client authentication when doing HTTPS request? Is it enough to set path to client certificate and key files:
struct mg_connect_opts opts;
opts.ssl_cert = "client_cert.pem";
opts.ssl_key = "clien_key.pem";
And then pass this opts struct to mg_connect_http_opt
function? Because when i do this as i described i get errors like:
[Mar 1 10:40:35.710] mongoose.c:4912 0x3fff194c received handshake message
[Mar 1 10:40:35.786] mongoose.c:4912 0x3fff194c mbedtls_ssl_flush_output() returned -78 (-0x004e)
[Mar 1 10:40:35.786] mongoose.c:4912 0x3fff194c mbedtls_ssl_write_record() returned -78 (-0x004e)
[Mar 1 10:40:35.786] mongoose.c:4912 0x3fff194c mbedtls_ssl_send_alert_message() returned -78 (-0x004e)
@hdmt-hock Did you try this?
Thank you @nliviu, the links works only after "brew unlink mos". This step is necessary if you have "latest version" installed and want to change to "released version". Please update the documentation. Just a comment, I did know those steps in the link and it did not works previously (meaning before 25 feb), I guess something has changed. Is "mos update release" and "mos update latest" still works?
confused on the parameters given for timer_callback, in particular how to convert the void pointer to an int.
#include "mgos.h"
static void timer_cb(void * arg) {
//int ledPin = *((int *) arg);
int ledPin = *(int*) arg;
static bool s_tick_tock = false;
LOG(LL_INFO,
("%s uptime: %.2lf, RAM: %lu, %lu free on pin %i", (s_tick_tock ? "Tick" : "Tock"),
mgos_uptime(), (unsigned long) mgos_get_heap_size(), (unsigned long) mgos_get_free_heap_size(), ledPin));
s_tick_tock = !s_tick_tock;
if (ledPin >= 0) {
mgos_gpio_toggle(ledPin);
}
}
enum mgos_app_init_result mgos_app_init(void) {
int ledPin = mgos_sys_config_get_board_led1_pin();
if (ledPin >= 0) {
mgos_gpio_setup_output(ledPin, 1);
}
mgos_set_timer(1000 /* ms */, MGOS_TIMER_REPEAT, timer_cb, &ledPin);
LOG(LL_INFO, ("pin %i", ledPin));
return MGOS_APP_INIT_SUCCESS;
}
i have tried the above code on an esp32 and an esp8266 and the results are pretty consistent. the LOG statement in mgos_app_init() will show the correct pin number for LED1 ( 2 or 13 ).
when i try to dereference the void pointer in timer_cb(), it doesn't show the the same number as i pass in; on the esp8266 it will almost always show -1, while on the esp32 it will vary widely.
my intent is to be able to have the same callback function just with a different pin number assigned to it ( and wait time fwiw ) depending on the remain logic.
I'm sure i'm doing something silly and any help would be appreciated. Thank you.
/home/MY_USER_NAME/...
are stripped from final FW binary? Thank you.
mos build --clean --local --platform=ESP8266
is stuck at Docker arguments: run --name mos_build_ ...
again. This is my 2nd build today, I had terminate a previous build and restart the build. The last time the mos build stuck at docker was about a week ago when using mos latest '74. Now with mos release 2.19.1 , same issue. Is this related to docker limitation of 200 container pull per 6 hr?
currently the mos build local on mac os mojave stuck at
CC /Volumes/Hidromotic/github/hidromotic/acueducto_sarah/pozo/esp/build/gen/mg_build_info.c
for the last hour. CTRL-C and rebuild, restart docker and rebuild, clean and rebuild.. stuck at the above line. Is mos under some maintanence schedule?
Hi, I try to upgrade my project to Mongoose-OS v2.19.1 and get this error wiht local build:
Generating esp32.project.ld
LD /home/mark_wahlberg/git/my-app/build/objs/my-app.elf
/opt/Espressif/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /home/mark_wahlberg/git/my-app/build/objs/mosapp/libmosapp.a(mgos_freertos_core_dump.c.o):(.text.mgos_freertos_core_dump+0x20): undefined reference to `mgos_freertos_extract_regs'
/opt/Espressif/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /home/mark_wahlberg/git/my-app/build/objs/mosapp/libmosapp.a(mgos_freertos_core_dump.c.o): in function `mgos_freertos_core_dump':
/home/mark_wahlberg/git/my-app/deps/freertos/src/mgos_freertos_core_dump.c:40: undefined reference to `mgos_freertos_extract_regs'
collect2: error: ld returned 1 exit status
make: *** [/home/mark_wahlberg/git/my-app/build/objs/my-app.elf] Error 1
/opt/Espressif/esp-idf/make/project.mk:563: recipe for target '/home/mark_wahlberg/git/my-app/build/objs/my-app.elf' failed
make: Leaving directory '/app'
Does anyone have a clue for me?
@hoffmann-m In the current version of esp-idf (4.2-r1), mgos_freertos_extract_regs
definition is protected by CONFIG_ESP32_ENABLE_COREDUMP_TO_UART.
In previous versions there was simply a #if 1
.
Hi all, any idea what could I check if my OTA via HTTP GET is not working (and it was working 3 weeks ago).
I use a Google Cloud Storage bucket to store the fw.zip file, and generate a V4 signed key URL to download it, which is passed onto the mgos_ota_http_start function. The mgos_ota_http_start function receives the URL but does not start the OTA process - just seems stuck.
[Mar 11 10:06:49.741] mgos_ota_http_clien:270 Update URL: https://randomstorage.storage.googleapis.com/fw.zip?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=...
[Mar 11 10:06:49.869] mg_ssl_if_mbedtls.c:35 0x3fff6354 ciphersuite: TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
[Mar 11 10:06:50.442] SW ECDSA verify curve 3 hash_len 32 sig_len 71
[Mar 11 10:06:55.666] SW ECDH curve 3
[Mar 11 10:07:00.587] mgos_mongoose.c:66 New heap free LWM: 6864
I am happy to share more of the code, but since it once was reliably working, I firmly believe that the issue is with credentials or something. I would appreciate your help, as I am really confused and disappointed that something that worked is not working after 2 weeks.