eddy_em

Пока добавлял работу с SI7005, подумал: а ведь датчики AHTxx практически ничем не отличаются (если не заморачиваться, то вообще одним и тем же кодом можно "обслуживать" и AHT1x, и AHT2x), и если у меня их N на шине одинаковых, то будет проблема со статическими переменными в файле → все это нужно вынести в "класс". А как скрыть члены "класса" от пользователя? Объявить typedef на некую структуру, которая будет объявлена "с подробностями" лишь в "private-header". Собственно, даже в glibc такое делают!
Правда, пришлось достаточно "порефакторить". Еще и в "класс" добавить void*, чтобы туда запихивать все нужные калибровки, промежуточные данные и прочее.
Сильно надеюсь, что больше значимых полей (которые нужно будет не нулем проинициализировать) добавлять не придется. Все-таки, с наследованием в С вообще плохо (хотя, можно заморочиться: при "наследовании" от одного "класса" его можно прямо в начало производного подсунуть, а если нескольких - воткнуть union'ы). А вот указателя this вообще нет! Поэтому во все функции "класса" приходится первым аргументом писать ссылку на сам "класс"…
Вот такая дичь получилась.

Репозиторий с кодом.
Сначала избавился от нескольких багов. Потом решил добавить сетевой функционал. Ну, а коль сеть — то и кольцевой буфер нужен. В общем, теперь там — не просто макросы и функционал, который в 99% случаев нужен (тот же разбор параметров командной строки), но и дополнительные облегчалки.
( Подробней )
Теперь как минимум все, что пользуется этой библиотекой, надо обновить. Ну, а сетевые демоны роботелескопов вообще радикально так переделать: чтобы "шапкой" с метеоданными не демон монтировки занимался (что вообще нелогично), а демон погоды; чтобы демоны купола, монтировки и телескопа "слушались" демона погоды. Скажем, если стоит prohibited=1, то прекращать наблюдения, когда они идут, или не давать наблюдателю открыться. Вот на БТА такую функцию АСУшник выполняет (правда, некоторые из рук вон плохо работают, позволяя наблюдателям-вредителям открывать телескоп при влажности свыше 90%, облачности или даже тумане). А на Ц-1000 почему-то до сих пор нет такого "супердемона", который бы "давал по шапке" наблюдателям-вредителям. Иначе угробят телескоп, а за это даже никакого наказания не понесут (я бы отстранял наблюдателей минимум на полгода от наблюдений, если они открывают телескоп тогда, когда этого делать ни в коем случае нельзя).

Пока с заглушками, ковыряюсь. Читаю исходник модуля ядра и не понимаю: функция usb_xfer принимает массив структур i2c_msg. У каждой структуры есть поле адреса, соответственно, подразумевается, что каждая такая посылка должна начинаться со START, потом отправка адреса, а заканчиваться выставлением STOP. По крайней мере, именно так я и реализовывал все функции работы с I2C на STM32. А тут — в начале выставляют START, потом пишут/читают все N сообщений, и лишь затем STOP! Неужели оно так будет работать? Что-то сомневаюсь… Посмотрел исходники "robotfuzz" — там та же бодяга, только, похоже, START выставляют на каждое сообщение, а вот STOP — только в самом конце.
Полезу ка, почитаю мануал на МК: вдруг так правда можно?
( tl;dr )
В общем, ближе к выходным еще повожусь с железякой. Основная задумка — попытаться на ее VID/PID поднять CDC. Понятно, что эмуляцию PL2303, увы, уже так не сделать, но вот "обычный унылый" /dev/ttyACMx, возможно, получится. Вот тогда все будет замечательно. А если нет, то хорошо бы поискать, существуют ли вообще среди простых STM32 МК, которые не приколачивают гвоздями в регистры USB номер, полученный при энумерации — чтобы можно было на них эмулировать USB hub.

P.S. Кстати, слышал обидную новость: нацик выкинул из ядра поддержку reiserfs. Уныло, однако. Теперь уж точно придется до определенной версии ядро заморозить. А когда уже HDD или SDD с корнем помрут — ставить систему почти с нуля, но уже на другую ФС. Правда, я понятия не имею, какую ФС сейчас для корня использовать. Не ублюдскую же ext4! Да и где гарантии, что с той же ZFS не поступят аналогично, как с reiserfs?

Решил было сэкономить объем text-секции в микроконтроллере и используемые по нескольку раз строковые константы объявить именно как константы. Однако, gcc, зараза такая, не хочет при компиляции в массив, использующий эти строки, подставить именно переменные, несмотря на то, что они - константы. Вот простой пример:

#include <stdio.h>

static const char * text1 = "One";
static const char * text2 = "Two";
static const char * text3 = "Three";

static const char * const array[3] = {text1, text2, text3};

int main(){
	for(int i = 0; i < 3; ++i) printf("%d: %s\n", i, array[i]);
	return 0;
}

Выхлоп:

gcc 2.c 
2.c:7:39: ошибка: элемент инициализатора не является константой
    7 | static const char * const array[3] = {text1, text2, text3};
      |                                       ^~~~~
2.c:7:39: замечание: (где-то рядом с инициализацией для «array[0]»)
2.c:7:46: ошибка: элемент инициализатора не является константой
    7 | static const char * const array[3] = {text1, text2, text3};
      |                                              ^~~~~
2.c:7:46: замечание: (где-то рядом с инициализацией для «array[1]»)
2.c:7:53: ошибка: элемент инициализатора не является константой
    7 | static const char * const array[3] = {text1, text2, text3};
      |                                                     ^~~~~
2.c:7:53: замечание: (где-то рядом с инициализацией для «array[2]»)

Однако, вот так прокатывает:

#include <stdio.h>

static const char * text1 = "One";
static const char * text2 = "Two";
static const char * text3 = "Three";

static const char ** const array[3] = {&text1, &text2, &text3};

int main(){
        for(int i = 0; i < 3; ++i) printf("%d: %s\n", i, *array[i]);
        return 0;
}

Ну, значит, придется делать массив указателей на указатели…

Добавил в ccd_capture плагин для "генерирования звезд". Пока он совершенно тупой, и не факт, что я все баги обнаружил, но уже кое-что: можно, не дожидаясь собирания стенда, тестировать алгоритмы автогида в разных условиях. "Звезды" генерируются по функции Моффата, всего их может быть до 32 штук в кадре (задаются координаты в угловых секундах и аппаратные звездные величины такие, что 0m соответствует интегральный поток в 65535/255 ADU в секунду в зависимости от выбора - 16 или 8 бит).
При желании добавляется пуассонов шум (медленно работает, зараза, надо будет, наверное, еще что-то попроще придумать). В принципе, весь алгоритм максимум на openmp, поэтому жутко медлительный — сто кадров 1000×1000 пикселей в секунду никак не получить. Возможно, надо будет как-то оптимизировать.
Еще умеет добавлять аддитивный фон (любое 8-битное монохромное изображение) - можно эмулировать всякие нехорошие условия с фоном (типа бликов, кривой подложки и т.д., и т.п.). Ну и бинарная маска - чтобы эмулировать щечки щели.
Можно задать скорость вращения (типа, не работает деротатор) и смещения (как бы общий дрейф) всего "звездного поля". Плюс флуктуации изображения в рамках заданных. С флуктуациями сиинга и взаимных положений, а уж тем более со спеклами я не связывался. И так все жутко тормозное получилось: хотелось бы, чтобы эмуляция 10мс экспозиции генерировалась не больше этих самых 10мс, а тут все 20 с хорошим шумом и всем фаршем выходит.
Заодно в improclib кое-какие косяки подправил (правда, не все: так, оказалось, что я читаю изображения как 8-битные, независимо от их реальной битности; на будущее надо бы это подправить). Косяки в usefull_macros тоже нашел, но пока не рискнул править: еще по разработке tty_term назрело перейти на termios2, умеющий произвольные скорости tty; ну а сейчас обнаружил некоторые неудобные косяки с парсером аргументов командной строки (просто раньше у меня нигде их не было в таком бешеном количестве, да чтобы еще и часть с короткими вариантами, а часть - только с длинными). В общем, как-нибудь потом…
Со следующей недели уже закончу эти игрища с ccd_capture и перейду на разработку ядра автогида. Уже четвертый вариант будет… Авось, на этот раз им и закончится: аналогично ccd_capture, к ядру будут подключаться внешние плагины, что в теории позволит цеплять его на любой прибор без изменения кода ядра. Как будет на практике - посмотрим. А то меня уже попинывают, мол, когда ж я займусь новой СУ БТА, да еще и СУ тремя новыми телескопами комплекса "Астро-М" (пока там все совсем уныло, СУ надо будет вообще с нуля рисовать).

В прошлый четверг мы поставили новую метеостанцию. Целый день с Амирычем возились, а я вспоминал, как электросваркой пользоваться (уродливо, конечно, надо как-нибудь потренироваться на ненужных железяках).
Таки дописал код демона, буду следить: надо проверить, как вычисляется среднее направление ветра, когда будет более-менее северный.
( Read more... )

В возне с прототипом спектрографа ESPriF, наткнулся на то, что все мои три железяки (контроллер восьми шаговиков, контроллер объектива Canon и контроллер узла калибровки) абсолютно никак в системе не различаются: те же самые VID/PID/Manufacturer (собственно, эмулирую PL2303). Подсказали мне, что можно завести текстовое поле Interface, которое поможет в дальнейшей идентификации. И вот на "заполнялке азотом" я решил поиграться. Заодно лишний раз оптимизировал USB, выкинув ненужные флаги. Все индексы текстовых дескрипторов задаются в дескрипторе устройства и конфигурационном дескрипторе. Скажем: iManufacturer, iProduct, iSerialNumber и тот самый iInterface. Чтобы не запутаться, проще завести enum, его поля и использовать как индексы. Если мы не хотим отдавать дескрипторы, задаем вместо индекса нуль. Ну, а дальше компьютер запрашивает нужный индекс и получает текстовую строку, которую и можно использовать в правиле udev, чтобы вместо кучи /dev/ttyUSBx создать более понятные (например, /dev/nitrogen_flooding0 или /dev/canusb0).
Вот с правилами UDEV пришлось повозиться подольше: благо, есть udevadm test, так что не пришлось постоянно шнурок туда-сюда втыкать/вытыкать. Сложность вызвало то, что поле Interface лежит в одном "устройстве", а поля VID/PID — в "родительских". Как обычно, SO помог в решении этой проблемы (что бы мы без Stack Overflow делали вообще? Я, например, по латеху там кучу проблем решил, ну и сам немного людям помог; да и по C, линуксу, башу…).
Одним словом, чтобы различить устройства с одинаковым VID/PID, нам нужно это правило:

ACTION=="add", DRIVERS=="usb", ENV{USB_IDS}="%s{idVendor}:%s{idProduct}"
ACTION=="add", ENV{USB_IDS}=="067b:2303", ATTRS{interface}=="?*", SYMLINK+="$attr{interface}%n"

Т.е. когда udev будет пробегаться по всем "родительским устройствам", на стадии добавления в систему USB он заведет переменную USB_IDS, а когда пройдется по "дочернему" устройству, проверит, соответствует ли эта переменная нужному VID:PID. Если соответствует — проверит, есть ли поле iInterface (нам не нужно "настоящие" PL2303 там именовать, да и у них все равно нет этого поля), и если оно есть — создаст нужную ссылочку.
В простейшем же случае (в данном) наше устройство отличается от всех остальных полем "DRIVERS" (которое как раз является свойством "подустройства" с полем interface), поэтому можно упростить правило:

DRIVERS=="pl2303", ACTION=="add", ATTRS{interface}=="?*", SYMLINK+="$attr{interface}%n"

Все, как только добавили устройство с нужным полем DRIVERS и существующим атрибутом interface, создастся нужная символическая ссылка.
Теперь достаточно для каждого USB-устройства только лишь менять название этого поля. И в системе теперь не придется перебирать из кучи /dev/ttyUSBx, чтобы найти свое устройство — на него будет удобный симлинк. Да и все демоны будут элементарно стартовать (не нужно будет перебирать устройства и запрашивать "ТЫ ХТО, Э?").

В очередной раз надо "старый новый" автогид делать (практически то же самое, что и на инасановский оптоволоконный спектрограф, но с другим исполнительным механизмом). Решил, что хватит уже одни и те же куски кода туда-сюда таскать, рискуя выдернуть более старую версию с багами. Завел репу improclib и понемногу оформляю код в виде библиотеки. Кстати, с удивлением обнаружил, что у меня уже есть рабочая библиотека для работы с FITS-файлами ☺ Но таки подумал, что не стоит мешать эту библиотеку и ту (лучше в случае необходимости буду с тремя сразу линковать - ведь usefull_macros у меня уже стала обязательной библиотекой).
( Read more... )

Понемногу вожусь с "дофигамоторным" контроллером. Решил сразу протокол делать не с кучей самописных аналогов strcmp, а на основе switch с хешем команды. Для этого взял свой "хешегенератор" и немного переделал: добавил в коды возврата отрицательные ("функция не найдена" и "неверный формат команды"). Функция parsecmd теперь не портит входную строку, что позволяет давать команды с номерами, не отделяя их от команды пробелом (например, goto0=-400, stop5 и т.п.). Старая возможность — номер через пробел — тоже осталась. А в файл test.c я поместил пример работы, когда для нескольких обработчиков используется одна функция (в этом-то случае и нужно в нее hash передавать — чтобы она знала, кто именно ее вызвал). Скажем, есть команды-геттеры вообще без параметров (типа vdd, time или temp) — обрабатываем их одной функцией. Для тех, что с параметрами и номером, сначала вызываем функцию разделения "хвоста" на номер и параметр, а потом, если все ОК, вызываем дальше уже нужную функцию, куда передаем лишь эти найденные номера и строку (которую сразу в число в этой же функции нужно превратить, если у всей группы в качестве параметра int используется). Скажем, move_motor(uint8_t nmotor, int32_t nsteps)…

Закинул код на гитхаб. Помимо старого hashtest добавил еще hashgen, который может генерировать по заданной таблице команд заголовочный файл и исходник, принимающий пользовательскую строку на вход, вычисляющий хеш команды (первое слово) и запускающий соответствующую функцию. Можно проверить это при помощи test.c.
( Read more... )