unknown type name 'uint32_t' when compiling with the latest sdk about colorchord

[cnlohr]

Try throwing in a #include <stdint.h> at the top of uart.c?

[pelrun]

That sounds like a problem with the build environment, not colorchord. Do you have the espressif sdk properly installed?

[con-f-use]

I believe I have. At least I can compile and flash esp8266ws2812i2s just fine.

The file that defines fixed size integer types is esp-open-sdk/ESP8266_NONOS_SDK_V1.5.4_16_05_20/include/c_types.h (as far as I know). That is included in uart.c and uart.h and passed to the xtensa-gcc via -I/home/confus/usr/build/esp-open-sdk/sdk/include. So I have no idea why it doesn't recognize things like uint8_t.

[pelrun]

The error happens in /home/confus/usr/build/esp-open-sdk/sdk/include/ets_sys.h immediately after an #include "c_types.h", and that file (/home/confus/usr/build/esp-open-sdk/sdk/include/c_types.h) should be defining the type. Unless there's another c_types.h file that's getting loaded instead.

[con-f-use]

I looked a bit more into it. c_types.h seems to get patched at some point during building the sdk. The patch seems to include files like sdtint.h and stdbool.h instead of defining the types directly. These files do not exist in the same directory as c_types.h, which is weird. If I replace the patched version with the original version that defines uint32_t etc. directly, I get a much shorter linking error, that I don't understand:

/home/confus/usr/build/esp-open-sdk/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc -mlongcalls -I/home/confus/usr/build/esp-open-sdk/sdk/include -Imyclib -Iinclude -Iuser -Os -I/home/confus/usr/build/esp-open-sdk/sdk/include/ -I../embeddedcommon -I. -Icommon -DICACHE_FLASH driver/uart.c common/mystuff.c common/flash_rewriter.c common/http.c common/http_custom.c common/mfs.c user/ws2812_i2s.c user/hpatimer.c user/custom_commands.c driver/adc.c ../embeddedcommon/DFT32.c ../embeddedcommon/embeddednf.c ../embeddedcommon/embeddedout.c user/user_main.c common/commonservices.c   -nostdlib -L/home/confus/usr/build/esp-open-sdk/sdk/lib -L/home/confus/usr/build/esp-open-sdk/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.5/libgcc.a /home/confus/usr/build/esp-open-sdk/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.5/libgcc.a /home/confus/usr/build/esp-open-sdk/sdk/lib/libmain.a /home/confus/usr/build/esp-open-sdk/sdk/lib/liblwip.a /home/confus/usr/build/esp-open-sdk/sdk/lib/libssl.a /home/confus/usr/build/esp-open-sdk/sdk/lib/libupgrade.a /home/confus/usr/build/esp-open-sdk/sdk/lib/libnet80211.a /home/confus/usr/build/esp-open-sdk/sdk/lib/libwpa.a /home/confus/usr/build/esp-open-sdk/sdk/lib/libnet80211.a /home/confus/usr/build/esp-open-sdk/sdk/lib/libphy.a /home/confus/usr/build/esp-open-sdk/sdk/lib/liblwip.a /home/confus/usr/build/esp-open-sdk/sdk/lib/libpp.a /home/confus/usr/build/esp-open-sdk/sdk/lib/libcrypto.a /home/confus/usr/build/esp-open-sdk/sdk/lib/libmain.a /home/confus/usr/build/esp-open-sdk/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.5/libgcc.a -T /home/confus/usr/build/esp-open-sdk/sdk/ld/eagle.app.v6.ld -Wl,-Map,output.map  -B/home/confus/usr/build/esp-open-sdk/sdk/lib -o image.elf
/home/confus/usr/build/esp-open-sdk/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/bin/ld: image.elf section `.text' will not fit in region `iram1_0_seg'
/home/confus/usr/build/esp-open-sdk/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.5/../../../../xtensa-lx106-elf/bin/ld: region `iram1_0_seg' overflowed by 1912 bytes
collect2: error: ld returned 1 exit status
Makefile:83: recipe for target 'image.elf' failed
make: *** [image.elf] Error 1

[pelrun]

That's issue #10 - you cannot use the latest Espressif SDK, you need to use 1.5.1.

[con-f-use]

Okay, thank you. That is really annoying. Can you or someone else provide a commit of the esp-open-sdk Makefile by pfalcon that doesn't have the error? From the history e32ff68 looks promising, it's just before 1.5.2 became the default. What commit is @cnlohr using, or are you building everything by hand?

Edit:
I'm one step further now. I used commit e32ff685 so, sdk version 1.5.0 of September 15, 2015. I had to undo the patches to c_types.h. That helped. The only thing I'm missing is what FW_TOOL should be set to, or more precisely where I get the executable, that @cnlohr is using in FW_TOOL= ~/esp8266/other/esptool/esptool. It seems to be a binary executable and not the esptool.py python script that comes with @pfalcon 's Makefile.

Additionally I was missing the binary esptool (not esptool.py). Now, after I built it, changing TARGET=Windows to Linux in its Makefile, everything works. There seems to be a newer version though.

This was more annoying than expected. Here future me, have a shell script to automate it, should you have have to do it again.

[cnlohr]

I actually just tried a couple things tonight and have found that after 1.5.1, Espressif really started to LOAD DOWN the iram segment with tons of stuff. There's basically no room left. Unfortunately, much of colorchord needs the iram to run, so unless Espressif makes some big changes we're stuck with 1.5.1.

I am really confused about this needing to patch, etc. P.S. I need to backport it into colorchord, unless someone here is up for it, but I have updated it so everything uses esptool.py. No more need to have the binary esptool. Does anyone mind giving that a shot and testing?

[con-f-use]

I need to backport it into colorchord

"It" being...? I'd be up for some testing but what exactly do you want to backport and test?

Btw. I need a virgin Ubuntu 16.04 to even build the latest SKD. Apparently some packages I have on my regular pc do something to binutils so that it won't build.

Offtopic: How do you set the IP and ssid for the esp to connect to in your code? Where in the sources are the defaults?

[cnlohr]

1. "it" = things like:

$(FW_FILES): $(TARGET_OUT)
    @echo "FW $@"
    PATH=$(FOLDERPREFIX):$$PATH;$(ESPTOOL_PY) elf2image $(TARGET_OUT)

So we don't need the binary.

and

burn : $(FW_FILES)
    $(ESPTOOL_PY) --port $(PORT) write_flash -fm dout 0x00000 image.elf-0x00000.bin 0x40000 image.elf-0x40000.bin

so it doesn't confuse the baud rate detector.

2. I am definitely using Mint 17.3 and it has built everything cleanly. Not sure what the difference is there.

The defaults are for it to make its own AP, you connect, it is at 192.168.4.1. You can use the web configuration to connect to another AP.

[con-f-use]

see pull request #13

I'm thinking of rewriting ./embedded8266/web/Makefile so that it can be included in the main Makefile and things like page.mpfs and execute_reflash are build automatically on demand from the main Makefile.

[cnlohr]

You may want to consider writing the rule in the main like so:

do_web_stuff:
    (cd web)&&(make);(cd ..)

[cnlohr]

P.S. @con-f-use I really appreciate you helping out on this!

[con-f-use]

You may want to consider writing the rule in the main

And so t'was done ---> #14