This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Data storage format

Hello,
I'm developing a DeviceNet application with Silicon Labs C8051F040, Keil compiler and a DeviceNet stack. The problem is the way that Keil stores var (16bit, 32 bit...). When I send data on the DeviceNet, the other devices get the inversion of my data.
For example, if i want to send 0x123456, the others Device, such as my computer, receive 0x563412.
Is there any way to solve this problem? Please don't tell me to convert the data into 8bit length because that is a very huge work (I'm using the DeviceNet stack of other company).
Thanks for reading this topic.

Parents
  • This is ridiculous, I posted and there was no evidence that my post had entered (using referesh) I posted AGAIN and there was no evidence that my post had entered (using referesh) I posted AGAIN and all 3 postings appeared.

    as it can be clearly seen, the postings "took" at the time I eneterd them

    in German: Diese website hat sehr ARM bekommen seit "Keil - An ARM Company."

    Erik

Reply
  • This is ridiculous, I posted and there was no evidence that my post had entered (using referesh) I posted AGAIN and there was no evidence that my post had entered (using referesh) I posted AGAIN and all 3 postings appeared.

    as it can be clearly seen, the postings "took" at the time I eneterd them

    in German: Diese website hat sehr ARM bekommen seit "Keil - An ARM Company."

    Erik

Children
  • Keil C51 stores multibyte integers in big-endian format. This is the most common network byte order (IP, Ethernet). It is, of course, reversed from the Intel 80x86 format, which means PCs.

    The PC has more horsepower, and is better equipped to do the byte-swapping. I'd be tempted to define the network byte order as big-endian, and let the PC deal with swapping bytes in the messages that it receives.

    If you want the source code to be portable between platforms, then you have to do as Andy says, and create a macro or function to do the byte swapping. For some platforms (like the PC), that function actually swaps bytes. For others (the 8051) the macro/function would do nothing.

  • Keil C51 stores multibyte integers in big-endian format. This is the most common network byte order (IP, Ethernet). It is, of course, reversed from the Intel 80x86 format, which means PCs.

    The PC has more horsepower, and is better equipped to do the byte-swapping. I'd be tempted to define the network byte order as big-endian, and let the PC deal with swapping bytes in the messages that it receives.

    If you want the source code to be portable between platforms, then you have to do as Andy says, and create a macro or function to do the byte swapping. For some platforms (like the PC), that function actually swaps bytes. For others (the 8051) the macro/function would do nothing.

  • Thanks for the suggestion.
    But the problem is I don't know the length of data that is transmitted over the DeviceNet.
    For example, I want to transmit 8 bytes on DeviceNet that includes 2 fields: first field has 2 bytes and the second one has 6 bytes. These fields are defined byte DeviceNet stack and they are produced automatically by the stack. So when I have 8 bytes data from the stack and transmit them over the DeviceNet, I don't know how many fields I have in the data and of course the length of these fields. So how can I make a conversion?

  • The sender and receiver have to know the message format to communicate at all. At the very least, it has to be parsable based on the early fields.

    If you know you have a 2-byte field, followed by a 6-byte field, then you can declare something like:

    typedef struct
         {
         U16 msgType;
         U8  MacAddr[6];
         }
         MyMessage;
    

    The receiver would byte-swap msgType, and perhaps swap MacAddr (or not, since it's not an integer). There would be perhaps lots of other structures, each one corresponding to a different msgType value.

  • "the problem is I don't know the length of data that is transmitted over the DeviceNet"

    As Drew says, that cannot possibly be true!
    A communications protocol cannot possibly work if you don't know (or cannot deduce) the length of the messages!

    "These fields are defined byte DeviceNet stack"

    There you go - that's where to look for your message size definitions!

    Is this a third-party (bought-in) stack?
    If it is, did it claim compatibility with an 8051 target & Keil tools?
    If it did, there will be configuration options somewhere that you need to set up - you will need to read the Manuals for both the stack & the tools.

    "I don't know how many fields I have in the data"

    Then you need to find out!
    This is fundamental - you obviously need to do a bit more reading on how DeviceNet and/or your stack works!

  • As Drew says, that cannot possibly be true!
    A communications protocol cannot possibly work if you don't know (or cannot deduce) the length of the messages!

    But every transmission has the data length different. And that length is base on what message the device want to send. So how can I make conversion for every different message?

  • This now has absolutely nothing to do with your original question, which was about the ordering of the bytes within 16-bit, 32-bit and larger variables.

    "So how can I make conversion for every different message?"

    Every protocol stack must have the ablity to build and decode every single message type defined by the protocol!

    You said your code was working before - just that the individual bytes within 16-bit, 32-bit and larger variables were in the wrong order.

    If your code was working before, then it must already have the means to build & decode messages - all you need to do is fix the parts where it takes individual bytes from larger variables - the rest of it must be OK!

  • "how can I make conversion for every different message?"

    Handling messages is what a protocol stack does!

    You didn't answer the question: are you writing this stack yourself, or have you purchased it from a supplier?

    If it's a purchased product, you need to contact the supplier's technical support for details of how to configure it to work with Keil tools.