Closed x0id closed 1 year ago
I personally like this change a lot. In hindsight, I really wish that I had not put the call to IO.iodata_to_binary(data)
in there. My intention is to merge, but I want to review some uses of circuits_uart
to check if they need to be updated and to see if I'm forgetting anything. Give me a few more days and I should have a good window of time to get this in and make a release.
Also, thanks for the EnOcean link. You have a good use case to motivate this.
Hi, is there any chance to make a progress with this PR?
@x0id - Sorry, I do look at it from time to time, but it's API breaking, doesn't have docs and has no tests. I really wish I did this in the beginning, but I don't have the time now to see through the API update and their ramifications on other libraries. If there were a way to make sure that code relying on IO.iodata_to_binary/1
being called still worked, that would make it an easier merge.
@fhunleth If you really like the proposed change, it is easy to make a progress.
I don't see a lot of activity in this project, so I think it would not be a problem to support old and new APIs for some reasonable time. Also, this is a rare chance that somebody uses master reference in the dependency list (especially in production). It is usually a bad practice to follow.
This is useful for complex framing cases, like, for example, EnOcean Serial Protocol 3 (ESP3) - https://www.enocean.com/esp3/, which has 2 checksums in the frame. It is more convenient to represent an application message as a tuple or structure than a binary or iolist, since unframing resulted in a broken-down message and vice versa.