I saw the comments Greg. Thank you so much for sharing that expertise. I
haven¹t had enough experience with I2C; your help is going to make this
great.
Regarding the commentsŠ. The mynewt team is in release mode today-Friday.
I¹m on another project today but will get to these comments tomorrow.
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
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.
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). 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.
Paul
On 4/20/16, 5:01 AM, "Greg Stein" <[email protected]> wrote:
>Sorry I missed this conversation ... I've commented on the recent commit.
>Please see my feedback there. I can chat about I2C for hours :-)
>
>On Tue, Apr 19, 2016 at 1:42 PM, [email protected] <[email protected]> wrote:
>
>> All,
>>
>> Please take a look at the i2c HAL api in
>>
>> https://github.com/apache/incubator-mynewt-core/pull/44
>>
>> I chose a simple blocking API for now to get some I2C functionality
>>fast.
>> Its mostly just read/write, with a few other functions.
>>
>>
>> 1. probe - I found that immediately after writing this I need some
>>way
>> to discovery what was on the bus. I wrote this simple function to look
>>for
>> a single address.
>> 2. Start/stop - Many devices are just read/write registers so there
>>is
>> no need to control transactions on the bus. However, for serial eeprom
>> random access, its more efficient to write an address then read the
>>data.
>> In this case you would issue start,write,read,stop.
>>
>> Paul
>>
