crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в Есть-ли здесь СПЕЦЫ ?
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
JohnZ Дата 18.1.2018, 16:49
  Согласен на 500100 % !!! :)
... но для стороннего наблюдателя (юЗверя) именно Скорость реакции и является Производительностью !
Прога может тупо ничего не делать выжидая "положенный" тайм-аут железяки, а юЗверь подумает что комп долго думает :)
и поэтому медленный, надо его менять :)
Алексей1153 Дата 18.11.2017, 8:48
 
Цитата(Iron Bug @ 16.11.2017, 15:53) *
А вотЪ если подумать над этим, то можно _тратить_ ресурсов на _порядок_ (а то и два) меньше, при схеме с прерываниями
Хорошо если этот поток "упадёт" на свободное ядро, и если это доп-е ядро в проце есть, - а если нет !?


по ресурсам меня там всё устраивает, комп работает быстрее железяки ) И даже быстрее десяти таких железяк

Потоки система всегда раскидывает по "свободным" ядрам, об этом в общем случае можно не думать. Но, если что, можно озаботится расстановкой affinity и даже priority.

Если нет дополнительного ядра, то прерываниями ты ну никак не разгонишь производительность. Скорость реакции - да, но производительность - нет
Iron Bug Дата 17.11.2017, 22:43
  у тебя очень примитивные и неграмотные рассуждения про системы. я системный программист с опытом более 20 лет и мне на эти глупости отвечать подробно просто некогда.
если ты хочешь что-то изучать - бери и читай документацию по написанию драйверов. тогда, вероятно, ты поймёшь, почему ты неправ и почему твои вопросы не имеют смысла в контексте современных операционных систем. вся документация по ядру Linux есть в онлайне. она быстро устаревает, поэтому самое актуальное - это документация в самом кернеле. есть книга LDD (Linux Device Drivers), там подбробнее написано, но не под совсем свежие ядра. под венду придётся покупать книги по KMDF и т.д. другой документации под венду практически нет.
но я тебе сразу скажу, что никаких "универсальных" драйверов не бывает. драйвер заточен для работы с конкретной железякой и привязан к специфике чипов, с которыми он общается. и поверх него до юзерского уровня может быть много других драйверов и библиотек. так что юзер напрямую с прерываниями ничего делать не должен.
JohnZ Дата 17.11.2017, 12:04
 
Цитата(Алексей1153 @ 15.11.2017, 8:29) *
JohnZ, не задумывался об этом, меня устраивает поток на 100%

А вотЪ если подумать над этим, то можно _тратить_ ресурсов на _порядок_ (а то и два) меньше, при схеме с прерываниями B)
Хорошо если этот поток "упадёт" на свободное ядро, и если это доп-е ядро в проце есть, - а если нет !?

Цитата(Iron Bug @ 15.11.2017, 11:51) *
я тебе ещё раз говорю: почитай хотя бы основы про систему, под которую ты собрался что-то писать.
последний раз, когда прерывания были доступны юзеру - это времена MS-DOS. с тех пор системы стали сложнее и драйвер в принципе не обязан ничего предоставлять юзеру.

Тогда нафига козе баян ? Ось ради оси ? Где логика ? Откройте определение и лог-й состав оси, хотя-бы даже с тех-же
времён MS-DOS ?! Разве во времёна Линь/Вынь изменилось её назначение / определение ?!
Если да, то опять на ум приходит вопрос про козу с баяном :)
И почему-это "драйвер в принципе не обязан ничего предоставлять юзеру" ??? Тогда вопрос - зачем он нужен ?
Под юзером здесь ес-сно подразумевается Пользовательское ПО !!!

Цитата
конечно, ты можешь написать свой драйвер, но это довольно сложная задача и главное, что это в принципе не нужно. потому что драйвер как раз предоставляет интерфейсы для libusb и всяких там HID интерфейсов и юзерский софт пользуется стандартизированными интерфейсами библиотек, а не затачивается под разные драйвера. на самом деле, с драйверами всё несколько сложнее, их там несколько уровней и они передают между собой сообщения. но то, о чём ты говоришь, доступно только драйверам самого низкого уровня и они точно ничего о прерываниях юзеру не сообщают. это загрузило бы ядро системы ненужными коллбеками вплоть до полного зависания.

Я в курсе что "это довольно сложная задача", поэтому и спрашиваю.
Я как-раз и хочу "вцепиться" в драйвер самого низкого уровня ! Ему-же без разницы кому отдать эвент ?!
К большому сожалению libusb этого НЕ делает, а должна была-бы ...

Цитата(Iron Bug @ 15.11.2017, 17:52) *
я, честно говоря, не видела USB-шных девайсов на майкрочипе. чаще всего там FTDI ставят. дёшево и сердито.

Вот именно ! Дёшево и сердито. !!! FTDI полностью обслуживает интерфейс и имеет физическую линию IRQ !
Я о том и спрашиваю - как его (IRQ) достать !!! Тогда можно было-бы "доточить" libusb ...
Скачал я описание проца RPi2 ( BCM2835 ), буду разбираться с его "мухами" :(

Цитата(Iron Bug @ 16.11.2017, 13:53) *
Цитата(Алексей1153 @ 16.11.2017, 9:34)
А по поводу FTDI - тоже используем. Он непредсказуемо затыкается на win7 и младше, на 8 и 10 вроде стабильно работает
вот ни разу такого не видела. там, главное, использовать правильный драйвер: не серийный, который эмулирует COM, а нормальный D2XX, который управляет регистрами железяки напрямую. мы использовали их в промышленной автоматике в очень нагруженных системах и ни разу ничего не затыкалось.

Ну вот-же, есть нормальные дрова ! И видимо из юзер-моде доступен ?!
А что это за звЯрушка такая, - D2XX ?
Iron Bug Дата 16.11.2017, 13:53
 
Цитата(Алексей1153 @ 16.11.2017, 9:34) *
А по поводу FTDI - тоже используем. Он непредсказуемо затыкается на win7 и младше, на 8 и 10 вроде стабильно работает

вот ни разу такого не видела. там, главное, использовать правильный драйвер: не серийный, который эмулирует COM, а нормальный D2XX, который управляет регистрами железяки напрямую. мы использовали их в промышленной автоматике в очень нагруженных системах и ни разу ничего не затыкалось.
Алексей1153 Дата 16.11.2017, 7:34
  Iron Bug, исторически так сложилось в одной старой железяке - вынуждены тянуть. На win 8 и 10 драйвер перестал работать, а libusb работает

А по поводу FTDI - тоже используем. Он непредсказуемо затыкается на win7 и младше, на 8 и 10 вроде стабильно работает

делал тест на win7 - гоню из прибора поток данных без остановки, принимаю в программу через стандартный COM порт. Самого непроизвольного затыкания можно ждать сутками, но спровоцировать легко - перетыкаешь разъём туда-сюда. В какой-то момент данные перестают приходить, хотя никаких ошибок из функций ком-порта не выскакивает. Лечится перезапуском программы, больше я способа не смог найти. Простое переоткрытие порта при этом не помогает, ошибок при этом тоже никаких не выскакивает
Iron Bug Дата 15.11.2017, 17:52
 
Цитата(Алексей1153 @ 15.11.2017, 19:36) *
в отличие от майкрочиповского драйвера, я могу программно передёрнуть разъём - и всё работает дальше

я, честно говоря, не видела USB-шных девайсов на майкрочипе. чаще всего там FTDI ставят. дёшево и сердито.
Алексей1153 Дата 15.11.2017, 17:36
  Iron Bug, иногда затыкается, да, но, в отличие от майкрочиповского драйвера, я могу программно передёрнуть разъём - и всё работает дальше. Протестил - и это точно работающее решение, потому что иначе бы мне мозг вынесли пользователи уже
Iron Bug Дата 15.11.2017, 11:51
 
Цитата(Алексей1153 @ 14.11.2017, 8:47) *
я использовал в винде libusb, именно в отдельном потоке. Нормальная штука, работает чётко, в отличие от зависающего майкрочиповского драйвера

под вендой она иногда зависает, судя по отзывам. честно говоря, я уже давно венду живьём не видела, так что меня сейчас этот вопрос мало волнует. но судя по форумам, проблема остаётся актуальной.

Цитата(JohnZ @ 14.11.2017, 13:53) *
Для потока и LibUSB у меня тоже реализовано, но некузяво это, при наличии аппаратного IRQ.
В том-то и вопрос, как выцарапать это IRQ у системы ?!
Где и как сказать драйверу что-бы он отдал конкретный EVENT моей Call-Back-чной ф-ции ?
Пишу под ARM на Linux (RPi-2) ...

я тебе ещё раз говорю: почитай хотя бы основы про систему, под которую ты собрался что-то писать.
последний раз, когда прерывания были доступны юзеру - это времена MS-DOS. с тех пор системы стали сложнее и драйвер в принципе не обязан ничего предоставлять юзеру. конечно, ты можешь написать свой драйвер, но это довольно сложная задача и главное, что это в принципе не нужно. потому что драйвер как раз предоставляет интерфейсы для libusb и всяких там HID интерфейсов и юзерский софт пользуется стандартизированными интерфейсами библиотек, а не затачивается под разные драйвера. на самом деле, с драйверами всё несколько сложнее, их там несколько уровней и они передают между собой сообщения. но то, о чём ты говоришь, доступно только драйверам самого низкого уровня и они точно ничего о прерываниях юзеру не сообщают. это загрузило бы ядро системы ненужными коллбеками вплоть до полного зависания.
Алексей1153 Дата 15.11.2017, 8:29
  JohnZ, не задумывался об этом, меня устраивает поток на 100%
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 28.3.2024, 22:36