Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pull in branch "Feature/16 bit data support" changes into develop - next step is a release #39

Merged
merged 22 commits into from
Feb 13, 2025

Conversation

gigapod
Copy link
Member

@gigapod gigapod commented Feb 10, 2025

Move the latest updates into the develop branch. Once merged ,will spin out a release.

Main changes:

  • Added endian/byte order support
  • expanded 16 bit address support
  • Abstract out platform dependent functions - a start for this
  • Added overloaded set of functions/methods for reading/writing registers.
  • Bus type methods added

gigapod and others added 15 commits November 4, 2024 16:12
…the I2C bus to determine if uint16_t transfers need to swap bytes; note- Arduino SPI does this correctly
…pr approach does not work on all compliers -- needs > c++11
…d. move to leverage the fast built in versions
… core toolkit, provide impl in platform specific driver - better than the namespace thing
Copy link
Member

@SFE-Brudnerd SFE-Brudnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with the vast majority of these changes. A question I did have is if you're changing a couple functions from sfeTk to sftk_ should we be doing that for the entire library?

src/sfeTk/sfeToolkit.h Outdated Show resolved Hide resolved
src/sfeTkArdI2C.cpp Outdated Show resolved Hide resolved
src/sfeTkArdI2C.h Outdated Show resolved Hide resolved
@gigapod
Copy link
Member Author

gigapod commented Feb 12, 2025

For the C function names sfeTk_<> to sfTk_<>

I was going to do sfetk_<*> but the prefix of 5 chars seemed tedious to me - normally like to keep that to 2-4 chars.

But you are correct, this differs from the class names and path used for the toolkit - sfeTk .... we could go to sfTk. Let's discuss tomorrow - I have no issue with it.

@@ -209,11 +209,34 @@ sfeTkError_t sfeTkArdI2C::writeRegisterRegion(uint8_t devReg, const uint8_t *dat
//
sfeTkError_t sfeTkArdI2C::writeRegister16Region(uint16_t devReg, const uint8_t *data, size_t length)
{
devReg = ((devReg << 8) & 0xff00) | ((devReg >> 8) & 0x00ff);
// devReg = ((devReg << 8) & 0xff00) | ((devReg >> 8) & 0x00ff);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can remove comment now that this has been replaced


// okay, we need to swap
devReg = sftk_byte_swap(devReg);
// devReg = ((devReg << 8) & 0xff00) | ((devReg >> 8) & 0x00ff);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can remove comment now that this has been replaced.

// devReg = ((devReg << 8) & 0xff00) | ((devReg >> 8) & 0x00ff);
uint16_t data16[length];
for (size_t i = 0; i < length; i++)
data16[i] = ((data[i] << 8) & 0xff00) | ((data[i] >> 8) & 0x00ff);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use the uint16_t sftk_byte_swap() overload here instead of doing it explicitly?

{
// if the system byte order is the same as the desired order, flip the address
if (sftk_system_byteorder() != _byteOrder)
devReg = ((devReg << 8) & 0xff00) | ((devReg >> 8) & 0x00ff);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use the uint16_t sftk_byte_swap() overload here instead of doing it explicitly?

if (status == kSTkErrOk && sftk_system_byteorder() != _byteOrder)
{
for (size_t i = 0; i < numBytes; i++)
data[i] = ((data[i] << 8) & 0xff00) | ((data[i] >> 8) & 0x00ff);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use the uint16_t sftk_byte_swap() overload here instead of doing it explicitly?

@gigapod
Copy link
Member Author

gigapod commented Feb 13, 2025

FYI -
Everything discussed - except the name changes - are made. This includes moving the endianness logic to the bus interface (and initializing the value to the system endianness value).

Merging into dev.

@gigapod gigapod merged commit 7f152ff into develop Feb 13, 2025
@gigapod gigapod deleted the feature/16-bit-data-support branch February 14, 2025 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants