@Inspirati thank you very much for the preview, I have taken a bit of time to review and consider.

Primary goal is to achieve little impact on the existing codebase.

I fully support this, the code is reasonably portable with only the timer and flash APIs being specific (and easily ported to other MCUs).

However, I do have some pause and concern with this particular approach.
Specifically, directly importing the esp32 code (lib/espidf) makes me uneasy. I'm unsure of the maintenance burden this may (or may not) entail.

A significant chunk of this effort has been splicing in the espidf framework with further work needed to manage and integrate the build to support both rp2040 and esp32.
This means we are creating our own multi-platform build system, something which is likely to become more complicated as more platforms are desired.

Perhaps an alternative to this effort (which I have already been idly entertaining), port the project to Zephyr.
In theory this would allow many more platforms to be supported, but especially rp2040 and esp32 support seems adequate for our needs.
Furthermore, platform support should be 'just' a device tree file configuration.

Zephyr also provides functionality that would supersede some of the custom work here, especially:

• shell/cli (https://docs.zephyrproject.org/latest/services/shell/index.html)
• USB HID (https://docs.zephyrproject.org/latest/connectivity/usb/device/usb_device.html#usb-human-interface-devices-hid-support)
• logging (https://docs.zephyrproject.org/latest/services/logging/index.html)

Of course, this is more effort, but I believe has longer term benefit.

Regardless of the outcome, thank you @Inspirati for your interest, I appreciate it.

G'day gkoh, I appreciate your timely response.

Primary goal is to achieve little impact on the existing codebase.

Preliminary proof of concept would ideally not make a mess of your current art, such that #if/#endif is apt to do.

I fully support this, the code is reasonably portable with only the timer and flash APIs being specific (and easily ported to other MCUs).

Thankfully I found the code easily portable, unlike many other projects I have worked with. I only came here looking to glean the interrupt driven cec decoder, however have found myself venturing far beyond..

However, I do have some pause and concern with this particular approach.
Specifically, directly importing the esp32 code (lib/espidf) makes me uneasy. I'm unsure of the maintenance burden this may (or may not) entail.

This is only the pathway, and not an intended destination. 'tis only meant as a means to achieving my objective of evaluating the desired routines in an esp environment.

A significant chunk of this effort has been splicing in the espidf framework with further work needed to manage and integrate the build to support both rp2040 and esp32.
This means we are creating our own multi-platform build system, something which is likely to become more complicated as more platforms are desired.

I am a make (makefile) aficionado myself, having never taken favourably to cmake. This recent experience is only reinforcing such. A brief attempt at coercing cmake to do what is required, with both the esp-idf and pi vscode extensions in mind, has proven frustratingly futile.

Perhaps an alternative to this effort (which I have already been idly entertaining), port the project to Zephyr.

Not familiar with Zephyr so shall take a look. However upon initialy noting it is an rtos unto itself, my hopes are not high. The entire espressif ecosystem seems to be very much tightly coupled to freertos. Indeed, the freertos scheduler is already running before main (or rather app_main) is invoked. My guess is this would prove more challenging than the multi-platform build dilemma. But trying to run Zephyr within a freertos task could be fun, until it aint.

In theory this would allow many more platforms to be supported, but especially rp2040 and esp32 support seems adequate for our needs.
Furthermore, platform support should be 'just' a device tree file configuration.

I feel like your quotation marks around 'just' are justified. Rarely such is the case with such things.

Zephyr also provides functionality that would supersede some of the custom work here, especially:

shell/cli (https://docs.zephyrproject.org/latest/services/shell/index.html)

I quite like the shell, and have now got it coupled with a relative minimum of effort. Abstracting it for ready extension may be a another story, so I probably won't be taking it away with me.

USB HID (https://docs.zephyrproject.org/latest/connectivity/usb/device/usb_device.html#usb-human-interface-devices-hid-support)
logging (https://docs.zephyrproject.org/latest/services/logging/index.html)

As per above (re cec interrupt algorithm), I am not planning on going there, and would leave this functionality to the next guy.

Of course, this is more effort, but I believe has longer term benefit.

Let's see what I make (intended) of Zephyr.

If you could please report back any regressions with the pico build, such would be a great help. I'm not exactly set-up, nor familiar enough with it, to be at all thorough. My basic philosophy being that if I don't touch it, it shouldn't break?

G'day gkoh, I appreciate your timely response.
@Inspirati You are most welcome.

Primary goal is to achieve little impact on the existing codebase.

Preliminary proof of concept would ideally not make a mess of your current art, such that #if/#endif is apt to do.

Based on #49 I think we can minimise #{if,endif} macro hell.
Specifically, if we refactor hdmi-link accurately, it should be the only place platform specific code needs to occur.
Using this PR, it could almost be the build system just including the right source files, eg. there would be a hdmi_link_rp2040.c and hdmi_link_esp32.c, the disparate CMakeLists.txt would use the desired one.

I fully support this, the code is reasonably portable with only the timer and flash APIs being specific (and easily ported to other MCUs).

Thankfully I found the code easily portable, unlike many other projects I have worked with. I only came here looking to glean the interrupt driven cec decoder, however have found myself venturing far beyond..

Excellent, I did spend some time refactoring things so they were clean.
Of course, I didn't go far enough.

However, I do have some pause and concern with this particular approach.
Specifically, directly importing the esp32 code (lib/espidf) makes me uneasy. I'm unsure of the maintenance burden this may (or may not) entail.

This is only the pathway, and not an intended destination. 'tis only meant as a means to achieving my objective of evaluating the desired routines in an esp environment.

At a minimum, I would be fine with this being a staged approach, I recall that "perfect is the enemy of done".

A significant chunk of this effort has been splicing in the espidf framework with further work needed to manage and integrate the build to support both rp2040 and esp32.
This means we are creating our own multi-platform build system, something which is likely to become more complicated as more platforms are desired.

I am a make (makefile) aficionado myself, having never taken favourably to cmake. This recent experience is only reinforcing such. A brief attempt at coercing cmake to do what is required, with both the esp-idf and pi vscode extensions in mind, has proven frustratingly futile.

Aha, a fellow Makefile zealot 🙂
Thankfully, CMake is unlikely to completely supplant make itself, it still relies on it for the actual build process.

Perhaps an alternative to this effort (which I have already been idly entertaining), port the project to Zephyr.

Not familiar with Zephyr so shall take a look. However upon initialy noting it is an rtos unto itself, my hopes are not high. The entire espressif ecosystem seems to be very much tightly coupled to freertos. Indeed, the freertos scheduler is already running before main (or rather app_main) is invoked. My guess is this would prove more challenging than the multi-platform build dilemma. But trying to run Zephyr within a freertos task could be fun, until it aint.

My suggestion here would be to completely replace FreeRTOS with Zephyr, not integrate the two.
There is increasing support for ESP32 from Espressif themselves, thus this landscape is continuously changing (and perhaps improving).

In theory this would allow many more platforms to be supported, but especially rp2040 and esp32 support seems adequate for our needs.
Furthermore, platform support should be 'just' a device tree file configuration.

I feel like your quotation marks around 'just' are justified. Rarely such is the case with such things.

Yes, I'm wary of what is advertised vs what is true.
When I find some time, I will give Zephyr's build framework 'west' a trial.

Zephyr also provides functionality that would supersede some of the custom work here, especially:

shell/cli (https://docs.zephyrproject.org/latest/services/shell/index.html)

I quite like the shell, and have now got it coupled with a relative minimum of effort. Abstracting it for ready extension may be a another story, so I probably won't be taking it away with me.

tclie is indeed quite nice.
I did find some issues if you nest the regex too deep, it just 'got stuck' (which I suspect was a stack overflow, but never proved).

USB HID (https://docs.zephyrproject.org/latest/connectivity/usb/device/usb_device.html#usb-human-interface-devices-hid-support)
logging (https://docs.zephyrproject.org/latest/services/logging/index.html)

As per above (re cec interrupt algorithm), I am not planning on going there, and would leave this functionality to the next guy.

Of course, this is more effort, but I believe has longer term benefit.

Let's see what I make (intended) of Zephyr.

If you could please report back any regressions with the pico build, such would be a great help. I'm not exactly set-up, nor familiar enough with it, to be at all thorough. My basic philosophy being that if I don't touch it, it shouldn't break?

As noted in #49, I regard clang-format a requirement to ensure merges are as clean and minimal as possible.
If you are able to do that, the CI will check the builds for you.
Furthermore, I can do actual device testing as needed.

@Inspirati Might be better to exclude the imported sources from clang-format.
It's in the workflow here:

Note I exclude the cloned into external libraries (FreeRTOS-Kernel, crc, tcli, etc).

@Inspirati Might be better to exclude the imported sources from clang-format. It's in the workflow here:

pico-cec/.github/workflows/main.yml

Line 28 in 23fb232

exclude-regex: '(crc\/.+|FreeRTOS-Kernel\/.+|pico-sdk\/.+|tcli\/.+)'

Note I exclude the cloned into external libraries (FreeRTOS-Kernel, crc, tcli, etc).

I went ahead and did this to help move things along.