В общем поскольку народ совсем не в теме позволю себе маленькую ремарку:
— RISC-V это набор ISA (instruction set architecture) открытых спецификаций, которые небходимо соблюдать, что быть RISC-V совместимыми
— есть открытые реазизации процессоров соответвующих данным спецификациям (открытые — есть код, бери и заливай на FGPA или запекай, участвуй в разработке)
— доподлинно известно, что микроконтроллеры по RISC-V уже используют NVIDIA и Western Digital
— Собственно V — означает пятую попытку :-D
Данная инициатива интересна своей открытостью, то есть все открыто и бесплатно.
Вы просто не в теме. HiFive Unleashed — это первая борда на которую можно поставить Linux. Сами процессоры по RISC-V или залитые на FGPA есть уже давно. Собственно уже есть выбор «микроконтроллеров» на RISC-V.
AXIS M3046-V: Защита от внешней среды IP42, IK08
IDIS DC-D3212X: нет
Потом идем и смотрим AXIS:
Approvals:
EMC EN 55032 Class B, EN 55024, EN 61000-6-1,
EN 61000-6-2, FCC Part 15 Subpart B Class A and B,
ICES-003 Class B, VCCI Class B, RCM AS/NZS CISPR 22 Class B,
KCC KN32 Class B, KN35
Safety IEC/EN/UL 60950-1
Environment IEC/EN 60529 IP42, IEC/EN 62262 Class IK08, RoHS, WEEE
Network NIST SP500-267
Это может быть решающим при выборе.
У IDIS DC-D3212X не нашёл информацию по этому поводу.
В общем кто ставит AXIS тот и будет ставить AXIS (как и оборудование Cisco и прочее) потому как корпоративный стандарт (не буду тыкать пальцем, сами знаете кто).
Для остальных я считаю разница в цене не столь существенна, а для кого существенна, найдут что-нибудь подешевле.
Я хорошо разбираюсь в данной теме. Можете почитать мои статьи. Поэтому и делаю замечания, поскольку ваша статья не раскрывает вопрос создания драйвера, можно открыть любой драйвер gpio поверх mmio и мы получим, более внятное представление, как стоит писать gpio драйвер:
1) для mmio можно использовать bgpio_init (написанный кстати нашим соотечественником еще аж в 2010 году), и тогда не надо самому писать однотипные в принципе функции write, read, direction и прочие.
2) для irq в большинстве случаев сгодится irq_chip_generic
3) Их, простите меня, не «разбивают» на банки они уже по банкам находятся.
А оправная точка для любого драйвера GPIO, это не подсматривание в готовую реализацию, а вдумчивое изучения документации на железо.
1) Если говорить про принцип создание драйвера с нуля, то стоило бы начать с описания железа и его регистров управления.
2) Если вы затронули тему идентификации gpio, то стоило бы изучить вопрос с наименованием, вы например в курсе, что экспортированный контакт не обязательно будет иметь имя вида gpioN?
3) Присутвующие в системе gpio надо смотреть исходя из приципиальной схемы и документации. Номера gpio в системе присваиваються по системе «кто первый встал тог и тапки», это раз, во-вторых номера абсолютно не обязательно идут подряд. Тогда уж надо смотреть base для gpiochip и делать экспорт по числу контактов на чипе, для каждого чипа.
Так datasheet говорит, что можно использовать rs485. То есть датчики можно поключить последовательно. Если скорость неважна, то с хорошим кабелем на малой скорости это дает длину шины до 1 км.
Если серьезно, я не возьмусь сравнивать, от слова совсем. Это две различные операционные системы, причем я ничего не знаю о FreeBSD.
Про everything is a file (but not really) — это правда, если начинаешь использовать epoll всегда и везде, как замену select, то точно заметишь. Можно попробовать перефразировать «everything is a file descriptor» — но это тоже не будет правдой.
Для автора сравнения [1] kqueue статьи важен epoll_ctl — а для меня никогда не было bottleneck, поэтому не берусь судить.
Так что мы можем сравнить только удобство пользования в каком то смысле, но пускай это делают те кто интересуется кросс-платформенной разработкой.
In this section we first compare the throughput achieved when using level-triggered epoll with that observed when using select and poll under both the one-byte and SPECweb99-like workloads with no idle connections.
>> Ну разумеется poll нельзя научить работать абсолютно так же как epoll, особенно с той же асимптотикой. Но нельзя же говорить что epoll лучше poll просто потому что он epoll!
Так… А с чего вы решили, что я в статье утверждаю обратное? Я вроде специально акцент сделал на изначальное предназначение epoll и с какой целью он создавался, а потом уже перешел к дополнительным плюшкам.
Здесь надо акцентировать на том, что epoll по-крайней мере не хуже poll, а в некоторых случаях лучше.
>> Фича EPOLLET решает ровно одну задачу — дает возможность отложить реакцию на событие и продолжить ждать остальные события. Но poll умеет так же без специальных флагов.
Именно поэтому я указал на отличие в обработке в ядре, чтобы было еще одно отличие. Собственно из-за это его называют O(1) I/O multiplexer…
Но если уж быть дотошным, то есть отличия и в правилах merge'a для событий разных типов.
— RISC-V это набор ISA (instruction set architecture) открытых спецификаций, которые небходимо соблюдать, что быть RISC-V совместимыми
— есть открытые реазизации процессоров соответвующих данным спецификациям (открытые — есть код, бери и заливай на FGPA или запекай, участвуй в разработке)
— доподлинно известно, что микроконтроллеры по RISC-V уже используют NVIDIA и Western Digital
— Собственно V — означает пятую попытку :-D
Данная инициатива интересна своей открытостью, то есть все открыто и бесплатно.
Покупали или бесплатно получили?Не заметил, что это перевод — прошу пардона.
AXIS M3046-V: Защита от внешней среды IP42, IK08
IDIS DC-D3212X: нет
Потом идем и смотрим AXIS:
Approvals:
EMC EN 55032 Class B, EN 55024, EN 61000-6-1,
EN 61000-6-2, FCC Part 15 Subpart B Class A and B,
ICES-003 Class B, VCCI Class B, RCM AS/NZS CISPR 22 Class B,
KCC KN32 Class B, KN35
Safety IEC/EN/UL 60950-1
Environment IEC/EN 60529 IP42, IEC/EN 62262 Class IK08, RoHS, WEEE
Network NIST SP500-267
Это может быть решающим при выборе.
У IDIS DC-D3212X не нашёл информацию по этому поводу.
В общем кто ставит AXIS тот и будет ставить AXIS (как и оборудование Cisco и прочее) потому как корпоративный стандарт (не буду тыкать пальцем, сами знаете кто).
Для остальных я считаю разница в цене не столь существенна, а для кого существенна, найдут что-нибудь подешевле.
Это очень смелое заявление. Что тогда по-вашему «привязка» к конкретной платформе?
Драйвер виртуальных GPIO с контроллером прерываний на базе QEMU ivshmem для Linux
Использование gpio-generic и irq_chip_generic для драйвера gpio
Заметка о новом интерфейсе linux kernel — gpio uapi
А пристал я потому, что
Без описания этого блока, данная работа лишена смысла. А что за блок? А он открытый? А скачать можно? А какие типы прерываний поддерживает?
А что за процессор?
Если все это закрытая разработка, то какой в этом во всем смысл?
То есть вы хотите сказать, что в вашей статье есть что-то новое, что нельзя прочитать в официальной документации?
https://www.kernel.org/doc/Documentation/gpio/
Тогда уж многое не упомянуто из того, что там уже есть.
1) для mmio можно использовать bgpio_init (написанный кстати нашим соотечественником еще аж в 2010 году), и тогда не надо самому писать однотипные в принципе функции write, read, direction и прочие.
2) для irq в большинстве случаев сгодится irq_chip_generic
3) Их, простите меня, не «разбивают» на банки они уже по банкам находятся.
А оправная точка для любого драйвера GPIO, это не подсматривание в готовую реализацию, а вдумчивое изучения документации на железо.
2) Если вы затронули тему идентификации gpio, то стоило бы изучить вопрос с наименованием, вы например в курсе, что экспортированный контакт не обязательно будет иметь имя вида gpioN?
3) Присутвующие в системе gpio надо смотреть исходя из приципиальной схемы и документации. Номера gpio в системе присваиваються по системе «кто первый встал тог и тапки», это раз, во-вторых номера абсолютно не обязательно идут подряд. Тогда уж надо смотреть base для gpiochip и делать экспорт по числу контактов на чипе, для каждого чипа.
То есть стоит написать, что пример не воспроизводим.
Если серьезно, я не возьмусь сравнивать, от слова совсем. Это две различные операционные системы, причем я ничего не знаю о FreeBSD.
Про everything is a file (but not really) — это правда, если начинаешь использовать epoll всегда и везде, как замену select, то точно заметишь. Можно попробовать перефразировать «everything is a file descriptor» — но это тоже не будет правдой.
Для автора сравнения [1] kqueue статьи важен epoll_ctl — а для меня никогда не было bottleneck, поэтому не берусь судить.
Так что мы можем сравнить только удобство пользования в каком то смысле, но пускай это делают те кто интересуется кросс-платформенной разработкой.
Тем более, что EPOLLET был добавлен позже, а не одновременно с epoll.
никакого выигрыша не будетникакого существенного выигрыша не будет:-D
Так… А с чего вы решили, что я в статье утверждаю обратное? Я вроде специально акцент сделал на изначальное предназначение epoll и с какой целью он создавался, а потом уже перешел к дополнительным плюшкам.
Здесь надо акцентировать на том, что epoll по-крайней мере не хуже poll, а в некоторых случаях лучше.
>> Фича EPOLLET решает ровно одну задачу — дает возможность отложить реакцию на событие и продолжить ждать остальные события. Но poll умеет так же без специальных флагов.
Именно поэтому я указал на отличие в обработке в ядре, чтобы было еще одно отличие. Собственно из-за это его называют O(1) I/O multiplexer…
Но если уж быть дотошным, то есть отличия и в правилах merge'a для событий разных типов.
Так, что вначале все более ли менее ровно.
А ядро у нас собирается исключтельно с помощью gcc =).
И я использую исключительно gcc, но статья о epoll!