Форум разработчиков электроники ELECTRONIX.ru

pfg

Apr 7 2008, 13:05

пишу полд ИАРом
Вот кусочек кода с дизасмеблером

unsigned char bb, cc, dd, ee;

ADC12MEM0 = 0x0456;
008130 40B2 0456 0140 mov.w #0x0456,&ADC12MEM0

bb = *((unsigned char*)0x140);
008136 42D2 0140 0200 mov.b &ADC12MEM0,&bb

cc = *((unsigned char*)0x141);
00813C 425C 0141 mov.b &0x141,R12
008140 4CC2 0201 mov.b R12,&cc

dd = ( (unsigned char*) & ADC12MEM0) [1];
008144 42D2 0141 0202 mov.b &0x141,&dd

ee = ( (unsigned char *) ADC12MEM0_) [1];
00814A 42D2 0141 0203 mov.b &0x141,&ee

В програмной эмуляции
происходит желаемое

в bb младший байт
в сс dd ee старший байт.

за пускаю на железе
во все (bb cc dd ee) пишет младший байт
Почему даже понять не могу

rezident

Apr 7 2008, 13:13

Цитата(pfg @ Apr 7 2008, 19:05)

во все (bb cc dd ee) пишет младший байт
Почему даже понять не могу

Потому что ADCMEMx это 16-разрядный регистр и работать с ним нужно именно как с 16-и разрядным словом или как с выровненной на границу 16-и разрядного слова (а не байта!) структурой, если так будет понятнее. Если хотите манипулировать со старшим байтом, то считайте все слово, сделайте сдвиг вправо на 8 бит и получите старший байт.

Код

dd=(unsigned char)(ADC12MEM0>>8);

msalov

Apr 7 2008, 13:31

Цитата(rezident @ Apr 7 2008, 16:13)

Потому что ADCMEMx это 16-разрядный регистр и работать с ним нужно именно как с 16-и разрядным словом или как с выровненной на границу 16-и разрядного слова (а не байта!) структурой

Разве эта ячейка памяти не такая же как все остальные? Ничего специфичного для этой ячейки памяти в User's Manual не увидел, возможно не там смотрел, подскажите где следует почитать.

rezident

Apr 7 2008, 14:00

В User's Manual есть таблица Table xxx.ADC12 Registers. Посмотрите, там приведен весь список и 16-и разрядных и 8-ми разрядных регистров ADC12. Адресуемых единиц по адресам 0x141, 0x143, 0x145 и т.п. физически нет в кристалле. Поэтому прямой байтовый доступ к ним просто невозможен. Если объяснять "на пальцах", то при доступе к 16-битной адресуемой единице на адрес как бы накладывается маска 0xFFFE и поэтому самый младший адресный бит в таком случае всегда имеет значение 0. Это называется неполная дешифрация. ИМХО сделана она для того, чтобы снизить до минимума вероятность неправильного считывания результата преобразования АЦП.

msalov

Apr 7 2008, 14:16

Цитата(rezident @ Apr 7 2008, 17:00)

В User's Manual есть таблица Table xxx.ADC12 Registers. Посмотрите, там приведен весь список и 16-и разрядных и 8-ми разрядных регистров ADC12. Адресуемых единиц по адресам 0x141, 0x143, 0x145 и т.п. физически нет в кристалле. Поэтому прямой байтовый доступ к ним просто невозможен. Если объяснять "на пальцах", то при доступе к 16-битной адресуемой единице на адрес как бы накладывается маска 0xFFFE и поэтому самый младший адресный бит в таком случае всегда имеет значение 0. Это называется неполная дешифрация. ИМХО сделана она для того, чтобы снизить до минимума вероятность неправильного считывания результата преобразования АЦП.

Спасибо

pfg

Apr 8 2008, 07:16

спсибо за разьяснение структуры, именно это и не укладывалось в башке.
правда указанный пример все равно не работает

ADC12MEM0 = 0x0956;
008120 40B2 0956 0140 mov.w #0x956,&ADC12MEM0

dd =(unsigned char)(ADC12MEM0);
008126 421E 0140 mov.w &ADC12MEM0,R14
00812A 4EC2 0204 mov.b R14,&dd

ee =(unsigned char)(ADC12MEM0>>8);
00812E 93C2 0140 tst.b &ADC12MEM0
008132 42D2 0141 0205 mov.b &0x141,&ee

опять пытаеться обратиться по "сдвинутому" адресу
сделал без извращений

aa = ADC12MEM0 ;
008138 4292 0140 0200 mov.w &ADC12MEM0,&aa

bb =(unsigned char)(aa);
00813E 42D2 0200 0202 mov.b &aa,&bb

cc =(unsigned char)(aa>>8);
008144 42D2 0201 0203 mov.b &0x201,&cc

Сергей Борщ

Apr 8 2008, 07:42

Цитата(pfg @ Apr 8 2008, 10:16)

спсибо за разьяснение структуры, именно это и не укладывалось в башке.

Вот из документации, на всякий случай:

Цитата

1.4.3 Peripheral Modules
Peripheral modules are mapped into the address space. The address space from 0100 to 01FFh is reserved for 16-bit peripheral modules. These modules should be accessed with word instructions. If byte instructions are used, only even addresses are permissible, and the high byte of the result is always 0.

Цитата(pfg @ Apr 8 2008, 10:16)

правда указанный пример все равно не работает

опять пытаеться обратиться по "сдвинутому" адресу
сделал без извращений

Это уже оптимизатор работает. Хм, а вот интересно - что надо будет делать, когда оптимизатор поумнеет настолько, что и второй ваш вариант соптимизирует до первого? Или я что-то недопонимаю, или компилятор не должен оптимизировать обращения к volatile-переменным. Надо будет почитать стандарт на эту тему.

P.S. для оформления кода в форме кода есть кнопочка с символом #