On Wed, Apr 20, 2016 at 11:01 AM, [email protected] <[email protected]> wrote:
>...

> What I¹d like to do is address the issues by commenting the API.  I¹ll try
> to do this tomorrow and commit comment changes only to the i2c HAL
> 1) Address the comment errors
> 2) detail the current timeout behavior (describe what it does now).
> 3) detail the usage of start/read/write in combination
>

Sounds great!


> Your other API changes look good, but I need to give them a thorough read
> and test. I will probably not be able to get that into the current
> release.  I¹m shooting for monthly HAL releases, but am trying to build a
> roadmap now.
>

No rush, so get your other stuff done. I'll still be around :-)

I think that we are trying to do two conflicting things with the HAL.
>         1) providing abstracted, but complete, hardware functionality
>         2) creating a simple usable API
>
> These two things may be leading to tradeoffs (simple versus full
> functioning). A new idea (for Mynewt) is to have a hal layer which
> abstracts the hardware at the lowest level possible with a somewhat more
> complicated API, and then a driver level which uses the HAL to provide
> robust user APIs (I2C is a good example).


Gotcha. I can see the tension. I2C might be difficult to create a
low-level, close-to-metal layer. I'm not sure what the various hardware
interfaces look like. I *do* know the Raspberry Pi cannot do repeated
starts, due to a buggy hardware implementation :-( ... I can only imagine
some of the crazy that might be involved at the different hardware
implementations/interfaces. My experience is with "no support at all", so I
bit-bang it on the PIC. Forces you to learn details real quick :-P

I can certainly help with the high-level API, and then when some
implementations are built where I can see the low-level h/w interface, can
help with defining the split.


>   I don¹t know what exactly that
> looks like yet but your expertise is invaluable.  I¹m trying to write up
> my thoughts and the get a concrete example going.  Maybe I2C is the right
> one to start with.
>

As you'd like. I'll keep watching for further commits, and offer reviews.
Might even have to clone me up a local repo ;-)

Cheers,
-g

Reply via email to