Prev: C2C interface from TI
Next: ------->>>FREE MAC<<<-------
From: Oliver Betz on 17 Jul 2010 13:53
Hello All,

refactoring a system where data is exchanged and stored in a terse
binary format, I'm looking for abstraction methods.

The packets consist of length, version and a version dependent
sequence of byte and (two-byte) word values.

The legacy version uses a set of defines with offsets and type casts
to access the byte and word values directly in the raw byte array. Of
course this is limited to controllers with the same endianness
(currently that's true). Not pretty but fast.

I'm considering a table based copy to a working structure for the
faster hosts, but that's not possible in the resource (speed and
memory) limited 8 bit controller.

Besides this, it will be difficult to use the same structure
definition for both methods, and I would dislike somewhat to to keep
two representations in sync (manually or by an automatic converter).

Any thoughts?

Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
From: Thad Smith on 17 Jul 2010 17:02
Oliver Betz wrote:

> refactoring a system where data is exchanged and stored in a terse
> binary format, I'm looking for abstraction methods.
>
> The packets consist of length, version and a version dependent
> sequence of byte and (two-byte) word values.
>
> The legacy version uses a set of defines with offsets and type casts
> to access the byte and word values directly in the raw byte array. Of
> course this is limited to controllers with the same endianness
> (currently that's true). Not pretty but fast.

I suggest adding an explicit byte order to the message specification. The
processor can load or write the proper order. This can done, if you wish, in
portable code that works on either endian machine.

> I'm considering a table based copy to a working structure for the
> faster hosts, but that's not possible in the resource (speed and
> memory) limited 8 bit controller.

ASN.1 BER encoding is a reasonable standardized binary encoding technique. As
an option, you can formally specify the message in ASN.1.

> Besides this, it will be difficult to use the same structure
> definition for both methods, and I would dislike somewhat to to keep
> two representations in sync (manually or by an automatic converter).

I don't know what you mean there.


--
Thad
From: Oliver Betz on 21 Jul 2010 03:06
Thad Smith wrote:

>> refactoring a system where data is exchanged and stored in a terse
>> binary format, I'm looking for abstraction methods.
>>
>> The packets consist of length, version and a version dependent
>> sequence of byte and (two-byte) word values.
>>
>> The legacy version uses a set of defines with offsets and type casts
>> to access the byte and word values directly in the raw byte array. Of
>> course this is limited to controllers with the same endianness
>> (currently that's true). Not pretty but fast.
>
>I suggest adding an explicit byte order to the message specification. The

the byte order is specified.

>processor can load or write the proper order. This can done, if you wish, in
>portable code that works on either endian machine.
>
>> I'm considering a table based copy to a working structure for the
>> faster hosts, but that's not possible in the resource (speed and
>> memory) limited 8 bit controller.
>
>ASN.1 BER encoding is a reasonable standardized binary encoding technique. As
>an option, you can formally specify the message in ASN.1.
>
>> Besides this, it will be difficult to use the same structure
>> definition for both methods, and I would dislike somewhat to to keep
>> two representations in sync (manually or by an automatic converter).
>
>I don't know what you mean there.

I was not clear in my question. I was looking for maintainable C code
to abstract the access to message elements in the different targets.

These targets range from tiny and "slow" 8 bit controllers where I
need direct access to the elements up to 32 bit controllers with
plenty of computing power to use indirect methods to access the
message elements, e.g. a table.

Direct access could be a "struct" or a bunch of defines with offsets
and type casts. That's rather simple to maintain in code and works for
all targets if:
* the endianness is the same,
* the target supports misaligned access (if the message requires for).
And of course the "struct" method only works if the compiler (for the
larger processors) has extensions to control the packing.
So this method would result in some limitation on future targets.

Larger, faster targets have enough resources to convert the message to
and from a working structure using an abstract description of the
message. But I'm afraid that there is no maintainable solution to have
_one_ message description for the tiny and the abstract format, IOW I
hade to maintain different versions of the message
description/abstraction sources.

Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
 | 
Pages: 1
Prev: C2C interface from TI
Next: ------->>>FREE MAC<<<-------