Я оказался неправильно понят, уточняю. Речь не идёт о чипах производства Atmel. Речь идёт об Arduino.
В комплексе, так сказать, с средой разработки и схемными решениями.
Ну бутерброд из шилдов скрученных изолентой, это наверно после ядреной травы может придуматься, а вот от среды разработки конечная работоспособность девайса думаю не зависит.
неужели найдётся такой чудак, который в серьёзном промышленном проекте (я имею в виду цену ошибки) будет использовать Arduino? По моему личному мнению - ничего сложнее стиральной машинки на ней делать нельзя.
Piskunov, просто объясните, чем среда разработки влияет на конечную работоспособность? Первые программы писали на рулоне туалетной бумаги, а после дыроколом прошивали и ведь работали)))).
И этот вопрос звучит от автора ТИТАНОВОГО ВЕЛОСИПЕДА???
Извините, без комментариев ))
э! не нужно мне тут славой вечно полупьяного ящиками Оболони радиомонтажника Клапауций 999 упрекать, который от скуки допился до класс титановый велосипед для тактовой кнопки.
я - Клапауций 321, в данный момент трезв и конкретен в желании получить комментарии на вопрос Клапауций 123: какие претензии к схемотехническим решениям плат дуино и Дуино ИДЕ у разработчиков серьёзных промышленных проектов?
Возьмем нижний уровень: notepad из Windows - писать код можно? Можно. Но не слишком удобно.
Возьмем notepad++: писать код уже получается быстрее, т.к. есть подсветка синтаксиса, т.е. оптимизация времени ошибок.
Возьмем Arduino IDE: писать получается еще быстрее, хоть по сути тот же notepad, но есть владки, подсветка и верификация компилятора.
Возьмем AVRstudio: добавляется еще куча плюшек по кодингу. Но чтобы понять их преимущество, надо некторое время посидеть на предыдущих вариантах.
Возьмем Proteus: добавляется моделирование схем, еще удобнее.
Для профи может быть и нет большой разницы, руки уже на автомате работают, а для новичка разница ощутима.
Возьмем нижний уровень: notepad из Windows - писать код можно? Можно. Но не слишком удобно.
Возьмем notepad++: писать код уже получается быстрее, т.к. есть подсветка синтаксиса, т.е. оптимизация времени ошибок.
Возьмем Arduino IDE: писать получается еще быстрее, хоть по сути тот же notepad, но есть владки, подсветка и верификация компилятора.
Возьмем AVRstudio: добавляется еще куча плюшек по кодингу. Но чтобы понять их преимущество, надо некторое время посидеть на предыдущих вариантах.
Возьмем Proteus: добавляется моделирование схем, еще удобнее.
Для профи может быть и нет большой разницы, руки уже на автомате работают, а для новичка разница ощутима.
это ты о комфорте, а не о принципиальных ограничениях.
Tomasina, вопрос стоял о конечной работоспособности устройства, а не удобстве разработки. Ведь программе то без разницы, в каком редакторе ее написали и отладили.)))))
Tomasina, вопрос стоял о конечной работоспособности устройства, а не удобстве разработки. Ведь программе то без разницы, в каком редакторе ее написали и отладили.)))))
Как бы да, но сюда бы ещё добавить "в разумные сроки".
неужели найдётся такой чудак, который в серьёзном промышленном проекте (я имею в виду цену ошибки) будет использовать Arduino? По моему личному мнению - ничего сложнее стиральной машинки на ней делать нельзя.
"Если вы разбираетесь в электронике, то некоторые технические решения, описанные в этой статье повергнут вас в шок и ужас, а также вызовут непреодолимое желание оторвать автору руки."
есть часть кода где кнопками задается значение, 1 кнопка плюсует, 2 кнопка вычитает. После каждого нажатия идет проверка, не привысило ли число максимально или минимально допустимого. я сначала не знал про функцию constrain() и писал так:
if (b_1.click_down)
{
x+=1;
if (x>xmax)x=xmax;
}
if (b_2.click_down)
{
x-=1;
if (x<xmin)x=xmin;
}
но потом узнал про constrain() и стал писать
if (b_1.click_down)
{x+=1;
constrain(x,xmin,xmax);
}
if(b_2.click_down)
{x-=1;
constrain(x,xmin,xmax)
}
Так получается в первом случае код оптимальнее, так как идет одно сравнение вместо 2-х во втором случае, так?
Так получается в первом случае код оптимальнее, так как идет одно сравнение вместо 2-х во втором случае, так?
Mr.Privet, самое главное и самое важное, что должен вынести любой начинающий из этого топика, это не срач и фаллометрию в которую он выродился, а подход к "добыче знаний" из первого поста.
Вот сейчас, Вам нужно сделать следующее:
1. Написал скетчик по образу и подобию скетчиков из первого поста
2. Запустил оба свои варианта. чтобы выполнились по 10 тыс. раз.
3. Сравнил время.
4. Гордо написал сюда новую, собственноручно добытую, информацию (вместо того, чтобы спрашивать как ребёнок у больших дядек).
Цитирую: "Arduino – это инструмент для проектирования электронных устройств (электронный конструктор) более плотно взаимодействующих с окружающей физической средой, чем стандартные персональные компьютеры, которые фактически не выходят за рамки виртуальности."
Заметьте, ни слова о создании на его основе готовых устройств.
Цитирую: "Arduino – это инструмент для проектирования электронных устройств (электронный конструктор) более плотно взаимодействующих с окружающей физической средой, чем стандартные персональные компьютеры, которые фактически не выходят за рамки виртуальности."
Заметьте, ни слова о создании на его основе готовых устройств.
Да, читал.
И полностью с Вами согласен, это конструктор. Наверное самый интересный из тех, которые у меня были ))
Но после прочтения этой темы у меня появилось стойкое подозрение, что кто-то пытается делать готовые устройства. Вот и спросил...
Все прочитал. Вынес некоторые полезные вещи для. Собственно, Господа, а из-за чего весь сыр бор? Понятно же оптимизации можно проводить разными путями при решении определенной задачи и имея определенное железо. Не влезаем с определенным инструментом в определенное железо, можно попробовать другой инструмент. Не хватает скорости опять пробуем разные подходы. Если все работает и с нужной скоростью, безглючностью и надежностью - всё проект закрыт, все радуются и никто не ломает голову над оптимизацией. Есть свободное время взял и уменьшил допустим код на 30 процентов. Похвалил себя и остался доволен. Потренеровал что называется голову, чтоб содержимое не усохло. Короче тут все правы.
Господа, я собственно чего приходил. Поскольку я начинающий то хотел бы испросить совета по оптимизации алгоритма. Правда это как раз из серии "чтобы содержимое головы не усохло".
Пишу код для ардуино. Есть десять неких датчиков с аналоговым выходом. К устройству может быть подключен только 1 датчик, но оно должно уметь работать со всеми типами датчиков из этого десятка. Формула обсчета для каждого датчика индивидуальна для получения результата. Т.е. снимается выходное напряжение и обсчитывается по уникальной формуле для каждого типа датчика. Самое главное, нет горячего подключния или замены датчиков. Т.е. на этапе выполения setup точно становится известно какой датчик подключен к контроллеру. Естественно напиана вызываемая процедура в которую в качестве аргументов передаются напряжение и тип датчика. Она же выдает конечный результат. Понятно, что процедура содержит описания для всех поддерживаемых датчиков. Короче каждый раз когда вызывается эта функция она каждый раз проходится (в худшем случае) по всем десяти выриантам, выбирая нужную формулу по типу датчика.
Отсюда вопрос. Т.к. известно что во время работы тип датчика уже не изменится, то может быть можно как-то по другому написать процедуру, чтобы процессор каждый раз не делал кучу бесполезных сравнений - если тип 1 делаем то, если тип 2 делает то и тд.
Отсюда вопрос. Т.к. известно что во время работы тип датчика уже не изменится, то может быть можно как-то по другому написать процедуру, чтобы процессор каждый раз не делал кучу бесполезных сравнений - если тип 1 делаем то, если тип 2 делает то и тд. Если есть идеи буду рад впитать.
Правильный вопрос содержит ответ. Там где можно (это известно только Вам) определяем тип датчика (записываем в переменную), а далее как у Вас и написано "если тип 1 делаем то, если тип 2 делает то и тд.", т.е. анализируем состояние переменной и выполняем нужный расчет. Это может быть в setup, а может быть и в loop. В любом случае, пока неизвестен тип, ничего не делаем (точнее определяем этот тип).
т.е. анализируем состояние переменной и выполняем нужный расчет.
Так у него так и сделано.
Оптимизируем так: пишем для каждого датчика свою, отдельную функцию расчета, но с одинаковым интерфейсом, обявляем переменную - указатель на функцию, в сетапе эту переменную инициализируем указателем на одну из функций расчета, вызов делаем через эту переменную.
т.е. анализируем состояние переменной и выполняем нужный расчет.
Так у него так и сделано.
???. Цитирую автора "Короче каждый раз когда вызывается эта функция она каждый раз проходится (в худшем случае) по всем десяти выриантам, выбирая нужную формулу по типу датчика.". Вообще задача расписана так, что можно понять как угодно. Это нужно в отдельной теме разбираться и формулировать задачу более корректно с выкладыванием скетча. А так - пустой треп.
т.е. анализируем состояние переменной и выполняем нужный расчет.
Я отталкивался от:
"Т.е. на этапе выполения setup точно становится известно какой датчик подключен к контроллеру. Естественно напиана вызываемая процедура в которую в качестве аргументов передаются напряжение и тип датчика."
А в функции уже варианты реализации.
Допишу сообщение о подходах.
Можна сделать так же через классы. Базовый с виртуальной функцией расчета и наследники для каждого датчика свой класс. В сетапе динамически создаем обект класса, соответствующего датчику и присваиваем указатель на него переменной типа базового класса. Вызываем через эту переменную. Этот фокус - сама суть ООП.
В Вашей ситуации я бы не трогал код. Работает - не трогай! Выиграш небольшой. Если сильно чешится - первый подход лучше. Если писать заново код, я бы именно так и писал.
Давным-давно Ваш подход считали типичным для новичков, первый подход - признак профи. Потом появился второй подход, с ООП, и все смешалось ))
Спасибо. В общем-то я так и думал. Однако, действительно вопрос в том насколько такой подход будет эффективным, например в плане скорости. Что-то сдается мне, что контроллер выполнит 9 "лишних" сравнений if ооочень быстро.
Спасибо. В общем-то я так и думал. Однако, действительно вопрос в том насколько такой подход будет эффективным, например в плане скорости. Что-то сдается мне, что контроллер выполнит 9 "лишних" сравнений if ооочень быстро.
Спасибо. В общем-то я так и думал. Однако, действительно вопрос в том насколько такой подход будет эффективным, например в плане скорости. Что-то сдается мне, что контроллер выполнит 9 "лишних" сравнений if ооочень быстро.
Ну, этих IF'ов, как Вам тут совершенно правильно сказали, Вы и не заметите.
Но если хочется поэстетствовать, можно и поэстетствовать. Типы датчиков занумеруйте от 0 до 9 (если их 10), заведите массив указателей на функции (например pF[10]) так, чтобы pF[0] - указывал на обработчик для нулевого датчика, pF[1] - для первого и т.д. Как только Вы определили номер датчика (допустим. sensorIndex), тут же просто вызываетя pF[sensorIndex](<параметры>). А если она вызывается часто, так можно и индекс каждый раз не вычислять, заведите такой же указатель pFM и присвойте ему pFM = pF[sensorIndex]. А впредь используйте pFM(<параметры>)
Но я бы делал совсем не так. Так как я предлагаю - по эффективности хуже, чем у Вас, но по коду красивее и яснее. Потеря эффективности опять же - не особо заметите.
Я бы сделал общий класс. содержащий ВСЮ общую, независящую от типа датчика работу. А от него пронаследовал бы 10 классов, которые содержат только один метод - завиящую от датчика обработку. Затем, определив тип датчика, просто создавал бы переменную нужного класса и вся обработка была бы везде одинаковой и прозрачной.
Все прочитал. Вынес некоторые полезные вещи для. ... Поскольку я начинающий то хотел бы испросить совета по оптимизации алгоритма. ... Есть десять неких датчиков с аналоговым выходом. К устройству может быть подключен только 1 датчик, но оно должно уметь работать со всеми типами датчиков из этого десятка. Формула обсчета для каждого [типа] датчика индивидуальна для получения результата. Т.е. снимается выходное напряжение и обсчитывается по уникальной формуле для каждого типа датчика. Самое главное, нет горячего подключния или замены датчиков. Т.е. на этапе выполения setup точно становится известно какой датчик подключен к контроллеру ... Если есть идеи буду рад впитать.
Выделил главное из вашего текста. Так вот, "на этапе setup()" означает, что вы сделали либу, которая способна обслуживать несколько типов железок, и какая конкретно подключается - определяется юзвером вашей либы. Что втыкнул - то и должно скомпиляться. Вас беспокоит влезание в скетч всех остальных алгоритмов обработки датчиков, в ситуации когда они заведомо не требуются.
Решение: вынести выбор алгоритма на этап ДО компиляции скетча.
Вариант 1 (традиционное С): требуете перед использованием вашей либы определить константу препроцессора #define тип_датчика_юзверя, и с помощью которой обрамляете код либы условной компиляцией #ifdef #elif #endif Для примера загляните в типовой io.h и его дочерние иклудящиеся файлы. Разница в том, что тип процессора там задан Ардуино ИДЕ "автоматически".
Как сделать, чтобы эта константа "сработала" в отдельном файле кода библиотеки? Тут - никак. Можно включить условно-компилирующийся код в заголовочный файл. Рояли не играет где его найдет компилятор при грамотной блокировке повторного включения - тоже типовые решения.
Вариант 2 ( С++ ): перелопачиваете свою либу в TEMPLATE, настраивающийся типом датчика и в коде либы делаете .. туже самую "условную компиляцию", но уже средставми языка С++ (см. реализация шаблонной функции/метода класса). Всё. Комплитор сам откомпиляет вашу функцию/метод строго согласно указанному типу при создании объекта в setup().
1. Все они тянут за собой ВЕСЬ код ВСЕХ обработок всех типов датчиков в КАЖДЫЙ скетч.
2. Вариант с указателями на функцию типа датчика - самый скоростной, но дополнительно (к моему) будет делать косвенный вызов вместо простого. потеря 1-2 десятков тактов и 10-20 байт кода на каждый вызов. Если их немного, то может и "пофиг";
3. Вариант с виртуальными функциями, дополнительно к 2, потянет за собой ещё и отображение виртуальных таблиц на память, как тут обсуждалось выше .. то есть это ещё и потеря памяти;
4. Вариант с созданием нескольких классов и динамического создания экземпляра нужного класса - может повлечь за собой косвенный доступ к многим функциям этого класса (его тип определен динамически) .. то есть, это может оказаться даже хуже варианта 1.
.. но пробуйте. Опыт - лучший критерий истины. Я ещё сильно не присматривался к особенностям компиляции С++ кодов.
Если скетч прошит единожды, а юзверь способен выключить ардуинку, переткнуть датчик и попытаться запустить снова, то "на этапе setup()" может означать только:
Датчик подключается к другим пинам (или "зажата кнопка перед включением"), и в setup() можно опросить какой именно датчик теперь подключен к ТОМУ ЖЕ САМОМУ СКЕТЧУ.
Этого варианта нет в озвученном ТЗ, а сам по себе он достаточно неочевиден.
Если скетч прошит единожды, а юзверь способен выключить ардуинку, переткнуть датчик и попытаться запустить снова, то "на этапе setup()" может означать только:
Датчик подключается к другим пинам (или "зажата кнопка перед включением"), и в setup() можно опросить какой именно датчик теперь подключен к ТОМУ ЖЕ САМОМУ СКЕТЧУ.
Этого варианта нет в озвученном ТЗ, а сам по себе он достаточно неочевиден.
"Есть десять неких датчиков с аналоговым выходом. К устройству может быть подключен только 1 датчик, но оно должно уметь работать со всеми типами датчиков из этого десятка."
Не. то что предложил Arhat109-2 если я правильно понимаю это условная компиляция. Это хорошо когда контоллер должен в будущем работать только с одним типом датчика, а датчиков 10 типов. Тогда не надо делать черте сколько разных прошивок (при наличии естественно при заливке всех типов датчиков или их эмуляторов).
Не прокатит. Фишка в том, что устройство универсальное, способное работать со всеми типами датчиков. Но вход под датчик у устройства только один. Нет горячей замены. Т.е. когда крутится loop к устройству не подключат другой датчик, выдернув предыдущий.
Корче на одной установке данное устройство рабоет допустим с датчиком типа 4 а на рядом стоящей установке такое же устройство работает с датчиком тип 8.
Если к одному и тому же устройству надо подключить другой датчик, то снимается питание с контроллера.
Сами датчики оборудованы идентификационными резисторами. Так собственно и определяется в SETUP тип датчика. И он уже не изменяется пока контроллер не выключат и допустим не подключат к нем другой тип датчика (контроллер перенесли на другую установку с другим типом датчиков).
Собственно меня просто интересовало можно ли в принципе уйти от множественной проверки IF. т.е. когда процедура калькуляции результата ищет нужную формулу обработки по известному типу датчика, который нифига не меняется. Результат - можно. Смогу себя похвалить за красивость и вообще, что я крут, но скорее всего не будет ни экономии памяти, ни ускорения.
А в лоб с If-ами вроде как-то сосет под ложечкой, но результат не ухудшает ни в скорости ни скорее всего в потребляемой памяти.
И еще, господа. Про использование глобальных и локальных переменных. ОЧЕНЬ важная тема и мне кажется подход можно формализовать. Если Вы как знающие програмисты задумаетесь на эту тему. Естественно применительно к конкретной платформе. Иначе формального подхода и рекомендаций не получится - в этом я уверен.
определение типа датчика
на разъём со стороны датчика повесить резистивный делитель , для каждого типа датчика - свой номинал
со стороны ардуины - на аналоговый пин и в сетапе определять что за датчик подключен
а коды для каждого типа ардуина должна знать
Вы совершенно правы. Нельзя, но только при определении самого типа датчика, тут без вариантов.
А вот выборку формулы обработки сигнала по известному типу датчика по ходу можно. Товарищи вот тут подсказали как для универсального так и для не универсального устройства.
Ok.
Я оказался неправильно понят, уточняю. Речь не идёт о чипах производства Atmel. Речь идёт об Arduino.
В комплексе, так сказать, с средой разработки и схемными решениями.
а, в чём проблема со схемными решениями и средой разработки?
Ok.
Я оказался неправильно понят, уточняю. Речь не идёт о чипах производства Atmel. Речь идёт об Arduino.
В комплексе, так сказать, с средой разработки и схемными решениями.
Ну бутерброд из шилдов скрученных изолентой, это наверно после ядреной травы может придуматься, а вот от среды разработки конечная работоспособность девайса думаю не зависит.
а каждый Программист мог бы спасти одного и более ДУМАЮЩЕГО начинающего......
от чего спасти?
Извините, что не сослался на автора SMS-ки. Как пришло, так и отписал. Arhat-109-2 похоже вчера приболел и не сможет отвечать вам какое-то время.
а, в чём проблема со схемными решениями и средой разработки?
И этот вопрос звучит от автора ТИТАНОВОГО ВЕЛОСИПЕДА???
Извините, без комментариев ))
http://geektimes.ru/post/258540/
Piskunov, просто объясните, чем среда разработки влияет на конечную работоспособность? Первые программы писали на рулоне туалетной бумаги, а после дыроколом прошивали и ведь работали)))).
И этот вопрос звучит от автора ТИТАНОВОГО ВЕЛОСИПЕДА???
Извините, без комментариев ))
э! не нужно мне тут славой вечно полупьяного ящиками Оболони радиомонтажника Клапауций 999 упрекать, который от скуки допился до класс титановый велосипед для тактовой кнопки.
я - Клапауций 321, в данный момент трезв и конкретен в желании получить комментарии на вопрос Клапауций 123: какие претензии к схемотехническим решениям плат дуино и Дуино ИДЕ у разработчиков серьёзных промышленных проектов?
bwn, а разве не влияет?
Возьмем нижний уровень: notepad из Windows - писать код можно? Можно. Но не слишком удобно.
Возьмем notepad++: писать код уже получается быстрее, т.к. есть подсветка синтаксиса, т.е. оптимизация времени ошибок.
Возьмем Arduino IDE: писать получается еще быстрее, хоть по сути тот же notepad, но есть владки, подсветка и верификация компилятора.
Возьмем AVRstudio: добавляется еще куча плюшек по кодингу. Но чтобы понять их преимущество, надо некторое время посидеть на предыдущих вариантах.
Возьмем Proteus: добавляется моделирование схем, еще удобнее.
Для профи может быть и нет большой разницы, руки уже на автомате работают, а для новичка разница ощутима.
bwn, а разве не влияет?
Возьмем нижний уровень: notepad из Windows - писать код можно? Можно. Но не слишком удобно.
Возьмем notepad++: писать код уже получается быстрее, т.к. есть подсветка синтаксиса, т.е. оптимизация времени ошибок.
Возьмем Arduino IDE: писать получается еще быстрее, хоть по сути тот же notepad, но есть владки, подсветка и верификация компилятора.
Возьмем AVRstudio: добавляется еще куча плюшек по кодингу. Но чтобы понять их преимущество, надо некторое время посидеть на предыдущих вариантах.
Возьмем Proteus: добавляется моделирование схем, еще удобнее.
Для профи может быть и нет большой разницы, руки уже на автомате работают, а для новичка разница ощутима.
это ты о комфорте, а не о принципиальных ограничениях.
Tomasina, вопрос стоял о конечной работоспособности устройства, а не удобстве разработки. Ведь программе то без разницы, в каком редакторе ее написали и отладили.)))))
Tomasina, вопрос стоял о конечной работоспособности устройства, а не удобстве разработки. Ведь программе то без разницы, в каком редакторе ее написали и отладили.)))))
Как бы да, но сюда бы ещё добавить "в разумные сроки".
http://geektimes.ru/post/258540/
Точняк. ))
Особенно мне понравилась первая фраза. Цитирую:
"Если вы разбираетесь в электронике, то некоторые технические решения, описанные в этой статье повергнут вас в шок и ужас, а также вызовут непреодолимое желание оторвать автору руки."
К вопросу оптимизации кода:
есть часть кода где кнопками задается значение, 1 кнопка плюсует, 2 кнопка вычитает. После каждого нажатия идет проверка, не привысило ли число максимально или минимально допустимого. я сначала не знал про функцию constrain() и писал так:
if (b_1.click_down) { x+=1; if (x>xmax)x=xmax; } if (b_2.click_down) { x-=1; if (x<xmin)x=xmin; }но потом узнал про constrain() и стал писать
if (b_1.click_down) {x+=1; constrain(x,xmin,xmax); } if(b_2.click_down) {x-=1; constrain(x,xmin,xmax) }Так получается в первом случае код оптимальнее, так как идет одно сравнение вместо 2-х во втором случае, так?
Так получается в первом случае код оптимальнее, так как идет одно сравнение вместо 2-х во втором случае, так?
Mr.Privet, самое главное и самое важное, что должен вынести любой начинающий из этого топика, это не срач и фаллометрию в которую он выродился, а подход к "добыче знаний" из первого поста.
Вот сейчас, Вам нужно сделать следующее:
1. Написал скетчик по образу и подобию скетчиков из первого поста
2. Запустил оба свои варианта. чтобы выполнились по 10 тыс. раз.
3. Сравнил время.
4. Гордо написал сюда новую, собственноручно добытую, информацию (вместо того, чтобы спрашивать как ребёнок у больших дядек).
Понимаете о чём я?
Точняк. ))
ты не дохлых котят по инетам собирай, а расскажи #161 чем отличается стиральная машина от коллайдера?
ты не дохлых котят по инетам собирай, а расскажи #161 чем отличается стиральная машина от коллайдера?
Ты глазки-то разуй, и #151 прочти. Я - новичок...
Piskunov, если новичек, то наверняка читали "Что такое Ардуино".
Цитирую: "Arduino – это инструмент для проектирования электронных устройств (электронный конструктор) более плотно взаимодействующих с окружающей физической средой, чем стандартные персональные компьютеры, которые фактически не выходят за рамки виртуальности."
Заметьте, ни слова о создании на его основе готовых устройств.
Ты глазки-то разуй, и #151 прочти. Я - новичок...
блин. в каком же вас инкубаторе делают? - каждый десятый дятел: страсте - я новичок-дурачок.
Piskunov, если новичек, то наверняка читали "Что такое Ардуино".
Цитирую: "Arduino – это инструмент для проектирования электронных устройств (электронный конструктор) более плотно взаимодействующих с окружающей физической средой, чем стандартные персональные компьютеры, которые фактически не выходят за рамки виртуальности."
Заметьте, ни слова о создании на его основе готовых устройств.
Да, читал.
И полностью с Вами согласен, это конструктор. Наверное самый интересный из тех, которые у меня были ))
Но после прочтения этой темы у меня появилось стойкое подозрение, что кто-то пытается делать готовые устройства. Вот и спросил...
блин. в каком же вас инкубаторе делают? - каждый десятый дятел: страсте - я новичок-дурачок.
Собственно из тех же ворот, что и весь народ.
А дурачкам проще живётся. Ты ведь тоже в этом убедился?
Я оказался неправильно понят, уточняю. Речь не идёт о чипах производства Atmel. Речь идёт об Arduino.
Arduino кроме чипа Atmel содержит USB-интерфейс и преобразователь напряжения.
Вариант Arduino только на одном чипе Atmega 328:
http://www.youtube.com/watch?v=joSc-AT8o5k
http://www.youtube.com/watch?v=W4LPlKKb__8
http://www.youtube.com/watch?v=VIf1WJrF8Hc
http://www.youtube.com/watch?v=wuEzIKybvXw
http://www.youtube.com/watch?v=HJH6j9JJkSM
А дурачкам проще живётся. Ты ведь тоже в этом убедился?
я в этом убеждаюсь ежедневно - дурачки дохнут в расцвете сил.
Этюды для начинающего штукатура выходят на новый уровень обсуждения - "Самдурак".
Этюды для начинающего штукатура выходят на новый уровень обсуждения - "Самдурак".
"Никогда такого не было, и вот опять :("
Все прочитал. Вынес некоторые полезные вещи для. Собственно, Господа, а из-за чего весь сыр бор? Понятно же оптимизации можно проводить разными путями при решении определенной задачи и имея определенное железо. Не влезаем с определенным инструментом в определенное железо, можно попробовать другой инструмент. Не хватает скорости опять пробуем разные подходы. Если все работает и с нужной скоростью, безглючностью и надежностью - всё проект закрыт, все радуются и никто не ломает голову над оптимизацией. Есть свободное время взял и уменьшил допустим код на 30 процентов. Похвалил себя и остался доволен. Потренеровал что называется голову, чтоб содержимое не усохло. Короче тут все правы.
Господа, я собственно чего приходил. Поскольку я начинающий то хотел бы испросить совета по оптимизации алгоритма. Правда это как раз из серии "чтобы содержимое головы не усохло".
Пишу код для ардуино. Есть десять неких датчиков с аналоговым выходом. К устройству может быть подключен только 1 датчик, но оно должно уметь работать со всеми типами датчиков из этого десятка. Формула обсчета для каждого датчика индивидуальна для получения результата. Т.е. снимается выходное напряжение и обсчитывается по уникальной формуле для каждого типа датчика. Самое главное, нет горячего подключния или замены датчиков. Т.е. на этапе выполения setup точно становится известно какой датчик подключен к контроллеру. Естественно напиана вызываемая процедура в которую в качестве аргументов передаются напряжение и тип датчика. Она же выдает конечный результат. Понятно, что процедура содержит описания для всех поддерживаемых датчиков. Короче каждый раз когда вызывается эта функция она каждый раз проходится (в худшем случае) по всем десяти выриантам, выбирая нужную формулу по типу датчика.
Отсюда вопрос. Т.к. известно что во время работы тип датчика уже не изменится, то может быть можно как-то по другому написать процедуру, чтобы процессор каждый раз не делал кучу бесполезных сравнений - если тип 1 делаем то, если тип 2 делает то и тд.
Если есть идеи буду рад впитать.
На этапе сетапа присвоить номер признака датчика и отталкиваться от него.
Пардон, у вас вроде это и сделано.
Правильный вопрос содержит ответ. Там где можно (это известно только Вам) определяем тип датчика (записываем в переменную), а далее как у Вас и написано "если тип 1 делаем то, если тип 2 делает то и тд.", т.е. анализируем состояние переменной и выполняем нужный расчет. Это может быть в setup, а может быть и в loop. В любом случае, пока неизвестен тип, ничего не делаем (точнее определяем этот тип).
т.е. анализируем состояние переменной и выполняем нужный расчет.
Так у него так и сделано.
Оптимизируем так: пишем для каждого датчика свою, отдельную функцию расчета, но с одинаковым интерфейсом, обявляем переменную - указатель на функцию, в сетапе эту переменную инициализируем указателем на одну из функций расчета, вызов делаем через эту переменную.
т.е. анализируем состояние переменной и выполняем нужный расчет.
Так у него так и сделано.
???. Цитирую автора "Короче каждый раз когда вызывается эта функция она каждый раз проходится (в худшем случае) по всем десяти выриантам, выбирая нужную формулу по типу датчика.". Вообще задача расписана так, что можно понять как угодно. Это нужно в отдельной теме разбираться и формулировать задачу более корректно с выкладыванием скетча. А так - пустой треп.
т.е. анализируем состояние переменной и выполняем нужный расчет.
Я отталкивался от:
"Т.е. на этапе выполения setup точно становится известно какой датчик подключен к контроллеру. Естественно напиана вызываемая процедура в которую в качестве аргументов передаются напряжение и тип датчика."
А в функции уже варианты реализации.
Допишу сообщение о подходах.
Можна сделать так же через классы. Базовый с виртуальной функцией расчета и наследники для каждого датчика свой класс. В сетапе динамически создаем обект класса, соответствующего датчику и присваиваем указатель на него переменной типа базового класса. Вызываем через эту переменную. Этот фокус - сама суть ООП.
В Вашей ситуации я бы не трогал код. Работает - не трогай! Выиграш небольшой. Если сильно чешится - первый подход лучше. Если писать заново код, я бы именно так и писал.
Давным-давно Ваш подход считали типичным для новичков, первый подход - признак профи. Потом появился второй подход, с ООП, и все смешалось ))
Спасибо. В общем-то я так и думал. Однако, действительно вопрос в том насколько такой подход будет эффективным, например в плане скорости. Что-то сдается мне, что контроллер выполнит 9 "лишних" сравнений if ооочень быстро.
В 99% проектов, думаю даже не заметите этих ифов.
Ну, этих IF'ов, как Вам тут совершенно правильно сказали, Вы и не заметите.
Но если хочется поэстетствовать, можно и поэстетствовать. Типы датчиков занумеруйте от 0 до 9 (если их 10), заведите массив указателей на функции (например pF[10]) так, чтобы pF[0] - указывал на обработчик для нулевого датчика, pF[1] - для первого и т.д. Как только Вы определили номер датчика (допустим. sensorIndex), тут же просто вызываетя pF[sensorIndex](<параметры>). А если она вызывается часто, так можно и индекс каждый раз не вычислять, заведите такой же указатель pFM и присвойте ему pFM = pF[sensorIndex]. А впредь используйте pFM(<параметры>)
Но я бы делал совсем не так. Так как я предлагаю - по эффективности хуже, чем у Вас, но по коду красивее и яснее. Потеря эффективности опять же - не особо заметите.
Я бы сделал общий класс. содержащий ВСЮ общую, независящую от типа датчика работу. А от него пронаследовал бы 10 классов, которые содержат только один метод - завиящую от датчика обработку. Затем, определив тип датчика, просто создавал бы переменную нужного класса и вся обработка была бы везде одинаковой и прозрачной.
Выделил главное из вашего текста. Так вот, "на этапе setup()" означает, что вы сделали либу, которая способна обслуживать несколько типов железок, и какая конкретно подключается - определяется юзвером вашей либы. Что втыкнул - то и должно скомпиляться. Вас беспокоит влезание в скетч всех остальных алгоритмов обработки датчиков, в ситуации когда они заведомо не требуются.
Решение: вынести выбор алгоритма на этап ДО компиляции скетча.
Вариант 1 (традиционное С): требуете перед использованием вашей либы определить константу препроцессора #define тип_датчика_юзверя, и с помощью которой обрамляете код либы условной компиляцией #ifdef #elif #endif Для примера загляните в типовой io.h и его дочерние иклудящиеся файлы. Разница в том, что тип процессора там задан Ардуино ИДЕ "автоматически".
Как сделать, чтобы эта константа "сработала" в отдельном файле кода библиотеки? Тут - никак. Можно включить условно-компилирующийся код в заголовочный файл. Рояли не играет где его найдет компилятор при грамотной блокировке повторного включения - тоже типовые решения.
Вариант 2 ( С++ ): перелопачиваете свою либу в TEMPLATE, настраивающийся типом датчика и в коде либы делаете .. туже самую "условную компиляцию", но уже средставми языка С++ (см. реализация шаблонной функции/метода класса). Всё. Комплитор сам откомпиляет вашу функцию/метод строго согласно указанному типу при создании объекта в setup().
Оно? :)
Озвученные тут все предыдущие варианты - ХУЖЕ.
1. Все они тянут за собой ВЕСЬ код ВСЕХ обработок всех типов датчиков в КАЖДЫЙ скетч.
2. Вариант с указателями на функцию типа датчика - самый скоростной, но дополнительно (к моему) будет делать косвенный вызов вместо простого. потеря 1-2 десятков тактов и 10-20 байт кода на каждый вызов. Если их немного, то может и "пофиг";
3. Вариант с виртуальными функциями, дополнительно к 2, потянет за собой ещё и отображение виртуальных таблиц на память, как тут обсуждалось выше .. то есть это ещё и потеря памяти;
4. Вариант с созданием нескольких классов и динамического создания экземпляра нужного класса - может повлечь за собой косвенный доступ к многим функциям этого класса (его тип определен динамически) .. то есть, это может оказаться даже хуже варианта 1.
.. но пробуйте. Опыт - лучший критерий истины. Я ещё сильно не присматривался к особенностям компиляции С++ кодов.
Насколько я понял Seva1800, решение "ДО компиляции скетча" для него не вариант. Если это действительно так, то тянуть все коды всё равно придётся.
Если скетч прошит единожды, а юзверь способен выключить ардуинку, переткнуть датчик и попытаться запустить снова, то "на этапе setup()" может означать только:
Датчик подключается к другим пинам (или "зажата кнопка перед включением"), и в setup() можно опросить какой именно датчик теперь подключен к ТОМУ ЖЕ САМОМУ СКЕТЧУ.
Этого варианта нет в озвученном ТЗ, а сам по себе он достаточно неочевиден.
Если скетч прошит единожды, а юзверь способен выключить ардуинку, переткнуть датчик и попытаться запустить снова, то "на этапе setup()" может означать только:
Датчик подключается к другим пинам (или "зажата кнопка перед включением"), и в setup() можно опросить какой именно датчик теперь подключен к ТОМУ ЖЕ САМОМУ СКЕТЧУ.
Этого варианта нет в озвученном ТЗ, а сам по себе он достаточно неочевиден.
"Есть десять неких датчиков с аналоговым выходом. К устройству может быть подключен только 1 датчик, но оно должно уметь работать со всеми типами датчиков из этого десятка."
Не. то что предложил Arhat109-2 если я правильно понимаю это условная компиляция. Это хорошо когда контоллер должен в будущем работать только с одним типом датчика, а датчиков 10 типов. Тогда не надо делать черте сколько разных прошивок (при наличии естественно при заливке всех типов датчиков или их эмуляторов).
Не прокатит. Фишка в том, что устройство универсальное, способное работать со всеми типами датчиков. Но вход под датчик у устройства только один. Нет горячей замены. Т.е. когда крутится loop к устройству не подключат другой датчик, выдернув предыдущий.
Корче на одной установке данное устройство рабоет допустим с датчиком типа 4 а на рядом стоящей установке такое же устройство работает с датчиком тип 8.
Если к одному и тому же устройству надо подключить другой датчик, то снимается питание с контроллера.
Сами датчики оборудованы идентификационными резисторами. Так собственно и определяется в SETUP тип датчика. И он уже не изменяется пока контроллер не выключат и допустим не подключат к нем другой тип датчика (контроллер перенесли на другую установку с другим типом датчиков).
Собственно меня просто интересовало можно ли в принципе уйти от множественной проверки IF. т.е. когда процедура калькуляции результата ищет нужную формулу обработки по известному типу датчика, который нифига не меняется. Результат - можно. Смогу себя похвалить за красивость и вообще, что я крут, но скорее всего не будет ни экономии памяти, ни ускорения.
А в лоб с If-ами вроде как-то сосет под ложечкой, но результат не ухудшает ни в скорости ни скорее всего в потребляемой памяти.
И еще, господа. Про использование глобальных и локальных переменных. ОЧЕНЬ важная тема и мне кажется подход можно формализовать. Если Вы как знающие програмисты задумаетесь на эту тему. Естественно применительно к конкретной платформе. Иначе формального подхода и рекомендаций не получится - в этом я уверен.
определение типа датчика
на разъём со стороны датчика повесить резистивный делитель , для каждого типа датчика - свой номинал
со стороны ардуины - на аналоговый пин и в сетапе определять что за датчик подключен
а коды для каждого типа ардуина должна знать
С этим все ОК. датчики оснащены идентификационными резисторами
понятно.... Сами датчики оборудованы идентификационными резисторами. Так собственно и определяется в SETUP тип датчика.
Собственно меня просто интересовало можно ли в принципе уйти от множественной проверки
нельзя... или IF , или CASE
а зачем универсальное устройство ?
не проще ли при выходе устройства перед заменой на новое залить в него код ОДНОГО нужного датчика ?
Вы совершенно правы. Нельзя, но только при определении самого типа датчика, тут без вариантов.
А вот выборку формулы обработки сигнала по известному типу датчика по ходу можно. Товарищи вот тут подсказали как для универсального так и для не универсального устройства.
Вся фишка в том что устройство должно быть универсальным.
Вся фишка в том что устройство должно быть универсальным.
полицейские ходят по двое почему ?
один умеет читать , второй - писАть...
Вся фишка в том что устройство должно быть универсальным.
устройство ещё не послало кредитора в пень и не объявило технический дефолт по его дурным претензиям? :D
Ребята, Вы напрасно ржете. Таких задач как эта вагон и маленькая тележка. )))