roboforum.ru

Хм... нашел таки как минимум 1 неоднозначность...и посерьезнее, чем неатомарность указанной вами строки. Спасибо, что обратили внимание.
Ща подумаю, как переделать.

Компилятор CVAVR, я писал вначале

Добавлено спустя 1 минуту 46 секунд:
Но кстати, убрав while в майне снимаются все неоднозначности, правда пропадает доп функционал, но фиг с ним, сейчас попробую...

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

Например если в обработчике сделать так
if(PIND & 0b01000000)
{
channel_start[2] = t; // Старт импульса
channel_end[1] = t; // Стоп импульса
channel[1] = channel_end[1] - channel_start[1];
if(channel[1]>1995) channel[1] = 1995; // ПРОБЛЕМНОЕ МЕСТО
return;
}
if(PIND & 0b00100000)
{
channel_start[3] = t; // Старт импульса
channel_end[2] = t; // Стоп импульса
channel[2] = channel_end[2] - channel_start[2];
return;
}
То один канал где нет проверки будет нормально работать, а где есть значение будет скакать от текущего к максимуму.
Буду копать дальше, но пока вообще не понятно почему так происходит. Причем число можно поставить любое, например if(channel[1]>65000) channel[1] = 1995; результат тот же. Это условие иногда срабатывает, хотя это невозможно.

Если вы намекаете на while(1); в конце программы, то у меня он есть и я это писал, читайте внимательнее. Никакого ресета не происходит.
I2C совершенно не причем, хотя результат я смотрю через него, да.

После некоторых экспериментов я выяснил, что такое происходит когда значение таймера переходит 0xFFFF между измерениями.
Например:
channel_1_start = 65000; // Время старта импульса
channel_1_end = 700; // Время окончания импульса

Должно получится в беззнаковом варианте channel_1 = 700 - 65000 = 1235
А получается что условие channel_1 > 1995 истинно

Ну так как условие прерывания any change, то прерывание срабатывает когда импульс заканчивается, а потом еще раз, когда следующий стартует. Разница по времени между ними = времени выполнения обработчика, этим можно пренебречь. В условиях же я отлавливаю только начала импульсов.

Большинство китайских передатчиков выдают сервоимпульсы именно последовательно, но например futaba стартует все импульсы одновременно, там пришлось бы алгоритм посложнее писать, но я делал под свои приемники, там именно так.

В принципе можно от этого перехода избавится, если на старте первого импульса обнулять показания таймера. Тогда 8й импульс заканчивается до 0xFFFF и перехода не происходит. Но все равно непонятно почему так получается.

чуть выше дописал.

надо надо.

Вот у вас таймер = 0xFFF0
t = 0x0FFF Start = 0x0FFF

Потом таймер равен, допустим, 0x0010
t = 0x0001 Stop = 0x0001

Вычитаем Stop - Start = 0x0001 - 0x0FFF = ?
Типа должно два получится? А получается 0xF002 (!) почему-то.

Если таймеры вычитать без масштабирования, то все правильно:
0x0010 - 0xFFF0 = 0x0020

Добавлено спустя 33 секунды:

HarryStar писал(а):чтоб нагляднее было

Фигассе

Добавлено спустя 10 минут 25 секунд:

HarryStar писал(а):В условиях же я отлавливаю только начала импульсов.

Это ошибка. Вы в условиях проверяете состояния порта в момент любого изменения на любой ноге. Это вовсе не "я отлавливаю начала импульсов".

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

Но причина скачков - это масштабирование таймера, как я писал выше.

Я бы, несмотря на это, ужесточил условия.
Например так
if (PORTD == 0b00100000)

Тогда неоднозначностей не будет (кроме последнего условия, но оно не повлияет на результат).

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