да ни к чему это. проблемы сделать кольцо нет никакой, проблема с осознанием необходимости этого.COKPOWEHEU писал(а):Если хотите, могу выложить свою версию кольцевых буферов для UART'а.
А ее нет. И никто, кроме Вас о необходимости не говорил не слова.ARV писал(а):проблема с осознанием необходимости этого.
Не вижу ошибки проектирования. Более того, на мой взгляд, моё решение для такой задачи лучше. У меня во второй задаче элементарно сделать любую задержку независимо от таймера. Это удобно. Ведь может потребоваться задержка, скажем, 131 мксек или 217 мксек, может потребоваться варьировать задержкой по ситуации. В первой задаче таймер может быть задействован под другие задачи, например, ШИМ, и т. д. В моём решении это просто делается.ptr128 писал(а):Налицо ошибка проектирования. Ведь никто не мешал таймером всегда считать промежутки по 1мс, обеспечивая каждые тысячу отсчетов (раз в секунду) обработку управляющего сигнала. Зато любой процесс в МК имел бы возможность выполнить паузу любой продолжительностью, кратной 1мс.AQ29 писал(а):Следящая схема, в которой МК, например, раз в секунду по прерыванию таймера вырабатывает управляющий сигнал. А в перерывах МК выполняет какую-нибудь программу, где необходима задержка, скажем, на 10 мсек.
Вообще-то простые решения часто бывают надёжней.ptr128 писал(а):Очень упрощенный подход. Кольцевой буфер сообщений гибче и надежней.AQ29 писал(а): В большинстве случаев в программе обработки прерывания только устанавливаю программный флаг.
На мой взгляд, в некоторые «ворота вполне лезет».ptr128 писал(а):Вот именно про это я и говорю! Что точную задержку циклом Вы сделаете только ценой монополии на CPU, что ни в какие ворота не лезет.AQ29 писал(а): Для точной задержки прерывание можно запретить, тогда задержка с циклами будет выполняться с точностью до одного такта.
Не замечал, что АВР медленно реагирует на внешние события. И с задержками с точностью до такта не встречал особых проблем.scorpi_0n писал(а):Соглашусь с АРВ. Если нужны мгновенные реакции на внешние события или задержки с точностью до такта, то АВР действительно не та платформа. Задержки на циклах имеют право на жизнь только в одном случае - начальная инициализация каких-то устройств.
А баллы как выбираются, согласно личным впечатлениям или по какой-нибудь методике?ptr128 писал(а): Можно сравнивать эффективность нескольких вариантов решения. Делается табличка достоинств и недостатков каждого решения. Варианты решения в заголовках столбцов. Анализируемые характеристики решений - в строках. Проставляем баллы по каждому пункту, во всех колонках, в зависимости от важности этой характеристики в данном случае. По сумме баллов определяем, какое решение эффективней.
AQ29 писал(а):Следящая схема, в которой МК, например, раз в секунду по прерыванию таймера вырабатывает управляющий сигнал. А в перерывах МК выполняет какую-нибудь программу, где необходима задержка, скажем, на 10 мсек.
ptr128 писал(а):Налицо ошибка проектирования. Ведь никто не мешал таймером всегда считать промежутки по 1мс, обеспечивая каждые тысячу отсчетов (раз в секунду) обработку управляющего сигнала. Зато любой процесс в МК имел бы возможность выполнить паузу любой продолжительностью, кратной 1мс.
Поясняю. Проектирование программ с задержками в 10 миллисекунд и 130 микросекунд (разница в 2 порядка) выполняется по разному.AQ29 писал(а):Не вижу ошибки проектирования.
Ведь может потребоваться задержка, скажем, 131 мксек или 217 мксек
Очень частный случай. Давайте все же считать общим случаем то, с чего начинали. Когда Вы уже используете все три таймера, а значит в Вашей программе может происходить не одно, а не меньше трех асинхронных событий.AQ29 писал(а):На мой взгляд, в некоторые «ворота вполне лезет».ptr128 писал(а):точную задержку циклом Вы сделаете только ценой монополии на CPU, что ни в какие ворота не лезет.
AQ29 писал(а):А баллы как выбираются, согласно личным впечатлениям или по какой-нибудь методике?
ptr128 писал(а):Проставляем баллы по каждому пункту, во всех колонках, в зависимости от важности этой характеристики в данном случае.
анекдот, правда, уже старый.ptr128 писал(а): Примитивная поддержка мультизадачности появилась только на 386. Полноценная - существенно позднее.
Любая работа сARV писал(а):ваши экзотические задачи попадают в те проценты, когда я не возражаю против буферизации
например, GPS: один раз в секунду передается пакет текстовых строк, максимальная длина строки ограничена 80 байтами. стандартная скорость передачи - 4800 бод, но сейчас чаще стандартно 9600, а можно настроить и на бОльшую скорость. так как всегда интересует какая-то конкретная строка из пакета, а не все подряд, требуется дождаться начала нужной строки, принять ее, и потом тупо игнорировать все данные - сколько бы их ни было! - в течение примерно 800-1000 миллисекунд. вы считаете, что эта задача как раз из тех "любых", которые просто невозможно решить без кольцевого буфера? простой линейный буфер в 80 байт, и никаких проблем! и никакого страха что-либо пропустить. кольцо не даст вообще никаких преимуществ в данном случае. если использовать достаточно высокую тактовую частоту МК, можно вообще без всяких буферов распарсивать приходящие данные на лету... но это уже на любителя острых ощущений.COKPOWEHEU писал(а):Любая работа
ARV писал(а):невозможно решить
ptr128 писал(а):Любая проблема имеет, как минимум, два решения.
Что, например, для ATTiny2313 составит почти 2/3 доступной RAMARV писал(а):простой линейный буфер в 80 байт
Больше 38400 мало какие SiRF поддерживают. Меньше 10 бит на байт не получится (1 старт, 1 стоп, 0 четности). Итого, нам надо забирать байты, в среднем, каждые 260мкс, с допустимой однократной максимальной задержкой не более 520мкс, благодаря однобайтной буферизации в UART. При частоте даже в 1МГц - это порядка 200 машинных команд. У меня получается, что даже на С, без ассемблера (хотя тема по ассемблеру!), за 200 команд можно не только полностью распарсить сообщение, но еще даже успеть начать что-то выводить по результатам его парсинга.ARV писал(а):можно настроить и на бОльшую скорость
SPI на UART с частотой Fclk/2. В среднем 16 тактов на байт. Примерно 10-12 команд. Так как это SPI - то 10-12 команд и на отправку и на прием байта.ARV писал(а):я не могу припомнить ни одного, где остро стояла бы проблема обработки данных UART-а
Где я писал что кольцевой буфер - единственное решение всех проблем? Впрочем, даже и так, его использование не навредит. Данные в любом случае надо принять и где-то хранить, а кольцевой буфер можно настроить чтобы он не игнорировал свежие данные, а перезаписывал ими старые.ARV писал(а):например, GPS
...
вы считаете, что эта задача как раз из тех "любых", которые просто невозможно решить без кольцевого буфера?
А вот с этим ничего не поделаешь если надо хранить строку целиком. Реализовать парсинг "на лету" может оказаться еще сложнее.Что, например, для ATTiny2313 составит почти 2/3 доступной RAMARV писал(а): простой линейный буфер в 80 байт
Это если контроллер ничего другого не делает и если данные вообще возможно парсить на лету.У меня получается, что даже на С, без ассемблера (хотя тема по ассемблеру!), за 200 команд можно не только полностью распарсить сообщение, но еще даже успеть начать что-то выводить по результатам его парсинга.
200 команд на один принятый байт - очень много. Причем я считал для минимальной частоты 1МГц. Не для 16 и даже не для 8. Еще на пару прерываний команд по 50 хватит. Если конечно не преобразовывать здоровенные десятичные числа в двоичные. Но в данном случае такой необходимости явно нет. Даже без команды двоично-десятичной коррекции с упакованными десятичными числами на AVR вполне реально управляться.COKPOWEHEU писал(а):Это если контроллер ничего другого не делает и если данные вообще возможно парсить на лету.
я и говорил, что любую задачу можно так сформулировать, что ее и решить будет невозможно.COKPOWEHEU писал(а):Например, надо по строке с UART'а "Read_ADC_0" считать АЦП, преобразовать в 4-байтный float и вывести обратно, причем сам АЦП работает на максимальной частоте и усредняется.
Вы, похоже, даCOKPOWEHEU писал(а):Ну мы же сейчас обсуждаем сферических коней.
И впрямь "сферический конь". Какой смысл максимум 12-тибитное значение ADC преобразовывать на ассемблере в четырех байтный float только для того, чтобы потом опять на ассемблере преобразовывать его в десятичное для передачи по UART в строковом виде?COKPOWEHEU писал(а):Например, надо по строке с UART'а "Read_ADC_0" считать АЦП, преобразовать в 4-байтный float и вывести обратно, причем сам АЦП работает на максимальной частоте и усредняется.
Зачем Вам float на ассемблере? Тем более для хранения 12-ти битного целого числа!ARV писал(а):преобразовывать во float
Задача ARV в 4 раза менее требовательна к скорости. С GPS дела не имел, но насколько только что прочитал, логично либо считывать всю строку в буфер (как делает ARV), либо считывать ее часть, достаточную для анализа фрагмента - строки описания, строки широты, долготы или времени. Но вот идея анализировать побайтно, вообще без буфера, не кажется особо удачной.Я обсуждаю cовершенно конкретную задачу парсинга данных GPS трекера на 38400 бодах ассемблером AVR при частоте CPU 1Мгц.
АЦП в AVR всего 10 бит. А у внешних может быть любой. Что до float'а, при достаточном диапазоне измерения (скажем, от микровольт до киловольт), переключаемым снаружи резистивными делителями или усилителями, для приемника может быть удобно получать значение вида 1.28e-3V. Разумеется, речь опять о сферических конях.Какой смысл максимум 12-тибитное значение ADC преобразовывать на ассемблере в четырех байтный float только для того, чтобы потом опять на ассемблере преобразовывать его в десятичное для передачи по UART в строковом виде?
Что Вам мешает внутри МК оперировать милливольтами или вообще абстрактными "попугаями" целочисленной арифметикой, а уже пользователю выводить данные в удобном ему виде?COKPOWEHEU писал(а):Что до float'а, при достаточном диапазоне измерения (скажем, от микровольт до киловольт), переключаемым снаружи резистивными делителями или усилителями, для приемника может быть удобно получать значение вида 1.28e-3V. Разумеется, речь опять о сферических конях.
Код: Выделить всё
uint8_t BCDinc(uint8_t i)
{
uint8_t res;
uint8_t corr=6;
asm volatile (
"mov %res, %i" "\n\t" \
"inc %res" "\n\t" \
"brhc label1%=" "\n\t" \
"add %res,%corr" "\n\t" \
"label1%=:" "\n\t" \
"nop" "\n\t"
);
return res;
}
Алгоритм не верен. После инкремента мы должны контролировать не только наличие переноса между полубайтами, но еще и то, что в младшем полубайте не возникло значения большего 9. Точнее, если у нас уже было корректное двоично-десятичное число, то перенос между полубайтами вообще при инкременте не может возникнуть, а вот 0x9 в младшем полубайте просто обязан превратиться в 0xA.prinv писал(а):Функция инкремента двоино-десятичного числа
С этим проще. Но исправленный код по вышеописанной причине работать не будет.prinv писал(а):при компилировании получаю ворох ошибок.
Код: Выделить всё
uint8_t BCDinc(uint8_t i)
{
uint8_t res;
asm volatile ( "; \n\t \
mov %[res], %[i] \n\t \
inc %[res] \n\t \
brhc label1%= \n\t \
add %[res],%[corr] \n \
label1%=: \n\t \
nop \n \
"
: [res] "=r" (res)
: [i] "r" (i), [corr] "r" (6)
: "cc" );
return res;
}
Сколько еще раз мне повторить что у меня такой задачи не возникало, я ее привел только в качестве примера?Что Вам мешает внутри МК оперировать милливольтами или вообще абстрактными "попугаями" целочисленной арифметикой, а уже пользователю выводить данные в удобном ему виде?
Особенно на ассемблере AVR, для которого float совершенно чуждое и инородное понятие.
Читайте документацию по avr-libc. Там есть и ассемблерные вставки и использование файлов ассемблерного кода средствами gcc (точнее, gnu-as + ld). В том числе, какие регистры программист обязан сохранять, а какими занимается gcc.Посмотрите, пожалуйста, мой первый опыт по скрещиванию Си и ассемблера AVR
Код: Выделить всё
Довольно неплохая статейка по этому поводу тут: http://imrannazar.com/Binary-Coded-Deci ... -Atmel-AVR