-
Notifications
You must be signed in to change notification settings - Fork 191
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
Capabilities query parsing #51
Comments
Hmm I think this would need bigger rewrite - there is problem that the same pin is capable of analog input and digital output, but there is two instances of pin in that case (one in I will prepare some patch and send a pull request, but this will lead to some changes in API to correct this bug. Boards definitions should contain real pin numbers for analog inputs (or some mapping of them), or auto configuration should be used. |
* Enhanced autoconfig, which handles capabilities query with mixed modes (fixes issue tino#51) * Pins can be both digital and analog pin (analog pins could be often used as digital pins) * All pins are saved into global board.pins list, each pins exists in one instance and in board.digital/board.analog are references to the same objects
* Enhanced autoconfig, which handles capabilities query with mixed modes (fixes issue tino#51) * Pins can be both digital and analog pin (analog pins could be often used as digital pins) * All pins are saved into global board.pins list, each pins exists in one instance and in board.digital/board.analog are references to the same objects
* Enhanced autoconfig, which handles capabilities query with mixed modes (fixes issue tino#51) * Pins can be both digital and analog pin (analog pins could be often used as digital pins) * All pins are saved into global board.pins list, each pins exists in one instance and in board.digital/board.analog are references to the same objects
* Enhanced autoconfig, which handles capabilities query with mixed modes (fixes issue tino#51) * Pins can be both digital and analog pin (analog pins could be often used as digital pins) * All pins are saved into global board.pins list, each pins exists in one instance and in board.digital/board.analog are references to the same objects
* Enhanced autoconfig, which handles capabilities query with mixed modes (fixes issue tino#51) * Pins can be both digital and analog pin (analog pins could be often used as digital pins) * All pins are saved into global board.pins list, each pins exists in one instance and in board.digital/board.analog are references to the same objects
Prepared for merge in #52. After this will be merged I am ready to sent more pull requests with new features based on this rewrite :-) |
* Enhanced autoconfig, which handles capabilities query with mixed modes (fixes issue tino#51) * Pins can be both digital and analog pin (analog pins could be often used as digital pins) * All pins are saved into global board.pins list, each pins exists in one instance and in board.digital/board.analog are references to the same objects
In
util.py
in functionpin_list_to_board_dict
there are some assumptions which may not be always true:For example I have some board, which returns this byte array of capabilities for some pin: [0, 1, 11, 1, 1, 1, 4, 14]
I think we need to save capabilities for the pins in more general way.
@tino have you any idea how do you want to implement these features? I am ready to implement them and send a pull request (and other pull request to add pin state queries).
The text was updated successfully, but these errors were encountered: