Ни хрена так не можно. И причин сразу несколько. В каждой строке как минимум по две ошибки.
И чё постить не проверив?
Смысл - когда с момента начала работы loop millis увеличится на 3600000.
Давайте тогда так:
#include <SFE_BMP180.h>
SFE_BMP180 pressure;
//для тактового генератора
static uint32_t period = 500;
static uint32_t moment;
bool trigger;
int st;
bool start_bmp180;
float cur_t, cur_p;
void setup()
{
pinMode(13, OUTPUT);
digitalWrite(13, 0);
pressure.begin();
Serial.begin(9600);
}
void loop()
{
//для BMP180
char status;
double T, P;
//тактовый генератор
if (millis() - moment >= period)
{
moment = moment + period;
trigger = !trigger;
digitalWrite(13, trigger);
if (trigger) //пришел секундный импульс
{
st++;
if (st == 5)
{
start_bmp180 = true; //разрешить запуск BMP180
st=0;
}
}
}
if (start_bmp180) //запуск BMP180
{
status = pressure.startTemperature();
if (status != 0)
{
delay(status);
status = pressure.getTemperature(T);
if (status != 0)
{
//Переменная T скоро испортится.
//ее надо срочно прочитать
if (T > 0)
{
cur_t = T;
}
status = pressure.startPressure(3);
if (status != 0)
{
delay(status);
status = pressure.getPressure(P, T);
if (status != 0)
{
//получаем текущее давление P и переводим миллибары в мм рт. ст.
// cur_p = P * 0.75014766658; //миллибары в мм рт. ст.
cur_p = P * 0.750063783; //миллибары в мм рт. ст.
}
}
}
}
start_bmp180 = false;
}
}
В этом скетче BMP180 опрашивается каждые пять секунд.
Если пренебречь временем, необходимым для начала работы loop после запуска, то когда millis насчитает 3600 секунд - диод мигнет 3600 раз. Что мне и надо.
А сколько раз он мигнет, если moment = millis() ?
Скорее всего столько же. В данном скетче разницу можно будет ощутить через пару/тройку месяцев, думаю ))
1 лайк
Здрасте! Для светодиода ничем, а кроме светодиода можешь заниматься чем хош. То же что и у ТС. Сократить - ключевое слово.)
Мне мешает delay() в опросе датчика. И мне надо одновременно отсчитывать секнды (вернее накапливать их) с точностью работы millis(), которая меня вполне устраивает… Поэтому moment = moment + period; - вынужденная мера.
миллис это уже делает, зачем его дублировать
Секунды можно накапливать и так. Накопить 20 минут.
static uint32_t period;
static uint32_t moment;
void setup()
{
period=20*60*1000;
moment=millis();
}
void loop()
{
if (millis() - moment >= period)
{
moment=millis();
// Пришли сюда через 20 минут
}
}
А вообще жаль, что нет возможности работать с потоками…
Да. Задумался над этим. #70.
как “так”? это обычный интервал на миллис. Что в этих строчках нового? Где тут “накопление”?
Бред какой-то
плохому танцору всегда жаль…
Вы тоже не сразу танцевать научились.
Этот интервал и есть - накапливание. Накопил 20 минут - что - то сделал.
В чем тут вопрос?
Это стандартный скетч из пособия “Блинк без delay”
вот эта часть, повторенная несколько раз - это какой-то вынос мозга. Откуда вы это списали? Можно ссылку?
Далеко ходить не надо.
Arduino - IDE.
Файл → Примеры → SFE_BMP180-master → SFE_BMP180_example
В том, что есть “две балетные школы” для “блинк без делей”.
Такое:
if (millis()- oldMillis > interval) {
oldMillsi = millis();
doSomething();
}
и такое
if (millis()- oldMillis > interval) {
oldMillis += interval;
doSomething();
}
Разница в том, что первая дает интервал между событиями не ниже заданного, а второе используется для сохранения средней частоты событий по времени, например 18 раз в минуту ;).
Естественно обе устойчивы к переполнению. 
Кому нравится арбуз, а кому свиной хрящик. (с)
А как вы думаете, как на одноядерном однопоточном процессоре любая ос умудряется крутить кучу процессов с кучей потоков в каждом? Правильно, переключаясь между ними. Собственно, примерно то же самое вы видели в статье о диспетчере задач. Только в мире больших ПК многозадачность вытесняющая, а тут вы организуете некое подобие кооперативной. Изучайте, глядишь и появиться у вас возможность “работать с потоками”
Или купить за тот же прайс контроллер, разработанный не в 20, а в 21 веке, например RP2040 или ESP32, и “работать с потоками” под FreeRTOS уже сейчас.
Это будет уже совсем другая пестня ))
А это не нужно рассказывать любителям “потоков”. Мутексы, семафоры и очереди сообщений будут для них “приятной” неожиданностью
Это да ))
Там еще критические секции должны быть…