К тому же отпаять Атмегу не так просто — нужна паяльная станция с феном.
Можно рискнуть с лезвием бритвы если место позволяет. Оно делается из нержавейки и не смачивается припоем, так что можно прогреть одну сторону, проталкивая лезвие между ножками и платой. Хотя, конечно, есть риск погнуть или даже отломать ножки. Я так пытался выпаять STM32L151 в 64-ногом корпусе, по результатам даже статью сюда написал. Если вкратце — вот там ножки слишком дохлые для таких экспериментов. А на Мегах риск намного меньше. Хотя феном, конечно, лучше.
Основные причины — цена и надежность. Специализированная микросхема в любом случае будет дешевле контроллера общего назначения. Помимо этого, ей не нужна часть обвязки, которую встраивают прямо в кристалл.
И надежность у нее будет выше: там нет нужды в какой-либо прошивке, то есть ничего не зависнет. Меньше элементов, как на кристалле, так и на плате — тоже меньше шансов что один из них выйдет из строя
Если я иду по улице с телефоном и проводными наушниками, я постоянно цепляюсь ими за одежду и распутываю лапшу
Странный подход. Что сложного пропустить провод под одеждой. И болтаться не будет, и вынуть уши никакой проблемы. Пока не нужны пусть себе болтаются или лежат в нугрудном кармане. Проблемы с лапшой возникают только если наушники долго лежат в кармане, а если складываются только на хранение, то путаться им и не с чего.
Причем я говорю исключительно из личного опыта: постоянно слушаю с телефона через обычные проводные наушники. Когда они не нужны — вытаскиваю, не останавливая воспроизведение, и пусть болтаются. Следить за аккумулятором было бы куда утомительнее.
а еще намного чаще меняю сами наушники, потому что у меня обычно ломаются именно провода
Опять не вижу проблемы раз в полгода купить за 100 р новые наушники либо перепаять провод. Для справки, косичка из МГТФ куда надежнее штатного и не ломается.
Если я работаю за ноутом от батареи, мне все равно придется снимать наушники из ушей, сматывать провод и убирать его в карман, чтобы перенести ноут с места на место — теряется мобильность
Вот это единственный реальный недостаток. Но так ли часто нужно таскать ноут с воспроизводящимся там звуком? Лично мне — нет.
Где-то читал, что это маркетинговый ход, не больше. Ничего в структуре USB не соответствует топологии «шина», даже адреса. На шине адреса обычно задаются вручную, и уж точно никто не полагается на поочередное включение-отключение отдельных портов, чтобы на 0-й адрес отозвалось только одно устройство.
127 не 127, но 3-4 устройства вполне реально
Особенно если половина high-speed, а вторая — low-speed, то есть тянут своими резисторами в разные стороны. В RS485 резисторы нужны для создания токовой петли, а не для определения скорости устройства. Там вообще не важно какой номинал, лишь бы источник сигнала потянул, да помех не слишком много было.
Про Hi-speed я не говорил, поскольку они появились несколько позже. И, если не ошибаюсь, теоретически тоже поддерживают совместимость с «тупыми» хабами, то есть совсем уж необходимости нет, просто общаться с флешкой на скорости 1.5 Мб/с как-то совсем грустно. А к тому времени и «умные» хабы подешевели и полностью (или почти полностью) вытеснили предшественников.
Хабы описаны в последней главе спецификации USB 1.1, возможно это признак, что они появились позже остального.
Мне казалось, что они входят в стандарт изначально, просто исходя из топологии и философии шины. Ведь пространство адресов изначально было 7-битным, а 127 портов на плату расширения не ставят. И просто соединить устройства впараллель нельзя, подтягивающие резисторы будут мешать.
Как бы то ни было, археологические раскопки изначальной причины проверки адреса на устройстве мне не слишком интересны. Пока что версия с упрощением конструкции (а она прослеживается везде, хотя и порой в странных формах) выглядит вполне правдоподобно.
Составное устройство это все же не «хаб плюс несколько устройств» в одном, а просто несколько конечных точек, объединенных по функционалу и описанных в десрипторе. Адрес устройства при этом все равно один, а различие делается именно по номеру точки.
Если же точек не хватает и приходится городить именно «хаб плюс устройства» в одном, то все равно придется обрабатывать хабо-специфичные запросы. То есть эмулировать так эмулировать, полноценно и с поддержкой всего функционала.
Так что во времена USB 1.0 просто не было особой нужды в умных хабах.
Даже тогда было разделение low-speed / full-speed, оно было с самого начала. Просто разработчики посчитали лучшим перенести основную сложность на хост, а периферию максимально упростить. Даже ценой снижения скорости обмена.
И суммарно система, где устройства сами определяют адрес, похоже, оказалась проще, чем система с более умными хабами.
.
Так что мое мнение остается неизменным: по смыслу было бы правильнее отдать управление адресатами на хаб (топология «звезда» или даже «дерево»), но в целях упрощения выбрали топологию «шина». Иначе говоря, причина больше практическая, чем философская.
Как фильтруют хабы точно не знаю, наверняка именно по адресу. Но это не единственный вариант, просто вот такой выбрали. Могли завернуть в «матрешку», где адреса принадлежат «оболочке», а не данным.
Потому что, повторюсь, самому устройству адрес без надобности.
Поэтому я и считаю, что его решили встроить из соображений упрощения. Вроде того что устройству лишний запрос обработать несложно, зато разработчикам хабов и тому подобного задача упрощается. Да и топология шины становится более похожей на шину.
И? Физически каждое устройство висит на своем порту. Кроме него туда больше ничего не подключено. К чему этот порт подключен дальше его, по идее, волновать не должно.
Ну и потом передача адреса может быть нужно всякому USB over IP
Так а устройству-то зачем адрес? Или IP адрес? Или адрес еще чего-то через что оно подключено?
Могли сделать адресацию по разъему (даже удобнее было бы), могли тоже по адресу, но скрыть его от устройства.
Какой устройству-то смысл знать свой «внешний» адрес, если оно им не может пользоваться, да и провода физически идут только от него и до хоста. Это же не I2C, где куча девайсов может параллельно висеть и где они действительно должны сами решать отвечать ли на запрос или игнорировать.
Спасибо. Видел ее, но чем-то она меня не устроила, уже точно не помню чем. То ли зависимости лишние тащить, то ли не удалось что-то реализовать, то ли собрать под windows.
Но в статью добавлю, почему бы и нет
Я в самом начале написал для чего это делалось.
Если нужно готовое устройство, можно взять контроллер с аппаратным USB, можно взять ft232, можно взять ту же vusb и использовать без анализа внутренностей (как, полагаю, большинство и делает).
Но мне было интересно разобраться как USB работает, причем не на уровне «передаем такой дескриптор, передаем эдакий», а вплоть до уровней сигнала и таймингов. И, смею надеяться, я не один такой.
А это законно? То есть в чем принципиальное отличие получения информации о внутреннем устройстве через отладочную сборку и через, скажем, дизассемблирование.
делеи не для точных таймингов в любом случае. Это скорее из серии «выждать 10 мс пока питание стабилизируется», «выждать 100 мкс когда дисплей прожует предыдущий байт»
Где нужны точные задержки, там надо как минимум прерывания запрещать. А лучше, конечно, использовать человеческие методы.
смотря где. Бывают ситуации, требующие высокой скорости и прерывать их другими задачами нет смысла. Хотя бы SPI: что программный, что аппаратный на максимальной скорости занимают десяток тактов. Программа просто не успеет переключиться чтобы сделать еще что-то в этом огрызке времени.
Или наоборот, есть длинная и развесистая задача в основном цикле, а все остальное распихано по прерываниям. Ну и смысл городить недо-ОС, когда задача всего одна.
В общем, как везде: есть инструмент. Есть люди, применяющие его к месту. А есть обезьяны, применяющие везде. Но инструмент-то в этом не виноват.
Вот только будет он не у людей, а у корпораций. И служить будет им, так что первое чему его научат — обходить блокировки и фигурно подсовывать все больше рекламы, слежки и прочей радости
И надежность у нее будет выше: там нет нужды в какой-либо прошивке, то есть ничего не зависнет. Меньше элементов, как на кристалле, так и на плате — тоже меньше шансов что один из них выйдет из строя
Странный подход. Что сложного пропустить провод под одеждой. И болтаться не будет, и вынуть уши никакой проблемы. Пока не нужны пусть себе болтаются или лежат в нугрудном кармане. Проблемы с лапшой возникают только если наушники долго лежат в кармане, а если складываются только на хранение, то путаться им и не с чего.
Причем я говорю исключительно из личного опыта: постоянно слушаю с телефона через обычные проводные наушники. Когда они не нужны — вытаскиваю, не останавливая воспроизведение, и пусть болтаются. Следить за аккумулятором было бы куда утомительнее.
Опять не вижу проблемы раз в полгода купить за 100 р новые наушники либо перепаять провод. Для справки, косичка из МГТФ куда надежнее штатного и не ломается.
Вот это единственный реальный недостаток. Но так ли часто нужно таскать ноут с воспроизводящимся там звуком? Лично мне — нет.
Особенно если половина high-speed, а вторая — low-speed, то есть тянут своими резисторами в разные стороны. В RS485 резисторы нужны для создания токовой петли, а не для определения скорости устройства. Там вообще не важно какой номинал, лишь бы источник сигнала потянул, да помех не слишком много было.
Мне казалось, что они входят в стандарт изначально, просто исходя из топологии и философии шины. Ведь пространство адресов изначально было 7-битным, а 127 портов на плату расширения не ставят. И просто соединить устройства впараллель нельзя, подтягивающие резисторы будут мешать.
Как бы то ни было, археологические раскопки изначальной причины проверки адреса на устройстве мне не слишком интересны. Пока что версия с упрощением конструкции (а она прослеживается везде, хотя и порой в странных формах) выглядит вполне правдоподобно.
Если же точек не хватает и приходится городить именно «хаб плюс устройства» в одном, то все равно придется обрабатывать хабо-специфичные запросы. То есть эмулировать так эмулировать, полноценно и с поддержкой всего функционала.
Даже тогда было разделение low-speed / full-speed, оно было с самого начала. Просто разработчики посчитали лучшим перенести основную сложность на хост, а периферию максимально упростить. Даже ценой снижения скорости обмена.
И суммарно система, где устройства сами определяют адрес, похоже, оказалась проще, чем система с более умными хабами.
.
Так что мое мнение остается неизменным: по смыслу было бы правильнее отдать управление адресатами на хаб (топология «звезда» или даже «дерево»), но в целях упрощения выбрали топологию «шина». Иначе говоря, причина больше практическая, чем философская.
Потому что, повторюсь, самому устройству адрес без надобности.
Поэтому я и считаю, что его решили встроить из соображений упрощения. Вроде того что устройству лишний запрос обработать несложно, зато разработчикам хабов и тому подобного задача упрощается. Да и топология шины становится более похожей на шину.
Так а устройству-то зачем адрес? Или IP адрес? Или адрес еще чего-то через что оно подключено?
Какой устройству-то смысл знать свой «внешний» адрес, если оно им не может пользоваться, да и провода физически идут только от него и до хоста. Это же не I2C, где куча девайсов может параллельно висеть и где они действительно должны сами решать отвечать ли на запрос или игнорировать.
Но в статью добавлю, почему бы и нет
Если нужно готовое устройство, можно взять контроллер с аппаратным USB, можно взять ft232, можно взять ту же vusb и использовать без анализа внутренностей (как, полагаю, большинство и делает).
Но мне было интересно разобраться как USB работает, причем не на уровне «передаем такой дескриптор, передаем эдакий», а вплоть до уровней сигнала и таймингов. И, смею надеяться, я не один такой.
Где нужны точные задержки, там надо как минимум прерывания запрещать. А лучше, конечно, использовать человеческие методы.
Или наоборот, есть длинная и развесистая задача в основном цикле, а все остальное распихано по прерываниям. Ну и смысл городить недо-ОС, когда задача всего одна.
В общем, как везде: есть инструмент. Есть люди, применяющие его к месту. А есть обезьяны, применяющие везде. Но инструмент-то в этом не виноват.