1166634 - (WebI2C) Implement WebI2C API

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[dynamis (Tomoya ASAI)]

Implement WebI2C API.

This is the bug to implement Web API for I2C (Inter-Integrated Circuit) on Gecko (FxOS).

API spec for this API is not defined nor discussed well yet.
We'll start with experimental implementation like WebGPIO (bug 1166588), then consider to update with Stream API.

references:
W3C Streams API http://www.w3.org/TR/streams-api/
WHATWG Streams Standard https://streams.spec.whatwg.org/

Comment 1

[Masashi Honma]

This is a patch for Mozilla Open Hardware (CHRIMEN).
The CHIRIMEN can run only Firefox OS 2.1 now.
And we does not have hardware which has GPIOs and runs master build.
So this patch is based on Firefox OS 2.1.

https://github.com/MozOpenHard/gecko-dev/commit/6bc3525f524d267220575af20ce2d5d9caffa8d1

And this is a sample app.
https://github.com/MozOpenHard/examples/tree/master/test-i2c
This app is for this I2C hardware.
https://international.switch-science.com/catalog/1405/

Currently this Gecko API does not returns Promise object.
So this app wrap the API to return Promise object.
We will modify this Gecko API to return Promise object.

Comment 2

[naoki sekiguchi]

Currently the WebI2C API maps an address to an I2C port. 
https://github.com/MozOpenHard/gecko-dev/commit/6bc3525f524d267220575af20ce2d5d9caffa8d1#diff-a482e565403c3559cb4c74629e102b75R119

The API should allows to map multiple addresses to an I2C port.

Comment 3

[Dave Hylands [:dhylands]]

I'd recommend that we implement the full set of smbus protocols. I've wound up using all of them with various devices.

The smbus spec defines 9 different "bus protocols":
quick command, send byte, receive byte, write byte/word, read byte/word, process call, block read/write, block write-block read process call and a host notify protocol.

Then there is the traditional read/write used by older non-smbus devices, like EEPROMS.

It should be pretty straight forward to create an AVR device which implements the full API for testing purposes. I have most of the code already written for some AVR projects I did a number of years ago.

Comment 4

[Masashi Honma]

(In reply to naoki sekiguchi from comment #2)
> The API should allows to map multiple addresses to an I2C port.

Thanks for comment and sorry for late reply.
I have implemented it with this patch.

https://github.com/MozOpenHard/gecko-dev/commit/6aea2ad0aeb4c98a26884b21f2a7fa9127bd3e7d

Comment 5

[Masashi Honma]

(In reply to Dave Hylands [:dhylands] (on PTO Jul 11-19) from comment #3)
> I'd recommend that we implement the full set of smbus protocols. I've wound
> up using all of them with various devices.
> 
> The smbus spec defines 9 different "bus protocols":
> quick command, send byte, receive byte, write byte/word, read byte/word,
> process call, block read/write, block write-block read process call and a
> host notify protocol.
> 
> Then there is the traditional read/write used by older non-smbus devices,
> like EEPROMS.
> 
> It should be pretty straight forward to create an AVR device which
> implements the full API for testing purposes. I have most of the code
> already written for some AVR projects I did a number of years ago.

Thanks for comment.

Your suggestion is right from an device layer point of view. I have same opinion because I am a device layer engineer.

But at previous Mozilla WoT work week in Mozilla Japan, a WWW engineer requires "Stream API" for I/O.

So now I think
1) implement 9 bus protocols as Web I2C API
2) Stream API sould be implemented as wrapper of the API (if needed)

And about the non-smbus devices, I think it is not required to support. Because basically Web I2C is used for WoT/IoT things layer. And I think EEPROM access should not be allowed for Browsers because it always includes important data (MAC address etc).

Comment 6

[Dave Hylands [:dhylands]]

On some boards, like the BeagleBone Black, the EEPROM is used to indicate what functionality a particular board is. So this is typically used by the kernel to determine which drivers to load.

If I'm going to be using JS to access custom devices, I want to be able to access anything. Otherwise I'll switch to something else.

I mean I've been avoid JS because it doesn't have decent serial port access and I wind up using Python instead.

Just because one board uses an EEPROM to store a MAC address in, doesn't mean that I'm going to use it for that purpose for some board I might be developing.

Streams only makes sense for a very limited set of access types. For example, most i2c devices would not fit into any type of streaming api. I also create my own custom devices using microcontrollers and might do some oddball interface or emulation.

So, I'm just saying I don't want to be restricted by arbitrary choices made by "the Web".

Comment 7

[Masashi Honma]

(In reply to Dave Hylands [:dhylands] from comment #6)
> On some boards, like the BeagleBone Black, the EEPROM is used to indicate
> what functionality a particular board is. So this is typically used by the
> kernel to determine which drivers to load.
> 
> If I'm going to be using JS to access custom devices, I want to be able to
> access anything. Otherwise I'll switch to something else.
> 
> I mean I've been avoid JS because it doesn't have decent serial port access
> and I wind up using Python instead.
> 
> Just because one board uses an EEPROM to store a MAC address in, doesn't
> mean that I'm going to use it for that purpose for some board I might be
> developing.
>
> So, I'm just saying I don't want to be restricted by arbitrary choices made
> by "the Web".

I understand your opinion. But I think not so much people want to use non-smbus access by JavaScript.
Is to use JavaScript as system programming language Mozilla policy ?
(I am not a Mozilla staff.)

> Streams only makes sense for a very limited set of access types. For
> example, most i2c devices would not fit into any type of streaming api. I
> also create my own custom devices using microcontrollers and might do some
> oddball interface or emulation.

Agree. Stream API wrapper should be made for only appropriate devices.

Comment 8

[BMO Automation]

Firefox OS is not being worked on