Долго не мог выявить, почему цифровой датчик давления выдает неверный результат.

Во втором случае дает другой (правильный) результат. Почему?

Потому что стандарт языка С не определяет порядок вычисления подвыражений.
Какой из i2c_read() будет вызван первым зависит в общем случае от положения звезд на небе. Ваша функция обладает побочными эффектами, поэтому вызывать ее дважды в одном выражении не рекомендуется во избежание таких неожиданностей.

Я поражен меткости и, главное, оперативности Ваших ответов. Спасибо, Сергей.

Заглядывание в листинг при непонятной работе программы частенько помогает очень быстро найти ошибку. Особенно если кажется, что все написано правильно.

Что значит, стандарт не определяет? Вот строчка из "K&R C": "Все бинарные операции и условная операция (прим. Перевод.: условная операция группируется справа налево; это изменение внесено в язык в 1978 г.) группируются слева направо"

Это следут проверить таким образом:

Я не такой большой специалист в Си и могу ошибаться, но ИМХО компилятор может "оптимизировать" вызов функции и вместо двух вызовов формировать один, а все бинарные операции проводить с одним полученным результатом. Как уже заметили, просмотр листинга может прояснить этот нюанс.

Вот что выдал листинг:

Как говорят у нас, на Украине, rezident "має рацію"

Если под бинарными понимаются && и || - определен. Для остальных (кроме ?: и оператора "запятая") - нет. Вот цитата из стандарта языка (INTERNATIONAL STANDARD ISO/IEC 9899, Programming languages — C, Second edition 1999-12-01):Это дает гораздо больше свободы оптимизатору.


Мне пришло в голову, что во избежание подобных недоразумений функцию надо бы объявить как volatile. В этом случае:
1) Компилятор был бы обязан вызвать ее дважды.
2) IAR выдал бы предупреждение о неопределенности при использовании более одной volatile в выражении. GCC такое предупреждение не выдает, это ему минус. Хотя когда в IAR появилась эта проверка - многих предупреждение ставило в тупик. Вот, видимо, наглядный пример, когда это предупреждение обосновано.

Вот оно как... Не дадите ссылочку на первоисточник - надо бы почитать для просвещения

Да запросто: Google -> ISO/IEC 9899, вторая ссылка дает pdf

Даже без volatile компилятор обязан был вызвать эту функцию дважды, т.к. внутри
этой функции есть работа с volatile переменными, например с регистрами TWI...

P.S. Нда... , чего-то у IAR совсем плохо c volatile..., уже 2 баги за последние пару дней...

Ничего он не обязан.
Кто писал программу - Вы или компилятор?
Все свойства функции - это типы параметров и адрес вызова, а требовать от компилятора анализа свойств используемых переменных внутри функции - эта попытка взвалить на него исправление Ваших ошибок.

Атлична, раскажите мне пожалуйста, исходя из каких правил описанных в стандарте С
компилятор имеет право обработать эти две ситуации по разному:

и


по Вашей логике в первом случае он имеет право вызвать NegPort() один раз а во втором
обязян вызвать 2 раза...
и почему во втором случае он не вызовет так же один раз ?

О порядке вызова функций при сложении речи не идет...

P.S. Пример конечно сильно упрощен, но смысл я надеюсь понятен...

P.P.S А так же в догонку очень хотелось бы понять, имеет ли право на жизнь
следующая запись в языке С:
Z = X * K1 * rand() + Y * K2 * rand();
или я обязан разделить ее на 2 подвыражения для того чтобы не получить одинаковый
результат на выходе rand().... ???

Видимо потому, что между вызовами во втором случае стоит ";", т.е. sequence point, на момент которой все побочные эффекты должны выполниться. Побочным эффектом в данном случае является запись в PORTB. Если я все правильно понимаю.

конечно, и функция уже должна наследовать признак "volatile", те sequence point должны
быть при каждом вызове этой функции

Кому должна? Ведь тело функции может находиться и в другой единице компиляции. Откуда в таком случае компилятор узнает, что вы в ней обращаетесь к volatille-объектам? Я полагаю, что для получения правильного поведения функция должна быть описана как int NegPort() voltile {}. "И сразу польется вода" © Тот самый Мюнхгаузен.

Хорошо, есть функция rand() которая определена в другой единице компиляции,
в стандартной библиотеке.
Определена она так int rand(void) , т.е. без всяких volatile.

Вопрос:
Могу ли я написать у себя в программе
А = rand() + rand(); ?
или компилятор может вызвать rand только один раз ?

Проконсультировался с ReAl - в С функция не может иметь атрибута volatile, это я с плюсами попутал: Так что тут вы правы - компилятор не может заменить два i2c_read() или NegPort() на один. Признаю, вводил в заблуждение.

Это заставило вновь внимательно посмотреть листинг из поста №7 - и что мы видим? Мы не видим там одного вызова i2c_read() - мы видим, что вызов(ы) i2c_read() происходят в подпрограмме ?Subroutine0, содержимое которой нам не показали. Видимо подобная конструкция используется в файле не один раз и компилятор посчитал оптимальным вынести ее в отдельную подпрограмму. Ставлю себе большую двойку за невнимательность.
Так что вопрос - ошибся тут компилятор или нет остается открытым до обнародования листинга ?Subroutine0

Возможно Вы правы насчет объединения двух вызовов в отдельную подпраграмму,
только тогда очень странно выглядит LDI R25,0 после подпрограммы...

Автор, выложите более полный листинг.

Пожалуйста. Не подозревал, что простой, на первый взгляд, вопрос вызовет такое бурное обсуждение


Добавлено

Прошу прощения, но теперь в данном lst функция i2c_read(ACK) вызывается дважды. Хотя готов поклясться, что в посте №7 функция вызывалась один раз. Попытаюсь воспроизвести ту ситуацию еще раз. Листинги я не сохранил, к сожалению.

Еще раз добавлено

Вот , восстановил (asdx-2). Возможно я был не внимательный, когда говорил, что функция вызывается один раз. Кстати, вопросик по ходу: как лучше писать


В последний раз добавлено

Прокоментируйте, пожалуйста следующее:

Возможно, здесь нарушен порядок вызовов функций: первым должен читаться старший байт, затем сдвинуться на 8 бит, затем сложить с прочитанным младшим байтом.

К сожалению Вы востановили не до конца,
перед обсуждаемыми строками у Вас еще стоят:
44 HiTemp=i2c_read(ACK);
45 LowTemp=i2c_read(NACK);
которые и мешают отработать оптимизатору так же как и было в самом первом листинге...
ИМХО, в данном случае пофиг, но в общем и в целом лучше в таких случаях
пользоваться |, так и вероятность ошибок меньше и скорость работы может быть выше,
все зависит от конкретного компилятора.
Порядок то здесь наверняка нарушен(наверное мы чуть запутали Вас нашим обсуждением),
в Вашем случае все равно нужно делить эти вызовы на два разных оператора, те первый ответ
данный Сергей Борщ был абсолютно правильный.
Тока вот все равно какая то фигня творится, LDI R25,0 здесь просто не должно быть...

Этот листинг формируется, если перед этим убрать вызовы функций:

Как узнать, в какой регистр возвращает первый и второй CALL i2c_readAck ? Мне кажется, что в результате младший и старший байты перепутаны местами.
MOV R24, R16
LDI R25, 0
это есть:
((unsigned int)i2c_read(ACK)<<8) ?

Никак. Сергей Борщ с самого начала дал правильный ответ.
Порядок вычисления подвыражений неопределён для всего, кроме . Точка. Это не имеет никакого отношения к порядку группирования операций слева направо или наоборот.
Сразу, чтобы не было иллюзий по поводу function call () ( "скобок вызова функции", круглые скобки выполняют роль cast operator, parentheses punctuator и function-call operator, в данном случае об этом)

Ну так вот, независимо от порядка группирования операторов op (за исключением перечисленных выше операторов) в следующем выражении
порядок вызова функций неопределён. Могут вычисляться в порядке группирования, могут быть вызваны все три в противоположном порядке, а потом будут произведены вычисления. Отдано на откуп реализации. "вероятнее всего" будут вызываться в порядке группирования, но я бы не стал закладываться.
Поэтому правильный вариант либо как указал Сергей, либо

А вот в этих местах что лучше писать - как правило, лучше ИЛИ.

В один и тот же. В регистр, принятый в компиляторе для возврата байтовых значений из функций.
Просто результат первого вызова по какой-то причине игнорируется вообще (но вызов сделан, ибо компилятор лишён информации о том, имеет ли данная функция побочные эффекты и поэтому обязан сделать вызов). А результат второго вызова из R16 приводится к беззнаковому целому в паре R25:R24
Почему так - совершенно непонятно.
Покажите (без ассемблера, С-шный исходник) - объявления функций i2c_* и тело этой функции, в коде которой бардак выходит.
У IAR-а случайно нет какого-то ключика/галочки - сделать int 8-битовым? Очень похоже, что ((unsigned int)i2c_read(ACK) << 8) считается равным 0

На счет галочек... Не нашел такого, чтоб "сделать int 8-битовым". Единственное, что нашел,- в закладке C/C++ Compiler->Language->Language conformance выбрано Allow IAR extantion; Plain char is -> unsigned; Enable multybyte support -> оставлено по-умолчанию (пустым).


Вот пример вызова. Все ли здесь правильно? i2c_stop(); - правильно или вынести в общий цикл. Напоролся на такую проблему. Хоть и написано что данный сенсор "The ASDX family uses I2C compatible protocol" , но он не читает последовательность байтов. Т.е. перед каждой парой байт необходимо делать RESTART. Обязательно ли после приема пары байтов делать STOP? Или оставить как есть. - это скорее для красоты. Ведь ИЛИ с нулем ничего не изменяет.

Я немного цитаты перетасую

И не надо. Просто если бы она была и стояла, то это могло привести к некоторым глупостям, отдалённо напоминающим то, что было.

Так для этого случая, с промежуточными переменными - вроде бы, всё было нормально?
И ещё - в предыдущих примерах было ACK в обеих строках.


О-о-о-о!!!
Давно не видел грабелек со столь любовно отполированной ручкой
Получил массу удовльствия
Значит так:

Т.е. вся первая тернарная операция входит в условие второй.
Дальше выполняется следующее
Константа ACK приводится к unsigned int и проверяется на 0.
Она не 0, поэтому вызывается i2c_readAck(), но ничего не сдвигается - сдвиг "прилип" к вызову в ветви "ЛОЖЬ" тернарной операции.
Результат первой тернарной операции "заиливается" с ACK и проверяется на 0.
Поскольку ACK не равно 0, эту битовую операцию "ИЛИ" можно и не производить, и так ясно, что будет не 0.
Итого от строки /* 1 */ остаётся только вызов i2c_readAck() (нельзя убрать, несмотря на то, что результат не используется) и к началу строки /* 2 */ мы получаем условие "ИСТИНА", в результате чего вызывается ещё раз i2c_readAck() и уже её результат приводится к unsigned, что и было в итоговом коде.

Настоятельно рекомендую если и пользоваться макросами - выражениями, то в скобки брать не только аргументы, но и весь макрос как целое.

Но всё равно в данном случае как минимум одна временная переменная нужна, см. мой предыдущий пост. Иначе рано или поздно будет радостная встреча с каким-то компилятором, который сделает "неожиданный", но допустимый стандартом порядок вызова функций.

это я сделал специально для чистоты эксперимента
ReAl - ну Вы просто гигант мысли . Вам огромный

Я тоже получил массу удовольствия от этого объяснения.

Позвольте реабилитироваться и внести свой вклад:
Кажется так может быть эффективнее. А может и нет. Надо смотреть листинг.

Ну у меня вообще не так, у меня read сразу с указателем и длиной, а внутри цикла что-то в духе

Всё равно по одному байтику практически никогда не читается, а если вдруг надо - то не так и страшно вызвать с указателем и длиной 1.