Как проверить на работоспособность микроконтроллер: Как проверить исправность микроконтроллера

Содержание

Как проверить исправность микроконтроллера

Как проверить исправность детали. Методика испытаний. Оглавление :: Поиск Техника безопасности :: Помощь. Иногда хорошая, проверенная схема, собранная правильно, не работает.


Поиск данных по Вашему запросу:

Схемы, справочники, даташиты:

Прайс-листы, цены:

Обсуждения, статьи, мануалы:

Дождитесь окончания поиска во всех базах.

По завершению появится ссылка для доступа к найденным материалам. ПОСМОТРИТЕ ВИДЕО ПО ТЕМЕ: Проверка микроконтроллеров

Воскрешение микроконтроллера ATtiny2313 после «кривой» установки Fuse-битов


На данный раздел помимо Правил форума распространяются текже следующие правила:. Если Вам понравилась атмосфера форума, заходите к нам чаще! Пожалуйста, подождите Здравствуйте, Гость Вход Регистрация Что даёт регистрация на форуме? Подскажите, пожалуйста. Возникла следующая проблемма. Тогда ничего не получилось сделать. Поднабравшись теории я решил попробовать еще раз. Первым делом решил прошить контроллер простенькой программой.

Просто поставил логическую 1 на выходы порта. Прошил контроллер с помощью программатора. Но при проверки на правтике контроллер не подавал ни каких сигналов. Тогда я пошел и купил новый котроллер ATmegaL обыного не было в наличии. Программа прошивки написанна верно, я ее проверял на Proteus Isis, все работало.

Как проверить действительно ли контроллер неисправен? Правильно ли воткнут мк? Нормальное ПО не может такого выдавать. Вот например читается ли сигнатура мк? Как тактируется мк? Вернее тактирует ли программатор мк? Как настроены длительность импульса сброса и частота sck? Восстановить пароль Выслать повторно письмо для активации.

Проверка исправности микроконтроллера [avr]. Опции темы. Дата На данный раздел помимо Правил форума распространяются текже следующие правила: Прежде чем создать тему воспользуйтесь поиском или посмотрите в faq. Возможно на форуме уже есть ответ на ваш или близкий к вашему вопрос. В заголовке темы в квадратных скобках обозначьте используемое семейство микроконтроллера: [avr],[pic],[arm].

При создании темы с вопросом указывайте участок кода с ошибкой, версию компилятора, схемы подключения, fuse биты и прочие данные, которые помогут найти правильный ответ.

Для форматирования текста программ используйте кнопку код. Новое сообщение должно иметь прямое отношение к тематике этого раздела. Для флуда, просьб выполнить задание, поиска партнёров или исполнителей существуют свои разделы. Если вы заметили несовместимое с правилами сообщение, то можете уведомить об этом модератора раздела нажав кнопку у соответствующего сообщения.

Не использовать. Вы можете загрузить файл в это сообщение. Максимальный размер файла: 1мб. Включить смайлики? Включить подпись? По вопросам размещения рекламы пишите на vladimir sobaka vingrad.


Как проверить диодный мост мультиметром

Перепутал полярность Имя Запомнить? Перепутал полярность. Программатор в ближ. После 4,5 Ампер контроллер можно выбросить. Пики — ребята крепкие. Как-то раз по-запарке подал 12В на й, камень выдержал. Проверить — просто.

all-audio.pro – для проверки на исправность в системе, работоспособность микроконтроллера, корректность.

Проверка микросхемы мультиметром и специальным тестером

Вот и пришло время для первой прошивки. Данная прошивка является тестовой. Она не производит ни каких полезных действий, кроме дрыганья ножками по определенному алгоритму. Этой прошивкой можно проверить работоспособность всего микроконтроллера и портов ввода-вывода в частности. Чтобы проверить микроконтроллер необходимо загрузить прошивку и посмотреть, что происходит на ножках. Без резистора проверять не стоит — можно спалить порт ввода-вывода. Микроконтроллер работает от внутреннего генератора, поэтому нет необходимости во внешнем кварце. Ножки 9 и 10 подключение внешнего кварца не задействованы, на случай если там окажется внешний кварц.

Как проверить транзистор мультиметром

Хабр Geektimes Тостер Мой круг Фрилансим. У меня есть MSP Launchpad. На нем была уже зашита программа мигания светодиодом и она работала нормально. После этого я попробовал зашить туда другую программу, но она почему то не работала, хотя в IAR все биты регистров устанавливались, как надо. Я попробовал подать единицу на все пины и проверил мультиметром напряжение, на некоторых оно было в норме, а на большей части пинов нет, причем иногда неработающие начинали работать, загорался светодиод.

В этой статье будет рассказано о том, как проверить на работоспособность микросхему с использованием обычного мультиметра. Иногда определить причину неисправности довольно просто, а иногда на это уходит много времени, и в результате поломка так и остается невыясненной.

Как проверить исправность цифровых микросхем без выпайки их из платы

Я как-то баловался с fuse-битами на моей тиньке Attiny и был добаловался. Так как фьюзы я трогал только отвечающие за источник тактирующего сигнала мне повезло. Фьюз биты делятся на несколько групп:. Lock-фьюзы — отвечают за сохранность кода программы находящегося в микроконтроллере, так сказать предостварщает попытки скачать с микроконтроллера управляющую программу. Я так считаю что даже если скачать программу и попробовать её расшифровать то мало что получится, напрмиер стыкался с такими случаями в PHP.

022-Тестовая прошивка для AVR микроконтроллеров (проверка работоспособности портов).

Не все знают, как проверить микросхему на работоспособность мультиметром. Даже при наличии прибора не всегда удается это сделать. Бывает, выявить причину неисправности легко, но иногда на это уходит много времени, и в итоге нет никаких результатов. Приходится заменять микросхему. Проверка микросхем — это трудный, иногда невыполнимый процесс. Все дело в сложности микросхемы, которая состоит из огромного количества различных элементов.

Микроконтроллеры, АЦП, память и т.д. различных режимах, часть из которых может не использоваться в заведомо исправной схеме.

022-Тестовая прошивка для AVR микроконтроллеров (проверка работоспособности портов).

DOC Rev 1. Перед этим тестом обязательно убедитесь, что контакты разъема чисты и на них нет остатков флюса. О технологии монтажа печатных плат, можете прочитать здесь. Уделите этому особое внимание так как эта неисправность очень сложно тестируется и выражается в общей ненадежности работы программатора или его полной неработоспособности.

Ремонт автомагнитол

ВИДЕО ПО ТЕМЕ: Как проверить любой ШИМ (PWM) контроллер

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

Чтобы более осознанно понималь, как проверить диодный мост мультиметром, рекомендую прежде ознакомиться со статьей, как проверить диод. Диодный мост предназначен для выпрямления переменного напряжения в постоянное, а точнее говоря, в пульсирующее.

Как проверить микросхему на работоспособность мультиметром не выпаивая

Как проверить работает ли МК? Еще слишал, что у неработоспособного МК на всех виводах портов высокий уровень. А кто еще знает какие методы проверки МК? Мы принимаем формат Sprint-Layout 6! Экспорт в Gerber из Sprint-Layout 6. Если своя разработка, можно записать тестовую программку, провтейший вывод во все порта от 0 до и посмотреть сигналы.

Как мультиметром проверить на работоспособность микросхему?

Если он перегорел, прозвоните относительно корпуса на короткое замыкание элементы фильтра питания, усилитель ли мощность по шине питания , фильтрующие конденсаторы блоков. Перегорание обугливание данного резистора указывает на короткое замыкание в данном блоке. Также следует визуально проверить целостность электролитических конденсаторов. Сверху у данных конденсаторов есть так называемая насечка в виде креста.


022-Тестовая прошивка для AVR микроконтроллеров (проверка работоспособности портов).

Вот и пришло время для первой прошивки. Данная прошивка является тестовой. Она не производит ни каких полезных действий, кроме дрыганья ножками по определенному алгоритму. Этой прошивкой можно проверить работоспособность всего микроконтроллера и портов ввода-вывода в частности.
Чтобы проверить микроконтроллер необходимо загрузить прошивку и посмотреть, что происходит на ножках. «Смотреть» можно или мультиметром, или простым пробником – светодиод последовательно с резистором 300 Ом – 1 кОм. Без резистора проверять не стоит – можно спалить порт ввода-вывода. Уровни сигналов на ножках меняются с «1» через «Z»-состояние в «0» и обратно. «Z» состояние введено в последовательность для контроля работоспособности порта в режиме входа.

Тестовая прошивка для микроконтроллера ATMega48/88/168.
Алгоритм работы прошивки ATMega48/88/168 показан на картинке (микроконтроллер установлен на макетной плате ATMega48/88/168, описанной ранее).

Микроконтроллер работает от внутреннего генератора, поэтому нет необходимости во внешнем кварце. Ножки 9 и 10 (подключение внешнего кварца) не задействованы, на случай если там окажется внешний кварц. Также не задействованы ножки 1 (сброс) и 21(опорное напряжение для АЦП). Проверить работоспособность можно двумя способами (смотри рисунок) – смотреть изменение уровня сигналов относительно земли (GND) или относительно ножки питания (VCC).

022-M48.HEX V1.0 [277 bytes] — Тестовая прошивка для ATMega48/88/168

Фьюзы для тестовой прошивки ATMega48/88/168

Как прошить микроконтроллер >

Тестовая прошивка для микроконтроллера ATTiny2313.
Алгоритм работы прошивки ATTiny2313 показан на картинке (микроконтроллер установлен на макетной плате ATTiny2313, описанной ранее).

Микроконтроллер работает от внутреннего генератора, поэтому нет необходимости во внешнем. Ножки 4 и 5 (подключение внешнего кварца) не задействованы на случай если там окажется внешний кварц. Также не задействована ножка 1 (сброс). Проверить работоспособность можно двумя способами – смотреть изменение уровня сигналов относительно земли (GND) и относительно ножки питания (VCC).
022-T2313.HEX V1.0 [259 bytes] — Тестовая прошивка для ATTiny2313

Фьюзы для тестовой прошики ATTiny2313

Как прошить микроконтроллер >

Тестовая прошивка для микроконтроллера ATTiny13.
Алгоритм работы прошивки ATTiny13 показан на картинке (микроконтроллер установлен на макетной плате ATTiny13, описанной ранее).

Микроконтроллер работает от внутреннего генератора (внешний большая роскошь для этого микроконтроллера, поэтому даже не рассматриваем). Естественно, не задействована ножка 1 (сброс). Проверяем работоспособность так же, как и у предыдущих микроконтроллеров.
022-T13.HEX V1.0 [240 bytes] — Тестовая прошивка для ATTiny13

Фьюзы для тестовой прошики ATTiny13

Как прошить микроконтроллер >

Проверка работоспособности «Z»-состояния портов ввода-вывода.

«Z»-состояние это состояние когда ножка сконфигурирована на вход и на ней нет ни какого уровня (она как-бы болтается в воздухе ни к чему не подключена). Для того чтобы проконтролировать наличие такого состояния можно воспользоваться резисторным делителем. При уровне «1» на делителе будет напряжение питания +5v, при уровне «0» – земля 0v, а при «Z»-состоянии порт ввода-вывода перестанет вмешиваться в работу делителя и он поделит напряжение питания и мы получим +2.5v.

ФАЙЛЫ:
022-AVR-tests — Исходники тестовых прошивок

ATMega48/88/168, ATTiny13, ATTiny2313, Начинающим, Отладка

Как проверить сервопривод на работоспособность. Тестер сервоприводов

Сервопривод является стандартным компонентом для движущихся моделей и, кроме того, он используется и для других целей. Иногда может потребоваться проверить правильность работы сервопривода. Для этой цели и была разработана эта небольшая схема, которая позволяет быстро и легко протестировать практически все типы сервоприводов.

Кроме того, данным тостером можно проверить другие компоненты, которые могут быть подключены к системе дистанционного управления, например, контроллеры освещения или регуляторы двигателя. С помощью потенциометра ширина импульса может регулироваться от 0,9 мс до 2,1 мс, что соответствует диапазону регулирования от минус 120% до плюс 120%.

Схема состоит из 2 частей: собственно самого тестера сервопривода (DD1, R1, C3 и C4) и стабилизированного источника питания с напряжением +5В (DA1, C1 и C2).

Сторонний источник питания не обязателен, если подходящее напряжение уже доступно, например, от аккумулятора приемника с напряжением 4,8 В или 6 В. Однако в небольших моделях привод и вся электроника обычно питаются от одного элемента аккумулятора.

На схему питание подается через разъем К1. Напряжение должно быть в диапазоне от +5,5 В до +15 В, при этом хорошо подходят LiPo аккумуляторы с 2 или 3 ячейками (7,4 В или 11,1 В) или пакеты NiMH/NiCd с 5-10 ячейками.

Микросхема DA1 (L4940V5) — это так называемый стабилизатор с низким падением напряжения, которому достаточно входного напряжения 5,5 В для создания стабильных 5 В. Это было сделано специально, чтобы схема надежно работала в широком диапазоне входных напряжений.

Кроме того, здесь сознательно использовалась модель с током 1,5 А, так как питается не только сервотестер, но и сам сервопривод, подключенный к разъему K2. Причем в охлаждении стабилизатора нет необходимости, поскольку опыт показывает, что тестер работает в течение непродолжительного времени и стабилизатор не успевает нагреться.

Сервотестер очень прост и состоит в основном из микроконтроллера ATtiny13 (DD1) и потенциометра R1. В зависимости от положения на ползунке R1 снимается напряжение от 0 В до +5 В и подается на вход PB3 микроконтроллера.

Микроконтроллер с помощью АЦП преобразует это напряжение в значение от 0 до 255. В соответствии с этим значением на выводе PB4 генерируется импульсный сигнал для сервопривода, который на осциллографе выглядит следующим образом:

 

С помощью потенциометра R1 ширина импульса может быть изменена в диапазоне от 0,9 мс до 2,1 мс. Импульсный сигнал повторяется каждые 20 мс. В соответствии с установленной шириной импульса сервопривод принимает следующие положения:

Микроконтроллер может быть запрограммирован через ISP (разъем K3).

Конструкция

На верхнем рисунке показана готовая схема, которая была построена на макете размером 32 мм x 26 мм. В верхней части вы можете видеть регулятор напряжения с конденсаторами C1 и C2, потенциометр слева внизу и микроконтроллер справа. Микроконтроллер установлен панельку, чтобы плату можно было использовать в качестве устройства программирования для ATtiny13.

 

Напряжение подается с левой стороны платы через разъем JST. Таким образом, летная батарея вертолета может быть подключена напрямую. Остальные разъемы расположены на правой стороне платы: сверху подключается сервопривод, а снизу интерфейс для программирования. Черная метка между разъемами показывает, с какой стороны должна быть подключена линия заземления (черный провод сервомотора).

Как выглядит обратная сторона платы показано на нижнем рисунке. Как обычно, линии питания выполнены проводом диаметром 0,5 мм, для остальных использовалась медная проволока 0,3 мм.

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

Программное обеспечение

При программировании обязательно следует учитывать установку фьюзов. Они должны быть установлены следующим образом:

Программа микроконтроллера работает следующим образом: при включении питания сначала активируются порты ввода/вывода, АЦП, таймер и прерывание таймера.

Так как таймер должен формировать сервоимпульсы с малым шагом в диапазоне от 0,9 мс до 2,1 мс, то он работает на относительно быстрой частоте 150 кГц (отсчет примерно каждые 6,67 мкс).

Поскольку это 8-битный таймер, он переполняется после 256 тактовых импульсов (т.е. примерно через 1,707 мс) и снова начинает отсчет с 0. Чтобы расширить диапазон счета, при каждом переполнении запускается прерывание, а затем регистр микроконтроллера увеличивается на 1.

В результате получается 16-битный счетчик, который может не только генерировать сервоимпульсы длительностью до 2,1 мс, но также и интервал 20 мс, в котором сервоимпульсы должны регулярно повторяться.

После инициализации основная программа запускается в бесконечном цикле. В нем постоянно проверяется, достиг ли счетчик значения 3000, что соответствует уже упомянутому интервалу 20 мс. Если это происходит, то 16-битный счетчик снова устанавливается на 0, а импульсный выход PB4 устанавливается на высокий уровень (начало импульса).

Затем определяется положение потенциометра путем считывания значения аналого-цифрового преобразователя. Это значение, которое находится в диапазоне от 0 до 255, теперь должно быть преобразовано в значение, которое можно напрямую сравнить со счетчиком таймера. Таким образом, основной программный цикл может определить конец импульса и в нужный момент снова установить на выходе PB4 низкий уровень.

Положение потенциометра преобразуется в значение импульса в 2 этапа: сначала значение аналого-цифрового преобразователя умножается на 181, и используется только старший байт 16-битного результата. В результате получается значение от 0 до 180.

На втором этапе добавляется фиксированное значение 135, так что конечный результат представляет собой диапазон значений от 135 до 315. По отношению к циклу таймера примерно 6,67 мкс — это соответствует желаемому диапазону импульсов от 0,9 мс до 2,1 мс.

Основная программа теперь постоянно сравнивает текущее показание счетчика с только что определенным значением импульса и, когда это значение достигается, переключает выход PB4 обратно на низкий уровень (конец импульса).

Скачать прошивку (11,2 KiB, скачано: 125)

Компания Renesas представила автомобильные микроконтроллеры RL78/F24 и RL78/F23

Японская компания Renesas Electronics анонсировала выпуск 16-разрядных микроконтроллеров RL78/F24 и RL78/F23, предназначенных для автомобилей. Они рассчитаны на работу датчиками и приводами, и интересны тем, что позиционируются как средство поддержки развития передовых технологий в архитектуре электроники и электротехники (E/E) следующего поколения.

С расширением архитектуры E/E путем включения приложений управления зонами и доменами, механизмы управления развиваются, охватывая управление фарами, окнами и зеркалами, двигателями насосов и вентиляторов, и работу с множеством датчиков. Как утверждается, в перспективе высокоскоростное и безопасное соединение с контроллерами зон и домена будет иметь решающее значение для периферийных электронных блоков управления (ЭБУ). Микроконтроллеры Renesas нового поколения RL78/F24 и RL78/F23 отвечают меняющимся требованиям технологий для управления исполнительными механизмами и датчиками с повышенной безопасностью, широкими возможностями подключения и возможностями функциональной безопасности. Новые устройства поддерживают протокол высокоскоростной связи CAN FD (RL78 / F24) и безопасность EVITA-Light и оптимизированы для систем, нацеленных на уровни ASIL-B в соответствии со стандартом функциональной безопасности ISO 26262.

Микроконтроллеры работают на частоте 40 МГц. На уровне выводов они совместимы с микроконтроллерами RL78/F14 и RL78/F13. Объем встроенной флэш-памяти равен 128 или 256 КБ. Микроконтроллеры гарантированно сохраняют работоспособность при температурах до 150°C. Они выпускаются в нескольких вариантах корпусов: от компактного 32-контактного QFN размерами 5 х 5 мм до 100-контактного QFP.

Образцы микроконтроллеров RL78/F24 и RL78/F23 будут доступны с апреля 2022 года, а их серийное производство запланировано на вторую половину 2023 года. В разработке сейчас находится плата RL78/F24 Target и стартовый ознакомительный комплект.

Как проверить ШИМ контроллер мультиметром и с применением тестера радиодеталей

Широтно–импульсные преобразователи являются конструктивной частью импульсных блоков питания электронных устройств. Разберем, как проверить ШИМ контроллер с применением мультиметра, на примере материнской платы компьютера.

Проверка на материнской плате

Итак, при включении питания платы, срабатывает защита. В первую очередь, необходимо проверить мультиметром сопротивление плеч стабилизатора.

Для этих целей также может быть использован тестер радиодеталей. Если одно из них показывает короткое замыкание, то есть, измеренное сопротивление составляет меньше 1 Ома, значит, пробит один из ключевых полевых транзисторов.

Выявление пробитого транзистора в случае, если стабилизатор однофазный, не составляет труда – неисправный прибор при проверке мультиметром показывает короткое замыкание. Если схема стабилизатора многофазная, а именно так питается процессор, имеет место параллельное включение транзисторов. В этом случае, определить поврежденный прибор можно двумя путями:

  1. произвести демонтаж транзистора и проверить мультиметром сопротивление между его выводами на предмет пробоя;
  2. не выпаивая транзисторы, замерить и сравнить сопротивление между затвором и истоком в каждой из фаз преобразователя. Поврежденный участок определяется по более низкому значению сопротивления.

Второй способ работает не во всех случаях. Если пробитый элемент определить не удалось, придется все же выпаять транзистор.

Далее производится замена поврежденного транзистора, а также, установка на место всех выпаянных в процессе диагностики радиоэлементов. После этого можно попытаться запустить плату.

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

Неисправности ШИМ контроллера могут проявляться так же, как и пробой мосфетов, то есть уходом блока питания в защиту. При этом проверка самих транзисторов на пробой результата не дает.

Кроме этого, следствием нарушения функций ШИМ контроллера может быть отсутствие выходного напряжения или его несоответствие номинальной величине. Для проверки ШИМ контроллера следует вначале изучить его даташит. Наличие высокочастотного напряжения в импульсном режиме, при отсутствии осциллографа, можно определить, используя тестер кварцев на микроконтроллере.

Признаки неисправности, их устранение

Перейдем к рассмотрению конкретных признаков неисправностей ШИМ контроллера.

Остановка сразу после запуска

Импульсный модулятор запускается, но сразу останавливается. Возможные причины: разрыв цепи обратной связи; блок питания перегружен по току; неисправны фильтровые конденсаторы на выходе.

Поиск проблемы: осмотр платы, поиск видимых внешних повреждений; измерение мультиметром напряжения питания микросхемы, напряжения на ключах (на затворах и на выходе), на выходных емкостях. В режиме омметра мультиметром надо измерить нагрузку стабилизатора, сравнить с типовым значением для аналогичных схем.

Импульсный модулятор не стартует

Возможные причины: наличие запрещающего сигнала на соответствующем входе. Информацию следует искать в даташите соответствующей микросхемы. Неисправность может быть в цепи питания ШИМ контроллера, возможно внутренне повреждение в самой микросхеме.

Шаги по определению неисправности: наружный осмотр платы, визуальный поиск механических и электрических повреждений. Для проверки мультиметром делают замер напряжений на ножках микросхемы и проверку их соответствия с данными в даташит, в случае необходимости, надо заменить ШИМ контроллер.

Проблемы с напряжением

Выходное напряжение существенно отличается от номинальной величины. Это может происходить по следующим причинам: разрыв или изменение сопротивления в цепи обратной связи; неисправность внутри контроллера.

Поиск неисправности: визуальное обследование схемы; проверка уровней управляющих и выходных напряжений и сверка их значений с даташит. Если входные параметры в норме, а выход не соответствует номинальному значению – замена ШИМ контроллера.

Отключение блока питания защитой

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

В этом случае нужно произвести замер сопротивлений между затвором и истоком ключей в каждой фазе. Заниженное значение сопротивления может указывать на неисправность драйвера. При необходимости делается замена драйверов.

Подготовка к первому тестированию платы микроконтроллера

Вы можете использовать IDT для FreeRTOS для тестирования переноса интерфейсов FreeRTOS. После того, как у вас есть портировали интерфейсы FreeRTOS для драйверов устройств вашей платы, вы используете AWS IoT Device Tester для запуска квалификационные испытания вашей платы микроконтроллера.

Добавить слои переноса библиотеки

Чтобы перенести FreeRTOS на свое устройство, следуйте инструкциям в Руководстве по переносу FreeRTOS.

Настройте свои учетные данные AWS

Вам необходимо настроить свои учетные данные AWS для AWS IoT Device Tester для связи с AWS. Облако.Дополнительные сведения см. в разделе Настройка AWS. Полномочия и регион для развития. Необходимо указать действительные учетные данные AWS. в devicetester_extract_location /devicetester_afreertos_ [win|mac|linux] /configs/config.json Файл конфигурации.

Создайте пул устройств в IDT для FreeRTOS

Тестируемые устройства организованы в пулы устройств. Каждый пул устройств состоит из одного или больше одинаковых устройств.Вы можете настроить IDT для FreeRTOS для тестирования одного устройства в пуле. или несколько устройств в пуле. Чтобы ускорить процесс квалификации, IDT для FreeRTOS может тестовые устройства с одинаковыми характеристиками параллельно. Он использует циклический метод для выполнить другую тестовую группу на каждом устройстве в пуле устройств.

Вы можете добавить одно или несколько устройств в пул устройств, отредактировав устройств раздел шаблона device.json в конфигах папка.

Все устройства в одном пуле должны иметь одинаковые технические характеристики и артикул.

Чтобы включить параллельные сборки исходного кода для разных групп тестирования, IDT для FreeRTOS копирует исходный код в папку результатов внутри извлеченной папки IDT для FreeRTOS. путь к исходному коду в команде сборки или прошивки должен указываться с помощью testdata.sourcePath или sdkPath переменная. IDT для FreeRTOS заменяет эта переменная с временным путем к скопированному исходному коду.Для получения дополнительной информации см. IDT для переменных FreeRTOS.

Ниже приведен пример файла device.json , используемого для создания пул устройств с несколькими устройствами.

  [
    {
        "id": " идентификатор пула ",
        "артикул": " артикул ",
        "Особенности": [
            {
                "имя": "WI-FI",
                "значение": "Да | Нет"
            },
            {
                "имя": "Сотовый",
                "значение": "Да | Нет"
            },
            {
                "имя": "ОТА",
                "значение": "Да | Нет",
                "конфиги": [
                    {
                        "имя": "OTADataPlaneProtocol",
                        "значение": "HTTP | MQTT"
                    }
                ]
            },
            {
                "имя": "БЛЕ",
                "значение": "Да | Нет"
            },
            {
                "имя": "TCP/IP",
                "value": "На чипе | Выгружено | Нет"
            },
            {
                "имя": "TLS",
                "значение": "Да | Нет"
            },
            {
                "имя": "PKCS11",
                "значение": "RSA | ECC | Оба | Нет"
            },
            {
                "имя": "Подготовка ключей",
                "value": "Импортировать | Встроено | Нет"
            }
        ],

        "устройства": [
          {
            "id": " идентификатор устройства ",
            "подключение": {
              "протокол": "уарт",
              "serialPort": "/dev/tty  *  "
            },
            ************Удалите раздел ниже, если устройство не поддерживает генерацию встроенного ключа***************
            "secureElementConfig": {
              "publicKeyAsciiHexFilePath": " абсолютный-путь-к/открытому-ключу-txt-файлу: содержит-шестнадцатеричные-байты-общего-ключа-извлеченного-из-встроенного-закрытого-ключа ",
              "secureElementSerialNumber": " безопасный-элемент-serialNo-значение ",
              «Предварительно подготовлено»: «Да | Нет»
            },
            ******************************************************* ******************************************************* ******
            "идентификаторы": [
              {
                "имя": "серийный номер",
                "значение": " серийный номер без значения "
              }
            ]
          }
        ]
    }
]  

В устройстве используются следующие атрибуты.файл json :

идентификатор

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

артикул

Буквенно-цифровое значение, однозначно идентифицирующее тестируемую плату.Артикул используется для отслеживания квалифицированных досок.

Если вы хотите разместить свою плату в Каталоге устройств партнеров AWS, номер SKU, который вы указанный здесь должен соответствовать SKU, который вы используете в процессе листинга.

характеристики

Массив, содержащий поддерживаемые функции устройства. AWS IoT Device Tester использует это информацию для выбора квалификационных тестов для запуска.

Поддерживаемые значения:

TCP/IP

Указывает, поддерживает ли ваша плата стек TCP/IP и поддерживается ли он. на кристалле (MCU) или перенесены в другой модуль. TCP/IP требуется для квалификация.

WI-FI

Указывает, поддерживает ли ваша плата Wi-Fi. Должен быть установлен на Нет , если для Сотовая связь установлено значение Да .

Сотовая связь

Указывает, поддерживает ли ваша плата сотовую связь.Должен быть установлен на Нет , если для WIFI установлено значение Да . Когда это установлено значение Да , будет выполнен тест FullSecureSockets использование инстансов AWS t2.micro EC2, что может привести к дополнительным затратам для вашего учетная запись. Дополнительные сведения см. в разделе Цены на Amazon EC2.

TLS

Указывает, поддерживает ли ваша плата TLS.TLS требуется для квалификация.

ПККС11

Указывает алгоритм шифрования с открытым ключом, поддерживаемый платой. Для квалификации требуется PKCS11. Поддерживаемые значения: ECC , RSA , Оба и . Оба указывает, что плата поддерживает как ECC , так и RSA . алгоритмы.

Подготовка ключей

Указывает метод записи доверенного сертификата клиента X.509 на ваш доска. Допустимые значения: Import , Onboard и . Для квалификации требуется подготовка ключа.

  • Используйте Import , если ваша доска позволяет импортировать закрытые ключи.IDT создаст закрытый ключ и встроит его в исходный код FreeRTOS. код.

  • Используйте Onboard , если ваша плата поддерживает встроенный закрытый ключ генерация (например, если на вашем устройстве есть защищенный элемент, или если вы предпочитаете генерировать собственную пару ключей устройства и сертификат). Убедись, что ты добавить элемент secureElementConfig в каждое из устройств разделы и указать абсолютный путь к файлу открытого ключа в поле publicKeyAsciiHexFilePath .

  • Используйте Нет , если ваша плата не поддерживает подготовку ключей.

ОТА

Указывает, поддерживает ли ваша плата функцию обновления по беспроводной сети (OTA). Атрибут OtaDataPlaneProtocol указывает, какая плоскость данных OTA протокол, который поддерживает устройство.Атрибут игнорируется, если функция OTA не поддерживается устройством. При выборе «Оба» тест OTA время выполнения увеличивается из-за запуска как MQTT, HTTP, так и смешанного тесты.

Начиная с IDT v4.1.0, OtaDataPlaneProtocol принимает только HTTP и MQTT в качестве поддерживаемых значений.

БЛЭ

Указывает, поддерживает ли ваша плата Bluetooth Low Energy (BLE).

устройства.id

Определяемый пользователем уникальный идентификатор тестируемого устройства.

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

Протокол связи, используемый для связи с этим устройством. Поддерживаемое значение: уарт .

устройства.connectivity.serialPort

Последовательный порт главного компьютера, используемый для подключения к устройствам, проверено.

devices.secureElementConfig.PublicKeyAsciiHexFilePath

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

Пример формата:

  3059 3013 0607 2а86 48се 3д02 0106 082а
8648 ce3d 0301 0703 4200 04cd 6569 ceb8
1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac
6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0
41b7 345c e746 1046 228e 5a5f d787 d571
dcb2 4e8d 75b3 2586 e2cc 0c  

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

Пример команды для .der открытый ключ для создания шестнадцатеричного файла:

  xxd -p pubkey.der > outFile  

Если ваш открытый ключ имеет формат .pem, вы можете извлечь часть, закодированную в base64, декодируйте его в двоичный формат, а затем закодируйте в шестнадцатеричном формате для создания шестнадцатеричного файла.

Например, используйте эти команды для создания шестнадцатеричного файла для общедоступного .pem-файла. ключ:

  1. Удалите закодированную в base64 часть ключа (удалит верхний и нижний колонтитулы) и сохраните его в файле, например, назовите его base64key , запустите этот команда, чтобы преобразовать его в .формат:

      base64 — декодировать base64key > pubkey.der  
  2. Запустите команду xxd , чтобы преобразовать его в шестнадцатеричный формат.

      xxd -p pubkey.der > outFile  
devices.secureElementConfig.SecureElementSerialNumber

(Необязательно) Серийный номер защитного элемента.Укажите это поле, когда серийный номер распечатывается вместе с открытым ключом устройства при запуске FreeRTOS демонстрационный/тестовый проект.

devices.secureElementConfig.preProvisioned

(Необязательно) Установите значение «Да», если на устройстве есть предварительно подготовленный элемент безопасности с заблокированные учетные данные, которые не могут импортировать, создавать или уничтожать объекты. Этот конфигурация вступает в силу только тогда, когда имеет функции . KeyProvisioning установлен на «Встроенный», вместе с PKCS11 установлен на «ЭКС».

идентификаторы

(Необязательно) Массив произвольных пар «имя-значение». Вы можете использовать эти значения в команды build и flash, описанные в следующем разделе.

Настройка параметров сборки, прошивки и тестирования

Чтобы IDT для FreeRTOS автоматически создавала и запускала тесты на вашу плату, вы должны настроить IDT для запуска команд сборки и прошивки для вашего оборудования.Сборка и прошивка параметры команды настраиваются в файле шаблона userdata.json находится в папке config .

Настройка параметров для устройств тестирования

Настройки сборки, прошивки и тестирования выполняются в файл configs/userdata.json . Мы поддерживаем настройку Echo Server по загрузка сертификатов и ключей клиента и сервера в customPath . Дополнительные сведения см. в разделе Настройка эхо-сервер в Руководстве по переносу FreeRTOS .Следующий JSON пример показывает, как можно настроить IDT для FreeRTOS для тестирования нескольких устройств:

  {
    "sourcePath": "/абсолютный-путь-к/freertos ",
    "vendorPath": "{{testData.sourcePath}}/vendors/  имя-вендора  /boards/  имя-платы  ",
    // *********** Блок sdkConfiguration ниже необходим, если вы не используете немодифицированный репозиторий FreeRTOS по умолчанию.
    // Другими словами, если вы используете немодифицированный репозиторий FreeRTOS по умолчанию, удалите этот блок**************
    "SDKConfiguration": {
        "имя": " SDK-имя ",
        "версия": " SDK-версия ",
        "путь": "/абсолютный-путь-к/SDK "
    },
    "строительный инструмент": {
        "имя": " ваше-имя-инструмента-сборки ",
        "версия": " версия вашего инструмента сборки ",
        "команда": [
            "  {{конфиг.idtRootPath}}/относительный-путь-к/build-parallel.sh  {{testData.sourcePath}} {{enableTests}}"
        ]
    },
    "флэштул": {
        "имя": " ваше-имя-флэш-инструмента ",
        "версия": " версия вашего flash-инструмента ",
        "команда": [
            "/  {{config.idtRootPath}}/относительный-путь-к/flash-parallel.sh  {{testData.sourcePath}} {{device.connectivity.serialPort}} {{buildImageName}}"
        ],
        "buildImageInfo": {
            "testsImageName": " тесты-имя-изображения ",
            "demosImageName": "  demos-image-name  "
        }
    },
    "testStartDelayms": 0,
    "клиентвификонфиг": {
        "wifiSSID": " ssid ",
        "wifiPassword": " пароль ",
        "wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
    },
    "testWifiConfig": {
        "wifiSSID": " ssid ",
        "wifiPassword": " пароль ",
        "wifiSecurityType": "eWiFiSecurityOpen | eWiFiSecurityWEP | eWiFiSecurityWPA | eWiFiSecurityWPA2 | eWiFiSecurityWPA3"
    },
    //**********
    //Этот раздел используется для запуска эхо-сервера на основе метода генерации сертификата сервера,
    //Если для certificateGenerationMethod задано значение Automatic, укажите eccCurveFormat для создания сертификата и ключа на основе формата кривой,
    //Когда certificateGenerationMethod установлен как Custom, укажите certificatePath и PrivateKeyPath, которые будут использоваться для запуска эхо-сервера
    //**********
    "echoServerCertificateConfiguration": {
      "certificateGenerationMethod": "Автоматически | Пользовательский",
      "пользовательский путь": {
          "clientCertificatePath": " /path/to/clientCertificate ",
          "clientPrivateKeyPath": " /path/to/clientPrivateKey ",
          "serverCertificatePath": " /path/to/serverCertificate ",
          "serverPrivateKeyPath": " /path/to/serverPrivateKey "
      },
    "eccCurveFormat": "P224 | P256 | P384 | P521"
    },
    "эхосерверконфигуратион": {
        "securePortForSecureSocket":  33333  , // Безопасный TCP-порт, используемый тестом SecureSocket.Значение по умолчанию — 33333. Убедитесь, что настроенный порт не заблокирован брандмауэром или вашей корпоративной сетью.
        "insecurePortForSecureSocket":  33334  , // Небезопасный TCP-порт, используемый тестом SecureSocket. Значение по умолчанию — 33334. Убедитесь, что настроенный порт не заблокирован брандмауэром или вашей корпоративной сетью.
        "insecurePortForWiFi":  33335  // Небезопасный TCP-порт, используемый тестом Wi-Fi. Значение по умолчанию — 33335. Убедитесь, что настроенный порт не заблокирован брандмауэром или вашей корпоративной сетью.
    },
    "атаконфигуратион": {
        "otaFirmwareFilePath": "{{testData.sourcePath}}/  относительный путь к/ota-образу, сгенерированному в процессе сборки  ",
        "deviceFirmwareFileName": " ota-имя-образа-на-устройстве ",
        "otaDemoConfigFilePath": "{{testData.sourcePath}}/  относительный-путь-к/ota-demo-config-header-file  ",
        "codeSigningConfiguration": {
            "signingMethod": "AWS | Пользовательский",
            "signerHashingAlgorithm": "SHA1 | SHA256",
            "signerSigningAlgorithm": "RSA | ECDSA",
            "signerCertificate": "arn:  раздел  :  служба  :  регион  :  идентификатор учетной записи  :  ресурс  :  квалификатор  |
            "signerCertificateFileName": " signerCertificate-file-name ",
            "compileSignerCertificate": логическое значение,
            // ************Используйте signerPlatform, если вы выбрали aws для signingMethod***************
            "signerPlatform": "AmazonFreeRTOS-Default | AmazonFreeRTOS-TI-CC3220SF",
            "untrustedSignerCertificate": "arn:  раздел  :  служба  :  регион  :  идентификатор учетной записи  :  тип ресурса  :  ресурс  :  квалификатор  ",
            // ************Используйте signCommand, если вы выбрали пользовательский метод для подписи***************
            "signCommand": [
                "/ абсолютный-путь-к /знак.ш {{inputImageFilePath}} {{outputSignatureFilePath}}"
            ]
        }
    },
    // ************* Удалите раздел ниже, если вы не настраиваете CMake **************
    "cmakeConfiguration": {
        "boardName": " имя-платы ",
        "vendorName": " имя поставщика ",
        "compilerName": " имя-компилятора ",
        "frToolchainPath":  "/path/to/freertos/toolchain ",
        "cmakeToolchainPath": " /path/to/cmake/toolchain "
    },
    "freertosFileConfiguration": {
        "обязательный": [
            {
                "configName": "pkcs11Config",
                "filePath": "{{testData.sourcePath}}/vendors/  имя поставщика  /boards/  имя платы  /aws_tests/config_files/core_pkcs11_config.h"
            },
            {
                "configName": "pkcs11TestConfig",
                "filePath": "{{testData.sourcePath}}/vendors/  имя поставщика  /boards/  имя платы  /aws_tests/config_files/iot_test_pkcs11_config.h"
            }
        ],
        "необязательный": [
            {
                "configName": "otaAgentTestsConfig",
                "filePath": "{{testData.sourcePath}}/vendors/  имя поставщика  /boards/  имя платы  /aws_tests/config_files/ota_config.h"
            },
            {
                "configName": "otaAgentDemosConfig",
                "filePath": "{{testData.sourcePath}}/vendors/  имя-вендора  /boards/  имя-платы  /aws_demos/config_files/ota_config.h"
            },
            {
                "configName": "otaDemosConfig",
                "filePath": "{{testData.sourcePath}}/vendors/  имя-вендора  /boards/  имя-платы  /aws_demos/config_files/ota_demo_config.час"
            }
        ]
    }
}  

Ниже перечислены атрибуты, используемые в userdata.json :

исходный путь

Путь к корню портированного исходного кода FreeRTOS. Для параллельного тестирования с SDK, sourcePath можно установить с помощью {{данные пользователя.sdkConfiguration.path}} заполнитель. Например:

  { "sourcePath": "{{userData.sdkConfiguration.path}}/  freertos  " }  
путь поставщика

Путь к специфичному для поставщика коду FreeRTOS. Для серийных испытаний vendorPath можно задать как абсолютный путь. Например:

  { "vendorPath": "C:/  путь к freertos  /vendors/espressif/boards/  esp32  " }  

Для параллельного тестирования vendorPath можно задать с помощью {{тестовые данные.sourcePath}} местозаполнитель. Например:

  { "vendorPath": "{{testData.sourcePath}}/vendors/espressif/boards/esp32" }  

Переменная vendorPath необходима только при работе без SDK, иначе его можно удалить.

При параллельном запуске тестов без SDK {{testData.sourcePath}} заполнитель должен использоваться в vendorPath , buildTool , flashTool полей.При запуске теста с одним устройством необходимо использовать абсолютные пути в vendorPath , buildTool , flashTool полей. При работе с SDK необходимо использовать заполнитель {{sdkPath}} в sourcePath , buildTool и flashTool команды.

конфигурация SDK

Если вы соответствуете требованиям FreeRTOS с любыми изменениями файлов и папок структура сверх того, что требуется для переноса, вам нужно будет настроить Информация SDK в этом блоке.Если вы не соответствуете требованиям с портированной FreeRTOS внутри SDK, то вам следует полностью опустить этот блок.

sdkConfiguration.name

Имя SDK, который вы используете с FreeRTOS. Если вы не используете SDK, тогда весь блок sdkConfiguration следует опустить.

sdkConfiguration.версия

Версия SDK, которую вы используете с FreeRTOS. Если вы не используете SDK, то весь блок sdkConfiguration должен быть опущено.

sdkConfiguration.path

Абсолютный путь к вашему каталогу SDK, содержащему ваш код FreeRTOS.Если вы не используете SDK, тогда весь блок sdkConfiguration следует опустить.

инструмент сборки

Полный путь к вашему скрипту сборки (.bat или .sh), который содержит команды для создайте свой исходный код. Все ссылки на путь исходного кода в команде сборки необходимо заменить переменной AWS IoT Device Tester {{testdata.исходный путь}} и ссылки на путь SDK следует заменить на {{sdkPath}} . Используйте заполнитель {{config.idtRootPath}} для ссылки на абсолютный или относительный путь IDT.

testStartDelayms

Указывает, сколько миллисекунд будет ждать средство запуска тестов FreeRTOS перед запуском. для запуска тестов.Это может быть полезно, если тестируемое устройство начинает выводить важную тестовую информацию до того, как IDT сможет подключиться и начать регистрацию к сети или другие задержки. Максимально допустимое значение составляет 30000 мс (30 секунд). Этот значение применимо только к тестовым группам FreeRTOS и не применимо к другим тестовым группам. группы, которые не используют средство запуска тестов FreeRTOS, например тесты OTA.

FlashTool

Полный путь к вашему флеш-скрипту (.sh или .bat), который содержит команды flash для вашего устройства. Все ссылки на путь к исходному коду в команде flash должны быть заменен IDT для переменной FreeRTOS {{testdata.sourcePath}} и все ссылки на ваш путь SDK должны быть заменены IDT для переменной FreeRTOS {{sdkPath}} . Используйте заполнитель {{config.idtRootPath}} . для ссылки на абсолютный или относительный путь IDT.

buildImageInfo
testImageName

Имя файла, созданного командой сборки при сборке тесты из исходный код freertos /тесты папка.

demosImageName

Имя файла, созданного командой сборки при сборке тесты из исходный код freertos /демо папка.

клиент WifiConfig

Конфигурация Wi-Fi клиента.Для тестирования библиотеки Wi-Fi требуется, чтобы плата MCU подключиться к двум точкам доступа. (Две точки доступа могут быть одинаковыми.) Это атрибут настраивает параметры Wi-Fi для первой точки доступа. Некоторые из Тестовые примеры Wi-Fi предполагают, что точка доступа имеет некоторую безопасность и не открыта. Убедитесь, что обе точки доступа находятся в той же подсети, что и главный компьютер. работает ИДТ.

wifi_ssid

SSID Wi-Fi.

wifi_пароль

Пароль Wi-Fi.

wifiSecurityType

Используемый тип безопасности Wi-Fi. Одно из значений:

  • eWiFiSecurityOpen

  • eWiFiSecurityWEP

  • eWiFiSecurityWPA

  • eWiFiSecurityWPA2

  • eWiFiSecurityWPA3

Если ваша плата не поддерживает Wi-Fi, вы все равно должны включить Раздел clientWifiConfig на вашем устройстве .json файл, но вы можете опустить значения для этих атрибутов.

testWifiConfig

Тестовая конфигурация Wi-Fi. Для тестирования библиотеки Wi-Fi требуется, чтобы плата MCU подключиться к двум точкам доступа. (Две точки доступа могут быть одинаковыми.) Это Атрибут настраивает параметр Wi-Fi для второй точки доступа. Некоторые из Тестовые примеры Wi-Fi предполагают, что точка доступа имеет некоторую безопасность и не открыта.Убедитесь, что обе точки доступа находятся в той же подсети, что и главный компьютер. работает ИДТ.

wifiSSID

SSID Wi-Fi.

пароль Wi-Fi

Пароль Wi-Fi.

wifiSecurityType

Используемый тип безопасности Wi-Fi. Одно из значений:

  • eWiFiSecurityOpen

  • eWiFiSecurityWEP

  • eWiFiSecurityWPA

  • eWiFiSecurityWPA2

  • eWiFiSecurityWPA3

Если ваша плата не поддерживает Wi-Fi, вы все равно должны включить Раздел testWifiConfig на вашем устройстве .json файл, но вы можете опустить значения для этих атрибутов.

эхосерверсертификатконфигуратион

Заполнитель генерации сертификата настраиваемого эхо-сервера для безопасного тесты сокетов. Это поле обязательный.

метод генерации сертификата

Указывает, генерируется ли сертификат сервера автоматически или предоставляется вручную.

пользовательский путь

Если certificateGenerationMethod — «Пользовательский», certificatePath и privateKeyPath являются обязательный.

Путь сертификата

Указывает путь к файлу сертификата сервера.

privateKeyPath

Указывает путь к файлу для закрытого ключа.

eccCurveFormat

Указывает формат кривой, поддерживаемый платой.Требуется, когда PKCS11 имеет значение «ecc» в device.json . Допустимые значения: «P224», «P256», «P384» или «P521».

эхосерверконфигуратион

Настраиваемые порты эхо-сервера для тестов WiFi и защищенных сокетов. Это поле является необязательным.

SecurePortForSecureSocket

Порт, который используется для настройки эхо-сервера с TLS для безопасного проверка сокетов.Значение по умолчанию — 33333. Убедитесь, что настроенный порт не заблокирован брандмауэром или вашей корпоративной сетью.

инсекурепортфорсекуресокет

Порт, который используется для настройки эхо-сервера без TLS для безопасного проверка сокетов. Значение по умолчанию, используемое в тесте, — 33334. Убедитесь, что порт настроенный не блокируется брандмауэром или вашей корпоративной сетью.

insecurePortForWiFi

Порт, который используется для настройки эхо-сервера без TLS для теста WiFi. значение по умолчанию, используемое в тесте, — 33335. Убедитесь, что настроенный порт не заблокирован брандмауэром или вашей корпоративной сетью.

конфигурация ota

Конфигурация ОТА.[Необязательно]

otaFirmwareFilePath

Полный путь к OTA-образу, созданному после сборки. Например, {{тестовые данные.sourcePath}}/ относительный-путь/к/ota/изображению/из/источника/корень .

устройствоFirmwareFileName

Полный путь к файлу на устройстве MCU, где находится прошивка OTA. Некоторые устройства не используют это поле, но вы все равно должны указать значение.

otaDemoConfigFilePath

Полный путь к aws_demo_config.h , найдено в af-source /vendors/vendor/boards/board/aws_demos/config_files/ . Эти файлы включены в шаблон кода переноса, предоставляемый FreeRTOS.

codeSigningConfiguration

Конфигурация подписи кода.

метод подписи

Метод подписи кода.Возможные значения: AWS или Пользовательский .

Для регионов Пекин и Нинся используйте Custom . Код АВС подписывание не поддерживается в этих регионах.

подписывающийАлгоритм хеширования

Алгоритм хеширования, поддерживаемый устройством.Возможные значения SHA1 или SHA256 .

подписывающий алгоритм подписи

Алгоритм подписи, поддерживаемый устройством. Возможные значения RSA или ECDSA .

Сертификат подписавшего

Доверенный сертификат, используемый для OTA.

Для метода подписи кода AWS используйте имя ресурса Amazon (ARN) для доверенный сертификат, загруженный в диспетчер сертификатов AWS.

Для метода подписи пользовательского кода используйте абсолютный путь к подписавшему файл сертификата.

Дополнительные сведения о создании доверенного сертификата см. в разделе Создание сертификата для подписи кода.

signerCertificateFileName

Имя файла сертификата подписи кода на устройстве.Это значение должно совпадать с именем файла, которое вы указали при запуске aws acm. команда импортного сертификата .

Дополнительные сведения см. в разделе Создание сертификата подписи кода.

compileSignerCertificate

Установите значение true , если проверка подписи лица, сертификат не подготовлен или не прошит, поэтому он должен быть скомпилирован в проект.AWS IoT Device Tester извлекает доверенный сертификат и компилирует его в aws_codesigner_certifiate.h .

untrustedSignerCertificate

ARN или путь к файлу для второго сертификата, используемого в некоторых тестах OTA в качестве ненадежного сертификата. Дополнительные сведения о создании сертификата см. Создайте сертификат подписи кода.

SignerPlatform

Алгоритм подписи и хеширования, который AWS Code Signer использует при создание задания обновления OTA. В настоящее время возможные значения для этого поля: AmazonFreeRTOS-TI-CC3220SF и AmazonFreeRTOS-по умолчанию .

Если вам нужно SHA256 | RSA или SHA1 | ECDSA для вашей конфигурации, свяжитесь с нами для получения дополнительной информации. поддерживать.

Настройте signCommand , если вы выбрали Custom для метод подписи .

signCommand

Команда, используемая для подписи пользовательского кода. Вы можете найти шаблон в каталоге /configs/script_templates .

Два заполнителя {{inputImageFilePath}} и В команде требуется {{outputSignatureFilePath}} . {{inputImageFilePath}} — это путь к файлу образа, созданного ИДТ для подписания. {{outputSignatureFilePath}} — это путь к файлу подпись, которая будет сгенерирована скриптом.

cmakeConfiguration

Конфигурация CMake [Необязательно]

Для выполнения тестовых случаев CMake необходимо указать имя платы, имя поставщика и либо frToolchainPath , либо имя_компилятора .Вы можете также укажите cmakeToolchainPath , если у вас есть собственный путь к CMake набор инструментов.

имя_платы

Имя тестируемой платы. Название доски должно совпадать с имя папки под путь/к/афр/источник/код /поставщики/ поставщик /платы/ плата .

имя поставщика

Имя поставщика тестируемой платы. Продавец должен быть таким же, как имя папки под путь/к/афр/источник/код /vendors/ поставщик .

имя_компилятора

Имя компилятора.

frToolchainPath

Полный путь к инструментальной цепочке компилятора

cmakeToolchainPath

Полный путь к цепочке инструментов CMake. Это поле опционально

freertosFileConfiguration

Конфигурация файлов FreeRTOS, которую IDT изменяет перед запуском тесты.

требуется

В этом разделе указаны необходимые тесты, файлы конфигурации которых вы переместили, например, PKCS11, TLS и т. д.

имя_конфигурации

Имя настраиваемого теста.

путь к файлу

Абсолютный путь к файлам конфигурации внутри freertos репо. Использовать переменная {{testData.sourcePath}} для определения дорожка.

опционально

В этом разделе указаны необязательные тесты, файлы конфигурации которых вы переместили, например OTA, WiFi и т.д.

имя_конфигурации

Имя настраиваемого теста.

путь к файлу

Абсолютный путь к файлам конфигурации внутри freertos репо.Использовать переменная {{testData.sourcePath}} для определения дорожка.

Для выполнения тестовых случаев CMake необходимо указать имя платы, имя поставщика и либо afrToolchainPath , либо имя_компилятора . Вы можете также укажите cmakeToolchainPath , если у вас есть собственный путь к CMake набор инструментов.

IDT для переменных FreeRTOS

Команды для создания кода и прошивки устройства могут потребовать подключения или другую информацию о ваших устройствах для успешной работы. AWS IoT Device Tester позволяет ссылаться информация об устройстве во флэш-памяти и командах сборки с использованием JsonPath. Используя простой JsonPath выражения, вы можете получить необходимую информацию, указанную в вашем файл device.json .

Переменные пути

IDT для FreeRTOS определяет следующие переменные пути, которые можно использовать в команде строки и файлы конфигурации:

{{testData.sourcePath}}

Заменяется на путь к исходному коду. Если вы используете эту переменную, она должна использоваться в команды flash и build.

{{SDKPath}}

Расширяется до значения в вашем userData.sdkConfiguration.path , когда используется в командах сборки и прошивки.

{{device.connectivity.serialPort}}

Расширяется до последовательного порта.

{{устройство.идентификаторы[?(@.name == 'serialNo')].value[0]}}

Заменяется серийным номером вашего устройства.

{{enableTests}}

Целочисленное значение, указывающее, предназначена ли сборка для тестов (значение 1) или демонстраций. (значение 0).

{{buildImageName}}

Имя файла образа, созданного командой сборки.

{{otaCodeSignerPemFile}}

PEM-файл для подписчика кода OTA.

{{config.idtRootPath}}

Расширяется до корневого пути AWS IoT Device Tester. Эта переменная заменяет абсолютный путь для IDT при использовании команд сборки и прошивки.

Тестирование микроконтроллера

AVR | Блог безумных разработчиков

Сравнение тестирования программных и аппаратных проектов

Скопировать ссылку

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

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

Какие виды тестирования можно использовать в зависимости от задачи?

Скопировать ссылку

Существует три основных варианта запуска тестов на встроенных системах. Перечислим их все:

  1. Локальное тестирование (на хост-компьютере).
    Преимущества: Тесты запускаются и работают быстро, нет необходимости доступа к устройству. Недостатки: ограниченная область тестирования. Он не будет работать с внешней периферией. Хорошим примером использования этого метода является тестирование независимого от платформы вычислительного алгоритма, для которого требуется набор данных с датчиков. Тестирование такого алгоритма на реальном источнике данных было бы очень неудобным. Набор данных лучше подготовить заранее. Вы можете сделать это, используя небольшую программу регистрации необработанных данных датчика.
  2. Тестирование микроконтроллера в моделировании.
    Преимущества
    : для тестирования не требуется устройство. Вы можете запрограммировать свою собственную среду для MCU.
    Недостатки:  ограниченная точность моделирования MCU и окружающей среды, сложность создания и настройки такого эмулятора.
  3. Тестирование прошивки на реальном MCU.
    Достоинства:
    есть возможность работы с периферией МК, прошивка будет работать так же как и в продакшене.
    Недостатки : нужно иметь готовое устройство со всей периферией и электронными компонентами.Циклы тестирования займут много времени, так как вам придется постоянно перепрошивать MCU. Автоматизировать тестирование с помощью этого метода очень сложно.

В этой статье мы разберем первые два метода как наиболее перспективные для автоматизации.

Локальное тестирование

Скопировать ссылку

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

Рассмотрим пример для микроконтроллеров AVR с возможностью локального тестирования платформонезависимых частей прошивки.

Проверка прошивки, совместимой с AVR MCU

Скопировать ссылку

Для микроконтроллеров AVR наиболее удобной и производительной средой разработки является Atmel Studio .К сожалению, эта среда не является кроссплатформенной и доступна только для Windows.

Для ясного понимания примеров в этом проекте я использую инструменты с открытым исходным кодом. Я полагаюсь на VSCode в Ubuntu для исходного кода, AVR GNU Toolchain для компиляции и компоновки прошивки, gcc для компиляции тестов и симулятора.

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

Для примера рассмотрим прошивку для микроконтроллера Atmega1284 , реализующую функционал простого термометра.

Измерение температуры выполняется путем считывания напряжения с делителя напряжения (который включает в себя термистор), преобразования значения АЦП в значения температуры и отображения его на ЖК-экране 1602 ( hd44780 ).

Функция связи с внутренней и внешней периферией может быть реализована посредством работы с регистрами микроконтроллера.

Тем не менее, в нашей прошивке есть функционал, который необходимо протестировать (преобразование значения АЦП в температуру и последующее отображение на светодиодном экране).

Рассмотрим пример нативного тестирования функционала прошивки.

Ссылка на репозиторий:

ЭТИЧЕСКИЕ СТАНДАРТЫ — Журнал с низкой комиссией за обработку в EEE/ECE/E&I/ECE/ETE

ЭТИЧЕСКИЕ СТАНДАРТЫ

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

1. ЭТИЧЕСКИЕ ОЖИДАНИЯ

  • Обязанности редакторов

Редактор является главным редактором издания и несет полную ответственность за все операции и политику. После получения статьи редактор направляет ее рецензентам в зависимости от темы и специализации статьи, не обращая внимания на принадлежность авторов, пол, религию и происхождение авторов.
Редакторы несут ответственность за все, что публикуется в их журналах. Они должны:

  • Полностью оправдать все ожидания авторов, читателей и рецензентов;
  • Обеспечить стандарт и качество материалов, которые они публикуют;
  • Решить все вопросы, уточнения, исправления или жалобы, размещенные авторами;
  • Поддерживать высокий уровень конфиденциальности и честности среди авторов;
  • Убедитесь, что они представили оригинальную и новую работу, а также позаботились о том, чтобы процитировать соответствующие цитаты.
  • Предоставить авторам достаточно времени для отражения необходимых изменений, указанных рецензентами;
  • Убедитесь перед публикацией любой статьи, все ли изменения, указанные рецензентами, отражены или нет.

 

  • Обязанности рецензентов
  • Оценивайте каждую рукопись на предмет ее интеллектуального содержания независимо от расы, пола, возраста, сексуальной ориентации, религиозных убеждений, этнического происхождения, политической философии, гражданства, места жительства или институциональной принадлежности авторов.
  • Подробное изучение и актуальность рукописи в соответствии с указаниями автора.
  • Тщательное изучение цели и задач проводимой работы.
  • Правильность выводов и рекомендаций с актуальными ссылками.
  • Редактирование и корректура рукописей в соответствии с издательскими стандартами, особенно в отношении грамматики, пунктуации и орфографии.
  • Области охвата рукописи в соответствии с тематикой журнала.
  • Проблемы, связанные с плагиатом, если таковые имеются.
  • Рецензенты должны дать не менее шести предложений, исходя из структуры рукописи.
  • Рецензенты имеют полное право принимать или отклонять рукописи, но окончательное решение в случае деликатных заголовков о включении или исключении из публикаций остается за главным редактором.

 

  • Ответственность авторов

1. Все рукописи должны быть написаны на хорошем английском языке. Это ответственность авторов, а не редакции. Статьи ниже стандарта журнала будут возвращены авторам на доработку и могут быть отклонены только по этой причине.
2. Как автор представленной работы, вы несете ответственность за то, чтобы рукопись представляла собой технически и грамматически правильную копию. Хорошо подготовленная рукопись поможет ускорить процесс рецензирования, поскольку рецензенты будут тратить меньше времени на аннотирование технических недостатков статьи и больше времени на оценку интеллектуального содержания.

3. Авторы должны описать роль спонсора(ов) исследования, если таковые имеются, в плане исследования, в сборе, анализе и интерпретации данных, в написании отчета и принятии решения о представлении статьи для публикации.

4. В целях соблюдения правил защиты данных и конфиденциальности каждое лицо, фигурирующее на любой фотографии или изображении, должно быть уведомлено о таком включении.

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

6. Авторы должны представить точный отчет о выполненной работе, а также цель и обсуждение ее значимости.

7. Документ должен содержать достаточно подробностей обо всех пунктах, подпунктах вместе со ссылками, чтобы позволить другим повторить работу.

8. Авторы должны убедиться, что они представили оригинальную и новую работу, а также позаботиться о том, чтобы процитировать соответствующие цитаты.

9. Плагиат во всех его формах представляет собой неэтичное поведение при публикации и является неприемлемым.

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

 

2. ПРОЦЕДУРЫ ПРАКТИКИ НЕЭТИЧНОГО ПОВЕДЕНИЯ

Выявление неэтичного поведения

·     Неправомерное и неэтичное поведение может быть выявлено и доведено до сведения редактора и издателя в любое время любым лицом вместе с доказательствами таких событий.В свою очередь, редактор несет ответственность за принятие необходимых и серьезных мер, о чем также сообщается соответствующему автору.

Результаты  

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

 

[PDF] UEENEEI156A Разработка и тестирование кода для микроконтроллеров

1 UEENEEI156A Разработка и тестирование кода для микроконтроллеров Выпуск: 12 UEENEEI156A Разработка и тестирование кода для microc…

UEENEEI156A Разработка и тестирование кода для устройств с микроконтроллерами

Выпуск: 1

UEENEEI156A Разработка и тестирование кода для устройств с микроконтроллерами

Дата создания этого документа: 26 мая 2012 г.

UEENEEI156A Разработка и тестирование кода для устройств с микроконтроллерами

Дескриптор модуля Дескриптор модуля

1) Область применения: 1.1) Дескриптор Этот стандартный модуль компетенции охватывает структурированные инструкции по программированию для микроустройств на фундаментальном уровне.Модуль включает в себя безопасную работу, применение архитектуры устройства знаний и основ программирования, написание и тестирование определенных инструкций и документирование деятельности по разработке. Примечание. В этом устройстве термин «микро» относится к микроконтроллерам, однако компетентность в устройстве может быть достигнута с использованием микропроцессоров.

Применение модуля Применение модуля

2) Этот стандартный модуль компетенции предназначен для применения к любой признанной программе развития, которая ведет к получению официальной награды на уровне AQF 5 или выше.

Лицензирование/нормативная информация Лицензия на практику

3) Навыки и знания, описанные в этом разделе, не требуют лицензии на практику на рабочем месте. Тем не менее, практика в этом подразделении регулируется правилами, непосредственно связанными с охраной труда и техникой безопасности, и, где это применимо, контрактами на обучение, такими как ученичество

Утверждено © Содружество Австралии, 2012 г. и тестовый код для микроконтроллерных устройств

Лицензия на практику

Дата создания этого документа: 26 мая 2012 г.

3) и т.п.

Предварительные условия Предварительные требования Подразделение(я)

4)

Компетенции

4.1) Предоставление полномочий в этом подразделении должно производиться только после подтверждения компетентности в следующем(их) подразделении(ях). UEENEEE1 01A

Применять правила, кодексы и практики по охране труда на рабочем месте

Для получения полной информации о цепочке предварительных условий для этого модуля см. Таблицу 2 в Томе 1, Часть 2

Навыки грамотности и счета

4.2) Участники лучше всего подготовлены к выполнению этого раздела, если у них есть навыки чтения, письма и счета, указанные в следующих шкалах. Описание каждой шкалы дано в Томе 2, Части 3 «Грамотность и счет». Чтение

5

Письмо

5

Счет

5

Навыки трудоустройства Информация Навыки трудоустройства

03 5

03 единица компетенции содержит применимые аспекты навыков трудоустройства.Сводка навыков трудоустройства, содержащая квалификацию, в которую включена эта единица компетенции, поможет определить требования к навыкам трудоустройства.

Утверждено © Commonwealth of Australia, 2012

Стр. 3 из 11 Стандарты обучения EE-Oz

UEENEEI156A Разработка и тестирование кода для микроконтроллерных устройств

Дата создания этого документа: 26 мая 2012 г. 6) Элементы описывают Критерии эффективности описывают требуемые основные результаты работы, необходимые для демонстрации достижения элемента.стандартная единица компетенции Оценка эффективности должна соответствовать Руководству по доказательствам.

Элементы и критерии эффективности ЭЛЕМЕНТ 1

2

Подготовка к разработке и тестированию основных спецификаций.

Разработка базовой спецификации.

Утверждено © Commonwealth of Australia, 2012

КРИТЕРИИ ЭФФЕКТИВНОСТИ 1.1

Получены и поняты процессы и процедуры охраны труда для данной рабочей области.

1.2

При подготовке к работе соблюдаются установленные меры и процедуры по управлению рисками по охране труда.

1.3

Объем разрабатываемых спецификаций определяется исходя из требований к выполнению работы и после консультаций с соответствующими лицами.

1.4

Мероприятия планируются в соответствии с установленными сроками в консультации с другими участниками работы.

1.5

Соответствующий комплект средств разработки и программное обеспечение выбираются на основе заданных требований и стандартов производительности.

1.6

Реализованы стратегии для обеспечения эффективного программирования.

2.1

Соблюдаются мероприятия по управлению рисками по охране труда и порядок проведения работ.

2.2

Знание функций и особенностей микроконтроллера применяется при разработке спецификаций.

2.3

Правильная структура и синтаксис применяются для разработки спецификации программы для целевой функции микроконтроллера.

2.4

Для разработки и тестирования применяются ключевые особенности языка программирования на ассемблере 26 мая 2012 г.

КРИТЕРИИ ПРОИЗВОДИТЕЛЬНОСТИ решения.

3

Протестировать и задокументировать базовую спецификацию.

Утверждено © Commonwealth of Australia, 2012

2.5

Подходы к вопросам/проблемам анализируются для обеспечения наиболее эффективных решений.

2.6

Качество работы контролируется в соответствии с личным соглашением и/или установленными организационными или профессиональными стандартами.

3.1

Процедуры тестирования разрабатываются для анализа разработанного кода.

3.2

Исправление проблем и ошибок для обеспечения соответствия спецификации создания кода.

3.3

Промежуточные и заключительные рабочие отчеты составляются в соответствии с профессиональными стандартами и представляются соответствующему лицу или лицам.

Страница 5 из 11 Стандарты обучения EE-Oz

UEENEEI156A Разработка и тестирование кода для микроконтроллерных устройств

Дата создания этого документа: 26 мая 2012 г.

Требуемые навыки и знания НЕОБХОДИМЫЕ НАВЫКИ И ЗНАНИЯ 8) 7) навыки и знания и их уровень, необходимые для данного модуля.Доказательства должны показать, что были получены знания о безопасных методах работы, а также о разработке и тестировании кода для микроконтроллерных устройств. Все знания и навыки, описанные в этом разделе, должны быть соотнесены с текущими отраслевыми практиками и технологиями. KS01-EI156A

Программирование микроконтроллера

Доказательства должны демонстрировать понимание методов программирования системы управления микроконтроллером в объеме, указанном в следующих аспектах: Архитектура микроконтроллера, охватывающая: Типы хранения программ Типы хранения данных Порты ввода/вывода: аналоговые/цифровые Встроенные периферийные устройства: таймеры, прерывания и т. д. Схема управления: системные часы, сброс и т. д. Стандартная среда программирования Термины программирования, включающие: Уровни языка и их особенности Симуляторы и эмуляторы языков Основы языкового программирования, включающие: Программирование функций ввода/вывода Временные циклы Организация памяти, методы работы и адресации, включающие: Модель программиста, охватывающая:        

структура регистра инструкция регистр/декодер арифметико-логическое устройство (ALU) накопитель и флаги цикл инструкции контрольные строки указатель стека индекс регистр

схемы системных часов выборка и выполнение охватывают

цикл синхронизации

Утверждено © Австралийское общество, 2012 г.

Стр. 6 из 11 Стандарты обучения EE-Oz

UEENEEI156A Разработка и тестирование кода для микроконтроллерных устройств

3

Май 26 26 ТРЕБУЕМЫЕ НАВЫКИ И ЗНАНИЯ  

Временная связь с логическими уровнями системных часов системных шин для каждого тактового периода командного цикла

Программирование портов ввода/вывода Программирование структурированных сборок единицы компетенции и должны рассматриваться вместе с критериями эффективности и заявлением о диапазоне единицы компетенции и Руководством по оценке учебных пакетов.Справочник по доказательствам является неотъемлемой частью этого стандартного модуля компетенций и должен использоваться вместе со всеми составными частями этого модуля и выполняться в соответствии с Руководством по оценке данного учебного пакета.

Обзор оценки

9.1) Подходы к оценке продольного развития компетенций, такие как профилирование, требуют надежного сбора данных в форме, которую можно последовательно интерпретировать с течением времени. Этот подход лучше всего использовать в программах ученичества и снижает вмешательство в процесс оценки.Это предпочтительная модель ученичества в отрасли. Однако там, где используется итоговая (или итоговая) оценка, она должна включать применение компетенции в обычной рабочей среде или, как минимум, применение компетенции в реалистично смоделированной рабочей среде. Признано, что при некоторых обстоятельствах частичная или полная оценка может проводиться вне рабочего места. Тем не менее, это должно соответствовать отраслевой и нормативной политике в этом отношении. На методы, выбранные для конкретной оценки, будут влиять различные факторы.К ним относятся объем оценки, наиболее эффективные места для проведения оценки, доступ к физическим ресурсам, дополнительные меры безопасности, которые могут потребоваться, и критический характер оцениваемых компетенций. Критический характер безопасности при работе с электричеством, электрооборудованием, газом или любым другим опасным веществом/материалом сопряжен с риском признания лица компетентным. Следовательно, источники доказательств

Утверждено © Commonwealth of Australia, 2012

Стр. 7 из 11 Стандарты обучения EE-Oz

UEENEEI156A Разработка и тестирование кода для микроконтроллерных устройств

Дата создания этого документа: 26 мая 2012 г.

3

3 быть «богатым» по своей природе, чтобы свести к минимуму ошибки в суждениях.Деятельность, связанная с обычной повседневной работой, влияет на решение о том, насколько и насколько подробно собранные данные будут способствовать ее «богатству». Некоторые навыки более важны для безопасности и эксплуатационных требований, в то время как одни и те же навыки могут применяться более или менее часто. Эти вопросы поднимаются для того, чтобы оценщики учитывали их при выборе метода оценки и разработке инструментов оценки. Образцы инструментов оценки включены для оценщиков в Руководство по оценке данного учебного комплекта.

Критические аспекты доказательств, необходимые для демонстрации компетентности в этом разделе

9.2)

Перед рассмотрением критических аспектов доказательств должны быть выполнены все предпосылки. Доказательства компетентности в этом разделе должны рассматриваться комплексно. Каждый элемент и связанные с ним критерии эффективности должны быть продемонстрированы не менее двух раз в соответствии с «Руководством по оценке — UEE11». Доказательства также должны включать: 

Репрезентативная совокупность результатов работы, продемонстрированная в сроки, обычно ожидаемые для дисциплины, рабочей функции и производственной среды.В частности, это должно включать доказательства, которые показывают, что кандидат способен:  Внедрять процедуры и методы охраны труда и техники безопасности на рабочем месте, включая использование мер контроля рисков, как указано в критериях и диапазоне эффективности; и  применять принципы и методы устойчивой энергетики, как указано в критериях эффективности и диапазоне; и  Продемонстрировать понимание основных знаний и связанных с ними навыков, описанных в этом разделе. В некоторых юрисдикциях может потребоваться, чтобы RTO предоставляли результат с процентильной оценкой для целей нормативных или лицензионных требований.; и  Демонстрировать соответствующий уровень навыков, позволяющий трудоустроиться; и  Проводить работу с соблюдением соответствующего антидискриминационного законодательства, положений, политик и процедур на рабочем месте;

Утверждено © Commonwealth of Australia, 2012

Стр. 8 из 11 Стандарты обучения EE-Oz

UEENEEI156A Разработка и тестирование кода для микроконтроллерных устройств в репрезентативном диапазоне контекстов из предписанных ниже пунктов:  Разработать и протестировать код для микроконтроллерных устройств, как описано в 8), включая:

A

Использование всех ключевых функций соответствующего языка ассемблера.

B

Разработка процедур тестирования.

C

Выявление проблем и ошибок в программе.

D

Исправление проблем и ошибок в программе.

E

Написание и представление рабочих отчетов в соответствии с приемлемыми стандартами.

F

Работа с незапланированными событиями путем использования основных знаний и навыков для предоставления соответствующих решений, включенных в комплексную оценку вышеперечисленных элементов.

Контекст и конкретные ресурсы для оценки

9.3)

Этот раздел следует оценивать, поскольку он относится к обычной рабочей практике с использованием процедур, информации и ресурсов, типичных для рабочего места. Это должно включать:  

Политика охраны труда, рабочие процедуры и инструкции. Подходящая рабочая среда, средства, оборудование и материалы для выполнения фактической работы, как предписано этой единицей стандарта компетентности.

Ресурсы, необходимые для оценки этого раздела, перечислены выше в контексте оценки, которую также следует использовать в формальной среде обучения/оценки.Примечание. Если моделирование считается подходящей стратегией оценки, оно должно гарантировать, что условия оценки являются аутентичными и, насколько это возможно, воспроизводят и воспроизводят рабочее место и соответствуют утвержденной отраслевой политике моделирования. Ресурсы, используемые для оценки, должны отражать текущую отрасль

Утверждено © Commonwealth of Australia, 2012

Стр. 9 из 11 Стандарты обучения EE-Oz

UEENEEI156A Разработка и тестирование кода для микроконтроллерных устройств

Дата создания этого документа: 26 мая 2012 г.

практика разработки и тестирования кода для микроконтроллерных устройств.

Метод оценивания

9.4) Эта единица стандарта компетентности оценивается методами, приведенными в томе 1 части 3 «Руководство по оцениванию». Примечание. В отрасли, к которой применяется эта стандартная единица компетентности, ожидается компетентная работа с присущими безопасными методами работы. Это требует, чтобы указанные основные знания и связанные с ними навыки оценивались в структурированной среде, которая в первую очередь предназначена для обучения/оценки и включает в себя все необходимое оборудование и средства для того, чтобы учащиеся развивали и демонстрировали основные знания и навыки, описанные в этом разделе.

Параллельная оценка 9.5) и взаимосвязь с другими модулями Для данного модуля нет рекомендаций по параллельной оценке

Утверждено © Австралийским союзом, 2012 г.

Стр. 10 из 11 Стандарты обучения EE-Oz

Дата создания этого документа: 26 мая 2012 г.

Заявление о диапазоне ОПИСАНИЕ ДИАПАЗОНА 10) Это относится к единице компетенции в целом, обеспечивающей диапазон контекстов и условий, к которым применяются критерии эффективности.Это позволяет использовать различные рабочие среды и ситуации, которые будут влиять на производительность. Эта стандартная единица компетентности должна быть продемонстрирована в отношении разработки и тестирования кода для микроконтроллерных устройств, включая не менее трех из следующих: Пакеты программного обеспечения /симулятора для отладки программы Поиск системных ошибок.

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

Добавить комментарий

Ваш адрес email не будет опубликован.