Есть-ли здесь СПЕЦЫ ?, QUSB-master |
Здравствуйте, гость ( Вход | Регистрация )
Есть-ли здесь СПЕЦЫ ?, QUSB-master |
JohnZ |
17.11.2017, 12:04
Сообщение
#11
|
Участник Группа: Участник Сообщений: 139 Регистрация: 19.7.2014 Пользователь №: 4190 Спасибо сказали: 10 раз(а) Репутация: 0 |
JohnZ, не задумывался об этом, меня устраивает поток на 100% А вотЪ если подумать над этим, то можно _тратить_ ресурсов на _порядок_ (а то и два) меньше, при схеме с прерываниями Хорошо если этот поток "упадёт" на свободное ядро, и если это доп-е ядро в проце есть, - а если нет !? я тебе ещё раз говорю: почитай хотя бы основы про систему, под которую ты собрался что-то писать. последний раз, когда прерывания были доступны юзеру - это времена MS-DOS. с тех пор системы стали сложнее и драйвер в принципе не обязан ничего предоставлять юзеру. Тогда нафига козе баян ? Ось ради оси ? Где логика ? Откройте определение и лог-й состав оси, хотя-бы даже с тех-же времён MS-DOS ?! Разве во времёна Линь/Вынь изменилось её назначение / определение ?! Если да, то опять на ум приходит вопрос про козу с баяном И почему-это "драйвер в принципе не обязан ничего предоставлять юзеру" ??? Тогда вопрос - зачем он нужен ? Под юзером здесь ес-сно подразумевается Пользовательское ПО !!! Цитата конечно, ты можешь написать свой драйвер, но это довольно сложная задача и главное, что это в принципе не нужно. потому что драйвер как раз предоставляет интерфейсы для libusb и всяких там HID интерфейсов и юзерский софт пользуется стандартизированными интерфейсами библиотек, а не затачивается под разные драйвера. на самом деле, с драйверами всё несколько сложнее, их там несколько уровней и они передают между собой сообщения. но то, о чём ты говоришь, доступно только драйверам самого низкого уровня и они точно ничего о прерываниях юзеру не сообщают. это загрузило бы ядро системы ненужными коллбеками вплоть до полного зависания. Я в курсе что "это довольно сложная задача", поэтому и спрашиваю. Я как-раз и хочу "вцепиться" в драйвер самого низкого уровня ! Ему-же без разницы кому отдать эвент ?! К большому сожалению libusb этого НЕ делает, а должна была-бы ... я, честно говоря, не видела USB-шных девайсов на майкрочипе. чаще всего там FTDI ставят. дёшево и сердито. Вот именно ! Дёшево и сердито. !!! FTDI полностью обслуживает интерфейс и имеет физическую линию IRQ ! Я о том и спрашиваю - как его (IRQ) достать !!! Тогда можно было-бы "доточить" libusb ... Скачал я описание проца RPi2 ( BCM2835 ), буду разбираться с его "мухами" Цитата(Алексей1153 @ 16.11.2017, 9:34) А по поводу FTDI - тоже используем. Он непредсказуемо затыкается на win7 и младше, на 8 и 10 вроде стабильно работает вот ни разу такого не видела. там, главное, использовать правильный драйвер: не серийный, который эмулирует COM, а нормальный D2XX, который управляет регистрами железяки напрямую. мы использовали их в промышленной автоматике в очень нагруженных системах и ни разу ничего не затыкалось. Ну вот-же, есть нормальные дрова ! И видимо из юзер-моде доступен ?! А что это за звЯрушка такая, - D2XX ? Сообщение отредактировал JohnZ - 17.11.2017, 12:13 |
|
|
Iron Bug |
17.11.2017, 22:43
Сообщение
#12
|
Профессионал Группа: Модератор Сообщений: 1611 Регистрация: 6.2.2009 Из: Yekaterinburg Пользователь №: 533 Спасибо сказали: 219 раз(а) Репутация: 12 |
у тебя очень примитивные и неграмотные рассуждения про системы. я системный программист с опытом более 20 лет и мне на эти глупости отвечать подробно просто некогда.
если ты хочешь что-то изучать - бери и читай документацию по написанию драйверов. тогда, вероятно, ты поймёшь, почему ты неправ и почему твои вопросы не имеют смысла в контексте современных операционных систем. вся документация по ядру Linux есть в онлайне. она быстро устаревает, поэтому самое актуальное - это документация в самом кернеле. есть книга LDD (Linux Device Drivers), там подбробнее написано, но не под совсем свежие ядра. под венду придётся покупать книги по KMDF и т.д. другой документации под венду практически нет. но я тебе сразу скажу, что никаких "универсальных" драйверов не бывает. драйвер заточен для работы с конкретной железякой и привязан к специфике чипов, с которыми он общается. и поверх него до юзерского уровня может быть много других драйверов и библиотек. так что юзер напрямую с прерываниями ничего делать не должен. |
|
|
Алексей1153 |
18.11.2017, 8:48
Сообщение
#13
|
фрилансер Группа: Участник Сообщений: 2941 Регистрация: 19.6.2010 Из: Обливион Пользователь №: 1822 Спасибо сказали: 215 раз(а) Репутация: 34 |
А вотЪ если подумать над этим, то можно _тратить_ ресурсов на _порядок_ (а то и два) меньше, при схеме с прерываниями Хорошо если этот поток "упадёт" на свободное ядро, и если это доп-е ядро в проце есть, - а если нет !? по ресурсам меня там всё устраивает, комп работает быстрее железяки ) И даже быстрее десяти таких железяк Потоки система всегда раскидывает по "свободным" ядрам, об этом в общем случае можно не думать. Но, если что, можно озаботится расстановкой affinity и даже priority. Если нет дополнительного ядра, то прерываниями ты ну никак не разгонишь производительность. Скорость реакции - да, но производительность - нет |
|
|
JohnZ |
18.1.2018, 16:49
Сообщение
#14
|
Участник Группа: Участник Сообщений: 139 Регистрация: 19.7.2014 Пользователь №: 4190 Спасибо сказали: 10 раз(а) Репутация: 0 |
Согласен на 500100 % !!!
... но для стороннего наблюдателя (юЗверя) именно Скорость реакции и является Производительностью ! Прога может тупо ничего не делать выжидая "положенный" тайм-аут железяки, а юЗверь подумает что комп долго думает и поэтому медленный, надо его менять |
|
|
Текстовая версия | Сейчас: 4.12.2024, 22:26 |