Re: [PATCH 10/11] [RFC] rc-core: use the full 32 bits for NEC scancodes

[James Hogan <james.hogan@imgtec.com>]

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]

On 31/03/14 14:22, David Härdeman wrote:
> On 2014-03-31 12:56, James Hogan wrote:
>> This would mean that if the data is put in the right bit order (first
>> bit received in BIT(0), last bit received in BIT(31)), then the scancode
>> = raw, and if the data is received in the reverse bit order (like the
>> raw decoder, shifting the data left and inserting the last bit in
>> BIT(0)) then the scancode = bitrev32(raw).
>>
>> Have I missed something?
> 
> I just think we have to agree to disagree :)
> 
> For me, storing/presenting the scancode as 0xAAaaDDdd is "obviously" the
> clearest and least confusing interpretation. But I might have spent too
> long time using that notation in code and mentally to be able to find
> anything else intuitive :)
> 
> 0xAAaaDDdd means that you read/parse/print it left to right, just as you
> would if you drew a pulse-space chart showing the received IR pulse
> (time normally progresses to the right...modulo the per-byte bitrev).

Sure, but the NEC bit order is little endian, and the scancode is a
32bit value not an array of 4 bytes, so it's artificial to expect it to
make any sense when read as big endian. E.g. if you extended the
transmission to 48 bits you'd expect the hex printed scancode to extend
to the left not the right.

The bits in the 32-bit word also become discontinuous for no good
reason, especially considering the cases we're trying to take into
account (NEC-32 and NEC-24) both effectively have 16-bit fields.

> It kind of matches the other protocol scancodes as well (the "address"
> bits high, cmd bits low, the high bits tend to remain constant for one
> given remote, the low bits change, although it's not a hard rule) and it

Very true, but you still have the low byte of the command in the 2nd
lowest byte, which is why my original suggestion was:
0xaaAAddDD

I.e. swap 16bit halves, each 16bit field intact.

> matches most software I've ever seen (AFAIK, LIRC represents NEC32
> scancodes this way, as does e.g. the Pronto software and protocol).
> 
> That said...I think we at least agree that we need *a* representation
> and that it should be used consistently in all drivers, right?

Yes, that would be nice.

Cheers
James


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]