Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UART for Erlang? #185

Open
siiky opened this issue Dec 2, 2024 · 1 comment
Open

UART for Erlang? #185

siiky opened this issue Dec 2, 2024 · 1 comment

Comments

@siiky
Copy link

siiky commented Dec 2, 2024

This is not a bug report or feature request, it's a "mood check" if you will.

I was recently searching for the best way to use UART in BEAM (preferably Erlang), and created a related forum thread. The only maintained library appears to be this one, in Elixir, which makes it not that straightforward to use from Erlang.

In hindsight, as one of the replies to that post suggested, it's obvious that the circuits_uart C port is likely reusable for an equivalent circuits_uart library in Erlang. However, it would probably be beneficial for everyone involved (maintainers and users of the Elixir and (hypothetical) Erlang libraries) if the common C port could be maintained in common rather than separately.

Another alternative would be to have an Erlang "baseline" library, on which the Elixir library is based on. It doesn't sound like a very good idea given the current state of affairs, though, because the Elixir library would need to be rewritten for little or no benefit.

So I'd like to know what's the "mood", in particular of current circuits_uart maintainers and users, regarding this question of making it easier to create a circuits_uart library in Erlang.

@fhunleth
Copy link
Contributor

fhunleth commented Dec 2, 2024

I'm definitely not opposed. The inability to use an Elixir library from Erlang makes me sad, but I'm aware that solving that problem is way harder than figuring out a good way to share this library's C port.

I'm really not sure where things will land. I wonder if it's best for you to copy/paste the C port for the first pass just in case there's a showstopper. I'd hate to spend a lot of time making things generic only to find out that there's a flaw in the current API that requires big changes.

Full disclosure here: This library has been around for 8 years and some of the decisions I made way back are different than ones I'd make today. However, it's definitely been more than "good enough", so I didn't put in the effort. If you need something for very fast UARTs (e.g., 4+ Mbps), then that might come up. My usage has maxed out at 1.5 Mbps on an 600 Mhz embedded device.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants