-
Notifications
You must be signed in to change notification settings - Fork 3k
Mode added to BusIn + allow creation of NC pins #247
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
Conversation
Now BusIn can also use PullUp, etc, instead of only BusInOut. If the pin is NC, it does get to the init, but all write/mode functions are disabled. This is how it used to be in the old gpio version. Quite some libraries allow users to make pins NC, and they are all locking up with the current mbed version. This is far from a perfect solution, but more a temporary fix.
Hello Erik, what do you propose as nicer solution? It's inconsistent now, there's a condition in the init function for pin == NC, and the rest gpio HAL functions do not handle it. What if you remove that NC condition from all gpio init and edit the gpio.c, so if NC is defined, do not invoke mbed HAL. With this, we assume that users don't call mbed HAL directly with pin defined as NC, which could lead to raising an exception. If this is not desired, mbed HAL should take care of NC pin case. Regards, |
You are too fast ;). I just made a post @ https://groups.google.com/forum/?authuser=0#!topic/mbed-devel/cy9Sk2r-4Is. Maybe handiest to do the discussion there: I have no idea when there is a new real mbed version, but I do feel that while this solution is not perfect, it is alot better than many user libraries not working with the latest version because it mysteriously locks up. If before there is a new version there is a better solution, all the better :) |
Is there a problem with this? |
Hi, I need to understand how this affects our core code and various platforms and I don't have enough time at the moment to look at this, so I'm going to postpone it for a while. Sorry about that. Best, |
Out of curiosity: Which part? The BusIn code is just the same as BusInOut, but with DigitalIns instead of DigitalInOuts. And the NC part only has an effect if you supply NC to a GPIO pin, which currently crashes the microcontroller on every platform that I am aware of, it is hard to do it worse than that. |
The part where I simply didn't have enough time to look at this and understand the problem :) When I accepted the GPIO refactoring code, I didn't realize that constructing a pin with a NC argument is a legitimate use case, thus I didn't consider the implications. This pull request, while not ideal, is indeed a partial solution. I'll think about a more complete solution for the future. |
Mode added to BusIn + allow creation of NC pins
… get non-public targets (ARMmbed#247) * Add a way to get target attributes for non public targets * Document all WiFi and LoRa modules * Fix some errors * Fix another CMake error
Now BusIn can also use PullUp, etc, instead of only BusInOut.
If the pin is NC, it does get to the init, but all write/mode functions
are disabled. This is how it used to be in the old gpio version. Quite
some libraries allow users to make pins NC, and they are all locking up
with the current mbed version. This is far from a perfect solution, but
more a temporary fix.