libretiny-eu / libretiny

PlatformIO development platform for IoT modules
http://docs.libretiny.eu/
MIT License
382 stars 55 forks source link

Location in structure to place additional definitions #74

Open lonerzzz opened 1 year ago

lonerzzz commented 1 year ago

I would like to add additional type definitions for Arduino to match what exists for ESP code, but I am not sure where in the current structure such items are intended to be placed. I would like to add:

1) typedef bool boolean; 2) IPAddress class definition 3) time.h definition with tm struct

Please let me know and I will create a pull request.

kuba2k2 commented 1 year ago

I believe they're all available. At least first two - I'm not sure about the third one. How did you find out that they're missing?

lonerzzz commented 1 year ago

I am working through type resolution issues in the IDE when attempting to build a project originally written for the ESP32.

The 1st and 2nd ones are showing up as unresolvable in the Eclipse CDT IDE in contrast to types such as uint8_t, uint32_t which are resolved with the inclusion of the Arduino.h header. The 3rd one, the tm struct from time.h, is showing up as unresolved in the platformio console output as an error that stops the build.

kuba2k2 commented 1 year ago

The bool typedef should be in ArduinoCore-API. The IPAddress also should. Can you check that using VSCode? Maybe Eclipse doesn't have proper PlatformIO support, or the ArduinoCore-API package didn't get installed.

lonerzzz commented 1 year ago

Just to confirm, bool is present but I am looking to add a typedef to define the boolean type from bool because it exists for the ESP and is all through the code that I am building. That is why I was wondering where it would be added.

I do see the framework-arduino-api package with IPAddress defined under the api directory. What I do not see is the arduino-api folder in the include directory list. My attempt to add the folder [parent_folder]\platformio\packages\framework-arduino-api\api did not resolve the issue.

lonerzzz commented 1 year ago

As far as PlatformIO support in Eclipse is concerned, the same project built against an ESP does not have the same errors. Type resolution is working at the IDE level.

lonerzzz commented 1 year ago

Testing in VS Code, the IDE does not seem to complain about boolean or IPAddress so that is IDE specific. The tm struct from time.h does not exist so please let me know where such an include should be added. I want to port a few ESP components to achieve parity on this chip.

kuba2k2 commented 1 year ago

If the tm struct is from POSIX, it should be added somewhere in the posix directory of LT. Did you check that GCC doesn't contain that struct disabled with #ifdefs? Maybe it's in sys/time.h instead?

If it's not POSIX.. then I believe there's a "compat" directory in LT where that can also be placed. Note that the project will be undergoing a huge structure refactor soon, so you can probably place it "anywhere that works", and I'll include that in the refactor (see issue #63).

lonerzzz commented 1 year ago

Here is what I found regarding time.h and the tm struct

tm structure in libretuya is resolved to an incomplete type defined here: [parent path]\platformio\packages\framework-beken-bdk\beken378\app\ftp\vfs.h yielding the error during compilation aggregate 'tm timeDetail' has incomplete type and cannot be defined versus ESP32 which uses [parent path]\platformio\packages\toolchain-riscv32-esp\riscv32-esp-elf\sys-include\time.h although time.h does exist within the toolchain for LibreTuya [parent path]\platformio\packages\toolchain-gccarmnoneeabi\arm-none-eabi\include\time.h

So it looks like an include should be added to time.h in order to ensure the correct tm struct implementation. The time.h include is not something that is explicitly required in ESP32 in order to use it.

lonerzzz commented 1 year ago

Regarding IPAddress, there are significantly different implementations between the espressif package and libretuya which leads to several issues during build including missing functions:

[parent path]\platformio\packages\framework-arduino-api\api\IPAddress.h vs [parent path]\platformio\packages\framework-arduinoespressif32\cores\esp32\IPAddress.h

What was the source for the IPAddress.h/IPAddress.cpp version used in LibreTuya? Was it chosen for a specific reason versus using the ESP32 version?

kuba2k2 commented 1 year ago

The IPAddress is used from the ArduinoCore-API. We're using everything from that package, plus some extras that aren't included there. We have a fork of the repo, where I added e.g. printf() to the Print class, so you should be able to port the missing functions there.

Does your program work after manually including time.hor sys/time.h? Or are the structs different in GCC vs the ESP32 toolchain? LT is meant to be as compatible as possible with ESP32, but it'll never be a drop-in replacement - some programs may need slight adaptations. If desired, the time.h include can be added to LibreTuyaAPI.h, where all oher stdlib includes are.

lonerzzz commented 1 year ago

Perfect, I will work those changes for IPAddress then.

For time.h, when I add the include to [parent path]\platformio\packages\framework-arduino-api\api\Arduino.API.h it worked properly so its just a matter of whether or where it fits among your files based on your structure layout.

There is also the matter of the related definitions around time and NTP. I added these:

extern "C" bool getLocalTime(struct tm info, uint32_t ms = 5000); extern "C" void configTime(long gmtOffset_sec, int daylightOffset_sec, const char server1, const char server2 = nullptr, const char server3 = nullptr); extern "C" void configTzTime(const char tz, const char server1, const char server2 = nullptr, const char server3 = nullptr); to [parent path]\platformio\packages\framework-arduino-api\api\Common.h

since that seemed to be where many of the other functions defined in the ESP32 Arduino.h implementation are now located within LibreTuya.

kuba2k2 commented 1 year ago

Hm, ArduinoAPI.h shouldn't be modified in terms of additional includes. There's a file in LT that does that.

The static functions can probably be added on LT as well, but I'm not yet sure where.

lonerzzz commented 1 year ago

Absolutely don't want to change the API. Just trying to get the build to complete with some placeholders. Please let me know when you have defined where you want these elements to go.

kuba2k2 commented 1 year ago

For now you can put them somewhere like arduino/libretuya/common/ntp.cpp. I'm not sure if NTP is a "library" in ESP32 (having a class, something like NTP.doSomething(). If it is, then you can put it in arduino/libretuya/libraries/NTP/NTP.cpp.

lonerzzz commented 1 year ago

Following more investigation, NTP is not a library for ESP32 or for beken chips and in both cases is included in the framework.

[parent path]\platformio\packages\framework-arduinoespressif32\cores\esp32\Arduino.h contains the mentioned code to access NTP:

extern "C" bool getLocalTime(struct tm info, uint32_t ms = 5000); extern "C" void configTime(long gmtOffset_sec, int daylightOffset_sec, const char server1, const char server2 = nullptr, const char server3 = nullptr); extern "C" void configTzTime(const char tz, const char server1, const char server2 = nullptr, const char server3 = nullptr);

and [parent path]\platformio\packages\framework-arduinoespressif32\cores\esp32\esp-32-hal-time.c contains the implementation for these methods with an include of "lwip/apps/sntp.h" which is located at [parent path]\platformio\packages\framework-arduinoespressif32\tools\sdk\esp32\include\lwip\include\apps\sntp\sntp.h

For the Beken chipset, the sntp interface is located at: [parent path]\platformio\packages\framework-beken-bdk\beken378\func\lwip_intf\lwip-2.0.2\src\include\lwip\apps\sntp.h

So it looks like the equivalent middle layer for the methods is what is needed. We then need to have a location where this gets pulled or break with the ESP approach and require a specific include.

kuba2k2 commented 1 year ago

We'd need to check the licensing status of that ESP32 ntp functions. You can put them somewhere, and I'll move them to the new correct place after the refactor (or you can do it locally and wait for the refactor, then add the code).