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

The Functor in I2C implementation appears to not working as expected #112

Open
slavdors opened this issue Feb 17, 2023 · 4 comments
Open
Assignees
Labels

Comments

@slavdors
Copy link

I may be misusing the feature, but I cannot make it working.
I am referring to the FUNCTOR template parameter in:
template<typename MANAGER, uint8_t REGISTER, typename T, typename FUNCTOR = functor::Identity> class TReadRegisterFuture
It appears only compiling when both FUNCTOR::ARG_TYPE and FUNCTOR::RES_TYPE types are related (when a cast is possible). I am not able to compile the code when both types are not related (and that's what I thought the functor was in the first place - to make this conversion possible).
Looking at the code in the ReadRegisterFuture template (i2c_device_utilities.h) I cannot see how it is possible for it to work.

Apologies for raising this if this is all OK and I simply missed something. Unfortunately, there is no example showing a case like mine - all existing ones convert types one-to-one.

@jfpoilpret
Copy link
Owner

Hello @slavdors
Thank you for your report on FastArduino.
The information you provide makes it difficult to understand your problem.
If you could post some sample code that exhibits the compilation issue, that would help me analyze what happens and determine if it is a bug and how to fix it.

@jfpoilpret jfpoilpret self-assigned this Feb 19, 2023
@jfpoilpret
Copy link
Owner

For the moment, I will classify your issue as a "Question" until I can get further input and reproduce the issue on my setup.

@jfpoilpret
Copy link
Owner

@slavdors it might also be useful to mention your avr-gcc version (and OS type and version), and any other information you deem useful for analysis.
Thank you

@slavdors
Copy link
Author

Thank you for getting back about the issue. I believe it is probably just my misunderstanding of the library, but may be useful to you to clarify it in the documentation.

As an example take your own implementation of the RTC clock in "devices\ds1307.h", where you defined your own "tm" structure (which layout is binary compatible with the registers on the device and can be transferred in one transaction). Then you have your GetDatetimeFuture and SetDatetimeFuture using this structure. Now, pretend that I want to write my get_datetime() and set_datetime() using ANOTHER structure holding the date and time. My understanding is that if you want to use one type for storing your data in your program and another type to communicate with the device, you would use the FUNCTOR to convert between the types. In you implementation of the DS1307 you do use the converters, but conveniently between the same type ("tm" to "tm") and that's why everything compiles.

To put it in other words: pretend you want to write your converters (FUNCTORs) in your DS1307 implementation: DatetimeConverterToDevice and DatetimeConverterFromDevice in the way that ARG_TYPE is still the "tm" structure, but RES_TYPE is a different type (let's say a different structure). It does not compile and that is the reason why I raised this ticket. I understand that such conversion should be possible - otherwise the FUNCTOR shouldn't have two distinct types defined: ARG_TYPE and RES_TYPE and the whole idea of converters would be questionable.
Currently, I cannot see any references to RES_TYPE in both ReadRegisterFuture and WriteRegisterFuture classes (in "i2c_device_utilities.h" file, lines 84 and 205) - only ARG_TYPE is used where probably lies the problem. It allows the converters to work, but only when ARG_TYPE is the same as RES_TYPE.

I hope that this clarifies a little bit what I meant originally.
Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants