Another approach for Atomic Echo Base

[stc1988]

Atomic Echo Base is a useful extension for adding audio input and output functionality to the M5Atom series. On the other hand, the current implementation has issues such as an increasing number of target device definitions and duplicated code.

Therefore, in my proposed approach, the common parts are defined while the differences between devices are managed through a manifest file. The key point here is that the main difference between devices lies in the pin assignments, while the audio settings and initialization processes are common. Instead of adding a device target, we will make it possible to support Atomic Echo Base by including a manifest file, just like using a driver.

This is an experimental implementation to validate this approach.

By using this approach, it becomes easier to handle additional devices in the future.

[phoddie]

The fundamental idea organizing around a base plus peripherals makes good sense.

Reviewing your experimental implementation reminds me that ECMA-419 IO Providers anticipated this in some ways. For example, the PI4IOE5V6408 is a GPIO expander. That can be supported as shown in the IO Providers example. There is an example ECMA-419 GPIO expander implementation in the Moddable SDK along with an example. The driver is documented here as part of ECMA TR/109

One advantage of this approach is that the expander's Digital constructor can be used just like the built-in Digital constructor. So, for example, you can pass it directly to a sensor drive that needs to access the digital pin. The sensor doesn't need to know if it is a built-in pin or on the expander.

I'm not sure if the IO Provider concept works for everything that might be connected to your base, but it could be interesting to explore. I'm happy to try to help.

[stc1988]

Thanks for the comment.
I still don’t fully understand the IO expander, but in this case, implementing it as an IO expander seems a bit excessive.
On the other hand, since the Atomic Echo Base itself also has IO ports via an IO expander, it seems preferable to be able to support that.

I’ll take a proper look again.

[phoddie]

Naturally, the optimal solution depends on your goals.

...seems a bit excessive

How so?