Пт дек 23, 2016 06:55:28
да ни к чему это. проблемы сделать кольцо нет никакой, проблема с осознанием необходимости этого.COKPOWEHEU писал(а):Если хотите, могу выложить свою версию кольцевых буферов для UART'а.
Пт дек 23, 2016 11:52:54
ARV писал(а):проблема с осознанием необходимости этого.
Пт дек 23, 2016 20:35:26
ptr128 писал(а):AQ29 писал(а):Следящая схема, в которой МК, например, раз в секунду по прерыванию таймера вырабатывает управляющий сигнал. А в перерывах МК выполняет какую-нибудь программу, где необходима задержка, скажем, на 10 мсек.
Налицо ошибка проектирования. Ведь никто не мешал таймером всегда считать промежутки по 1мс, обеспечивая каждые тысячу отсчетов (раз в секунду) обработку управляющего сигнала. Зато любой процесс в МК имел бы возможность выполнить паузу любой продолжительностью, кратной 1мс.
ptr128 писал(а):AQ29 писал(а):В большинстве случаев в программе обработки прерывания только устанавливаю программный флаг.
Очень упрощенный подход. Кольцевой буфер сообщений гибче и надежней.
ptr128 писал(а):AQ29 писал(а):Для точной задержки прерывание можно запретить, тогда задержка с циклами будет выполняться с точностью до одного такта.
Вот именно про это я и говорю! Что точную задержку циклом Вы сделаете только ценой монополии на CPU, что ни в какие ворота не лезет.
scorpi_0n писал(а):Соглашусь с АРВ. Если нужны мгновенные реакции на внешние события или задержки с точностью до такта, то АВР действительно не та платформа. Задержки на циклах имеют право на жизнь только в одном случае - начальная инициализация каких-то устройств.
ptr128 писал(а):Можно сравнивать эффективность нескольких вариантов решения. Делается табличка достоинств и недостатков каждого решения. Варианты решения в заголовках столбцов. Анализируемые характеристики решений - в строках. Проставляем баллы по каждому пункту, во всех колонках, в зависимости от важности этой характеристики в данном случае. По сумме баллов определяем, какое решение эффективней.
Сб дек 24, 2016 00:46:08
AQ29 писал(а):Следящая схема, в которой МК, например, раз в секунду по прерыванию таймера вырабатывает управляющий сигнал. А в перерывах МК выполняет какую-нибудь программу, где необходима задержка, скажем, на 10 мсек.
ptr128 писал(а):Налицо ошибка проектирования. Ведь никто не мешал таймером всегда считать промежутки по 1мс, обеспечивая каждые тысячу отсчетов (раз в секунду) обработку управляющего сигнала. Зато любой процесс в МК имел бы возможность выполнить паузу любой продолжительностью, кратной 1мс.
AQ29 писал(а):Не вижу ошибки проектирования.
Ведь может потребоваться задержка, скажем, 131 мксек или 217 мксек
AQ29 писал(а):ptr128 писал(а):точную задержку циклом Вы сделаете только ценой монополии на CPU, что ни в какие ворота не лезет.
На мой взгляд, в некоторые «ворота вполне лезет».
AQ29 писал(а):А баллы как выбираются, согласно личным впечатлениям или по какой-нибудь методике?
ptr128 писал(а):Проставляем баллы по каждому пункту, во всех колонках, в зависимости от важности этой характеристики в данном случае.
Сб дек 24, 2016 13:19:46
анекдот, правда, уже старый.ptr128 писал(а): Примитивная поддержка мультизадачности появилась только на 386. Полноценная - существенно позднее.
Сб дек 24, 2016 14:39:42
Любая работа сARV писал(а):ваши экзотические задачи попадают в те проценты, когда я не возражаю против буферизации
Сб дек 24, 2016 19:31:17
например, GPS: один раз в секунду передается пакет текстовых строк, максимальная длина строки ограничена 80 байтами. стандартная скорость передачи - 4800 бод, но сейчас чаще стандартно 9600, а можно настроить и на бОльшую скорость. так как всегда интересует какая-то конкретная строка из пакета, а не все подряд, требуется дождаться начала нужной строки, принять ее, и потом тупо игнорировать все данные - сколько бы их ни было! - в течение примерно 800-1000 миллисекунд. вы считаете, что эта задача как раз из тех "любых", которые просто невозможно решить без кольцевого буфера? простой линейный буфер в 80 байт, и никаких проблем! и никакого страха что-либо пропустить. кольцо не даст вообще никаких преимуществ в данном случае. если использовать достаточно высокую тактовую частоту МК, можно вообще без всяких буферов распарсивать приходящие данные на лету... но это уже на любителя острых ощущений.COKPOWEHEU писал(а):Любая работа
Сб дек 24, 2016 20:12:48
ARV писал(а):невозможно решить
ptr128 писал(а):Любая проблема имеет, как минимум, два решения.
ARV писал(а):простой линейный буфер в 80 байт
ARV писал(а):можно настроить и на бОльшую скорость
ARV писал(а):я не могу припомнить ни одного, где остро стояла бы проблема обработки данных UART-а
Сб дек 24, 2016 22:40:21
Где я писал что кольцевой буфер - единственное решение всех проблем? Впрочем, даже и так, его использование не навредит. Данные в любом случае надо принять и где-то хранить, а кольцевой буфер можно настроить чтобы он не игнорировал свежие данные, а перезаписывал ими старые.ARV писал(а):например, GPS
...
вы считаете, что эта задача как раз из тех "любых", которые просто невозможно решить без кольцевого буфера?
А вот с этим ничего не поделаешь если надо хранить строку целиком. Реализовать парсинг "на лету" может оказаться еще сложнее.ARV писал(а):простой линейный буфер в 80 байт
Что, например, для ATTiny2313 составит почти 2/3 доступной RAM
Это если контроллер ничего другого не делает и если данные вообще возможно парсить на лету.У меня получается, что даже на С, без ассемблера (хотя тема по ассемблеру!), за 200 команд можно не только полностью распарсить сообщение, но еще даже успеть начать что-то выводить по результатам его парсинга.
Сб дек 24, 2016 23:03:52
COKPOWEHEU писал(а):Это если контроллер ничего другого не делает и если данные вообще возможно парсить на лету.
Вс дек 25, 2016 01:13:38
Вс дек 25, 2016 07:57:34
я и говорил, что любую задачу можно так сформулировать, что ее и решить будет невозможно.COKPOWEHEU писал(а):Например, надо по строке с UART'а "Read_ADC_0" считать АЦП, преобразовать в 4-байтный float и вывести обратно, причем сам АЦП работает на максимальной частоте и усредняется.
Вс дек 25, 2016 09:56:16
COKPOWEHEU писал(а):Ну мы же сейчас обсуждаем сферических коней.
COKPOWEHEU писал(а):Например, надо по строке с UART'а "Read_ADC_0" считать АЦП, преобразовать в 4-байтный float и вывести обратно, причем сам АЦП работает на максимальной частоте и усредняется.
ARV писал(а):преобразовывать во float
Вс дек 25, 2016 13:36:28
Я обсуждаю cовершенно конкретную задачу парсинга данных GPS трекера на 38400 бодах ассемблером AVR при частоте CPU 1Мгц.
АЦП в AVR всего 10 бит. А у внешних может быть любой. Что до float'а, при достаточном диапазоне измерения (скажем, от микровольт до киловольт), переключаемым снаружи резистивными делителями или усилителями, для приемника может быть удобно получать значение вида 1.28e-3V. Разумеется, речь опять о сферических конях.Какой смысл максимум 12-тибитное значение ADC преобразовывать на ассемблере в четырех байтный float только для того, чтобы потом опять на ассемблере преобразовывать его в десятичное для передачи по UART в строковом виде?
Вс дек 25, 2016 13:48:28
COKPOWEHEU писал(а):Что до float'а, при достаточном диапазоне измерения (скажем, от микровольт до киловольт), переключаемым снаружи резистивными делителями или усилителями, для приемника может быть удобно получать значение вида 1.28e-3V. Разумеется, речь опять о сферических конях.
Вс дек 25, 2016 17:36:38
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;
}
Вс дек 25, 2016 18:11:25
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;
}
Вс дек 25, 2016 18:22:57
Вс дек 25, 2016 18:38:07
Сколько еще раз мне повторить что у меня такой задачи не возникало, я ее привел только в качестве примера?Что Вам мешает внутри МК оперировать милливольтами или вообще абстрактными "попугаями" целочисленной арифметикой, а уже пользователю выводить данные в удобном ему виде?
Особенно на ассемблере AVR, для которого float совершенно чуждое и инородное понятие.
Читайте документацию по avr-libc. Там есть и ассемблерные вставки и использование файлов ассемблерного кода средствами gcc (точнее, gnu-as + ld). В том числе, какие регистры программист обязан сохранять, а какими занимается gcc.Посмотрите, пожалуйста, мой первый опыт по скрещиванию Си и ассемблера AVR
Пн дек 26, 2016 20:12:03
Довольно неплохая статейка по этому поводу тут: http://imrannazar.com/Binary-Coded-Deci ... -Atmel-AVR