PDA

Просмотр полной версии : Проецирование структуры в буфер и наоборот



VaRela
28.02.2016, 16:57
Добрый день Уважаемые.
Опыта работы с 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
28.02.2016, 17:16
на первый взглфд вроде все верно, единственное лучше держать структуру однотипных данных

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

Хм, а почему?

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

Yegor
28.02.2016, 18:09
sizeof может не верно давать количествоВпервые слышу. Откуда информация?

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

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

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

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

Валенок
28.02.2016, 21:08
Ход мысли - правильный. Из помех на пути - невозможность обращения проца к слову по нечетному адресу
Т.к. 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
28.02.2016, 22:42
5лет назад писал архив для ПЛК 100.
Получилась достаточно большая структура.
Эту структуру упаковал в массив 60 строк.
Вся работа с архивом через символьную адресацию в
циклах For и выход из них через прерывание цикла exit.
только указателями я не использовал

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

Валенок
29.02.2016, 00:44
Мдя )) Не любит народ структурки. Тоже самое (практически) :

STRUCT x
_ : DWORD;
Нс,Mn : INT;
END_STRUCT


STRUCT Uchet_po_smenam
Den,Mesiac, God : WORD;
Dnevnaia,Nochnaia : array [1..5] of x;
Num : BYTE;
END_STRUCT


с указателями возможны периодические сбои.
Если это происходит на Новый год, то это нормально.
Ведь смена вероисповедания до добра не доводит ))

lara197a
29.02.2016, 09:52
......
Если это происходит на Новый год, то это нормально.
Ведь смена вероисповедания до добра не доводит ))

Ужене раз писал. что в далеком 2008г. на выставке у стенда КДС имел разговор
с И. Петровым. В частности разговор касался указателей и Петров крайне не рекомендовал их использовать.
Без них обойтись очень просто.
относительно объявления структуры и так понятно.
только там в дневной и ночной по 5 машин и при написании из массива в массив к структуре обращаясь,
голову свернешь. у меня нет феноменальной памяти, легко запутаться, т.к. усложняется запись переменных далее по ходу.

Валенок
29.02.2016, 10:06
lara197a ! Новый God ! )))

VaRela
29.02.2016, 19:21
Ход мысли - правильный. Из помех на пути - невозможность обращения проца к слову по нечетному адресу
Т.к. 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.


Я правильно понимаю, что МК не позволит мне прочитать/записать word/dword с нечетного адреса??? Это для меня откровение, честно говоря. :eek:



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


Мне в общем-то тип буфера не принципиален, в C/C++ я бы указал void*, а тут выбрал BYTE.



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 (местного аналога) для переноса абстрактных куч байтов

Вариант с копированием рассматривал, но это как-то неэкономично в плане ресурсов :-) Привык на атмеге экономить на всем.

Валенок
29.02.2016, 20:20
1,2
Да. Такая особенность. Но не напрягает если знать и соответственно ваять.

3
Ну и замечательно

4
Значит не подходит. А раз произвольно - то или 5 или 6

5
Принципиально. 5 это неявный 6, а 6 - побайтовый

6
По сравнению с атмегой - наверное здесь целая вселенная. Да и сэкономленное никому не нужно.