Работа со спец. железом

Друк, чем таким интересным ты занимаешься? ;)

Общее представление примерно таково: в состав твоей платы входит коммуникационный узел для общения с хост-машиной через PCI, сама плата видна на шине как PCI-устройство. При записи в регистры коммуникационного узла возможна посылка прерывания в хост-машину. При записи в регистры PCI-устройства возможна посылка прерывания программе, исполняющейся на плате. Кроме регистра управления прерываниями коммуникационный узел может содержать регистры для передачи данных. Вот на этих средствах ты должен построить какие-то примитивы синхронизации между программами, исполняющимися на хосте, и программами на плате.

Еще на твоей плате должны быть какие-то средства для обмена данными с хостом - скорее всего, ьанк памяти, видимый на PCI.

В общем, тебе надо написать драйвер устройства, который будет управлять непосредственно коммуникационным узлом и средствами обмена данных, и библиотеку, предостваляющую синхронизационные примитивы и средства обмена данными.

Если плата не использует прерывания, и является нормальной PCI-платой, то через /proc или /sys можно узнать, на какие адреса io/mem ему назначило PnP и прямо с ней и работать. (man iopl)

Но работать будет только под рутом.

Если использует прерывание, либо нужно, чтобы работало не под рутом - нужно писать драйвер ядра.

> Если использует прерывание, либо нужно, чтобы работало не под рутом - нужно писать драйвер ядра.

ИМХО, драйвер лучше писать в любом случае - чтобы упавшая прога при отладке не оставила железо в каком-нибудь странном состоянии, из которого непонятно как выйти.

> в состав твоей платы входит коммуникационный узел для общения с хост-машиной через PCI.

А ты случайно не в курсе, есть ли какие-нить готовые микросхемы, способные выступать в роли "коммуникационный узел"? Или подскажи пожалуйста англ.термин, чтоб в гугле поискать.

[честно предупреждаю - я программист, а не железячник]

> А ты случайно не в курсе, есть ли какие-нить готовые микросхемы, способные выступать в роли "коммуникационный узел"?

Посмотри на PLX90xx - это семейство чипов PCI-интерфейса, довольно широко используемое (www.plxtech.com)

>Или подскажи пожалуйста англ.термин, чтоб в гугле поискать.

Термини "коммуникационный узел" я только что сам придумал 8) Попробуй искать платы с регистрами, которые называются mailbox и doorbell.

Огромное спасибо за поддержку!

Но я имел ввиду несколько другое (извините, если что неточно спрашиваю – в linux я новичок :) ). Меня сейчас больше интересует каким образом возможен обмен данными с драйвером. Т.е. пока я подразумеваю, что драйвер для нужного железа есть. Если уж драйвера не будет, то это будет отдельная тема, которой я как-то очень опасаюсь ;), поэтому даже не хочу пока об этом ужасе думать ;).

> Друк, чем таким интересным ты занимаешься? ;)

Да задумывается тут спец-прога на linux-платформе по обработке неких данных (извини, дальше болтать не уполномочен ;))) ). Т.е. получаем пакет данных по сетке, немного поковыряем его (более чем возможно что с помощью спецвычислителей) и кладем результаты рядом в файлики или шлем дальше по сетке. Вот кратенько так. Соответственно кроме общих тем по linux, есть общие вопросы по техникам программирования - по работе с сетью, организации многопоточной работы, работе с дополнительным железом. С сетью все более-менее понятно – запускаем поток, который создает сокет и слушает порт, затем получает данные, отдает их потокам-обработчикам. С многопоточкой с Вашей помощью тоже уже проясняется :). Вот остался вопрос по работе с железом.

> Меня сейчас больше интересует каким образом возможен обмен данными с драйвером

Через файл устройства. Какой и как с ним работать зависит от драйвера.

Т.е. что делают read, write, seek, ioctl для данного устройства. А вообще почитай Linux Device Drivers.

> Т.е. пока я подразумеваю, что драйвер для нужного железа есть. Если уж драйвера не будет, то это будет отдельная тема, которой я как-то очень опасаюсь ;)

Нечего опасаться. Интересная работа (по крайней мере, первые несколько драйверов 8) ).

> спец-прога на linux-платформе по обработке неких данных (извини, дальше болтать не уполномочен ;))) )

Тоже мне, бином Ньютона 8) - РЛС, сонар ? И вообще - не работаешь ли ты в соседней комнате? ;)

> по работе с сетью, организации многопоточной работы, работе с дополнительным железом. С сетью все более-менее понятно – запускаем поток, который создает сокет и слушает порт, затем получает данные, отдает их потокам-обработчикам. С многопоточкой с Вашей помощью тоже уже проясняется :).

Если тебе для _этого_ нужна многонитевая программа, предлагаю подумать дважды. Если организовать обработку от единого event loop, где через poll принимаются события от сети и железа, отлаживаться будет намного проще. По крайней мере, с этого стоит начать.

Конечно, для этого драйвер вашего железа должен поддерживать poll - но это в любом случае хорошая идея. А вот mmap не нужен :)

Ок, спасибо за инфу.

2 Begemoth

Спасибо! Понял направление.

2 tailgunner

> И вообще - не работаешь ли ты в соседней комнате? ;

Ну если ты в профиле верную инфу указал, то точно как минимум не в одной комнате :))

> Если тебе для _этого_ нужна многонитевая программа, предлагаю подумать дважды

Это я там достаточно упрощенно описал. Там только обработка подразумевает несколько процедур, некоторые из них могут еще брать некие дополнительные данные из дополнительной БД. Просто хочу сделать наиболее продуманную архитектуру, чтобы не расставить себе возможные грабли.

>> И вообще - не работаешь ли ты в соседней комнате? ;

>Ну если ты в профиле верную инфу указал, то точно как минимум не в одной комнате :))

Если ты не знаешь, где это, тогда да ;) Хотя очень похоже было 8)

> Просто хочу сделать наиболее продуманную архитектуру

Одно из основных правил нашего ремесла гласит: не мудри. Одонитевые приложения и в самом деле проще отлаживать (проверено на себе).

> Одно из основных правил нашего ремесла гласит: не мудри. Одонитевые приложения и в самом деле проще отлаживать (проверено на себе).

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

Ну ниче, думаю как грится "нужно делать хорошо, а плохо оно само получится". Так что пока рассчитываю на потоки, а если что, то в один поток все запихать всегда успею. Судя по текущим прикидкам потоки будут относительно автономны, единственное что нужно реализовать через критические секции доступ к общим очередям блоков данных. Да и к тому же у меня такое ощущение, что у нас будет или два камня или двухядерный камень, так что хочется их оба под завязку загрузить работой :)))