Hi All,
Вот такой код volatile struct Msg { long a; long b; long c; long d; unsigned char Buf[40]; } MsgOut; ....
*((short int *)&MsgOut.Buf[4+16]) = 0x7ff7; *((int *) &MsgOut.Buf[4+18]) = 0x87654321; упорно записывает 0x87654321 по смещению 20.И как это побороть ? #pragma pack(1) нарисовать ? А куда ? Я разве что не "на бумажке печатал и насквозь смотрел"
SY, EK
pack(1) и bytealign вписать в опции компилятора "Misc Controls". Можно для всего проекта или только для данного файла, смотря как надо.
Wed Mar 29 2006 17:20, Myasoedov Andrey wrote to Evgeny Kotsuba:
MA> From: "Myasoedov Andrey" snipped-for-privacy@vgts.ru
MA> pack(1) и bytealign вписать в опции компилятора "Misc Controls". Можно MA> для всего проекта или только для данного файла, смотря как надо.
литовский национальный прадник в индейском национальном жилище.
#pragma bytealign встречается только в хелпе, во всех остальных местах на bytealign ругается.. >> >> Вот такой код >> volatile struct Msg { >> long a; >> long b; >> long c; >> long d; >> unsigned char Buf[40]; >> } MsgOut; >> .... >> *((short int *)&MsgOut.Buf[4+16]) = 0x7ff7; >> *((int *) &MsgOut.Buf[4+18]) = 0x87654321; >> упорно записывает 0x87654321 по смещению 20. >> >> И как это побороть ? нарисовать ? А куда ? Я разве что не "на >И как это побороть ? #pragma pack(1) нарисовать ? А куда ? Я разве что не ^^^^^^^^^^^^^^^^^^^^^^^^ вот это я для кого писал ??
SY, EK
Версия Кейла какая? У меня Кейл С166 V6.02, все работает. В опциях проекта выбираем С166, в Misc Controls пишем BYTEALIGN PACK(1). Все работает. Кстати, рекомендуется указывать оба ключа - и BYTEALIGN и PACK(1).
Thu Mar 30 2006 09:33, Myasoedov Andrey wrote to Evgeny Kotsuba:
MA> From: "Myasoedov Andrey" snipped-for-privacy@vgts.ru
MA> Версия Кейла какая? У меня Кейл С166 V6.02, все работает. В опциях MA> проекта выбираем С166, в Misc Controls пишем BYTEALIGN PACK(1). Все MA> работает. MA> Кстати, рекомендуется указывать оба ключа - и BYTEALIGN и PACK(1).
Может этих Кейлов много ? :-/
mVision3 V3.21 C Compiler CA.Exe V2.40a Assembler AA.Exe V2.40a
Target процессор - Phillips LPC21xx
SY, EK
Да вроде свежий...
Дык кто и на что ругается-то? Бывает, ругается линкер, если разные файлы, использующие одну и ту же переменную, скомпилированы один с ключами, другой без (Different data types, говорит).
Thu Mar 30 2006 15:51, Myasoedov Andrey wrote to Evgeny Kotsuba:
MA> From: "Myasoedov Andrey" snipped-for-privacy@vgts.ru
MA> Да вроде свежий...
MA> Дык кто и на что ругается-то? Бывает, ругается линкер, если разные файлы, MA> использующие одну и ту же переменную, скомпилированы один с ключами, MA> другой без (Different data types, говорит).
варант 1:
#pragma bytealign
TST.C(9): warning C2: 'BYTEALIGN': unknown #pragma/control, line ignored
вариант 2:
ARM COMPILER V2.40a - SN: Eval Version COPYRIGHT KEIL ELEKTRONIK GmbH 2003 - 2005 CARM FATAL-ERROR - ACTION: PARSING INVOKE-/#PRAGMA-LINE LINE: C:\Keil\ARM\BIN\CA.exe upr_net.c ARM WARNINGLEVEL(3) OPTIMIZE(8,SPEED) BROWSE BYTEALIGN ERROR: UNKNOWN CONTROL CARM TERMINATED. Target not created MA> -- MA> С уважением MA> Мясоедов Андрей
MA> на
Насколько тут писали, Keil для ARM - умело прикрученный GCC. Видимо именно в районе GCC надо искать описание правильного написания #pragma pack() вот это не поможет?
Не надо без острой на то нужды использовать упакованные структуры. Ибо там граблей разложено, больше чем битов в ней умещается. НЕ надо хакерскими методами приводить типы -- для этого есть union. Размерность типа int -- 16 бит. Нужна конкретная размерность -- используй int32_t, например, и другие типы для этого предназначенные. Не уверен что влезет в 16 бит -- используй long.
18+4 == 22. А sizeof(char) точно >= 1. Такого быть не может.Если формат пофиг -- оставить как есть. Если не пофиг -- писать сериализатор этой структуры в упакованный вид.
В GCC -- читать info до просветления. Там много познавательного и интересного. В частности, атрибуты.
Sat Apr 01 2006 03:05, Kirill Frolov wrote to Evgeny Kotsuba:
KF> From: Kirill Frolov snipped-for-privacy@fk0.pp.ru>
KF> >> Вот такой код
KF> Hе надо без острой на то нужды использовать упакованные структуры. KF> Ибо там граблей разложено, больше чем битов в ней умещается. KF> HЕ надо хакерскими методами приводить типы -- для этого есть union. KF> Размерность типа int -- 16 бит. Hужна конкретная размерность -- KF> используй int32_t, например, и другие типы для этого предназначенные. KF> Hе уверен что влезет в 16 бит -- используй long.
KF> 18+4 == 22. А sizeof(char) точно >= 1. KF> Такого быть не может.
KF> Если формат пофиг -- оставить как есть. Если не пофиг -- писать KF> сериализатор этой структуры в упакованный вид.
Я ж указывал процессор. оно 32 битное. И sizeof(int) = 4, а sizeof(char) = 1, т.е. все как у взрослых ;-)
И запись вида *((int *) &MsgOut.Buf[4+18]) = 0x87654321; у взрослых никаким хакерством не считается. KF> HЕ надо хакерскими методами приводить типы -- для этого есть union. union - не метод приведения типа, если _так_ типы приводить, то неудивительно что потом начинаются стоны про грабли.
Короче, постановлено что в части #pragma pack() keil глюкав, как минимум для
32 битных процов и "все выравнивать на 4 байта".SY, EK
ЗЫ: Кстати, никто не может сказать, почему у них на сайте мю-вижен относится уже к чему-то древнему, и толкается нечто новое ?
sizeof(int) в среднем где-то равен трём. Чему он равен на конкретном процессоре не имеет никакого значения. Нужны 32-битные числа -- используй int32_t.
Взрослые используют в таком случае union.
union -- это метод НЕ ИСПОЛЬЗОВАТЬ приведение типов. Потому как оно небезопасно и глючно.
Если, как тут пишут, keil -- это gcc, то тогда никакой pragma pack на него и не должен действовать. Пиши struct tag {} __attribute__((packed));
Привет Evgeny.
29 мар 06 14:43, Evgeny Kotsuba -> All:EK> Вот такой код EK> volatile struct Msg { EK> long a; EK> long b; EK> long c; EK> long d; EK> unsigned char Buf[40]; EK> } MsgOut; EK> .... EK> *((short int *)&MsgOut.Buf[4+16]) = 0x7ff7; EK> *((int *) &MsgOut.Buf[4+18]) = 0x87654321; EK> упорно записывает 0x87654321 по смещению 20.
EK> И как это побороть ? #pragma pack(1) нарисовать ? А куда ? Я разве что EK> не "на бумажке печатал и насквозь смотрел"
Проверил твой пример в RVMDK v3.00a взяв за основу их пример Hello. Используемый компилятор CARM.
...
int main(void) { /* execution starts here */
#pragma pack(1) /* byte alignment */ volatile struct { long a; long b; long c; long d; unsigned char Buf[40]; } MsgOut; #pragma pack() /* reset to default alignment */
/* initialize the serial interface */ PINSEL0 = 0x00050000; /* Enable RxD1 and TxD1
*/ U1LCR = 0x83; /* 8 bits, no Parity, 1 Stop bit */ U1DLL = 97; /* 9600 Baud Rate @ 15MHz VPB Clock */ U1LCR = 0x03; /* DLAB = 0 */printf("%p, %p, %p\n", MsgOut.Buf, &MsgOut.Buf[4+16], &MsgOut.Buf[4+18]);
*((short int*)&MsgOut.Buf[4+16]) = 0x7ff7; *((int*)&MsgOut.Buf[4+18]) = 0x87654321;for(;;); }
Результаты по симуляции: Окно Serial #2: 400003d4, 400003e8, 400003ea
Окно Memory #1, дамп памяти: 0x400003D4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x400003E3: 00 00 00 00 00 F7 7F 21 43 65 87 00 00 00 00
Так что с выравниванием в CARM'е все в порядке. CA v2.51a, LA v2.51a .
2All: GCC в кейловском пакете давно уже нет, хотя настройки под него и остались, в текущей поставке идут родные и ARM тулзы.Kosty K.
Sat Apr 01 2006 16:47, Konstantin Konstantinov wrote to Evgeny Kotsuba:
KK> Так что с выравниванием в CARM'е все в порядке. CA v2.51a, LA v2.51a .
так где взять ? (У меня - 2.40) Или оно все-таки сильно от камня зависит ?
SY, EK
Привет Evgeny.
01 апр 06 17:26, Evgeny Kotsuba -> Konstantin Konstantinov:KK>> Так что с выравниванием в CARM'е все в порядке. CA v2.51a, LA KK>> v2.51a .
EK> так где взять ? (У меня - 2.40) Или оно все-таки сильно от камня EK> зависит ?
Их пример под серию LPC21xx заточен, как у тебя.
Где скачать. Если есть доступ на ftp электроникса, то туда VAI уже выложил. Если доступа нет, могу предложить следующий вариант. Я выкладываю torrent на полную версию RVMDK v3.00a на трэкер
Kosty K.
Sat Apr 01 2006 15:39, Kirill Frolov wrote to Evgeny Kotsuba:
KF> From: Kirill Frolov snipped-for-privacy@fk0.pp.ru>
KF> >> KF> Если формат пофиг -- оставить как есть. Если не пофиг -- писать >> KF> сериализатор этой структуры в упакованный вид. >> Я ж указывал процессор. оно 32 битное. И sizeof(int) = 4, а sizeof(char) = >> 1, т.е. все как у взрослых ;-)
KF> sizeof(int) в среднем где-то равен трём. ;-))))))))))))))))))))) KF>Чему он равен на конкретном KF> процессоре не имеет никакого значения. Hужны 32-битные числа -- KF> используй int32_t.
эт позволь мне самому решать - включать лишние инклюды или ну его нафиг.
KF> Взрослые используют в таком случае union. расскажи об этом взрослым; особенно при записи в буфер произвольных данных
KF> union -- это метод HЕ ИСПОЛЬЗОВАТЬ приведение типов. Потому как оно KF> небезопасно и глючно. расскажи это всем разработчикам юниксов или программерам интеля
KF> Если, как тут пишут, keil -- это gcc, то тогда никакой pragma pack на KF> него и не должен действовать. Пиши struct tag {} __attribute__((packed));
на заборе тоже пишут, и что из этого ?
SY, EK
Sat Apr 01 2006 18:41, Konstantin Konstantinov wrote to Evgeny Kotsuba:
KK> Привет Evgeny.
KK> 01 апр 06 17:26, Evgeny Kotsuba -> Konstantin Konstantinov:
KK>>> Так что с выравниванием в CARM'е все в порядке. CA v2.51a, LA KK>>> v2.51a .
EK>> так где взять ? (У меня - 2.40) Или оно все-таки сильно от камня EK>> зависит ?
KK> Их пример под серию LPC21xx заточен, как у тебя.
KK> Где скачать. Если есть доступ на ftp электроникса, то туда VAI уже KK> выложил. Если доступа нет, могу предложить следующий вариант. Я KK> выкладываю torrent на полную версию RVMDK v3.00a на трэкер KK>
ахренеть. я неделю назад вроде последнее скачивал - оно было 2.50a с датой от
03.02.06 Во ребята работают! А eval-версия лечится ?SY, EK
Привет Evgeny.
01 апр 06 20:21, Evgeny Kotsuba -> Konstantin Konstantinov: [...skipped...]EK> ахренеть. я неделю назад вроде последнее скачивал - оно было 2.50a с EK> датой от 03.02.06 Во ребята работают! А eval-версия лечится ?
Hе знаю, не было случая проверить.
Kosty K.
Sat Apr 01 2006 22:54, Kirill Frolov wrote to Evgeny Kotsuba:
KF> Юниксы вполне успешно на достаточно разных архитектурах работали. KF> Что вряд ли было бы возможным при описываемом подходе.
Возьми навскидку любой исходник и посмотри, а потом спорь о вкусе булочек с тем, кто ими питается.
SY, EK
Беру и записываю. Поскольку между записями архитектура и опции компилятора не изменятся -- на выравнивание плюю. Типиный пример использования union очень хорошо в lex виден.
Юниксы вполне успешно на достаточно разных архитектурах работали. Что вряд ли было бы возможным при описываемом подходе.
Не читай.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.