|
Битовые поля - есть ли способ поменять Little Endian на Big Endian, расположение битов |
|
|
|
May 30 2009, 22:21
|

Любитель
    
Группа: Свой
Сообщений: 1 864
Регистрация: 20-08-06
Из: Тольятти
Пользователь №: 19 695

|
Осваиваю тут карты памяти, и возникла нужда поработать со структурами их регистров. К примеру: Код __packed struct CID { byte man_ID: 8; byte oem_ID[2]; byte product_name[5]; byte revision: 8; dword serial: 32; unsigned : 4; word man_date: 12; unsigned crc: 7; unsigned dummy: 1; }; Вроде бы всё хорошо, да только данные в такой структуре должны идти линейно сверху вниз - байт 0 - биты 31...24, байт 1 - биты 23...16 и т.д. (big endian). А компилятор (RealView) считает наоборот - сначала младшие биты (little endian). То есть читаем слово revision, в регистре должны быть данные вида 0x08070605 [31...0], а на деле имеем 0x05060708... Есть ли способ побороть такую досадную "однобокость"? Иначе придётся ручками обрабатывать все битовые сдвиги и маски...
|
|
|
|
|
May 31 2009, 06:55
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(sonycman @ May 31 2009, 01:21)  А компилятор (RealView) считает..... Он 'считает', причем совершено обосновано, что у контроллера именно такая адресация. Причем, полагаю, Вам не скоро придется встретиться с big endian (они вообще померли, ну кроме одного легендарного и считающегося вечно живым динозавра  ), ибо для всего, что не является машинным словом получается чистой воды издевательтство ). И уж тем более не встретитесь с компилятором работающим 'наоборот' от архитектуры контроллера. Посему препешите структуру, "как положено", а не так, как кажется "правильным" в данный момент времени глядя с конкретной колоколенки и все. Цитата(sergeeff @ May 31 2009, 02:59)  Это одна их проблем переносимости программ. Практически этой проблемы уже нет.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
May 31 2009, 07:54
|

Частый гость
 
Группа: Участник
Сообщений: 98
Регистрация: 3-03-09
Пользователь №: 45 590

|
Цитата(sonycman @ May 31 2009, 01:21)  ... Вроде бы всё хорошо, да только данные в такой структуре должны идти линейно сверху вниз - байт 0 - биты 31...24, байт 1 - биты 23...16 и т.д. (big endian). А компилятор (RealView) считает наоборот - сначала младшие биты (little endian). Используйте преобразование типов и всё. Пусть они лежать как лежат.
|
|
|
|
|
May 31 2009, 08:18
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(sonycman @ May 31 2009, 10:51)  Тут нужно или "переворачивать" все поля вручную, по мере приёма от карты, или обрабатывать такую структуру ручками... Нафига, простите, ПРОСТО опишите стуктуру "правильно" - битовыми полями и байтами уже проблем не будет. Останется разворачивать то, что short и long, там где встречаются. Их через htons/htonl/...... В случае чего и опортируете без особых проблем
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
May 31 2009, 08:23
|

Любитель
    
Группа: Свой
Сообщений: 1 864
Регистрация: 20-08-06
Из: Тольятти
Пользователь №: 19 695

|
Цитата(zltigo @ May 31 2009, 12:18)  Нафига, простите, ПРОСТО опишите стуктуру "правильно" - битовыми полями и байтами уже проблем не будет. Останется разворачивать то, что short и long, там где встречаются. Их через htons/htonl/...... В случае чего и опортируете без особых проблем  А как правильно? Вот другая структура: Код __packed struct CSDv1 { unsigned ver: 2; unsigned : 6; unsigned TAAC: 8; unsigned NSAC: 8; unsigned tran_speed: 8; unsigned ccc: 12; unsigned read_bl_len: 4; unsigned read_bl_part: 1; unsigned write_bl_misal: 1; unsigned read_bl_misal: 1; unsigned dsr_imp: 1; unsigned : 2; unsigned c_size: 12; unsigned vdd_r_curr_min: 3; unsigned vdd_r_curr_max: 3; unsigned vdd_w_curr_min: 3; unsigned vdd_w_curr_max: 3; unsigned c_size_mult: 3; unsigned erase_bl_en: 1; unsigned sector_size: 7; unsigned wp_grp_size: 7; unsigned wp_grp_enable: 1; unsigned : 2; unsigned r2w_factor: 3; unsigned write_bl_len: 4; unsigned write_bl_part: 1; unsigned : 5; unsigned file_form_grp: 1; unsigned copy: 1; unsigned perm_wr_prot: 1; unsigned tmp_wr_prot: 1; unsigned file_format: 2; unsigned : 2; unsigned crc: 7; unsigned dummy: 1; }; Проблемы с полями точно такие-же: 12 битное поле c_size воспринимается наоборот...
|
|
|
|
|
May 31 2009, 08:25
|

Гуру
     
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095

|
Цитата(zltigo @ May 31 2009, 09:55)  (они вообще померли, ну кроме одного легендарного и считающегося вечно живым динозавра  ), "Огласите весь список, пожалуйста" (с). В смысле, кто остался. Согласно википедии, большие индейцы (из более-менее популярных) у PowerPC, SPARK. Самсунговские ARMы S3Cxxxx, заточенные на коммуникации, работают в больших индейцах. Цитата(zltigo @ May 31 2009, 09:55)  Практически этой проблемы уже нет. "Как же так? Ж... - есть, а слова - нет?"  Сетевые протоколы используют больших индейцев, и с этим тяжелым наследием приходится бороться на остальных процессорах.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
May 31 2009, 08:31
|

Гуру
     
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095

|
Цитата(sonycman @ May 31 2009, 11:19)  Они меняют порядок следования битов? Это подколка такая? Ссылку на описание прикрепил ведь. "to and from the network byte order". О порядке битов речь не шла. Порядок битов надо (если надо) менять в точке приема.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
May 31 2009, 08:34
|

Любитель
    
Группа: Свой
Сообщений: 1 864
Регистрация: 20-08-06
Из: Тольятти
Пользователь №: 19 695

|
Цитата(zltigo @ May 31 2009, 12:29)  Ужас. Код #define htons_ptr(p) *(p) = (*(p) << 8) | (*(p) >> 8)) #define ntohs( sh ) ( (unsigned short)(( (sh)>>8 )|( (sh)<<8 )) ) #define htons( sh ) ntohs( (sh) ) Спасибо. Цитата(Сергей Борщ @ May 31 2009, 12:31)  Это подколка такая? Ссылку на описание прикрепил ведь. "to and from the network byte order". О порядке битов речь не шла. Порядок битов надо (если надо) менять в точке приема. Да я там с наскоку не понял ничего. Какие то network и host byte order мне ничего не говорят. Теперь знаю! Спасибо!
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|