AP_HAL_ESP32 mega new feature branch - with AP_Periph support, CAN drivers, generated hwdef.h from hwdef.dat support and more

[davidbuzz]

All targets seem to build except esp32buzz + periph which needs code changes to build.

tests done:

generic s3 target using new-for-esp32 hwdef.dat to build from:
rm -rf build; ./waf configure --board=esp32s3buzz ; ./waf plane --jobs=7
-- builds ok

generic 'classic' esp32 target using old/current/existing esp32buzz.h static header to build from:
rm -rf build; ./waf configure --board=esp32buzz ; ./waf plane --jobs=7
-- builds ok

s3 periph target using hwdef.dat new-for-esp32:
rm -rf build; ./waf configure --board=esp32s3buzz_periph ; ./waf AP_Periph --jobs=7
-- builds ok

classic esp32 periph target using using old/current/existing esp32buzz.h static header to build from:
[ needs changes to the header to build currently as i haven't made a new old-style board that is periph-enabled ]
put this in ./libraries/AP_HAL_ESP32/boards/esp32buzz.h

// #define AP_PERIPH 1
// #define HAL_CAN_DEFAULT_NODE_ID 42
// #define HAL_BUILD_AP_PERIPH 1

.. and this in ./libraries/AP_HAL_ESP32/hwdef/esp32buzz/hwdef.dat

env AP_PERIPH 1

... and this turns the build into a "periph" build...
-- builds ok

./Tools/scripts/configure_all.py --stop --esp32
-- configures all 'esp32' boards without error if your environment is setup to build esp32/esp32s3

./Tools/scripts/configure_all.py --stop
-- configures all chibios boards without error

tests not yet done: (yet)

• putting any of these binaries on real hardware and making sure it boots etc.
• attaching enough hardware to be able to put it on a CAN bus and that sort of thing

history:

• more than a year ago, when this was first experimented with, it was tested well enough to put it on a CAN bus and correctly get issued a node id, and show up in missionplanner, but its been cleaned up and rebased and code has moved on since then, and the idf version has changed so none of that testing is to be trusted. :-)

[davidbuzz]

here's the two main targets i'm working with and how to upload them:
( the port-auto-detection works for me, but if it doesn't for you you can also set ESPPORT=/dev/ttyACM0 or ESPPORT=/dev/ttyUSB0 etc - the port name depends on which usb port u are plugged into on a dual-port board, but either works for upload)
./waf configure --board=esp32s3buzz ; ESPBAUD=921600 ./waf plane --jobs=15 --upload
./waf configure --board=esp32s3buzz_periph ; ESPBAUD=921600 ./waf AP_Periph --jobs=15 --upload

[srmainwaring]

@davidbuzz - I've built this PR (rebased on master) for esp32 targets: esp32empty, esp32s3empty: - builds ok, but when flashed to esp32s3 there is a repeated message regarding uart initialisation and no wifi.

I then cherry-picked a rebased-on-master version of @tpwrules's esp32s3m5stampfly branch over this branch to see if that worked, and currently it does not. The baro will not initialise, not surprising given the above, so further investigation needed.

The stampfly branch, rebased on master, and excluding this PR does fly if the recent changes to RCOutput are reversed and replaced with the stampfly branch's version.

For this PR, would it be possible to split out the changes needed to support CAN from those for AP_Periph? That might make it easier to work through, as there is a lot in here.

The second thing needed, although it's an unrelated series of PRs, is to get changes in https://github.com/tpwrules/ardupilot/tree/stampfly grouped into a set of PRs and merged. I'd like to use the flying stampfly as a baseline, as that's something I have access to, is operational with a sensor suite, and is easy to check.

I'd like to help with both, and propose as an intermediate target for testing this PR to get a CAN GPS / compass module running on the stampfly. That doesn't exhaustively test everything that is in here, but would include a portion of it.

[MR-VENOM]

Why is the optical flow sensor disabled . Any peticular reason for that ?

[davidbuzz]

Why is the optical flow sensor disabled . Any peticular reason for that ?

nope, just because this is (a) a huge collection of code produced over a long time (b) not something i'm personally interesrted in (c) not hardware I have and (d) as the "main" maintainer of the esp32 port/s for quite a while, not something I see most of the esp32 user/s wanting.