Так что я бы вывод перефразировал — кодить на асм смысла нет, если разработка ведется на современных МК.
Но при этом понимать как работает МК без хотя бы поверхностного представления об асме — затруднительно, поэтому из академического интереса изучить асм как минимум полезно.
Контроллер ждет и обрабатывает информацию с датчика 0,39 сек, а спит минуту
… но тут «внезапно» всплывает то, что для тактирования Вы зачем-то используете кварц, а время его раскачки много больше, чем встроенного RC генератора (и много больше, чем время исполнения этих нескольких инструкций).
Вы вырвали фразу мою фразу из контекста. «Внезапно» всплывает — это для Вас. Советую посмотреть мой пост хотя бы по диагонали. Там встроенный RC-генератор. Методика измерений характеристик тщательно продумана — для этого разработаны несколько вспомогательных скетчей и т.п. Никаких замечаний по поводу методики и результатов измерений не было.
Я все это написал к тому, что если уж говорить о минимизации потребления, то, помимо «вылавливания блох» между C и ассемблером, нужно так же грамотно подходить и к общему проектированию системы.
«Блохи» я не ловлю, поскольку Ассемблера не знаю, а анализирую и сопоставляю то, что уже сделано, иногда компилируя коды составленные другими. Говорю о тенденциях. Грамотность проектирования системы (метеостанции) подтверждена «железом» и полученными техническими характеристиками. Недостатки проекта тоже знаю и их не замалчиваю.
Я тоже имею опыт проектирования на ТТЛ-, МОП-структурах, который исчисляется десятилетиями. Но однозначно утверждать, что построить управление простого бытового прибора на дискретных элементах дешевле, чем на одном контроллере стоимостью десяток-другой центов — не стану. Впрочем, жизнь подтверждает — никто этого и не делает. Заранее благодарю за понимание.
если планируется многомиллионный тираж достаточно сложного устройства — для софта нужен подход, который за вменяемое время для ассемблера не обеспечить.
накладные расходы у Си немногим выше, чем у ассемблера — но пишется/тестируется гораздо быстрее, удобнее…
Согласен! Но повторю ваши слова: «если планируется многомиллионный тираж достаточно сложного устройства ...». Вы правы — в таких случаях и подходы другие.
Тут в метеостанции у меня не плата Ардуино, а «голая» Atmega328P и кварц. Прототип делал для себя и добился поставленной цели: потребление устройства на уровне автономных промышленных продуктов.
Мало ли, вдруг они оба 90% времени тупо ждут ответа от датчика, так что разницы и незаметно будет.
Все это я давно прошел. Посмотрите, пожалуйста, тут. По ключевым словам «Операционное время функции измерений параметров воздуха, состояния батареек» найдите таблицу. В ней приведено время выполнения операций и потребление. Контроллер ждет и обрабатывает информацию с датчика 0,39 сек, а спит минуту.
Разве что стоило это явно отметить в тексте мол «да, я знаю что „язык“ Ардуино это всего лишь avr-g++, густо обмазанный специализированными библиотеками и костылями, но чтобы отличать от программирования на Си в рамках статьи буду называть его „языком Ардуино“».
Спасибо за замечание, учту. Я не подозревал, что настолько болезненно воспримется мой сленг. Конечно, нет никакого языка Ардуино!
Какой большой структурированный код нужен для управления, допустим, кофеваркой? Кроме того, в посте я категорично нигде не утверждаю — Ассемблер и никаких вариантов. Понятие «оптимизация» у меня тоже встречается.
Не могу согласиться. Оплата работы программиста — ничто по сравнению с дополнительными потерями/прибылью при многотысячном… многомиллионном тираже товара.
Я меня только один совет: Вместо того, чтобы оттачивать свой многословный стиль изложения, зайти на Амперку, выбрать одну из многих нерешенных проблем с nRF24L01 и попытаться ее решить. Уверяю – пользы будет больше, притом, для всех.
Изначально все ваши претензии к моему коду можно было бы выразить несколькими словами: убери из кода строку setRetries(...) – она лишняя. Что, собственно, я уже давно сделал. Все!
А тут многословные монологи, достойные отдельного блога. О магических открытиях, светодиоде на плате Ардуино, таскании по квартире радиомодуля, на котором люди строят радиостанции и прочее, прочее…
github.com/makarenya/nrf24_examples/blob/master/nrf24_receiver.ino
Тут как раз пара передатчик-приёмник. Сделал специально под проверку
Я в растерянности — не знаю, что и думать, посмотрев коды вашей пары передатчик-приёмник на Гитхабе. Вернее, не могу понять причин ошибок в «примерах» — они от невнимательности, непонимания или чего то другого. Далее по порядку:
В скетче передатчика функция radio.stopListening(); — обязательна. Без этой функции (вкупе с другими) передатчик будет работать в полнофункциональном полудуплексном режиме. Я об этом дважды написал: набрал буковками «…затем один из пары работающих радиомодулей тестируется на работу в режиме передатчика без ожидания отклика с приемника (шаг 2) …» и в комментарии к функции в скетче: «radio.stopListening(); //радиоэфир не слушаем, только передача». Предполагаю, что ваша «неочевидная магия» тут цитирую: «radio.stopListening(); // Неочевидная магия» неочевидна и магия только для вас.
В скетче приемника тоже явная ошибка – не просчитан банальный сценарий, а именно: отсутствие питания приемника. Светодиод не моргает при инициализации и не горит в цикле. Это свидетельствует вроде о том, что радиомодуль инициализирован и по каким-то причинам не принят пакет с передатчика. На самом деле – нет питания. Поэтому, раз уж занялись переводом инфы скетча с монитора последовательного порта на светодиодную, советую добавить еще один светодиод – индикатор питания, аналог функции Serial.println(«ReceiverTester ON»); Кстати, почему в скетче передатчика не светодиодная индикация, а вывод инфы в монитор порта. Логики нет: в одном узле светодиоды, в другом – монитор порта Ардуино.
О оптимизации кода я молчу. Например, приемник работает 120 миллисекунд, а потом пауза на 100 мсек, что обозначить результат светодиодом. Получается, что приемник в работе 54 процента от всего времени. Время для приема 50 пакетов из 1000, а это реальная ситуация, будет заоблачным. Прикиньте сами. При этом не забудьте, что передатчик у вас работает с задержками в цикле 100 мсек, узлы не синхронизированы и учтите время на выполнение операций в цикле.
После просмотра ваших скетчей, понял, что надо более критично относиться к отдельным файлам из Гитхаба. Постарайтесь в ближайшее время что-то предпринять со своими «примерами» на Гитхабе, иначе мне придется зарегистрироваться и выложить нечто похожее там. Успехов!
Готов поспорить: размер кода > количество операций > энергопотребление. Ведь очевидно, что на две операции затраты меньше, чем, допустим, на 10 таких же. Что легче: вытащить 2 ведра воды из колодца или 10?
… к тому же не красивый проводок и где то установленная коробка с батарейками. жена не оценит такую красоту
Тоже есть варианты:
Красивый многожильный проводок. Плюс красивая коробочка для жены. Замечу, красивая коробочка — это работа посложнее. Эстетику разделения проводка на два — оставить на суд голубей.
По результатам своих наблюдений внести корректировку температуры в скетч и оставить только am2320.
Побороть недоверие, разобравшись в его причинах.
Продолжать гробить не дешевые аккумуляторы, оставив все как есть.
При этом датчики живут полгода — год на одном аккумуляторе легко. Все кроме уличного. Уличный кроме того что морозится так еще находится дальше всех от базы. С ним постоянные танцы. Если уличный питать батарейками — то мороз по ним бьет прямо сразу.
А почему бы не вывести за пределы помещения тонким кабелем только датчик ds18b20, а остальное оставить в помещении. В промышленных образцах реализовано именно такое решение.
Логично. Свой вывод уточнил.
Вы вырвали фразу мою фразу из контекста. «Внезапно» всплывает — это для Вас. Советую посмотреть мой пост хотя бы по диагонали. Там встроенный RC-генератор. Методика измерений характеристик тщательно продумана — для этого разработаны несколько вспомогательных скетчей и т.п. Никаких замечаний по поводу методики и результатов измерений не было.
«Блохи» я не ловлю, поскольку Ассемблера не знаю, а анализирую и сопоставляю то, что уже сделано, иногда компилируя коды составленные другими. Говорю о тенденциях. Грамотность проектирования системы (метеостанции) подтверждена «железом» и полученными техническими характеристиками. Недостатки проекта тоже знаю и их не замалчиваю.
Согласен! Но повторю ваши слова: «если планируется многомиллионный тираж достаточно сложного устройства ...». Вы правы — в таких случаях и подходы другие.
Тут в метеостанции у меня не плата Ардуино, а «голая» Atmega328P и кварц. Прототип делал для себя и добился поставленной цели: потребление устройства на уровне автономных промышленных продуктов.
Разговор начался давно. Почитайте комменты.
Побродите, пожалуйста, по форумам ремонтников бытовой техники. Я к тому же, в свою кофеварку заглядывал. Предположения и реалии — разные вещи.
Все это я давно прошел. Посмотрите, пожалуйста, тут. По ключевым словам «Операционное время функции измерений параметров воздуха, состояния батареек» найдите таблицу. В ней приведено время выполнения операций и потребление. Контроллер ждет и обрабатывает информацию с датчика 0,39 сек, а спит минуту.
Спасибо за замечание, учту. Я не подозревал, что настолько болезненно воспримется мой сленг. Конечно, нет никакого языка Ардуино!
Я меня только один совет: Вместо того, чтобы оттачивать свой многословный стиль изложения, зайти на Амперку, выбрать одну из многих нерешенных проблем с nRF24L01 и попытаться ее решить. Уверяю – пользы будет больше, притом, для всех.
Изначально все ваши претензии к моему коду можно было бы выразить несколькими словами: убери из кода строку setRetries(...) – она лишняя. Что, собственно, я уже давно сделал. Все!
А тут многословные монологи, достойные отдельного блога. О магических открытиях, светодиоде на плате Ардуино, таскании по квартире радиомодуля, на котором люди строят радиостанции и прочее, прочее…
Поэтому повторюсь -успехов!
Я в растерянности — не знаю, что и думать, посмотрев коды вашей пары передатчик-приёмник на Гитхабе. Вернее, не могу понять причин ошибок в «примерах» — они от невнимательности, непонимания или чего то другого. Далее по порядку:
После просмотра ваших скетчей, понял, что надо более критично относиться к отдельным файлам из Гитхаба. Постарайтесь в ближайшее время что-то предпринять со своими «примерами» на Гитхабе, иначе мне придется зарегистрироваться и выложить нечто похожее там. Успехов!
И неважно, как они выполняются — одним махом или не одним.
Тоже есть варианты:
А почему бы не вывести за пределы помещения тонким кабелем только датчик ds18b20, а остальное оставить в помещении. В промышленных образцах реализовано именно такое решение.