0
В имеющемся арче halt и shutdown не одно и тоже:)
shutdown -P завершает работу и выключает питание, все светодиоды на плате тухнут и все отключается, т.е. никакого там уровня нет, и даже говорить что там HI-Z наверное не совсем корректно.
halt завершает работу системы, но не выключает ее питание (у меня 3 раза подряд получилось, что вывод в высоком состоянии остался ). Это видно и потому что красный светодиод продолжает гореть.
  • avatar
  • kest
  • 12 августа 2014, 15:20
0
не дописал… еще тут гляньте:
rus-linux.net/MyLDP/BOOKS/Moduli-yadra-Linux/06/kern-mod-06-26.html
  • avatar
  • kest
  • 09 августа 2014, 22:26
0
Думаю лучше попробовать повесить свое прерывание на второе ядро (я кажется видел функции для этого, но прям так уже не вспомню).
dmilvdv.narod.ru/Translate/LDD3/ldd_implementing_handler.html
  • avatar
  • kest
  • 09 августа 2014, 22:24
0
Может и есть, но для второго я арч не нашел, потому и выложил тут свой.
ЗЫ делал через виртуальную машину(с убунтой) из под винды
  • avatar
  • kest
  • 09 августа 2014, 22:01
0
У первого одно ядро, у второго два => ядра не совместимы, а значит и образ не пойдет
Для первого установка арча: archlinuxarm.org/platforms/armv7/allwinner/cubieboard
  • avatar
  • kest
  • 09 августа 2014, 21:40
0
Компилятор при использовании iowrite вставляет барьеры синхронизации, которые заставляют нас ждать пока все операции завершатся и данные будут сохранены. если их убрать — скорость работы с gpio возрастает(у меня получилось ~в 2 раза). При этом эта пауза сильно от нагрузки зависит.

До DMA пока далеко, я про это не смотрел даже еще ничего + на мк только один раз использовал. А для чего вам DMA надо? :)
  • avatar
  • kest
  • 09 августа 2014, 21:34
0
частоту не мерял, но для GPIO предел, который я смог достичь — скорость записи(не RMW, а чисто запись ассемблером) порядка 30 МГц
  • avatar
  • kest
  • 09 августа 2014, 15:04
0
Ну хотябы та-же робототехника. Воткнул WiFi и камеру в USB, подключил моторчики(а вот для них уже нужны «драйвера»: аппаратные и программные.). Уже можно кататься. Далее навешивать датчики — а тут уже без драйверов не обойтись.
  • avatar
  • kest
  • 06 августа 2014, 15:22
0
Так а SPI аппаратный есть же, драйвер стандартный мне запустить удавалось. Правда не использовал, только осцилом посмотрел выдает ли то что пишешь — выдавал.
Прерывания и таймеры я осилил(DMA пока даже не смотрел), но пока не описал(начал в черновиках), т.к. занимаюсь повышением быстродействия GPIO (2Mhz маловато) и с RMW доступом… В ARM ассемблере похоже нет инструкций побитового доступа к регистрам. Вам это как-то удалось с GPIO решить?
  • avatar
  • kest
  • 05 августа 2014, 21:20
0
Мифическая цифра 500КГц образовалась из ожидаемой максимальной тактовой частоты АЦП
Все это конечно не гарантируется, разве что изменение частоты должно компенсироваться(не проверял), т.к. есть как минимум прерывания. Но в обычном МК прерывания тоже есть, но с этим все мирятся.
  • avatar
  • kest
  • 04 августа 2014, 00:56
0
Смотря какой входной сигнал.
Если параллельный то варианты:
использовать младшие разряды какого либо порта и как в этом модуле: читать, накладывать маску и отдавать. Но скорее всего стоит использовать DMA. А еще как минимум в А20 есть специальный потоковый порт: страница 784 в мануале
Если какой-то последовательный интерфейс — тот уже сложнее. Кстати я на неделе попробую померить максимальную частоту, генерируемую из модуля ядра.
  • avatar
  • kest
  • 03 августа 2014, 23:46
0
  • avatar
  • kest
  • 03 августа 2014, 21:16
0
да-да, эту статью видел. И ссылку из нее к The Linux Kernel Module Programming Guide читал.
  • avatar
  • kest
  • 03 августа 2014, 20:02
0
А Вы тоже занимаетесь разработкой аппаратуры под линукс? Откуда информацию берете? :)
  • avatar
  • kest
  • 03 августа 2014, 19:26
0
О, таки есть люди «в теме».
По поводу неточностей — виноват, будем стараться:)
А касаемо sysfs: тоже читал, что оно для настроек ядра… Но модуль sunxi-gpio(там вся работа ведется через /sys/class), в котором я подсматривал некоторые моменты, слишком уж убедил, что sysfs это хорошо:)
  • avatar
  • kest
  • 03 августа 2014, 19:24
0
На Allwiner A10? Или чья-то еще?
  • avatar
  • kest
  • 03 августа 2014, 18:51
0
  • avatar
  • kest
  • 29 июля 2014, 21:54
0
не дописал:
Один раз посчитать на калькуляторе руками и округлить частоту в большую сторону до ближайшего целого? Или до десятков-сотен(так же в большую сторону), чтобы обеспечить кратность 1 мс. Все равно это значение не изменяется динамически(хотя подозреваю это возможно при необходимости).

Или какую формулу предлагаете вы? В статье я нашел только определение соотношения времен.

Кстати, а если задач будет не 1 и не 2 а 5, 10 и дальше, то что станет с числом 34?
  • avatar
  • kest
  • 28 июля 2014, 18:07
0
Чтобы не сталкиваться с дробными числами чего?
Не пользовался freeRTOS и что конкретно делает этот макрос не знаю, но почти уверен что он не будет оперировать дробными числами при расчете задержки.
  • avatar
  • kest
  • 28 июля 2014, 18:01
0
В линуксе частота переключения задач ядром рекомендуется 1000 Гц для новых ядер.
Для старых было 100 Гц. И я таки не увидел формулу сколько мне необходимо герц :)

Предлагаю такую формулу:
f=n/(0.7*Tr)
где Tr — максимально допустимое время реакции системы, n — число потоков, 0.7 — 30% запас.
При этом необходимо, чтобы критичная ко времени реакции задача выполняла цикл не более чем за Tr. Это если нет приоритетов у задач. Если приоритеты есть, то можно считать n=1 и критичная ко времени задачи должна иметь макс. приоритет
Если критичных ко времени задач несколько, то уже интересней:) возможны компромиссы в зависимости от приоритетов, требуемых времен и др
  • avatar
  • kest
  • 28 июля 2014, 17:42