Если речь о материнской плате, то сейчас это asus m4n78 se. Железо довольно старое и возникают проблемы с подключением даже одно из трех устройств, которые описаны в упомянутой вами теме. Потому, судя по всему, железо придется заменить. Потому я и не привожу в вопросе модель своей материнской платы, а сразу спрашиваю о том, какую лучше купить.
На счет характеристик устройств, то какие характеристики нужны?
Заколхозил девайс - подвел питание от дополнительного БП (зарядка от айфона, 5В и 1А). Линию питания от ПК отключил физически (сначала хотел бросить ее через диод Шоттки, но для надежности убрал совсем). К этой радости добавил электролитический конденсатор на 100 микрофарад, для надежности опять же.
При подключении устройства через PCI-E контроллер установка драйверов зашла чуть дальше и ОС отрапортовала о недостаточности ресурсов контроллера. Дальше повторилась старая картина с ошибкой 43.
О каких ресурсах контроллера может идти речь в подобном случае? Не уж то проблема в трехвольтовой линии данных?
На счет ограничений на уровне протокола USB - я тоже об этом думал. 127 устройств не такая большая цифра. Но ведь на другом ПК устройство заработало, а кроме него к данному ПК по USB подключена только мышка с клавиатурой, как и на других ПК.
Все указывает на недостаток питания. Мне казалось, что PCI-E контроллер с дополнительным питанием должен решить эту проблему. Но потом я понял, что он запитывается от Molex с того же самого БП. Изначально я проверил теорию о проблемах с БП путем отключения дополнительного жесткого диска - это никак не помогло. Но БП старый, может он просто напросто не обеспечивает стабильное напряжение в 5 вольт? Хотя казалось бы, зачем оно, если у устройств внешнее питание?
Может ли помочь ситуации использование внешнего хаба с внешним питанием (и, возможно, полным физическим отключением VCC линии от ПК)?
Кстати, я правильно понимаю, что в теории я могу повесить 127 устройств на штатный контроллер и 127 устройств на контроллер PCI-E?
Евгений Шатунов:
Ну вот, спустя без малого год, пришло время переписать проект с нуля. И честно говоря, я уже дня три не могу придумать даже с какой стороны ухватиться за это дело. Не менее 20 раз перечитал ваши комментарии, изучил все прикрепленные ссылки, разобрался с теорией... Но на практике никак не выходит это применить. Как только я начинаю продумывать конкретное применение, так сразу находится множество подводных камней. В связи с этим возникает гнетущее чувство неопределенности: то ли я что-то продумываю не так, то ли этот подход не применим к моей задаче.
В общем, очень бы хотелось получить мнение со стороны. Если вы не против небольшого обсуждения - дайте, пожалуйста, знать когда у вас появится свободная минутка, хорошо?
Благодарю за развернутый ответ. Решение действительно интересное. Ту часть, что про асинхронное общение с устройством и коллбэки я уже реализовывал в ранних версиях проекта. Но потом пришлось отказаться от такого, потому как возникала лютая вложенность. К примеру, для инициализации устройства нужно 10-15 последовательных команд. Мешанина выходит страшная. :)
Сейчас у меня уже поджимает время и придется все реализовывать по той схеме, что уже имеется. После этого хочу попробовать реализовать описанный вами вариант, даже не смотря на проблему с большой вложенностью коллбэков. Думаю, по ходу действия у меня возникнет не мало вопросов на счет определенных деталей. Не возражаете, если я, вдруг что, задам их в этой ветке?
Речь идет о GSM-модемах.
До узнавания о новом устройстве дело пока не дошло, так как это второстепенная задача. Для Win можно просто подписаться на уведомление о новых устройствах, для Nix пока не смотрел.
Потоки инициализируют девайсы и раз в 5 секунд чекают на предмет новых данных. Если данные есть, скидывают их коммутатору. Между этим делом спят. Вся работа через AT-команды.
Пока просто агрегировал std::thread в рабочих классах. Запускается в конструкторе, джойнится в деструкторе. Бесконечный цикл с флагом вызывающий рабочий метод tick.
Если переходить на предложенную схему, то по хорошему нужно переделать все, даже общение с девайсами.
Ничего, я, конечно же, подожду. :) Заодно будет время все получе обдумать.
Никак не могу уловить вашу идею на счет пула потоков. Обычно пул потоков применяется если нужно масштабирование. В данной же задаче оно не нужно, количество потоков всегда равно количеству девайсов. Можете описать поподробнее то, что вы имеете ввиду?
Да, самый лучший вариант не доводить дело до автовозврата. Но он не всегда возможен. Зачастую у "человека" конкретная цель - обмануть систему. И он даже связываться с продавцом не будет, просто сразу откроет диспут и все.
На счет вашей ситуации с фотографиями посылок - вы ведь не из США, да? Насколько я понял, защита продавцов работает только если продавец из США. Во всех остальных случаях ничего сделать нельзя. Совсем.
D' Normalization: паспортные данные есть, место жительства есть, данные о банковском счете тоже. Дело на половину сделано. Осталось только продать долг. Единственное, что потребуется, это "поделиться" с коллекторами. Так что схема вполне реальна, на мой взгляд.
На счет характеристик устройств, то какие характеристики нужны?