Edrv and byte Order

[Stefan Enzinger]

hello!

I have troubles with the byte-order when sending statusResponse frames.
The machine is arm little endian with some RTOS.

What should happen to the buffer given to the edrv?
Must the buffer be byteswapped before sending?
Or does the oPL stack write everything to the buffer in the right format?

Currently I do byteswap the whole buffer before sending, this works fine for the first statusResponse (PreOperational1)

01 11 1e 00 00 04 00 21 83 00 12 34 88 ab 06 ff
01 02 08 00 1d 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

but the second one: (preOperational2) is kind of mixed up.

00 1e 11 01 83 00 00 21 83 00 12 34 88 ab 06 ff
00 08 08 19 5d 00 00 1d 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

any ideas?

[Wolfgang Wallner]

Hello Stefan,

I don't think the Edrv module should change the byte order.
The DLL takes care of these issues, as it uses the functions provided by the AMI-library (Abstract Memory Interface) to write byte-order dependent stuff.

--> Which AMI-library is linked into your project?

The directory EplStack contains the following three files:
amiiarm.c
amibe.c
amix86.c

As far as I can see only the destination MAC gets sent in the wrong order.
However, I do not understand why this could be the case.

The buffers for these frames get pre-allocated at startup.
At this time, they are already filled with constant information like the destination MAC. Have a look at function EplDllkCreateTxFrame() in dllk.c, this is where the buffers are allocated. For StatusResponse frame, the MAC address gets set like this:

AmiSetQword48ToBe(&pTxFrame->m_be_abDstMac[0], EPL_C_DLL_MULTICAST_ASND);

So as far as I can see this should be fine on any architecture (provided that the correct AMI-library is linked).

regards, Wolfgang

[Stefan Enzinger]

Thank you very much for this verbose and quick answer.

Knowing this, I figured out that my board reads the buffer in a byteswapped order. This is an errata for the board. (imx28)

So I need to do a manual swap before and after transmission.
This works so far, and I don't mind the slowdown right now.

Do you think I could use the "wrong" AMI-lib eventually to omit the double byteswap?

[Wolfgang Wallner]

This works so far, [...]

Good :)

Do you think I could use the "wrong" AMI-lib eventually to omit the double byteswap?

Might be. But as I do not know the details of the hardware-quirk of your platform I can't really answer this question.

regards, Wolfgang