caxapa.ru :: Keil C51 преобразование типов.

RedFroggy (22.02.2013 10:00 - 10:03, просмотров: 13861)

Keil C51 преобразование типов. Исходные условия: 1. Keil C51 8.04, (также проверялось на 9.50a и 9.51) 2. Silabs C8051F021 3. Уровень оптимизации от 2 до 8 Описание проблемы: есть глобальная переменная: unsigned int Var1; есть функция: f1(char *buff) в функцию передаётся указатель на буфер, для определённости пусть будет размером 256 байт в теле функции есть код: Var1 = buff[2] + 4; допустим, buff[2] на данный момент хранит значение 0xC0 в Var1 помещается не 0x00C4, а 0xFFC4 Как с этим бороться? Причём, если записать выражение как Var1 = 0xC0 + 4, то всё работает правильно.

Ответить

- POV дал верную мысль. Компилятор прав, не прав был я. После объявления и реализации функции как f1(unsigned char* buff) всё стало работать. Всем большое спасибо за помощь. - RedFroggy(22.02.2013 12:10)
  - ЗБСЬ! - POV(22.02.2013 12:13, картинка)
- а если так - Var1 = (unsigned char)(buff[2] + 4); - Vit(22.02.2013 11:33)
  - Уж точно не так. Сначала надо бы buff в беззнаковый превратить. разве что скобочку поставить "как никто не ставил": Var1 = ((unsigned char)(buff[2])) + 4 <- тоже не работает - POV(22.02.2013 11:35 - 11:55)
    - Но вопрос - а как афтор поста интерпретирует отрицательные значения буфера? Какой вообще результат он хочет получить? Знаковое 0xC0 - есть отрицательное и меньше 128. Т.е. с 1 в старших битах. Так шта преобразование в 0xFFC0 корректное. - POV(22.02.2013 11:49 - 11:54)
      - вроде как (unsigned int)((unsigned char)(buf[2]+4)) не должно приводиться к signed long, но вот будет ли ((unsigned char)(buf[2]+4)) приводиться к signed int по-любому или не будет - не вкурсе - Vit(22.02.2013 11:57)
        
        Проверил на стимуляторе в кейле. Ничего не работает - всегда получается 0xFFC0 - и, как я выше написал, это, похоже, корректно. Ибо в кейле char по умолчанию знаковый, а афтар явно не этого хотел... POV(312 знак., 22.02.2013 12:01 - 12:11)
        
        Гнусный паскализм. char нужно использовать только для символов (алфавита). Для чисел int. И не морочить мозги... - fk0(22.02.2013 12:10)
        
        Дык их жаба душит: целых 8 лишних битов. Вот и извращаются как могут. - SciFi(22.02.2013 12:38)
        
        Для жлобов есть int_fast8_t и uint_fast8_t. Для совсем жлобов -- uint8_t. - fk0(22.02.2013 13:47)
      - Опппа. Неплохая мысль. После поздравлялок, если буду в состоянии - проверю сей факт. - RedFroggy(22.02.2013 11:56)
- А ещё... POV(92 знак., 22.02.2013 11:03)
- Всё правильно кейл сделал. А бороться так: Var1 = (unsigned char)buff[2] + 4; - SciFi(22.02.2013 10:02)
  - Возможно, это ошибка из разряда таких (из последнего Release Note): RedFroggy(1218 знак., 22.02.2013 10:25)
  - Это не помогает, пробывал RedFroggy(143 знак., 22.02.2013 10:04 - 10:08)
    - Не верю. - SciFi(22.02.2013 10:11)
      - Так и я был уверен, что всё нормально. Пока мне в последовательный порт не полетели дикие объёмы данных, из-за того, что Var вместо 196 байт превратилась в чудовище - RedFroggy(22.02.2013 10:14)
    - Сразу опишите buff как unsigned char. И в каком положении у вас стоит галочка "Enable ANSI integer promotion rules" во вкладке C51 опций проекта? - vmp(22.02.2013 10:09)
      - Enable ANSI integer promotion rules - галочка установлена - RedFroggy(22.02.2013 10:12)
        
        Тогда попробуйте Var1 = (unsigned int)buff[2] + 4; - vmp(22.02.2013 10:13)
        
        Это тоже не помогает - RedFroggy(22.02.2013 10:21)
        
        Ну а принудительно на ноль помножить? 0x00ff & (int)buf[] - Vladimir Ljaschko(22.02.2013 10:47)
        
        Самое плохое - что ошибка неявная. Т.е. все способы, которые сразу приходят в голову, по приведению типов и т.п. - НЕ работают. Так как конструкцию 0xC0 + 4 работает, то всё что приходит в голову - какая-то проблема с передачей указателя на RedFroggy(157 знак., 22.02.2013 10:56)
        
        пробуем так abivan(522 знак., 22.02.2013 11:12 - 11:26)
        
        Паяльником старший адрес закоротить на землю :-) - SciFi(22.02.2013 10:51)
        
        Криптометод? RedFroggy(132 знак., 22.02.2013 11:07)
        
        Вы не поверите - это было первое, что я сделал. Но увы... - RedFroggy(22.02.2013 10:50)
        
        Попробуйте no int promotion. Тогда компилятор будет использовать байтовую арифметику, вместо полагаюшегося по стандарту предварительного перевода из char в int. - vmp(22.02.2013 10:54)
        
        "Фу, кейл" подумали те, кто использует ИАР. Загадка. - Vladimir Ljaschko(22.02.2013 10:54)
        
        Пользуюсь и тем, и другим. Надо только привыкнуть, что Keil C51 - это не язык Си, а некий специфический язык программирования, заточенный под архитектуру 8051. - vmp(22.02.2013 11:09)
        
        Так и я тоже и тем и другим. Но сейчас Keil. Так получилось. - RedFroggy(22.02.2013 11:13)
        
        Подумали и хорошо. Можно и в ИАРе на ровном месте яму с гов...м найти и в ней утонуть. - RedFroggy(22.02.2013 10:59)
        
        Это вредный совет, так как (unsigned int)(signed char)'\xC0' == 0xFFC0u. - SciFi(22.02.2013 10:18)
        
        Обычно я для 51 отключаю int promotion (пусть считает в байтах) и вместо обычного char пишу что-то типа typedef unsigned char byte. Только в редких случаях приходится вручную указывать, что нужно действительно перевести байты в слова. - vmp(22.02.2013 10:23)
  - И чего правильного? Ни разу на такое не наталкивался, а явное приведение типов использую только чтобы варнингов было поменьше... POV(69 знак., 22.02.2013 10:06)
    - И вообще есть принципиальные возражения, так как пример кода - типичное программирование на ассемблере с синтаксисом Си. - SciFi(22.02.2013 10:21)
      - Так для 51 постоянно приходится выбирать - или писать на стандартном Си и мириться с диким перерасходом ресурсов из-за особенностей архитектуры, или писать на специфическом ассемблероподобном диалекте Keil C51 для приемлемого объема кода. - vmp(22.02.2013 10:41)

Микроконтроллеры