-->
Page 1 of 2

c_types.h bug in open sdk?

PostPosted: Tue Oct 06, 2015 8:43 pm
by amadeus84
I'm trying to install esp-open-sdk and compile it standalone in order to compile a web server firmware. So, following (the official?) docs from wiki/doku.php?id=toolchain

Code: Select allgit clone --recursive https://github.com/pfalcon/esp-open-sdk
cd esp-open-sdk
 make STANDALONE=y


add to path, etc.

Then, I download the web server code and try to compile that now:

Code: Select allgit clone "https://github.com/dubaurazvan/esp8266-wireless-switcher.git"
cd esp8266-wireless-switcher
make


Then I get zillion errors, all similar to this:

Code: Select allCC user/stdout.c
In file included from include/espmissingincludes.h:4:0,
                 from user/stdout.c:13:
/home/amadeus/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/usr/include/ets_sys.h:14:1: error: unknown type name 'uint32_t'
 typedef uint32_t ETSSignal;


So I look at the ets_sys.h file and the first few lines are

Code: Select all/*
 * copyright (c) 2008 - 2011 Espressif System
 *
 * Define user specified Event signals and Task priorities here
 *
 */

#ifndef _ETS_SYS_H
#define _ETS_SYS_H

#include "c_types.h"
#include "eagle_soc.h"

typedef uint32_t ETSSignal;
typedef uint32_t ETSParam;



It uses uint32_t which I'm guessing should be defined in c_types.h in the same directory. So then I look at c_types.h and

Code: Select all/*
 *  Copyright (c) 2010 - 2011 Espressif System
 *
 */

#ifndef _C_TYPES_H_
#define _C_TYPES_H_

#include <stdint.h>
#include <stdbool.h>
#if 0
typedef unsigned char       uint8_t;
typedef signed char         sint8_t;
typedef signed char         int8_t;
typedef unsigned short      uint16_t;
typedef signed short        sint16_t;
typedef signed short        int16_t;
typedef unsigned long       uint32_t;
typedef signed long         sint32_t;
typedef signed long         int32_t;
typedef signed long long    sint64_t;
typedef unsigned long long  uint64_t;
typedef unsigned long long  u_int64_t;
typedef float               real32_t;
typedef double              real64_t;
#endif


etc. so sure enough, uint32_t is not defined, because of the #if 0 directive. In the esp-open-sdk (the root of the sdk) I have a c_types-c99.patch that does precisely that, surrounds the typedefs in c_types.h with an #if 0 / #endif.

So what's the deal here? I might be able to re-compile the sdk without the c_types-c99 patch somehow, but I bet that will break other things. Any ideas?

I'm doing this on a 64 bit Fedora 22 machine.

Thanks!

Re: c_types.h bug in open sdk?

PostPosted: Tue Oct 20, 2015 7:10 am
by Drum
Have you resolved this? I am having a very similar issue trying to compile a firmware in 1.4.0 that was originally created in 1.3.0. But I have noticed the c_types.h files in the others which do compile without a problem, are not using #if 0 / #endif, which as far as I can tell removes the section from the process completely.

I'll try it with them removes to see what happens, I don't think it can do anything worse than it is now.

Re: c_types.h bug in open sdk?

PostPosted: Sun Oct 25, 2015 8:13 am
by amadeus84
Unfortunately I have not. I did download other SDK examples firmware and they do compile with esp-open-sdk. For instance

https://github.com/anupak/esp8266-samplecode

I also compiled my own nodeMcu following these excellent instructions

http://www.allaboutcircuits.com/project ... e-esp8266/

and I now have nodeMCU on one of my modules. So, since these things compile with uint*_t undefined in c_types.h, I'm guessing there must be some version mismatch between my sdk version and the web server code I was trying to compile and that it would probably be easier to start from some examples that did compile, and write my own web server.

Now I'm trying to figure out how to write my own "hello world" in C for esp8266, but I don't even know where to start. I'm sifting through these examples that I got to compile and I'm trying to figure out the compilation commands, in order to understand which files are being included, etc. I don't even know what the entry point is - the equivalent of main() - or even what the directory structure should be. It seems there has to be a user/user_main.c file that contains a user_init() function. Beyond that, I don't know.

I wish there was some documentation describing the structure of the C code, but from the examples I came across it seems that everybody used some primordial code as a template and mechanically modified it for their purposes, but I'd like to understand a bit what I'm doing.

Someone, pleas show us the beginning.

Re: c_types.h bug in open sdk?

PostPosted: Sun Oct 25, 2015 9:36 pm
by amadeus84
I looked more at the esp8266-wireless-switcher code, originally written by Jeroen Domburg. I can compile some of the .c files in the user directory, if I comment out #include "espmissinginlcludes.h"

However, other files still do not compile, such as cgiwifi.c or espfs.c. For instance

xtensa-lx106-elf-gcc -I../include -I. -I../../esp-open-sdk/sdk/include -Os -g -O2 -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -D__ets__ -DICACHE_FLASH -c cgiwifi.c

xtensa-lx106-elf-gcc -I../include -I. -I../../esp-open-sdk/sdk/include -Os -g -O2 -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -D__ets__ -DICACHE_FLASH -c cgiwifi.c
In file included from ../../esp-open-sdk/sdk/include/os_type.h:10:0,
from ../../esp-open-sdk/sdk/include/user_interface.h:9,
from cgiwifi.c:20:
../../esp-open-sdk/sdk/include/ets_sys.h:14:1: error: unknown type name 'uint32_t'

Now esp-open-sdk/sdk/include/ets_sys.h is full of uint??_t and includes c_types.h, presumably to have these defined, but in my version of open-sdk they remain undefined within an #if 0 / #endif block. Instead, c_types.h defines the uint* types without the trailing _t. I don't understand how anything that includes ets_sys.h can possibly work. This has to be a bug in the sdk. Maybe it's fixed in a more recent version of the Expressif sdk, but it's not fixed in open-sdk.

This is such a shame, because this code is both non trivial and very useful.