-
Notifications
You must be signed in to change notification settings - Fork 440
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
Hardware control APIs #110
Comments
As wrote in PR #113, process.iotjs can be used for distinguishing between iotjs and others. |
I think we may need API reference for device control. |
What type of mode could be exist for a pin of GPIO? As far as I know there is only one; direction. Direction of a pin could be either input or output at one time thus rw pin is not possible right? Is there any other type of mode besides direction? |
I've prepared a short page https://github.com/Samsung/iotjs/wiki/GPIO-control-ideas few days ago, and pin mode is described in summary. If you jump to link http://coactionos.com/embedded%20design%20tips/2013/10/21/Tips-Understanding-Microcontroller-Pin-Input-Output-Modes/ there is more. Hope this helps. |
@seanshpark The page you referred are only saying there are input and output mode(direction). Then can we assume that there are no other type of mode? |
@ILyoan , If you let mode to be input/output, one more thing is
Besides direction, to the pin,
|
Let's summarize what pin configuration are commonly definable so we can design our GPIO API more usable for anyone. I see configurable options are: Direction / modeinput
output
FrequencyPorts |
Mode control depends on H/W. Is it ok to define actual mode in iotjs? Previous your comment was not to. |
I'm not sure about it. If detailed configuration(like pull-do/down, open-drain, etc.) was up to hardware (for example, if target architecture was fixed, modes will also be fixed), then we don't need to expose the APIs for control it for user. On the other hand, if some user application should choose detailed mode, we need to provide APIs for it. My intention is that I want to know minimum set of APIs that is enough for controlling GPIO for majority of use case. |
What about GPIO API like below: gpio.set(pin, direction[, callback])
gpio.write(pin, value[, callback])
gpio.read(pin[, callback])
Concerns
|
Binding GPIO in |
these may need for some devices for addition in/out control. so
please look around
yes, nice. currently in private but please look inside |
Then, what about this? gpio.set(pin, direction[, mode][, callback])
It looks like name aliasing such as GPIO1, GPIO2, GPIO3,... is not proper approach as pin specification are very different from HW to HW. Let's just leave aliasing for application until we find general solution. |
|
There may be resource waste. disagree on this.
why use string when number is used underneath? user module can use this. API seems nice but for linux system using /sys/class/gpio, I cannot see how to |
@seanshpark I think using string is more intuitive than using enum like number so easy to understand for user. For example filesystem use We can add API for initialiing / releasing / unset pin. gpio.initialize()Initialize gpio service. User application should call this function before calling any other gpio functions. gpio.release()Release gpio service. gpio.unset(pin[, callback])
|
From discussion today morning, we have formed a consensus for GPIO API candidate. I think this API layout will reflect the idea. iotjs.gpio
gpio.initialize()Initialize gpio control. gpio.release()Release gpio control. gpio.setPin(pinNumber, direction[, mode][, callback])
Configure single pin. gpio.writePin(pinNumber, value[, callback])
Write a boolean value to a pin. gpio.readPin(pinNumber, callback)
Read value from a pin. gpio.setPort(portNumber, direction[, mode][, callback])
Configure single port. All pins bound to this port will have the configuration. gpio.writePort(portNumber, value[, callback])
Write a byte value to a port. gpio.readPort(portNumber, callback)
Read value from a port. gpio.query(queryOption, callback)
|
Great. I've coped above descriptions to GPIO-API-candidate page. I've some comments
|
|
|
I think I got confused. for the JS API, |
@seanshpark, thanks for your confirmation. |
thank you too, I'll begin the implementation when new HW arrives, for testing. |
Closing as we reached consensus about the API: Feel free to reopen if it needed. |
Make a build error when CONFIG_MAX_TASKS is not power of 2
As of today, nodejs is on the discuss to support hardware and libuv is ready with uv_device_t PR.
For IoT.js, how are we going to support hardware control and manage devices?
First PR #105 needs some more adjustments and we need to discuss how to provide the API and manage H/W boards and devices. GPIO-control-ideas is prepared to draw everyones sketch.
Please add comments and write down to WiKi page.
The text was updated successfully, but these errors were encountered: