Как стать автором
Обновить

Комментарии 261

НЛО прилетело и опубликовало эту надпись здесь
А какую альтернативу вы предложите?
НЛО прилетело и опубликовало эту надпись здесь
А я вот в своё время намучался с 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. Собственно, и написал все это потому, что было с чем сравнивать. Понятно, что идеала не существует и баги есть везде, но не таких же и не столько же!
arm: lpc, stm32;
из 8 битников: stm8;
или вообще msp430
stm32 тоже «веселья» хватает.
В принципе в любом контроллере есть ошибки и всегда возникают ситуации, когда приходиться дико колдовать над кодом и вчитываться в даташиты.
Возможно автору так неповезло, что он собрал все возможные грабли.Я в своё время очень намучался с PIC, в частности с обеспечение стабильной работы USB(эмуляция com-порта через USB), радость моя была неописуема когда я вернулся к своему AVR.Теперь не в жизнь не захочу по своей воле работать с PIC исключительно из-за плохих воспоминаний.
НЛО прилетело и опубликовало эту надпись здесь
stm32 тоже «веселья» хватает.
Конкретней, пожалуйста.
Поддерживаю. У нас на предприятии как раз используются 32-битные LPC и 8-битные STM8. STM32 щупали, но по какой-то причине решили не применять. С STM8 тоже случаются иногда непонятные глюки, но очень редко.
На любительском уровне работаю с атмелами (16й и 8й) и ардуино, вышеобозначенных проблем не имел.

А что дебаггеры некачественно собраны — это прескорбно.
НЛО прилетело и опубликовало эту надпись здесь
> Можно было, например, переключить его с использования внутренней тактовой частоты на внешнюю.
Меня кстати иногда в этих случаях спасает волшебный палец

Вообще кажется Atmel болт положила на создание нормальной IDE, лично мне пока приходится юзать VMLAB для 8-ми биток, вроде все бы ничего, но практически нулевая подсветка синтаксиса
Вы похоже собрали все косяки начинающих на AVR какие только можно. Даже ряд сами раскопали. Может дело не в бобине, а в плохом танцоре?

человек собрал все имеющиеся баги? он отличный тестер! Не знаю насчет танцора.
А это мысль. Надо будет контактики записать, вдруг пригодятся аппаратные тестеры :)
Да-да, есть у меня такое, не раз замечал :)
Ну и, вдобавок, напоролись на кривую, косую и глючную 5ю студию. Вам еще повезло, что она вообще увидела ваш отладчик. Реально работать можно только на 4й студии.
Что значит «напоролись»? То, что именно эта кривая, косая и глючная студия была на тот момент официально рекомендуемой Атмелом средой разработки, надо было просто не брать во внимание? Но не это ли как раз говорит об уровне системы?
Это говорит лишь о том, что где то в менеджменте атмела завелись придурки. Которые ЭТО выкинули в продакшн, выдав за основное решение. Скажите спасибо, что было хоть это. Другие производители часто и такого не дают. Предлагают сразу мол покупайте Keil, IAR или колхозьте сами на эклипсе из левых тулчейнов.

Вопрос про прогуляться вышли, что ниже, актуален. Да. Словно в первый раз, в самом деле.
зачем нужны кривые студии «от производителя» если есть универсальные качественные решения от тех, кто занимается разработкой именно софта…
я вот не понимаю. ну делает атмел кристаллы, хорошо делает (не без косяков, но не хуже других а во многом лучше), пусть делает.
в софт-то зачем лезть? :D
А вы никогда не пробовали убедить заказчика раскошелиться еще и на коммерческий тул, если на сайте производителя выложен бесплатный и к тому же рекомендованный? Особенно если решение об этом принимается тем, кто код не пишет и не писал?
Нет, не пробовал. Я пользуюсь бесплатными утилитами но нифига не от производителя.
Рекомендую попробывать Eclipse AVR Plugin для 8-битных контроллеров (насчет 32-битных не знаю).
Попробовал пятёрку, поплевался поставил четвёрку.
Вышедшая совсем недавно 6 вроде выглядит постабильнее
Дело не в стабильности даже, а в поддержке собственных же инструментов. Например в 5 и выше студии забили на старые модели отладчиков и программаторов.
НЛО прилетело и опубликовало эту надпись здесь
Тут ситуация такая, что обычно компания хорошо делает камни, а вот софт и родные отладочные средства делают аутсорсные китайцы и делают это на от… сь И это скорей правило, чем исключение.

Так что выбираем камень, потом, если нужно, ищем подходящую отладочную плату (не обязательно от производителя, скорей всего у него УГ) и подходящий софт.
Вы знаете у них своих американских «китайцев» хватает. В хорошо известной мне компании во время кризиса в Штатах сокращали целыми офисами. После кризиса, вместо хороших програмистов, инженеров электронщиков, набрали толпу людей с медицинской индустрии с опытом Visual Basic.
А насчёт софт, компании привязывают релизы и всю разработку к цыклу выпуска новых чипов. И если планировать чип достаточно просто, условно 3 месяца топология, 3 отладка, потом 3 для подготовки производства, то с софтом так не выходит, но никого не волнует им выкатывай функционал одновременно.

Про плохого танцора подписываюсь. Впрочем, Ди, вспомни как мы начинали
Вачдог!
А с непониманием успеха все просто.

Ардуино не использует

Родную среду
Родной компилятор
Родной отладчик.

А именно с ними у вас были косяки.
Ребята, а вы вообще embedded разработкой занимаетесь, или прогуляться вышли?!
Когда разрабатывается девайс — исходя из ТЗ подбирается процессор опираясь на требуемую накристальную периферию, объём ОЗУ процессора и его флешки, и ядро, если это важно (например, мы как правило берём только 51е, так как большой объём наработок под него у нас).
На процессор берётся даташит, и изучаются моменты, относящиеся к особенностям задачи.
Рисуется схема, разводится, спаивается один экземпляр, под него пишется программа.
Если програмно оказывается удачно поменять немного разводку — в штучном правится перемычками и правится разводка.
Когда ясно что разводка больше не поплывёт — заказывается изготовление плат, тем временем доделывается программа.
Занимаемся-занимаемся. В данном случае нами предлагалось 5 различных процессоров, именно исходя из требований периферии, производительности и т.п. Заказчик выбрал то, что выбрал, убедить его сделать другой выбор у нас не получилось — что ж, кто платит деньги, тот и принимает решения (и несет ответственность). А сроки не позволяли сделать вторую итерацию на другом проце — увы, так тоже бывает, когда все упирается в требование выйти на рынок не позже какой-то даты, т.к. если этого не сделать, то можно вообще ничего не разрабатывать.

Но это уже совсем другая тема…
Вопрос почему вы пытались какие-то макетные платы, которые явно не про ваш случай, вместо разводки под процессор «какой сказали»?

Зачем нужна отладочная плата вообще?
Ну… как бы хорошо перед началом столь серьезного шага, как разработка и заказ плат, все же провести хоть какие-то тесты, нет? Для этого и нужны eval платы.
Ей-богу, как в первый раз. Вот какие платы для этого нужны:
И вы на такую плату сможете установить 32-битный AVR?
О, а за это спасибо!
ДА, именно так я и запускал свой первый ARM

Еще раз снимаю шляпу!
макетка с панелькой реюзабельна :)
Ну да, только стоит дорого и фиг достанешь.
ну простые-то панельки валяются на всех углах. хотя под bga конечно не лежат.
а я до сих пор беру такие макетки и собираю на них)
А что, вот на ЭТОМ собрать навесным монтажом быстрее, чем изготовить тем же ЛУТом (хотя, с сегодняшней доступностью химии, можно и фоторезистом) аккуратный тестовый образец?
Если учесть время потраченное на разводку платы, то да, быстрей.
Прибавить время на разводку и вычесть время на ковыряние тестером в соплях припоя и ногах кондеев. Особенно весело, если таки есть JTAG и какой-нибудь I2C.
Особенно весело когда еще не знаешь, что конкретно надо развести и что должно получиться.
Нее, все же развести быстрее.

1. Сначала все делаем в виртуальном мире — схему, растановку элементов (что сильно проще на экране, чем на макетке — ну, или это будет Горгона из МГТФ :)), и разводку.
2. Корректность разводки определяется атоматически, экономим время на проверку и/или исправления
3. Некоторые вещи на макетке раобтают сильно не так, как в жизни (ОУ с большим усилением, импульсные схемы, ВЧ, и так далее). На макетке сложнее добиться чистоты (отсутствия флюса).

Это только то, что сразу в голову пришло.
Разумеется, это все применимо только, если речь идет не об «пищалка на 555-м таймере».

Мне в последнее время (учитывая наличие правильной бумаги, принтера, ламинатораи бурбулятора с ХЗ) развести простенбкую платку и вытравить ее занимает от часа до трех.
И экономит безумное количество времени впоследствии…
Всем известно, что AVR дебажатся светодиодом и выводом в консоль, если доступен УАРТ. И программятся программатором из 5 проводков-на-лпт, тот же Дракон используют исключительно в режиме программатора. Зачем на МК с 16к Флеша смотреть стек вызовов? Видно автор знаком с программированием других МК в которых без дебаггера ничего не сделаешь и к AVR подошел с той же стороны, но тут свои нюансы.
Вот и я о том — да и на STM тоже неясно зачем долбаггер — если есть экран и уарт?
Чтобы просто, быстро и без плясок со светодиодами ответить на вопросы:
1. Сработало ли прерывание таймера? (поставить там брекпоинт одним кликом мышкой, а не писать туда «Светодиод, зажгись» и изничтожать это в других местах)
2. А почему оно не сработало второй раз или не сработало и в первый? (запихать все регистры таймера в live watch и сразу же посмотреть, какие регистры чему равны)
3. Правильно ли посчиталась контрольная сумма? а на N-ном шаге? А какие были еще три переменные рядом? А адрес последнего посчитанного байта? (просто навести мышкой на нужные переменные после брекпоинта)
4. Завис ли контроллер и в каком месте? (ткнуть в break и увидеть, что он где-то посередине нигде лопатит непрошитую область)

Я уже не говорю о таких штуках, как RTOS, стеки и прочее подобное.
Я недавно портил ChibiOS на STM8S, если бы не дебагер, я бы там сдох на месте. Никакими светодиодами и юартами это не отладить.
Стек вызовов надо было смотреть на UC3A3 — там полноценная RTOS c весьма немаленьким приложением крутится, и флеша там 256к кстати.

На ATMega вообще в результате дебаггер не используется, отчасти из-за перечисленных проблем — image заливается в него через SPI c UC3A3. И не сказать, что это сильно упрощает разработку — порой возможность пошаговой отладки бы сильно ускорила процесс.
А пошаговая отладка делается в симуляторе, но там тоже свои гайки на которые новички обычно жалуются, типа watchdog не сбрасывается командой (для фикса надо просто его отключить), или прерывания от периферии не приходят (а им надо просто в ручную флаг установить) и т.п. Лично я в симуляторе только бизнес логику отлаживал, а периферию руками эмулировал, если было сильно надо. А в железе, светодиод наше всё.
Это я про АтМега.
С UC3 не работал, но РТОС, может иметь свои средства отладки, тот же вывод на УАРТ.
Это просто подход к отладке: кто-то умеет читать код, а кому-то надо отладчик.
Я уже давно не пользуюсь отладчиком вообще, хватает отладочного вывода/светодиода.
Это еще ладно, я видел когда люди отказывались от проца, т.к. его протеус не эмулирует. Вот это ппц.
И при каких масштабах разработки вам хватает светодиода и принтфов в консоль?
DN OSP
Веб-проекты
Весьма нагруженная телефония (erlang)
Весьма нагруженные распределённые приложения (erlang)
Контроллеры измерения и управления (на 8051 embedded) — регуляторы температуры, расхода газа, ПЛК, хроматографы, и т.п. дребедень.
Снимаю шляпу!

Но по-прежнему считаю, что в очень многих ситуациях самый простой и быстрый способ отладки — это таки пошаговая отладка с заглядыванием в регистры проца, переменные и т.п. Можно, конечно, обойтись и без этого — вопрос только зачем?
Простые ошибки на то и просты, что дебаггер там просто не нужен.
Сложные ошибки на то и сложны, что требуют совпадения фазы луны с напряжением в сети — тут отладчиком ловить крайне сложно.

А узкий пласт ошибок, когда знаем где, решается с помощью «дурака» — берёшь любого, садишь рядом, и начинаешь рассказывать что ты тут делаешь. Через 5 минут говоришь «вот я дурак», отпускаешь человека, правишь баг.
Проблема дебагера в том, что он наглухо ломает реалтайм. Ну ходите вы пошагово — это можно и в симуляторе проверить, а периферия то не будет вас ждать.
… или наоборот — периферия как раз тогда хорошо дождётся…
На кортексах несколько раз на это ловился: с дебаггером всё работает, без дебаггера — хоть набей на бубне шишку — не запускается.
Дебаггер — не панацея ни разу, согласен. Но все же лучше, когда он есть. А осциллограф с паяльником все равно применять придется…
любой масштаб софта требует наличие грамотного логгинга. При наличии грамотного логгинга дебагер не нужен — в «подозрительном месте» добавляется еще одно log(DEBUG, ...) или как там у вас.
Мы тоже jtag не используем, светодиод и консоль достаточно всегда.
Jtag удобен, когда камень новый, плата первая и не стартует. Вот тут он помогает понять, что там вообще происходит и куда капать.
А когда проц запускается то, как ниже написали, грамотный логгинг решает все проблемы. Процессоры используем ARM. Системы с RTOS и без.
Абсолютно верно, сколько работал с ATMega ни разу не было необходимости в JTAG'е. С ARM и разными RTOS — аналогично. В случае проблем, прикидываешься процессором и сам в голове находишь проблемное место. Логгирование сильно помогает в этом.
Кстати да, JTAG там весьма торомозной и убогий. Что первый ICE, что второй, что dW. Да и не нужен он по большему счету, что там на 16кб то отлаживать?
Ответил выше — отлаживать надо было не на 8-битном, а на 32-битном, там 256к флеша (почти полностью занятых в результате), RTOS и т.п.
НЛО прилетело и опубликовало эту надпись здесь
Лежит у меня пара железячек в работе, внутри что-то вроде линукса, на одной железяке снаружи для отладки светодиод, на второй буззер (и тачскрин с графическим интерфейсом, но это непринципиально). Программируются скриптом паскалеподобным. Подключить дебаггер/отладить с мониторингом через комп — невозможно. Есть эмулятор на компе. Поведение почти :) похоже на железное. Пошаговой отладки нет. Скрипт на компе работает идеально, на железяке или команды не отправляет по сети или вообще уходит в перезагрузку (перезагружается не сама ось, а только скриптоисполнялка). Светодиод/буззер в данном случае помогают только факт перезагрузки установить, для прочей отладки толку от них нет. Я понимаю, что светодиодом можно логику отлаживать (попал в ветвление или нет, пришла команда снаружи или нет), но для этого и на тачскрин можно выводить значения переменных, а для установления причины глюков такой фокус не поможет.
Тогда надо подключать тяжелую артиллерию — редуцировать код пока сохраняется баг.
А там еще и осцилограф.

Помню весёлый эффект об отладке аппаратной. Еще 8080, код прекрасно работает на макетной плате, в реальном устройстве глючит. Втыкается плата пошаговой отладки, гоняется — всё прекрасно, сбоев нет. Запускается — сбоит.

В общем, нашли — микросхема памяти попалась бракованная, просто не успевала отрабатывать.
Ну то, что сложные баги в embedded без осциллографа фиг найдешь — факт!
Рад бы, но железяка по сути своей закрытая, все что программисту-наладчику предоставлено — комп, скрипты и светодиод. До внутренностей системы (логфайл там почитать например) не добраться. Стоит относительно большых бабок, так что с отверткой туда не пускают. Да и чипы в ней заказные, так что и с осциллографа толку мало. Вот и лежыт уже пол года в лабораторных условиях и мигает светодиодом :)
А, вас в нутро не пускают… Нас пломбы не останавливают, так как мы и обслуживаем почти всё оборудование, в том числе импортное — это дешевле и эффективнее.
Ну так закрытая система, без бешеного реверсинжиниринга толку не будет, а платить за это никто не собирается.
Да и вообще «политика партии» такая, что если устройство отказало — списать и заменить новым. Ремонтировать никто не будет, зато можно кинуть его в ящик стола, а потом препарировать ради интереса.
В начале мы говорили про отладку светодиодом AVR. Понятно, что чем сложнее система тем труднее ее отлаживать. Хотя в Линуксе JTAG отладчиком тоже делать нечего. Там много своих средств отладки типа strace и gdb, ну и вывод в консоль (о котором я упоминал для AVR) и в лог никто не отменял.
И зачем вам понадобилась схема STK600, что вы там хотели увидеть? Все порты и все пины выведены там на колодки, а большего и не надо. Что куда выведено описано в документации.
Например, затем, что на avr freaks про этот toolkit часто писали, что на нем очень легко убивается блок питания, и без схемы это исправить практически нереально. В общем, показалось черезчур рискованным, и решили, что проще и дешевле обойтись без него.

А вопрос на самом деле не «зачем нам понадобилась», а «зачем Атмелу понадобилось ее прятать», не находите?
LOL похоже БП в их тулзах делает один и тот же человек. В AVR Dragon питальник тоже со свистом от тычка пальцем в конденсатор вылетает.

Вообще там из надежно проверенных только JTAG ICE II. Про него я ничего плохого не слышал, ну кроме того, что дорогой.

А открытых официальных тулзов я вообще ни от кого не видел. Тот же ST-LINK закрытый, Свисток от MSP430 тоже. Так что это частая практика. Только микрочип тут отличился, вбросил на публику свой пиккит 2.
Атмеловский STK500 тоже имел открытую документацию, только нужные нам процы не поддерживал. И отзывы про него были гораздо лучше.
Не имел, а стал. Поначалу тоже был закрытым. Через пару лет и STK600 откроют :)
Господа суровые железячники, а может мне кто-то объяснить, почему вообще кто-то еще использует микроконтроллеры, когда есть нормальные полноценные процессоры, позволяющие без проблем гонять там Linux и использовать практически любой удобный язык программирования, отладчик и среду?

Просто это напоминает спор ассемблерщиков и сишников. Типа ассемблер круто и всё такое, но время разработки на нем (самая большая статья расходов обычно) — в разы, если не десятки раз больше, чем на более высокоуровневных языках.

Не холивара ради, а просвещения для. Действительно не понимаю.
НЛО прилетело и опубликовало эту надпись здесь
1) можно пример задач и примерного времени реакции?
2) если разработка крайне сложна и неудобно, открытых и популярных инструментов (стандартной библиотеки), как таковой нету (если и есть, то она на порядок хуже того же ulibc, например).
и 3 — понятно. Но если задача решается при этом несообразно дороже, то пункты могут перестать играть такую важную роль.

Как бы, не все на атмегах делают бортовые компьютеры космических кораблей… Да и потребление ARMов, на сколько я знаю, не сильно больше этих 8-32-битных контроллеров. По крайней мере, обвязка уж точно и там, и там сравнительно с процессором потреблять должна больше.
Не дописал 2)…

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, потом вроде как и ставить их себе начали. И не думаю, что они сильно страдали от потока писем «почему чужая прошивка мне убила роутер». Они просто не обязаны отвечать на то, что не описано в гарантийном соглашении. Почему линукс внутри что-то поменяет в этом плане?
Потому что это куча лишнего геморроя, вот и все.

Там все равно какая-то ОС внутри живет, но нафига им куча лишних прослоек между железом и логикой?

Основное свойство линукса тут — универсальность — хочешь апач поставь, хочет — питон. А им это все не надо, у них конечное количество тредов и это реально надежнее, тупо за счет меньшего количества кода.

В роутере и вправду проще поставить линукс, потому что основная задача роутера — роутинг — в линуксе УЖЕ сделана. А драйверов стиралок там нет…
> В роутере и вправду проще поставить линукс, потому что основная задача роутера — роутинг — в линуксе УЖЕ сделана. А драйверов стиралок там нет…

N лет назад за предложение пороутить трафик софтом — в приличном обществе бородатых админов могли закидать ссаными тряпками.

Драйверы стиралок появятся в ядре на второй день после решения кого-либо сделать это. Сделать по человечески, я имею ввиду, со спеками, без блобов.
свою стиралку с блэкджеком и линуксом уже сделали до меня. Я просто не понимаю, почему остальные не чешутся, пытаюсь найти разумные доводы. Пока не особо, если честно.
НЛО прилетело и опубликовало эту надпись здесь
Это понятно. Основной (и главный) довод в пользу неоткрытия исходников — стыд разработчиков. Остальное — наведенное и притянутое за уши.
Кроме всего прочего, линукс — это не ОС реального времени, время от времени он может начать себя вести совершенно непредсказуемо.
Ну это совсем мимо кассы. Уж сколько было споров про оси реального времени…

Для 10khz может и не хватит дефолтной убунты. Но есть RT Linux. Ну и не везде нужно 10KHz, где ставят микроконтроллеры.
А линукс уже научились пихать в квадратик 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% применений микроконтроллеров.
Это не меньше 60% процентов применения.
Оглянувшись, я насчитал десяток микроконтроллеров в разных девайсах в квартире, но ни одного батарейного, с суровой спячкой и принципиальной бесприбыльностью установки линукс-совместимого проца.

Но спорить не буду, я не в теме. 60% — так 60%.
>Например, стоит у меня дома стиралка. С каким-то там очередным микропроцессором. А вот хочу я туда залезть. Не с jtag/com/can (тем более что в продакшн-версии, небось, они и не распаяны), а через ssh, крон написать — напоминать постироать и триггер повесить — смс мне отправлять по окончанию стирки.

А производитель хочет, чтобы вы туда залезли?
> А производитель хочет, чтобы вы туда залезли?

А я, простите, не очень хочу его спрашивать, что он хочет, а что нет. Это моё личное право. Стиралка — даже не софт с сомнительными лицензиями (ты не купил, а взял в аренду свой виндовс, поэтому лазить внутрь нельзя). Стиралка моя личная. Хочу — использую как есть, хочу — залажу внутрь. Понятно, что гарантийное соглашение я читал и всё делаю на свой страх и риск.
Ну вам плевать на его мнение, а ему на ваше. Пока ваши идеи в исчезающе малом меньшинстве ничего не изменится.
На исчезающе малом меньшинстве делают миллиарды, к слову.
Тогда у вас есть шанс!
Если это не стиральная машина, а блок управления электропневматическим тормозом локомотива? Тоже пускай каждый внутрь залезает и правит что хочет?
> Тоже пускай каждый внутрь залезает и правит что хочет?

Таки да. Но мы же не машиниста имеем ввиду, правда? А, например, сборочный цех локомотивов, которые закупили тормоза у сомнительного подрядчика, который сделал «для юзеров, без возможности разборки и настройки», и заводу с этим черным ящиком приходится работать — ни настроить, ни модифицировать. Просто потому что у подрядчика были умные маркетологи и юристы, которые за всех решили — что надо заводу, а что не надо.

Я лично с таким сталкиваюсь чуть не каждый день.
Такой блок должен просто работать, выполнять свою функцию. Там не место каким-то настройкам, твикам и т. п. Отход от этого принципа приведёт в конце концов к крушению поезда.
Вот я и говорю — решают за других.

Условия меняются. Вчера это был тормоз для локомотива, сегодня — для трамвая. Масса другая, рельсы другие, воздух и влажность, в конце концов, другие могут быть. Маркетологи тут же быстро подсуетятся, подсунут тот же тормоз, но с другой прошивкой под видом «специально для трамваев», а на деле корректировки мог сделать сам завод. У них свои спецы есть, как бы.
Вот когда в поезде (метро, самолетах) появится USB-разъем в юзерской зоне для программирования, я перестану ими пользоваться. Мало ли кто плагин для вывода на орбиту туда подсунет…
> Вот когда в поезде (метро, самолетах) появится USB-разъем в юзерской зоне для программирования, я перестану ими пользоваться.

Самолёты давно управляются софтом (и там есть не только usb), не понимаю проблемы. Почему в крайности надо бросаться-то? Либо заклеенный МК, либо usb-порты наружу там где их не просят?
Заказчик обычно знает, что ему нужно — прибор или конструктор. Закажут конструктор на линуксе — разработчики сделают ему конструктор на линуксе. Если есть в том потребность.
Вчера это был тормоз для локомотива, и сегодня он останется тормозом для локомотива, и завтра. Что там устанавливают на трамвай, предприятиям железнодорожной промышленности неведомо, потому что это совершенно другая область.
НЛО прилетело и опубликовало эту надпись здесь
Ок, понятно, спасибо за пример.
Пример: недавно писал драйвер для управления UHF RFID считывателем. Для того, чтобы считыватель правильно работал, в некоторых случаях время реакции контроллера на внешнее прерывание должно быть в пределах 50-75 микросекунд (вернее за эти микросекунды надо успеть еще и послать 1 байт по SPI). Даже если ядро Линукс скомпилировано как ядро реального времени, скорее всего сработать не успеет. Решением было выделение отдельного маленького контроллера для управления считывателем, который связывался с основным контроллером по UART.
Тут все понятно. Но дальше данные уходят куда? На еще один микроконтроллер (usb/rs232) или на полноценный комп (usb/rs232/ethernet/web/...)?
Пример:
устройство на основе микроконтроллера при правильной трассировке способно выдержать многократный удар электрошокером, даже не сбрасывается.
встраиваемые ПК в большинстве своем и все ПК сбрасываются даже если рядом с корпусом электрошокером пощелкать.

То есть с точки зрения электромагнитной совместимости микроконтроллеры выигрывают. И там где есть наводки, двигатели и любые силовые ключи — их стихия.
habrahabr.ru/post/147025/#comment_4953976

Так что не все так хорошо и с МК, видимо :)
Удары электрошокером, подозреваю, одинаково хорошо выдержит и МК, и ПК, если оба одинаково к этому подготовить. Физика одна и с элетрическим пробоем что МК, что ПК работать не будет. Или нет? Понятно, что МК может выиграть за счет простоты, но пережить пару киловольт и не сгореть, просто потому что МК — не очень понятно почему.
Процессор с линуксом может не заработать просто из-за не правильной трассировки шин памяти. Соответственно восприимчивость к внешним воздействиям больше. А значит сложней подготавливать, если совсем возможно.
Ок, понятно.

Пишем в список недостатков восприимчивость к ЭМ-помехам.
Ограниченность ресурсов, физических размеров, скорость на определенных задачах и проч
если вы производите 1 девайс, стоимость процессора 20$ против 10$ не имеет роли.
когда вы производите 1 млн девайсов, эта разница выливается в 10млн$.
причем процессор за 10$ в объёме млн штук производить можно по 0.5$, а более мощный — только извините за 5$. итого разница выливается в огромные суммы.
Тут же, на хабре, было сравнение цен, и АРМы были не сильно дороже (не в разы даже) 32-битных микроконтроллеров.
вы напомнили мне недавно на форуме виденное.
человек сделал поворотники на велосипед. голова — 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%… Риторический вопрос :)
У меня тут одна херня есть, она шевелится (а еще моргает диодом) и я из нее могу вытащить пару проводов в USB. У вас на нее дрова уже есть?
Был где-то проект, где линукс-разработчики предлагали писать драйвера (бесплатно) производителям железа. Единственное требование — наличие спек, пусть даже под NDA. Так что не проблема, честно.
НЛО прилетело и опубликовало эту надпись здесь
> Под что драйвера есть, под произвольный usb-wifi?

Под совместимый с самсунговским (но стоящий в 10 раз дешевле), либо загрузить скомпиленный модуль.

Это реальное положение вещей, что сейчас происходят, я не из головы это выдумываю. У меня дома такой телевизор стоит. Прошивку только поменять не могу, потому что она низкоуровневая сильно (привет, микроконтроллеры), и не под мой регион еще не собрал никто (под другие есть).
НЛО прилетело и опубликовало эту надпись здесь
Если брать бытовую технику, где электроника не является основной фичей (как в смартфоне, например), то там стоимость именно электронного RD ничтожная по сравнению с остальным.
НЛО прилетело и опубликовало эту надпись здесь
Думаю за несколько дней, максимум, управлюсь. От алгоритмов зависит. При четкой циклограмме это не представляет сложностей.
НЛО прилетело и опубликовало эту надпись здесь
Я имел ввиду только софт. С электроникой и тестированием получилось бы поболее конечно.

Хотя… контроллер Для Вятка-Автомат 16 (взамен сдохшему механическому коммандоаппарату) я склепал за вечер, и за второй написал прошивку по скану бумажной циклограммы). На столе все работало как часы. Правда так и не поставил, т.к. у машинки до кучи прогнил еще и бак. Пришлось выбросить.

Но вернемся к вашим расчетам. Добавим к стоимости разработку прессформ для пластика и их изготовление (100000 евро, минимум), разработку технологической оснастки для сборочной линии (уже приближаемся к миллиону), разработку всего железа, оплату технологам, сертификации и еще кучу всего разного. Достаточного для того, чтобы даже 100 000 евро за электронику выглядели ничтожным пятнышком на фоне огромной громады остальных затрат. И это только разработка. А есть еще себестоимость изготовления, сборки, логистики, материалов, зарплатный фонд.
НЛО прилетело и опубликовало эту надпись здесь
разве речь шла не о

>Если брать бытовую технику, где электроника не является основной фичей (как в смартфоне, например), то там стоимость именно электронного RD ничтожная по сравнению с остальным.
НЛО прилетело и опубликовало эту надпись здесь
Речь же шла о массовом производстве. Не тысячи штук, а сотни и миллионы экземпляров. Там доля RD часто минимальная. А если еще себестоимость судиться по примерной розничной цене комплектухи, так реальная выходит еще и сильно ниже даже с учетом RD
НЛО прилетело и опубликовало эту надпись здесь
10 000 это средняя серия, вообщет. Даже я, на своем мелком производстве наклепал уже несколько тысяч изделий.
> промышленное исполнение для массового производства по определению создается с нуля, без лишних деталей или функциональностей. Ибо дешевле. Для пользователя, в итоге.

Ну да, конечно. Движки делаем сами, кнопки делаем сами, микрухи каждый раз проектируем с нуля. Даже шнур 220V делаем с нуля, придумываем каждый раз состав пластика…
Наоборот все к унификации идёт. Те же микроконтроллеры — тому пример. Относительно малой кровью получается универсальность. Но я о том и завел спор — на сколько эта кровь малая и на сколько универсальная получается универсальность — не стоит ли подняться на уровень выше? Всё остальное — лирика, попытка приблизится к ответу.

> Стиральная машина, которая будет глючить раз в десять стирок, полетит из окна нахрен — она должна работать как часы.

Эта фраза ни о чем не говорит. Бывает неглючный софт для ПК, бывают глючные решения на микроконтроллерах.

> Линукс, который с железом общается через железо-драйвера-ядро-юзерспейс-ядро-драйвера-железо — по определению менее надежен и избыточен.

Миллионы серверов с многолетними аптаймами с вами не согласятся. Да, менее надежен, да, более избыточен, но достаточен.

> Ваша главная ошибка — это то, что Вы думаете, что нормальное промышленное (и даже консумерское) оборудование и то, что слепил энтузиаст из Урюпинска из конструктора Лего — одно и то же, только у энтузиаста оно еще и лучше (потому что с финтифлюшками).

Да нет. Я нигде это не говорил.
Вот стоит у меня на столе телефон Polycom. SIP, линукс, POE, ethernet, десяток кодеков, веб-интерфейс, прошивки, кастомизация, xml в каждой щели.

Производится в промышленных масштабах. Работает надежно (ни разу ни один не завис, аптайм — годы).

И вспоминаю про аналоговые телефоны, с наборным диском. Вроде та же функция — звонить. Но при этом там даже микрух не было, все аналоговое. Но почему-то в итоге перешли на полностью программные решения (да, я понимаю, что в этом же поликоме есть с десяток микрух, но ядро — полноценный компьютер, что-то на ARM мегагерц на 600).

Почему то же не может произойти со стиралками — не понимаю.
Мы про электронику управляющую вообще-то говорили, причем тут пластик для проводов.

В качестве примеров Вы почему-то всегда приводите те устройства, подавляющее большинство функций которых УЖЕ реализованы в линуксе, то есть сетевые устройства, работающие с потоками данных — роутеры, VOIP, и так далее. Стиралка к таковым не относится.

Вот чайнику, с таким подходом, нужно ли это?

Заметьте, линукс в телевизорах появился ровно тогда, когда стало популярным смотреть видео через интернет и с сетевых дисков (на которые качают торренты). До этого момента оно там нафиг нужно не было и его там-таки не было.

Когда стало нужно — оказалось, что свое все то же самое делать геморройнее в плане R&D, чем поставить готовый линукс и дописать туда интерфейс — ну, взяли и поставили.

Со сторалками — не проще. Не основная это их функция и даже не в первой десятке.
> В качестве примеров Вы почему-то всегда приводите те устройства, подавляющее большинство функций которых УЖЕ реализованы в линуксе, то есть сетевые устройства, работающие с потоками данных — роутеры, VOIP, и так далее.

Уже реализованы, а когда-то не было. Тот же SIP-стэк в железе, помнится, кто-то пытался делать. Но быстро плюнули. Кодеки, правда, делают еще, но тож на софтовые решения переходят по очевидным причинам.

Это ситуация, к которой _пришли_, а не которая была всегда с начала времён.

> Стиралка к таковым не относится.

Это _пока_.
> Стиральная машина, которая, мать ее, ЗАГРУЖАЕТСЯ??? Проверяет диски, если ее вырубить из сети? У которой дохнет флеш? Которую надо обновлять? Подключать ее в домашнюю сеть, чтобы поглядеть достирала ли она? Потом еще Касперского для стиралки скачивать? Да ну нахер! Это из разряда „фонарик с ethernet, который через веб-интерфейс показывает уровень зарядки батареек“.

Роутер, который, мать его, ЗАГРУЖАЕТСЯ??? Проверяет диски, если его вырубить из сети (там, вообще-то, ro на /usr, а /tmp и /var в памяти монтируются, но ладно, пусть). Который надо обновлять? Подключать в домашнуюю сеть что б настроить? Касперского качать — да, бывает иногда, роутеры криворуких компаний ломают удалённо. Ну, tradeoff, как есть.
Черт, я ждал такого ответа. :)

Вы пробовали роутером торренты качать, в качестве сетевого диска его использовать, фильмы оттуда смотреть, в качестве принт-сервера? Я пробовал, скажу честно — говно во всех категориях, кроме собственно роутинга.

Если оно залипать будет на простейших функциях, то-таки да, оно сможет мне через SNMP раз в десять секунд честно сообщать, что не успевает контролировать энкодер :)
Говорят, бывают нормальные. Вот приедет raspberri, попробую сам :)
P.S. Ну и жду ответ от вас по МК с поддержкой езернета, экрана с тачскрином и SNMP :)
Вот тут и кроется ваша ошибка: алгоритм работы стиральной машины встраивается в универсальный контроллер. И всё. Зачем там распбери с линуксом?
Итак ваше решение:
1. От контроллера вы не отказываетесь, собственно вы и не сможете от него отказаться. Вы просто покупаете готовый модуль (ок, универсальный контроллер), который будет стоить достаточно много денег, так как его не используют фирмы с серийным производством, а только хоббисты.
2. Вместо того, чтоб на этом контроллере закончить, вы ствите ещё один, который выполняет элементарный алгоритм в три строки. Опять же, тут следует ещё наладить самостоятельное производство распбери, потому-что количество производящихся машинок гораздо выше количества выпускаемых распбери.
3. Сколько вы планируете потратить на вычислительную логику? По моим прикидкам, это вам обойдётся от 40 до 60 долларов.

Стоит учесть, что себестимость машинки должна быть ниже 100 долларов, иначе она просто будет неконкурентноспособной. Самыми дорогими комплектующими являются корпуса, барабаны, клапаны, моторы и прочая фигня (долларов на 85 наберётся).

Моё решение:
Разрабатывается одна (!) плата для управления всем этим на процессоре Cortex-M3. Камешек обойдётся доллара в 2-3, изготовление печатки под него с элементами — ещё 7-10.
Камень, как и любой другой современный контроллер обладает аппаратной поддержкой езернета, экран с тач-скрином управляется нашару (если лень писать самому — полно библиотек, хотя что это за фирма, где инженер не может сделать управление тач-скрином), либ для поднятия SNMP — полно.

Итак, вы продавец — консультант. Перед вами стоит покупатель, за вами 2 стиральных машинки. Выглядят одинаково, функции идентичные. Вообще, ни одного отличия. Теперь обьясните покупателю, какая ему разница, есть ли внутри линукс и распбери и почему он должен заплатить за это ещё 50 долларов (в лучшем случае).
> 1. От контроллера вы не отказываетесь, собственно вы и не сможете от него отказаться. Вы просто покупаете готовый модуль (ок, универсальный контроллер), который будет стоить достаточно много денег, так как его не используют фирмы с серийным производством, а только хоббисты.
> 2. Вместо того, чтоб на этом контроллере закончить, вы ствите ещё один, который выполняет элементарный алгоритм в три строки. Опять же, тут следует ещё наладить самостоятельное производство распбери, потому-что количество производящихся машинок гораздо выше количества выпускаемых распбери.

Взаимоисключащие пункты. То ли у нас мелкосерийное производство и используем хобби-комплекты, то массовое производство и хобби-комплектов надо много и хоббисты не справятся с поставками.
Я, к сожалению, не могу оперировать конкретными названиями и использую «распберри» просто как пример полноценного компьютера в компактном форм-факторе с открытой схемой разработки (загрузчик можно менять, софт можно заливать, drm/tivo нету).

Соответственно, если фирме надо массовое производство — они закажут большую партию. Опять-таки, специализированный контроллер не нужен, подозреваю. Нужна просто прошивка под один из имеющихся контроллеров общего назначения.

Зачем нужен отдельно контроллер, отдельно полноценный комп — я описывал в соседней ветке. Контроллер реализует низкоуровневые операции вида «включить барабан», «держать температуру N градусов», «выяснить состав порошка».

Контроллер может меняться от машины к машине (вдруг где два барабана или набор датчиков совсем другой) — но маловероятно.

Дальше — полноценный комп. Нужен банально для того, что б кардинально удешивить разработку софта, который нужен все-равно.

> хотя что это за фирма, где инженер не может сделать управление тач-скрином)

Вот так и появляются отвратительные интерфейсы. Свежий пример стоит у меня через стенку — некий МФУ от самсунга. Редкостное говно, как в работе, так и в интерфейсе. А могли сделать просто веб-интерфейс, открыть прошивку, дать доступ и забыть. А сделали по другому — отвратительный глючный тормозной кривой интерфейс, закрытая прошивка, отсутствие доступа и на всех забили. Ни поддержки, ни обновлений прошивки с фиксами уже имеющихся глюков. К слову о сервисе, да.

> либ для поднятия SNMP — полно.

facepalm.jpg.to

А потом мне с ними работать. Тут не реализовали одно, тут другое, тут это не работает, а работает другое, а тут просто сделали свой MIB, ни с чем, кроме родного софта не совместимый вообще впринципе. А могли юзать одну стандарную, проверенный годами, открытую библиотеку. Не для МК, правда, вот в чем затык. А от полноценного компа мы отказались, потому что у нас герой-инженер, тратящий время на повторение очередного велосипеда, вместо того что б использовать готовые компоненты…
> А могли сделать просто веб-интерфейс, открыть прошивку, дать доступ и забыть.

Т.е. вы предлагаете выбросить на рынок сырую недоделку, а пользователи пусть допиливают? Браво!
Не надо путать сырые недоделки и будущие опции.

Ну и, собсно, сейчас весь мир делает сырые недоделки, только вот прошивки при этом недоступны.
1 и 2 это не взаимоисключающие пункты. А прямоследующие. Если без 1 не обойтись, более того возможности позволяют и все можно сделать на 1, то зачем там 2? Ради пары сомнительных штук которые нужные единицам и то исключительно для лузлов?
Нет, у нас крупносерийное производство и мы используем хобби-комплекты. Их уже изобрели — мы же не герои писать всё это заново.

Выскокуровневую операцию — включить барабан — лучше реализовывать на стороне сервера, желательно в облаке — она требует выскокой вычислительной мощности.


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

Хотя, насчёт цены мы лучше не будем вообще говорить, пользователи, ведь, знают — чем дороже, тем лучше.

Любой инженер становится дизайнером, если ему дать библиотеки с открытым исходным кодом.

И да, чуть не забыл, я не хочу с вами спорить и тролить кого-бы то ни было.
эзернет на МК Вообще не проблема. В цикле статей от lifelover это было подробно обсосано и ради лулзов поднят даже сервачок на 8мибиитке с 32кб ОЗУ, где мы толпой радостно чатились. Как не проблема и тачскрин и большой экран.

Просто надо ли оно? У стиральной машины, в идеале вообще не должно быть интерфейса. Положил белье, закрыл, достал чистое.
НЛО прилетело и опубликовало эту надпись здесь
Да, но при исправной машине Вы их видеть не должны.
НЛО прилетело и опубликовало эту надпись здесь
В том и дело что для лулзов. На полноценном компе ставится сервис чата (ставится, а не пишется). За полчаса, а не за месяц.
И Вы хотите, чтобы ради Ваших лулзов все производители и пользователи резко прогнулись?
Да, и несли мне дань.

Читайте ветку с начала. Я ничего не хочу, я пытаюсь понять, почему в одной индустрии это — промышленный стандарт, а в соседней — пальцем у виска крутят при намёках.
По той же причине, по которой Вы сами не можете обновить софт в контроллере двигателя своего автомобиля. Потому что оно не нужно 99.999% пользователей.
Вот в машинах, на сколько я знаю, уже давно не микроконтроллеры стоят. Последний, что видел, Motorola 68K. Это полноценный проц, хоть и древний, ни разу не микроконтроллер. Микроконтроллеры могут быть на входах-выходах, для низкоуровневого управления, но высокоуровневый контроль — вполне себе обычный проц.

И на счет 5 девяток вы погорячились. Сервисы, производящие настройку (фактически, перепрошивку) софта для контроллеров двигателей — хватает.
А теперь, в качестве самообразования, объясните, что Вы понимаете под термином «микроконтроллер», а что — под термином «микропроцессор».
Вы правы, там стоит Freescale.
MPC5XX стоит на большинстве ECU (на EDC16 и на EDC15, используемых в MB, VW, GM). Это — современный микроконтроллер, ни разу не древний "проц".
В прочем, вы не знаете, что такое микроконтроллер и что такое то, что вы называете процессором.
Учите матчасть ©.
Сервисы, производящие апгрейд софта стиралок, тоже есть.
Другое дело, что если они отвечают за работу машины — они туда никого не пускают, и это нормально.

Да, это не отвечает требованиям гиков. Зато это отвечает требованиям домохозяек, которым нужна Одна Большая Кнопка «сделать хорошо».
Ага, а потом местный хакер Вася найдет эксплоит в стиральной машине Бабы Нюры, живущей над Леной, которая его в прошлом году бросила, и устроит ей массовый потоп.
Он и сейчас может пойти и кипричем в стекло запустить.
Я же сказал, Хакер Вася, а не Гопник Вася.
Кибергопник Вася, ок.

Взлом стиралки с целью затопа — это не хакерство.
НЛО прилетело и опубликовало эту надпись здесь
Зачем фразу обрывать на полпути? Там был еще тачкскрин и SNMP.
НЛО прилетело и опубликовало эту надпись здесь
Да, зафлудился.

А тачскрин?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ну и 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 сек и жил сутки от аккума! Мобильный девайс как ни как!
это для angry_elf ))
> Я бы предпочел чтобы прибор включался за 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 раз в секунду обрабатывать и отдавать дальше данные. Зачем в таком модуле полноценный процессор с линуксом?
Мне кажется, что вы немного спешите с выводами.

Я работаю с контроллерами Atmel уже много-много лет и из реальных недостатков увидел только два:
  • относительно высокая цена
  • особые требования к экранированию в шумных средах


Если вдруг нужно будет работать с Атмелом и дальше, то может быть вам помогут некоторые выводы, к которым я пришел за это время:
  • используйте JTAG для прошивки (мы используем самодельный JTAG ICE, его вполне хватает для многих популярных контроллеров)
  • используйте проверенные контроллеры (мы почти всё собираем на AtMega169 и AtMega32/64/128/128CAN)
  • намного лучше сразу делать макетную под конкретный проект (это не занимает больше нескольких часов, сразу видно намного больше потенциальных проблем)
  • уделяйте особое внимание экранированию
  • забросьте студию, пишите на IAR Embedded Workbench, оно того стоит


У нас реально на Атемлах (128CAN, 169) системы управления цехами завода работают вообще без каких-либо проблем, написана своя микроОС.

Вообще, писать для Атемлов — это удовольствие; исходя из нашего опыта — это очень стойкие, беспроблемные камни.
Недавно выбирал себе программатор под 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. Да, дороже, но на этом я точно знаю, что сделаю.

Заказчик подумал и выбрал атмегу.
На работе так же сначала подумал сделать на АРМе один девайс, потом выбрал AVR. В сто раз будет меньше граблей, ибо я его знаю.
А как бы вы отвечали заказчику в ответ на требование провести анализ рынка и выдать варианты, соответствующие указанным требованиям?

Или вы почему-то решили, что мы не стали сообщать заказчику, что с такой-то и такой-то платформой у нас уже есть опыт работы и платформа себя показала весьма хорошо, поэтому в нашем списке предпочтений именно эта платформа на первом месте, а с такой и такой платформой мы раньше дела не имели, поэтому в случае выбора ее на проекте появляется дополнительный риск неизведанной платформы?
Пипец.
Можно спросить, кто там еще кроме атмела был в списке и какие были требования?

А ответ такой — я бы не дал заказчику выбирать платформу, либо отказался бы делать.
Не дело это — учиться работать прямо по ходу работы за деньги.
Так если заказчику об этом было сразу сказано, и он все равно выбрал то, что выбрал — то почему нет? Ну и «не дать заказчику выбрать платформу» тоже сильно звучит, т.к. кто платит — тот и решает, кому какие полномочия давать, нет? К сожалению, даже когда видишь, что заказчик делает полную фигню, все, что можешь — это ему корректно про это сообщить, и предложить альтернативу. Согласится — хорошо, нет — придется, матерясь, делать так, как он хочет, увы :(

Основной альтернативой были STM32F207ZG и MK60FN1M0VLQ12, требования не буду разглашать…
Целая статья о том какие у вас руки кривые)) Ни слова не нашел про недостатки самих контроллеров. Одни лучи поноса в сторону средств разработки и отладки. Авр студио 4 вполне себе ничего, а использовать САМУЮ НОВУЮ студию — очень странно для программистов. Что вы не понимаете, чтоли, что компании стараются выпускать поскорее сырые программные продукты, чтобы бабла срубить — тот же альтиум чего стоит, используйте стабильную версию и всё, отладчиков для атмелов тоже хватает нормальных. Короче «Нечего на зеркало пенять, коли рожа крива»
Хорошая у вас логика, ничего не скажешь — из того, что «компании стараются выпускать поскорее сырые программные продукты», вы почему-то делаете вывод, что кривые руки у нас. И наверное, именно из-за наших кривых рук у дебаггеров отваливались коннекторы и разъемы питания, сами дебаггеры иногда просто сгорали, а у контроллеров вдруг стирались read-only CPU ID и данные калибрации тактового генератора (из-за чего тактовая частота с 8 МГц вырастала до 16, а дебаггеры тупо переставали видеть контроллер).
ну можно было перед покупкой дебагеров изучить — какие из них стоит брать, а какие нет.
И кстати, самая новая 6-я студия таки оказалась вполне ничего и сильно получше 5-й.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории