Часть четвертая – это может показаться немного сложно.


Play

Структура проекта.

Для облегчения конфигурирования проекты MPLAB Harmony обычно структурированы таким образом, чтобы изолировать код, необходимый для настройки «системы», от кода библиотеки и кода вашего приложения, как показано на следующем рисунке.

На следующем рисунке показано, как файлы приложения, библиотеки и конфигурации организованы в проекте MPLAB X IDE.

 

В проекте MPLAB Harmony файл main.c поддерживается очень простым и согласованным (просто “супер цикл”, ранее я говорил о нём). Файлы приложения (app.c и app.h на предыдущем рисунке) отделены от файлов конфигурации в подпапках system_config, поэтому у одного приложения может быть несколько конфигураций, для разных микроконтроллеров или для разных схематических конфигураций проекта. (Использование этой возможности можно увидеть на примерах в демонстрационных проектах, включенных в установку MPLAB Harmony). Модули библиотеки, которые составляют платформу MPLAB Harmony (в папке framework (конструкция)), используют определения, предоставленные в выбранном заголовке (system_config.h, выделенный серым фоном на предыдущем рисунке), чтобы указать параметры конфигурации, выбранные при настройке проекта. Наконец, специфичные для процессора периферийные библиотеки предоставляются как в виде предварительно скомпилированного двоичного файла (.a файл компоновщика), так и в виде встроенного исходного кода, чтобы обеспечить максимальную эффективность сборки для вашего проекта.

План проекта или как организован проект MPLAB Harmony.

Заголовочные файлы и папки с исходными файлами

Среда MPLAB X IDE разделяет файлы на языке C на заголовочные (.h) и исходные (.c) файлы, помещая заголовочные файлы в логическую папку Header Files верхнего уровня, а исходные файлы – в логическую папку Source Files верхнего уровня. Это различие предназначено только для отображения в среде MPLAB X IDE, и эти папки не отображаются на диске. Кроме того, в большинстве случаев логические папки, которые отображаются как подпапки этих папок, дублируются, как в логических папках верхнего уровня, так и в файлах верхнего уровня, поскольку заголовочные и исходные файлы хранятся в одном вместе на диске.

Папка приложения

Эта папка содержит исходные файлы main.c и app.c и заголовочный файл app.h.
Папка app (то есть application) и ее подпапки содержат все исходные и заголовочные файлы, зависящие от проекта (но не общие файлы, хранящиеся в папке framework, которые разберем позже). В простом проекте папка app содержит файлы main.c, app.c и app.h и подпапка system_config. Более сложные проекты, будут содержать дополнительные файлы по мере необходимости. В проекте MPLAB Harmony файл main.c обычно содержит основную функцию языка C и ничего или почти ничего более. Логика основной функции одинакова во всех проектах MPLAB Harmony и не требует изменений. Файл app.c обычно содержит логику самого приложения. Именно здесь обычно реализуется желаемое общее поведение вашей системы (хотя сложные системы могут иметь несколько приложений). Файл app.h определяет типы данных и другие определения, требуемые прототипами приложения или интерфейса для функций, которые приложение хочет предоставить другим приложениям или системе.

Папка system_config

Папка system_config содержит один или несколько подкаталогов, каждый из которых соответствует отдельной конфигурации вашего проекта. Проекты MPLAB Harmony могут иметь несколько конфигураций. Каждая конфигурация проекта создает различные варианты вашей встроенной системы с потенциально различным оборудованием или функциями. В каждой конфигурации вы можете выбрать разные наборы библиотек или модулей, выбрать разные параметры сборки для каждого модуля и даже выбрать разные исходные файлы для вашего приложения. Конфигурация состоит из определенного набора свойств (настройки инструментов) в MPLAB X IDE, набор исходных файлов, которые определяют параметры сборки, и набор исходных файлов и заголовочных файлов, которые контролируют, какие модули инициализируются и поддерживаются в вашей системе.

В MPLAB X IDE конфигурацию проекта можно выбрать с помощью раскрывающегося меню на панели инструментов, в верхней части окна или щелкнув правой кнопкой мыши имя проекта и выбрав «Свойства». В большинстве примеров и демонстрационных проектов, распространяемых с MPLAB Harmony, имя каждой конфигурации MPLAB X IDE будет совпадать с именем связанной папки в папке system_config в проекте (папка 795_pim_e16 в примере проекта). Когда выбрана конкретная конфигурация MPLAB X IDE, файлы конфигурации для этой конфигурации включаются в сборку, а файлы конфигурации в других папках конфигурации исключаются из сборки. Рекомендуется следовать этому соглашению, если вы используете несколько конфигураций в своих проектах.

Файлы конфигурации:

  • system_config.h
  • system_init.c
  • system_tasks.c
  • system_interrupt.c
  • system_exceptions.c
  • system_definitions.h

Этот набор файлов определяет конфигурацию системы. Назначение каждого из этих файлов будет более подробно описано в следующих разделах. Но основная идея заключается в том, что вам могут потребоваться разные конфигурации вашего приложения для разных аппаратных плат, разных микроконтроллеров Microchip или разных наборов функций, в зависимости от ваших конкретных потребностей.
Разрешение разных конфигураций одной и той же логики приложения делает ваше приложение более гибким и обеспечивает хорошо организованный способ справляться с разновидностями, которые обычно возникают в любом проекте достаточного размера и сложности. Эта техника помогает устранить дублирование кода (и непродуктивный труд), которые в противном случае были бы необходимы для управления несколькими смежными проектами. Конечно, если вам не нужно или не нужна такая гибкость, все эти файлы специально созданы для вашего проекта, и вы можете вносить в них любые изменения, которые вам нравятся. Выбор всегда за вами.

Относительный путь от папки проекта MPLAB X IDE к папке конфигурации (содержащей файл system_config.h) для каждой конфигурации проекта автоматически помещается в список «Включает каталоги» в свойствах компилятора для каждой конфигурации проекта MPLAB X IDE MHC (MPLAB Harmony configurator).

Структура папок

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

1. У вас всегда есть возможность скопировать файлы инфраструктуры непосредственно в исходную папку вашего проекта, если это необходимо. Фактически, это хорошая идея, если вы планируете перемещать или распространять свой проект отдельно от установки MPLAB Harmony.
2. В большинстве случаев организация «логическая папка» в проекте MPEAB X IDE в точности совпадает с организацией физической директории в рамках установки MPLAB Harmony (и в каталоге вашего проекта) на вашем жестком диске. Это сделано для того, чтобы все было просто и согласованно, поэтому вам нужно выучить только один макет. Но есть несколько заметных исключений.

MPLAB X IDE имеет соглашение о разделении «Заголовочные файлы» (.h) и «Исходные файлы» (.c), чтобы организация виртуальных папок в проекте разделяла файлы на эти две группы и  не делайте это на диске с физическими каталогами.
• В примере или демонстрационном проекте MPLAB Harmony папка приложения будет соответствовать каталогу src на диске внутри папки прошивки проекта.

Основной файл

Точка входа на языке C для встроенного приложения MPLAB Harmony является основной функцией. Эта функция определена в файле main.c, созданном MHC в папке приложения проекта (или в каталоге src на диске). Основная функция (см. Следующий пример) реализует простой «супер цикл», обычно используемый во встроенных приложениях, которые не используют операционную систему.
Example main Function Logic – Пример функции логики main.

Функция SYS_Initialize

Первое, что делает основная функция, это вызывает функцию с именем SYS_Initialize. Цель функции SYS_Initialize – инициализировать каждый программный модуль в системе. MPLAB Harmony основан на модели взаимодействующих конечных автоматов. Следовательно, эта функция должна гарантировать, что конечный автомат каждого модуля находится в допустимом начальном состоянии. Реализация этой функции является одной из вещей, сгенерированных MHC для конфигурирования системы MPLAB Harmony. Определение этой функции генерируется в файле system_init.c, описанном в system_init.c секции.

Сигнатура функции SYS_Initialize имеет входной параметр «void *». Это сделано для того, чтобы впоследствии она могла быть реализована в библиотеке, и в нее можно передать произвольную структуру данных инициализации. Однако для статически реализуемой функции SYS_Initialize (которая обычно будет иметь место, если вы реализуете ее самостоятельно), этот параметр не нужен и может быть передан как «NULL».

The “Super Loop” –  “Супер Луп” – “Супер петля” – “Супер цикл”

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

Файл SYS_Tasks и функция SYS_Tasks

Внутри «супер цикла» основная функция вызывает функцию SYS_Tasks. Цель функции SYS_Tasks – опросить каждый программный модуль в системе, чтобы убедиться, что он продолжает работать. Таким образом система поддерживает конечные автоматы всех опрошенных модулей.
(Обратите внимание, что некоторые модули могут управляться прерываниями и, следовательно, не вызываться из функции SYS_Tasks.) Реализация функции SYS_Tasks генерируется MHC в файле system_tasks.c, который описан в секции system_tasks.c.

Файлы приложения.

С точки зрения системы MPLAB Harmony, приложение состоит из двух основных функций:

  • APP_Initialize
  • APP_Tasks

Функция инициализации приложения (APP_Initialize) обычно вызывается из функции SYS_Initialize, которая вызывается из main перед входом в цикл верхнего уровня. Функция приложения «задачи» (APP_Tasks) обычно вызывается из функции SYS_Tasks, которая вызывается из main из цикла верхнего уровня. Вот как конечный автомат приложения инициализируется и «опрашивается», чтобы оно могло выполнять свою работу.
Функция SYS_Initialize обычно реализуется в файле system_init.c, а функция SYS_Tasks обычно реализуется в файле system_tasks.c. Это соглашение актуально, например, для демонстрационных проектов, распространяемые вместе с MPLAB Harmony, и это относится к проектам, созданным MHC. Вы конечно можете делать все, что угодно, в своих собственных проектах, но рекомендуется следовать этому соглашению, поскольку это облегчит управление несколькими конфигурациями, если они вам понадобятся, и будет соответствовать MHC и другим инструментам.

Инициализация приложения.

Функция инициализации приложения, переводит конечный автомат приложения в исходное состояние и может при необходимости выполнить дополнительную инициализацию. Эта функция не должна блокировать и не должна вызывать подпрограммы любых других модулей, которые могут блокировать работу. Если что-то нужно инициализировать, что может потребовать времени для завершения, то эта инициализация должна быть выполнена на конечном автомате приложения (то есть в его функции «Задачи» “Tasks function“).

Функция инициализации примера приложения:

Функция инициализации примера проекта инициализирует внутреннюю переменную и переводит конечный автомат приложения в исходное состояние, присваивая значение перечисления APP_STATE_INIT в элементе «state» структуры данных, которая содержит все данные, требуемые приложением (appData). Эта структура определена глобально, но доступна только приложению. Функция инициализации приложения вызывается из функции SYS_Initialize (определенной в system_init.c), которая вызывается из main после сброса системы. Используя эту технику, приложение инициализируется (вместе с остальной частью системы) всякий раз, когда система выходит из состояния Сброс.

Задачи приложения.

Конечный автомат приложения разбивает работу, которую приложение должно выполнять, на несколько коротких «задач», которые оно может быстро выполнить, но между которыми оно должно ждать, пока какой-то другой модуль завершит некоторые свои собственные задачи. (В этом случае другой модуль является драйвером USART в примере.) Как только каждая короткая задача успешно завершена, приложение переходит в другое состояние для выполнения следующей короткой задачи.

Example Application Tasks Function: Пример приложения Функции задачи:

Примеры состояний приложения.

Функция «задачи» (Tasks) в примере приложения разбивает работу приложения на следующие состояния с помощью оператора «switch» со следующими «случаями».

  • APP_STATE_INIT
  • APP_STATE_SEND_MESSAGE
  • APP_STATE_IDLE

В примере, приложение переводится в состояние APP_STATE_INIT с помощью функции инициализации приложения до того, как будет вызвана функция «tasks». Итак, при первом вызове функции APP_Tasks выполняет код оператора switch и первая короткая «задача», которую пытается выполнить пример приложения, – это открыть драйвер USART, чтобы получить дескриптор, чтобы он мог передавать данные через USART. Обратите внимание, что приложение проверяет значение дескриптора, возвращенного функцией DRV_USART_Open, чтобы убедиться, что он является действительным до его перехода в состояние APP_STATE_SEND_MESSAGE. Если значение дескриптора, перенастроенного на то, что функция «открытия» драйвера недействительна (равно DRV_HANDLE_INVALID), приложение остается в состоянии APP_STATE_INIT и продолжает пытаться открывать драйвер USART каждый раз, когда вызывается его функция «tasks». Эта техника позволяет опрашиваемому конечному автомату ждать чего-то, что ему требуется, и избегать неуместного перехода в новые состояния, до тех пор пока модуль USART не готов выполнять требуемые задания..
Как только приложение имеет действительный дескриптор драйвера USART, оно выполняет код в случае APP_STATE_SEND_MESSAGE при следующем вызове его функции APP_Tasks. В этом состоянии приложение вызывает процедуру передачи данных драйвера USART (DRV_USART_BufferAdd) для отправки строки буфера данных, определенной в заголовке system_config.h. Затем он проверяет дескриптор, возвращенный функцией DRV_USART_BufferAddWrite, чтобы убедиться, что он действителен. Если дескриптор буфера действителен, это означает, что драйвер USART принял буфер и будет нести ответственность за передачу данных с этого момента. Приложению не нужно ничего делать, чтобы вызвать передачу данных. Однако, если буфер не принят драйвером (в этом случае дескриптор, возвращенный функцией DRV_USART_BufferAddWrite, будет недействительным), приложение остается в APP_STATE_SEND_MESSAGE и повторяет попытку при следующем вызове функции APP_Tasks.
После того, как приложение успешно передало буфер в драйвер USART, оно переходит в состояние APP_STATE_IDLE, где оно находится и ничего не делает каждый раз, когда вызывается его функция «tasks». Его работа выполнена! Более сложное приложение может перейти к какой-либо другой задаче или потенциально начать процесс заново. Но это простой пример приложения “Hello World“.

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

Конфигурации системы.

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

system_config.h

В MPLAB Harmony большинству библиотечных модулей требуется набор параметров конфигурации времени сборки, которые определяют различные параметры (например, размеры буфера, максимальные или минимальные ограничения и поведение по умолчанию). Чтобы настроить библиотеку для ваших конкретных потребностей, ее параметры конфигурации могут быть определены с помощью операторов препроцессора языка C #define. Набор поддерживаемых параметров конфигурации надо искать, для каждой библиотеки, в разделе «Конфигурирование библиотеки» его справочного документа, и большинство библиотек предоставляют шаблоны и примеры файлов заголовков конфигурации в подпапке config, в папке src.
Чтобы получить параметры конфигурации своей сборки, каждая библиотека включает в себя один и тот же общий файл конфигурации верхнего уровня с именем system_config.h, и он создается MHC как часть конфигурации вашей системы. Относительный путь к каталогу конфигурации, который содержит этот файл, определяется в свойствах сборки конфигурации вашего проекта MHC, чтобы компилятор мог найти его в своем пути поиска включаемого файла.

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

system_init.c

В проекте MPLAB Harmony функция SYS_Initialization вызывается из основной функции для инициализации всех модулей в системе. Эта функция реализована как часть конфигурации системы MHC в файле с именем system_init.c. Этот файл может также включать другие необходимые глобальные системные элементы, которые должны быть реализованы для инициализации системы, такие как биты конфигурации процессора и глобальные структуры данных инициализации модуля.

В дополнение к реализации функции SYS_Initialize в предыдущем примере файл system_init.c из конфигурации «pic32mx_795_pim_e16» проекта, определяет биты конфигурации процессора, структуры данных, используемые для инициализации драйвера USART и службы управления устройством, и глобальная структура данных sysObj, используемая для службы системы управления устройствами драйвера USART, возвращаемой их функциями инициализации.

Обратите внимание, что тип данных SYSTEM_OBJECTS для структуры даты sysObj определен в секции system_definitions.h.

system_tasks.c

Поскольку модули MPLAB Harmony управляются конечным автоматом, у каждого из них есть функция «Задачи» (“Tasks”), которая должна вызываться повторно (из общесистемного «супер цикла» в основном или из потока ISR или ОС). Все функции «Задачи» вызываются из функции SYS_Initialize верхнего уровня, которая обычно реализуется в файле system_tasks.c, который генерируется MHC как часть конфигурации системы.

Файл system_tasks.c для конфигурации «pic32mx_795_pim_e16» проекта содержит только реализацию функции SYS_Tasks для этой конфигурации. Эта функция вызывает функцию задач службы системы управления устройствами, функции задач драйвера USART (у нее три функции, по одной для задач передатчика, приемника и обработки ошибок), передачу дескриптора объекта, возвращенного из процедуры инициализации драйвера, и он вызывает функцию задач приложения APP_Tasks, чтобы поддерживать конечные автоматы всех трех модулей.

system_interrupt.c

В конфигурации, управляемой прерываниями, любые модули (такие как драйверы или системные службы), которые могут управляться из прерывания, должны иметь свою функцию (и) задач с возможностью прерывания, вызываемую из «векторной» функции подпрограммы обработки прерывания (ISR) вместо из функции SYS_Tasks. Форма определения векторной функции ISR зависит от типа микроконтроллера PIC32, на котором работает система. Таким образом, любые требуемые векторные функции обычно реализуются как часть определенной конфигурации системы в файле, обычно называемом system_interrupt.c.
Поскольку образец приложения полностью опрашивается, его файл system_interrupt.c не содержит векторных функций ISR. Обратитесь к любому демонстрационному или примерному приложению, управляемому прерываниями, чтобы увидеть, как реализованы векторные функции.

system_definitions.h

Все исходные файлы конфигурации системы (system_init.c, system_tasks.c и system_interrupt.c) требуют определения структуры данных системных объектов и ее внешнего объявления. MHC генерирует эти элементы в заголовочном файле system_definitions.h, и все исходные файлы системы включают этот заголовочный файл.

Например, пример приложения определяет следующее определение структуры и внешнее объявление.

Эта структура содержит дескрипторы объектов, возвращаемые функциями Initialize для элемента управления устройства и модулей USART (в system_init.c), потому что они должны быть переданы в связанные функции Tasks (вызываемые в system_tasks.c), поэтому глобальная структура sysObj системы требует внешнего объявления. MHC генерирует переменные дескриптора объекта в этой структуре для каждого экземпляра активного модуля в системе.
Кроме того, исходные файлы конфигурации системы требуют заголовков интерфейса для всех библиотек и приложений, включенных в систему, чтобы у них были прототипы для их функций Initialize и Tasks. В примере приложения файл system_definitions.h содержит следующие заголовки интерфейса (и стандартные заголовки языка Си).

Внимание: Заголовочный файл system_configuration.h не должен включаться в исходные файлы приложения (app.c, app.h или другие), поскольку он обеспечивает прямой внешний доступ к системным объектам, и эти объекты не должны использоваться приложением напрямую. Приложение (или другие модули) должно взаимодействовать с модулем только через его определенный прикладной программный интерфейс (API) или клиентский интерфейс, а не через системные объекты или системные функции, которым требуется этот объект.

system_exceptions.c

Исходный файл system_exceptions.c предоставляет скелетную реализацию общей функции обработчика исключений (показанной ниже), переопределяя слабую реализацию функции, предоставляемую компилятором C/C++ MPLAB XC32, который просто зависает в бесконечном цикле.

Если возникает общее исключение, эта реализация захватывает адрес инструкции, вызвавшей исключение, в переменной _excep_addr, код причины в переменной _excep_code и использует таблицу поиска, проиндексированную причиной, для предоставления отладочного сообщения, описывающего исключение если включена поддержка отладочных сообщений. Затем функция попадет в жестко запрограммированную точку останова отладки (в режиме отладки) и зависнет в цикле, чтобы предотвратить быстрое выполнение.
Эта реализация предназначена для помощи в разработке и отладке. Пользователю рекомендуется изменить эту реализацию в соответствии с потребностями своей системы.
Использование этого обработчика исключений вместо встроенного обработчика компилятора включается в MHC путем выбора вкладки «Параметры», а затем «Конфигурация приложения»> «Обработка исключений»> «Использовать шаблон обработчика исключений MPLAB Harmony» (Application Configuration > Exception Handling > Use MPLAB Harmony Exception Handler Template). Расширенные обработчики исключений, которые предоставляют дополнительную информацию об исключении, доступны на вкладке «Параметры», выбрав «Расширенное исключение» и «Обработка ошибок» (Advanced Exception and Error Handling).

The Configuration-specific “framework” Folder.

Заголовки интерфейса (т. е. API) и исходные файлы для динамических реализаций всех библиотек MPLAB Harmony содержатся в основной папке фреймворка (<install-dir>\framework). Однако MHC генерирует любые статические реализации библиотек MPLAB Harmony. Эти сгенерированные исходные файлы являются специфичными для конфигурации, потому что они генерируются со знанием выбора конфигурации. Таким образом, они помещаются в специфическую для конфигурации структуру фреймворка. Для обеспечения согласованности организация дерева подпапок в папке инфраструктуры, зависящей от конфигурации, совпадает с организацией основной папки платформы.
Например, специфичная для конфигурации папка фреймворка для конфигурации pic32mx795_pim_e16 примера проекта содержит источник файлы для статических, сгенерированных MHC реализаций системной службы часов и системной службы портов, как показано на следующем рисунке.

Other Configuration-specific Files – Другие специфические файлы конфигурации.

Есть два дополнительных файла (не на языке C), сгенерированных MHC и помещенных в папку для конкретной конфигурации. Первый файл, <имя-конфигурации>.mhc (<config-name>.mhc), фиксирует выбор конфигурации, сделанный пользователем. Второй файл, который всегда называется configuration.xml, содержит различные контрольные суммы и дополнительную информацию, необходимую MHC для определения того, какие сгенерированные файлы были отредактированы извне, и для хранения другой разной информации, которая ему требуется (например, путь к установке MPLAB Harmony).



Итак как правильно должен был выглядеть наш проект в MPLAB Harmony.

В файле main.c мы не делаем ничего, он должен выглядеть так:

Все изменения будут относиться к файлам app.c и app.h именно эти файлы предназначены для состыковки системных модулей построчных MHC и модулей пользователя.

В файле app.h в секции определения, добавим описание портов светодиодов.

В файле app.c в функцию APP_Initialize добавим начальную инициализацию светодиода, для получения эффекта перемигивания светодиодов.

В функцию APP_Tasks впишем в операторе switch в case APP_STATE_SERVICE_TASKS: исполнительный код пользователя (или функции):

Так как так, может быть выглядеть первая программа с использованием MHC для мигания двух светодиодов. Готовый проект можно загрузить:


По мере выполнения проектов, буду описывать интересные решение с использованием MHC.


Это может быть интересно


  • WiFi ESP8266 ESP-202 (ESP-12F)WiFi ESP8266 ESP-202 (ESP-12F)
    Первое знакомство, сначала надо его купить… http://voron.ua/catalog/024404 Схема для подключения и тестирования По схеме ставим две кнопки, сброс и кнопку BT2, для перевода в режим обновления прошивки. Если надо сделать аппаратный сброс …
  • Проект с использованием MCC часть 06Проект с использованием MCC часть 06
    Изменим схему следующим образом добавим две тактовые кнопки BT1 и BT2. Теперь переключимся на конфигурацию выводов, для этого сделаем двойной клик в окне Ресурсы проекта на Pin Module. В окне Pin …
  • Мониторинг температурыМониторинг температуры
    Настоящий проект создан как обучающий с применением библиотек ds18b20 и LCDHD44780 и компилятора Microchip MPLAB XC8 C Compiler V1.12. Если необходимо иметь информацию по состоянию температуры в помещении или в здании, с количеством до 6 точек (16), то вы сможете …
  • Модуль CAN в микроконтроллерах PIC18Модуль CAN в микроконтроллерах PIC18
    Введение   CAN последовательный интерфейс связи, который эффективно поддерживает распределенное управление в реальном масштабе времени с высокой помехозащищенностью. Протокол связи полностью определен Robert Bosch GmbH, в спецификации требований CAN 2.0B …
  • Простой цифровой милливольтметр постоянного токаПростой цифровой милливольтметр постоянного тока
    Простой цифровой вольтметр постоянного тока. Три диапазона измерений с автоматическим переключением 1 – 0,001 – 0,999 V, 2 – 0,01-9,99 V, 3 – 0,1-99,9. Четыре управляемых выхода с возможностью задания функции контроля и времени реакции на …
  • Одноканальный емкостной сенсор – AT42QT1012Одноканальный емкостной сенсор – AT42QT1012
    Описание сенсора  Незаконченный проект, так-как сенсор не оправдал своего назначения, не рекомендую, просто выброшенные деньги. Особенности. • Количество сенсоров – один, режим переключения ( touch-on/touch-off ), а также программируемая автоматическая задержка выключения …
  • AD9833 – Programmable Waveform Generator – part twoAD9833 – Programmable Waveform Generator – part two
    Прошло время и появилась тема, что-бы закончить проект AD9833 – Programmable Waveform Generator. Приехали печатные платы. В этот раз я печатные платы заказывал в https://jlcpcb.com/ делал это в первый раз …
  • Часы + Календарь + Термометр + …Часы + Календарь + Термометр + …
    Часы + Календарь + Термометр + Индикатор влажности + Секундомер + Дистанционное управление на ИК лучах (пульты на RC-5 протоколе) + Автоматическая регулировка яркости + Возможность вывода данных через USB, на плате ILLISSI_B4_primum …
  • MPLAB® Harmony – или как это просто! Часть 2.MPLAB® Harmony – или как это просто! Часть 2.
    Часть вторая – Первая программа на PIC32. Музыкальная тема к статье, слушаем: Для начала изучения PIC32 надо иметь или демоплату или самому её изготовить имея микроконтроллер. Начнем из трудоемкого варианта …
  • CCP модуль для декодирования ИК-кодов пультов ДУCCP модуль для декодирования ИК-кодов пультов ДУ
    Множество изготовителей для своих пультов дистанционного управления на ИК лучах используют принцип широтно-импульсной модуляции. В таких кодах бит единицы представляется импульсом большой длительности, а ноль импульсом короткой длительности. Внешний вид …



 

Tagged with →  
Share →

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

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

Translate »

Copyright © Catcatcat electronics 2013-2019. Все права защищены.
Копирование разрешается только с указанием активной ссылки на правообладателя.

e-mail: catcatcat.electronics@gmail.com