[Library Manager] Please add I2C_DMAC and BMP280_DEV libraries

[ghost]

Please could you add the following Arduino libraries:

https://github.com/MartinL1/BMP280_DEV

https://github.com/MartinL1/I2C_DMAC

Thank you.

It's my first attempt at adding libraries to the Library Manager, please could you let me know if anything is amiss?

[ladyada]

@MartinL1 heyyy... this is interesting, do you want to perhaps add it to the adafruit samd BSP?

[ghost]

@ladyada Hi. The Adafruit SAMD Board Support Package? Which repository do you have in mind?

[ladyada]

hmm - would it be fully TwoWire compatible? I was thinking how people could use this without re-writing libraries :)

[ghost]

@ladyada The I2C_DMAC library could in theory be used in a similar manner to TwoWire library. It would be possible to have the same TwoWire function calls, but instead perform the transfer in hardware using the DMA controller.

However, while some of the higher level I2C_DMAC functions such as WriteByte() and ReadBytes() operate in a similar manner to the TwoWire library, the lower level function calls separate out the initialisation of the DMAC from the transmission and reception of data. This allows the DMAC to be intialised just once and data transfer to be repeated continously for maximum efficiency.

The other thing is that the I2C_DMAC library currently only works in bus master mode.

[cmaglie]

In the meantime I've added the library to the indexer. Let me know if there is something else I can do.

[ghost]

@cmaglie Thank you for adding the I2C_DMAC library to the libraries manager.

I know that there are currently quite a few BMP280 libraries on the library manager already, but if possible, please could you also add the BMP280_DEV library as well? Thanks.

[cmaglie]

Oops sorry about that, I read the discussion and I totally missed the second library! Now i've added BMP280_DEV too.

[ghost]

Thank you.

[ladyada]

thanks @cmaglie ! :)

@MartinL1 since this isn't a subclass of TwoWire, perhaps it would be easier to add it as an interface to our new I2C wrapper library (it abstracts away the device and register objects) so we don't have the same copy-n-paste chunk all the time: https://github.com/adafruit/Adafruit_BusIO we're using it for new libraries and will probably go back and redo old ones as well. see https://github.com/adafruit/Adafruit_VEML7700/blob/master/Adafruit_VEML7700.cpp#L46 for a demonstration

[ghost]

@ladyada Thank you for the links to your Bus IO Library and the VMEL7700 example.

I see, so the Register and Device objects are completely abstracting the user from I2C device's registers and underlying communications.

The I2C_DMAC library could be used for either blocking or non-blocking I2C communication in conjunction with the Device object for the SAMD21/SAMD51. In the non-blocking case, some additional wrapper functions would however be required to support synchronization of the DMA controller data transfer with the loop() code.

[ladyada]

we could update the write/read functions with block=True default, and if non-blocking, use DMA

for each read/write we'd have to check the DMA is complete, of course!

[PaulStoffregen]

@ladyada - Wow, so glad to see you're now interested in non-blocking APIs!

[ladyada]

@PaulStoffregen yes! i'm for it as long as it isnt default because classic arduino is not non-block friendly. have you had a chance to look at the SPITFT to see if you can adapt your non-blocking API into it?

[PaulStoffregen]

The SPITFT matter is about FIFO support, which is basically an optimization to blocking, but still blocking at the end of each transfer. Going to refrain from writing a lengthy message, since I'm finishing up a 6 layer & fine-patch BGA layout right now. Probably won't look at SPITFT or any other non-critical library issues until after this PCB is done.

Over the last couple years, I've started work on the larger "arduino is not non-block friendly" issue. I've tried over and over to involve the Arduino folks, but they just don't seem interested. Last year they intended to set up monthly chats, but then held only 1 (or only 1 as far as I know) They expressed interest in some sort of developer meeting before Maker Faire in May. But now it's 2 months away (time to book airfare) and @mbanzi isn't even answering my emails - so I'm afraid the prospects of collaborating or even communicating with Arduino on major core lib & API design choices aren't looking good. :(

If Arduino doesn't step up with non-blocking APIs, maybe in the summer we could collaborate on a substantial set of Arduino non-blocking API extensions? Especially with Adafruit now shipping more powerful SAMD51 boards, and PJRC soon to ship powerful M7-based Teensy boards, we really good, well thought out non-blocking APIs that will let Arduino libraries be crafted in ways that automatically work together on these powerful processors that don't burden novice users.

[ladyada]

Yep sounds good to me, we have some well-working SAMD21 and '51 DMA code and it would be good if it were not floating around but grounded in an API that would let people DMA various peripherals.

(ps. unrelated but just came in - do you have this famous blog post text anywhere else? https://dorkbotpdx.org/blog/paul/battery_pack_load

[PaulStoffregen]

Since that site deleted its blog section, I've been republishing those old articles on the PJRC site, one every other Friday. That one is in the queue. I'll post that one for you this Friday.

[PaulStoffregen]

@ladyada - blog article reposted - https://www.pjrc.com/battery-pack-load/