Tarbal

Фильтровать надо.

Много лет назад я поступал таким образом: Брал источник переменного напряжения и последовательно с лампочкой включал резистор. Номинал такой, чтобы про максимальном напряжении достичь наивысшей желаемой точки на характеристике. Точку соединения резистора и лампочки заземляем (в смысле к земле осциллографа подключаем), а к свободным концам резистора и лампочки подключаем незаземленное (хотя бы для осциллографа) переменное напряжение. Допустим с трансформатора. Второй конец лампочки ко входу осциллографа X в X-Y режиме, а второй конец резистора к Y входу. На экране наблюдаем желаемую характеристику. X - напряжение, а Y - ток. Одно неудобство -- характеристика зеркальна той, что обычно рисуют на бумаге из-за разной полярности тока и напряжения. Если есть инверсия входа, то включите ее для тока и все будет точно.

Да ладно. Все давно применяют Линукс в в коммерческих и серьезно-ответственных девайсах.

Да. Прикольный способ. Активная микросхема по адресу 0, а все остальные имеют другой адрес. Обращаемся всегда с адресом 0.

Я не сталкивался с такой проблемой, хотя много раз подключал UART к различным карточкам, включая малину. Все контроли отключены. Все работает нормально. Проверьте кабель и разъемы. Попробуйте с другим компьютером. Короче ишите комбинации, что работают. Это поможет локализовать причину. Если вас устраивает посмотреть последние системные сообщения после загрузки, то в терминале исполните команду dmesg. Это о том, что некоторые вещи можно сделать и другим путем.

Коммутировать сигнал идущий на динамик нехорошо. Красиво и дешево не получится. Лучше коммутировать перед усилителем мощности.

Работал с индусами. Это отдельная и грустная песня.

Мне сказал разработчик програм на Java, а не создатели Котлина. Он не для Андроида пишет. Смешной вы. Я не встречал электронщиков даже не авторитетных, которые бы интересовались Java. Разве что сам, когда изучал андроид.

Речь не идет о поддается обнаружению. Если в дереве устойств есть и зарегистрирован драйвер, то драйвер ставится и устройство готово работать. Для pug&play устройств тоже надо в дереве описывать. Там просто еще дополнительный механизм. Почему описывают структуру platform device я уже написал. До версии ядра 3.Х.Х все устройства описывались структурами, а после появилось дерево, которое компилируется отдельно и не надо перестраивать ядро. /dev это не то же самое что /proc и /sys две последние примерно одно и то же. первая пришла из юникса. В них отображаются внутренние структуры ядра, а в /dev расположены pipes для связи с устройствами. Все драйвера, к которым нужно иметь доступ из пространства пользователя отображены в /dev.

Мне рассказал о Котлине приятель, работающий в Канаде. Он крутой спец по Java, но говорит, что они перешли на Котлин и довольны. Я на С пишу и мне мало понятны его доводы, но к сведению принял.

Случайно увидел ваш вопрос. Пишите про Линукс в теме Линукс. 1) Не рекомендуется писать драйвер под файловую систему /dev. Раньше конечно так делали. Сейчас, якобы актуально писать под файловую систему /proc или /sys. Верно ли это? Хочется сразу научиться праивльным вещам. maniac.gif Т.е. может при написании драйвера под какую-нибудь фс скрываются ккаие-то подводные камни. И есть резон писать под другую фс. В этом вопросе каша. На самом деле все происходит таким образом: Вы регистрируете драйвер, ядро записывает информацию о нем в соответствующие структуры и драйвер появляется в /sys/. В дереве устройств вы описываете устройство для этого драйвера (в /sys появятся записи об устройстве) и если они (драйвер и устройство) соответствуют друг другу, то вызовется функция драйвера probe. Если probe не вернет ошибку, то устройство встало и подключилось к драйверу. Если у вас написано правило для этого устройства в правилах udev, то в /dev появится псевдофайл для доступа к вашему устройству. Если нет, то его можно создать при помощи команды mknod. platform device: Вы наверняка за обилием информации не заметили важнейшего момента, что драйвер и устройство должны СООТВЕТСТВОВАТЬ друг другу. На самом деле драйверы (о блоковых драйверах мы вообще не говорим) подразделяются на несколько групп. Список этих групп вы найдете в разделе шин: /sys/bus/ Оказалось, что есть такая группа, которую ни к одной шине отнести нельзя. Ее назвали platform. Внутри каждой группы свои правила по которым проверяется соответствие драйвера и устройства. Для PCI и USB это Vendor ID и Product ID, для platform это просто текстовое имя. Это должно совпасть в драйвере и устройстве. На самом деле есть еще нюансы, но в целом картина выглядит таким образом. В этом тексте все описано для ядер до 2.6.Х включительно. С 3.Х.Х вместо структуры устройства в тексте программы начали описывать устройства в дереве устройств. Можно на все положить и сделать нестандартно, но так профессионалы не будут делать. Сделать доступ к программе (не могу назвать это драйвером) через интерфейс /proc. Но так сделать легко. Как это делать подробно изложено здесь: https://www.iitg.ac.in/asahu/cs421/books/LKM2.6.pdf Это навскидку нашел. есть и более свежие версии этого документа.

Нужна надежность. Цена не ограничена. Массовости не требуется. Процессор уровня не выше Кореткс М4 Можно и послабее. Даже ATMega какой-нибудь подойдет. Так что Линукс, ethernet, HDMI не надо. Много каналов (40) АЦП неплохо иметь. Но я понимаю, что такого не бывает и наверное придется использовать аналоговый мультиплексор.

Производятся ли в России аналоги (или близкие по устройству) каких-нибудь чипов из семейства ST. Может похозуе на Microchip или AVR есть?

Лучший ответ про output compare и input capture :) Еще можно DMA использовать. Правда на начало приема для синхронизации придется прерывание использовать. Зато передавать можно сразу несколько каналов :) Опять же буферизация получится естественным образом..

Пару лет назад я делал проект на похожем процессоре для Боинга. Там с SPI была проблема. Он (не помню на прием или передачу) младший бит иногда портил. В этом форуме есть моя тема про это. В конце я сделал програмный SPI. Через несколько месяцев вышла errata с описанием этой проблемы. https://electronix.ru/forum/index.php?showtopic=135946