Pull to refresh

Comments 104

погружённые электроды и показания на основе проводимости среды, но это сразу отметалось, так как состав воды бы постоянно менялся вместе с проводимостью от добавляемых удобрений и растворения примесей из субстрата.

Вода в любом случае проводит, количество примесей тут не принципиально. Тут два состояния: электроды в воздухе, электроды в жидкости. Еще есть вариант с тремя электродами, это когда бак сливается до минимального уровня, потом включается насос и наполняет до максимального.

Система как-то реагирует на аварии — протечки?
Вода в любом случае проводит, количество примесей тут не принципиально. Тут два состояния: электроды в воздухе, электроды в жидкости.

Я так понимаю, датчик уровня на этом принципе, замеряет сопротивление между электродами, чем больше они погружены, тем меньше сопротивление. Но кривая будет разная, в зависимости от концентрации примесей.

Система как-то реагирует на аварии — протечки?

Лень победила, и я недоделал этот момент, хотя изначально считал его очень важным. Сейчас только останавливает работу и кричит, если перед очередным циклом оказывается слишком мало воды. Остальные ситуации не обрабатываются (пока). Как я уже писал, мотивация — серьёзная штука. После первой аварии код чудесным образом допишется.
Не думаю, что существуют датчики умеющие отличить доли Ома, изменившиеся при погружении в жидкость на разную глубину.

Классически это так:
image
ВУ — верхний уровень.
НУ — нижний уровень.
Ну вот пример того, что я видел на eBay. Насколько я понимаю, аналоговый выход пропорционален уровню погружения.

А доли Ома мерить не проблема, если абсолютная величина порядка долей Ома (то есть 0.1-0.5, а не 100.1-100.5). Например, включив измеряемое сопротивление в плечо моста с фиксированными сопротивлениями того же порядка, и в диагональ какой-нибудь операционный усилитель.

Да, судя описанию, изменение сопротивления между проводниками усиливается транзистором.

Может быть, если поделить измеряемые значения на несколько диапазонов, для компенсации проводимости, то можно получить аналог «железного» указателя уровня.
image
Сопротивление измерять бессмысленно — электроды могут вносить поправку из-за электрохимического потенциала… да и растворятся будут понемногу, если не позолоченные или из инертного материала.
Лучший способ измерения уровня — емкостной. Сенсоров только много надо будет. Но их преимущество — нет непосредственного контакта с водой.
Я вот тоже не до конца понимаю, на каком принципе работает этот датчик. Возможно, там как раз-таки измеряется не сопротивление, а ЭДС, возникающая между электродами, погруженными в электролит.

Вариант с ёмкостным датчиком я тоже рассматривал, но отбросил из-за возможной капризности, хотя уже начинаю жалеть, что не поэкспериметировал с этим. Ёмкость микроконтроллером померить несложно, например, включив ёмкость в задающий контур генератора, и замеряя его выходную частоту.
Это фигня. Так много не намеряешь. Лучше подавать фиксированную частоту на емкость сенсора через резистор. Он образует элементарный RC фильтр низких частот, когда емкость сенсора растёт меняется частота среза фильтра и резко падает амплитуда. Но и этот способ не идеален…
Можно просто заряжать емкость большим сопротивлением 100К-1М и измерять время необходимое на заряд емкости сенсора с нуля. Так работают практически ВСЕ реализации емкостных сенсоров и тач-панелей. Итого — нужен только один резистор на сенсор… иногда даже длительность заряда не нужно измерять — достаточно прочитать значение на порту сразу после переключения пина из состояния «выход, 0» в режим «вход» — этого достаточно чтобы зарегистрировать емкость сенсора в 10пФ, если больше — отложить операцию чтения парочкой NOP-ов.
Можно просто заряжать емкость большим сопротивлением 100К-1М и измерять время необходимое на заряд емкости сенсора с нуля.

Ну собственно, концептуально это ничем не отличается от включения того же сопротивления в задающую RC-цепь генератора. Время, нобходимое на заряд — это и есть часть периода генератора. Просто, вместо формирования импульса самому, они будут сами формироваться в генераторе.
В описании сенсора — полоски электродов посеребренные. Но лучше угольные электроды.
Серебро растворяется в воде, эти электроды видимо не предназначены для постоянного контакта с водой — так, поиграться только.
Еще кошернее взять золотые. Не так дорого можно поискать с гальванозолотом. Но дешевле всего, если не нужна точность измерения — графит для цанговых карандашей.

image
Если быть точным, то дешевле всего разобрать использованные батарейки — угольный стержень бесплатно.
Оно то бесплатно, но и столь же бесполезно. Сколько работы надо будет проделать, чтобы из угольного стерженька сделать электрод для измерителя уровня. А главное как их срастить с медным проводником, чтобы в последствии контакт с жидкостью имел только графит иначе всё это зря.
У графитного стрежня припрессован металлический колпачок "+" — к нему припаять, сам колпачок с проводом и местом пайки залить, например, эпоксидкой.
Ты смотри, не поленились даже фиксирующие винты позолотить…
Самая жепь это электролиз раствора. А идет он очень мощно даже при коротких импульсах. Очень. Там pH улетает и что только ни начинает плавать в растворе.
А почему бы не использовать пластиковую трубку с герконами и магнитом на поплавке? Просто, дешево и сердито.
Соли… всё обложат и в один прекрасный момент поплавок просто застрянет.
А электроды соли не не обложат?
Они не помешают работе электродов.
Ну не так уж просто — герконов надо много, потому что шкала трбуется с достаточно большим разрешением, чтобы как можно более точно обнаруживать, когда уровень воды начал понижаться или повышаться (да и вообще, хочется точно знать уровень). Каким-то образом всю эту кучу надо подключить к микроконтроллеру, желательно не тридцатью проводами. (Как вариант, можно сделать цепочку резисторов, и чтобы геркон или пара электродов, как предлагали выше, замыкали часть цепочки, и в итоге её общее сопротивление было пропорционально уровню жидкости. И дальше уже на АЦП мерить его.). Но всё-таки просто — это пара изолированных электродов, как в случае с ёмкостным датчиком (если, конечно, эта идея рабочая и такой датчик может выдавать надёжные показания).
чтобы отслеживать изменение уровня, а возможно и сам уровень, как вариант можно поставить датчик давления под сам бак, чтобы измерять изменение веса, либо положить его на дно бака :)
Разница уровней в 20см по жидкости… для измерения надо будет сильно бороться с помехами и влиянием температуры на датчик, да и дорогое вобщем-то выйдет решение и недостаточно точное.
У меня была такая идея, когда хотел делать с аквариумом. Но не под аквариум, а под такую мензурку рядом с ним, которая сообщается с ним через трубку по принципу сифона. Мне тогда казалось это простым и надёжным решением.
Там жёлтые светодиоды? Для растений они слабо подходят.
Смотрите тут, раздел светодиоды:
https://ru.wikipedia.org/wiki/Искусственное_освещение_растений
Да, я об этом тоже узнал, когда уже заказал «тёплые» белые (ну как же, они ведь почти как солнце :) ). Только потом включилась логика — если листья зелёные, значит зелёный цвет они отражают, а поглощают красный и синий. Но на самом деле это вопрос эффективности. Эти жёлтые (точнее тёплые белые, фотографии не очень хорошо получились) тоже подходят, просто больше энергии тратится впустую, отражаясь от листьев.
Проблема искусственного освещения растений несколько глубже. Была статья примерно год назад по поводу системы искусственного выращивания, там прозвучали утверждения что от соотношения цветовых составляющих изменяются разные аспекты роста растения — насколько быстро оно наберёт массу, насколько интенсивный будет вкус плодов и т.д.
Хоть красно-синее излучение и приводит к интенсивному росту растения, но плоды становятся безвкусными и водянистыми. Это хорошо для не плодоносящих: цветы, марихуана, конопля…
Насколько я понимаю, эта проблема стоит oстро, если выращиваемые растения получают только искусственное освещение, например, такие фермы. У меня же основное освещение — естесственное от окна, подсветка только для продливания светового дня, задумывалась для зимы. Не знаю, насколько вообще эта концепция рабочая, и даст ли какой-то толк, но мне кажется, что в такой ситуации спектральный состав освещения гораздо менее критичен (главное, конечно, чтоб не оказалось, что оно совсем бесполезно).
«Теплые» белые светодиоды тоже относительно неплохо — у них максимум приходится на красную часть спектра, поменьше не сине-фиолетовую и меньше всего как раз на зеленую.

Тут (слева внизу график) спектр плохеньких китайских светодиодов «теплого» класса:
lamptest.ru/images/graph/new-energy-led-corn-bulb-12w.png
Тут получше качеством тоже теплые (3000К)
lamptest.ru/images/graph/camelion-led10-a60-830-e27.png

Как ни странно чисто с точки зрения эффективности конвертации энергии — солнечный свет самый плохой вариант (т.к. в нем максимум приходится как раз на не усваиваемый растениями зеленый участок спектра). Он рулит только за счет своей огромной интенсивности — даже в облачный день интенсивность естественного солнечного света как минимум на порядок выше яркого искусственного.
Ну да, у меня в принципе все компоненты в сумме где-то на столько и наберутся, может даже немного поменьше.
OLED дисплей — это красиво, но недолговечно. За год яркость постоянно светящихся пикселей заметно снизится.
У меня тоже были такие подозрения, поэтому большую часть времени дисплей отключен. Он включается, если тронуть валкодер, и горит, пока с момента последних действий не пройдёт какой-то таймаут (минут 5 вроде поставлено). Добавлю в текст этот момент.
Дешевый и надежный датчик уровня жидкости — контактный с дискретными показаниями. Просто делается набор электродов разной длины на плате и выводится контактными площадками на разных уровнях. В зависимости от того, где коротит — там и вода. Не надо париться с электропроводностью.

Еще вариант — емкостный, но он более капризный.
А если просто сделать поплавок и соединить его вторым герметичным концом с реостатом? Он будет вверх вниз двигаться и менять сопротивление. Такую штуку можно легко собрать и достаточно точно откалибровать.
Это были первые мысли. Но есть вопросы к надёжности такого решения — любая механика увеличивает сложность и уменьшает надёжность (при этом оно может быть ещё и достаточно громоздким). Ещё из тех же соображений хочется бесконтактный вариант — реостат будет изнашиваться.
В таком случае лучше на датчиках холла. Но поплавок в любом случае и дороже и менее надежен (зарастает солями жесткости, например).
Электроника для гидропоники это круто, но меня больше интересует какие удобрения надо использовать для питательного раствора и как его приготовить. В интернете куча разных советов по этому поводу начиная от готовых и заканчивая самостоятельным приготовлением из разных химреактивов.
Книг по этому поводу издано много, например, Вахмистров Д. Растения без почвы, 1960 года. Меня в этом вопросе интересует другой вопрос — как не получить овощи с передозировкой нитратов и т.п…
Кроме того, содержание нитратов в овощах может резко увеличиться при неправильном применении азотистых удобрений (не только минеральных, но и органических). Например, при внесении их незадолго до уборки
Я на самом деле к этому вопросу безответственно подошёл. Пока росток был маленький подлил в воду чуть-чуть обычного жидкого удобрения для помидоров. Потом, когда вода начала цвести, решил, что ничего больше добавлять не буду, только марганцовкой изредка травил живность. В итоге весь этот куст вырос практически на чистой воде и марганцовке. Ну собственно, и на вкус он получился достаточно противный. В общем агроном из меня не очень. Ну и всё-таки это первый экземляр продукта — больше фана было наблюдать, как работает электроника и изредка исправлять огрехи в прошивке, когда что-то шло не так. Когда буду сажать следующего клиента, уделю вопросу правильного питания больше внимания.
Кстати по поводу живности в воде geektimes.ru/post/255486
После двух месяцев роста клубники возникли проблемы. Я заметил, что её листья становились скорее белыми, чем зелёными. Перелопатив массу информации, я выяснил, что возможная причина заключается в нехватке питательных элементов в воде, необходимых для формирования правильного роста. Какую-либо химию добавлять не хотел. Поэтому принял простое решение – увеличить количество рыб, так как больше рыб выработают больше продуктов жизнедеятельности.

По истечении месяца положительного результата не наблюдалось, листья по-прежнему оставались бледно-зелёные. Но зато начала обильно плодоносить клубника.
Да, нечто подобное я и хотел изначально сделать. В этой статье проскочила хорошая мысль — делать не дома, а на работе :).
Марганец вызовет отравление. Вначале на молодых листьях.
Избыток марганца, в отличие от его недостатка проявляется чаще на кислых почвах. В результате избытка марганца в клетках растений уменьшается содержание хлорофилла, поэтому при этом симптомы будут такие же, как и при недостатке магния, т.е. начинается мезжилковый хлороз, в первую очередь со старых листьев, появляются бурые некротичные пятна. Листья сморщиваются и облетают.
Нитратами перекормить почти нереально. Растение подохнет от передоза. Вообще выход за рамки это всегда стресс и замедление роста.
а есть ли веб ресурсы(рус/англ), специализирующиеся на аква-/гидропонике «домашнего» масштаба?
На форумах «дачников» такие темы есть, только это сплошное имхо на любые темы, иногда с переходом на личности. Например здесь много фото урожаев можно найти.
По гидропонике много, только они определённой направленности, вот например – olkpeace.ru
http://forum.ponics.ru/. Один из лучших. Крайне рекомендую ресурсы по выращиванию альтернативных «трав». Принципы те же, но там люди упоротые в плане выхода конечного продукта на стоимость электричества/удобрений и т.п. Народ цеые заросли в холодильнике и прочем выращивает.
Кстати, чтобы не мучится со шрифтами сделал программу для их редактирования и экспорта в код. от 5x7 до 16x16.
Я брал за основу сгенерированный шрифт. Но всё-таки потом пришлось вручную подправлять много погрешностей, осматривая с лупой каждый символ.
вот собственно для этого и сделал. Можно даже весь шрифт окинуть взглядом 1:1 и увеличенное изображение символа, и основное поле с «квадратами размером с кулак».
А собственно помидорки то как? Растут? Вкусные?
У меня вкусные росли. Томат Жёлтый малыш. Но у меня смесь кокоса и агроперлита. Капельная система.
А чем подсвечивали? Какие удобрения давали?
Без подсветки на северной стороне. Света им маловато, но прожектор был занят салатами. В Краснодаре с солнцем неплохо. В основном кальциевая селитра и Буйские удобрения «Овощные» и «Плодовые». В одних больше азота, в других калия. Плюс микроэлементы в хороших пропорциях.
Самый ступор был, когда у меня грибы в кокосе выросли.
image
А ещё перцы отлично растут в кокосе.

image
Класс… с грибами кстати можно было и таймлапс снять… они относительно быстро растут.
Они там надолго поселились) постоянно лезут. Мицелий же жив
Ну я там написал в конце, что не очень получились. Как пишут в комментариях — подбор раствора целая наука, скорей всего из-за этого. Я же на первом поселенце вообще эту тему не изучал и на авось этот вопрос оставил, больше уделяя внимание на наблюдение за работой электроники и периодическое исправление недочётов в прошивке. Следующему поколению уделю больше внимания в вопросах питания.
Спасибо за статью, очень интересно.
Очень не хватает схемы установки гидропоники. На словах непонятно как работает всё в целом, и понятно только по отдельности.

И ещё Вы делаете в опросе такой упор на ассемблер. Почему?
Да, с общей схемой поленился, подумал, что такие установки, только в большем масштабе и так известны и в целом очень просты. Насос просто перегоняет воду из нижнего бака в верхний, а когда он полностью заполняется, срабатывает сифон и вся вода опять сливается в нижний. Вот, например, на этом видео показано:
Видео


Про ассемблер — это, чтобы не отпугнуть от ответа тех, кто делает ассемблерные вставки, чтобы не расценили, что ответ с их преимущественным языком из-за этого не подходит. Без них ведь иногда никак. К примеру, в этом проекте для них нашлось место в планировщике задач:

/* Atomic sleeping. */
__asm__ volatile ("sei; sleep");

Согласно даташиту на AVR атомарное засыпание следует делать таким образом. Специально для этих целей инструкция SEI имеет особенность — следующая за ней инструкция выполнится до того, как обработается первое прерывание в очереди. Это для того, чтобы не получилось race condition — прерывание может придти после sei, но до sleep, в результате процессор заснёт, вместо того, чтобы выполнить действия для soft interrupt в главном цикле.
спасибо, вроде яснее стало, это видео куда удачнее первого.

а насчёт ассемблера:
Я пишу под МК на базе кортексов М0… М4. Там все такие особенности уже реализованы в библиотеке CMSIS от арм консорциума и прочих подобных.
За 5 лет ни разу не приходилось использовать асм ни в одном проекте что для кортексов писал все эти года. Потому что либо всё сделано уже до меня в либах и очень хорошо сделано. Обычно производительности не хватает не 5-10%, а не хватает в 5-10 раз, и тут надо либо менять МК либо ставить ПЛИС либо пересматривать хотелки и ТЗ в сторону упрощения или вообще менять идею целиком. А компилятору я доверяю больше чем моим умениям вылизывать инструкции: местами может и выйдет быстро если на асме написать, но в целом современные компиляторы существенно лучше.
Поэтому такое сочетание С++11 и упора на асм вызвало удивление: обычно любят что то одно.
Добавлю видео в текст.

Я поэтому и привёл пример, когда без этого никак. Речь не об оптимизациях, а именно о специфических инструкциях, для которых нет нужной обёртки в стандартной библиотеке. Да и подобные библиотеки тоже кто-то пишет.
Если уж C++11, то зачем макросы, можно
static constexpr auto &&
.
И удостовериться, что во всех translation unit'ах используется один и тот же экземпляр.
Не совсем уловил мысль. Можете привести более полный пример?
Пардон, static вам, видимо, не подходит из-за необходимости добавить аттрибут PROGMEM.
Я предлагал завести тип со статическими полями, объявленными примерно так:
struct Strings {
    static constexpr auto&& Prompt /*PROGMEM*/ = "Are you sure you want to format SD-card?";
};

но видимо
static
и
PROGMEM
не сочетаемы, так как по сути оба являются storage спецификаторами.
PROGMEM — это атрибут GCC, раскрывается в "__attribute__((__progmem__))". Со static он не конфликтует. Вот это компилируется.
struct Strings {
    static constexpr auto&& Prompt PROGMEM = "Are you sure you want to format SD-card?";
};

Если при линковке для всех compilation unit каждая строка в итоге будет выделена только в одном месте, то это да, лучший вариант.
Вопрос по ЛУТ.
Со стороны меди у вас плохо перенесена краска, со стороны шелкографии — наоборот. Какой бумагой пользуетесь?
Я со стороны меди использую фотомумагу для струйников Lomond, результат отличный.
Со стороны шелкографии обычно кальку, потому что её не надо отмывать — результат так себе, размазано немного.
Грею просто утюгом через газету, без конфорки.
В этом проекте попробовал какую-то китайскую с eBay специально для ЛУТа. Думаю, что не очень хороший результат связан с неправильной температурой для моего тонера или бумаги, неравномерным проглаживанием или ещё какими-нибудь тонкостями процесса. Я платы довольно редко делаю, ещё не отработал эту технологию. В принципе уже привык ретушировать маркером после перевода.
Отходит сама, но, как видите, частично с краской в моём случае.
А насчёт RTC — внутрениий таймер по моему опыту (небольшому) использовать получается очень криво. Из-за обилия других прерываний он очень сильно уходит. Поэтому думаю что внешние RTC очень даж верное решение.
Ну по моему опыту, когда таймеров хватает, вполне сносно работает (если не нужно большой точности, но до показателя пару секунд за несколько месяцев, ему, конечно, далеко). Другие прерывания влиять не должны — прерывание от таймера (я использовал 16-битный таймер с верхним значением, удобным для ровного деления) довольно редкие, пропустить их сложно (они ведь в очередь аппартно ставятся), если код написан правильно. Как-то так для 20МГц:

/** TOP value for clock counter. */
#define CLOCK_MAX_VALUE     62499

/** Called on each second. */
static inline void
OnClockSecond()
{
    g_clockSec++;
    if (g_clockSec < 60) {
        return;
    }
    g_clockSec = 0;
    g_clockMin++;
    if (g_clockMin >= 60) {
        g_clockMin = 0;
        g_clockHour++;
        if (g_clockHour >= 24) {
            g_clockHour = 0;
            g_clockDow++;
            if (g_clockDow >= 7) {
                g_clockDow = 0;
            }
        }
    }
    OnClockMinute();
}

/** Clock ticks occur with TICK_FREQ frequency. */
static inline void
OnClockTick()
{
    static u8 divisor = TICK_FREQ;

    g_clockTicks++;
    divisor--;
    if (divisor == 0) {
        divisor = TICK_FREQ;
        OnClockSecond();
    }
    ProcessTaskQueue();
}

ISR(TIM1_COMPA_vect)
{
    OnClockTick();
}

static inline void
ClockInit()
{
    /* CLK / 8
     * WGM = 0100 (CTC)
     */
    TCCR1B = _BV(CS11) | _BV(WGM12);
    OCR1A = CLOCK_MAX_VALUE;
    TIMSK1 = _BV(OCIE1A);
}

Но в целом да, если требуется устройство для длительной автономной работы с точным временем, то только специализированные модули.
/** Clock ticks frequency. */
#define TICK_FREQ       40

20000000/8/62500
Если прерываний много и МК находится в другом прерывании (а там обычно ставят запрет прерываний) то прерывания от таймера не будет. Я вот это имел ввиду. То есть будут пропуски отсчёта времени.
Если же прерывание одно, то и тут будут сдвиги — из-за многотактовых команд. Т.е. сначала довыполняется текущая команда, потом уже прерывание, а не сразу.
Не сразу заметил — про очередь прерываний. Они точно ставятся в очередь?
Я не прав, вот какая задержка будет:

При входе в прерывание флаг Global Interrupt Enable автоматически сбрасывается, запрещая дальнейшие прерывания. Если он будет явно установлен в программе обработки прерывания, то новый запрос с наивысшим приоритетом прервет текущий обработчик. Приоритет прерывания уже запущенного обработчика при этом не имеет значения: если одновременно выставлены запросы INT0 и INT1 и оба они разрешены, начнет обрабатываться INT0; если далее в обработчике INT0 будет установлен флаг Global Interrupt Enable, то текущий обработчик будет вытеснен обработчиком INT1, а по его завершении будет продолжен (если кто-то еще снова не вытеснит).

Точно так же уже запущенный обработчик INT1 будет прерван более приоритетным INT0 лишь в том случае, если сам установит Global Interrupt Enable. Приоритет важен лишь в момент выбора одного прерывания из нескольких одновременных запросов.

Есть еще одна тонкость: если в данный момент обрабатывается прерывание, а другой запрос уже ожидает своей очереди, то после завершения текущего обработчика производится возврат в прерванную программу, выполняется одна инструкция, и лишь затем запускается новый обработчик. Эту задержку следует учитывать, если время реакции на прерывание очень критично.
Очередь работает так — каждое прерывание выставляет свой специфичный флаг в регистрах МК (INT0F, например). Далее соответствующий хандлер аппаратно вызывается, как только будет одновременно выставлен этот флаг и GIE (в порядке приоритетов). Получается, что если в это время работал другой хандлер, то как только он выйдет, GIE будет выставлен и следующий хандлер вызовется (с задержкой в одну инструкцию).

Время реакции на прерывание в данном случае не критично — нам ведь главное ничего не пропустить, чтоб со временем не сбивалось время. Задержка в обработке (latency), это уже другая история, там, где это действительно важно. А пропустить можно, только если МК постоянно сидит в обработке более приоритетных прерываний — а это уже перегрузка и надо что-то менять в дизайне, так ваше приложение нормально работать не сможет.

Ещё стоит помнить, что обработчики прерываний обычно делают по возможности очень короткими, использую подход т.н. software interrupt — непосредственно обработчик только выставляет флаг, по которому уже делаются какие-то действия в главном цикле, вне контекста прерывания.
Всё верно. Там ещё есть тонкость с асинхронным таймером, у меня был он на отдельном кварце.
Кстати да, если есть возможность поставить часовой кварц для таймера, то с часами вообще проблем быть не должно.
Да вот нет, чтобы точно работало нужно засыпать постоянно камнем. Часовые прерывания там тактуются отдельно по частоте часового кварца и пока на них переключится камень тоже проходит время. Всеми тонкостями я ещё не владею.
На точность отсчёта времени это никак не влияет. Таймер как тепловоз — идёт себе независимо ни от чего, досчитает до переполнения и выставит признак прерывания — когда его контроллер обработает его не волнует абсолютно и отсчет при этом НЕ останавливается, следующий «флажок» будет выставлен в строго назначенное время, незвисимо от того насколько быстро и своевременно отработал обработчик прерывания, да хоть прямо перед следующим прерыванием…
Очень важны только две вещи: 1) не трогать ни коим образом работающий таймер, 2) обработать прерывание ДО прихода следующего.
Не согласен. Вы можете пропустить событие прерывания если у вас их несколько (от разных источников). Флажок-то будет выставлен, только он может быть несколько раз выставлен.
Ну так и я, и предыдущий комментатор писали:
2) обработать прерывание ДО прихода следующего.

В моём примере кода периодичность прерывания 40Гц, времени на обработку более, чем достаточно, если МК не перегружен, а про это я тоже говорил, перегруженный МК — неправильный дизайн — либо код, либо не хватает вычислительной мощности для выполняемой задачи и надо использовать более производительный МК.
Следующего того же прерывания или вообще любого? Я понял что такого же.
ОК.
Да, до прихода следующего такого же, у каждого прерывания есть свой специфичный аппаратный флаг. Другие прерывания не затрут ничего, связанного с данным.
До при хода любого прерывания. Иначе отсчёт времени будет нарушен.
И как он будет нарушен?
Единственная ситуация когда прерывание не будет обработано до возникновения следующего это постоянно срабатывающее прерывание более высокого приоритета до того как оно будет обработано. Например, прерывание по уровню на порту, и если этот уровень держать постоянно, то флаг прерывания от порта будет висеть постоянно, контроллер не выйдет с обработки этого прерывания пока не уберёшь уровень по которому оно срабатывает. Но допущения таких ситуаций — это проблемы с дизайном…
Обработка часового прерывания будет не в момент отсчёта времени, а позже. Статистически скажем за час будет одинаковое число обработок, только сам момент срабатывания будет гулять.
Это если предположить что нет обработчика какого-то любого прерывания, отрабатывающего медленнее, чем частота часового таймера. В этом случае будут пропуски.
Статистически скажем за час будет одинаковое число обработок, только сам момент срабатывания будет гулять.

Ну про это речь выше была. Для учёта времени маловажна задержка обработки. Важно как раз общее количество за единицу времени — именно тогда время со временем никуда не уйдёт (если точность кварца позволяет).

Это если предположить что нет обработчика какого-то любого прерывания, отрабатывающего медленнее, чем частота часового таймера.

Это и есть ошибка дизайна. Опять же, как сказано выше, обработчики должны быть как можно более короткими, длинные операции надо выносить за пределы контекста прерываний, например, устанвливая в обработчике только флаг, и в главном цикле проверяя его и выполняя работу (подразумевая, что обработка может длиться несколько прерываний и быть к этому готовым).
Ясно. Спасибо за ответы!
UFO just landed and posted this here
Сейчас у меня раз в 6 часов стоит. Подобрал на глазок, через прозрачную стенку видно, насколько влажно внутри. По ощущениям сейчас можно и меньше. Летом, когда стояло на солнце весь день, было раз в 3 часа.
UFO just landed and posted this here
Ага, понятно какой «цветочек» :D
Вот у меня коллеги тоже не верили, что будет помидор. А он внезапно оказался помидором.
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.

Articles