Две переменные
D:0006H SYMBOL old
X:7800H SYMBOL n_char
D:0004H SYMBOL vv_dat

загнаны в регистры. Почему? Во Franklin'е такого замечено не было. Как избавиться от этого?

После выполнения ф-ции atoi() получаем ерунду. Видимо эти р-ры в ф-ции тоже используются.

А почему нет?
Что запрещает разместить эти локальные переменные в регистрах?
И в чем глубокий смысл этого "=" :

return (vv_dat=atoi(IN_ASCII_BUFF_L));


нет причина в чем-то другом. Размещение этих переменных (old, vv_dat) никак не могут сказываться на результате atoi.

[quote name='defunct' date='May 6 2008, 06:36' post='406878']
А почему нет?
Что запрещает разместить эти локальные переменные в регистрах?
И в чем глубокий смысл этого "=" :

return (vv_dat=atoi(IN_ASCII_BUFF_L));
[/quote]
"Тайного смысла" здесь нет. Раньше vv_dat вычислялось в теле п/п. Потом пошли изменения. при отладке поставил так, вот оно и осталось. Согласен, уберу "vv_dat=".

нет причина в чем-то другом. Размещение этих переменных (old, vv_dat) никак не могут сказываться на результате itoa.
[/quote]
Да, причина не в них. Я заменил локальную переменную глобальной и получил тоже самое:
Vent_revers=0xC355 после выполнения atoi().
А как в отладчике посмотреть память DATA, IDATA?

View -> Memory window
В окне Memory указать адрес со спецификатором памяти
B Bit–addressable RAM memory (BIT)
C Code memory (CODE)
D Internal directly-addressable RAM memory of the 8051 (DATA)
I Internal indirectly-addressable RAM memory of the 8051 (IDATA)
X External RAM memory (XDATA)

1- Согласно дркументации Keil использует для передачи параметров и локальных переменных регистры текущего банка. Так что криминала нет.
2 - Проблема может быть в том что не закрыта строка (нет 0 в конце буфера IN_ASCII_BUFF_L).
3 - Keil иногда оптимизирует такие конструкции ( return (vv_dat=atoi(IN_ASCII_BUFF_L)); ), поэтому результат нужно смотреть не в переменной vv_dat а в регистре R7 (через него функция возвращает значение)

После командировки снова возвратился к Keil.
Конструкцию return (vv_dat=...) заменил на return (atoi(IN_ASCII_L)). Но результата это не дало. А вот закрытие строки помогло. И сейчас ввод работает нормально. Буду проверять остальное.
Но вот что интересно.
Bin_To_ASCII(old);
IN_ASCII_BUFF[0]=Rab.symv5.old_value[0];
IN_ASCII_BUFF[1]=Rab.symv5.old_value[1];
...
return (atoi(IN_ASCII_BUFF));

Работает без закрытия строки. А вот такая конструкция:
Bin_To_ASCII(old);
IN_ASCII_BUFF_L[0]=Rab.symv4[0];
IN_ASCII_BUFF_L[1]=Rab.symv4[1];
IN_ASCII_BUFF_L[2]=Rab.symv4[2];
IN_ASCII_BUFF_L[3]=Rab.symv4[3];
IN_ASCII_BUFF_L[4]='\0';
...
return (atoi(IN_ASCII_BUFF_L));

работает только с завершающим нулем.
Хотелось бы докопаться до сути, что-бы не наступать на эти "грабли" в будущем.

Вполне может быть, что в массиве IN_ASCII_BUFF нулевой байт случайно оказался на нужном месте (например, массив инициируется нулями при старте программы); а в массиве IN_ASCII_BUFF_L - на этом месте какая-то "бяка"... Посмотрите память перед выполнением atoi().

Или переменная, расположенная в памяти следом за ним, в момент проверки содержала ноль.