<h4>Description</h4>
<p>I'm working on a 8kb EEPROM connected via I2C to a SAML21. I'm having strange wrap around issues on memory writing. After some debug my feeling is that the <code>i2c_write_regs</code> and <code>i2c_read_regs</code> functions do not take into account the endianess of the CPU and do work only with big endian code.</p>
<p>Example trying to write to register 0x10 the value 1:<br>
<code>   i2c_write_reg(I2C_DEV(0), 0x50, 0x10, 1, I2C_REG16);</code><br>
Putting some debug prints I see that the write request will generate an address on the bus:</p>
<pre><code>0x10
0x0
</code></pre>
<p>While I would expect the MSB to come first (by specs, but please correct me if I'm wrong as I'm not very used to I2C):</p>
<pre><code>0x0
0x10
</code></pre>
<p>Looking at <code>i2c_write_regs</code> the register is received as an <code>uint16_t</code> which is then passed down to <code>i2c_write_bytes</code> that gets it as <code>const void *</code> that is then written physicall in a loop as <code>const uint8_t *</code>.<br>
Therefore in little endian machines the LSB will come first, while for big endian machines MSB will come first (as it should).</p>
<p>I think the two regs function should take the endianess into account and always pass the registers data with MSB first to the underneath functions. I believe this should be the place to do it, so the calls to the CPU specific functions underneath already always receive the data as it should be written.</p>
<p>I would gladly do a PR once I get confirmation that I'm not seeing something wrong. Worst case I would suppose this should be documented if it is correct as it is.</p>
<p>Swapping beforehand the register data in my application seems to solve all the troubles.</p>
<h4>Steps to reproduce the issue</h4>
<p>Write some i2c registers using <code>i2c_write_regs</code> and see if the data gets written where it should.</p>
<h4>Versions</h4>
<p>RIOT master</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/RIOT-OS/RIOT/issues/11544?email_source=notifications&email_token=ABE7WYAJK5OG2LSWSYRJ6FDPWDX6FA5CNFSM4HN3Y33KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUSE45Q">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABE7WYFQMIXYFYELBN43PITPWDX6FANCNFSM4HN3Y33A">mute the thread</a>.<img src="https://github.com/notifications/beacon/ABE7WYBYKTV5NXNCZTFSOMLPWDX6FA5CNFSM4HN3Y33KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUSE45Q.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/RIOT-OS/RIOT/issues/11544?email_source=notifications\u0026email_token=ABE7WYAJK5OG2LSWSYRJ6FDPWDX6FA5CNFSM4HN3Y33KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUSE45Q",
"url": "https://github.com/RIOT-OS/RIOT/issues/11544?email_source=notifications\u0026email_token=ABE7WYAJK5OG2LSWSYRJ6FDPWDX6FA5CNFSM4HN3Y33KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUSE45Q",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>