не могу понять свою ошибку
- Войдите на сайт для отправки комментариев
Сб, 09/11/2019 - 00:18
собственно осваиваю массивы и операторы выбора Switch
и на пробном скетче впал в ступор.
что я сделал не так? прошу ткнуть носом: какое первичное выражение я пропустил?
алгоритм хочу считать так:
если разница между 10ым и 1ым значением в матрице меньше "-5", то тренду присвоить значение "4"
если от "-2" до "-5", то тренду присвоить "3" и т.д.
Это понадобится мне в последующем заполнении скетча выводом на экран и т.п.
пишет ошибку:
C:\Users\Documents\Arduino\my sketchs\trend\trend.ino: In function 'void loop()':
trend:23:11: error: expected primary-expression before 'case'
(-5) >= case: trend = 4; // неуклонно падает
^~~~
trend:25:10: error: expected primary-expression before 'case'
(-5) < case <=(-2): trend = 3; // уменьшается
^~~~
trend:27:10: error: expected primary-expression before 'case'
(-2) < case <= 2: trend = 5; // без изменений
^~~~
trend:29:7: error: expected primary-expression before 'case'
2 < case <= 5: trend = 1; // повышается
^~~~
trend:31:8: error: expected primary-expression before '>' token
case > 5: trend = 2; // неуклонно растет
^
Несколько библиотек найдено для "DHT.h"
Используется: C:\Users\Documents\Arduino\libraries\DHT
Несколько библиотек найдено для "Wire.h"
Используется: C:\Program
exit status 1
expected primary-expression before 'case'
#include "DHT.h" // подключаем библиотеку для датчика
DHT dht(A0, DHT11); // сообщаем на каком порту будет датчик
#include <Wire.h>
long temperature, temperature_massive[10]; // переменная температуры и массива температур из 30 значений
byte trend; // переменная тенденции
void setup() {
Serial.begin(9600); // подключаем порт монитора
dht.begin(); // запускаем датчик DHT11
for (byte i = 0; i < 10; i++) {
temperature_massive[i] = temperature; // забить весь массив текущими значениями температуры
}
}
void loop() {
temperature = dht.readTemperature();
for (byte i = 0; i < 10; i++) {
temperature_massive[i] = temperature_massive[i + 1]; // сдвинуть массив на один шаг назад (кроме последнего элемента)
}
temperature_massive[10] = temperature; // последний элемент массива теперь - новая температура
int a = (temperature_massive[10] - temperature_massive[1]);
switch (a) {
(-5) >= case: trend = 4; // неуклонно падает
break;
(-5) < case <=(-2): trend = 3; // уменьшается
break;
(-2) < case <= 2: trend = 5; // без изменений
break;
2 < case <= 5: trend = 1; // повышается
break;
case > 5: trend = 2; // неуклонно растет
break;
}
Serial.print ("trend = ");
Serial.println (trend);
delay (5000);
}
Открываем любое пособие по С или С++ и смотрим синтакис оператора switch
Шах и мат, сторонники эволюции и естественного отбора! А иначе как объяснить факт того, что ТС дожил до настоящего времени?
Вот и я говорю: на всё воля Б..жия и пути Господни неисповедимы!
а цикл 10-12, с красноречивым комментарием ?
а 17-20 и 21 с выходом за границы?
Да, ладно, вам, мужики. У меня вот уже фраза
вызвала уважение.
Согласитесь, чаще в проблемах виноваты не свои ошибки, а китайскость платы :)
И американские компиляторы.)
Вот, только помянул не к месту и давеча столкнулся.) Должно выдать v = 1234, а выдаёт 3412.
Не Ардуино - ХС8. С GCC всё ОК.
Где тут подвох? Вроде всё красиво. ЕвгенийП, есть мысли?)
...Должно выдать...
Мне бы так хотелось.) Слева направо ведь или нет?
А что, кто-то обещал?
Ну да, префиксный декремент справа-налево. Но тогда отчего у Ардуино наоборот?
Ну да, префиксный декремент справа-налево. Но тогда отчего у Ардуино наоборот?
виновата китайскость платы :)
Особенно когда проверяешь в эмуляторе.)
пожалуй подпишусь )))
Особенно когда проверяешь в эмуляторе.)
Да, в этом случае особенно.
А вообще, может настроение не то, но что-то троллинг не смешной какой-то.
Вот, только помянул не к месту и давеча столкнулся.) Должно выдать v = 1234, а выдаёт 3412.
Не Ардуино - ХС8. С GCC всё ОК.
Где тут подвох? Вроде всё красиво. ЕвгенийП, есть мысли?)
Специально попробовал ... похоже, подвох в том, что Вы неудачно шутите.
Так он какой-то компилятор другой в сарае отыскал - ХС8. С ним, говорит, little endian в big endian превращаются.
Нет никаких шуток. Вы невнимательно читаете.) Проблема не в Ардуино, проблема с ХС8 - компилятором для PIC16. А там 3412, хотя аналогичный фрагмент Ардуино выдаёт 1234. И вот вопрос, кто неправ.)
Так он какой-то компилятор другой в сарае отыскал - ХС8. С ним, говорит, little endian в big endian превращаются.
Ну почему в сарае? Это самый нормальный компилер для PIC среднего семейства.
Ну да, префиксный декремент справа-налево. Но тогда отчего у Ардуино наоборот?
Так дело не в декременте, а в том, что компилятор исходит и того, что преобразование из a*b в b*a с точки зрения математики является тождественным. А то, что программист совершил грубую ошибку, совместив в одном выражении два подвыражения, имеющих каждый побочный эффект, причем так, что этот эффект зависит от порядка вычисления выражения, от компилятора никак не зависит.
Компилятору неизвестно, что хотел написать программист, он может оперировать только с тем, что программист написал.
Вы можете разложить (разжевать) это выражение с точки зрения компилятора?
andriano, видимо, намекает на то, что компилятор вправе eeprom_read_byte(--i)<<8 | eeprom_read_byte(--i); выполнять сзаду.
Так я ж не против. Мне только непонятна последовательность выполнения.
Ты серьезно?
Так я ж не против. Мне только непонятна последовательность выполнения.
надо спросить армянское радио
а так?
Ты серьезно?
Да. Непонятно почему для одного компилятора так, а для другого - по другому. Просто пришлось в тему.)
Так я ж не против. Мне только непонятна последовательность выполнения.
Я сначала не заметил про другой компилятор и посчитал сообщение троллингом. Сорри.
А так-то всё нормально, вполне допустимо, что в разных компиляторах по-разному, т.к. стандарт не определяет последовательность вычисления операндов:
"Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced ... The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If a side effect on a memory location (4.4) is unsequenced relative to either another side effect on the same memory location or a value computation using the value of any object in the same memory location, and they are not potentially concurrent (4.7) , the behavior is undefined"
(ISO/IEC 14882:2017 разд. 4.6(17) стр. 14)
Где то такое у меня мыслях и витало, но хотелось какого то определения от знающих.) Спасибо!
Получилось так, что я аналогичный код делал под Ардуино и всё было ОК, а тут вот столкнулся с другим МК и на тебе!)
Вот так дураком и помрёшь.(
Кстати, порядок вычисления аргументов функции тоже не определён.
В моём случае сначала уменьшаем аргумент, затем передаём параметр. Разве нет?
Где то такое у меня мыслях и витало, но хотелось какого то определения от знающих.) Спасибо!
Получилось так, что я аналогичный код делал под Ардуино и всё было ОК, а тут вот столкнулся с другим МК и на тебе!)
Вот так дураком и помрёшь.(
будьте проще - пишите в лоб )))
а так?
а так?
видимо мой учитель твой компилятор писал )))
В моём случае сначала уменьшаем аргумент, затем передаём параметр. Разве нет?
это да. Я говорю про порядок вычисления аргументов.
Например f(++n, --n); ХЗ какой из аргументов будет вычисляться первым, а какой вторым.
видимо мой учитель твой компилятор писал )))
"Microchip MPLAB XC8 MPLAB XC16 MPLAB XC32 Три компилятора MPLAB XC для 8-, 16- и 32-разрядных микроконтроллеров позволяют увеличить скорость выполнения кода на 30% и уменьшить размер кода на 35%
Компания Microchip сообщила о выходе серии Си компиляторов MPLAB XC для всех 900 микроконтроллеров с 8/16/32-разрядной архитектурой и цифровых сигнальных контроллеров. Компиляторы MPLAB XC8, XC16 и XC32 упрощают выбор программиста и разработку приложений на базе микроконтроллеров, предоставляя три уровня оптимизации: Бесплатный (Free), Стандартный (Standard) и Продвинутый (Pro). Pro версии имеют оценочный режим на 60 дней. Компиляторы XC мультиплатформенные и работают под Linux, Mac и Windows.""
Так я ж не против. Мне только непонятна последовательность выполнения.
Программисту следует исходить из того, что при такой записи последовательность выбирается компилятором по своему усмотрению.
Вариант, где последовательность выполнения определена, приведен в сообщении №24.
Ну, так мы договоримся до того что и оптимизацию нам самим тоже нужно делать.
Я ж говорю, смутило то что с одним так, а с другим иначе. Потому и вопрос возник.
Еще раз: с конструкциями, имеющими побочный эффект, обращаться нужно крайне осторожно.
А оптимизацию - да: самая эффективная оптимизация - алгоритмическая, ее нужно делать именно "нам самим", компилятор ее за нас делать не может.
в MPLAB я только ассемблером пользовался да и из пиков только для pic16F84
всем спасибо. разобрался с синтаксисом.
массив не до конца победил.=(