-
Notifications
You must be signed in to change notification settings - Fork 106
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
Enhancements to Pico(W) gpio driver #874
Conversation
968f632
to
a60c772
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this match gpio module type?
I read pin() is a number or a tuple with an atom and a number.
Should we change the pin() type?
a60c772
to
5f16e3d
Compare
Fixed now. |
5f16e3d
to
f5fede6
Compare
f5fede6
to
90d792b
Compare
90d792b
to
90b5290
Compare
90b5290
to
fdffe16
Compare
Fixed now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced returning error tuples is the best semantic, but ERROR_ATOM
was also wrong. I would prefer we raise badarg with bad arguments detected before making the platform API call (for example gpio_set_dir
) and reserve error tuples for errors from the platform's API.
We will need to rewrite the edoc for the driver if we are going to require try catch statement for some of the functions, otherwise deciphering the stack trace and looking up in the source where their code went wrong is a lot more work to decipher than an informative error return. |
This is Erlang, we don't need try / catch but just let the processes die 😁 |
In general our pattern has been to raise an error on badarg (see the VALIDATE_VALUE macro, which we use extensively). As far as the docs, I don’t know if we need to fix every function with a @raises entry. OTP doesn’t go that far. And yeah, it’s Erlang, so “let it fail”. |
I guess I missed the point of #894. |
Here is an example from OTP:
And here is the OTP doc: https://www.erlang.org/doc/man/math (not pointing to OTP as the purveyors of perfect documentation, but…) |
I think my point there was we need to change As far as raising errors, exits, throws, etc (I think we use |
But from this conversation it sounds like we want to |
I think @pguyot ’s point (which I agree with) is that we raise errors on any parameter checks the user has supplied. These are almost always the equivalent of calling When we get to the point of implementing the logic of the function (e.g., interfacing with whatever system we are dealing with), and we get an error back from some API (usually an integer code, or something), we encode that error into something meaningful to the user, like an atom, or even a string if it makes sense (though we have to be careful with size, etc), and we return that error as a tuple: I believe this is fairly established OTP behavior, if not AtomVM behavior. The whole discussion of throw vs return is fraught with debate and not easy to untangle. I think even the idea of try-catch was not without controversy in OTP. Maybe one way to look at it is to distinguish between the kinds of error that are due to the programmer (bad args) and those that are due to the deployment or environment (case |
fdffe16
to
3a8ba9f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about using the tuple semantic, so we can have {wl, 0} instead of creating new ad-hoc additions to the general semantic?
3a8ba9f
to
7c71c5c
Compare
{ ATOM_STR("\x3", "wl0"), 0 }, | ||
{ ATOM_STR("\x3", "wl1"), 1 }, | ||
{ ATOM_STR("\x3", "wl2"), 2 }, | ||
SELECT_INT_DEFAULT(-1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would use a mnemonic define here for -1.
@@ -96,7 +105,7 @@ static term nif_gpio_set_pin_mode(Context *ctx, int argc, term argv[]) | |||
int gpio_num = term_to_int(argv[0]); | |||
int mode = interop_atom_term_select_int(pin_mode_table, argv[1], ctx->global); | |||
if (UNLIKELY(mode < 0)) { | |||
return ERROR_ATOM; | |||
throw(BADARG_ATOM); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no throw in C. Use the RAISE_ERROR macro
term level_term = argv[1]; | ||
|
||
int level; | ||
if (term_is_integer(level_term)) { | ||
level = term_to_int32(level_term); | ||
if (UNLIKELY((level != 0) && (level != 1))) { | ||
return ERROR_ATOM; | ||
throw(BADARG_ATOM); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RAISE_ERROR
That is a very good point that I didn't even consider... I think that makes a lot more sense, I will go back and make that change. |
7c71c5c
to
25bbda8
Compare
I pushed changes using a |
I realize a lot of effort has been put in this PR and it is very good work. The pico gpio code was just a draft and the platform will soon have something on par with the others in this domain. Thank you @UncleGrumpy |
11668f6
to
66c8cdf
Compare
Modifies the Pico gpio dirver to accept atoms for the special wl_gpio pins present in the Pico-W. - Adds support for `wl0` and `wl1` as output pins in `gpio:digital_write/2`. - Adds support for `wl2` as an input pin in `gpio:digital_read/1`. Signed-off-by: Winford <[email protected]>
66c8cdf
to
1f310fb
Compare
Modifies the Pico gpio dirver to accept atoms for the special wl_gpio pins present in the Pico-W.
{wl, 0..1}
as output pins ingpio:digital_write/2
.{wl, 2}
as an input pin ingpio:digital_read/1
.badarg
instead of returningerror
These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).
SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later