Компания
29,92
рейтинг
2 июня 2015 в 14:33

Разное → Метеостанция не на Arduino, или Работа с таймерами и прерываниями GPIO в OpenWRT

Привет, Хабр, давно не виделись!

Сначала — несколько важных новостей о проекте микрокомпьютеров Black Swift, а потом перейдём к основной теме: как на микрокомпьютер с OpenWRT сделать полноценным встраиваемым устройством.

Полноценный встраиваемый компьютер, на мой взгляд, невозможен без двух вещей:
  • Поддержка прерываний по разным поводам, включая сигналы на входах GPIO
  • Поддержка аппаратных таймеров с хорошим разрешением


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

Тем удивительнее, что при достаточном количестве микрокомпьютеров на SoC Atheros AR9331 и более дешёвых Ralink RT5350, позиционируемых именно как встраиваемые решения, с поддержкой в OpenWRT именно этих двух функций всё крайне печально. Здесь, конечно, возникает вопрос, кому эти микрокомпьютеры при таком уровне поддержки нужны — но оставим его висеть в воздухе.



Впрочем, если посмотреть на неё же по TCP/IP, то может сойти и для здорового человека.

Но сначала — новости:

  • Первая партия Black Swift — в России и уже рассылается по рублёвым предзаказам (то есть сделанным не на Kickstarter). Если вы при предзаказе указывали доставку — ждите, если самовывоз — звоните в офис и подъезжайте.
  • Если вы не оформляли предзаказ, но хотите купить Black Swift — звоните в офис и подъезжайте, у нас довольно много плат сверх объёма предзаказов. Оформить доставку можно, но тогда вы по понятным причинам встанете в хвост очереди предзаказов.
  • Сертификация FCC скоро завершится, судя по всему — успешно.
  • Удовлетворение бэкеров с Kickstarter, как и обещалось, ожидается в июне. Разослать отдельно русскоязычным или каким-либо ещё отдельным бэкерам платы мы не можем по техническим особенностям Kickstarter.
  • Потихоньку пополняется документация, из-за нехватки времени —  в первую очередь англоязычная.
  • В частности, образы виртуальных машин с OpenWRT SDK и Eclipse — вот тут (через пару дней обновлю их на свежую версию SDK с нашими патчами). Полезны для всех, кто хочет что-то писать под OpenWRT, но не очень понимает, как.


Ну а теперь — к теме.

Теория


В Atheros AR9331 есть две вещи, весьма важные для встраиваемого компьютера — это аппаратные таймеры (четыре штуки, тикают на частоте системной шины, по достижении нуля генерируют прерывание) и прерывания на ножках GPIO (умеют срабатывать по обоим фронтам сигнала).

К сожалению, на программном уровне в OpenWRT нет поддержки ни того, ни другого — то есть, если вы захотите сделать отсчёт каких-то интервалов или эмулировать какие-то протоколы, то udelay() вам в руки и надежду на то, что в многозадачной среде никто не влезет в середину эмуляции вашего протокола — на шею. Для поддержки GPIO IRQ есть широко известный в узкой среде патч, который решает только часть проблемы: вам мало получить прерывание, надо его ещё обработать и вывести в юзерспейс, где живёт уже ваша собственная программа. Ну и, конечно, чтобы патч наложить, вам потребуется самостоятельно собрать всю прошивку — занятие небыстрое и небезгеморройное.

Для поддержки таймеров нет ничего.

Точнее, до недавнего момента не было.

Модуль ядра, ловящий прерывания от GPIO и передающий их сигналом в юзерспейс — тут: github.com/blackswift/gpio-irq-handler

Работает просто: вам надо в псевдофайл /sys/kernel/debug/gpio-irq записать строку «+ GPIO PID», где GPIO — номер нужной ножки, PID — ваш процесс, в который надо слать сигнал. Потом поднять обработчик сигнала номер 42 и стойко ждать. Снять прерывание — «- GPIO PID» в тот же файл.

Модуль ядра, реализующий поддержку аппаратных таймеров — здесь: github.com/blackswift/timer-irq-handler

Работает не сложнее: сначала в /sys/kernel/debug/timer-irq пишем «+ TIMER TICK», где TIMER — номер таймера (от 0 до 3, системой не занят ни один, так что остаётся следить между своими приложениями, чтобы они не пытались за один таймер хвататься вдвоём), TICK — его разрешение в микросекундах (каждый тик будет генерировать прерывание, так что меньше 20 мкс лучше не ставьте). Потом туда же — «+TIMER TIMEOUT PID», где TIMEOUT — период, через который вы хотите получать сигнал, а PID — ваш процесс. Номер сигнала — 43. Если хотите, чтобы таймер сработал только один раз — добавьте в конце слово «once». Если не хотите — он будет работать, пока вы в вышеуказанный файл не скажете «- TIMER».

Модули ядра со всей очевидностью будут работать только на AR9331, так как у других чипов — другая адресация регистров. Более того, для работы GPIO IRQ вам потребуется прошивка с вышеупомянутым патчем, и на данный момент «из коробки» вы получаете такую прошивку только на Black Swift.

Практика



Полученным знанием надо пользоваться, то есть — собрать что-то полезное с таймерами и прерываниями. У меня это будет метеостанция (см. КДПВ). Почему? Во-первых, понятная всем вещь, во-вторых, распространённый датчик DHT22 — та ещё заноза в заднице. У него похожий на 1-Wire протокол, только если в 1-Wire синхронизация есть, то здесь хост один раз притягивает ножку данных к «земле», а дальше датчик сам оттарабанивает на выходе 41 импульс в ответ. «0» и «1» отличаются длительностями импульсов — 28 мкс против 70 мкс.

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

С прерываниями дело упрощается радикально: без особого труда можно написать модуль ядра, который ловит прерывание на нужной ножке, отсчитывает от него 35 мкс банальным udelay() и измеряет уровень на этой же ножке. Если там «1» — значит, сигнал длиннее 35 мкс, то есть, собственно, «1». Собственно, всё. Если вам написать свой модуль ядра чуть сложнее, чем нам, то вот исходники: github.com/blackswift/gpio-dht-handler

Поймав данные с датчика, модуль выдаёт их либо в вывод ядра (смотреть командой logread), либо сигналом 44 в приложение по указанному PID. При ошибке CRC в консоль приедет «Error», в приложение — 0.



Теперь осталось написать вокруг этого собственно приложение — мы же не в лог ядра будем ходить посмотреть, надевать ли шапку.

Здесь всё оказывается столь же банально: запускаем аппаратный таймер, которые будет тикать раз в минуту (максимально возможный период тикания — UINT_MAX микросекунд, то есть чуть больше 71 минуты). От него приходит сигнал, обработчик которого посылает запрос модулю протокола DHT22 — просто пишет в псевдофайл. Ещё через десяток миллисекунд прилетает ответный сигнал от DHT22, обработчик которого, собственно, его обрабатывает — в нашем случае пишет в файл.

void irq_handler(int n, siginfo_t *info, void *unused)
{
	//every minute
	counter++;
	dht_request_data();
}

void dht_request_data()
{
	int fd=open("/sys/kernel/debug/irq-dht", O_WRONLY);
	sprintf(buf, "%d %u", DHT_GPIO, getpid()); // gpio-dht-handler kernel module
	write(fd, buf, strlen(buf) + 1);
	close(fd);
}


void dht_handler(int n, siginfo_t *info, void *unused)
{
	if (info->si_int == 0) // DHT protocol CRC error
	{
		if (++failcounter > 10)
		{
			printf("Error retrieving data from DHT sensor\n");
			failcounter = 0;
			return;
		}
		usleep(3000000); // wait 3 seconds between attempts
		dht_request_data();
		return;
	}

	float humidity = (float)((info->si_int) >> 16)/10.0; // 2xMSB
	float temperature = (float)((info->si_int) & 0xFFFF)/10.0; //2xLSB

	// ...
}

int main(int argc, char* argv[])
{
	int timer = TIMER_TIMER;
	int tick = 1000*1000; // 1 sec
	unsigned int timeout = 1000*1000*60; // 60 sec

	if (!init_handler(timer, tick, timeout))
	{
		printf("Error initializing timer %d\n", timer);
		return -1;
	}

	struct sigaction sig;
	sig.sa_sigaction = dht_handler;
	sig.sa_flags = SA_SIGINFO | SA_NODEFER;
	sigaction(SIG_DHT_IRQ, &sig, NULL);

	// ...
}




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

Текстовый файл — это лучше команды logread, но пока не совсем то, что хочется иметь дома более-менее здоровому человеку. Надо бы выводить данные красиво, с графиками. Рисование графиков в C с выводом в PNG-файл — задача достаточно нетривиальная, наверное, вы не только не хотите решать её голыми руками, но и искать умеющие это библиотеки. К счастью, так как на микрокомпьютере у нас бегает вполне полноценный Linux, то ничего этого делать не надо: ставим пакет gnuplot и далее просто скармливаем ему наши данные, сопроводив их несложным скриптом, указывающим, где какая ось и какой масштабчик поставить.

set terminal png medium size 600,300
set format x ""
set key below
set xrange [60:0]
set yrange [0:100]
set grid ytics lc rgb "#bbbbbb" lw 1 lt 0
set grid xtics lc rgb "#bbbbbb" lw 1 lt 0
set output "/www/light/img/last_60m.png"
plot "-" using 0:1 title "Temperature" with lines, "-" using 0:1 title "Humidity" with lines




Опять же, как мы будем эту температуру узнавать? Да элементарно: ставим веб-сервер (например, opkg install lighttpd — поставит веб-сервер, соответственно, lighttpd, примечательный тем, что он ещё и PHP умеет, если надо) и делаем HTML-страничку, подсасывающую наши картинки, а заодно текущие данные в цифрах. Если вам не надо выдерживать хаброэффект, то можно всё сделать на PHP, если нужно — текущие данные можно менять в статическом HTML-файле известным всяком линуксоиду (и способным привести в ужас остальных) редактором sed, дёргая его из той же нашей софтины по мере прихода новых данных.

SR_TIME="class=\"time\">.*</span"
RP_TIME="class=\"time\"> $3 </span"
SR_TEMP="class=\"temp\">.*</span"
RP_TEMP="class=\"temp\"> $1\°C $2% </span"

cat /www/light/index.html | sed -e s,"$SR_TIME","$RP_TIME", | sed -e s,"$SR_TEMP","$RP_TEMP",




Что ещё осталось? Ну, наверное, иногда полезно посмотреть глазами, что там вообще происходит-то. Берём веб-камеру, втыкаем через переходник USB-OTG в Black Swift и с помощью утилитки fswebcam выводим с неё раз в минуту картинку. Заходим браузером по ссылке и смотрим.

Ссылка? Вот ссылка: http://files.black-swift.com:9000/

Порт пробрасывается напрямую на Black Swift, поэтому всё, что вы видите по ссылке, крутится исключительно на нём.

Также, говорят, последнее время модно выводить данные о том, сколько у тебя на балконе градусов, на сервис narodmon.ru. Честно говоря, никогда им не пользовался, но выяснилось, что это не очень сложно — копируем из документации пример на PHP, записываем его в файл /root/narodmon.php на Black Swift и далее раз в 15 минут дёргаем его из нашей софтины командой /usr/bin/php-cgi /root/narodmon.php, благо PHP у нас тоже есть и готов к использованию. Ну и параметры не забываем передать, конечно.

Здесь читатель может удивиться — зачем нужно такое разнообразие языков и утилит? Не лучше ли писать всё месяц на ассемблере неделю на чистом C, а потом восхищаться красотой? Нет, не лучше. Прелесть полноценного линукса на встраиваемом компьютере — в частности в том, что результат вы можете получить за считанные часы, пользуясь уже известными утилитами и языками, а не устраивать полноценный НИОКР на неделю без сна и отдыха.

Базовое знание C, знакомство с популярными юниксовыми утилитами — и готово. Хотите PHP — вот, пожалуйста. Хотите в базу данных — получите, распишитесь. Хотите на ассмеблере — тоже можно, но очень дорого.

Nothing works and nobody knows why



Theory is when you know everything but nothing works. Practice is everything works but no one knows why. In our laboratory, theory and practice are combined: nothing works and no one knows why.

Впрочем, чтобы не перехвалить самих себя, отмечу — пока что не всё работает так, как хотелось бы.

Если вы прогуляетесь по нашему гитхабу, то без труда найдёте там альтернативный модуль для работы с DHT22, который внутри сделан совсем красиво — он в прямом смысле слова измеряет длительность приходящих импульсов. В микросекундах. И довольно точно — я не проверял его на калиброванном генераторе, но приходящее с DHT22 отличается от указанного в даташите на него не более чем на 3-4 мкс.

За одним исключением.

В глубинах OpenWRT есть довольно злой обработчик прерываний USB, который на время своей работы маскирует все остальные прерывания — а работает он долго, запросто может уйти в себя микросекунд на 30-40. В результате часть прерываний от GPIO в нашем случае мы можем просто пропустить, в лучшем случае — получить с большой задержкой. Увы, в дебрях ассемблера и копирайтов 1999 года мы пока окончательно не разобрались, поэтому модуль, работающий по двум прерываниям на импульс, приходится отложить в сторону — ловить первое прерывание и далее отмерять от него 35 мкс в таких условиях оказывается значительно надёжнее.

Вот тут он скушал два прерывания и подвинул третье:



Кроме того, при активной работе USB (например, по нему идёт поток с веб-камеры) такие задержки случаются настолько часто, что и модуль, которому одного прерывания достаточно, оказывается под угрозой. Впрочем, в чуть менее критичных вещах, где задержки в пару десятков микросекунд несущественны, вы этого не заметите — но всё равно неприятно.

Если у вас есть что сказать по этому поводу, мы с интересом послушаем.

В следующих сериях



А вы знаете, что в OpenWRT нет работающего способа полностью отключить вывод консоли в UART?

Да, это ещё одна весёлая ловушка: какие бы параметры и в какие файлы вы бы ни писали, при загрузке платы в UART высыпается гора мусора; доступными пользователю параметрами определяется только размер этой горы — и он всегда ненулевой.

На Black Swift для полного отключения всех консолей от UART достаточно дать команду «fw_setenv silent 1» и перезагрузиться. Но это — другая история.

P.S. Завтра на Skolkovo Startup Village приедет не только Д.А. Медведев, но и я — в частности, вот на это мероприятие. Если хотите пообщаться по темам краудфандинга и/или (за рамками мероприятия) Black Swift — подходите.
Автор: @olartamonov
Black Swift
рейтинг 29,92
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Комментарии (32)

  • +1
    Д.А. Медведев
    Чо за чувак? Он будет вести доклад по метеостанциям?
    • 0
      Не, мы ему метеостанцию дарить не стали.
  • 0
    Краудфандинг надо развивать в России. Удачного выступления.

    И кстати было бы не плохо придумать/предложить схему со-финансирования от государства краудфандинга для интересных инновационных и/или технически-ёмких проектов.
    • +1
      Зачем софинансирование? Никто не мешает денег взять в разных местах одновременно. Другое дело, что большинство берущихся просто понятия не имеют, как их взять.

      С госфинансированием проблемы другие — там надо очень много бумаг, желательно показывать «социальную значимость» бизнеса, и наконец, есть большая проблема с получением маленьких денег, до десяти миллионов: госфинансирование в основном заточено на крупные проекты. Есть, впрочем, Сколково, есть Роснано, для интернет-проектов есть ФРИИ — там везде люди разной степени странности, но они есть, и кто-то с них даже денег получает.

      Но лично я не вижу, зачем здесь нужно именно госфинансирование. Если говорить, например, про нашу область — электронику — то наибольшей проблемой является то, что большая часть потенциальных клиентов даже не задумывается, что электронику можно разрабатывать и производить в России («слушайте, а может лучше взять вашу команду, отправить кого-нибудь в Китай, пусть он там договорится, чтобы они под нас сделали, и проследит сразу на месте» — реальный разговор с крупным дистрибьютором, например). То есть нет моста между заказчиками и исполнителями. Одни — условно — сидят в своих технопарках, для других технопарк — это такой закрытый крышкой котелок, в котором варится непонятно что, но вряд ли имеющее отношение к их бизнесу.

      Другая проблема — то, что венчурное финансирование (а уж в России оно вообще местами странное) в большей степени нацелено на одну конкретную задачу: создание бизнеса для последующей продажи. Настолько нацелено, что обсуждающие тему эффективность стартапа рассматривают исключительно с точки зрения количества сумок с деньгами, которые его владелец получит при продаже (см. свежую историю с Get Satisfaction и волны вокруг неё, например), причём большинство, похоже, даже не отдаёт себе в этом отчёта. В результате стартапам, которые хотят строить какой-то плавно развивающийся бизнес, который нельзя быстро надуть деньгами до размера слона, весь этот дивный новый мир оказывается параллелен. Нет, там есть исключения разные, но в целом — увы.
      • 0
        Спасибо за развернутый ответ.

        Вы всё верно сказали. И про то что маленькие суммы сложно, и про «закрытый крышкой котелок».

        Моя идея скорее такого плана — сделать некий фонд, для поддержки (скорее стимулирования). Финансироваться он может и из государства и от частных компаний и других фондов. И этот фонд согласно неким кураторам — может тратить на со-финансирование именно российских краудфандинговых проектов.

        Плюсы в том, что будет развитие «краудфандинговой культуры», т.к. многие у нас просто не знают, что есть такие механизмы как коллективный сбор денег на что-то интересное.

        Даже сумма в 100 т.р./месяц из этого фонда (итогово) — может помочь в старте многим энтузиастам в городах — кто хочет оборудовать свою лабораторию — новым железом, 3д принтер, наборы Ардуино, Малины, тех же BlackSwift и т.п. Сейчас как правило за свой счёт все покупается.

        При этом 50% суммы заявителю — необходимо собрать через краудфандинг — то есть обеспечить и подтвердить социальную привлекательность идеи. Это так же может быть и переводы книг, и подготовка методических материалов (много ли у нас русскоязычных книг по OpenWrt, Scratch, Snap и т.п.), выпуск печатных версий книг.

        • 0
          Этот фонд будет крайне неэффективен минимум по двум причинам:

          1) Про краудфандинг большинство таки знает. Больше не знает, как правильно сделать продукт, как его продвигать, как работать с возражениями и так далее — но это всё именно к краудфандингу как таковому отношения не имеет, но определяет его результат. Вот я писал про российский кампании по краудафандингу, там на две из трёх авторы в комментарии пришли — это же обнять и плакать что они несут. Ну и все кампании провалены, конечно, с грохотом. Фонд тут ничем не поможет.

          2) Краудфандинг — сравнительно лёгкая нажива для мошенников и прибежище для идиотов. Первые раскручивают там большие кампании под модные темы, вторые просто верят в чудо (вот бесконечно прекрасный просто чувак).

          То есть, краудфандинг — так себе фильтр. Кроме того, государственный фонд неизбежно обрастёт всеми бюрократическими атрибутами, которые есть у тех же Сколково и Роснано — говоря проще, надо будет сдать неимоверную прорву бумажек и для получения денег, и для отчёта по ним.

          Если разработать способ преодолеть вторую проблему, то в качестве фильтра тогда уж проще панель экспертов использовать.
  • 0
    Интересно это у них там метеостанция глючит или чего может случилось?
    image
    http://narodmon.ru
    • 0
      Глючит, конечно. Единичные точки вываливаются.
      • 0
        Ну мало ли, может грузовик со странными бочками мимо ездит…
  • 0
    А возможно(будут ли виртуальные машины) для сбора qt проектов?
    • 0
      Для начала потребуется саму Qt портировать на OpenWRT, а этого пока в планах нет.
      • 0
        Есть проект Xorg под OpenWrt, там qt4 встроен. Но вот как-то гложут меня смутные сомнения… Надо будет попробовать оттуда выдрать саму библиотечку.
  • 0
    Сертификация FCC скоро завершится, судя по всему — успешно.
    Отлично, но это для американских пользователей, верно? В России и СНГ есть ли что-то подобное?
    • 0
      В России вся нужная для импорта и продажи сертификация традиционно проще и бессмысленней.
  • +1
    спасибо за работу с прерываниями
  • +1
    Первая партия Black Swift — в России и уже рассылается по рублёвым предзаказам (то есть сделанным не на Kickstarter)...

    Звучит так же оптимистично как «Мы уже перегоняем Америку!!!». Я мониторю ситуацию с доставкой еще с февраля, получили платы только те кто заехал за ними сам. Люди которые заказывали в августе прошлого года до сих пор ждут, как и я (заказ в январе 2015). Как инженеры, товарищи внушают доверие и оптимизм, но то как игнорируются соотечественники поддержавшие проект рублем в самом начале — очень печально, никаких уведомлений о срывах сроков на е-мейл или где-то еще, лишь когда плач «ждунов» на форуме достигает критической точки, релизится нова дата, когда будет «все готово», каждая новая дата начала рассылки плат означает лишь, что будет новая дата рассылки плат. На данный момент прошло две недели со старта рассылки, но в соответствующей ветке на форуме ни одного человека подтвердившего получение по почте.
    Как 4 месяца затягивалась рассылка плат здесь
    • 0
      Вы во всем правы, кроме одного — «Люди которые заказывали в августе прошлого года до сих пор ждут». Заказы мы начали принимать только в конце ноября. Обещали выдать в феврале. Так что да, задержали на 4 месяца. Кругом виноваты, согласен. Конечно, у этого есть свои причины, но ответственности с нас это не снимает.
    • 0
      Про август вам уже написали — никаких предзаказов в августе не было. И в сентябре не было, и даже в октябре. Приём начался в ноябре, основной объём пошёл в декабре.

      На данный момент оформлявшим предзаказы выдано немногим более двух сотен плат, конкретно Почтой России отправлено несколько десятков (сколько уже доставлено — сейчас сходу не скажу).

      Ну да, на форуме пишут не все. На форуме вообще пишут считанные единицы, причём недовольные пишут чаще, чем наоборот. Это нормальная особенность форумов.
  • 0
    Спасибо за примеры с прерываниями. Надо будет попробовать на досуге.

    Сам достаточно давно пользуюсь альтернативным вариантом — i2c-tiny-usb
    Т.е. простейший программатор USBisp или USBasp перепрошиваю в USB_to_I2C переходник, подгружаю стандартный модуль ядра i2c-tiny-usb (он там еще за собой несколько потянет) и подключаю на шину датчики температуры, давления, влажности, освещённости, напряжения/тока и т.д.

    Очень радует, что, например, датчик AM2321 I2C вполне прекрасно заменяет DHT22 и стоит таких-же денег на Алиэкспрессе.
    На GitHub когда-то выложил некоторые наработки по I2C датчиков с базовыми примерами (прошу не судить строго) отправки данных на Народный мониторинг, ThingSpeak и FlyMon.

    Правда сейчас немного отвлёкся на ESP8266 (опять не судите строго, всё вручную ;) и в стадии разработки), занятная штукенция в плане автономности ;) Некоторые гики с нашего форума/чата добиваются 2-х месячной работы (период отправки данных 10мин, всё остальное время — глубокий сон) от двух АА батареек, что уже неплохо.

    Авторам Black Swift успехов во всех, безусловно нужных, начинаниях!

    • 0
      Есть универсальный способ — подцепить любую AVR'ку по SPI + Reset, на ней уже реализовывать нужные протоколы. Т.к. под OpenWRT есть avrdude, то и программируется AVR'ка прямо с Black Swift, из консоли.

      Но это — случай, когда нужен жёсткий риалтайм, много датчиков и/или протоколов и т.п. А задачу одного-двух-трёх датчиков с редкими измерениями и толерантностью к единичным сбоям странно решать внешним контроллером, когда вот по-любому проц на 400 МГц простаивает.
  • –2
    Как я уже говорил 15 евро со склада в Болгарии. И 24 евро полный комплект достаточный для управления, например, двигателем желюзей. Комплект драйверов и сенсоров для множества возможных устройств.
    • +1
      а работа с прерывания в этом комплекте налажена?
      • 0
        Выше было отмечено что код для решения этой проблемы, сформулированной автором статьи, был его же группой и выложен на гитхаб. Возможно вам эти примеры подойдут. Думаю что этот конкретно вопрос о прерываниях не является проблемой. Когда у меня будет точная информация, я напишу в деталях. Пока же можно просто самостоятельно заказать устройство Olimex и проверить или задать вопрос на форуме.
  • +1
    Ситуация с таймерами мягко говоря странная, как и решение.

    В FreeBSD есть eventtimers: www.freebsd.org/cgi/man.cgi?query=eventtimers&sektion=4&apropos=0&manpath=FreeBSD+10.0-stable
    пишешь для них драйвер (300-1000 строчек) высокоуровневые таймеры из юзерспейса начинают это всё прозрачно использовать, притом системе достаточно одного таймера, она настраивает его чтобы он срабатывал тогда, когда должен сработать самый ранний из всех таймеров, после его срабатывания перенестраивает на следующий.
    Часто эти самые таймеры используются планировщиком задач для переключения потоков/процессов.
    На некоторых чипах один из таких таймеров может быть настроен на сброс чипа вместо генерации прерывания — вачдог, а других вачдог отдельно.

    Учитывая то, что линукс на х86 платформе прекрасно работает с HPET (что по сути тоже самое что и встройка в AR9331), tsc и прочими — очень странно нахрена было городить костыль с сигналами и прочим, когда, скорее всего, нужно было просто посмотреть код hpet и соседних таймеров и аналогично научить ядро с ними общатся, чтобы куча приложений использующих задержки корректно работали на этой платформе.

    Но!
    У всех MIPS есть стандартный таймер работающий на частоте кристала. Он так же умеет генерировать прерывания.
    И по дефолту все используют его, и мало кто пишет дрова для всех дополнительных таймеров ибо даёт это не слишком много.
    Те epoll()/read()/… + timerfd должно быть не хуже и заметно гибче + стандартнее.

    С gpio — тоже можно было бы сделать какое то устройство, кторое бы генерировало эвент на чтение из себя при срабатывании прерывания.
    Типа открыл /dev/gpio, записал туда "+ GPIO" и дальше epoll()/read() срабатывает при прерывании, да ещё и можно было бы какую то полезную инфу отдавать.
    • +1
      Возможно, позже мы так и сделаем. Но сейчас у нас стоит традиционная задача быстрого решения множества проблем в условиях ограниченных ресурсов.

      Причём до нас эти проблемы никто даже в таком виде не решал.
      • 0
        Как я писал выше, эта «проблема» вами же лично и придумана (с вашего разрешения могу привести вашу цитату). Но если я столкнусь в практике с этой «проблемой» или его решением, которое возможно есть в устройстве от Olimex, то обещаю опубликовать это решение. Вот исходники ядра. Каждый может изучить их самостоятельно и найти ответ.
        • 0
          Проблема поддержки прерываний на GPIO была придумана лично мной?

          Ok.

          Хорошее радио у вас в голове играет, забористое.
          • 0
            Иногда и nice достаточно на практике. Обычно в устройствах SoC и в MIPS в частности есть ВатчДог устройства. Драйвера к ним то же есть.
            • 0
              Удачи вам в разработке.
              • 0
                Спасибо и вам так же. На SGSII вроде нареканий не было особо много :-) И на CM9 то же. Надеюсь что и на RT5350F-OLinuXino не будет. Как и на остальные продукты которые мне удалось поделать.
  • 0
    остаётся следить между своими приложениями, чтобы они не пытались за один таймер хвататься вдвоём


    Сделано ли так, что чтение из /sys/kernel/debug/timer-irq выдаёт уже настроенные таймеры?
    • 0
      На данный момент нет. Хотя да, надо бы.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное