search

lumapu / ahoy

Various tools, examples, and documentation for communicating with Hoymiles microinverters
https://ahoydtu.de
Other
947 stars 222 forks source link

[ESP8622] Build not working #748

Closed deeplymbedded closed 1 year ago

deeplymbedded commented 1 year ago

Hardware

Modelname: __ Retailer URL: __

nRF24L01+ Module

Antenna:

Power Stabilization:

Connection diagram:

Connection diagram I used:

nRF24L01+ Pin ESP8266 GPIO
Pin 1 GND [*] GND
Pin 2 +3.3V +3.3V
Pin 3 CE GPIO2 CE D4
Pin 4 CSN GPIO15 CS D8
Pin 5 SCK GPIO14 SCLK D5
Pin 6 MOSI GPIO13 MOSI D7
Pin 7 MISO GPIO12 MISO D6
Pin 8 IRQ GPIO0 IRQ D3

Note: [*] GND Pin 1 has a square mark on the nRF24L01+ module

Software

Version / Git SHA:

Version: 0.5.66 Github Hash: f8fe044

Build & Flash Method:

Desktop OS:

Debugging:

IDE Visual Studio:

Version: 1.76.0 Commit: 92da9481c0904c6adfe372c12da3b7748d74bdcb Datum: 2023-03-01T10:25:16.105Z Electron: 19.1.11 Chromium: 102.0.5005.196 Node.js: 16.14.2 V8: 10.2.154.26-electron.0 Betriebssystem: Linux x64 6.1.14-200.fc37.x86_64 Sandkasten: No

Build is not successfull for all ESP86x targets. This is the console output for ESP8622-release:

Processing esp8266-release (platform: espressif8266; board: esp12e; framework: arduino)

Verbose mode can be enabled via -v, --verbose option Firmware Revision: gf8fe044 CONFIGURATION: https://docs.platformio.org/page/boards/espressif8266/esp12e.html PLATFORM: Espressif 8266 (2022.12.0) > Espressif ESP8266 ESP-12E HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash PACKAGES:

fsck-block commented 1 year ago

Version / Git SHA: Version: 0.5.66

Tried to reproduce your issue but no problem to build the current stable (main) version 0.5.66 [esp8266-release] (downloaded as zip-file)

deeplymbedded commented 1 year ago

Thanks for the feedback. I was taking the sources directly from GIT repository but meanwhile also tested with the .zip file -> Same result.

On which OS did you try to reproduce? For me it looks like some includes are not properly resolved, eg from above log the line hm/hmInverter.h:402:28: error: 'u_int16_t' has not been declared

I can find definition of u_uint16_t in types.h which is located in .platformio/packages/framework-arduinoespressif8266/tools/sdk/libc/xtensa-lx106-elf/include/sys/types.h But in the hmInverter.h file, I can't find this types.h included.

fsck-block commented 1 year ago

On which OS did you try to reproduce?

Linux / Ubuntu 22.04 LTS

located in .platformio/packages/framework-arduinoespressif8266/tools/sdk/libc/xtensa-lx106-elf/include/sys/types.h

types.h on my computer is located at .platformio/packages/toolchain-xtensa/xtensa-lx106-elf/include/sys/types.h

But in the hmInverter.h file, I can't find this types.h included.

It's included via app.h and Arduino.h.

You may add -E to the build_flags in your platformio.ini file to see what's generated by the preprocessor.

[env:esp8266-release]
platform = espressif8266
board = esp12e
board_build.f_cpu = 80000000L
build_flags = -D RELEASE -E

you will find the processed source code in .pio/build/esp8266-release/src/app.cpp.o

deeplymbedded commented 1 year ago

I added the -E option and took a look at the app.cpp.o and main.cpp.o file. In both I can only find the usage of u_int16_t variable, but not the definition.

Taking a deeper look at sys/types.h shows that the u_int16_t is encapsulated by a #ifdef __MS_types__ directive, which doesn't seem to be defined in my environment. I try to dig deeper, currently it looks like really the target-system has something to do with it...

lumapu commented 1 year ago

thanks for pointing that out

lumapu commented 1 year ago

@deeplymbedded I checked the code again, both main and development03 but didn't found any u_int16_t occurance. Does it come from our code our is it hidden in some library? Do you know a line number?

deeplymbedded commented 1 year ago

Hello @lumapu , thanks for the feedback. I traced it according to the error-description of the compiler: In file included from hm/hmSystem.h:9:0, from app.h:25, from main.cpp:7: hm/hmInverter.h:402:28: error: 'u_int16_t' has not been declared String getAlarmStr(u_int16_t alarmCode) { ^

while compiling main.cpp it includes app.h, which includes hmSystem.h, which includes finally hmInverter.h There the u_int_16 is used in line 402.

I have also a Windows PC running, I installed platformio there and gave a build. It is indeed going through successfully there.

I took a look at the used header-file types.h and they differ a lot. Looks like the Windows and Linux packages are not the same and cause the problem platformio_windows platformio_linux

lumapu commented 1 year ago

thanks, I will search for these places and try to resolve that. I don't know why here are these definitions were used.

deeplymbedded commented 1 year ago

Thank you. I think the main issue is that on my Linux system, platforio somehow uses different packages than on my Windows system. I'm not that familiar with platformio, yet, hence I do not understand 100% how the IDE decides which libs to use. The fact that I have different packages / libs installed on my Linux PC probably comes because I also had a tasmota project loaded there, which runs on an ESP8266, too and loaded some libs.

So to sum it up: The build issue I face is most probably due to messed up paths to the packages at my local machine. Anyway the used types u_intxx_t seem to be deprecated, but this seems not to be the real issue for my problems with the build

lumapu commented 1 year ago

just saw that the development version does not have this issue. Check Branch development03

deeplymbedded commented 1 year ago

Yes you are right, the type-issue doesn't appear on the development03 branch. However something is still not clean. It seems like the tasmota project installed some packages via github URL which are modified and anyhow used by the ahoy project

Processing esp8266-release (platform: espressif8266; board: esp12e; framework: arduino)

Verbose mode can be enabled via -v, --verbose option Firmware Revision: g28bd99e CONFIGURATION: https://docs.platformio.org/page/boards/espressif8266/esp12e.html PLATFORM: Espressif 8266 (2022.12.0) > Espressif ESP8266 ESP-12E HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash PACKAGES:

Environment Status Duration

esp8266-release FAILED 00:00:08.443

deeplymbedded commented 1 year ago

I just removed all packages from esp8266 which came with the tasmota and loaded them newly, now build is working. Anyway I wonder why they conflict, as I thought platformio is maintaining every package separately in the project context to avoid exactly such clashes

DasUrmel commented 1 year ago

Wahoo... exactly my problem - and @deeplymbedded 's solution worked for me as well - at least in part.

I removed all old installed platforms from platformio and I could finally compile the ahoy project. Some espressif stuff was installed gain:

tool-esptoolpy@1.40401.0

espressif32@6.1.0 toolchain-xtensa-esp32@8.4.0+2021r2-patch5 framework-arduinoespressif32@3.20007.0 tool-esptoolpy@1.40500.0

Then I compiled tasmota - wich installed some more espressif stuff again:

toolchain-xtensa@2.40802.200502 framework-arduinoespressif8266@2.7.4+9 tool-esptoolpy@1.40501.0

espressif32@2023.2.0 framework-arduinoespressif32@2.0.7 tool-mkspiffs@2.230.0 tool-mklittlefs@1.203.210628

And that also worked as well. Fine.

I'm a little pessimistic, so I double checked: Compiling ahoy again... Error !

Compiling .pio/build/az-delivery-devkit-v4/lib7ed/AsyncTCP/AsyncTCP.cpp.o utils/dbg.cpp:3:1: error: 'DBG_CB' does not name a type DBG_CB mCb = NULL; ^~~~~~

So something of the espressif stuff installed by tasmota blocks compiling of ahoy.