Hardware control APIs

[seanshpark]

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.

[seanshpark]

As wrote in PR #113, process.iotjs can be used for distinguishing between iotjs and others.
it may also have other properties, such as running product class, H/W board, and network or other environments that is needed to make application to decide better.
If this seems to be a bad idea, please add comments.

[ILyoan]

I think we may need API reference for device control.
And for new module features will be introduced later on, how about consensus of API first and then implementation?

[ILyoan]

https://github.com/Samsung/iotjs/wiki/IoT.js-API:-GPIO

[ILyoan]

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?

[seanshpark]

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.

[ILyoan]

@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?

[seanshpark]

@ILyoan , If you let mode to be input/output, one more thing is floating that is something like disconnected.

Is there any other type of mode besides direction?

Besides direction, to the pin,

• Pull up or down or open-drain(open collector)
• Rise up or down edge detection
• input in digital or analog

[ILyoan]

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 / mode

input

• floating
• pull-up
• pull-down

output

• open-drain
• push-pul

Frequency

Ports

[seanshpark]

Mode control depends on H/W. Is it ok to define actual mode in iotjs? Previous your comment was not to.

[ILyoan]

I'm not sure about it.
My first thought was that mode configuration API might be sufficient if it enable user to select direction("input" or "output"). but you mentioned there are other modes besides it. so I listed it up.

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.

[ILyoan]

What about GPIO API like below:

gpio.set(pin, direction[, callback])

• pin: Number - pin number.
• direction: String - direction of the gpio pin 'in' | 'out'.
• callback: Function(err: Exception | null)

gpio.write(pin, value[, callback])

• pin: Number - pin number.
• value: Boolean - true to turn on false to turn off.
• callback: Function(err)

gpio.read(pin[, callback])

• pin: Number - pin number.
• callback: Function(err: Exception | null, value: Boolean)

Concerns

• API for initializing GPIO may not be needed because we can initalize gpio when it is required.
• API for releasing GPIO may not be needed because we can release resources when program down.
• Setting mode like 'pull-up', 'pull-down', 'open-drain', and etc might not be need if we don't support interrupt based event, I'm not sure about this but my understanding is that this is trivial for most of the use cases, many gpio application could use default mode setting.
• pin number could be actual hardware pin number or it could be gpio number. I prefer later one, so that pin number could be always 1,2,3,... independent on hardware.