Проецирование структуры в буфер и наоборот

[VaRela]

Добрый день Уважаемые.
Опыта работы с CoDeSys очень мало, поэтому, возможно, вопрос ламерский, но в Гугле как-то не нашел...

Есть структура следующего типа:

TYPE TiceHeader:
STRUCT
  CRC       : WORD;
  Size      : WORD;
  Signature : BYTE;
END_STRUCT
END_TYPE
TYPE PiceHeader = POINTER TO TiceHeader;

Вот объявлен указатель на структуру этого типа:

HDR         : PiceHeader;

Ну или так:

HDR         : POINTER TO TiceHeader;

И есть байтовый массив:

DATA        : ARRAY[0..127] OF BYTE;

Смогу ли я проецировать указатель HDR на адрес массива? Вот так:

HDR := ADR(DATA);

Это позволило бы мне читать и писать данные внутри массива используя поля структуры

FOR I := 0 TO 5 DO
HDR := ADR(DATA) + I * SIZEOF(TiceHeader);
HDR.CRC := GetCRC16;
HDR.Size := 3;
HDR.Signature := I;
END_FOR

Заранее благодарю за ответ.

[capzap]

на первый взглфд вроде все верно, единственное лучше держать структуру однотипных данных

[VaRela]

на первый взгляд вроде все верно, единственное лучше держать структуру однотипных данных

Хм, а почему?

[capzap]

sizeof может не верно давать количество. Но если у Вас всё работает, то можно и не опасаться, единственное зачем Вы спрашивали тогда

[Yegor]

sizeof может не верно давать количество

Впервые слышу. Откуда информация?

[capzap]

Впервые слышу. Откуда информация?

если честно, по памяти помню разговоры, кто то убеждал меня что указатели на структуры не адекватны. Искать тему не стал, лень. Для надежности, вариант однотипной структуры ни кому не помешает

[VaRela]

Дело в том, что пока вынужден писать код вслепую без железа, поэтому оцениваю различные способы.
А на счет неверного sizeof для структуры, я так понимаю такое возможно, если компилятор выравнивает данные, например до слова или двойного слова.

[amn]

sizeof в симуляторе не выравнивает данные в структуре, а в живом ПЛК выравнивает кратно 4 байтам.

[Валенок]

Ход мысли - правильный. Из помех на пути - невозможность обращения проца к слову по нечетному адресу
Т.к. DATA байтовый, он может залечь легко и с нечетного адреса и при первом же HDR.CRC := получим ёк.
Гарантировать лежку DATA с четного адреса можно :

1.
Рукотворно после проверки и внедрения, при необходимости, например лишнего типа DATA :array[ -1...127] of byte


2.
Изначального расположения DATA в FB или в структуре с явными предварительными выравнивающими байтами типа
VAR_INPUT
d : dword;
b1,b2 : byte;
DATA : ..[0..127]
В общем развитие варианта 1.


3.
Отказа от базового типа DATA как байтового. А нафига байт-то сдался ?
DATA : array[0..63] of word;


4.
Вообще отказа от промежуточных буферов. А на фига буфера-то нужен ?
НDR : array[0..??] of TiceHeader; //это и есть буфер. Сюда/отсюда и пишем/читаем, и кузнец нам не нужен


5.
Простого необращения к полям структур в стремных местах
X : TiceHeader;

FOR I := 0 TO 5 DO
HDR := ADR(DATA) + I * SIZEOF(TiceHeader);
X.CRC := GetCRC16;
X.Size := 3;
X.Signature := I;
HDR^ := X; //тута нет обращений к полям
END_FOR


6.
Юзания функций типа SysMemCpy (местного аналога) для переноса абстрактных куч байтов

[lara197a]

5лет назад писал архив для ПЛК 100.
Получилась достаточно большая структура.
Эту структуру упаковал в массив 60 строк.
Вся работа с архивом через символьную адресацию в
циклах For и выход из них через прерывание цикла exit.
только указателями я не использовал

с указателями возможны периодические сбои.