Linux IIO development
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Peter Meerwald <pmeerw@pmeerw.net>, Crt Mori <cmo@melexis.com>
Cc: linux-iio@vger.kernel.org
Subject: Re: Spliting u16, u32 to u8 array
Date: Thu, 06 Aug 2015 13:00:07 +0200	[thread overview]
Message-ID: <55C33E37.8050707@metafoo.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1508061229430.24774@pmeerw.net>

On 08/06/2015 12:42 PM, Peter Meerwald wrote:
> Hello,
> 
>> I am sure at least some of you were faced to split a u16 or u32 value
>> in u8 array without being affected by host endianness. My search
>> turned empty for a standardized function for this task, but this seems
>> quite improbable. My task is to send 16 bit LE data through i2c.
>>
>> I am looking for something like:
>> static void u16_to_u8_array(u16 value, u8 *array)
>> {
>>         *array = cpu_to_le16(value) >> 8;
>>         *(++array) = (u8) cpu_to_le16(value);
>> }
> 
> how about
> 
> static void u16_to_le16_array(u16 value, __le16 *array)
> {
> 	*array++ = cpu_to_le16(value);
> }
> 
> and calling it with a cast if need be, such as
> 
> char *u8array;
> u16_to_le16_array(123, (__le16 *) u8array)
> 
> an issue could be alignment of the u8array

There is put_unaligned_le16() and friends for this situation where the
target buffer is just a generic bytestream. This is architecture optimized,
so if the architecture supports unaligned access it will just do a store, if
it doesn't it will split the operation into multiple stores.

> 
> I'd try to avoid u8 altogether and work with le16 as a datatype

That seems to be the best solution in this case.

  reply	other threads:[~2015-08-06 11:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06  9:39 Spliting u16, u32 to u8 array Crt Mori
2015-08-06 10:42 ` Peter Meerwald
2015-08-06 11:00   ` Lars-Peter Clausen [this message]
2015-08-06 11:35     ` Crt Mori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55C33E37.8050707@metafoo.de \
    --to=lars@metafoo.de \
    --cc=cmo@melexis.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox