Микроконтроллеры AVR

[akl]

Другое дело, что в МК нет приоритетных прерываний, срабатывает первое поступившее.

А как иначе? Касательно AVR одновременно поступившие запросы прерывания будут обработаны в соответствии с таблицей для каждого камня.

[ozforester]

Обработать-то обработает, но для вложенности придется обратно разрешать прерывания в обработчике и добавлять лишний код там, где в нем меньше всего есть неообходимость.

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

[veso74]

Приоритет определяется адресом вектора прерывания в таблице векторов. Прерывания с меньшим адресом имеют более высокий приоритет. Все аапаратного, изменений нет. Возможно, как написали, с программных "трюков", но все равно медленно: cli()/sei(), флаги. Нет NVIC (Nested Vectored Interrupt Controller) (ARM) и приоритетный выбор, нет прерывание в прерывания ... Как только привыкнеш, писал уже: пути назад нет: AVR - только для старых проектов и для простых идей.

[cuneum]

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

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

Добавлено через 23 минут(ы):

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

[vadim_d]

Делается на любом МК, при наличии таймера

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

[cuneum]

он помнит в каждой задаче о существовании други

Пробовал создать некое распределение времени между процессами в программе, но при использовании IRQ возникали коллизии с выводом на экран, потому и пишу, что нужны подпрограммы-драйверы для периферии и общение через них. Например, в синтезаторе на 5351, используется часто "отложенная запись" на LCD, вместо delay и счетчик "тиков" с распределением между подпрограммами. Да, всё это "сыро", но и цель была не в создании многозадачности.

Переключатель задач должен учитывать приоритет задачи (грубо число тиков) и минимальный интервал обращения. Ваш вывод телеграфа на пине относится с одной стороны к "real-time", с другой, его можно организовать иначе на МК. В 8085, весь вывод звука у вас был программным, отсюда и "хрипы" от переключения задач. Однако, если посмотреть демо-сцены или игры, то там пусть и неявно присутствует неуправляемая многозадачность, переключая время процессора на разные подпрограммы. Особенно это заметно на старых 8-бит машинах. Тем не менее, программная эмуляция звука весьма ресурсоёмкий процесс.

[ozforester]

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

[veso74]

Купил дешевый MPLAB Snap In-Circuit Debugger PG164100.
Положительные эмоции от программирования и отладки с PIC MCU здесь.

Устройство также работает и с MCU Atmel: перемычка от PIC на AVR.
Решил попробовать. Пока только до компиляция и записи в чип добрался, включая чтение, изменение фьюзы.
Попробую и отладчик, но если у AVR есть указанный интерфейс (в Atiny13A нет?), надеюсь, и это будет успешно.
В целом это интересное устройство. Оптимизации до 2 в бесплатной лицензии компилятора XC8 достаточно.

[Андрей_1976]

А там в комплекте только плата? Или шнуры есть? Или самому делать?

[veso74]

В комплект не входят кабели. Но изготовление проводов с Dupont клеммами - тоже удовольствие .
Но можно использовать и заводские: 5 контактов: для PIC, 6 контактов: для AVR. Лучше 8 контактный - для все.
---
Отладка в AVR тоже заработала, неважно что пришлось несколько раз обновить прошивку. Но всe же удалось: MPLAB X v6.05 и на win7 64 bit - OK.
И моя мечта из прошлого сбылась: ATtiny13 в режиме отладки .

Для отладки AVR нужно переключаться в MPLAB X между режимами + включаем перемычку на плате MPLAB Snap. Описано во многих местах.