Цитата(xelax @ Mar 3 2008, 08:59)
И когда решил применить свой код к UARTу, который стоял на материнке, то к удивлению аппаратные FIFO буферы, документированные для микросхемы, заработали и на материнке.
Насколько я помню, были чипы 16450 без FIFO, 16550 с глючным FIFO и 16550A с поправленным. И не помню - можна ли было определить разницу между 16550 и 16550А программно.
В свойствах порта у винды можна было поставить/снять галку "использовать FIFO" и подвигать ползунки порога прерывания на приём и передачу - может, просто в Вашем случае драйвер сам не понял, стоит у него чип с нормальным FIFO или с глючным и галка по умолчанию была снята.
Я сам иногда снимал, когда приходилось работать с чужим оборудованием с встроенной программой, которая захлёбывалась, если от компа валил "зафифошенный" поток без пауз.
Цитата(xelax @ Mar 3 2008, 08:59)
Посмотрел дизасм кода калибровки в раличных режимах оптимизации. В -O0 она действительно 7 тактов, а при -Os я так и не смог в процедуре понять где она эта калибровка начинается, а где заканчивается, но есть большое подозрение, что она уже не 7 тактов.
А зачем было вообще так делать? Сделайте так:
Прерывание по таймеру2, когда он отсчитал нужное число циклов (причём это можно делать не только при старте, см. мой предыдущий пост), в этом прерывании чтение нового состояния таймера1, определение дельты с предыдущим состоянием таймера1 и подкоррекция OSCCAL прямо в прерывании. Разброс времени входа в прерывание чепуха по сравнению с периодом прерываний, RC-генератор всё равно грубее шаг имеет. Я метки времени от внешних часов даже не на ICP заводил а на обычное прерывание, смысла нет выжимать лучше нескольких сот микросекунд на фоне 0,5секунды (это 0,1%, куда тому RC).
И никакой зависимости от оптимизатора (если работа программы зависит от установленного уровня оптимизации компилятора, то в 99.9% случаев это ляп или как минимум недоработка разработчика программы).
Портится старший бит при приёме через UART, atmega1281
Feb 29 2008, 07:10
