nrf52 - fix i2c/twi driver

[maciejbocianski]

Sync TWI driver to sdk version 15.3.0 to get rid of data length limitation

Description

Pull request type

[X] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@jamesbeyond

Release Notes

[ciarmcom]

@maciejbocianski, thank you for your changes.
@jamesbeyond @ARMmbed/mbed-os-maintainers please review.

[40Grit]

I could always tell whoever wrote the nrf i2c driver probably had not used it very extensively.

Was really annoying bug, especially when trying to dump an accelerometers large sample buffer.

Though using int like the mbed os api does is not much better.

[0xc0170]

Though using int like the mbed os api does is not much better.

Is this related to drivers using basic types like int ?

[kjbracey]

Is this related to drivers using basic types like int ?

Just like uint8_t can be too small for data size, so could int. size_t is technically correct.

But in practice, in Mbed OS-size embedded systems, int is probably fine, and may be preferable. For example, Nanostack tends to avoid size_t, due to 8 or 16-bit platforms that use a large memory model to address ROM (>64K), but have <64K RAM. In those platforms, size_t is 32-bit to cope with ROM objects, but it's overkill and bloat for RAM buffers. So I'd be sympathetic for int if envisaging portability to those systems.

But if assuming 32-bit ARM or bigger, then size_t is solid - there's no overhead, and only a benefit when you go 64-bit.

[40Grit]

@0xc0170, @kjbracey-arm

My main beef with int is its signed-ness and the fact that it provides no implication as to it's use.

Maybe if we had an '''i2c_tranceive()''' function signed length would make sense. I joke.

I am a huge fan of type defining for context as well.

[kjbracey]

My main beef with int is its signed-ness and the fact that it provides no implication as to it's use.

I'm aware that there's a large contingent of people who regard the unsignedness of size_t as a significant problem. (eg https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-nonnegative) I can see the arguments both ways.

I am a huge fan of type defining for context as well.

Agreed - if doing that, I'd prefer to have some sort of buffer_size_t typedef to at least indicate what it is. (Even if it doesn't actually cause any real compiler type checking).

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts