Будет происходить не "шопопало", а "шонаписано". Если МК зависает, это значит, что обработчик написан неправильно, и не более того. Наверное стоило не делать поспешный вывод, что вложенные прерывания невозможны, а проанализировать ситуацию и найти ошибку. У меня во многих устройствах выполняется sei в обработчике - и никаких "шопопало", работает как часы. Подозреваю, что "шопопало" возникало из-за превышения дозволенного уровня вложенности обработчиков...

Преведы бывают хоть на ассемблере, хоть на с хоть на чём! Если руки не оттуда.
Функциональность программы для МК - гм, изначально несколько более строго задаётся, чем функциональность программы для большого компьютера. Брать куски из одного проекта для другого - да. Расширять функциональность - это если плохое ТЗ.


Потому что многих жмёт пространство и время. Про коробочку размером с "крону" написано. Про время: попробуйте сделать хоть генератор текста для врезания в видеосигнал - будете считать циклы процессора. С карандашом в руках, совсем несложно.

На ассемблере преведов на порядок больше, и руки тут не при чем.
Зерно примитивов меньше - текста больше, сложность программы выше.
Программа получается ДУБОВАЯ - практически не подлежащая вразумительному расширению.


У кого как, мне важнее time-to-market и возможность заливать в одно и тоже железо разное ПО. Постепенно наращивать функциональность приходится - допустим выпустят новый Сепам или МРЗС и еще какую-то байду, добавить их к уже имеющейся прошивке нет проблем, и все управляющие устройства сразу умеют с ними работать. Надо только обновить прошивку.
За примерами далеко ходить не надо -
DVD/CD-RW - поддержка дисков разных производителей часто добавляется уже после выхода привода в продажу;
Wireless AP / Router'ы - добавление различных режимов и служб тоже происходит после.
и т.п.

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


Пространство меня не жмет. Хоть в медном тазу можно клепать, лишь бы крепилось на дин-рейку.
А про время, я вас умаляю. Ассемблеру с C не тягяться в этом.
Улыбнуло. ;>


Мне не нужен генератор врезки текста, но например в IP router я смогу при необходимости легко добавить telnet консольку или http сервер или фильтр какой-нить хитроумный.

А я наоборот как наполучал преведы на С (для АВР), так на асм перешёл. И С для АВР забыл как страшный сон (для компьютера конечно на С++ пишу). У АВР 80% работы - это работа с USART, CAN, SPI, таймерами, портами др. устройсвами. А в этом С только мешает. Напишешь на С и понимаешь, что написал программу на ассемблере с помощью С. Всё равно приходится весь получившийся ассемблерный текст контролировать.
А насчёт расширяемости:
1. Я сначала USB-HID написал и обращение через него к специфическим задачам.
2. Самопрограммирование через USB.
3. Всякие модбасы и др. USARTовские дела.
4. Mass Storage.
5. FAT (при работе без подключения к компьютеру).
6. SLEEP (работа от ионистора).
7. CAN.
Всё это работает в разных проектах в разных вариантах. В т.ч. и всё это в одном устройстве (на AT90CAN128). И прошивки без проблем через интернет обновляются самими пользователями. Причём они даже об этом иногда не знают.
Я всё это к тому, что и на асме и на С можно как плохо, так и хорошо писать.

Вместо того, чтобы найти их причину?

Нашёл несколько причин. Одна из них - несохранение С некоторых регистров в прерываниях. Искал долго т.к. вылезало редко, не во всех режимах, вылезало совсем в другом месте (в том месте которое было прервано после возврата с испорченными регистрами) и приводило к тому, что процессор выдавал на шину 1, а устройство 0. При этом происходило замыкание, срабатывала защита по питанию, срабатывал BOD, процессор перезапускался. Столько времени я бесполезно потерял... Понимаю, что в новых версиях это исправлено, но у меня уже какая-то аллергия на С для АВР выработалась. Мне всё кажется, что это глюк не мой, а С. А когда на асме пишу, то между мной и процессором никого нет... Макрокоманд для стандартных случаев понаписал. Если надо быстро сделать (и можно неоптимально), то макрокомандами пользуюсь. В принципе что-то типа своего языка на макрокомандах получилось.
ЗЫ Прошу прощения за офтоп.

Вот оно, ключевое слово:



ИМХО для этого всего avr-ки мягко говоря, слабоваты. Или есть примеры DVD-RW на любимой народом восьмой меге? Нет, не контроллер евонного двигателя, а весь DVD привод?


Прям представил медный таз, повешенный на DIN-рейку УмАлять меня не надо, и улыбаться про себя типа как Джоконда. Лучше расскажите, как на С написать обработчик прерывания, длиной, например, 10 тактов процессора.

Что есть такты и зачем именно 10? Что это даст?
Прерывания использую не ради тактов, а ради своевременной реакции на события системы. И мне производительности хватает.


Если пользовать все обработчики длиной в 10 тактов, то конечно AVRки будут слабоваты для всего.

+1

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

У меня тоже не зависает, проверено.
Пишу на С (gcc), как-то и особой отладки не разу не требовалось.

Вы просто не умеете их готовить

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

Не по теме, но не удержался Обработчик на gcc, для подсчета импульсов, например. count потом обрабатываем в основном цикле. И правда - зачем заморачиваться с ассемблером?

Сообщение отредактировал 733259 - Jun 15 2008, 10:04