Ну не вся, я про это и говорю. Микроконтроллер далеко не всегда может работать без периферии, для интересных применений, с дисплеями и прочим, чаще всего требуется дополнительная периферия, как на фотографии выше. Собственно, на фото — процессорный модуль, он вставляется в хостовую плату, содержащую необходимую схематику для работы с дисплеем, выход на эзернет, GPIO и т.п.
Полагаю, проектирование и сборка подобного компьютера с нуля, вместе с установкой туда uCLinux — занятие намного более серьезное, чем пара кликов в ардуинчатой IDE и не уступает копанию в старых микросхемах.
Собственно, изначально моя идея в этом и состояла — что можно и с использованием современных микросхем разобраться в железе на очень глубоком уровне и, напротив, даже взяв старые, бездумно перекопировать схему)
Хм, не могу понять, что такого сложного в моих фразах
>можно с тем же успехом подключить внешнюю память
>Всяко будет периферия. А уж если говорить о более мощных, наподобие STM32F4 так там и память внешнюю часто требуется прикрутить, физические уровни интерфейсов и прочее.
Вы их намеренно не читаете, фиксировав для себя «микроконтроллер» = «один чип, АВР»?
Я сейчас даже безотносительно изначальной темы, я просто не понимаю, я недостаточно ясно выразился? Почему уже второй человек мне говорит про одиночную АВРку?)
Дык я про собранный девайс. Он-то уже контроллер.
АВР без доп. микросхем довольно мало на что способен. Всяко будет периферия. А уж если говорить о более мощных, наподобие STM32F4 так там и память внешнюю часто требуется прикрутить, физические уровни интерфейсов и прочее. Я ж говорю:
>а взять отдельный микроконтроллер можно с тем же успехом подключить внешнюю память
Несмотря на техническую навороченность, эти железки до ужаса скучные. Посудите сами: подал питание, загрузил программу,… и всё! А что делается внутри кремния, установленного на печатную плату — сие нам не ведомо.
Не согласен с этим. Вопрос подхода, ваш девайс в корпусе точно также могут использовать — подали питание и все. То, что вместо памяти на кристалле вы используете отдельный чип не коррелирует со знанием того, как работает железо, точно также можно квадратики соединить на схеме по даташиту (благо, типовая схема есть), и радоваться.
Если не брать ардуину, а взять отдельный микроконтроллер можно с тем же успехом подключить внешнюю память и на глубоком уровне понимать, как работает система.
На АВРке так и вовсе сделали эмулятор АРМа (да еще и контроллер DRAM!) и запустили линукс.
Так что я не думаю, что достаточно взять старые микросхемы, чтобы решить проблему незаинтересованности людей и подтолкнуть их к изучению глубин, а не поверхностному тырканью.
>Управляем регуляторами — управляем и двигателями, все просто.
Если бы все было так просто…
Согласен с предыдущим комментатором, заходил сюда в ожидании схемотехнических и программных решений по управлению BLDC, или хотя бы обзор интегральных драйверов этих двигателей (как у TI), а тут очередное «воткнем проводок в ардуину».
Ну а зачем изначально выбирать неподходящий кристалл? В 2012 году уже были те же СТМки с эзернет и аппаратным SDIO на борту.
Да даже без аппаратного SDIO DMA даст существенный прирост производительности, разгрузив процессор.
А так получается, что намеренно берем контроллер без ДМА, без СДИО, и долго решаем проблемы софтварно.
Ну просто жаль, что они столь закрыты и не расширяются — вышли бы к людям, опубликовали вакансии. Там и инвесторы бы, глядишь, потдянулись.
Мне, лично, было бы интересно посмотреть на их вакансии. Правда в Зеленоград совсем нет желания ездить(
Дык причем тут сеточка уже, вы же говорите «такого размера может быть только сонар за $15»)
Сеточка это понятно, я и сказал что это сонар. Кстати, не такой как на вашей фотографии, там отдельно приемник и передатчик, поэтому их два. А в вашем варианте это такой трансивер, который может и излучать и принимать.
Далеко не всегда. Только совсем безумные фанатики радуются смерти близкого человека «зато он теперь на небе», большинство же однозначно предпочло, чтобы он остался жив здесь и сейчас, для них это очень слабое утешение.
А что до менее трагичных ситуаций, с которых мы, собственно, начали этот диалог — примерно то же самое прослеживается, трудно продолжать верить в идеальный мир, и, главное, становиться счастливым от этой веры, если на деле твои перфекционистские усилия не ценят, премию платят Васе из соседнего отдела, потому что он к дедлайну успел склепать альфу, а ты «замки строил», начальство отговорки про «отвлекающих» уже не слушает и шлет нахрен…
Лучше смотреть на мир практичнее, намечать серию шагов, которые могут привести к улучшению, но в то же время не безумствовать с перфекционизмом, понимать, что «идеальность» недостижима, осознавать, где стоит «полировать», а где лучше «в продакшен».
Это только в идеальном мире.
В реальном — и отвлекающие факторы, и совещания, и внезапная смена ТЗ, и внезапно подвинувшиеся дедлайны, когда надо уже не замки строить а подпирать то, что есть.
Поэтому те, кто так наивно смотрят на мир — эдакие стереотипные программисты из воззрений 90х годов и ваших описаний, не в состоянии не только эффективно работать в реальных условиях, но и, зачастую, мешают работе остальных.
Например, если от них зависит критический модуль, а они все «строят замки» вместо того, чтобы сделать хотя бы прототип.
В общем пост реально очень похож на сборник стереотипов 90х — также, как, например, фильм «Хакеры» 95го года. Никто не говорит, что фильм плохой — обычные люди в те времена и в самом деле думали, что великий и ужасный шеф службы безопасности может, допустим, заехать на скейтборде к генеральному директору корпорации, сесть ему на стол. Сказать, чтоб этот генеральный звал его The Plague, а не мистер Белфорд и т.п.
Но в то же время это все далеко не соответствует реальности, только пересекается с ней в некоторых точках.
Да, я серьезно. С увеличением числа перфекционистов качественного софта больше не станет. Потому что его будут выпускать те, кто и выпускал, а перфекционисты все еще будут сидеть и переписывать первые строчки кода в поисках Той Самой Архитектуры, невероятно красивой, безумно универсальной, элегантно масштабируемой, но, к сожалению, не существующей.
Скольких я таких навидался. Планируют-планируют-планируют, потом рефакторят-рефакторят-рефакторят, в итоге софт до альфы даже не доходит. Если сверху не пнут и не скажут «пиши уже код, ...»
Наступает, а не наступило. Потому что за кадром в таких видео обычно стоит огромная вычислительная система, которая (это хуже всего!) наблюдает за «роем» через несколько камер. Так, например, работают всякие «рои» коптеров.
Наступит когда:
1) Этот «овермаинд» будет получать информацию от каждого робота индивидуально, а не через камеры
2) Роботы смогут питаться автономно, а не зависить от этого поля
Полагаю, проектирование и сборка подобного компьютера с нуля, вместе с установкой туда uCLinux — занятие намного более серьезное, чем пара кликов в ардуинчатой IDE и не уступает копанию в старых микросхемах.
Собственно, изначально моя идея в этом и состояла — что можно и с использованием современных микросхем разобраться в железе на очень глубоком уровне и, напротив, даже взяв старые, бездумно перекопировать схему)
>можно с тем же успехом подключить внешнюю память
>Всяко будет периферия. А уж если говорить о более мощных, наподобие STM32F4 так там и память внешнюю часто требуется прикрутить, физические уровни интерфейсов и прочее.
Вы их намеренно не читаете, фиксировав для себя «микроконтроллер» = «один чип, АВР»?
Я сейчас даже безотносительно изначальной темы, я просто не понимаю, я недостаточно ясно выразился? Почему уже второй человек мне говорит про одиночную АВРку?)
АВР без доп. микросхем довольно мало на что способен. Всяко будет периферия. А уж если говорить о более мощных, наподобие STM32F4 так там и память внешнюю часто требуется прикрутить, физические уровни интерфейсов и прочее. Я ж говорю:
>а взять отдельный микроконтроллер можно с тем же успехом подключить внешнюю память
Не согласен с этим. Вопрос подхода, ваш девайс в корпусе точно также могут использовать — подали питание и все. То, что вместо памяти на кристалле вы используете отдельный чип не коррелирует со знанием того, как работает железо, точно также можно квадратики соединить на схеме по даташиту (благо, типовая схема есть), и радоваться.
Если не брать ардуину, а взять отдельный микроконтроллер можно с тем же успехом подключить внешнюю память и на глубоком уровне понимать, как работает система.
На АВРке так и вовсе сделали эмулятор АРМа (да еще и контроллер DRAM!) и запустили линукс.
Так что я не думаю, что достаточно взять старые микросхемы, чтобы решить проблему незаинтересованности людей и подтолкнуть их к изучению глубин, а не поверхностному тырканью.
Если бы все было так просто…
Согласен с предыдущим комментатором, заходил сюда в ожидании схемотехнических и программных решений по управлению BLDC, или хотя бы обзор интегральных драйверов этих двигателей (как у TI), а тут очередное «воткнем проводок в ардуину».
Да даже без аппаратного SDIO DMA даст существенный прирост производительности, разгрузив процессор.
А так получается, что намеренно берем контроллер без ДМА, без СДИО, и долго решаем проблемы софтварно.
Мне, лично, было бы интересно посмотреть на их вакансии. Правда в Зеленоград совсем нет желания ездить(
Сеточка это понятно, я и сказал что это сонар. Кстати, не такой как на вашей фотографии, там отдельно приемник и передатчик, поэтому их два. А в вашем варианте это такой трансивер, который может и излучать и принимать.
Если нет вакансий, откуда они специалистов берут тогда? Так и работают изначальным составом?
Хм, не совсем понял эту фразу. Я видел камеры и такого же размера, и меньше и больше.
Это явно не камера на фото, а ультразвуковой датчик, сонар.
А что до менее трагичных ситуаций, с которых мы, собственно, начали этот диалог — примерно то же самое прослеживается, трудно продолжать верить в идеальный мир, и, главное, становиться счастливым от этой веры, если на деле твои перфекционистские усилия не ценят, премию платят Васе из соседнего отдела, потому что он к дедлайну успел склепать альфу, а ты «замки строил», начальство отговорки про «отвлекающих» уже не слушает и шлет нахрен…
Лучше смотреть на мир практичнее, намечать серию шагов, которые могут привести к улучшению, но в то же время не безумствовать с перфекционизмом, понимать, что «идеальность» недостижима, осознавать, где стоит «полировать», а где лучше «в продакшен».
Что будет, когда этот «идеальный мир» столкнется с реальным, совсем не таким радужным?
В реальном — и отвлекающие факторы, и совещания, и внезапная смена ТЗ, и внезапно подвинувшиеся дедлайны, когда надо уже не замки строить а подпирать то, что есть.
Поэтому те, кто так наивно смотрят на мир — эдакие стереотипные программисты из воззрений 90х годов и ваших описаний, не в состоянии не только эффективно работать в реальных условиях, но и, зачастую, мешают работе остальных.
Например, если от них зависит критический модуль, а они все «строят замки» вместо того, чтобы сделать хотя бы прототип.
В общем пост реально очень похож на сборник стереотипов 90х — также, как, например, фильм «Хакеры» 95го года. Никто не говорит, что фильм плохой — обычные люди в те времена и в самом деле думали, что великий и ужасный шеф службы безопасности может, допустим, заехать на скейтборде к генеральному директору корпорации, сесть ему на стол. Сказать, чтоб этот генеральный звал его The Plague, а не мистер Белфорд и т.п.
Но в то же время это все далеко не соответствует реальности, только пересекается с ней в некоторых точках.
Скольких я таких навидался. Планируют-планируют-планируют, потом рефакторят-рефакторят-рефакторят, в итоге софт до альфы даже не доходит. Если сверху не пнут и не скажут «пиши уже код, ...»
Наступит когда:
1) Этот «овермаинд» будет получать информацию от каждого робота индивидуально, а не через камеры
2) Роботы смогут питаться автономно, а не зависить от этого поля