nik1234

Зачем выводить очередной разряд индикации в прерывании? Процессы вывода на индикацию и считывания клавиатуры - медленные процессы. В моей концепции: войдите в подпрограмму обслуживания индикатора, сделайте делитель на 2 и получите 2 мс на разряд, в этой же подпрограмме выведете очередной разряд на индикатор, и не надо отрывать время процессора на обработку прерывания. Для вывода на индикацию тогда вообще не нужно прерывания. Аналогично для кнопок. В моей концепции нужно лишь одно прерывание для таймера. Прерывания с обработкой в прерывании нужны в основном для УАРТА, для безпаузной передачи / приема на высоких скоростях. Ну может быть и2с или спиай, там тоже нужна высокая скорость обработки. вторичные таймеры / счетчики также прекрасно вписываются в предложенную концепцию. Самый большой ее плюс, то что время на прерывание минимально для медленных задач, и отсутствуют конфликты прерываний. А впрочем... у каждого свой путь... А зачем в блоке питания так часто измерять напряжение и ток, если это вывод на индикацию, то там и десяти измерений в секунду за глаза хватит. Резких скачков всеравно не отследить, выходной конденсатор все сгладит.

Про флаг Т: если он не используется в основной программе, а у меня он постоянно в деле. для меня меня отложенная обработка прерывания обычное дело, нужно лишь правильно расставить приоритеты частей программы. И обычное дело: выставляешь частоту задающего генератора побольше, делишь его до получения частоты 1000 Гц каким либо таймером, загоняешь в прерывание с флагом. затем закольцовываешь основную программу с проверкой флага прерывания от таймера 1000Гц. загоняешь программу в Sleep. Получаешь кольцо обработки с образцовым интервалом в 1 мс. После любого прерывания проверяешь флаг от таймера, если он, то сбрасываешь флаг и начинаешь перебирать подпрограммы обработки индикаторов, клавиатуры, и тд. и тп, подпрограммы обработки флагов и др. После окончания обработки всех подпрограмм возвращаешься к Sleep. И так по кольцу. Если происходит прерывание не от таймера, программа выходит из Sleep, проверяется флаг от таймера, если не он (а это не он) обратно к Sleep. В большенстве программ использую этот алгоритм. GPIOR1 и GPIOR2 в 88 условно можно использовать как флаги, но их адреса больше 0х1Е, на них не распространяются команды cbi, sbi, sbic, sbis, и их сначала нужно загрузить в общий регистр, промодифицировать, и заново сохранить. Эта последовательность длинная, и модифицирует SREG, что сводит на нет работу по сравнению с классическим GPIOR.

О, это очень полезные регистры! в 88 только GPIOR0 сохранил свои полезные свойства. использую их как флаги событий прерываний. для GPIOR0 адрес порта ввода-вывода 0х1Е, а значит к нему применяются команды cbi, sbi, sbic, sbis ну и in, out. Когда происходит прерывание, процессор переходит на адрес обработки прерывания, вот там-то мы и располагаем код: sbi GPIOR0, 0 ;установить в 1 бит 0 в регистре GPIOR0 reti ;вернуться из прерывания Без использования регистра GPIOR0, а с использованием обычного регистра код выглядел бы иначе: push R0 ;освобождаем регистр R0 для SREG и сохраняем его in R0, SREG ;сохраняем SREG в R0, все флаги операций текущей программы sbr R23, 1<<0 ;выставляем флаг признака прерывания, например бит 0 в регистре R23 out SREG, R0 ;восстанавливаем SREG, все флаги операций текущей программы pop R0 ;восстанавливаем значение R0 reti ;вернуться из прерывания Нетрудно заметить......! А, да команда: sbr R23, 1<<0 в идеале изменяет флаги в SREG, потому и такая длинная цепочка команд. Далее, из всего сказанного выше... в АТмега8 до адреса ввода / вывода 0x1F, находятся некоторое количество регистров, которые крайне редко (...никогда...) используются, например: TWBR, TWSR, TWAR, SPCR, ....... их можно (... нужно...) использовать как GPIOR регистр. До связи.

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

А да, точно GPIOR 1 и 2 вообще выпадают из концепции побитового доступа! 88 это уже микрочиповское изделие. А WDT нужно в хелпе просто указать, что нельзя программировать и не париться с перепрограммированием. Я вообще никогда не занимался загрузчиками, не было задач, а тут вдруг "повезло"! На этих чипах, с маленькой памятью и низкой частотой работы только мелкие задачи решать. И на ассемблере программа получается более "гибкая" чем на С.

К 15 версии замечаний нет. К 20 версии претензий нет. СПАСИБО ВАМ за гигантскую, проделанную Работу!!!

Да, сначала был написан бутлодер для тини 24. Там нет выделенной памяти под бутлодер и заморочек с областями откуда можно записывать и перезаписывать флеш из программы, там все просто! Также там нет УАРТА, пришлось написать. Ну и самое главное: перезаписывай любые страницы флеш из любого места! В тини 24 под бутлодер ушло 48% памяти. В проекте технологи выделили слишком мало физического места под схему. Потом развел плату, оказалось, что места не так уж и мало. Потом выяснилось, что пинов впритык, и если будет дальнейшее расширение, их может не хватить. И после долгих (ну очень долгих) изысканий (цена, доступность, размеры) остановился на 88 (очень низкая цена, корпус чуть больше чем у 24, датчик температуры, а это важно, но не критически). Да, и сейчас все программируют на С и др. языках высокого уровня, что занимает очень (ну очень) много места, и чипы с небольшой памятью остаются не востребованы, и как следствие низкий спрос, и низкая цена!!! И при тупом переносе программы перезаписи страниц флеш программа не заработала... Ну и пошли изыскания, и я набрел на ВАШ проект, самый полный и законченный на то время. Нужно было выяснить чип который был у меня битый или я что-то упустил при программировании? (в бутлодерах я новичек) Недостаток 88 на сегодня, то что из пользовательской памяти нельзя перепрограммировать флеш, хотя страница стирается. По поводу ВАШЕЙ программы: выяснилось, что при включенном фьюзе WDT в конфигурации, соединение не устанавливается, а в хелпе это не отражено. В некоторых ситуациях соединение можно восстановить лишь отключив / включив питание, сброс через ножку ресет не помагает. Будем копать дальше,... и глубже....! Иногда при "установить соединение" выдается сообщение, "соединение не установлено", а на осциллографе виден ответ с чипа?

Посмотрим, потрогаем, проверим...

У меня нет команд приема от МК, я использую транзакцию "передал 12 байт / принял 12 байт" всегда. Если не принял 12 байт за отведенный промежуток времени с перезапросами(не более 3х раз), то "ошибка связи". команды: 1 -16. Записать в буфер по адресу "А" 8 байт, ответ те-же 8 байт для проверки. буфер 128 байт. Чтобы заполнить буфер в 128 байт необходимо 16 транзакций. 17. Прочитать из буфера 8 байт по адресу "А", данные любые, ответ 8 байт. Необязательная команда, используется для проверки. 18. Записать во флеш буфер по адресу "Е", ответ: данные любые, флаг верификации записи либо 0 (без ошибок), либо 1 (ошибка записи). 19. Прочитать 8 байт из флеш по адресу "Е", ответ: данные из флеш для верификации. Необязательная команда. 20. Записать в ЕЕПРОМ один байт по адресу "Р", ответ: данные любые, флаг верификации записи либо 0 (без ошибок), либо 1 (ошибка записи). 21. Прочитать 8 байт из ЕЕПРОМ по адресу "Р, ответ: данные из ЕЕПРОМ для верификации. Необязательная команда. 22. Прочитать версию, дату бутлодера, название используемого МК, начальный адрес бутлодера для ATtiny 24/44/84.

Так, ну ладно,... забудем про сигнатуры.... И так,... как я вижу Программу. Программа состоит из двух файлов: экзешника и хелпера, а лучше одного экзешника, чтобы не путаться в обилии файлов в директории. Можно выбрать номер кома и его скорость, тип МК, а также другие вспомогательные парметры,..... и ... большая красная кнопка "сгенерировать Бутлодер", при нажатии которой, создается файл Бутлодера, с соответствующим именем. Внутри файла Бутлодера несколько байт выделено для названия МК, которые возможно считать Программой, и которые в дальнейшем определяют модель работы Программы с Бутлодером, чтобы не путать пользоваетля. Сделать относительно короткими пакеты обмена между Программой и Бутлодером, чтобы избежать длительных зависаний. Конечно это увеличит общее время записи, ну мы же никуда не спешим. Добавить команду считывания названия МК из Бутлодера, что кажется мне самым важным. Да, как я организую процесс записи флеш: заполняю буфер несколькими командами, запускаю команду записать страницу. МК принимает данную команду, декодирует и запускает стирание страницы, дожидается окончания процесса стирания страницы (<5 мс, ЦПУ остановлено), запускает запись страницы (<5 мс, ЦПУ остановлено), осуществляет проверку записанных данных на странице(верификация) и посылает ответ ПК с флагом проверки данных.(Это все из дата шита). Запись в еепром производится побайтно в каждой комманде. (ну мы же никуда не спешим). При записи в еепром считываются данные из ячейки, и если они совпадают с теми, что нужно записать, то запись не осуществляется. В противном случае запускаем запись данных в ячейку (<5 мс), ждем окончания записи , осуществляем проверку записанных данных в еепром(верификация) и посылаем ответ ПК с флагом проверки данных. Ну как-то так крупными мазками. И да, существует два типа Бутлодеров, написанных с применением прирываний, и без прирываний. объем без прерываний как ни странно меньше.

по поводу чтения сигнатур: 31.8.10. Reading the Signature Row from Software. регистр SPMCSR, бит SIGRD.

у меня длина пакетов туда и обратно составляет фиксированные 12 байт: 8 данные, 1 команда или флаги операций, остальные контрольная сумма и кодеры пакета (шифрование). И тройной перезапрос со стороны ПС в случае отсутствия ответа от МК. При сборе статистики обмена, в среднем на 70 транзакций приходится один перезапрос, но не более 2 раз. После трех безуспешных перезапросов, программа выдает ошибку соединения.

По поводу времени ожидания последовательного порта. В случае обмена пакетами разной длинны, времени ожидания последовательного порта изменяется в соответствии с длинной пакета. Ну и подразумевается, что байты в пакете передаются без пауз (обусловлено тем, передача ведется через контроллер прямого доступа к памяти [ПДП]). А учитывая, что бутлодер только тем и занят, что принимает данные с последовательного порта, а затем записывает во флеш или еепром (время записи не более 5 мс), ответ МК на пакет данных от ПС не должен составлять большого времени (<10мс). мне кажется здесь кроется какое-то логическое несоответствие.

А я считал, что ВЫ появитесь не раньше 23 апреля. Выяснил, почему последний купленный чип (ATmega88), такой дешевый. При записи в ЕЕПРОМ по СРИАЙ постранично (4 байта на страницу) в некоторых страницах не записываются некоторые байты. Хотя при записи по одному байту все пишется без ошибок.

Несколько изменив программы, можно отказаться от выбора МК. В моих бутлодерах (ATtiny24, ATtiny44, ATmega88) присутствует команда чтения идентификатора чипа. При считывании известного идентификатора программатор сам устанавливает модель взаимодействия с бутлодером.