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

Make the SPI *_readInt and *_writeInt weak symbols #50

Open
fleutot opened this issue Jan 25, 2024 · 0 comments
Open

Make the SPI *_readInt and *_writeInt weak symbols #50

fleutot opened this issue Jan 25, 2024 · 0 comments

Comments

@fleutot
Copy link

fleutot commented Jan 25, 2024

I am using the TMC4671, but I suppose that my issue is valid for most other target chips.

The current version of the API requires the user to implement tmc*_readwriteByte. It implements its own tmc*_readInt and tmc*_writeInt, which in turn calls to that user-defined function.

This implies that the firmware is involved and makes calls between each byte of the datagram.

MCUs often offer the possibility to send multiple bytes at once (one API call, maybe even one peripheral trigger), allowing to send a whole datagram with much fewer operations.

To do that, I would like to be able to override the _readInt and _writeInt functions with my own functions, written appropriately for the MCU I am using.

I understand that it is a good idea to let the current functions be there, for simplicity. However, making them weak would also let the user write their own, more efficient, version.

I have just tested that in my personal clone of TMC-API, with great success:

__attribute__((weak)) int32_t tmc4671_readInt(uint8_t motor, uint8_t address)
{
    // ...
}

Please consider making these functions weak, so that users can use your library without modifications.

Note: attributes to make weak symbols are not part of the C standard, so this might require some kind of pre-processor-fu. But I don't think that this is very difficult.

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

No branches or pull requests

1 participant