А я вот в своё время намучался с Microchip-ами. Вот мой старый комментарий на эту тему: habrahabr.ru/post/131843/#comment_4376599
Вообще багов везде хватает. Это ещё маленькие восьмибитные микроконтроллеры, а вот Errata для некоторых больших ARM-ов c MMU порой приводит в ужас =)
Везде свои нюансы есть. У меня, к примеру, на PICKit-2 стабильно раз в месяц слетает прошивка, на ровном месте. Приходится его разбирать, и шить «шайбой» (ICD-2). Это хорошо, что она у меня есть, а если бы не было? Причём оная шайба не работает в новой MPLAB-X, Микрочип предлагает мне ее выбросить, и купить ICD-3. Плюс архитектуру 8и битных PIC-ов не пинал только ленивый, плюс ценовая политика, доступность свободных компиляторов (GCC), и т.д. Форум микрочипа изобилует темами, подобными этой, мол, прощай, гадкий микрочип, ухожу от тебя навечно. Нет в мире совершенства.
Ничего подобного не наблюдалось на stm, на power quiccII и III, на mcf5235. Собственно, и написал все это потому, что было с чем сравнивать. Понятно, что идеала не существует и баги есть везде, но не таких же и не столько же!
stm32 тоже «веселья» хватает.
В принципе в любом контроллере есть ошибки и всегда возникают ситуации, когда приходиться дико колдовать над кодом и вчитываться в даташиты.
Возможно автору так неповезло, что он собрал все возможные грабли.Я в своё время очень намучался с PIC, в частности с обеспечение стабильной работы USB(эмуляция com-порта через USB), радость моя была неописуема когда я вернулся к своему AVR.Теперь не в жизнь не захочу по своей воле работать с PIC исключительно из-за плохих воспоминаний.
Поддерживаю. У нас на предприятии как раз используются 32-битные LPC и 8-битные STM8. STM32 щупали, но по какой-то причине решили не применять. С STM8 тоже случаются иногда непонятные глюки, но очень редко.
> Можно было, например, переключить его с использования внутренней тактовой частоты на внешнюю.
Меня кстати иногда в этих случаях спасает волшебный палец
…
Вообще кажется Atmel болт положила на создание нормальной IDE, лично мне пока приходится юзать VMLAB для 8-ми биток, вроде все бы ничего, но практически нулевая подсветка синтаксиса
Ну и, вдобавок, напоролись на кривую, косую и глючную 5ю студию. Вам еще повезло, что она вообще увидела ваш отладчик. Реально работать можно только на 4й студии.
Что значит «напоролись»? То, что именно эта кривая, косая и глючная студия была на тот момент официально рекомендуемой Атмелом средой разработки, надо было просто не брать во внимание? Но не это ли как раз говорит об уровне системы?
Это говорит лишь о том, что где то в менеджменте атмела завелись придурки. Которые ЭТО выкинули в продакшн, выдав за основное решение. Скажите спасибо, что было хоть это. Другие производители часто и такого не дают. Предлагают сразу мол покупайте Keil, IAR или колхозьте сами на эклипсе из левых тулчейнов.
Вопрос про прогуляться вышли, что ниже, актуален. Да. Словно в первый раз, в самом деле.
зачем нужны кривые студии «от производителя» если есть универсальные качественные решения от тех, кто занимается разработкой именно софта…
я вот не понимаю. ну делает атмел кристаллы, хорошо делает (не без косяков, но не хуже других а во многом лучше), пусть делает.
в софт-то зачем лезть? :D
А вы никогда не пробовали убедить заказчика раскошелиться еще и на коммерческий тул, если на сайте производителя выложен бесплатный и к тому же рекомендованный? Особенно если решение об этом принимается тем, кто код не пишет и не писал?
Дело не в стабильности даже, а в поддержке собственных же инструментов. Например в 5 и выше студии забили на старые модели отладчиков и программаторов.
Тут ситуация такая, что обычно компания хорошо делает камни, а вот софт и родные отладочные средства делают аутсорсные китайцы и делают это на от… сь И это скорей правило, чем исключение.
Так что выбираем камень, потом, если нужно, ищем подходящую отладочную плату (не обязательно от производителя, скорей всего у него УГ) и подходящий софт.
Вы знаете у них своих американских «китайцев» хватает. В хорошо известной мне компании во время кризиса в Штатах сокращали целыми офисами. После кризиса, вместо хороших програмистов, инженеров электронщиков, набрали толпу людей с медицинской индустрии с опытом Visual Basic.
А насчёт софт, компании привязывают релизы и всю разработку к цыклу выпуска новых чипов. И если планировать чип достаточно просто, условно 3 месяца топология, 3 отладка, потом 3 для подготовки производства, то с софтом так не выходит, но никого не волнует им выкатывай функционал одновременно.
Ребята, а вы вообще embedded разработкой занимаетесь, или прогуляться вышли?!
Когда разрабатывается девайс — исходя из ТЗ подбирается процессор опираясь на требуемую накристальную периферию, объём ОЗУ процессора и его флешки, и ядро, если это важно (например, мы как правило берём только 51е, так как большой объём наработок под него у нас).
На процессор берётся даташит, и изучаются моменты, относящиеся к особенностям задачи.
Рисуется схема, разводится, спаивается один экземпляр, под него пишется программа.
Если програмно оказывается удачно поменять немного разводку — в штучном правится перемычками и правится разводка.
Когда ясно что разводка больше не поплывёт — заказывается изготовление плат, тем временем доделывается программа.
Занимаемся-занимаемся. В данном случае нами предлагалось 5 различных процессоров, именно исходя из требований периферии, производительности и т.п. Заказчик выбрал то, что выбрал, убедить его сделать другой выбор у нас не получилось — что ж, кто платит деньги, тот и принимает решения (и несет ответственность). А сроки не позволяли сделать вторую итерацию на другом проце — увы, так тоже бывает, когда все упирается в требование выйти на рынок не позже какой-то даты, т.к. если этого не сделать, то можно вообще ничего не разрабатывать.
Ну… как бы хорошо перед началом столь серьезного шага, как разработка и заказ плат, все же провести хоть какие-то тесты, нет? Для этого и нужны eval платы.
А что, вот на ЭТОМ собрать навесным монтажом быстрее, чем изготовить тем же ЛУТом (хотя, с сегодняшней доступностью химии, можно и фоторезистом) аккуратный тестовый образец?
Прибавить время на разводку и вычесть время на ковыряние тестером в соплях припоя и ногах кондеев. Особенно весело, если таки есть JTAG и какой-нибудь I2C.
1. Сначала все делаем в виртуальном мире — схему, растановку элементов (что сильно проще на экране, чем на макетке — ну, или это будет Горгона из МГТФ :)), и разводку.
2. Корректность разводки определяется атоматически, экономим время на проверку и/или исправления
3. Некоторые вещи на макетке раобтают сильно не так, как в жизни (ОУ с большим усилением, импульсные схемы, ВЧ, и так далее). На макетке сложнее добиться чистоты (отсутствия флюса).
Это только то, что сразу в голову пришло.
Разумеется, это все применимо только, если речь идет не об «пищалка на 555-м таймере».
Мне в последнее время (учитывая наличие правильной бумаги, принтера, ламинатораи бурбулятора с ХЗ) развести простенбкую платку и вытравить ее занимает от часа до трех.
И экономит безумное количество времени впоследствии…
Всем известно, что AVR дебажатся светодиодом и выводом в консоль, если доступен УАРТ. И программятся программатором из 5 проводков-на-лпт, тот же Дракон используют исключительно в режиме программатора. Зачем на МК с 16к Флеша смотреть стек вызовов? Видно автор знаком с программированием других МК в которых без дебаггера ничего не сделаешь и к AVR подошел с той же стороны, но тут свои нюансы.
Чтобы просто, быстро и без плясок со светодиодами ответить на вопросы:
1. Сработало ли прерывание таймера? (поставить там брекпоинт одним кликом мышкой, а не писать туда «Светодиод, зажгись» и изничтожать это в других местах)
2. А почему оно не сработало второй раз или не сработало и в первый? (запихать все регистры таймера в live watch и сразу же посмотреть, какие регистры чему равны)
3. Правильно ли посчиталась контрольная сумма? а на N-ном шаге? А какие были еще три переменные рядом? А адрес последнего посчитанного байта? (просто навести мышкой на нужные переменные после брекпоинта)
4. Завис ли контроллер и в каком месте? (ткнуть в break и увидеть, что он где-то посередине нигде лопатит непрошитую область)
Я уже не говорю о таких штуках, как RTOS, стеки и прочее подобное.
Я недавно портил ChibiOS на STM8S, если бы не дебагер, я бы там сдох на месте. Никакими светодиодами и юартами это не отладить.
Стек вызовов надо было смотреть на UC3A3 — там полноценная RTOS c весьма немаленьким приложением крутится, и флеша там 256к кстати.
На ATMega вообще в результате дебаггер не используется, отчасти из-за перечисленных проблем — image заливается в него через SPI c UC3A3. И не сказать, что это сильно упрощает разработку — порой возможность пошаговой отладки бы сильно ускорила процесс.
А пошаговая отладка делается в симуляторе, но там тоже свои гайки на которые новички обычно жалуются, типа watchdog не сбрасывается командой (для фикса надо просто его отключить), или прерывания от периферии не приходят (а им надо просто в ручную флаг установить) и т.п. Лично я в симуляторе только бизнес логику отлаживал, а периферию руками эмулировал, если было сильно надо. А в железе, светодиод наше всё.
Это просто подход к отладке: кто-то умеет читать код, а кому-то надо отладчик.
Я уже давно не пользуюсь отладчиком вообще, хватает отладочного вывода/светодиода.
DN OSP
Веб-проекты
Весьма нагруженная телефония (erlang)
Весьма нагруженные распределённые приложения (erlang)
Контроллеры измерения и управления (на 8051 embedded) — регуляторы температуры, расхода газа, ПЛК, хроматографы, и т.п. дребедень.
Но по-прежнему считаю, что в очень многих ситуациях самый простой и быстрый способ отладки — это таки пошаговая отладка с заглядыванием в регистры проца, переменные и т.п. Можно, конечно, обойтись и без этого — вопрос только зачем?
Простые ошибки на то и просты, что дебаггер там просто не нужен.
Сложные ошибки на то и сложны, что требуют совпадения фазы луны с напряжением в сети — тут отладчиком ловить крайне сложно.
А узкий пласт ошибок, когда знаем где, решается с помощью «дурака» — берёшь любого, садишь рядом, и начинаешь рассказывать что ты тут делаешь. Через 5 минут говоришь «вот я дурак», отпускаешь человека, правишь баг.
Проблема дебагера в том, что он наглухо ломает реалтайм. Ну ходите вы пошагово — это можно и в симуляторе проверить, а периферия то не будет вас ждать.
любой масштаб софта требует наличие грамотного логгинга. При наличии грамотного логгинга дебагер не нужен — в «подозрительном месте» добавляется еще одно log(DEBUG, ...) или как там у вас.
Мы тоже jtag не используем, светодиод и консоль достаточно всегда.
Jtag удобен, когда камень новый, плата первая и не стартует. Вот тут он помогает понять, что там вообще происходит и куда капать.
А когда проц запускается то, как ниже написали, грамотный логгинг решает все проблемы. Процессоры используем ARM. Системы с RTOS и без.
Абсолютно верно, сколько работал с ATMega ни разу не было необходимости в JTAG'е. С ARM и разными RTOS — аналогично. В случае проблем, прикидываешься процессором и сам в голове находишь проблемное место. Логгирование сильно помогает в этом.
Лежит у меня пара железячек в работе, внутри что-то вроде линукса, на одной железяке снаружи для отладки светодиод, на второй буззер (и тачскрин с графическим интерфейсом, но это непринципиально). Программируются скриптом паскалеподобным. Подключить дебаггер/отладить с мониторингом через комп — невозможно. Есть эмулятор на компе. Поведение почти :) похоже на железное. Пошаговой отладки нет. Скрипт на компе работает идеально, на железяке или команды не отправляет по сети или вообще уходит в перезагрузку (перезагружается не сама ось, а только скриптоисполнялка). Светодиод/буззер в данном случае помогают только факт перезагрузки установить, для прочей отладки толку от них нет. Я понимаю, что светодиодом можно логику отлаживать (попал в ветвление или нет, пришла команда снаружи или нет), но для этого и на тачскрин можно выводить значения переменных, а для установления причины глюков такой фокус не поможет.
Тогда надо подключать тяжелую артиллерию — редуцировать код пока сохраняется баг.
А там еще и осцилограф.
Помню весёлый эффект об отладке аппаратной. Еще 8080, код прекрасно работает на макетной плате, в реальном устройстве глючит. Втыкается плата пошаговой отладки, гоняется — всё прекрасно, сбоев нет. Запускается — сбоит.
В общем, нашли — микросхема памяти попалась бракованная, просто не успевала отрабатывать.
Рад бы, но железяка по сути своей закрытая, все что программисту-наладчику предоставлено — комп, скрипты и светодиод. До внутренностей системы (логфайл там почитать например) не добраться. Стоит относительно большых бабок, так что с отверткой туда не пускают. Да и чипы в ней заказные, так что и с осциллографа толку мало. Вот и лежыт уже пол года в лабораторных условиях и мигает светодиодом :)
А, вас в нутро не пускают… Нас пломбы не останавливают, так как мы и обслуживаем почти всё оборудование, в том числе импортное — это дешевле и эффективнее.
Ну так закрытая система, без бешеного реверсинжиниринга толку не будет, а платить за это никто не собирается.
Да и вообще «политика партии» такая, что если устройство отказало — списать и заменить новым. Ремонтировать никто не будет, зато можно кинуть его в ящик стола, а потом препарировать ради интереса.
В начале мы говорили про отладку светодиодом AVR. Понятно, что чем сложнее система тем труднее ее отлаживать. Хотя в Линуксе JTAG отладчиком тоже делать нечего. Там много своих средств отладки типа strace и gdb, ну и вывод в консоль (о котором я упоминал для AVR) и в лог никто не отменял.
И зачем вам понадобилась схема STK600, что вы там хотели увидеть? Все порты и все пины выведены там на колодки, а большего и не надо. Что куда выведено описано в документации.
Например, затем, что на avr freaks про этот toolkit часто писали, что на нем очень легко убивается блок питания, и без схемы это исправить практически нереально. В общем, показалось черезчур рискованным, и решили, что проще и дешевле обойтись без него.
А вопрос на самом деле не «зачем нам понадобилась», а «зачем Атмелу понадобилось ее прятать», не находите?
LOL похоже БП в их тулзах делает один и тот же человек. В AVR Dragon питальник тоже со свистом от тычка пальцем в конденсатор вылетает.
Вообще там из надежно проверенных только JTAG ICE II. Про него я ничего плохого не слышал, ну кроме того, что дорогой.
А открытых официальных тулзов я вообще ни от кого не видел. Тот же ST-LINK закрытый, Свисток от MSP430 тоже. Так что это частая практика. Только микрочип тут отличился, вбросил на публику свой пиккит 2.
Господа суровые железячники, а может мне кто-то объяснить, почему вообще кто-то еще использует микроконтроллеры, когда есть нормальные полноценные процессоры, позволяющие без проблем гонять там Linux и использовать практически любой удобный язык программирования, отладчик и среду?
Просто это напоминает спор ассемблерщиков и сишников. Типа ассемблер круто и всё такое, но время разработки на нем (самая большая статья расходов обычно) — в разы, если не десятки раз больше, чем на более высокоуровневных языках.
Не холивара ради, а просвещения для. Действительно не понимаю.
1) можно пример задач и примерного времени реакции?
2) если разработка крайне сложна и неудобно, открытых и популярных инструментов (стандартной библиотеки), как таковой нету (если и есть, то она на порядок хуже того же ulibc, например).
и 3 — понятно. Но если задача решается при этом несообразно дороже, то пункты могут перестать играть такую важную роль.
Как бы, не все на атмегах делают бортовые компьютеры космических кораблей… Да и потребление ARMов, на сколько я знаю, не сильно больше этих 8-32-битных контроллеров. По крайней мере, обвязка уж точно и там, и там сравнительно с процессором потреблять должна больше.
2) если разработка крайне сложна и неудобно, открытых и популярных инструментов (стандартной библиотеки), как таковой нету (если и есть, то она на порядок хуже того же ulibc, например) — это значительно удорожает разработку, как минимум, а еще и может сделать менее стабильной (непроверенные самописанные библиотеки => нестабильный код).
1) можешь привести пример с конкретными цифрами? мне правда интересно. Т.е. если, например, средний такой мотор с хоббикинга на 10к оборотов — сколько чего надо в секунду делать? считать каждый из 10к оборотов и выдавать импульсы наружу? с какой частотой? 10KHz? 100?
> Чем сложнее система, тем она хуже поддается контролю.
Линукс — сложная система, не спорю. Но любая разработка — это набор стандартных (читай, написанных не тобой) библиотек, плюс твой личный код. У меня. например, если брать по соотношению строк кода — моего кода может 1-2% от библиотек. А то и еще меньше, если посчитать строки кода ядра :)
В случае микроконтроллеров какое соотношение?
ну вот простая задача — терморегулятор. это такой автономный блок.
Задача 1, измерение: с фиксированной частотой (от 10Гц) производить измерение напряжения с термопары и измерение температуры холодного спая, по табличке пересчитать в температуру.
Задача 2, регулирование: сравнить уставку с измеренным, вычислить требуемую выходную мощность.
Задача 3, управление: дождаться перехода через 0 напряжения в сети, отсчитать время пропорциональное требуемой мощности, выдать сигнал на симистор для поджига.
Ну вот контрпример — секретарь-машинист.
Задача 1 — записать речь начальника — берется бумажка и стенографируется.
Задача 2 — отпечатать речь начальника — берется бумажка со стенограммой и перепечатывается на пишмашинке.
Задача 3 — сделать три копии речи. Берется бумажка со стенографией и перепечатывается на пишмашинке 3 раза (продвинутый вариант — под копирку).
В общем, не убедительно.
Контр-примеров могу привести много.
Например, стоит у меня дома стиралка. С каким-то там очередным микропроцессором. А вот хочу я туда залезть. Не с jtag/com/can (тем более что в продакшн-версии, небось, они и не распаяны), а через ssh, крон написать — напоминать постироать и триггер повесить — смс мне отправлять по окончанию стирки.
В случае линукса задача делается на раз. На конечной стоимости продукта не скажется вообще никак (5 долларов вместо 0.5 при себетоимости в 200-500 — копейки).
Пришли же к этому в роутерах, хотя тоже пальцем у виска крутили — «роутер — что б роутить, какой еще торрент туда?». А в итоге к роутеру даже монитор подключют и встроенный плеер крутит свежескачанные им же торренты в HD.
И как противоестественное это не воспринимается, привыкли.
А как терморегулятор автономный (читай — запаянный, влезть — ни-ни), должный на скорости в целых 10 герц управлять техпроцессом — так почему-то микроконтроллер. Хотя впарят этот терморегулятор не по себестоимости железа (2-5 баксов), а за 50-100 (продакшн! хай кволити! надежность! микроконтроллеры!). Но линукс туда ни-ни. И прошивку потом поменять (поправить баги одноразовых программистов из предыдущего коммента) — ни-ни. И перенастроить на режимы, про которые маркетологи не додумались изначально — ни-ни.
ну в терморегуляторе еще наружу как правило торчит последовательный канал, позволяющий менять уставку.
к этому последовательному каналу прицеплен компьютер, на котором уже линух и управляющее ПО.
делайте что хотите. но не надо пихать то, что не требуется туда, куда не требуется.
… на котором линух, на котором в dosbox'е крутится закрытое кривое управляющее ПО, общающееся с железякой посредством закрытого проприетарного протокола…
сталкивался, да. Не припомню ни единого доброго слова авторам железяки, протокола и софта, к сожалению…
Прямо ща вот работают с одной такой. Принтрбот называется. Электроника — какая-то атмега. Управляет 4-мя степперами, два нагревателя, два датчика температуры. Трахинг с ней — сказочный.
Даже несмотря на то, что есть софт под все платформы (открытый, несколько вариантов), есть прошивки альтернативные (тюнинг и допиливание — пожалста). В итоге — уныло. Подключается usb (usb2com) кабелем. Или флешку втыкать. Печать через usb-кабель — существует вероятность
а) зависания кабеля
б) зависания программы
в) зависания хз чего, но печать прерывается.
Заливаешь на флешку (интересно, как скоро умрут контакты на материнке?) — прошивка умеет только FAT и имена файлов в стиле 8.3 (спасибо, родные, у меня одни .gcode).
Кто им мешал поставить ARM и полноценный линукс — я не понимаю. За электронику отдельно от принтера они 130 баксов. Пусть бы стоил 140, но
1. с полноценным линуксом на борту
2. с нормальными коммуникациями (ethernet/wifi)
3. даже пусть с встроенным веб-интерфейсом — загрузил из браузера .stl, оно само сконвертило в .gcode, пошло печатать, по окончании прислало смс, дернув внешний веб-сервис.
Но нет — микроконтроллеры наше всё. Зачем — не понимаю.
Блин, так с этого и начинался разговор, что если бы они не парили мне мозг микроконтроллерами, закрывая все входы и выходы, а ставили бы что-то продвинутое, с линухом на борту, то и мне был бы профит, и производитель мог бы чего-нить поиметь (индустрия аддонов и альтернативных прошивок — не самое плохое дело для производителей, как бы), и все эти плюшки, на деле, могли бы стоит не слишком дорого. Т.е. я пытаюсь понять (цитирую себя), почему за минимальные потери никто не хочет обрести вполне себе ощутимый профит. И пока не понимаю и никто не просветил.
Потому, что конечному пользователю в 99% нужно чтобы включил и работало. И чтобы сломать было как можно сложней.
Как думаете какой процент будет ставить аддоны на стиральную машину? А альтернативыную прошивку? А если эта альтернативная прошивка затопит соседей снизу?
А также чтобы другие производители стиральных машин взяли и внаглую спопячили алгоритмы и встроили себе?
> Как думаете какой процент будет ставить аддоны на стиральную машину? А альтернативыную прошивку? А если эта альтернативная прошивка затопит соседей снизу?
Какое количество пользователей скачивает аддоны к Half Life? Starcraft? Diablo?
Какое количество пользователей качают торренты своим adsl-роутером?
Какое количество пользователей фотографируют телефоном?
Это все называется — неокученный рынок. Пока не начнешь — не поймешь профита.
> А также чтобы другие производители стиральных машин взяли и внаглую спопячили алгоритмы и встроили себе?
Ну это стандартные страшилки проприетарщиков. Как будто «запаянные вглухую цепи без кислоты и такой-то матери не подберешься» — кого-то останавливало. Ну и крутые алгоритмы стирки, которые я опознаю на слух после второй стирки — та еще интеллектуальная собственность.
Меньше 1%. Сильно меньше. Даже я, умея все это и то ленюсь похачить свой роутер. Мне проще комп не выключать. Т.е. более чем 99% на это насрать. Включил и работает. ОК.
А по поводу алгоритмов стиралки…
Хы. Это оно с виду только бултыхает и крутит. А продвинутые машинки чуть ли не химсостав порошка и воды анализируют, проверяют температуру и жесткость воды (на основании этого добавляют нужное количество порошка), распределение температуры по баку, развесовку белья, плюс какие то динамические ускорения, чтобы белье не бултыхалось как попало (а то изнашивается сильней и машинка скачет) плюс куча защит от всего что можно. И все это скрыто за циферкой режима и кнопкой START.
> Меньше 1%. Сильно меньше. Даже я, умея все это и то ленюсь похачить свой роутер.
Сапожник без сапог, это понятно. А вот какое количество юзеров ставят примочки для разнообразия своей винды, всякие аддоны и плагины для всевозможного софта — ты удивишься.
> Мне проще комп не выключать. Т.е. более чем 99% на это насрать. Включил и работает.
Заграницей электричество дороже. Поэтому если роутер умеет качать торренты и хавает при этом в разы меньше энергии — этим будут пользоваться. И, к слову, для этого ломать роутер не надо. Есть куча уже готовых, с красивым удобным веб-интерфейсом.
По поводу машины и порошка — ок, может быть. Хоть и сомневаюсь слегка :)
> Вот именно, что куча готовых. С красивым интерфейсом. Пользователь купит его и ничего не будет переделывать.
Пока появилась куча готовых — народ переделывал то что было. OpenWRT не от хорошей жизни появился. И юзает его пусть и 1%, но в размерах планеты — это немножко дофига людей. Просто потом производителям дошло, что кастомизация и многофункциональная прошивка — востребовано, а не «нужно 1% людей», «никто не будет туда лазить», «дорого в роутер линукс пихать» и т.п. :)
Если они дадут возможность лазить в стиралку — это им не только туда придется линукс пихать и проц дороже. Им придется еще потом отвечать на остальные вопросы:
1. почему не открываете исходные коды?
2. кто так строит пишет?
3. какого хрена у меня не работает?
4. почему у вас нет техподдержки?
5. почему нету usb (hdmi, rs-485, wi-fi...)?
И заводить отдельную техподдержку в Индии. Так как 99.9% домохозяек хотят нажать на кнопку и приджти, когда запищит, оно того однозначно для них не стоит.
Но Вы, конечно, можете сделать свою машинку с блекджеком и линуксом :)
Им и без линукса техподдержку держать надо. А с линуксом можно делать как тот же dlink в своё время: вначале не мешали перепрошивать (mcmcc тут же начал клепать прошивки за прошивкой, за ним другие потянулись), потом начали выкладывать mcmcc'шные прошивки у себя на ftp, потом вроде как и ставить их себе начали. И не думаю, что они сильно страдали от потока писем «почему чужая прошивка мне убила роутер». Они просто не обязаны отвечать на то, что не описано в гарантийном соглашении. Почему линукс внутри что-то поменяет в этом плане?
Там все равно какая-то ОС внутри живет, но нафига им куча лишних прослоек между железом и логикой?
Основное свойство линукса тут — универсальность — хочешь апач поставь, хочет — питон. А им это все не надо, у них конечное количество тредов и это реально надежнее, тупо за счет меньшего количества кода.
В роутере и вправду проще поставить линукс, потому что основная задача роутера — роутинг — в линуксе УЖЕ сделана. А драйверов стиралок там нет…
свою стиралку с блэкджеком и линуксом уже сделали до меня. Я просто не понимаю, почему остальные не чешутся, пытаюсь найти разумные доводы. Пока не особо, если честно.
А линукс уже научились пихать в квадратик 5х5 мм без внешней умной обвязки?
Опять же потребление. То, что ARM сравнился по потреблению с 8ми битниками, ну да. Только при этом он наглухо забивается в спячку, отключена большая часть периферии и прочее. А при запуске на полную мощь он хавает очень и очень даже ощутимо. Особенно для батарейных применений.
Система на линуксе может проснуться, за 2милисекунды сделать все что нужно, и снова свалиться в спячку? Для любого МК работающего от батарей это, зачастую, самый обычный рабочий цикл.
Я выше по треду описал электронику принтрбота (3d-принтер). В его габариты отлично попадает raspberry pi. Питание внешнее, без батареи, спячка не нужна. От микроконтроллера тут только проблемы.
А там надо смотреть на то, что делает этот контроллер. Если он просто тикает такты для специализированного контроллера шаговика (аля L297), то МК там как корове седло. Можно было загнать все в LPT порт любого компа, подключить все к MACH3 и не париться. Сделав все программно.
Если же МК там генерирует хитрые шимы для микрошагового режима шаговиков (4 канала на движок, с частотой в сотни килогерц, хитрые алгоритмы) то линуху там делать нечего — быстродействия не хватит.
Ну или можно было толково сделать на том же МК, прицепив к нему эзернет контроллер и подняв на МК вебсервер. Видимо у разработчиков мозгов на это не хватило.
Я б, честно, сделал бы это как полноценный комп (на арм или чем угодно) + управляемые через i2c контроллеры.
Понятно, что в этом контроллере был бы микроконтроллер для тех же импульсов для шаговых двигателей. Но вот внешнее управление стоило бы сделать высокоуровневым. Т.е. разделение абстракций по уровням:
1. команды вида «загрузить модель», «запустить печать» — линукс, веб-интерфейс, ethernet
2. команды шаговым двигателям «повернуться на N градусов», команды регуляторам температуры «нагреватель A в 210 градусов». И это все еще высокоуровневые команды, из линукса на внешний контроллер
3. ну и на этом уровне самое что-то простое, умеющее только принимать команды снаружи (со второго уровня) и преобразовывать в команды для нагревателей и движков.
Но главное что бы все три уровня были в одной коробке (на одной плате), т.е. что б это решение было автономное. Да, я тут описал вместо одного микроконтроллера — один микроконтроллер и один полноценный компьютер. Но удорожало бы это систему не сильно (исходная стоимость — 130 баксов, напомню. А тот же распберри стоит 40).
Зачем разрабатывать с нуля миникомп?
Почему не взять уже готовое? Много их. К тому же распберри пи нужно всего лишь добавить управление шаговыми двигателями и температурой. Я находил похожее с i2c интерфейсом. Цены, правда, дурные (к слову о себестоимости). Но в сумме можно уложиться почти в то же. Но профита будет неимоверно больше.
Будет дороже. Опять же если сам что то делаешь, то проще делать все от и до. Чем гемороиться с закупками чего то там, думать на предмет того, а не сдохнет ли оно внезапно, не исчезнет ли? Экстренно переделывать все в случае чего. Плюс дополнительная логистика, дополнительные расходы. Лишний геморрой.
У вас интересный дар видеть только вершину айсберга :)
Как раз наоборот. Готовый распберри пи + готовый контроллер моторов надо всего лишь купить и объяснить юзерам, какой шлейф в какой порт втыкать. И если вдруг умрет производитель распберри или контроллеров — подбирается другой, потому что линукс везде один, i2c тоже стандарт, протокол степперов, опять же, не закрытый, не проприетарный. И свои платы не надо дизайнить. Только софт, который еще можно отдать на откуп комьюнити (к слову, прошивку для принтрботов юзают какую-то открытую, сами не делали). А вот плату, я так понял, делали сами. Одни расходы.
> У вас интересный дар видеть только вершину айсберга :)
Это только так кажется. Когда у тебя готово и уже прошито 100500 плат под определенную железку, а ты внезапно узнаешь, что ее больше нет и все надо переделывать… В общем это хороший такой баттхерт. Тогда уж делать привязку к любому PC совместимому компу со стандартными интерфейсами и софтом.
А вообще это у них надо спрашивать почему так, а не иначе. Я бы тоже сделал все на МК, т.к. в линухах (да и вообще комповом программировании) ваще не шарю и даже хеллоу ворлд не напишу. А на МК да за нефиг делать.
Позвольте оживить тему…
Я сейчас делаю робота. Связка seeeduino adk + смартфон с андроидом. Например. датчик температуры через МК скидывает данные на смартфон, а он в свою очередь делает высокоуровневую обработку — отсылает в почту.
И я абсолютно согласен с вами по поводу стиральной машинки с линуксом :)
Батарейное применение с хитрыми циклами спячки — спорить не буду, с линуксом будет очень не просто это сделать. Но это не 100% применений микроконтроллеров.
Оглянувшись, я насчитал десяток микроконтроллеров в разных девайсах в квартире, но ни одного батарейного, с суровой спячкой и принципиальной бесприбыльностью установки линукс-совместимого проца.
>Например, стоит у меня дома стиралка. С каким-то там очередным микропроцессором. А вот хочу я туда залезть. Не с jtag/com/can (тем более что в продакшн-версии, небось, они и не распаяны), а через ssh, крон написать — напоминать постироать и триггер повесить — смс мне отправлять по окончанию стирки.
А я, простите, не очень хочу его спрашивать, что он хочет, а что нет. Это моё личное право. Стиралка — даже не софт с сомнительными лицензиями (ты не купил, а взял в аренду свой виндовс, поэтому лазить внутрь нельзя). Стиралка моя личная. Хочу — использую как есть, хочу — залажу внутрь. Понятно, что гарантийное соглашение я читал и всё делаю на свой страх и риск.
> Тоже пускай каждый внутрь залезает и правит что хочет?
Таки да. Но мы же не машиниста имеем ввиду, правда? А, например, сборочный цех локомотивов, которые закупили тормоза у сомнительного подрядчика, который сделал «для юзеров, без возможности разборки и настройки», и заводу с этим черным ящиком приходится работать — ни настроить, ни модифицировать. Просто потому что у подрядчика были умные маркетологи и юристы, которые за всех решили — что надо заводу, а что не надо.
Такой блок должен просто работать, выполнять свою функцию. Там не место каким-то настройкам, твикам и т. п. Отход от этого принципа приведёт в конце концов к крушению поезда.
Условия меняются. Вчера это был тормоз для локомотива, сегодня — для трамвая. Масса другая, рельсы другие, воздух и влажность, в конце концов, другие могут быть. Маркетологи тут же быстро подсуетятся, подсунут тот же тормоз, но с другой прошивкой под видом «специально для трамваев», а на деле корректировки мог сделать сам завод. У них свои спецы есть, как бы.
Вот когда в поезде (метро, самолетах) появится USB-разъем в юзерской зоне для программирования, я перестану ими пользоваться. Мало ли кто плагин для вывода на орбиту туда подсунет…
> Вот когда в поезде (метро, самолетах) появится USB-разъем в юзерской зоне для программирования, я перестану ими пользоваться.
Самолёты давно управляются софтом (и там есть не только usb), не понимаю проблемы. Почему в крайности надо бросаться-то? Либо заклеенный МК, либо usb-порты наружу там где их не просят?
Заказчик обычно знает, что ему нужно — прибор или конструктор. Закажут конструктор на линуксе — разработчики сделают ему конструктор на линуксе. Если есть в том потребность.
Вчера это был тормоз для локомотива, и сегодня он останется тормозом для локомотива, и завтра. Что там устанавливают на трамвай, предприятиям железнодорожной промышленности неведомо, потому что это совершенно другая область.
Пример: недавно писал драйвер для управления UHF RFID считывателем. Для того, чтобы считыватель правильно работал, в некоторых случаях время реакции контроллера на внешнее прерывание должно быть в пределах 50-75 микросекунд (вернее за эти микросекунды надо успеть еще и послать 1 байт по SPI). Даже если ядро Линукс скомпилировано как ядро реального времени, скорее всего сработать не успеет. Решением было выделение отдельного маленького контроллера для управления считывателем, который связывался с основным контроллером по UART.
Пример:
устройство на основе микроконтроллера при правильной трассировке способно выдержать многократный удар электрошокером, даже не сбрасывается.
встраиваемые ПК в большинстве своем и все ПК сбрасываются даже если рядом с корпусом электрошокером пощелкать.
То есть с точки зрения электромагнитной совместимости микроконтроллеры выигрывают. И там где есть наводки, двигатели и любые силовые ключи — их стихия.
Так что не все так хорошо и с МК, видимо :)
Удары электрошокером, подозреваю, одинаково хорошо выдержит и МК, и ПК, если оба одинаково к этому подготовить. Физика одна и с элетрическим пробоем что МК, что ПК работать не будет. Или нет? Понятно, что МК может выиграть за счет простоты, но пережить пару киловольт и не сгореть, просто потому что МК — не очень понятно почему.
Процессор с линуксом может не заработать просто из-за не правильной трассировки шин памяти. Соответственно восприимчивость к внешним воздействиям больше. А значит сложней подготавливать, если совсем возможно.
если вы производите 1 девайс, стоимость процессора 20$ против 10$ не имеет роли.
когда вы производите 1 млн девайсов, эта разница выливается в 10млн$.
причем процессор за 10$ в объёме млн штук производить можно по 0.5$, а более мощный — только извините за 5$. итого разница выливается в огромные суммы.
вы напомнили мне недавно на форуме виденное.
человек сделал поворотники на велосипед. голова — stm32. в каждой фаре — stm32.
управление по радиоканалу.
Ну и, собсно, неужели процессор в конечном устройстве составляет значительную долю стоимости? Это ж не интелы/амд, где процессор стоит 100-200 долларов и реально заметен в устройстве.
Материнская плата, обвязка, экран там, периферия…
нет, не значительная. просто даже на тысяче штук экономия на 1 элементе в 1 бакс = 1 килобакс.
на пяти тысячах — 5 килобаксов.
причем затраты на программиста разовые, затраты на производство — повторяемые.
Линукс даёт гибкость, микроконтроллер — железобетонную предсказуемость поведения. У вас случайно соседний ssh не сожрёт CPU, отдав вам квант времени только через несколько миллисекунд, посреди выполнения кода у вас не возникнет page fault с подгрузкой куска программы с бинарника, и все прочие вещи, сопутствующие многозадачности.
Я в своих разработках всегда рядом ставлю микроконтроллеры и линукс. Линукс отвечает за высокоуровневую логику, контроллер — за работу с датчиками, приводами, протоколами обмена и т.д.
Я бы сказал, что все ответы вам в этом треде нормальные и правильные. Мой, как бы, тоже был скорее возражением. У каждого инструмента есть своя область применения. Даже несмотря на то, что микрокомпьютеры с линуксом становятся всё дешевле, они не подойдут для всех задач. Хороший пример был с симисторным регулятором мощности. Грамотно сделать его на линуксе (с запретом прерываний на время регулировки, с настройкой ОС, чтобы вам гарантированно выдала квант перед следующим полупериодом) — весьма нетривиальная инженерная задача.
Не буду вступать с вами в дискуссию, благо занимаются этим специалисты серьёзнее меня.
Если вы действительно хотите получить ответ на свой вопрос, то прочитайте, чем отличаются системы реального времени от систем общего назначения.
Если вам этого будет недостаточно, то постарайтесь придумать, как с помощью нормальных полноценных процессоров реализовать электронику современного автомобиля.
> Если вам этого будет недостаточно, то постарайтесь придумать, как с помощью нормальных полноценных процессоров реализовать электронику современного автомобиля.
Я не настаиваю все МК поменять на cpu общего назначения. Я говорю о ситуациях, когда можно поставить или/или, но ставят МК и парятся с наведенными траблами (проблемы с разработкой, проблемы с поддержкой, проблемы с расширением).
Опять же, я не спорю с вами, но давайте разберём пример, приведённый вами выше: стиральная машина. Представим, что в ней установлен простой DC двигатель на барабане, один DC двигатель на насосе, 2 электронных клапана, датчики температуры воды, пьезодатчики на оси барабана, оптопары для измерения скорости вращения барабана, защёлка передней крышки, механический енкодер для выбора программы, 6 кнопок и монохромный дисплей.
Получается: 2 ШИМа, 3 логических выхода, 9 линий входа (предположим, что разработчики не используют динамический опрос кнопок и вспомогательную цифру), 4 аналоговых входа для датчиков и ещё 2 для мониторинга сотояния двигателей (чтоб двигатель не клинило или, чтоб он не работал в холостую). Интерфейс дисплея последовательный.
Какой полноценный процессор вы выберите для реализации управления этой машинкой и как вы представляете его работу?
Вы забыли про пользовательский интерфейс. Обычно сейчас это крутилка и пара кнопок. Возможно, с экраном. Возможно, тачскрин.
А хотелось бы еще, например, внешний интерфейс, например, с нотификациями вида «дернуть урл», «проиграть мелодию через встроенные колонки или airplay», snmp-trap, в конце концов.
И вот смотрю (ставлю себя на место разработчика) я на это всё и понимю:
1. Маркетологи захотят 3-5 моделей с набором опций (см. выше) в разных комбинациях.2
2. Низкоуровневая элементная база остаётся одинаковой — барабан и датчики везде одни.
3. Интерфейс везде разный. Типа.
И первое решение, которое приходит в голову — управление моторами, контроль датчиков и т.п. — одна плата. Берем универсальный контроллер (гуглим steppers + pwm + gpio + i2c), берем универсальный компьютер (да тот же распберри — его хватит). Включаем одно в другое. Ставим линукс. Осталось написать софт, стартующий при включении и управляющий микроконтроллером для процесса стирки.
Вывод на экран — хочешь x11, хочешь opengl. Коммуникации — ethernet/wifi уже есть. Экран — hdmi уже распаён. Тачскрин — возьми usb-шный и загрузи драйвер мыши в ядро. Это всё уже есть, ни одной лишней строки кода писать не надо.
Сделать стиралку, подключаемую к интернету — прошивки можно будет скачивать хоть автоматически. «В новой версии прошивки появился SNMP! Промышленная стирка стала еще проще!». Убедите меня, что SNMP в стиралках не нужен.
Маркетологи могут продавать будущие функции, зная, что для развития обычной стиралки достаточно залить другую прошивку / поставить аддон. Что там поменялось за 100 последних лет? Набор датчиков и моторов остался неизменным, а высокоуровневая логика, которую может дописывать любой китаец, знающих php — огромное преимущество.
Да екарный бабай…
Не берем. Ничего мы не берем. Мы разрабатываем. Самоделки из серии «Ардуино управляет космолетом» как была, так и останется уделом любителей.
Подход «мы щас возьмем воон ту плату, которую делает Вася из Урюпинска и называет ее „МоёДуино“, потом gsm-модуль еще вот отсюда и где-то у меня там тиристоров пачка валялась и соберем клевую стиралку из говна и веток — НЕ РАБОТАЕТ. Один экземпляр для себя — да хоть с виндой внутри, промышленное исполнение для массового производства по определению создается с нуля, без лишних деталей или функциональностей. Ибо дешевле. Для пользователя, в итоге.
Стиральная машина, которая будет глючить раз в десять стирок, полетит из окна нахрен — она должна работать как часы. Она должна стирать. Не писать свои статусы через веб-интерфейс в твиттер, а СТИРАТЬ БЕЛЬЕ. Ей не надо свистелок-перделок и загружаемой мелодии конца стирки.
Она просто должна работать НАДЕЖНО. Линукс, который с железом общается через железо-драйвера-ядро-юзерспейс-ядро-драйвера-железо — по определению менее надежен и избыточен.
Стиральная машина, которая, мать ее, ЗАГРУЖАЕТСЯ??? Проверяет диски, если ее вырубить из сети? У которой дохнет флеш? Которую надо обновлять? Подключать ее в домашнюю сеть, чтобы поглядеть достирала ли она? Потом еще Касперского для стиралки скачивать? Да ну нахер! Это из разряда „фонарик с ethernet, который через веб-интерфейс показывает уровень зарядки батареек“.
Ваша главная ошибка — это то, что Вы думаете, что нормальное промышленное (и даже консумерское) оборудование и то, что слепил энтузиаст из Урюпинска из конструктора Лего — одно и то же, только у энтузиаста оно еще и лучше (потому что с финтифлюшками).
Так вот нифига. То, что делает энтузиаст из Ардуины — нетиражируемое, ненадежное, дорогое и сильно избыточное решение для простой задачи „постирать белье без участия человека“.
Задумайтесь — Вы до конца даже не знаете, что должна делать эта хрень (ну, кроме, уведомления о конце стирки), и извините, но нифига не понимаете в том, как делается надежное оборудование, но рьяно хотите, чтобы лично для вас во все, где есть хоть что-то сложнее таймера, ставили линукс.
У меня есть вкрадчивый осторожный вопрос: а почему не виндовс?..
В почти любых довольно нормальных машинах имеется диагностический разъем, куда выводится в том числе и интерфейс на контроллер. При наличии легких изменений (а может, даже и без них) можно сделать дополнительное устройство, которое подключается к сущестсвующему контроллеру в одном местеи наружу торчит файфаем, езернетом, почтовыми голубями и т.д.
Это позволит:
— использовать существующее железо без переделки
— не снизит надежность основных процессов
— позволит продавать дополнительное устройство для гиков задорого
— не увеличит стоимость для подавляющего большинства потребителей
> — позволит продавать дополнительное устройство для гиков задорого
Да-да, обычно так и бывает. Шина, вроде, и USB, а втыкать можно только «сертфицированные производителем устройства», потому что они нам, козлы, доходы уменьшают. Почему они хотят втыкать китайский usb-wifi за 5 баксов, если наш стоит всего 70??? Козлы, не иначе.
Так там линукс внутри. Драйверы уже есть. Максимум, .ko залить. Кто-нить добрый соберет очередной .ko под очередную железку и всё ок. Был бы интерфейс для залития .ko (ssh, который никому не нужен, да).
В базовом ядре хватает дров под все, что шевелится. По крайней мере, в моем случае, в телевизоре есть драйвера (и блокировка по USB-ID) на ровно 1 модель. А в том линуксе, который там стоит, может быть поддержка N (N больше 100500) usb-wifi устройств. Залил .ko-файл в телевизор, воткнул любой usb-wifi и вперёд. TCP стэк одинаковый везде.
Но нет, в самсунге решили по своему. Шелла нет, есть DRM.
Но это почему-то не мешает появляться альтернативным прошивкам. Кто только их делает — если их 0.1%… Риторический вопрос :)
Был где-то проект, где линукс-разработчики предлагали писать драйвера (бесплатно) производителям железа. Единственное требование — наличие спек, пусть даже под NDA. Так что не проблема, честно.
> Под что драйвера есть, под произвольный usb-wifi?
Под совместимый с самсунговским (но стоящий в 10 раз дешевле), либо загрузить скомпиленный модуль.
Это реальное положение вещей, что сейчас происходят, я не из головы это выдумываю. У меня дома такой телевизор стоит. Прошивку только поменять не могу, потому что она низкоуровневая сильно (привет, микроконтроллеры), и не под мой регион еще не собрал никто (под другие есть).
Если брать бытовую технику, где электроника не является основной фичей (как в смартфоне, например), то там стоимость именно электронного RD ничтожная по сравнению с остальным.
Я имел ввиду только софт. С электроникой и тестированием получилось бы поболее конечно.
Хотя… контроллер Для Вятка-Автомат 16 (взамен сдохшему механическому коммандоаппарату) я склепал за вечер, и за второй написал прошивку по скану бумажной циклограммы). На столе все работало как часы. Правда так и не поставил, т.к. у машинки до кучи прогнил еще и бак. Пришлось выбросить.
Но вернемся к вашим расчетам. Добавим к стоимости разработку прессформ для пластика и их изготовление (100000 евро, минимум), разработку технологической оснастки для сборочной линии (уже приближаемся к миллиону), разработку всего железа, оплату технологам, сертификации и еще кучу всего разного. Достаточного для того, чтобы даже 100 000 евро за электронику выглядели ничтожным пятнышком на фоне огромной громады остальных затрат. И это только разработка. А есть еще себестоимость изготовления, сборки, логистики, материалов, зарплатный фонд.
>Если брать бытовую технику, где электроника не является основной фичей (как в смартфоне, например), то там стоимость именно электронного RD ничтожная по сравнению с остальным.
Речь же шла о массовом производстве. Не тысячи штук, а сотни и миллионы экземпляров. Там доля RD часто минимальная. А если еще себестоимость судиться по примерной розничной цене комплектухи, так реальная выходит еще и сильно ниже даже с учетом RD
> промышленное исполнение для массового производства по определению создается с нуля, без лишних деталей или функциональностей. Ибо дешевле. Для пользователя, в итоге.
Ну да, конечно. Движки делаем сами, кнопки делаем сами, микрухи каждый раз проектируем с нуля. Даже шнур 220V делаем с нуля, придумываем каждый раз состав пластика…
Наоборот все к унификации идёт. Те же микроконтроллеры — тому пример. Относительно малой кровью получается универсальность. Но я о том и завел спор — на сколько эта кровь малая и на сколько универсальная получается универсальность — не стоит ли подняться на уровень выше? Всё остальное — лирика, попытка приблизится к ответу.
> Стиральная машина, которая будет глючить раз в десять стирок, полетит из окна нахрен — она должна работать как часы.
Эта фраза ни о чем не говорит. Бывает неглючный софт для ПК, бывают глючные решения на микроконтроллерах.
> Линукс, который с железом общается через железо-драйвера-ядро-юзерспейс-ядро-драйвера-железо — по определению менее надежен и избыточен.
Миллионы серверов с многолетними аптаймами с вами не согласятся. Да, менее надежен, да, более избыточен, но достаточен.
> Ваша главная ошибка — это то, что Вы думаете, что нормальное промышленное (и даже консумерское) оборудование и то, что слепил энтузиаст из Урюпинска из конструктора Лего — одно и то же, только у энтузиаста оно еще и лучше (потому что с финтифлюшками).
Да нет. Я нигде это не говорил.
Вот стоит у меня на столе телефон Polycom. SIP, линукс, POE, ethernet, десяток кодеков, веб-интерфейс, прошивки, кастомизация, xml в каждой щели.
Производится в промышленных масштабах. Работает надежно (ни разу ни один не завис, аптайм — годы).
И вспоминаю про аналоговые телефоны, с наборным диском. Вроде та же функция — звонить. Но при этом там даже микрух не было, все аналоговое. Но почему-то в итоге перешли на полностью программные решения (да, я понимаю, что в этом же поликоме есть с десяток микрух, но ядро — полноценный компьютер, что-то на ARM мегагерц на 600).
Почему то же не может произойти со стиралками — не понимаю.
Мы про электронику управляющую вообще-то говорили, причем тут пластик для проводов.
В качестве примеров Вы почему-то всегда приводите те устройства, подавляющее большинство функций которых УЖЕ реализованы в линуксе, то есть сетевые устройства, работающие с потоками данных — роутеры, VOIP, и так далее. Стиралка к таковым не относится.
Вот чайнику, с таким подходом, нужно ли это?
Заметьте, линукс в телевизорах появился ровно тогда, когда стало популярным смотреть видео через интернет и с сетевых дисков (на которые качают торренты). До этого момента оно там нафиг нужно не было и его там-таки не было.
Когда стало нужно — оказалось, что свое все то же самое делать геморройнее в плане R&D, чем поставить готовый линукс и дописать туда интерфейс — ну, взяли и поставили.
Со сторалками — не проще. Не основная это их функция и даже не в первой десятке.
> В качестве примеров Вы почему-то всегда приводите те устройства, подавляющее большинство функций которых УЖЕ реализованы в линуксе, то есть сетевые устройства, работающие с потоками данных — роутеры, VOIP, и так далее.
Уже реализованы, а когда-то не было. Тот же SIP-стэк в железе, помнится, кто-то пытался делать. Но быстро плюнули. Кодеки, правда, делают еще, но тож на софтовые решения переходят по очевидным причинам.
Это ситуация, к которой _пришли_, а не которая была всегда с начала времён.
> Стиральная машина, которая, мать ее, ЗАГРУЖАЕТСЯ??? Проверяет диски, если ее вырубить из сети? У которой дохнет флеш? Которую надо обновлять? Подключать ее в домашнюю сеть, чтобы поглядеть достирала ли она? Потом еще Касперского для стиралки скачивать? Да ну нахер! Это из разряда „фонарик с ethernet, который через веб-интерфейс показывает уровень зарядки батареек“.
Роутер, который, мать его, ЗАГРУЖАЕТСЯ??? Проверяет диски, если его вырубить из сети (там, вообще-то, ro на /usr, а /tmp и /var в памяти монтируются, но ладно, пусть). Который надо обновлять? Подключать в домашнуюю сеть что б настроить? Касперского качать — да, бывает иногда, роутеры криворуких компаний ломают удалённо. Ну, tradeoff, как есть.
Вы пробовали роутером торренты качать, в качестве сетевого диска его использовать, фильмы оттуда смотреть, в качестве принт-сервера? Я пробовал, скажу честно — говно во всех категориях, кроме собственно роутинга.
Если оно залипать будет на простейших функциях, то-таки да, оно сможет мне через SNMP раз в десять секунд честно сообщать, что не успевает контролировать энкодер :)
Вот тут и кроется ваша ошибка: алгоритм работы стиральной машины встраивается в универсальный контроллер. И всё. Зачем там распбери с линуксом?
Итак ваше решение:
1. От контроллера вы не отказываетесь, собственно вы и не сможете от него отказаться. Вы просто покупаете готовый модуль (ок, универсальный контроллер), который будет стоить достаточно много денег, так как его не используют фирмы с серийным производством, а только хоббисты.
2. Вместо того, чтоб на этом контроллере закончить, вы ствите ещё один, который выполняет элементарный алгоритм в три строки. Опять же, тут следует ещё наладить самостоятельное производство распбери, потому-что количество производящихся машинок гораздо выше количества выпускаемых распбери.
3. Сколько вы планируете потратить на вычислительную логику? По моим прикидкам, это вам обойдётся от 40 до 60 долларов.
Стоит учесть, что себестимость машинки должна быть ниже 100 долларов, иначе она просто будет неконкурентноспособной. Самыми дорогими комплектующими являются корпуса, барабаны, клапаны, моторы и прочая фигня (долларов на 85 наберётся).
Моё решение:
Разрабатывается одна (!) плата для управления всем этим на процессоре Cortex-M3. Камешек обойдётся доллара в 2-3, изготовление печатки под него с элементами — ещё 7-10.
Камень, как и любой другой современный контроллер обладает аппаратной поддержкой езернета, экран с тач-скрином управляется нашару (если лень писать самому — полно библиотек, хотя что это за фирма, где инженер не может сделать управление тач-скрином), либ для поднятия SNMP — полно.
Итак, вы продавец — консультант. Перед вами стоит покупатель, за вами 2 стиральных машинки. Выглядят одинаково, функции идентичные. Вообще, ни одного отличия. Теперь обьясните покупателю, какая ему разница, есть ли внутри линукс и распбери и почему он должен заплатить за это ещё 50 долларов (в лучшем случае).
> 1. От контроллера вы не отказываетесь, собственно вы и не сможете от него отказаться. Вы просто покупаете готовый модуль (ок, универсальный контроллер), который будет стоить достаточно много денег, так как его не используют фирмы с серийным производством, а только хоббисты.
> 2. Вместо того, чтоб на этом контроллере закончить, вы ствите ещё один, который выполняет элементарный алгоритм в три строки. Опять же, тут следует ещё наладить самостоятельное производство распбери, потому-что количество производящихся машинок гораздо выше количества выпускаемых распбери.
Взаимоисключащие пункты. То ли у нас мелкосерийное производство и используем хобби-комплекты, то массовое производство и хобби-комплектов надо много и хоббисты не справятся с поставками.
Я, к сожалению, не могу оперировать конкретными названиями и использую «распберри» просто как пример полноценного компьютера в компактном форм-факторе с открытой схемой разработки (загрузчик можно менять, софт можно заливать, drm/tivo нету).
Соответственно, если фирме надо массовое производство — они закажут большую партию. Опять-таки, специализированный контроллер не нужен, подозреваю. Нужна просто прошивка под один из имеющихся контроллеров общего назначения.
Зачем нужен отдельно контроллер, отдельно полноценный комп — я описывал в соседней ветке. Контроллер реализует низкоуровневые операции вида «включить барабан», «держать температуру N градусов», «выяснить состав порошка».
Контроллер может меняться от машины к машине (вдруг где два барабана или набор датчиков совсем другой) — но маловероятно.
Дальше — полноценный комп. Нужен банально для того, что б кардинально удешивить разработку софта, который нужен все-равно.
> хотя что это за фирма, где инженер не может сделать управление тач-скрином)
Вот так и появляются отвратительные интерфейсы. Свежий пример стоит у меня через стенку — некий МФУ от самсунга. Редкостное говно, как в работе, так и в интерфейсе. А могли сделать просто веб-интерфейс, открыть прошивку, дать доступ и забыть. А сделали по другому — отвратительный глючный тормозной кривой интерфейс, закрытая прошивка, отсутствие доступа и на всех забили. Ни поддержки, ни обновлений прошивки с фиксами уже имеющихся глюков. К слову о сервисе, да.
А потом мне с ними работать. Тут не реализовали одно, тут другое, тут это не работает, а работает другое, а тут просто сделали свой MIB, ни с чем, кроме родного софта не совместимый вообще впринципе. А могли юзать одну стандарную, проверенный годами, открытую библиотеку. Не для МК, правда, вот в чем затык. А от полноценного компа мы отказались, потому что у нас герой-инженер, тратящий время на повторение очередного велосипеда, вместо того что б использовать готовые компоненты…
1 и 2 это не взаимоисключающие пункты. А прямоследующие. Если без 1 не обойтись, более того возможности позволяют и все можно сделать на 1, то зачем там 2? Ради пары сомнительных штук которые нужные единицам и то исключительно для лузлов?
Нет, у нас крупносерийное производство и мы используем хобби-комплекты. Их уже изобрели — мы же не герои писать всё это заново.
Выскокуровневую операцию — включить барабан — лучше реализовывать на стороне сервера, желательно в облаке — она требует выскокой вычислительной мощности.
Разработка софта стоит значительно дороже системы — особенно в крупносерийном производстве — стоимость железа, ведь, делится на все машины, а, вот, софт пишется для каждой машины отдельно и его стоимость напрямую добавляется к её себестоимости.
Хотя, насчёт цены мы лучше не будем вообще говорить, пользователи, ведь, знают — чем дороже, тем лучше.
Любой инженер становится дизайнером, если ему дать библиотеки с открытым исходным кодом.
И да, чуть не забыл, я не хочу с вами спорить и тролить кого-бы то ни было.
эзернет на МК Вообще не проблема. В цикле статей от lifelover это было подробно обсосано и ради лулзов поднят даже сервачок на 8мибиитке с 32кб ОЗУ, где мы толпой радостно чатились. Как не проблема и тачскрин и большой экран.
Просто надо ли оно? У стиральной машины, в идеале вообще не должно быть интерфейса. Положил белье, закрыл, достал чистое.
Читайте ветку с начала. Я ничего не хочу, я пытаюсь понять, почему в одной индустрии это — промышленный стандарт, а в соседней — пальцем у виска крутят при намёках.
По той же причине, по которой Вы сами не можете обновить софт в контроллере двигателя своего автомобиля. Потому что оно не нужно 99.999% пользователей.
Вот в машинах, на сколько я знаю, уже давно не микроконтроллеры стоят. Последний, что видел, Motorola 68K. Это полноценный проц, хоть и древний, ни разу не микроконтроллер. Микроконтроллеры могут быть на входах-выходах, для низкоуровневого управления, но высокоуровневый контроль — вполне себе обычный проц.
И на счет 5 девяток вы погорячились. Сервисы, производящие настройку (фактически, перепрошивку) софта для контроллеров двигателей — хватает.
Сервисы, производящие апгрейд софта стиралок, тоже есть.
Другое дело, что если они отвечают за работу машины — они туда никого не пускают, и это нормально.
Да, это не отвечает требованиям гиков. Зато это отвечает требованиям домохозяек, которым нужна Одна Большая Кнопка «сделать хорошо».
Ага, а потом местный хакер Вася найдет эксплоит в стиральной машине Бабы Нюры, живущей над Леной, которая его в прошлом году бросила, и устроит ей массовый потоп.
Ну и SNMP придется к нему писать самому или брать готовую либу для МК — открытую полноценную реализацию сюда, видимо, не запихнуть. Соответственно, имеем риск >0 в несовместимости с рядом других реализаций.
Ну во первых это размер. Типичная конфигурация системы для запуска линукса это контроллер, озу и внешняя флеш память. Это 3 чипа, причем контроллер с ОЗУ нужно еще правильно развести, чтобы эта связка надежно работала. Чипы эти не самого маленького размера, даже если взять BGA корпуса.
Если задача полностью помещается в микроконтроллер в корпусе 5х5 мм, то зачем городить систему, где большая часть потраченных ресурсов уйдет просто на загрузку и исполнение самого линукса?
Ну а как примеры задач такого рода:
— фронт енд разного рода датчиков, передающий замеренную величину по какой либо шине головному устройству. Использую микроконтроллер, можно интегрировать его прямо в датчик и на ружу вывести только требуемую шину. При этом размер и потребление этого датчика особо не увеличатся.
— контроллеры исполнительных устройств, которые могут опять же находиться на расстоянии от управляющего блока и быть связаны с ним посредством какой-нибудь шины.
И еще есть момент с безопастностью. Если взять современный автомобиль, то система с ОС типа линукса ставится только в головное устройство, которое работает с мультимедиа и от которого не зависит функциональность самого автомобиля. На это есть причины.
У нас в устройстве (лазерный 3D-сканер) микроконтроллеров разбросано не меньше десятка по разным углам — они управляют моторами, лазером, заслонками, синтезаторами… управлять всем этим с одного процессора (в реальном времени) было бы сложнее. А ставить вместо микроконтроллеров полноценные процессоры — вообще безумие.
По-моему, для управления этой мелочью стоит 8051, а основной поток данных обрабатывается с помощью двух XILINX (один — для счета, другой — для формирования потока). Потом все это дело отправляется на USB, но к кому конкретно он подключен (к 8051 или к связному XILINX) уже не скажу.
Но я конкретной схемы в деталях не знаю.
Полноценный процессор ставить думаем, но сначала надо облегчить вычислительную нагрузку на него (первичный анализ потока) — слишком мощный будет тратить много энергии, а у нас каждый ватт на счету. А слабый (1 ГГц, например) не успеет привести поток к виду, пригодному для записи в файл.
Вот роутер с пачку сигарет, на linux, потому-что так проще, взять устаревший мультимедийный чип от android-смартфона (с графическим ускорителем, GPS и прочей ненужной лабудой) воткнуть на него linux побыстренькому, закрыть естественно все что только можно, и продукт на рынке!
Да, только каждый раз при включении, подождите минутку, пока linux загрузится, а еще не забывайте заряжать почаще, linux любит кушать…
Про torrent или ftp (32Гб макс, на скорости 1 Мб/с), или медиастриммер который даже иногда не лагает на фильмах с низким битрейтом, я не буду рассказывать…
Да, sshd там нет, но есть telnetd из busybox, но чтоб он заработал надо перепрошить веб-морду…
Какой профит от linux? он еле шевелится, жрет батарею и тупит.
Я бы предпочел чтобы прибор включался за 5 сек и жил сутки от аккума! Мобильный девайс как ни как!
> Я бы предпочел чтобы прибор включался за 5 сек и жил сутки от аккума! Мобильный девайс как ни как!
Всегда будет tradeoff, никуда не дется. Или надежно и долго от батареи и дорого, или просто быстро на коленке и дешево. Микроконтроллеры, конечно, на копейку дешевле, но разработка под них (читай исходный топик) выходит, по-моему, гораздо дороже. То что «софт пишется один раз» — не довод. Ни одна фирма не делает только один тип железок — хорошо если это только 1 железка в год, чаще — с полдесятка. И сидят и пишут, и пишут, и пишут. Одно и то же, только чип каждый раз немножко другой. Чем это дешевле готового софта и готовых компонент — не понимаю.
linux используют там, где нужно побыстрому прикрутить кучу железа, wifi, usb, файловые системы… т.к. в нем много дров практически под все. Или же использовать стек сетевых протоколов, с гибкой маршрутизацией…
Сам по себе linux ничего не сможет в железке делать, разве что top через COM-port выводить ))
Для работы с железом ему нужны дрова, а программирование дров задача сложнее написания кода под МК, шаг влево, шаг вправо — кернел паник и core dump. Написание таких дров, реализация некоей логики в них, превышает сложность написания той же логики для MK на Си в IAR, причем намного! Получается что мы сделали ту же или больше работы, но в добавок у нас где то сбоку еще и linux висит. Возникает вопрос, зачем он нужен? для того чтоб ssh было у 0.1% пользователей которые знают что это означает?
Даже если вы используете стандартные шины, и в linux под ваш чип, в ядре уже есть модули (что далеко не факт) поддержки вашей конкретной перефирии вашего чипа, вам все равно придется описывать обмен данными через шину своими драйверами, если вы конечно делаете что то отличное от сферического девайса с одним COM-портом для отладки наружу
А цена? У нас при автоматизации на один объект ставится как минимум 10 модулей (по сути — датчиков) на PIC (это ОЧЕНЬ маленькая станция, обычно 40-50), с очень простой логикой работы — 50 раз в секунду обрабатывать и отдавать дальше данные. Зачем в таком модуле полноценный процессор с линуксом?
Недавно выбирал себе программатор под AVR32.
Сперва тоже хотел купить Дракона, но немного прочесав ибей, заказал себе вот такую штучку :)))
AVR JTAGICE2 ebay.com/itm/320693050740?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649#ht_3039wt_952
Дешево, но очень сердито.
Чипы моей бывшей компании не идельны конечно, но всё же я себе даже представить такого не могу чтобы такие дефекты ушли в production. Попробуйте Cypress Semiconductor в зависимости от сложности задач есть PSoC1(провереный веременем микроконтролер на M8C, но не очень производительный) или более производительные PSoC3(i8051) PSoC5(ARM Cortex M3). IDE конечно по сравнению с студией не фонтан, но одни из лучших среди IDE для микроконтролеров. Да и отладчики, конечно не по 20$ но и не 600$ www.cypress.com/?id=1353
Мы рассматривали PSoC как альтернативу (более того, по желаемости нами он был вообще на первом месте!), но подходящий по требованиям проц задерживался на полгода с датой выпуска, к сожалению.
По поводу конфигураций запуска («Run->Run Configurations»). Если среда Eclipse-based, то в настройках конфигурации запуска, на закладке Common, обычно есть вариант типа «Save As->Shared File». Если его выбрать, то конфигурация сохранится в один из проектов и при импорте проекта автоматически появится в меню.
С AVRStudio32 не работал, так что информация не точная.
Меня вообще удивил заголовок: кроме AVR у Atmel есть хорошие контроллеры (я работал с SAM3U и он мне очень понравился). Так что, правильнее будет сказать "[..]не рекомендовал AVR[..]"
Что же касается AVR, и, в часности 8-битных контроллеров, то с ними лучше всего работать, используя простой USBasp. Может это субьективное мнение, но отладку на мегах я ни разу не видел вменяемую.
В качестве среды разработки — лучше использовать Eclipse в связке с AVR-GCC — удобный менеджер проекта и редактор при полном отсутсвии тормозов с лёгкостью компенсирует симулятор AVRStudio, настройщик периферии c предирективами компилятора ICC и пафосность IAR.
Когда прочел то сложилось мнение что вы совсем не делали анализ того что есть на рынке и как это реализовать. Ваши крутые JTAG отладчики давно можно собрать на коленке за пару минут и за пару копеек. Лично я AVRStudio никогда не понимал и в основную всегда использую CodeVisionAVR если вас смущает данный софт, то используйте IAR что в первом случае что во втором проблем с дебагом и брейк поинтами никогда небыло. Почитайте внимательнее что пишут люди на форумах, а уж потом обсырайте оскорбляйте Atmel. Тем более на Atmel чипах сделано очень много полезных устройств и не нужно акцентировать свое внимание только на Arduino
Анализ мы как раз делали, и предлагали другие микроконтроллеры, а конкретно Atmel и AVR One! в качестве отладчика выбрал заказчик. И как уже писал — если для того, чтобы начать работать, нужно прочитать кучу неофициальных форумов, то это как раз и показывает то, что с данной системой что-то не в порядке. До этого с другими контроллерами все было гораздо более предсказуемо и стабильно. Тот факт, что «сделано много полезных устройств» ничего не показывает — мы в итоге тоже сделали наше полезное устройство на AVR, но описанные выше проблемы от этого никуда не делись.
Если у вас такие грабли с AVR, то что будет когда вы будете использовать более мощный и навороченный контроллер? Там граблей пропорционально частоте и количеству разрядов.
На самом деле с такой петрушкой сталкиваются все начинающие, и негодовать по этому поводу глупо. Если курсачь не получается писать в институте, то виноват в этом как правило не препод ;)
Выше уже отписывался, что а) приходилось использовать контроллеры помощнее и б) такого количества и качества граблей обнаружено не было. Так что если грабли обнаруживаются, то виноват в этом, как правило, не тот, кто их обнаруживает :)
С AVR ещё со школьной скамьи, когда этих граблей было много даже железных (это больше чем десять лет назад). Никакой нормальной документации и примеров, кроме даташит не было. О внутрисхемных отладчиках даже и не мечтали.
И честное слово, ни разу не сталкивался с такими граблями. Ни с одним из перечисленных выше. Даже с теме жи фьюз битами, в домашних условиях, имея программатор аля 4 провода на LPT-порт, вытаскивал контроллер с того света тупо внешне тактируя его от пальца! Наводки. Медленно, но поправить фьюзы хватает.
Ди верно сказал, вы талантливо собрали все баги.
Могу припомнить в действительности мощный баг, когда писал на ассемблере, затем декомпилировал написанное и в одном месте стояли другие операнды, нежели в моей программе. Но после обновления студии прошло.
По поводу пятой студии, увы таки да, она УГ. Пользуюсь четвёртой.
Меня больше интересует, как ребята, которым надо покупать средства отладки (т.е. своих нет) и узнавать на тему STK (то есть до этого не знали), другими словами, с процессорами незнакомые, а также неспособные сделать простенькую платку «на коленке», предложили ATMEL как одно из решений заказчику.
У меня был как-то случай, когда человек попросил юзать STM8, я тогда только начинал с ним работать, получил вполне оправданный отказ, то есть либо к другому разработчику, либо на atmega8. Да, дороже, но на этом я точно знаю, что сделаю.
А как бы вы отвечали заказчику в ответ на требование провести анализ рынка и выдать варианты, соответствующие указанным требованиям?
Или вы почему-то решили, что мы не стали сообщать заказчику, что с такой-то и такой-то платформой у нас уже есть опыт работы и платформа себя показала весьма хорошо, поэтому в нашем списке предпочтений именно эта платформа на первом месте, а с такой и такой платформой мы раньше дела не имели, поэтому в случае выбора ее на проекте появляется дополнительный риск неизведанной платформы?
Так если заказчику об этом было сразу сказано, и он все равно выбрал то, что выбрал — то почему нет? Ну и «не дать заказчику выбрать платформу» тоже сильно звучит, т.к. кто платит — тот и решает, кому какие полномочия давать, нет? К сожалению, даже когда видишь, что заказчик делает полную фигню, все, что можешь — это ему корректно про это сообщить, и предложить альтернативу. Согласится — хорошо, нет — придется, матерясь, делать так, как он хочет, увы :(
Основной альтернативой были STM32F207ZG и MK60FN1M0VLQ12, требования не буду разглашать…
Целая статья о том какие у вас руки кривые)) Ни слова не нашел про недостатки самих контроллеров. Одни лучи поноса в сторону средств разработки и отладки. Авр студио 4 вполне себе ничего, а использовать САМУЮ НОВУЮ студию — очень странно для программистов. Что вы не понимаете, чтоли, что компании стараются выпускать поскорее сырые программные продукты, чтобы бабла срубить — тот же альтиум чего стоит, используйте стабильную версию и всё, отладчиков для атмелов тоже хватает нормальных. Короче «Нечего на зеркало пенять, коли рожа крива»
Хорошая у вас логика, ничего не скажешь — из того, что «компании стараются выпускать поскорее сырые программные продукты», вы почему-то делаете вывод, что кривые руки у нас. И наверное, именно из-за наших кривых рук у дебаггеров отваливались коннекторы и разъемы питания, сами дебаггеры иногда просто сгорали, а у контроллеров вдруг стирались read-only CPU ID и данные калибрации тактового генератора (из-за чего тактовая частота с 8 МГц вырастала до 16, а дебаггеры тупо переставали видеть контроллер).
Почему бы я не рекомендовал Atmel или о непонимании успеха Arduino