Board.KolibriOS.org

Я написал драйвер для USB-to-COM конвертера от конторы FTDI. Стало ясно, что использовать драйвер, как прослойку между программой и виртуальным COM-портом не слишком практично и удобно, в том числе и потому, что подобные конвертеры производят разные фирмы (и для каждого нужен будет свой драйвер). Поэтому будет разумно написать прослойку (подсистему) виртуальных COM-портов, аналогичную Windows. Предлагаю обсудить подробности реализации, после чего я возьмусь за это дело. Пока я это представляю, как процедуру RegVCP() для драйвера. И доработка одной из системных функций, чтобы не пришлось переписывать программы, которые уже работают с COM-портом

I've developed driver for USB-to-COM converter from FTDi company. It became clear, that using driver to communicate with virtual COM-port not that handy and easy, also because there are many converters from different manufacturers (and each require own driver). That's why it is reasonable to develop Virtual COM Port (VCP) subsystem, like windows' one. As for now, I think it should look like RegVCP proc for driver. And rework of one of sys funcs, to make unnecessary rewriting existing programs, which use COM-port

Not many applications use the com port right now.
And the ones that do, access the I/O ports directly. They will need to be rewritten.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein

Ah, yes. Really sysfunc 46 only reserves, I thought it whole interface)

gtament
Да, кроме стандартного RS232 у всех чипов имеется свой собственный функционал, доступный через дополнительные порты, MMIO или конфигспейс.

И люди выбирают конкретный чип не только ради стандартных COM-портов, но и еще и ради этих дополнительных печенек - RS485, GPIO, встроенного счетчика событий и что у них еще там наворочено.

Предусмотрен ли у тебя доступ к этим печенькам, или легче просто открыть для юзера все порты и MMIO?

В данном случае речь идет только о подсистеме виртуальных ком портов, прослойке между драйвером конкретного устройства и пприложением. Для ее работы по-прежнему нужен полноценный драйвер, который и будет реализовывать все то, что ты выше озвучил. И если кому-то эти плюшки понадобятся, то ему придется обращаться к устройству через драййвер и IOCTL. Надеюсь, понятно ответил

Кто-нибудь этим занят сейчас? Если нет, то возьму эту таску себе. В планах:

• Сделать в ядре базовую поддержку последовательных портов: вынести в экспорт функции для добавления/удаления, добавить системный вызов для приложений (перечисление, открытие/закрытие, запись/чтение, настройка параметров, аппаратный контроль потока);
• Написать отдельный драйвер для стандартных портов;
• Адаптировать usbftdi (возможно впоследствии написать универсальный usbcdc?);
• Поправить system/terminal для работы с новым API.

какая то библиотечка про UART пробегала

Sh@dy , было бы здорово всё это реализовать!
Как будет что потестирвать — выкладывай.

Хочу добавить новое событие для подсистемы последовательных портов. Назначение события пока что два:

• уведомить все приложения о том, что в системе появился/исчез порт
• уведомить приложение, открывшее порт, что доступны данные для чтения

В связи с этим вопрос: EVENT_EXTENDED, судя по всему, сейчас не используется. Можно его заменить?

I don't think EVENT_EXTENDED is to be used for that. There are virtual com devices, usb devices, ahci devices, network devices, etc: using a new event for each device type seems to be wasteful and just an improper design. I don't know what design would be a proper one though . It often happens in KolibriOS that to solve problem Y you have to solve problem X first. May be this is the case too.

Спасибо за ответ. Я согласен с тем, что добавление очередного события, возможно, является не лучшим выходом в этой ситуации. Оставлю пока в стороне реализацию событий от последовательных портов. Данные от них можно будет получить просто по запросу.