-
Notifications
You must be signed in to change notification settings - Fork 66
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
Custom device #214
Custom device #214
Conversation
Firmware for this pull request: |
Looks reasonable, it's essentially what I did when I had custom devices. I don't understand the init parameter though. What would it get used for? |
Like other devices this custom device can also be initialized multiple times. There could be cases where each/some device must be initialized in a different way or needs different parameters to work. For this the init string would be used. |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
Firmware for this pull request: |
This PR is closed as major changes are implemented in a new branch. |
This is a proposal for adding a custom device to the firmware.
It requires also changes in the connector which have not been done so far.
The intention is to have a base for further discussion.
The pre condition for the custom device is that it will be set up from the connector like:
"kTypeCustomDevice , x.thDevice, Pin1, Pin2, Pin3, Pin4, Pin5, Pin6, initString"
This gives the possibility to use up to 6 Pins from the custom device and to get an init parameter which could differ if more than one custom device from the same type are defined within the connector.
We can also think about not to define 6 fixed Pins but to handle this in a way that only required pins will be defined. In this case Pin1 would be replaced by the number of following Pins.
Data to the custom device should be transferred like for the LCD display. For now a haven't foreseen a different way. I guess this gives the maximum flexibilty to send informations like variables or fixed test or whatever.
A lot of comments are added in the source files to support a user to set up his custom device.
I am pretty sure there will be some optimisation possible in this pull request.
There will come a second pull request with additional changes which are sensefull in my eyes to have maximum flexibility for the custom device.