|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 21 Dec 2004 22:31:06
To : Victor Wagner
Subject : Re: драйвер
--------------------------------------------------------------------------------
Dec 21 09:01 04, Victor Wagner wrote to Zahar Kiselev:
VW>>> А кто тебе сказал, что не будет иметь смысла управлять
VW>>> платой из скриптов на bash?
ZK>> Математические действия на данными в скриптах на Баше - ну
VW> Hу не из скриптов на баше, а из скриптов на octave.
Я бы кстати не отказался, если бы в octave можно было присобачить какое-то
удобное средство читать данные с устройства. Hо то что я нашел в качестве
примера(чтение со звуковой карты) - ну очень топорно сделано.
Вот если бы вкомпилировать в octave функцию, возвращающую данные с АЦП, так
чтобы ее можно было вызывать из встроенного скриптового языка... Hо на это у
меня не хватит квалификации - слишком велик объем исходника чтобы я в нем не
"утонул".
VW> Кроме того, задачей шелловского скрипта может быть преобразовать
VW> данные в формат, понимаемый каким-нибудь gnuplot.
Вот как раз в процессе преобразования данных и требуются математические
действия. Hу-ка представь медианную фильтрацию на баше? А без нее "мусорные"
отсчеты на графике некрасиво "торчат" в стороны от основной кривой.
Поэтому у меня есть небольшой исходник на Си, размером экрана два, который я
почти что под каждый сеанс измерений правлю и переделываю(обычно это надо если
датчики заменил на другие или по-другому к установке присобачил). Вот эта-то
программка данные в порядок и приводит- используется как фильтр, напускаешь на
файл с исходными отсчетами - получаешь другой, с обработанными. Решение может
быть не очень эстетичное, но простое, понятное и удобное. Хотя я бы предпочел не
Си, а паскалеподобный язык. Даже довольно хорошо знакомую мне Аду, но для нее у
меня под линукс нет библиотек для удобного чтения файлов(то, что прилагается к
языку по умолчанию - прошу не предлагать). Вот в досе у меня такие библиотеки
были, как и вообще куча полезных функций.
ZK>> высокой частотой увеличение потока данных будет такое, что
ZK>> не хватит производительности машины.
VW> Ой, не факт. 12 бит - 3 шестнадцатиричные цифры. Плюс один пробел. И
VW> того четыре байта. Увеличение потока данных всего втрое.
Hу если втрое это "всего" - то я молчу:)
ZK>> засунуть. А отсутствие файловой системы проблематично по
ZK>> причине необходимости места для хранения собранных данных.
VW> А нафига их хранить?
А чтобы с snmp и прочими предложенными сетевизмами не возиться.
Вот когда на этот проект выделят финансирование эдак с полмиллиона - тогда можно
будет подумать о солидном измерительном комплексе вокруг установки,
с передачей данных по сети и рисованием кривых на экране в реальном времени.
Потому что ползущие по экрану кривые хорошо потенциальным заказчикам
показывать:) А "для себя" - и нарисованного за чашкой чая после испытаний
графика более чем достаточно.
VW> Пусть двадцать таких мелких машинок по углам здания эти данные цифруют, а
VW> один большой сервер их тут же собирает и обрабатывает.
VW> Я могу представить себе много случаев, когда такая система окажется
VW> надежнее хранения данных непосредственно на месте измерения.
Полностью согласен. Hо это несколько другой масштаб уже. Вот если денег дадут -
тогда будем подобные монстрообразные системы создавать:)
VW>>> Так что чем меньше странного ты хочешь, тем лучше.
ZK>> В общем случае верно, но если бы автор Линукса не хотел
ZK>> чего-то странного - он не создал бы Линукс:)
VW> Заметим что он не хотел странного. Он хотел под имеющееся железо
VW> операционную систему, похожую на хорошо известный ему Unix, только
VW> помощнее имеющегося у него Minix, и полнее использующую возможности
VW> железа.
Заметим, что он хотел систему под свое железо вместо того, чтобы сменить железо
на то, которое считалось актуальным на тот момент и поставить туда единственно
правильную ОС :-)
VW> То есть он руководствовался сложившимися традициями.
Hу действовал-то он правильно. Хотя и несколько нетипично для обычного человека.
VW>>> Hу естественно. Это же реализации системных вызовов
VW>>> write(2)
ZK>> Вот меня и заинтересовало - что будет если я его из кода
ZK>> ядра вызову? Hаткнусь на проблему "повторной невходимости"
ZK>> как в досе или нет?
VW> Боюсь что ты наткнешья на проблему kernelspace vs userspace.
VW> А то что из этого следует, что sys_write может привести к странным
VW> эффектам, так как ожидает буфера отнюдь не в ядерном пространстве, не
VW> очевидно?
А в этом месте я уже покопался. И выяснил, что с какой-то там версии ядра
распределение и отображение памяти поменяли так, что указатель, действительный в
пользовательском пространстве, остается таковым и в пространстве ядра.
Как совершенно верно ранее было замечено - использовать этот эффект напрямую не
рекомендуется - надо проверять высвоплена эта страница или нет. А вот при
использовании "наоборот", когда буфер находится в пространстве ядра, на
высвопленность можно не проверять - так как ядро всегда в памяти. То есть вызову
sys_write теперь должно быть все равно где находится подсунутый ему буфер:)
VW> Повторной невходимости быть не может, так как система -
VW> многозадачная.
Вот только во всяких интернетных статьях попадались намеки, что ядро внутри себя
работает последовательно. Я не уверен в том, что правильно понял то что там было
сказано и что сказанное имеет отношение к данному вопросу.
VW> И этот самый sys_write зовет одновременно куча разных процессов.
Зовет-то одновременно, а вот обрабатывается оно как?....
И одновременные запросы можно ведь в очередь поставить...
Zahar(@spbdept.rbc.ru) Остров Большой Березовый: http://birch-island.spb.ru
--- Msged/LNX 6.1.1
* Origin: N:60.17'54" E:28.39'40" (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
