В каком смысле — платы «заказывать»? Заказывать разработку или производство? Если вы про производство, то тут вопросов нет — самому производить платы, все равно, что самому шить себе одежду и выращить все продукты питания: только этим и будешь заниматься и то плохо сделаешь.
Если же речь шла о разработке, то в вашем случае, боюсь, это невозможно, т.к. зачем кому-то на заказ делать готовый продукт, если его можно продавать самому — уведут. Так можно заказывать только разработку плат, которые без софта бесполезны, а софт можно защитить битом RO в MCU.
Я всё-таки говорил про обучение, а не про работу. Про работу я специально уточнил: отладчик может понадобиться; по крайней мере в некоторых ситуациях.
Насчёт «пару раз наткнуться на неожиданное для новичка поведение» у меня другое мнение: для новичка много что будет неожиданным и это ещё не повод заниматься практикой без теории.
Вот не соглашусь. Чтобы «попробовать микроконтроллеры», отладка совсем даже не нужна. Она (возможно) нужна для работы, но для ознакомления с предметной областью нужен минимум инструментов и — это самое главное — мозг. При обучении очень важно, чтобы программа заработала сначала на эмуляторе, который встроен в ваш мозг, а уж потом — на реальном железе. А у большинства начинающих (по моей статистике) получается наоборот: сначала они при помощи отладчика методом тыка находят работающий вариант (часто даже не открывая datasheet и progmanual), а уж потом — если есть желание, время или упёртость — пытаются понять почему это работает. Должно быть как раз наоборот.
Все написаное есть ИМХО, выстраданное на некотором опыте обучения людей embedded разработке и на собственном опыте. Сам я не пользуюсь отладчиком даже в рабочих проектах, хотя не считаю это обязательным. Просто у меня почему-то всего два состояния: либо я пользуюсь отладчиком и выключаю эмулятор в моей голове, либо не пользуюсь отладчиком. У других получается сопрягать и я им завидую :)
И этого не надо. Надо купить переходник USB<->UART и не мучаться. У подавляющего большинства ARM'ов есть возможность прошивки (или хотя бы BOOT) через UART.
Как разработчик электроники, очень часто отвечаю на такие заявления, чтобы, так сказать, просветить людей, для которых область разработки покрыта мраком.
Да, никто сейчас не разрабатывает, что называется, from scratch. Это просто невозможно сделать (речь идет о современной бытовой электронике). Но есть большая разница между, скажем, ноутбуком Lenovo и ноутбуком RoverBook.
В первом случае цепочка разработки такова (я не знаю точно какова эта цепочка, но опишу «худший» с вашей точки зрения вариант). Инженеры Lenovo разрабатывает дизайн-проект нового ноутбука. Дизайн-проект, если по-простому, представляет собой набор требований. Требования могут звучать, например, так: «ноутбук должен иметь вес менее 1 кг, габариты такие-то, процессор производительностью такой-то и при этом время бесперебойной работы такое-то». Дальше разработка разделяется.
1. Нанимают дизайнеров, которые разрабатывают внешний вид ноутбука.
2. Инженеров по эргономике, которые разрабатывают эргономику.
3. Железячников (моих коллег), которые разрабатывают материнскую и сопутствующие платы.
4. Технологов, разрабатывающих корпус.
Конкретная декомпозиция задачи может быть более сложной, я привел самый простой вид. Каждый из исполнителей как правило работает не в вакууме — он взаимодействует с остальными; стандартная ситуация: дизайнеры придумали что-то такое супер-пупер красивое, но технологи утверждают, что это Г… будет ломаться от дуновения ветра, т.к. не существует доступных дешевых материалов, имеющих при таких размерах достаточную прочность. И т.д. и т.п.
В результате получается продукт, который «сделал не Lenovo» (как бы). Но на самом деле это просто воплощение проекта, который разработан в Lenovo, воплощение идей их инженеров.
В китае существует много контор, которые хорошо умеют только разрабатывать железо и дружат с разработчиками корпуса. Т.к. в их технологической цепочке нет «головы» (нет людей, которые заняты только тем, что продумывают, что должно получиться в итоге и — главное — зачем оно должно быть именно таким), их продукты, мягко говоря, спросом не пользуются.
Теперь о грустном: от том, как построена разработка у нас. Она намного проще.
1. Находим китайского производителя, описанного в предыдущем параграфе.
2. Заказываем у него разработку корпуса «не похожего на тот, в котором вы уже продаете свои ноутбуки».
3. Заказываем ноутбуки с этим «другим» корпусом, на котором красуется шильдик российской компании.
4. Profit.
По этой схеме работают, например, всем известные CarCam'овцы. Кстати, они этого, в отличие от многих других наших «производителей», даже не скрывают.
Так вот к чему все это говорилось. К таким «производителям» (CarCam, RoverBook и пр.) претензий нет — ну делают что-то, ну продают, люди покупают — какие претензии? Не сказали, что китайцы делают? Ну да, скрытные немного… А в остальном — ничего плохого…
Претензии у нас, честных налогоплательщиков, к тем госзаказчикам и их «паханам», которые с такими вот «производителемя» заключают контракты на такие суммы. Суммы, которые вливаются в отечественные «разработки» не соотвестствуют рыночной стоимости таких «разработок». Если перевести в человеко-часы… лучше даже не переводить.
В общем, либо это — глупая трата наших народных денег глупыми госзаказчиками, либо — просто пускание пыли в глаза электрату. Хочется верить, что хотя бы первое. Но в любом случае осуждать такую деятельность надо: не сам её факт, а суммы, которые при этом мелькают…
FreeRTOS возможно и не требует MMU и Memory Protectrion модулей, но Linux уже не встанет.
FreeRTOS разрабатывалась в те времена, когда рядовому разработчику дотянуться до микропроцессора (не MCU, а MPU) было очень трудно. Да и SDRAM память в 32 мегабайта стоила прилично. А многозадачности хотелось. Сегодня можно свободно купить lpc31xx за гроши (менее $5) и поставить туда SDRAM от Hynix на 32 мегабайта за $1.5! И на этом железе можно свободно развернуть и Linux (если главное требование — скорость и стоимость разработки) и полноценный вариант FreeRTOS со всеми защитами памяти и пр. (если требуется ОСРВ) или ещё, что душеньке угодно. И главное — это будут полноценные ОС, процессы которых не могут случайно залезть в ядро и преврать жизнь разработчика в АД.
Я для себя, как для разработчика embedded систем, давно решил: ОС нужна только тогда, когда надо защитить одну ветвь выполнения от другой. В любом другом случае можно по-быстрому наклепать систему параллельно выполняемых задач и на этом успокоиться (хотя такое нужно редко). В качестве примера приведу случай из практики. Мы разрабатывали для стороннего заказчика аппаратную платформу (АП). Под АП подразумевается собственно железка (А) и уровень аппаратных абстракций (П, или, правильнее, — HAL). HAL нужен для того, чтобы программисты заказчика могли писать задачи для железки не зная её архитектурных особенностей. Для них мы предоставляем Си-шный интерфейс к железке, выраженный очень простыми и понятными терминами.
Когда уже казалось, что проект сдан, стали поступать многочисленные жалобы от них. Якобы наша железка ведет себя не стабильно. Отчасти это в том проекте и было так, процессор (только что вышедший) оказался редкостным Г, но были и другие причины: в своих программах разработчики заказчика, сидя в достаточно стесненных условиях (рамы мало, скорость процессора не велика), вели себя так же, как на полноценном ПК. Удобней передать в стек 15 КБайт данных — передам. Рекурсивная функция — пожалуйста. В итоге стек начал переполняться и программа начинала выкидывать фокусы (работа превратилась в морской бой, при пуске устройства никогда не знаешь заранее, что отвалится). Прикручивание тормозящей все и вся защиты стека дало мало: есть же ещё разыменования указателей и много других способов залезть куда не надо. Из-за их ошибок происходило повреждение памяти, где находился наш код HAL и после этого происходили самые невероятные вещи. Намучились мы тогда здорово…
В следующем проекте мы специально выбрали микропроцессор (MPU) и написали свою маленькую ОС с защитой памяти ядра (ядром являлся наш HAL) и системными вызовами. Получилась ОС с одной задачей, ядро — HAL, задача — прикладная задача заказчика. Ни одного сообщения, подобного тому, которое получали по прошлому проекту, в этот раз не было. Вот тогда мы поняли, зачем в действительности нужны операционные системы в embedded…
Чуть-чуть дополню. На данный момент есть, хотя и несколько размытое, разграничение терминов микророцессор и микроконтроллер. Я долго думал над тем, кто же есть кто и не одно ли это и тоже, но в итоге удалось спросить об этом главного инженера по развитию NXP на одной из конференций. Вот, что он ответил.
Микроконтроллеры (MCU) — однокристальные микрокомпьютеры, предназначенные для исполнения т.н. задач (task). Задача — это самостоятельная программа, которая полностью и единолично управляет всеми ресурсами системы. Никого, кроме задачи в системе нет.
Микропроцессоры (MPU) — однокристальные микрокомпьютеры, предназначенные для исполнения связки операционная_система&приложения.
Из этих базисных положений вытекают разные конструкторские решения для MCU и MPU:
1. Микроконтроллеры как правило имеют и оперативную память и постоянную память на борту, т.к. для задачи и того и другого требуется не много. Средств для аппаратной защиты сегментов памяти (MMU и пр.) — нету (а зачем? мы же в системе одни!). Интерфейсов для RAM большого объема как правило нет. Часто нет и интерфейса для NVM большого объема.
2. Связка ОС&приложения требуют заметно больше места как в RAM, так и в NVM, причем диаппазон требуемой памяти в зависимости от задачи может разниться от 4 Мегабайт RAM до 4 ГБайт RAM на MPU одной мощности. Поэтому памяти как правило (но бывают исключения для специальных случаев) не размещают на кристалле, а делают для них интерфейсы (SDRAM, NAND интерфейс, MMC и т.д.).
А есть ещё один ещё более туманный термин — SystemOnChip. SystemOnChip — это микропроцессор, который специально заточен для исполнения на нем прикладной ОС для конечных пользователей. Возьмем обычный MPU, добавим туда видеопроцессор, аудиопроцессор и пр. необходимые для ПК или КПК вещи и вуаля.
Это всё несколько размыто, но тот NXP'шный инженер сам признался, что термины нигде не закреплены и витают в воздухе, просто есть более-менее общая трактовка.
1. На дискете однозначно сертификат.
2. Таблетка однозначно используется для идентификации.
Варианты использования:
1. Генерация серийных номеров продуктов Symantec. (уже писали)
2. Подпись документов во внутреннем документообороте компании: приказов, служебных записок и пр.
На самом деле очень интересна строка на дискете "# of Days: 50". Мне кажется это — ключ к разгадке. Эти 50 дней выдаются и их надо использовать за указанный на дискете период. В связи с этим ещё версии:
3. Сотруднику выдают 50 отпускных дней в год, учет этих дней автоматизирован, при помощи этого аппаратно-программного средства производится использование этих 50 дней отпуска.
4. 50 дней использования какого-то ресурса (например суперкомпьютера).
Любопытный каламбур получился у вас :) Добавка "-с" как раз образовалась как сокращение от «сударь». У вас получилось сударь-сударь :) Ну это так, просто смешно вышло.
А статья действительно интересная, молодцы ребята.
1. Трафарет в домашних условиях изготовить значительно проще, проделать то, что изображено на фотографии.
2. Шары не нужны. Нужна, как уже указали, паяльная паста. Ещё нужен паяльный фен. Но можно обойтись и строительным, раз уж такая пьянка пошла.
Цифры в студию! Очень сомневаюсь, что ИК-светодиод потребляет больше, чем беспроводные модули связи.
А вообще, логичнее было бы модернизировать не канал связи пультов ДУ, а корпуса и кнопки. Давно уже пора отойти от этих дурацких замусоривающихся/залипающих резиновых кнопок к чему-нибудь вроде емкостных.
Не претендую на истину в последней инстанции но всегда считал так.
Трансляция — «дословный перевод», «перевод по таблице соответствий», скорее подходит к Ассемблеру, чем к Си (для примера). Хотя современные ассемблеры содержат много «примочек», но всё же.
Компиляция — получение объектных файлов из исходного кода.
Компоновка — получение исполняемого файла из объектных файлов.
А также:
Программа — любая последовательность действий.
Приложение — файл, содержащий последовательность действий (программу), записанную на понятном процессору языке и пригодном для исполнения (возможно упакованную в определённом формате).
Насчёт нетбука в цеху. Если удорожание в три-четыре раза приемлемо, гляньте в сторону грязе/водо/ударо-защитных планшетников. Если сама идея заинтересует, узнаю у человека, который их использовал в своих разработках и дам линки/контакты.
Нетбук для цеха достаточно хлюпкое создание, на мой взгляд (и многие знакомые подобные ситуации решались НЕ при помощи стандартных PC — не важно настольных или нет). Но своё разрабатывать, разумеется, не стоит.
Если же речь шла о разработке, то в вашем случае, боюсь, это невозможно, т.к. зачем кому-то на заказ делать готовый продукт, если его можно продавать самому — уведут. Так можно заказывать только разработку плат, которые без софта бесполезны, а софт можно защитить битом RO в MCU.
Насчёт «пару раз наткнуться на неожиданное для новичка поведение» у меня другое мнение: для новичка много что будет неожиданным и это ещё не повод заниматься практикой без теории.
Все написаное есть ИМХО, выстраданное на некотором опыте обучения людей embedded разработке и на собственном опыте. Сам я не пользуюсь отладчиком даже в рабочих проектах, хотя не считаю это обязательным. Просто у меня почему-то всего два состояния: либо я пользуюсь отладчиком и выключаю эмулятор в моей голове, либо не пользуюсь отладчиком. У других получается сопрягать и я им завидую :)
Да, никто сейчас не разрабатывает, что называется, from scratch. Это просто невозможно сделать (речь идет о современной бытовой электронике). Но есть большая разница между, скажем, ноутбуком Lenovo и ноутбуком RoverBook.
В первом случае цепочка разработки такова (я не знаю точно какова эта цепочка, но опишу «худший» с вашей точки зрения вариант). Инженеры Lenovo разрабатывает дизайн-проект нового ноутбука. Дизайн-проект, если по-простому, представляет собой набор требований. Требования могут звучать, например, так: «ноутбук должен иметь вес менее 1 кг, габариты такие-то, процессор производительностью такой-то и при этом время бесперебойной работы такое-то». Дальше разработка разделяется.
1. Нанимают дизайнеров, которые разрабатывают внешний вид ноутбука.
2. Инженеров по эргономике, которые разрабатывают эргономику.
3. Железячников (моих коллег), которые разрабатывают материнскую и сопутствующие платы.
4. Технологов, разрабатывающих корпус.
Конкретная декомпозиция задачи может быть более сложной, я привел самый простой вид. Каждый из исполнителей как правило работает не в вакууме — он взаимодействует с остальными; стандартная ситуация: дизайнеры придумали что-то такое супер-пупер красивое, но технологи утверждают, что это Г… будет ломаться от дуновения ветра, т.к. не существует доступных дешевых материалов, имеющих при таких размерах достаточную прочность. И т.д. и т.п.
В результате получается продукт, который «сделал не Lenovo» (как бы). Но на самом деле это просто воплощение проекта, который разработан в Lenovo, воплощение идей их инженеров.
В китае существует много контор, которые хорошо умеют только разрабатывать железо и дружат с разработчиками корпуса. Т.к. в их технологической цепочке нет «головы» (нет людей, которые заняты только тем, что продумывают, что должно получиться в итоге и — главное — зачем оно должно быть именно таким), их продукты, мягко говоря, спросом не пользуются.
Теперь о грустном: от том, как построена разработка у нас. Она намного проще.
1. Находим китайского производителя, описанного в предыдущем параграфе.
2. Заказываем у него разработку корпуса «не похожего на тот, в котором вы уже продаете свои ноутбуки».
3. Заказываем ноутбуки с этим «другим» корпусом, на котором красуется шильдик российской компании.
4. Profit.
По этой схеме работают, например, всем известные CarCam'овцы. Кстати, они этого, в отличие от многих других наших «производителей», даже не скрывают.
Так вот к чему все это говорилось. К таким «производителям» (CarCam, RoverBook и пр.) претензий нет — ну делают что-то, ну продают, люди покупают — какие претензии? Не сказали, что китайцы делают? Ну да, скрытные немного… А в остальном — ничего плохого…
Претензии у нас, честных налогоплательщиков, к тем госзаказчикам и их «паханам», которые с такими вот «производителемя» заключают контракты на такие суммы. Суммы, которые вливаются в отечественные «разработки» не соотвестствуют рыночной стоимости таких «разработок». Если перевести в человеко-часы… лучше даже не переводить.
В общем, либо это — глупая трата наших народных денег глупыми госзаказчиками, либо — просто пускание пыли в глаза электрату. Хочется верить, что хотя бы первое. Но в любом случае осуждать такую деятельность надо: не сам её факт, а суммы, которые при этом мелькают…
FreeRTOS возможно и не требует MMU и Memory Protectrion модулей, но Linux уже не встанет.
FreeRTOS разрабатывалась в те времена, когда рядовому разработчику дотянуться до микропроцессора (не MCU, а MPU) было очень трудно. Да и SDRAM память в 32 мегабайта стоила прилично. А многозадачности хотелось. Сегодня можно свободно купить lpc31xx за гроши (менее $5) и поставить туда SDRAM от Hynix на 32 мегабайта за $1.5! И на этом железе можно свободно развернуть и Linux (если главное требование — скорость и стоимость разработки) и полноценный вариант FreeRTOS со всеми защитами памяти и пр. (если требуется ОСРВ) или ещё, что душеньке угодно. И главное — это будут полноценные ОС, процессы которых не могут случайно залезть в ядро и преврать жизнь разработчика в АД.
Я для себя, как для разработчика embedded систем, давно решил: ОС нужна только тогда, когда надо защитить одну ветвь выполнения от другой. В любом другом случае можно по-быстрому наклепать систему параллельно выполняемых задач и на этом успокоиться (хотя такое нужно редко). В качестве примера приведу случай из практики. Мы разрабатывали для стороннего заказчика аппаратную платформу (АП). Под АП подразумевается собственно железка (А) и уровень аппаратных абстракций (П, или, правильнее, — HAL). HAL нужен для того, чтобы программисты заказчика могли писать задачи для железки не зная её архитектурных особенностей. Для них мы предоставляем Си-шный интерфейс к железке, выраженный очень простыми и понятными терминами.
Когда уже казалось, что проект сдан, стали поступать многочисленные жалобы от них. Якобы наша железка ведет себя не стабильно. Отчасти это в том проекте и было так, процессор (только что вышедший) оказался редкостным Г, но были и другие причины: в своих программах разработчики заказчика, сидя в достаточно стесненных условиях (рамы мало, скорость процессора не велика), вели себя так же, как на полноценном ПК. Удобней передать в стек 15 КБайт данных — передам. Рекурсивная функция — пожалуйста. В итоге стек начал переполняться и программа начинала выкидывать фокусы (работа превратилась в морской бой, при пуске устройства никогда не знаешь заранее, что отвалится). Прикручивание тормозящей все и вся защиты стека дало мало: есть же ещё разыменования указателей и много других способов залезть куда не надо. Из-за их ошибок происходило повреждение памяти, где находился наш код HAL и после этого происходили самые невероятные вещи. Намучились мы тогда здорово…
В следующем проекте мы специально выбрали микропроцессор (MPU) и написали свою маленькую ОС с защитой памяти ядра (ядром являлся наш HAL) и системными вызовами. Получилась ОС с одной задачей, ядро — HAL, задача — прикладная задача заказчика. Ни одного сообщения, подобного тому, которое получали по прошлому проекту, в этот раз не было. Вот тогда мы поняли, зачем в действительности нужны операционные системы в embedded…
Микроконтроллеры (MCU) — однокристальные микрокомпьютеры, предназначенные для исполнения т.н. задач (task). Задача — это самостоятельная программа, которая полностью и единолично управляет всеми ресурсами системы. Никого, кроме задачи в системе нет.
Микропроцессоры (MPU) — однокристальные микрокомпьютеры, предназначенные для исполнения связки операционная_система&приложения.
Из этих базисных положений вытекают разные конструкторские решения для MCU и MPU:
1. Микроконтроллеры как правило имеют и оперативную память и постоянную память на борту, т.к. для задачи и того и другого требуется не много. Средств для аппаратной защиты сегментов памяти (MMU и пр.) — нету (а зачем? мы же в системе одни!). Интерфейсов для RAM большого объема как правило нет. Часто нет и интерфейса для NVM большого объема.
2. Связка ОС&приложения требуют заметно больше места как в RAM, так и в NVM, причем диаппазон требуемой памяти в зависимости от задачи может разниться от 4 Мегабайт RAM до 4 ГБайт RAM на MPU одной мощности. Поэтому памяти как правило (но бывают исключения для специальных случаев) не размещают на кристалле, а делают для них интерфейсы (SDRAM, NAND интерфейс, MMC и т.д.).
А есть ещё один ещё более туманный термин — SystemOnChip. SystemOnChip — это микропроцессор, который специально заточен для исполнения на нем прикладной ОС для конечных пользователей. Возьмем обычный MPU, добавим туда видеопроцессор, аудиопроцессор и пр. необходимые для ПК или КПК вещи и вуаля.
Это всё несколько размыто, но тот NXP'шный инженер сам признался, что термины нигде не закреплены и витают в воздухе, просто есть более-менее общая трактовка.
2. Таблетка однозначно используется для идентификации.
Варианты использования:
1.
Генерация серийных номеров продуктов Symantec.(уже писали)2. Подпись документов во внутреннем документообороте компании: приказов, служебных записок и пр.
На самом деле очень интересна строка на дискете "# of Days: 50". Мне кажется это — ключ к разгадке. Эти 50 дней выдаются и их надо использовать за указанный на дискете период. В связи с этим ещё версии:
3. Сотруднику выдают 50 отпускных дней в год, учет этих дней автоматизирован, при помощи этого аппаратно-программного средства производится использование этих 50 дней отпуска.
4. 50 дней использования какого-то ресурса (например суперкомпьютера).
А статья действительно интересная, молодцы ребята.
2. Шары не нужны. Нужна, как уже указали, паяльная паста. Ещё нужен паяльный фен. Но можно обойтись и строительным, раз уж такая пьянка пошла.
Но для иллюстрации основ конкретный контроллер имеет не много значения. Автору спасибо.
А вообще, логичнее было бы модернизировать не канал связи пультов ДУ, а корпуса и кнопки. Давно уже пора отойти от этих дурацких замусоривающихся/залипающих резиновых кнопок к чему-нибудь вроде емкостных.
Трансляция — «дословный перевод», «перевод по таблице соответствий», скорее подходит к Ассемблеру, чем к Си (для примера). Хотя современные ассемблеры содержат много «примочек», но всё же.
Компиляция — получение объектных файлов из исходного кода.
Компоновка — получение исполняемого файла из объектных файлов.
А также:
Программа — любая последовательность действий.
Приложение — файл, содержащий последовательность действий (программу), записанную на понятном процессору языке и пригодном для исполнения (возможно упакованную в определённом формате).
Нетбук для цеха достаточно хлюпкое создание, на мой взгляд (и многие знакомые подобные ситуации решались НЕ при помощи стандартных PC — не важно настольных или нет). Но своё разрабатывать, разумеется, не стоит.
А что происходит? Драйвер есть в opera:plugins например?