Flesh out https://github.com/SuperHouse/esp-open-rtos/blob/master/include/esp8266.h to provide register masks, values for known ESP8266 registers - GPIO, UART, etc.

Try to avoid clunky WRITE_PERI_REG-style macros, it should be possible to write clean-looking code that accesses registers directly.

To reproduce:

• Change WEB_SERVER and WEB_PORT in examples/http_get_ssl to connect to a server that rejects 1024 bit keys (chainxor.org / 443 is suitable).
• TLS handshake fails each time (PT_ALERT_PROTOCOL packet sent by server with AlertDescription 40 = handshakefailed, leads to -40 handshake result in program.)
• Reported free heap size sporadically jumps down by a large amount (~3KB) until out of memory.

Seems timing related - happens sporadically, and adding debug output around malloc/free makes it less frequent.

Happens when using both FreeRTOS malloc & newlib malloc routines.

Brainstorm of possible causes:

• Race condition in vPortEnterCritical/vPortExitCritical protection of malloc.
• axTLS memory leak in a rare code path.
• lwIP is caching/leaking pbuf/other data for stale TCP sockets in time_wait or other states.

Clean TLS sessions where the handshake succeeds are not affected by the leak.

At the moment all functions get moved from .text to .irom0 at build time, to avoid needing the ICACHE_FLASH_ATTR attribute on basically everything.

Downside is that it's currently impossible to write new code that loads into IRAM.

There should be an attribute for this, which causes the linker to place the function into IRAM.

Possibly also a mechanism in the build process, similar to the "norename list", which can move individual symbol names declared in lwip or FreeRTOS (to avoid having to put ESP-specific code into the upstream sources.) This may not be necessary though, most of the likely "hot" paths are ESP-specific in FreeRTOS portable/esp8266.

I was writing a webserver code, it worked fine till I moved my function that called "write()" to another file. Suddenly it wasn't doing anything anymore, just giving errors.

I was attempting to see if I was getting the same write functions so I printed out the pointer:

printf("response.write=%x\n", (int) write);

turns out, this statement can't compile as write in "this file" is a macro!

Same problem exists with fcntl() function as nonblocking suddenly didn't work on stdio,
because all the levels of macros included the socket functions instead of the file functions.

CC /home/knoppix/GIT/esp-lisp-other/lisp.c
In file included from ../esp-open-rtos/libc/xtensa-lx106-elf/include/sys/fcntl.h:3:0,
from ../esp-open-rtos/libc/xtensa-lx106-elf/include/fcntl.h:1,
from /home/knoppix/GIT/esp-lisp-other/lisp.c:80:
../esp-open-rtos/libc/xtensa-lx106-elf/include/sys/_default_fcntl.h:44:0: error: "O_NONBLOCK" redefined [-Werror]
#define O_NONBLOCK _FNONBLOCK
^
In file included from ../esp-open-rtos/lwip/lwip/src/include/posix/sys/socket.h:33:0,
from /home/knoppix/GIT/esp-lisp-other/lisp.c:74:
../esp-open-rtos/lwip/lwip/src/include/lwip/sockets.h:278:0: note: this is the location of the previous definition
#define O_NONBLOCK 1 /* nonblocking I/O */

./libc/xtensa-lx106-elf/include/sys/_default_fcntl.h:23:#define _FNONBLOCK 0x4000 /* non blocking I/O (POSIX style) _/
./libc/xtensa-lx106-elf/include/sys/_default_fcntl.h:24:#define _FNDELAY FNONBLOCK / non blocking I/O (4.2 style) _/
./libc/xtensa-lx106-elf/include/sys/_default_fcntl.h:44:#define O_NONBLOCK _FNONBLOCK
./libc/xtensa-lx106-elf/include/sys/_default_fcntl.h:77:#define FNONBIO FNONBLOCK / XXX fix to be NONBLOCK everywhere */

I'm not sure how to resolve this, but having macros overriding functions gets somewhat complicated..., also having two non-compatible implementations of functions get even worse...
As I can't use "files/io" and "sockets" in the same file.

As per reports on mailing list and in comments of #31.

The current UART reading code in master doesn't seem to work.

Fix will be to implement our own UART wrapper functions and test whatever initialisation stages are necessary to set the UART RX FIFO up correctly and read/buffer characters in hardware on input.

Hi,

While converting time into a user understandable form the following link error occurs. I also attached a minimal c file, which in my case reproduces the problem. (Checked with latest master branch 2fe1b7a)

../../libc/xtensa-lx106-elf/lib/libc.a(lib_a-sysopen.o):(.literal+0x0): undefined reference to `_open_r'
../../libc/xtensa-lx106-elf/lib/libc.a(lib_a-sysopen.o): In function `open':
/home/gus/dev/esp/rtos/newlib/build/xtensa-lx106-elf/newlib/libc/syscalls/../../../../../newlib/libc/syscalls/sysopen.c:21: undefined reference to `_open_r'
collect2: error: ld returned 1 exit status

Is there something I've missed in the Makefile?

Makefile

PROGRAM=simple
include ../../common.mk

Sample Code

/* Does not link ...
 */
#include "stdio.h"
#include "time.h"

void user_init(void)
{
   time_t rawtime;
   struct tm *info;
   char buffer[80];

   time( &rawtime );

   info = localtime( &rawtime );

   strftime(buffer,80,"%x - %I:%M%p", info);
   printf("Formatted date & time : |%s|\n", buffer );

   while(1) {};
}

Calling

int ch = sdk_uart_rx_one_char();

leads to a crash inside sdk_uart_rx_one_char (if I understand the reboot log correctly):

s8i     a6, a2, 0

Since this is an SDK provided function I guess something has not been set up correctly.

The Espressif SDK includes the option for an app to install a custom "putc" function if they want stdout to go somewhere other than UART0. Currently with the newlib stuff, etc, esp-open-rtos does not actually support this, but it would be a good thing to bring back (and shouldn't be too hard).

(As a side-note, it might also be interesting to add support for registering a stderr handler as well)

Version: 5cd31c6

I'm trying to scan for APs, and I'm getting a fatal exception (28). The call to sdk_wifi_station_scan returns successful, but then I am getting a fatal exception... I suspect on the invocation of the callback. Can anyone else repro?

#include "espressif/esp_common.h"
#include "esp/uart.h"

#include <string.h>

#include "FreeRTOS.h"
#include "task.h"

#include "lwip/err.h"
#include "lwip/sockets.h"
#include "lwip/sys.h"
#include "lwip/netdb.h"
#include "lwip/dns.h"
#include "ssid_config.h"

static void scan_done(void *arg, sdk_scan_status_t status)

{
    printf("scan done with status %i\n", status);
}

void scan_task(void *pvParameters) {
    printf("About to start scan\n");
    if(sdk_wifi_get_opmode() == SOFTAP_MODE) {
        printf("ap mode can't scan !!!\r\n");
        return;
    }
    bool s = sdk_wifi_station_scan(NULL, &scan_done);
    printf("Scan call done, status: %i\n", s);

    while(1) {
        printf("scan task\n");
        vTaskDelay(4000 / portTICK_RATE_MS);
    }
}


void user_init(void)
{
    uart_set_baud(0, 74880);
    printf("SDK version:%s\n", sdk_system_get_sdk_version());
    sdk_wifi_set_opmode(STATION_MODE);
    xTaskCreate(&scan_task, (signed char *)"scan_task", 512, NULL, 2, NULL);
}

Output:

ESP-Open-SDK ver: 0.0.1 compiled @ Nov 14 2015 00:31:02

phy ver: 273, pp ver: 8.3

SDK version:0.9.9
mode : sta(18:fe:34:a6:04:74)
add if0
About to start scan
scandone
Scan call done, status: 1
scan task
Fatal exception (28):
epc1=0x4010689d
epc2=0x00000000
epc3=0x4022218e
excvaddr=0x00000000
depc=0x00000000
excsave1=0x40233489

I have completed support for this in e648cd2

The driver is placed in extras/serial-driver and there is an example program in examples/terminal showing how to include the driver (it is not included by default).

TL;DR:
_read_r in newlib_syscalls.c is now declared as weak and extas/serial-driver/serial_driver.c implements a new version of _read_r that blocks until data is available and reads from a circular buffer filled by the UART0 IRQ handler. The IRQ handler is installed on the first call to _read_rwith a small penalty for subsequent calls.

First of all, I do not know if this is the correct place to post this (is there a forum, mailing list, w/e?). Sorry in case it is not.

I've been trying to understand how the GPIO works here, and so far it is quite intuitive. But when it comes to PWM, I have no clue on how to enable it.
I successfully did so on the bare Espressif SDK, but had no luck so far with this RTOS.

Any help would be really appreciated.

Thank you!

I am trying to write a small application to configure esp8266 as SoftAP using esp-open-rtos in the example folder.

As below:
extern struct station_info* sdk_wifi_softap_get_station_info();
extern bool sdk_wifi_softap_free_station_info();
extern uint8_t sdk_wifi_softap_get_station_num();
/**************************************************

task()
{ while(true)
{
uint8_t stationCount = sdk_wifi_softap_get_station_num();
if(stationCount)
{
printf("No of stations=%d\n",stationCount);
sleep(1000);

                   struct station_info *stationInfo = sdk_wifi_softap_get_station_info();
                if (stationInfo != NULL)
               {
                while (stationInfo != NULL)
                {
                    printf("Station IP: %d.%d.%d.%d\n", IP2STR(&(stationInfo->ip)));
                    stationInfo = STAILQ_NEXT(stationInfo, next);
                }
                sdk_wifi_softap_free_station_info();
            }

}
}
I defined station_info structure in one of the .h files as seen in standard iot-sdk.

But i get linker and compiler error as "undefined reference" to these below functions:

extern struct station_info* sdk_wifi_softap_get_station_info();
extern bool sdk_wifi_softap_free_station_info();
extern uint8_t sdk_wifi_softap_get_station_num();

Are these not part of libmain.a as are other wifi functions?

How can I configure esp8266 in AP mode and get the list of stations connected using esp-open-rtos?
Are there some other API's to configure as AP?
/**************************************************

(This is spinning off a discussion from #1.)

A large part of DRAM usage is currently .rodata, and a substantial part of that is string literals. It'd be nice to store string literals in SPI flash (irom), but irom requires 4-byte aligned word reads..

These are the options that I know of, with a summary from my point of view:

Option A

Suggested by @pfalcon, add a compiler frontend attribute that forces all pointer access to go via 32-bit aligned reads.

Advantages of being generic. Disadvantage of requiring separate functions to propagate the attribute, due to C's type system, and requiring gcc changes to front-end and back-end. Tricky to apply to existing binary library code.

Option B

This is a suggestion based on Option A, which is that it would be possible to implement Option A just in terms of existing gcc primitives. ie base it around a macro that dereferences char * via a 32-bit read. I think this would end up looking similar to avrlibc's avr/pgmspace.h functions.

Advantages/disadvantages similar to Option A, although the separate functions will be more complex to write than for Option A (but no compiler changes).

Option C

This is @jcmvbkbc's suggestion, to implement an exception handler that catches the faulting read and completes it.

Advantages of requiring basically no additional code changes, could potentially work with any/all of .rodata automatically, and is potentially applicable to binary libraries by moving .rodata symbols to irom (symbols that are accessed while SPI flash is unmapped notwithstanding). Disadvantage of being slow, @jcmvbkbc thinks 2 orders of magnitude slower.

Option D

This was my original plan, which is to wrap printf(), write() and any other likely functions at compile time. Where the argument is a const at compile time, store it statically in IROM then load it into stack or heap dram at runtime and pass it to the inner wrapped function.

Advantages of being pretty easy to implement (I think), and relatively fast. Disadvantages of only applying to certain functions, although I think printf will cover a large number of use cases. Can't be applied to binary library code.

Option E (EDIT)

Suggested below and in #1, compiler flag that causes memory reads to go via l32.

***

My gut feeling at the moment is I'd like to implement (D) soon, and maybe experiment with (C) when I have some more time as it sounds interesting. I'd be open to patches that try any of these approaches, though!

In my test build, only two libhal functions are actually used, xthal_get_ccount and xthal_set_intset. xthal_get_ccount is provided in ROM, so it can easily be eliminated. That just leaves one instance of xthal_set_intset in FreeRTOS. If that was replaced, then libhal could be dropped as a dependency.

Currently libc functions are provided in libmain. Move to a standalone open source libc.

The new newlib 2.2.0 "nano" features may be a good fit.

Unsure whether it's easier to maintain a separate libc repo and add a binary libc to esp-open-rtos, or build an RTOS-specific libc as yet another source-based "component".

The following patterns should be refactored out for simplicity & flexibility, save code size:

• core/include/xxx_private.h internal headers - roll into either normal functions or standard inlines at point of declaration.
• Remove INLINED macro, replace with 'inline static'
• Move larger inlined functions (or inlined functions that need constant data arrays) to become normal functions, either in IRAM or flash (candidates include gpio_to_imux, gpio_enable, probably others.)

I'm gonno create this a place holder, so I can track it.

If I'm correct, we currently don't have any flash file system under esp-open-rtos.

nodemcu/lua uses the spiffs which is on https://github.com/pellepl/spiffs
However, their interface only allows one file open at a time. From viewing the
https://github.com/pellepl/spiffs/blob/master/src/spiffs.h it seems to be more
capable.

Spiffs provides a flat file sytem with no directories, however, filenames aren't limited
and can contain "/" thus if one kept track of cwd/pwd one could easily make directly
listing functions that filtered correctly.

Any other ideas/preferences?

I created a simple test to see what would happen, currently we get linking errors:

  CC /home/knoppix/GIT/esp-lisp/lisp.c
  CC /home/knoppix/GIT/esp-lisp/tlisp.c
  AR build/program.a
  LD build/*.c.out
  ../esp-open-rtos/libc/xtensa-lx106-elf/lib/libc.a(lib_a-fopen.o):(.literal+0x10): undefined reference to `_open_r'
  ../esp-open-rtos/libc/xtensa-lx106-elf/lib/libc.a(lib_a-fopen.o): In function `_fopen_r':
  /home/gus/dev/esp/rtos/newlib/build/xtensa-lx106-elf/newlib/libc/stdio/../../../../../newlib/libc/stdio/fopen.c:141: undefined reference to `_open_r'

"/home/gus/" path is curious too ;-)

--- snipp ----

  void filetest() {
      FILE* f = fopen("afile", "r");
      if (!f) {
          f = fopen("afile", "w");
          fprintf(f, "Hello mother!\n");
      }
      int len = 1;
      while (len) {
          char buff[100] = {0};
          len = fread(&buff, 1, sizeof(buff), f);
          if (len > 0) printf(buff);
     }
      fclose(f);
  }

--- snopp ---

TODO:

• Add doxygen markup to existing code comments.
• Build doxygen for the project automatically to gh-pages.
• Move current wiki content to doxygen documentation pages.
• Add new content documenting OTA updates, clearer quickstart steps.

The makefiles are currently set up to build all of the libraries as part of building each app (using the app's own build directory for the results, etc). This means that, for example, if you build all of the examples, you end up recompiling the same libraries 9 times.

The makefiles should be set up so that the libraries are compiled into their own destination directory, which only needs to be built once, and then is just linked in by any application build which needs it.

(Eventually, we should probably also add a top-level makefile with build/install targets for those people who just want to download and build esp-open-rtos and then just reference the prebuilt libs as a normal build dependency from their own (external) project directories/makefiles.)

I'm using Ubuntu 14.04.3 LTS
When build any example there is the same error log assembly cite below.
Examples of esp-open-sdk going without problems.

neo@esp-server:~/esp8288/esp-open-rtos$ make flash -j1 -C examples/blink ESPPORT=/dev/ttyUSB0
make: Вход в каталог `/home/neo/esp8288/esp-open-rtos/examples/blink'
CC /home/neo/esp8288/esp-open-rtos/examples/blink/blink.c
AR build/program.a
CC /home/neo/esp8288/esp-open-rtos/FreeRTOS/Source/croutine.c
CC /home/neo/esp8288/esp-open-rtos/FreeRTOS/Source/list.c
...
CC /home/neo/esp8288/esp-open-rtos/FreeRTOS/Source/portable/esp8266/port.c
AR build/freertos.a
CC /home/neo/esp8288/esp-open-rtos/lwip/esp_interface.c
CC /home/neo/esp8288/esp-open-rtos/lwip/sys_arch.c
CC /home/neo/esp8288/esp-open-rtos/lwip/lwip/src/api/api_lib.c
....
CC /home/neo/esp8288/esp-open-rtos/lwip/lwip/src/netif/ethernetif.c
CC /home/neo/esp8288/esp-open-rtos/lwip/lwip/src/netif/slipif.c
AR build/lwip.a
CC /home/neo/esp8288/esp-open-rtos/axtls/axtls/crypto/aes.c
...
CC /home/neo/esp8288/esp-open-rtos/axtls/axtls_esp_stubs.c
AR build/axtls.a
CC /home/neo/esp8288/esp-open-rtos/core/esp_gpio_interrupts.c
CC /home/neo/esp8288/esp-open-rtos/core/esp_iomux.c
CC /home/neo/esp8288/esp-open-rtos/core/esp_timer.c
CC /home/neo/esp8288/esp-open-rtos/core/newlib_syscalls.c
CC /home/neo/esp8288/esp-open-rtos/core/sdk_compat.c
AS /home/neo/esp8288/esp-open-rtos/core/exception_vectors.S
AR build/core.a
SDK processing stage 1: Removing unwanted objects from ../../lib/libmain.a
cat ../../lib/symbols_norename.txt | grep -v "^#" | sed ':begin;N;s/\n/\\|/;tbegin' > build/sdklib/norename.match
SDK processing stage 2: Building symbol list for build/sdklib/libmain_stage1.a -> build/sdklib/libmain.rename
SDK processing stage 1: Removing unwanted objects from ../../lib/libnet80211.a
SDK processing stage 2: Building symbol list for build/sdklib/libnet80211_stage1.a -> build/sdklib/libnet80211.rename
SDK processing stage 1: Removing unwanted objects from ../../lib/libphy.a
SDK processing stage 2: Building symbol list for build/sdklib/libphy_stage1.a -> build/sdklib/libphy.rename
SDK processing stage 1: Removing unwanted objects from ../../lib/libpp.a
SDK processing stage 2: Building symbol list for build/sdklib/libpp_stage1.a -> build/sdklib/libpp.rename
SDK processing stage 1: Removing unwanted objects from ../../lib/libwpa.a
SDK processing stage 2: Building symbol list for build/sdklib/libwpa_stage1.a -> build/sdklib/libwpa.rename
cat build/sdklib/libmain.rename build/sdklib/libnet80211.rename build/sdklib/libphy.rename build/sdklib/libpp.rename build/sdklib/libwpa.rename > build/sdklib/allsymbols.rename
SDK processing stage 3: Renaming symbols in SDK library build/sdklib/libmain_stage1.a -> build/sdklib/libmain.a
SDK processing stage 3: Renaming symbols in SDK library build/sdklib/libnet80211_stage1.a -> build/sdklib/libnet80211.a
SDK processing stage 3: Renaming symbols in SDK library build/sdklib/libphy_stage1.a -> build/sdklib/libphy.a
SDK processing stage 3: Renaming symbols in SDK library build/sdklib/libpp_stage1.a -> build/sdklib/libpp.a
SDK processing stage 3: Renaming symbols in SDK library build/sdklib/libwpa_stage1.a -> build/sdklib/libwpa.a
LD build/blink.out
/home/neo/esp8288/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/usr/lib/libmain.a(mem_manager.o): In function `xPortGetFreeHeapSize':
(.irom0.text+0x4): multiple definition of `xPortGetFreeHeapSize'
./build/freertos.a(port.o):/home/neo/esp8288/esp-open-rtos/FreeRTOS/Source/portable/esp8266/port.c:215: first defined here
./build/ld-16/eagle.app.v6.ld:10: undefined symbol `malloc' referenced in expression
collect2: error: ld returned 1 exit status
make: *** [build/blink.out] Ошибка 1
make: Выход из каталога `/home/neo/esp8288/esp-open-rtos/examples/blink'

As discussed in #10 and partially implemented in 147257e.

Turns out that writing to flash, which requires disabling interrupts, causes dropped packets which play havoc with TCP retry times (think 10 minutes to transfer a 200KB image).

For useful TCP-based OTA support, we need a way to throttle packet flow on either the network layer or a lower layer, or alternatively to reliably trigger TCP Fast Retransmits from the other end to avoid retry backoff times climbing exponentially. See this comment for some discussion of ways that have been attempted (and failed) already.

Relates to #2 and other libmain replacement functions.

Interrupt vectors are currently in libmain, however some of the user interrupt handling code can be found in the bottom of FreeRTOS/Source/portable/esp8266/port.c

These should probably be combined into a single source file that handles the Xtensa interrupt vectors and the user interrupts.

The more we start hacking on the internals of the existing SDK, the more useful I think it would be to have one or more standard test case apps we can use to try to make sure we don't break existing behavior. Ideally, I'm thinking a single, reasonably complex application which attempts to exercise most of the types of functionality people currently use which could be compiled and run, and then a testing procedure designed to make sure it does actually function as intended. That way anybody who wants to has a well-defined procedure to test that at least basic functionality still works as expected on any given esp-open-rtos build.

Unfortunately, all of the current examples are fairly limited in scope for this purpose.. It might be good to start by finding an existing app which exercises a reasonable range of behavior, and then work from there.

Hi,

In the blink example.

void blinkenTask(void *pvParameters) does not work.
void blinkenRegisterTask(void *pvParameters) works with GPIO4 an GPIO5 as parameters.

I checked eagle_soc.h found that some GPIOs are controlled in other way.
PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDI_U, FUNC_GPIO12); // Set GPIO12 function
PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTCK_U, FUNC_GPIO13); // Set GPIO13 function
PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTMS_U, FUNC_GPIO14); // set GPIO14 function

Thanks.

When I was trying the bmp180_i2c example I see this typo, should be temperature.

Hi,

AFAIK, the ESP8266 does not have hardware support for the I2C protocol. Thus it must be implemented in code ('bit-banging').

If I'm correct, any thought on how to implement that? Timing critical, and don't really wan't to disable interrupts while doing I2C...

/michael

PS. Is there someplace else where we can sort of discuss instead of creating an Issue? Google Groups, Google+, other...

The code is littered with ESPTODO markers for things that need cleaning up.

Find all these and fix them directly or convert them to github issues.

This is something that arguably isn't major, but keeps bugging me, and I'm sure is going to bug a bunch of people out there who might try to use esp-open-rtos, so it'd be good to fix..

stdint.h currently typedefs int32_t as long int and uint32_t as unsigned long int, despite the fact that int/unsigned on this architecture are 32-bits, so these could/should just be int and unsigned instead. From an ABI standpoint, there's no difference, but a few things do care (most notably, the printf-format checking that GCC does (-Wformat) complains bitterly and stops the build if you try to print an int32_t value using a "%d", for example, which is just dumb).

The esp-open-sdk stuff does not have this problem by default (things built with esp-open-sdk outside of esp-open-rtos define int32_t as int), so it's an issue specific to our particular configuration, not a general GCC thing. From what I can tell so far, the problem seems to be that we're using the stdint.h from newlib, whereas esp-open-sdk normally uses the one from gcc.

I'm not sure the best way to fix this. The most straightforward would probably be to include our own copy of stdint.h somewhere in the search path before the newlib stuff (which it occurs to me might be easier to do cleanly if we had a standard "include" directory for everything, as suggested in issue #28, but that's not necessarily a prerequisite)..

I proposed the following change to esp_iot_rtos_sdk wrt wifi SSID and password management. I find it rather attractive as there will be a file containing dummy SSID/pw following a git clone and changes to that file will be ignored by git. I'd be happy to incorporate that change here if more people than me likes the idea :)

kanflo/esp_iot_rtos_sdk@3d0f7be

Similar to the official SDKs pre-v1.1.0, esp-open-rtos uses no entropy source so the random values used in TLS, WPA, etc. are wholly predictable.

It should be possible to use internal timers and/or ADC values to inject entropy. Possibly implement our own versions of rand() and srand() that combine the entropy source with PRNG?

The best way to write suitable code is to first add documentation somewhere like the esp8266 wiki (https://github.com/esp8266/esp8266-wiki/) describing factual information gained from reverse engineering - such as register addresses, bit masks, orders of register writes, etc.

There're known concerns about wiki at https://github.com/esp8266/esp8266-wiki, see esp8266/esp8266-wiki#32 . So, consider forking it and maintaining a more accessible version of it as part of this project.

esp-open-rtos hasn't had an abort handler because of fiddliness with newlib libc, but once f697917 is merged we will be able to just implement one somewhere in a C file and have it called (the header is already in newlib).

The abort implementation should probably do something like flush the UART TX FIFO and encourage a reset. Perhaps by infinite looping the CPU with interrupts off and WDT on, but details are up to the implementer.

Once abort() is available, all of the places that currently do a while(1) {} should be refactored to use it.

Rather than preprocessing library binaries with objcopy, etc. we can use xtobjdis to produce assembly source files that are then assembled as part of the library build process.

Among other benefits this means that "rewriting in C" work can happen in smaller chunks, and minor tweaks and bugfixes can be applied directly to the assembly code source. As well as commenting functionality directly in the "source" as people figure it out.

A (non-functional) work in progress for this is currently at:
https://github.com/SuperHouse/esp-open-rtos/tree/feature/assemble-sdk

Once this is done, all of the library preprocessing steps can be removed from the Makefile (yay) and therefore #38 will become a good deal more straightforward.
#11 will also benefit a lot, as we can go through the strings and other constant data in the SDK and mark which ones need to live in DRAM.

The IROM macro causes a data definition to be placed in the .irom0.literal segment, however there's nothing anywhere in the linker scripts to cause .irom0.literal (or any other .irom/.irom0 segment that's not part of the sdklibs) to actually be linked into the final binary.

This results in very bad/confusing things if you actually use the IROM macro anywhere in your code..

As discussed a bit on issue #25, GitHub issues are not necessarily the best way to discuss some issues, and a more general-purpose maillist / forum / etc would be very useful.

I believe @projectgus was looking into some options, but am not sure the status on that. This ticket is just to track the progress on getting something set up (and will hopefully be closed soon :) )

This it not an issue as such :-)

1. How do you feel about having the ability to use C++ within this project? I have forked esp-open-rtos (https://github.com/mikejac/esp-open-rtos) and made some initial steps to get C++ supported. However, I'm in no way an Makefile/make expert, so would you take a look at the /common.mk file (lines 183 - 187 I believe) and perhaps think of a way to get .cpp files compiled with their own compiler flags (CXXFLAGS).

2. How about adding the Eclipse Paho MQTT client library to esp-open-rtos? Already got it "ported" locally.

One thing we are currently lacking is support for handling GPIO > 15. Looking at the Arduino port, GPIO 16 is handled in other registers than GPIOs 0..15:

extern void __digitalWrite(uint8_t pin, uint8_t val) {
  if(pin < 16){
    if(val) GPOS = (1 << pin);
    else GPOC = (1 << pin);
  } else if(pin == 16){
    if(val) GP16O |= 1;
    else GP16O &= ~1;
  }
}

GPIOS above corresponds to our GPIO.OUT_SET and GP16O resides at 0x60000768 where we have no mapping.

Creating this issue to track what we know about libnet80211.a & libwpa.a, which implement the (upper?) MAC layer and the WPA functionality.

The layer above is the IP stack in lwip, specifically the esp network interface code (in lwip/esp_interface.c). The layer below is radio-specific stuff in libpp.a.

The symbols in libnet80211.a match pretty closely to an older revision of FreeBSD's net80211 module, but it may be via a fork taken from FreeBSD somewhere:
https://svnweb.freebsd.org/base/head/sys/net80211/?pathrev=234018

Some symbols in libwpa.a match closely to FreeBSD wpa, but it may come via somewhere else or have substantial Espressif additions (latter seems unlikely)?
https://svnweb.freebsd.org/base/head/contrib/wpa/wpa_supplicant/?pathrev=252726

I'm hoping to analyse the source revisions from FreeBSD SVN to find the revision which are "closest" to the contents of the binaries, in terms of symbols.

TODO also is to analyse the exact connections between libpp.a to see where it interacts with libnet80211.a & libwpa.a.

I have tried the http_get_ssl example, and the result is below:

ip:10.0.0.11,mask:255.255.255.0,gw:10.0.0.1
DNS lookup failed err=202 res=0
top of loop, free heap = 29932
Running DNS lookup for www.google.com...
DNS lookup succeeded. IP=74.125.23.147
... allocated socket
... connected. starting TLS session...
initial status 0x3fff9610 -261
SSL handshake failed. :( -261

Please give me a hand. Thank you.

This does not seem quite right:

/* Non-OTA sizes */
#if FLASH_SIZE == 2 /* 256kB */
#define IROM0_LEN 0x3C000
#elif FLASH_SIZE == 4 /* 512kB */
#define IROM0_LEN 0x7C000
#elif FLASH_SIZE == 8 /* 1MB */
#define IROM0_LEN 0xFC000
#elif FLASH_SIZE == 16 /* 2MB */
#define IROM0_LEN 0x1FC000
#elif FLASH_SIZE == 32 /* 4MB */
#define IROM0_LEN 0x3FC000
#else /*FLASH_SIZE*/
#error "Unknown flash size for linker script. Check the FLASH_SIZE variable in your Makefile."
#endif

As the IROM starts at 0x20000, should these not be 0x1c0000, 0x5c0000, 0xdc0000, 0x1dc0000 and 0x3dc0000?

I translated register definitions for the SLC and I2S registers from Espressif sources to try and match the esp-open-rtos style. I also tried to slightly change the naming to be a bit more readable, as this seems in line with the other headers already provided. There's a slight risk I may have guessed wrong in some places, though.

(I also left out the very last definitions for the SLC, because the I couldn't make heads or tails of the code.)

i2s_regs.h.txt
slc_regs.h.txt

Feel free to edit these as you see fit to better match the rest. I have some code too which actually uses these and can serve as a few hints to what this stuff all means, but it's still a mess. I might post it later if anybody's interested, once it's cleaned up.

There have been a few occasions now where folks have found functions from the published Espressif SDK API which are implemented, but for some reason are simply not present in the headers Espressif provided with the RTOS 0.9.9 branch of the SDK.

We should go through and check all the current SDK APIs to make sure that if they are present in the current implementation, they are also defined in the headers in an appropriate place so people can actually use them.

(the most recent of these and the one that triggered opening this issue is that apparently sdk_system_adc_read is present in the libraries but missing from the header files. I know there have been others, though..)

Be able to compile OTA-compatible image pairs that work with an OTA-type bootloader.

AFAIK the esp_iot_rtos_sdk does not support OTA at the moment.

The rBoot open source OTA bootloader looks like an excellent option:
http://richard.burtons.org/2015/05/18/rboot-a-new-boot-loader-for-esp8266/
http://richard.burtons.org/2015/05/17/decompiling-the-esp8266-boot-loader-v1-3b3/

This might be possible just with linker script changes to the existing code base, or it might require open source startup code (#2) to change some of the early runtime behaviour.

Also need some library functions to download OTA updates, verify image, etc.

The chip freezes when strtok_r is in use. It doesn't even print previous statements.
if strtok_r line is commented then the program runs just fine.

Does someone has used succesfully strtok on the esp?
Any suggestions?

void worker(void * pvParameters){
  char cR[BUF_SIZE];
  char *cMethod;
  //char *cURI;
  char *rest;
  int iBites;
  int sockClient;
  xQueueHandle xWorkersQueue=*(xQueueHandle *)pvParameters;
  while(1){
    //waiting for clients
    while( xQueueReceive(xWorkersQueue , (void *)&sockClient , portMAX_DELAY ) != pdTRUE );
    //get client request
    iBites=lwip_recv(sockClient, cR, sizeof(cR), 0);
    printf("-----REQUEST-------\n");
    printf("%.*s\n",iBites,cR);
    //parsing request
    //strcpy(cMethod,strtok_r(cR," ",&rest));
    //strcpy(cURI,strtok_r(NULL," ", &rest));
    cMethod=strtok_r(cR," ",&rest);
    printf("----------DEBUG----------\n%s\n%s\n",cMethod,"");


    strcpy(cR, "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\nprova");
    printf("-----RESPONSE-------\n");
    printf("%s\n",cR);
    lwip_send(sockClient, cR, strlen(cR), 0);
    lwip_close(sockClient);

There are a lot of functions available in the ESP8266 ROM. The Espressif RTOS SDK doesn't seem to list most of them in its linker script, however, and esp-open-rtos seems to have inherited that.

Would it be a good idea to add all of them to the linker script, and provide headers at least for the ones that are known for some reason or other? Possibly by prefixing them with rom_ or something similar.

Some of them are C library functions, too, but I don't know how well they work compared to what newlib provides. It might be worth looking into saving space by using them if they are not already.

I get this error when compiling examples. I have download the source code and compiler is in PATH

../../include/espressif/esp_misc.h:9:26: fatal error: lwip/ip_addr.h: No such file or directory
#include "lwip/ip_addr.h"

At the moment the startup code is provided in binary libmain. The reset vector is in ROM which performs low level initialisation then maps the SPI flash and calls into the entry point at call_user_start.

Startup code includes:

• "standard" libc-style setup of memory & interrupts
• calling into libpp for radio calibration
• setup of the FreeRTOS task which handles wifi functions.
• Other things?

As a first step, this process needs to be documented in detail.

It should be possible to write open source routines that give more fine-grained control to the program author.

Some more details (ROM & IoT SDK based, but could be extended to document RTOS startup code):
https://github.com/esp8266/esp8266-wiki/wiki/Boot-Process

Mentioned by @foogod in #24 & #35, but it's been on my mind as well.

There's at least 3 contributing factors I know of:

• esp arch has a lot of memory types and spi flash size variations.
• The SDK libraries do things in a way which is incompatible with upstream code unless you want to put an attribute on nearly every function, so need special cases for SDK vs non-SDK .text sections and similar.
• That linker script has been hacked up from the RTOS SDK one instead of starting from scratch, and I think the RTOS SDK one was hacked up from an Xtensa boilerplate one. so there's at least some cruft.

The last part is something that can be easily fixed with a clean up pass to remove the cruft.

The one thing I don't want to do is make the linker script less complex by preprocessing libraries with objcopy (any more than we already have to!). That just moves the complexity around.

The other significant change with the current linker script is running it through the C preprocessor to pick up things like flash size. This is a kind of "lesser of two evils" thing in my mind, compared to the Espressif solution of having multiple linker scripts. There might be a better way though, possibly using two linker scripts so the flash-specific parts go in a smaller script and then there's a longer generic script with the rest...

Thoughts/suggestions welcome.

At the moment all examples and other programs need their own FreeRTOSConfig.h.

There should be a default FreeRTOSConfig.h with sensible defaults, and programs can just override any values they want to override instead of needing to make a full copy.