Eddy_Em

Попробуйте нормальные свободные вещи для работы с USBTMC, гугол сразу же мне выдал вот это. В любом случае, сдается мне, что проще свое будет написать, руководствуясь документацией, чем гадать, что там в этом "черном ящике" от непонятно кого!

Моховские железки вполне надежны, согласен. Но цена!.. Да и бывает проблемка, что некоторые железки в линуксе не работают - и зачем такое вообще делать? Что до цены, то просто для сравнения: самодельный переходник usb-can с гальваноразвязкой - около 600р (себестоимость включает заказ плат в Китае). У мохи я дешевле 8000р не видел почему-то ...

Кто-то чересчур перестарался. Я же выше писал: есть socat, так зачем извращаться со всеми этими делами? Ну, в принципе, если с обоих концов модбас, а не нормальный протокол, то придется, наверное, и поизвращаться. Но с модбасом компьютер не может работать через переходники CAN-USB (т.к. они кэшируют данные), т.е. придется все равно делать свой аппаратный modbus-USB. А коль так, то отпадает необходимость в написании софтовой прокладки для сетевой передачи данных: ведь есть же socat! А особо ударенные могут обернуть трафик socat в ssh, чтобы уж совсем враг не смог вам в туалете свет выключить :)

Лучше кривой модбас реализовать в виде конечного автомата: ты ему в кольцевой буфер отправляешь структуры данных, которые нужно будет переслать, а он уже самостоятельно по прерываниям контролирует паузы и т.д., и т.п. В суперлупе каждый проход вызывать этот modbus_process(). Вот с приемом намного проще, двух буферов-структур хватит: заполняешь себе посредством DMA один буфер, как только получил прерывание idle, выставляешь флаг готовности буфера и начинаешь заполнять второй. А в суперлупе какой-нибудь modbus_incoming() будет обрабатывать данные из этого буфера. В общем, даже если требуется несколько усартов контролировать, все это элементарно решится одним систиком и парой указанных функций (а там уж внутри будет рассматриваться источник и т.д., и т.п.)

Неужели у уартов STM32 нет флага, который выдерживал бы заданную паузу после передачи последнего символа из посылки DMA? Ну, даже если так, можно кривой модбас хоть на шести уартах одновременно реализовать при помощи всего одного систика, просто счетчики отдельные завести на каждый уарт.

А можно пример хотя бы одного свободного такого поделия под Linux? Как, нет его? Ну, тогда чего удивляетесь, что люди свои протоколы пишут? Может, оттого, что под форточками охранную систему только совсем сбрендивший будет делать?

Это элементарно делается при помощи socat. С одной стороны открываем "серверный сокет" и организуем связь между ним и /dev/ttyUSB0 (или какое там устройство переходника на 485), с другой стороны - "клиентский сокет" и аналогичную связь. И готово: через сокет вся информация из одного порта будет писаться в другой и обратно. Если же у вас вместо компьютера игровая приставка, то уж ССЗБ, что сказать!

Для этого не нужна ФС вообще! В простейшем случае можно считывать дамп флешки при помощи dd. А про модуль FUSE я уже писал. Не надо нагружать МК лишней работой. Зачем ему знать о файловых системах, если нужно просто данные на флешку записать? Пусть пишет себе последовательными блоками. А уж софт на компе разберется, как это считать. А если человек не умеет пользоваться элементарной командой dd, гнать его в шею с работы на обучение! И пока не научится владеть компьютером хотя бы на уровне "начинающего юзера", до работы не допускать! Это пока их руководители настолько глупы, что согласны держать некомпетентных на ставках! Вменяемый руководитель как минимум всех на курсы отправил. А еще лучше - сразу брал бы соображающих сотрудников на работу, чтобы не нужно было еще деньги и время на обучение тратить - этим они сами должны были заниматься до того, как на работу устроиться. Если человек не понимает, как собрать ядро, то компьютер ему в работе однозначно только во вред! Пусть на абаке считает и в тетрадку записывает.

Зачем такая дикая свистопляска с таймерами ради модбаса, когда есть регистр RTO? Получили прерывание по таймауту - выставили флаг - поменяли приемный буфер, а в суперлупе, как увидели флаг, обработали принятые данные!.. В случае с DMA нужно лишь, чтобы буферы были достаточно большими. В обработчике прерывания по таймауту отключаем DMA, меняем буферы, ставим флаг - вуаля!

Надо было просто загуглить момент инерции стержня, коль вывести лень. J=ml²/3 → из второго закона Ньютона получим момент силы как произведение момента инерции на угловое ускорение. Ускорение у вас наверняка будет меньше радиана в секунду за секунду, так что, можно считать, что ml²/3 будет являться самой верхней границей для выбора момента силы двигателя. Получается, что для трехметрового шлагбаума массой 5кг момент силы движка в пределе будет 15Н·м, а в реале намного даже меньше.

Не надо ext4: она чрезвычайно жирная. Лучше выдернуть из старых ядер модуль ext2 и приколбасить его к микроконтроллеру. Я и сам давно так сделал бы, если б была нужда с флешками работать в виде ФС. Да, кстати, а зачем вам вообще ФС на флешке? Можно же просто линейно писать файлы - примерно как в формате tar, но с обозначением смещения на следующий кусок метаинформации (обычная структура: размер, atime/mtime etc, адрес следующего куска, собственно данные). Можно даже модуль FUSE для такой псевдоФС написать. И еще: на гитхабе есть множество ФС, предназначенных специально для МК. Поищите. Скажем, в данном случае вообще не нужно такое понятие, как директория - нужны лишь файлы, наваленные в корне. Не нужны права доступа. Зачастую даже atime/mtime не нужны - только ctime. P.S. что до VFAT, я никогда не использовал бы ее при работе с МК: во-первых, не встречал ни одной вменяемой реализации; во-вторых, она ужасна; в-третьих, нельзя облегчать вендовозам жизнь! Пусть хоть раз пересилят себя и почитают что-нибудь, кроме фконтактегов. Пересядут на линукс, а там, глядишь, IQ поднимется с 20 до хотя бы 80...

Делаю. Вот, недавно возникла острая необходимость заменить огромный PEP-контроллер. На коленке сварганил на STM32F072 замену - отлично работало. Теперь нужно плату развести. Элементы на али закупили: на 10 плат выходит где-то на 35тыр (уж очень дорогие гальваноразвязки: аж по 250-300 рублей!!! Да и МК нонче дико подорожали: 250-300р за STM32F072C8T6, который еще недавно я по 65-70р брал, да еще и B, а не 8). Плюс сами платы (правда, там я в 10х10см² не влезу, да и, боюсь, придется четырехслойку разводить). А что до частотников, то я давно с ними мучаюсь. SEW'ы уже почти прекратили нормальные приводы разрабатывать. Сименс — дерьмо адово. Всякая дешевая китайщина — вообще жесть (еще и на модбасе убогом). В общем, надо найти хорошего инженера, который высоковольтную часть спроектирует, да с ним в тандеме разработать нормальный советский частотник. На нормальном CAN-протоколе (а не убогом CANopen или еще какой-нибудь мерзости). Сделать конфигуратор из ini-файла или JSON-файла, да и все будет здорово.

Я таки повторю вопрос: почему ядро свертки не нормировано? Ведь результат операции сильно будет искажать амплитуду сигнала! Ну и да: коль уж вы отбрасываете крайние значения (т.е. делаете из автокорреляции гауссианы какой-то "колокол"), то можете вообще сразу использовать колоколообразное ядро. Смысл сворачивать с гауссианой (нормированной, еще раз повторю!) в том, чтобы эмулировать прохождение сигнала через некий набор фильтров с рандомным распределением (что в итоге сведется - согласно закону больших чисел - к гауссовой аппаратной функции). Если вам нужно элементарно сгладить, вы вообще можете взять ядро вида 1/N*[1 1 ... 1] (N раз), что осуществит вам операцию скользящего среднего по N элементам. Ну или распределяйте как-то веса, скажем: 1/50 * [1 4 40 4 1].

Такой сбой приведет к вызову обработчика HardFault, который по умолчанию "завешивает" МК намертво. А если вы туда воткнули рестарт, то это - ваша проблема, что вы не сделали его корректным. Лично я из стартапа выбросил сброс периферии - нет смысла на это такты тратить.

Мужики, вы реально хотите противостоять дебилу с электрошокером, который открутит кнопочку и подключит этот электрошокер к проводам? А смысл? Такие дебилы что - каждый день приходят? Внешнюю кнопку можно просто повесить на опторазвязку. Запитать от маломощного гальваноразвязанного DC-DC за бакс. И сделать обычным отдельным модулем, легко подцепляемым к основной плате. Сдохнет - ну и хрен с ним! Просто заменить на новый, цена которому - пара сотен деревянных!!! P.S. А цены на нынешние "из коробки" СКУД настолько завышены, что я просто в шоке! Когда разберешься с их схемотехникой, понимаешь, что такое [censored] можно сварганить из самых дешевых китайских компонентов (как, собственно, это УГ и сделано), как минимум, на порядок дешевле! Да еще и сделать свой нормальный протокол, а не это огороженное УГ!!!

ОК, здесь нужно будет хэширование всего и вся. Но на формате "пара миллионов строчек данных" разница будет вообще неощутимой! С современными мощностями серверов тупой линейный поиск по бинарной базе в сотню мегабайт (которая еще и в /dev/shm хранится) это потребует несколько миллисекунд. По крайней мере, мой демон, работающий с запросами к этой импровизированной БД, крутящийся на несчастной железяке 10-летней давности, выдает желаемые результаты достаточно быстро (меньше пары секунд, как и положено для веб-морд).

А я на "почти 10 лет" могу только простейшим логгером похвастаться (UNIX socket + бинарное логгирование, а для ускорения дополнительно хранится файлик со смещением через каждые несколько тысяч порций данных). В остальном же примерно так же: для логгирования жестко фиксированного набора параметров нет никакого смысла БД использовать. Тот же SQLite в разы жирней будет, чем тупой бинарный лог. Для логгирования же "всего подряд" годится только текстоывй файл (но и разбираться в нем - ад). В общем, если мне нужно каждые 15 минут сохранять температуры 60 точек, я просто буду сохранять это в виде бинарной структуры {magick, timestamp, array[60]} и параллельно вести файл смещений с определенным шагом по timestamp (чтобы потом бинарным поиском быстрей можно было найти нужные смещения).

Такое разве что распоследнейшему абдуринщику в голову придет. Грамотный инженер - прежде всего специалист. И всяким кривым он уж точно пользоваться не будет.

Какой-то у вас Гаусс совершенно неправильный: почему нормировка отсутствует?

Так и есть: просто выполняется сверка с результатом автокорреляции гауссианы. В общем, если не устраивает однократная свертка с гауссианой, то просто увеличьте сигму! Либо можно другую функцию фильтрации выбрать. Все зависит от оригинального сигнала. Может, там вообще вейвлет-фильтрация лучше будет (заодно избавитесь от проблемы с краевыми эффектами из-за применения БПФ)?

Может, неплохо было бы еще и гальваноразвязку поставить? Только все равно это на "отечественной элементной базе" никак не сделать, увы... Придется у китайцев вражеские микросхемы закупать. P.S. Рисую несложную штукенцию, где в разных цепях гуляют вполне себе приличные потенциалы, пришлось вообще все развязывать (пробовал без развязки USB - при подключении ноутбука МК перезагружается!). Уже какая-то жесть вышла…

Тогда все значительно проще: сгенерировать постскрипт-файл! А его уже и печатать... Можно простой командой [inline]cat file.ps > /dev/lp0[/inline] (если принтер нормальный, конечно). Ну или стандартным [inline]lp file.ps[/inline]. Но таки лучше не напрягать МК такими суровыми задачами. Например, можно сделать связку: Orange Pi Zero (около 2000 рублей сейчас стоит) или просто Orange Pi (около 2500) + микроконтроллер. Одноплатник пусть с МК общается, а через веб-морду или standalone приложение пользователь будет общаться с одноплатником. Настроить печать на одноплатнике - вуаля! Нажал пользователь в веб-морде кнопочку "печать отчета", и принтер радостно зажужжал! P.S. А вообще, я заметил, что вендузятники - люди крайне алогичные. Они любят искать проблемы на ровном месте и решать их совершенно дикими способами! Что-то у меня есть подозрение, что ТС ни о техе/латехе не слыхал, ни даже о постскриптах!

А не проще на МК генерить латеховский файл, а уж на ПК его компилировать? Или еще лучше: пусть МК генерирует файл с отчетом, а ПК его обрабатывает, генерирует латеховский исходник и компилирует его.

У ST же есть отличные сниппеты для STM32F0! Советую попробовать. Вот, сам оттуда брал и малость под себя изменял.

Все нормально: ведь USART тоже буферизуется, так что, окончание пересылки через DMA вообще не означает, что USART тоже все передал! Но это и не важно: все равно ведь уже можно запускать следующую транзакцию...