Есть вот такая интересная функция задержки времени.
Сначала задается:
ldi AL, 125
Потом вызывается сама функция:
dly:
mov _Stm1, AL
tst _Stm1
brne PC-1
ret
При кварце в 10 МГц задержка выходит примерно в 500 мс.
Вопрос - как это работает, а именно, что постепенно обнуляет регистр _Stm1?

Очевидно, прерывание; предположительно, по таймеру.

Я бы сказал, что функция не интересная, а наоборот - тупая. Зачем использовать прерывание, если все равно выхода из функции не будет пока переменная _Stm1 не обнулится?

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

Не следует делать скоропалительных выводов.
Я иногда примерно так делал для формирования точных но больших временных интервалов. Скорее всего данное прерывание используется совсем не для этого. А это, так сказать, лишь мелкий довесок, - одна команда. Как правило когда используются в программе различные временные метки, то я их все формирую в одном прерывании по таймеру. Чем меньше в программе прерываний (учитывая отсутствие ранжирования), тем проще работать.

Я не хочу здесь начинать спорить о стилях программирования, я просто высказал мнение по поводу приведенного выше кода, и мнение мое однозначно.

))))))))))))))))))))))))))Нонсенс...

В данном случае я имел ввиду "дублирующих или бесполезных прерываний". Зачем плодить 10 прерываний от таймера для формирования различных задержек?

Представьте себе что Вы обрабатываете канал информации. И недопустимы слишком большие задержки на обработку этого канала. У меня не более 250мкс. Вам надо кроме этого канала обработать прерывание от последовательного порта и сформировать следующие задержки: 1cек, 0.1сек, 20мс, 0.25сек, 8мс. При этом по некоторым из задержек приходится одновременно отсчитывать несколько интервалов.
Вы как по каждому интервалу свой таймер заводите?

Извините, но я избегаю ответов типа "однозначно" или "нонсенс". Это сродни "этого не может быть потому что этого я не могу себе представить". Я вовсе не защищаю автора той программы. Я её не видел. Но программирование мне нравится за то, что любую задачу можно решить десятком способов! И я отнюдь не уверен что Ваш, - самый правильный.

Известно, что о вкусах не спорят, но зачем постоянно торчать в этом месте, если можно заходить время от времени (для максимальной точности - с интервалом прерываний или чаще) и делать

вместо

А пока идет выдержка поделать еще что-нибудь полезное.

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


ну я тогда тоже выскажу свое мнение:
вполне грамотная организация задержки. которая к тому же будет работать намного точнее чем __delay_cycles в совокупности с кучей прерываний.

Так, так...И в каком же месте она точнее?

Люблю послушать грамотеев)

prottoss
к чему ирония? разумеется, измерение отрезка времени таймером точнее, чем с помощью цикла, неизвестно на сколько времени продлённого разнообразными возникающими по ходу работы прерываниями.

Интересно, а если у нас вся работа происходит в прерываниях, то что мы будем
делать, в то время пока не произошло интересуещее нас событие (ИМХО, ковырять в носу в
каком-нибудь пустом цикле ).

Так и я о том же, а уважаемый defunct пытается доказать обратное

Кто то ковыряет в носу, а кто то спокойно спит)))

Угу, а если после наступления события нам необходимо очень оперативно отреагировать ?
Типа, реалтайм какой-нибудь, а событие такое что выход из sleep не прикрутить ?
Дальше "спокойно спим".
Уважаемый prottoss, если Вы умеете делать выводы о коде на основании
5-6 команд на ассемблере, то вероятно вы выбрали не ту профессию, возможно Вас ждет
большой успех в области ясновидения.

P.S. без обид пожалуйста

Что Вы, какие обиды) Я просто стараюсь не обращать внимание на глупые реплики подобные вашим... Я всего лишь сказал, что не вижу смысла делать задержку на прерывании, если выхода из функции все равно нет! Раз уж все накинулись на меня скопом) давайте найдем истину). Вот обсуждаемый код:



Потоки, работающие по прерываниям и так отработают свое.. О какой точности идет речь? Между tst _Stm1 и brne PC-1 может возникнуть прерывание, которое сведет всю вашу точность на нет. И, наконец, можете описать, или придумать, хотя бы одну ситуацию, где нельзя прикрутить sleep хотя бы в режиме idle?

Можно, но это сути не меняет.

Давайте просто проэкспериментируем:

Итак условия задачи:
atmega8, частота 14372800
16-ти битный таймер занят, ну например, "опросом датчиков". То есть режим CTC, прерывание 4мс.
В голове надо сформировать следующую диаграму на порт b.outx
"1" - 500мс, "0" - 300мс, "1" - 200мс, "0"

По версии НЕИЗВЕСТНОГО АВТОРА это выглядело примерно так.

1) Версия ассемблера atmel.

В прерывании
.....
dec cnt_ms
.....

В голове
.....

.equ wt_tim1 = 4 ; 4ms

....
.macro setout ; задать таймаут
ldi cnt_ms,@0/4 ; установить время таймаута
tst cnt_ms
brne PC-1
.endm

.....
sbi portb,outx
setout 500
cbi portb,outx
setout 300
sbi portb,outx
setout 200
cbi portb,outx
......

Подведём итоги:
Задействовано регистров - 1
стек - 0
длина проги в прерывании - 2байта/1такт
общая длина проги - 28 байт
число строк программы - 14
==================================================

Попробуем на С


В прерывании
.....
cnt_ms--;
.....

В голове
.....

#define wt_tim1 = 4 // 4ms


.....
PORTB |= (1<<OUTX);
cnt_ms = 500/wt_tim1;
while(cnt_ms);
PORTB &= ~ (1<<OUTX);
cnt_ms = 300/wt_tim1;
while(cnt_ms);
PORTB |= (1<<OUTX);
cnt_ms = 200/wt_tim1;
while(cnt_ms);
PORTB &= ~ (1<<OUTX);
......

Подведём итоги:
Задействовано переменных - 1
длина проги в прерывании - 2байта/1такт
общая длина проги - хх байт
число строк программы - 12

================================================

Предложите Ваш вариант. Я с удовольствием воспользуюсь красивым решением этой задачи.

Я предложу, но объясните мне, непонятливому, зачем Вы используете прерывание?

Потоки отработали свое, и например сохранили метку времени в регистре ICR, будем ждать
когда ее кто-нибудь испортит, или обработаем как можно быстрее ?
prottoss все, кто спорит здесь с Вами, имеют в виду всего лишь то, что
такой код вполне имеет право на существование, а Вы утверждаете, "никогда".

Кстати есть ещё причина защиты НЕИЗВЕСТНОГО АВТОРА.
Дело в том, что настоящий конструктор - это не чистый программист.
Он должен видеть чуть дальше. Конечно красивое решение в программе всегда приятно и воспринимается как личная победа, но ...

Если кто-нибудь когда-нибудь будет разбирать исходники моей последней завершённой темы (а я ей доволен), то он увидит несколько "явных некрасивых решений".
Задача: atmega8. Приборная панель. 6 датчиков/ 6 шаговых двигателей-стрелок.

1) "Ну нафига он в одно прерывание от таймера засунул чтение АЦП и вывод на двигатели"
2) "Ну зачем он использует промежуточные ячейки - образы портов - при работе с двигателями"
3) "В форумах мне рекомендовали правила работы с АЦП: выставляем канал - ждём готовности - читаем значение. А у него всё наоборот..."
Наверняка найдутся и другие вопросы. Да у меня самого бы нашлись ...

Отвечаю по порядку.
1) При работе с ШД включенными по 3-ёх точечной схеме по одному двигателю ток может достигать 40ма. По шести - 240. В момент переключения возможны выбросы и чтение АЦП лучше привязать к циклу переключения обмоток.
2) Расчёт состояний на обмотках предусматривает ветвления. При 6 двигателях их набирается много. Я по прерыванию сразу вывожу образы портов (расчитанные в предыдущем прерывании). А потом формирую новые. Поэтому временные диаграмы на двигателях стоят так, как будто их аппаратным способом обрабатывали. Это даёт возможность точно расчитывать тайминги при разгоне/торможении.
Ещё одна причина - 3 двигателя - 9 точек. На один порт не вешается. И одновременный вывод невозможен, а задержки вывода на разные ноги одного двигателя могут привести к сбоям.
3) На самом деле удобнее работать как раз на оборот: Читаю текущее значение по текущему каналу. Сохраняю (или обрабатываю). Изменяю номер канала и вывожу его. К началу следующего прерывания, измерение гарантировано будет завершено. А я не буду тратить время на бессмысленное ожидание.

Как видите объяснения есть (мои, и я не претендую на безошибочность суждений), но они, на самом деле, далеки от программирования.
Зато, голова - маленькая иммитация OS.... Четыре паралельных задачи..... Обмен только ч/з данные.... Вот здесь я пытался (в силу своих слабых сил и слабых сил камня) быть программистом.

Это где же я говорил "никогда"? Любой код, пусть даже самый абсурдный имеет право на существование...

Я не использую прерывание. Прерывание используется для ДРУГОЙ ЦЕЛИ!!! Почитайте мой первый пост. Я писал, что так иногда делают, когда уже есть прерывание! И я в него вставляю одну команду. Одну для каждой метки!!!
Безусловно иначе - это глупо.

Ну а чем плох вот такой вариант на С?





ИТОГО:

*ни одной переменной

*не надо прерываний

*работает абсолютно так же

*число строк 6

*число байт кода 46

Пример:
1. Timer1 считает время (по прерываниям)
2. INT0 и Timer0 ловят код(старт и стоп) по RF каналу. (то есть должны работать
все время)
3. Основной цикл выводит текущий результат на LCD (причем без всяких там HD4XXX).
4. Когда код от RF "поймали" наполовину, перестаем выводить на LCD и
ждем(в цикле похожем на цикл автора топика ) когда получим код полностью.
5. фиксируем время.

Это, с некоторыми упрощениями логика работы некоторого девайса.
Все это работает при 1Мгц тактовой (ну типа устройство было "батарейным" -
надо было экономить).

А при чем здесь задержки через задний проход?

Можно чуть-чуть по подробнее что Вы имеете ввиду ?

автор топика всего лишь предположил что это был таймер...


Или может быть просто хотите пообщаться с модераторами ?

Я и имею ввиду задержки на прерываниях, если так можно выразится об этих задержках
OFFTOP: Что вы нервничаете так? Сначала оскорбляете обидными словами, что мол работу меняй) Теперь модераторами пугаете)

Окорблять не собирался (смайликов поставил).
Просто создалось впечатление, что Вы высказались не очень ТОЧНО(это ключевое слово),
а теперь боитесь упасть "лицом в грязь", ну и от сюда все проблеммы.
А может быть просто нужно "уточнить", что Вы имели ввиду ?
ИМХО, это куда как более достойное поведение (Все мы иногда ощибаемся,
или говорим так, что другим нас не понять).

Ага, обижать человека с улыбкой, по Вашему это нормально?Ладно, проехали...
За все, мною сказанное выше в топике я отвечаю, и я не боюсь упасть в грязь лицом) Вы тут чего то наговорили непонятного, по моему даже Вам самому) Я всего лишь сказал, что
и от своего мнения не отказываюсь. Так же выше в топике я привел свой вариант выполнения задержек, чем он хуже? Вы еще ни одного реального довода мне не привели, зато впечатлениями обо мне делитесь. Может быть Вам пора работу сменить, психологом например заделаться, а? Огорчает, что замусорили топик перепалкою, это и меня касается(

Ничего ужасного про Вас я и не расказывал, мы ведь просто обсуждали некий
"абстрактный" код, а Вы почему-то решили что это камень в Ваш огород.
ок, давайте подождем мнений других участников данного топика, и постараемся
высказываться только по существу.

prottoss
Ваш вариант хуже в смысле точности, и намного.
Повторюсь, таймер считает число тактов без привязки к программе, а программный цикл - число машинных циклов, без учета прерываний.
Считаем: если каждые 100 мкс возникает прерывание длиной 20 мкс (152 такта @8МГц + 8 тактов вход/выход), то 1-сек задержка циклами ошибется на 0.25 с. В то время, как та же задержка таймером - максимум на время выполнения какого-либо текущего прерывания.

Добавим к этому то, что, пока таймер тикает, программа может заниматься разнообразными полезными делами или вообще спать. Впрочем, это уже обсуждалось.

Хм...Странный ход мыслей, и в цикле, где идет подсчет тактов (что привел я), и в цикле, где ожидается изменение переменной (оригинальный обсуждаемый сдесь код) могут возникать сколь угодное количество прерываний, отчего же оригинальный код точнее, чем тот, что привел я? Получается так: задержка не точная, prottoss, это нормально, но вот Вы привели код, он еще менее точен, и это не нормально. Давайте уж так, либо прецизионные задержки, либо никакие. А если в каком то прерывании ветвления, что тогда? Плавающая точная задержка...Мдя
Я и спорить то начал с того, что подпрограмма использует прерывание для вычисления таймингов, но фактически она ничего, акромя ожидания изменения переменной НИЧЕГО НЕ ДЕЛАЕТ! Смысл в использовании прерывания?

Опять не понимаете. Таймер тикает независимо от программы, и привязан ко времени с точностью, какую обеспечивает кварц. Программа будет реагировать на событие с макс. задержкой порядка микросекунд, спору нет; но какие бы прерывания ни возникали, отсчеты времени не будут убегать. Циклами такого в общем случае не добиться.

Смысл в использовании прерывания? Это остаётся на усмотрение программиста. Нигде не было сказано, чем это прерывание занимается; может, на него навешено полезных функций, которые там исполнять удобнее, чем в цикле задержки.

Цитату в студию.

protoss
Может быть прежде чем слепо спорить, что-то домысливать и т.п. лучше просто подумать над тем что было сказано?..

А код такой задержи на мой взгляд имеет корни скорее всего из realmode x86 платформы. Системный таймер в realmode x86 располагается по фиксированному адресу и инкрементируется 18.2 раз в секунду обработчиком прерывания IRQ0, т.о. самый простой способ организации относительно точной задержки, независимой от частоты процессора для realmode x86 - это просто постоянно вычитывать значение системного таймера и сравнивать с требуемым значением:

типичная организация задержки в DOS программах:

Надоело спорить о бессмысленном, но Вы хоть добавляйте, что типично для Вас. Хотите поговорить о DOS? Пожалуйста. Вы слышали чего нибудь о функции BIOS INT15? Это типично для DOS... Но долго...Представляю лучшие ДОСовские игры, с задержками, организованными по Вашему коду)))

PS: счетчик располагается по адресу 0000:046Ch

Боже упаси, кто с вами спорит-то?
Вы эта.. хоть читайте сообщения.. или "чукча только писатель" © ?


Сервисные функции DOS начинаются с INT 20H, поэтому INT 15 это "типично для Вас" © protoss, а не для DOS.


Всякий овощ полезен. ©

Ну вот))) Опять разнервничались)))
Я про BIOS он про DOS))) Мдя, кто писатель...а кто...
Ну кто ж себя любимого осудит

prottoss
Если вы такой умный насколько и нагловатый (!?!), то приведите простой и в то же время максимально точный (в силу ограничений системы) пример функции задержки для большинства процессоров (идеален для армов), не использующий прерываний. А то кроме вашей критики ничего дельного на этой ветке я не нашёл.

Как сказал один великий "... нельзя объять необъятное ...". Универсальных методов нет...Я высказал лишь свое мнение по поводу кода, который я не считаю оригинальным, и не считаю нормальным. Но это все уже ближе к стилю программирования. И это мое ИМХО, от которого я не отказываюсь. Каждый имеет право на свое мнение, ведь так? Зачем пытаться нападать на меня?))) Вроде люди здесь, в основном, проффесионалы, умные.... начинают гадости говорить, если с ними не соглашаются...А методов на самом деле много, все зависит же от конкретной задачи и от средств, которые на эту задачу выделенны) Вы ведь сами это понимаете.

Ну то есть задание вы провалили. Приходите через год.
Если есть желание критиковать чужое, то должно быть своё заведомо лучшее.

Уважаемый, мне конечно все равно, однако я в отличие от вас, когда постил свой пост, потрудился добавить туда вашу цитату, в которой вы сказали:

Поэтому не вижу смысла вам отпираться от того, что вы сами и сказали.

PS: не уподобляйтесь A.Bolshev'у - "мастеру перевоплощений", он тоже очень любит использовать домыслы и подмену понятий в своих изречениях.

Я ни кому не уподобляюсь) По моему это вы тут играетесь словами а не я: Хотя Вы прекрасно понимаете, о чем я говорю, начинаете играть словами и выражениями, и уходите от сути вопроса, акцентируете внимание совсем на другом...Спор давно уже перетек в неприязнь, по моему, так что прекращайте молоть...

Ну это по вашему. А по-моему вы перегнули палку в этой ветке.

Спора как такового здесь не было. Было высказано 2 мнения и была перебранка с использованием подмены понятий с вашей стороны.

Высказанные мнения:
1. Такой способ задержки - ламерский.
2. Такой способ задержки - не ламерский.

Большинство склоняется ко второму мнению. Вот и все.

Си прогу я привёл просто так. Обсуждаемая явно ассемблерная. Ваша на Си использует регистры. Просто Вы не знаете. Использует стэк. Длинее по коду.
Так в чём выигрыш?

Но в целом мне кажется тему надо прибить, так как главное - доказано.
А главное:
1) Нельзя по нескольким строчкам судить о "тупости" автора.
2) Если не понимаешь причины какого-нибудь решения, то стоит сначала его осмыслить, и уж потом делать выводы.

Не хотел больше отвечать на обидные слова в мой адрес, и, тем более, оскорбления и насмешки (касается defunct и иже с ним), но Вы туда же лезете) Я знаю, что программа использует регистры. Когда Вы привели пример на Си, я же не напоминал Вам о том, что она использует регистры, то есть я не посчитал Вас идиотом, так? Для тех, кто на бронепоезде, повторю еще раз, что не вижу смысла пользовать прерывание для ожидания прохождения отрезка времени и при этом висеть в цикле...

В чем выйгрыш? Да ни в чем, просто я привел то же самое, что и Вы но без прерываний.



Давно пора





Я не сказал, что тупой автор, протрите глаза! Я сказал что "... функция не интересная, а наоборот - тупая ...", про автора и слова не было сказанно. Если я говорю о тупом решении, это не значит что я говорю о тупости автора



Если не понимаешь о чем говорит человек, то стоит сначала осмыслить его слова, и уж потом умничать.

Специально использую класический смайл так как он переводится как улыбка. И ведь так и в жизни... Вот люблю улыбаться... Но время от времени нарываюсь на неприятности ... ну типа: "чё лыбишься..." или там "Ваша насмешка не уместна".

По моему "улыбка" или "насмешка", - это просто отражение Вашего взгляда на жизнь и окружающих. Я - улыбался.

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

В прерывании
.....
cnt_ms500++;
cnt_ms300++;
cnt_ms200++;
.....

В голове
.....

#define wt_tim1 = 4 // 4ms


// Точность определяется периодом цикла головы
.....
if(cnt_ms500 > 500/wt_tim1) {
cnt_ms500 = 0;
// Данный блок исполняется с периодом 500 мс
}

if(cnt_ms300 > 300/wt_tim1) {
cnt_ms300 = 0;
// Данный блок исполняется с периодом 300 мс
}

if(cnt_ms200 > 200/wt_tim1) {
cnt_ms200 = 0;
// Данный блок исполняется с периодом 200 мс
}

....

Конечно это можно сделать и семафорами (и даже лучше если переменные > 1 байта), но сути это не меняет. Подход тот же.


По поводу прерываний. С одной стороны Вы пишете "нонсенс" по поводу моего высказывания "о необходимости минимизировать число прерываний", с другой - ругаете за его применение. Дело в том что таймерные прерывания - самые низкоприоритетные (обычно). А посему я делаю первой командой "sei". Но ещё раз повторяю такое используется ПОПУТНО. Прерывание не задействовано. В этом не минус а плюс такой реализации. Используется прерывание без которого НЕ ОБОЙТИСЬ. И добавляется туда всего ОДНА КОМАНДА. Например регенерация экрана, опрос датчиков, програмный ШИМ, регулярный обмен с внешними устройствами, опрос АЦП по таймеру и т.д.

Если я Вас не убедил, то давайте считать что я просто заблуждаюсь и мне поможет только время.
(улыбка)

Поскольку вы написали, что это касается и меня, то вынужден ответить на этот пост.
Ваши "проблемы" исходят от вас же, почитайте ветку с начала "со стороны". Или попросите почитать друга, но не говорите ему вашего ник-нейма и потом спросите его, кто на его взгляд в этой ветке вел себя хамовато. Если вы чуствуете что в ваш адрес было сказано что-то уж очень обидное, тогда может быть в пора почитать это?


Зачем повторять ваше мнение многократно, к тому же отдельно тем кто на бронепоезде или в танке и т.п. Совсем тупых, чтобы возникала необходимость в многократном разжевывании вашего мнения, полагаю здесь нет. С вашим мнением уже ознакомились, еще на первой странице этой ветки.



Выигрыш в том, что с прерыванием можно легко организовать HAL (Hardware Abstraction Layer) и т.о. заданные интервалы задержек не будут зависеть от частоты кварца и от латентности других прерываний.

пример:
задаем в hal константу - чатоту чипа.
задаем в hal формулу расчета делителя для таймера для получения периода в 1ms.
пишем в hal обработчик "системного таймера" и отводим две переменных: одну под счетчик (системное время) и одну под таймер (декремент до нуля).
далее в программах пользуемся этими переменными и всегда знаем что счетчик считает миллисекунды, а таймер отнимает миллисекунды. И не заморачиваем себе голову тем сколько циклов надо отмерять для получения задержки в N ms.
При переносе проекта под другой процессор, просто немного подправляем hal - меняем частоту, меняем формулу, меняем синтаксис обработчика прерывания, а все остальное оставляем как было. И все задержки используемые в любых других модулях остаются правильными.

Не забываем о том, что такая задержка будет много точнее холостых циклов за счет независимости от других прерываний и их латентности.

Иллюстрация: требуется организовать задержку в 100 ms при частоте чипа 1 Mhz и при наличии в программе 5-ти обработчиков прерываний (_IRQ0_handler, _IRQ1_handler, ... _IRQ4_Handler)
с длительностью обработки:
_IRQ0 - 50 циклов (цикл для AVR = 1 такт)
_IRQ1 - 100 циклов
_IRQ2 - 150 циклов
_IRQ3 - 200 циклов
_IRQ4 - 250 циклов.
Допускается, что за 1 ms каждое из прерываний может произойти не более одного раза.
Вопрос каким способом мы можем наиболее точно организовать задержку в 100ms?

1. Рассмотрим способ предлагаемый prottoss. (без использования прерываний):
- рассчитываем количество циклов Nc требуемое для организации задержки в 100ms на 1Mhz
Nc = 1Mhz * 0.1c = 1*10^5
формируем и запускаем функцию задержки на 1*10^5 циклов.

А теперь оценим точность.
С учетом того, что в системе имеется 5 обработчиков прерываний, и каждое из них может произойти раз в 1ms, то в наихудшем случае за 100 ms, каждое и прерываний произойдет 100 раз. Суммируем количество циклов требуемое на обработку всех этих прерываний Nirqc (ведь в момент обработки прерываний, функция отсчитывающая задержку приостанавливается).
Nirqc = (50 + 100 + 150 + 200 + 250) * 100 = 7.5*10^4
т.о. 75 тыс циклов не будут нами учтены функцией задержки, врезультате чего вместо 1*10^5 циклов наша функция задержки пропустит 1*10^5 + 7.5*10^4 = 1.75*10^5 циклов, а это в 1.75 раза больше чем требовалось. И вместо задержки в 100ms у нас получится задержка в 175ms.
Суммарная точность получится:
Acc = +-(7.5*10^4) *100%/ (1*10^5) = +-75%

2. Рассмотрим способ обсуждаемый в сабж.
- пишем еще один обработчик прерывания либо модифицируем существующий. который будет вызываться раз в 1 ms и декрементировать до нуля определенную переменную. Код такого обработчика:


- формируем функцию задержки как:


Оценим точность:
за одну ms проц выполняет 1mhz * 10^(-3)с = 1000 циклов. Суммарная нагрузка обработчиков прерываний в 1 ms составляет (50 + 100 + 150 + 200 + 250) = 750 циклов, т.о. наше прерывание с периодом вызова 1ms в худшем случае вызовется с отставанием на 750 циклов, если будет иметь наинизший приоритет. Отставание в 750 циклов и будет единственной погрешностью нашей функции задержки с использованием прерываний, поскольку наше прерывание выполняется через каждую 1ms.
Итого наша функция задержки с использованием прерывания обеспечит точность:
Acc = +-(0.75ms)*100%/100ms = +-0.75%



Ну так где выше точность?
prottoss, Вы поняли разницу или вы на бронепоезде?



Вот именно. Хороший совет вы дали. Следуйте ему.

2 SasaVitebsk: объяснения об улыбках, ухмылках, и капающего с зубов яда приняты)

2 defunct: Скорее всего до HAL не доросли, идите далее обсуждайте AVR32, ARM etc.. Вумно и глупокомысленно))) К сожалению дальше я Вас послать пока не могу)

На этом откланяюсь, продолжать "беседу" намерений нет

LMD

А дык чего вы хотите от Пиннокио? Ж)))