Понял. Да, мог бы конечно и сам понять что в адрес ничего не запишешь, можно записать по указателю адреса.

Но short вроде бы тип для целых чисел, а у меня переменная Temp потом будет преобразовывать свое содержимое из двух байт двоичного кода в десятичные показания температуры с точностью до десятых. И сама функция будет возвращать такое число. Поэтому я и спросил за float, может лучше это тип использовать?

Сообщение отредактировал RW6MKA - Mar 9 2014, 07:12

Обычно из таких - низкоуровневых - функций данные в плавающей точке все же не вытаскивают. Но если очень хочется, то можно.
Другой вопрос, нужен ли будет на деле этот float потом.

Хорошо, может это стрельба по воробьям из пушки. Какой тип вы для этой функции и переменной порекомендуете, если в результате функция должна вернуть число от -45,5 до 45,5 ?

Я бы оставил short, а привести/масштабировать всегда можно по месту.

Умножте это дело на 10, получите -455...455, это влезает в 16 битное целое с запасом.

Во общем из советов я прихожу к выводу, что float лучше не использовать, а все постараться свести к типу целых чисел например int или short. Кстати вот еще вопрос, чем они отличаются? Как я понял и тот и тот тип могут быть 16 битным.

Могут. На 8-16 битных архитектурах ничем не отличаются. На архитектурах большей разрядности short может (по стандарту никто не обязывает) остаться 16 битным, а int соответствует разрядности процессора.

Понятно. Тогда с учетом того, что я пишу код в AVRStudio под tiny2313 будет ли правильной вот эта функция

Правильнее будет int16_t, а не uint - результат ведь знаковый. И проверьте, что TD_receive_byte() возвращает char, а не больше.

Не совсем правильнее. Еще один момент есть - при таком раскладе, если Если TD_receive_byte() возвращаяет signed char, то операция temp = (temp << 8) | TD_receive_byte() убьет старший байт, если 7-ой бит там окажется в единице, и расширится до 16 бит. Так что, поосторожнее, надо бы на всяк случай написать temp = (temp << 8) | ((unsigned char)TD_receive_byte()). Вариант с прямой записью байтов на свои места по указателю в данном случае не имеет под собой таких "засад".

Нет, знак еще находится в коде, т.е. если 11-15 биты 1,то знак будет -. Так же и с дробной частью. Она заложена в 0-3 битах. Все это буду извлекать в отдельной функции с преобразованием в код LCD дисплея. Функция TD_receive_byte() возвращает uint8_t.

Это понятно. Но если Вы хотите, чтобы этот знак был учтен в дальнейшем, то результат должен быть знаковый:
short s = 0xffff;
unsigned short us = 0xffff;
float f;

f = s; // f = -1;
f = us; // f = 65535


Тогда порядок.

Понятно. Учту.
Спасибо всем за подробные ответы. Надеюсь и в дальнейшем на вашу помощь.

Судя по стартовому посту темы, вопрос касался оптимизации кода, т.е. стремления избавиться от операции 8-кратного сдвига, который МК обычно не умеют делать одной инструкцией. А то и вызывают на этом месте библиотечную функцию, которая осуществляет сдвиги в цикле со счетчиком. Тогда как ответы в общем-то сводятся к тому, как этот сдвиг красивше записать. Т.е. в плане оптимизации эти ответы не только бесполезны, но и уже негативно проявили себя по части всевозможных ошибок при реализации.

В этом плане выражение
было вполне оптимальным, с тем лишь недостатком, что оказалось непонятным топикстартеру. Т.е. его и надо было просто разъяснить, но не возвращаться к сдвигу.

На этот счет могу предложить альтернативу с union, которая в максимальной степени оптимальна, но гораздо проще в понимании:

Здесь union располагает в одной и той же памяти 2 байта byte и одно слово word, тем самым, позволяя заполнить последнее по частям.

Вот это, как раз, большинство 8-разрядных МК делают одной командой с легкостью, так как 16-битные регистры образуются из пар 8-битных, и такой сдвиг оптимизируется в пересылку сразу в нужный регистр.