Извлечение записи из данных с обратным порядком байтов

Взгляните на этот Сообщение AdaCore о порядке битов и порядке байтов, чтобы увидеть, как они с этим справляются. Прочитав это, вы, вероятно, обнаружите, что порядок битов значения вашего кадра действительно 16 # 08 #, что, вероятно, не то, что вы ожидаете.

Big Endian / Little Endian обычно относится к порядку байтов, а не к порядку битов, поэтому, когда вы видите, что сетевые протоколы имеют порядок байтов, они имеют в виду порядок байтов. Не устанавливайте Bit_Order для своих записей. В современных системах вам это почти никогда не понадобится.

Ваша запись имеет размер всего один байт, поэтому порядок байтов сам по себе не имеет значения. Порядок байтов вступает в игру, когда у вас есть большие значения поля (длиной> 8 бит).

Так,

    for Frame use
      record
         Transaction_Id at 0 range 0 .. 15;
         Protocol_Id at 2 range 0 .. 15;
         Frame_Length at 4 range 0 .. 15;
         Unit_id at 6 range 0 .. 7;
         Function_Code at 7 range 0 .. 6;
         Is_Exception at 7 range 7 .. 7;
      end record;

Кажется, вы хотите, чтобы Is_Exception был младшим битом последнего байта? С for Frame'Bit_Order use System.High_Order_First; LSB будет бит 7,

(также 16#32# никогда не будет -- Big endian version of 16#4#, просто битовый шаблон не совпадает)

Может быть более интуитивно и ясно указать все ваши поля относительно слова, в котором они находятся, а не байта:

         Unit_ID at 6 range 0..7;
         Function_Code at 6 range 8 .. 14;
         Is_Exception at 6 range 15 .. 15;

Учитывая приведенное выше определение Command, допустимые значения для последнего байта будут следующими:

• 2 -> READ_COILS ЛОЖЬ
• 3 -> READ_COILS ИСТИНА
• 8 -> READ_DISCRETE_INPUTS FALSE
• 9 -> READ_DISCRETE_INPUTS ИСТИНА

КСТАТИ, применив ваше обновление к вашей исходной программе и добавив/изменив следующее, ваша программа работает для меня

Добавить

    with Interfaces;

Добавить

    type Byte_Array is array(1..8) of Byte with Pack;

измениться, так как мы не знаем определения

    Transaction_ID : Interfaces.Unsigned_16;
    Protocol_ID : Interfaces.Unsigned_16; 
    Frame_Length : Interfaces.Unsigned_16;
    Unit_ID : Interfaces.Unsigned_8;

изменять

    function To_Frame is new Ada.Unchecked_Conversion (Byte_Array, Frame);

изменять

    my_frame := To_Frame (Byte_Array'(00, 01, 00, 00, 00, 09, 16#11#, 16#9#));

Ваше исходное объявление записи работает нормально (GNAT жалуется на Pack, warning: pragma Pack has no effect, no unplaced components). Проблема заключается в отработке прямого порядка байтов Byte.

---------------------------------
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |    BE bit numbers
---------------------------------
| c   c   c   c   c   c   c | e |
---------------------------------
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |    LE bit numbers
---------------------------------

поэтому, если вы хотите, чтобы Command был Read_Discrete_Inputs, в Byte должен быть установлен бит 4 BE (бит 3 LE), то есть LE 16#8#.

Я, наконец, нашел, что было не так.

Фактически, в Определение кадра Modbus Ethernet упоминается, что в случае исключения возвращаемый код должен быть кодом функции плюс 128 (0x80) (см. объяснение в Википедии). Вот почему я хотел представить это через значение логический, но мои предложения представления были неправильными.

Правильные предложения следующие:

   for Frame use
      record
         Transaction_Id at 0 range 0 .. 15;
         Protocol_Id at 2 range 0 .. 15;
         Frame_Length at 4 range 0 .. 15;
         Unit_id at 6 range 0 .. 7;
         Is_Exception at 6 range 8 .. 8;
         Function_Code at 6 range 9 .. 15;
      end record;

Таким образом, сетевой протокол Modbus моделируется правильно (или нет, но, по крайней мере, мой код работает).

Я очень благодарен эгилхх и Саймонрайт за то, что они помогли мне найти ошибку и объяснить семантику аспектов.

Очевидно, я не знаю, кто награждает :)

Прагма bit_order не меняет порядок расположения битов в памяти. Он просто определяет, будет ли старший значащий бит (самый левый) логически называться нулем (High_Order_First) или младший значащий бит будет называться нулем (Low_Order_First) при интерпретации смещений First_Bit и Last_Bit относительно позиции байта в представлении. пункт. Имейте в виду, что эти смещения берутся из MSB или LSB скаляра, компонент записи принадлежит КАК ЗНАЧЕНИЕ. Таким образом, для того, чтобы позиции байтов имели то же значение на ЦП с прямым порядком байтов, что и на ЦП с обратным порядком байтов (а также представление в памяти многобайтовых машинных скаляров, которые существуют, когда один или несколько компонентов записи с одним и тем же байтом position имеют значение last_bit, превышающее емкость одного байта), то для Scalar_Storage_Order необходимо указать также.