Комментарии 18
Как насчет помех, насколько чистый сигнал приходит от датчика Холла, не покажете? Очень интересно глянуть
получить данные температуры с датчика (sensor.getTemp()) мы можем только отправив запрос (sensor.requestTemp();) и подождав (delay(1000);). Как всегда delay всё портит и если без таймера опрашивать кнопку в loop, то переключив один раз режим на отображение температуры (сработает delay) — сменить режим мы уже не сможем
Зачем плодить сущности? В loop уже есть активный таймер, зовётся millis(). С ним легко решается обход delay, пусть датчик ждёт своей секунды, а программа работает параллельно.
Да и вообще, концепция суперцикла это зло, которое заставляет выдумывать костыли и порождает непонятные проблемы. Достаточно взять любой планировщик, коих под ардуину много, и ценой 5кб памяти решить любые подобные проблемы, перейдя на концепции отдельных задач-потоков.
А можно также взять другой контроллер. Или на дискретной логике сделать. Или на raspberry с линуксом.
Для 2 датчиков планировщик как то из пушки по воробьям.
Вы передергиваете.
Во-первых, реализация этого на логике — это еще больший оверинжиниринг, ибо влечет за собой десяток плат с микросхемами. Малину и жирные контроллеры с линуксом я не предлагал, как не предлагал и смену контроллера.
Во-вторых, у автора возникла проблема, я описываю подход, где этой проблемы вообще не возникнет — опрос кнопки в одном потоке, работа с датчиком в другом, с экраном в третьем. Причем, как я уже сказал, ничего менять не надо, ни новый контроллер, ни малину, ни линукс, просто немного кода, все равно у тс достаточно памяти.
В-третьих, нет никакого понятия «из пушек по воробьям»: все определяется стоимостью часа разработки и экономией денег после этой разработки. Если я делаю устройство в тираж 1м, то я буду биться за каждый рубль стоимости контроллера, и если надо, посажу разрабов писать на ассемблере прошивку, чтобы уложиться в более дешевый контроллер (разумеется, если меня удовлетворит стоимость поддержки такого ПО): там стоимость разработки сильно-сильно ниже стоимости партии. Если я делаю устройство в тираж 1 (прописью: одну) штуку, то мне абсолютно пофиг, стоит контроллер 10 рублей или 50 рублей, но очень-очень не пофиг на свое время: если +40 рублей к цене устройства экономят мне неделю работы за счет RTOS, планировщика, готовых жирных библиотек и так далее, то выбор очевиден. Тратить неделю на непрофильную работу, если это можно сконвертировать в небольшие затраты смысла ноль, лучше в свободное время какой-нибудь другой девайс сделать. Тут же даже не надо менять контроллер, просто прочитать и понять некоторые концепции, и разобраться, как добавить в проект либу.
В-четвертых, вы неправильно воспринимаете ситуацию. Это не планировщик усложняет конкретную разработку, это из-за отсутствия планировщика конкретная разработка останавливается на одном уровне сложности и не идет дальше, потому что в суперцикле сложная логика превращается в простыни кода, сотни счетчиков и кучу вложенных if-ов. Да, два датчика можно реализовать и так. Но в какой-то момент разработчик упрется в то, что n-ый датчик реализовать уже не получается, все, нафиг надо, уйду в проститутки. Это плохо, так как ограничивает полет фантазии и возможности разработчика. Пока в голове сидит это «RTOS это оверкилл для этого проекта, он же маленький», удел разработчика это поделки на ардуиновском суперцикле. Вырасти в своем хобби или профессиональном плане можно только после того, как мышление сменится на «я знаю, что есть такой инструмент как RTOS, и если я сейчас не смогу (или думаю, что не смогу в будущем) реализовать этот функционал на суперцикле, я просто возьму необходимый инструмент, не загоняясь на тему потраченных пяти килобайт»
Во-первых, реализация этого на логике — это еще больший оверинжиниринг, ибо влечет за собой десяток плат с микросхемами. Малину и жирные контроллеры с линуксом я не предлагал, как не предлагал и смену контроллера.
Во-вторых, у автора возникла проблема, я описываю подход, где этой проблемы вообще не возникнет — опрос кнопки в одном потоке, работа с датчиком в другом, с экраном в третьем. Причем, как я уже сказал, ничего менять не надо, ни новый контроллер, ни малину, ни линукс, просто немного кода, все равно у тс достаточно памяти.
В-третьих, нет никакого понятия «из пушек по воробьям»: все определяется стоимостью часа разработки и экономией денег после этой разработки. Если я делаю устройство в тираж 1м, то я буду биться за каждый рубль стоимости контроллера, и если надо, посажу разрабов писать на ассемблере прошивку, чтобы уложиться в более дешевый контроллер (разумеется, если меня удовлетворит стоимость поддержки такого ПО): там стоимость разработки сильно-сильно ниже стоимости партии. Если я делаю устройство в тираж 1 (прописью: одну) штуку, то мне абсолютно пофиг, стоит контроллер 10 рублей или 50 рублей, но очень-очень не пофиг на свое время: если +40 рублей к цене устройства экономят мне неделю работы за счет RTOS, планировщика, готовых жирных библиотек и так далее, то выбор очевиден. Тратить неделю на непрофильную работу, если это можно сконвертировать в небольшие затраты смысла ноль, лучше в свободное время какой-нибудь другой девайс сделать. Тут же даже не надо менять контроллер, просто прочитать и понять некоторые концепции, и разобраться, как добавить в проект либу.
В-четвертых, вы неправильно воспринимаете ситуацию. Это не планировщик усложняет конкретную разработку, это из-за отсутствия планировщика конкретная разработка останавливается на одном уровне сложности и не идет дальше, потому что в суперцикле сложная логика превращается в простыни кода, сотни счетчиков и кучу вложенных if-ов. Да, два датчика можно реализовать и так. Но в какой-то момент разработчик упрется в то, что n-ый датчик реализовать уже не получается, все, нафиг надо, уйду в проститутки. Это плохо, так как ограничивает полет фантазии и возможности разработчика. Пока в голове сидит это «RTOS это оверкилл для этого проекта, он же маленький», удел разработчика это поделки на ардуиновском суперцикле. Вырасти в своем хобби или профессиональном плане можно только после того, как мышление сменится на «я знаю, что есть такой инструмент как RTOS, и если я сейчас не смогу (или думаю, что не смогу в будущем) реализовать этот функционал на суперцикле, я просто возьму необходимый инструмент, не загоняясь на тему потраченных пяти килобайт»
У каждого есть свой набор микроскопов с удобными ручками ;)
Нет, всё значительно проще. Аналоговый датчик (1 операционник) + интегратор для импульсов (ещё один) + линейный светодиодный индикатор на компаторах (по 1 на светодиод), например. Операционники бывают и по 4 в одном корпусе. Или АЦП на сдвиговых регистрах — тоже ничего сложного. Конечно, если задаться целью сделать I2C на мелкой логике, это будет страшно…
Вы правы. Но это же хобби-проект. Совершенно не факт, что автор планирует сильно упарываться в микроконтроллеры. А ардуиновский суперцикл — проще всего для понимания.
реализация этого на логике — это еще больший оверинжиниринг, ибо влечет за собой десяток плат с микросхемами
Нет, всё значительно проще. Аналоговый датчик (1 операционник) + интегратор для импульсов (ещё один) + линейный светодиодный индикатор на компаторах (по 1 на светодиод), например. Операционники бывают и по 4 в одном корпусе. Или АЦП на сдвиговых регистрах — тоже ничего сложного. Конечно, если задаться целью сделать I2C на мелкой логике, это будет страшно…
все определяется стоимостью часа разработки и экономией денег после этой разработки
в какой-то момент разработчик упрется в то, что n-ый датчик реализовать уже не получается
Вы правы. Но это же хобби-проект. Совершенно не факт, что автор планирует сильно упарываться в микроконтроллеры. А ардуиновский суперцикл — проще всего для понимания.
Ну для 328p целых 5 кб — непозволительно много.
Есть два вопроса: 1) этого датчика хватит только до +125 градусов, Вам этого хватит? Не совсем понимаю что именно Вы собрались мониторить. Есть смысл смотреть температуру масла и температуру выхлопа.
2) обороты минимото ниже 10 тысяч?
2) обороты минимото ниже 10 тысяч?
обороты можно еще считывать по индуции провода свечи — рапространенное решение. а в комбинации с уже существующим датчиком холла можно понять если искры нет
Спидометр/тахометр в виде цифр — не думаю что это удобно. Привычно — шкала с делениями и «зеленой зоной» — чтобы с одного взгляда было понятно, разумные обороты или нет ;) Цифры удобнее при регулировке.
Прочитать долгоиграющий датчик без delay()
unsigned int start_read_temp = 0;
void loop()
{
if (start_read_temp == 0)
{
// begin read temp code here
start_read_temp = millis();
};
if (start_read_temp != 0 && (millis - start_read_temp) > 1000)
{
start_read_temp = 0;
// final read temp code here
};
// other code in loop()
}
Сюда идеально впишется вариант с круглым дисплеем, типа такого: https://drive.google.com/file/d/1en2UMwhEnxgcWEULq-M5SGpxSyn9qdtz/view?usp=sharing
Смотрите в стоорону прерываний. Она решает проблемы с задержками токого рода.
датчик холла лучше всего вешать на прерывание:
const byte interruptPin = 2;
pinMode(interruptPin, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(interruptPin), mesure, CHANGE);
const byte interruptPin = 2;
pinMode(interruptPin, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(interruptPin), mesure, CHANGE);
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тахометр + температура двигателя на Arduino для МиниМото