Re: i2c hal API issues and possible modifications

I also think the calls to read() and write() should be modified to take a flag, which tells whether or not to generate a STOP. Linux’s I2C APIs take a linked list of commands to pass to the device that encompass an I2C “transaction.” The last element of that generates the STOP. This seems

C++ support added to newt

Hi, I’ve added C++ support to Newt in the “develop” branch. In order to use C++ with newt, the compiler definition files have a new entry which is: compiler.path.cpp: arm-none-eabi-g++ -x c++ And newt will search every package for files that end with *.cpp, *.cxx, and *.cc. I decided not

Re: i2c hal API issues and possible modifications

Hi Will, Having control over when the STOP happens is important since different devices will behave differently, especially if you are performing a series of events like read/write/read or something similar. Some devices expect the STOP to happen in different places in a command sequence.

i2c hal API issues and possible modifications

Hello: I am new to i2c so please bear with me. Hopefully this makes sense to the i2c experts out there. In adding i2c to the nordic platforms I ran across an issue that I am not sure how to solve. Well, I know one way to solve it but it would require changes to the API. Here is the issue: In

Re: i2c hal API issues and possible modifications

Well, I do agree that this new API I am proposing is not as clean as the old API; just dont know what else to do. I guess this is part of the problem trying to make generic HALs. At least you will be able to control when the STOP occurs which is the most important thing I think. > On Oct 18,

Re: i2c hal API issues and possible modifications

I would be ok having the extra flag instead of calls to begin/end. > On Oct 18, 2016, at 2:58 PM, Kevin Townsend wrote: > > I agree designing HALs that play well across vendors is difficult since the > peripherals have all kinds of limitations and edge cases, sometimes even