Skip to content

proposal for I2C master/slave example #5360

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

Closed
wants to merge 21 commits into from

Conversation

suculent
Copy link
Contributor

Please comment code style and propose way to share code. Yes, there are duplicities. However, this is example where code-bases for master and slave will be always expectably different and because Arduino IDE does not allow two sketches in one folder, only way would be to create a library or use CRC16 from core (if any) to share code in the example.

Copy link
Collaborator

@devyte devyte left a comment

Choose a reason for hiding this comment

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

This brought back memories from when I implemented a modbus exchange.
Overall, so good that I may shamelessly steal some of it for my own app, although I don't use I2C 😜

uint16_t _xorIn;
uint16_t _xorOut;
uint16_t _polynomial;
uint8_t _reflectIn;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess these are uint8_t instead of bool for size? It's ok to do that, but at the very least the interface args should be bool type.

_mask = 0xFFFF;
_crc = _xorIn;
}
inline Crc16(uint8_t reflectIn, uint8_t reflectOut, uint16_t polynomial, uint16_t xorIn, uint16_t xorOut, uint16_t msbMask, uint16_t mask)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I suggest the args reflectIn/Out be bool type

inline void clearCrc();
inline void updateCrc(uint8_t data);
inline uint16_t getCrc();
inline unsigned int fastCrc(uint8_t data[], uint8_t start, uint16_t length, uint8_t reflectIn, uint8_t reflectOut, uint16_t polynomial, uint16_t xorIn, uint16_t xorOut, uint16_t msbMask, uint16_t mask);
Copy link
Collaborator

Choose a reason for hiding this comment

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

reflect => bool type

inline void updateCrc(uint8_t data);
inline uint16_t getCrc();
inline unsigned int fastCrc(uint8_t data[], uint8_t start, uint16_t length, uint8_t reflectIn, uint8_t reflectOut, uint16_t polynomial, uint16_t xorIn, uint16_t xorOut, uint16_t msbMask, uint16_t mask);
inline unsigned int XModemCrc(uint8_t data[], uint8_t start, uint16_t length)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I suggest changing the signature to:

template <std::size_t dataSize>
unsigned int XModemCrc(const uint8_t (data&)[dataSize], const uint8_t start)

This assures that the dataSize value always corresponds to the size of the array passed in as an arg.
Also, the user has one less arg to pass into the function.
And, because it's a 1-line forwarder, it gets optimized away.

However, this works only for arrays of predetermined size, and not for dynamically allocated arrays. In this last case, the function signature to use should be:

inline unsigned int XModemCrc(const uint8_t *data, const uint8_t start, const uint16_t length)

Of course, both can coexist as overloads.

@@ -0,0 +1,209 @@
//-------------------------------------------------------------------------------------
Copy link
Collaborator

Choose a reason for hiding this comment

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

I know this is not your code, but I thought to add some suggestions anyways. It's ok to ignore them 😛
Globally, consider adding const-ness to all relevant args.

}
Serial.print(address, HEX);
Serial.println(" !");
nDevices++;
Copy link
Collaborator

Choose a reason for hiding this comment

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

++nDevices

Serial.println(datasize);

// Generate new data set for the struct
for (size_t i = 0; i < datasize; i++) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

++i


}

void receiveEvent(int howMany) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

const.size_t howMany

bool requestRetransfer = false;

unsigned long rtimeout = millis() + 200; // skip 100ms timeouts
while (millis() < rtimeout) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Rollover issue

Copy link
Contributor Author

@suculent suculent Nov 24, 2018

Choose a reason for hiding this comment

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

How would you solve this without getting involved in something complex? It's not that important, it might be removed instead.
I do understand, that the rtimeout can become a less than millis almost forever in certain moment. However it should take just another 200 millis until it will get unstuck, as real millis will reset back to zero soon as well.

Copy link
Contributor

@JiriBilek JiriBilek Nov 24, 2018

Choose a reason for hiding this comment

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

I think you should subtract current millis from the original value:

  unsigned long rtimeout = millis();
  while (millis() - rtimeout < 200) {

} // if 0

digitalWrite(LED_PIN, HIGH);
index++;
Copy link
Collaborator

Choose a reason for hiding this comment

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

++index

@devyte
Copy link
Collaborator

devyte commented Nov 23, 2018

Fixes #5288

@suculent
Copy link
Contributor Author

suculent commented Nov 24, 2018 via email

@devyte
Copy link
Collaborator

devyte commented Dec 12, 2018

Closing in favor of #5464 .

@devyte devyte closed this Dec 12, 2018
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.

3 participants