Золотовский Д.В. Учебный курс для новичков по микроконтроллерам AVR. Часть 1
Подождите немного. Документ загружается.
Сборка схемы
Что к чему идет показано на фотках (кликабельны). Думаю все понятно. Благо схема то
там — три с половиной проводка.
Увеличить
Увеличить
Ну и процесс работы (видео):
Мультимастерный обмен по шине i2c
•
Архив с проектами под оба контроллера
Пара слов о отладке
В процессе написания было наделана куча багов, порой идиотских, но от
этого не менее страшных. В процессе отладки активно применялся
отладочный буфер. Его вы найдете закомментированым в коде. Это барахло
вида:
1
2
3
4
5
6
7
8
9
10
11
12
13
if (WorkIndex <99) // Если лог не переполнен
{
if (TWSR) // Статус нулевой?
{
WorkLog[WorkIndex]= TWSR; // Пишем статус в лог
WorkIndex++;
}
else
{
WorkLog[WorkIndex]= 0xFF; // Если статус нулевой
то вписываем FF
WorkIndex++;
}
}
И прочие почеркушки в массив WorkLog.
Т.е. мы пишем все статусы TWSR с лог, а потом, спустя какое то время (я
выбирал около 1с) сбрасываем его в терминал.
1
2
3
4
5
6
7
8
9
10
11
12
13
void LogOut(void) // Выброс логов
{
u08 i;
WorkLog[WorkIndex]= 0xFF;
WorkIndex++;
for(i=0;i!=WorkIndex+1;i++)
{
UDR = WorkLog[i];
_delay_ms(30);
}
}
Напрямую в UART данные пихать нельзя. Т.к. TWI автомат щелкает гораздо
быстрей чем UART может прожевать. И получится что что то потеряется, что
то перепутается. А так мы получаем четкую историю работы программы.
Понятно что происходит, где зацикливается передача, где не идет обмен.
Вот, например, мне Slave выдавал такие логи в хексах:
60 80 88 08 20 08 18 28 28 10 40 58 08 18 30
Сразу видно, по статусам, как прошел обмен. Как он получил байт от Master
(60 80 88). Как попытался достучаться до EEPROM, но та была занята
прожевыванием предыдущего байта (08 20). Как повторил попытку и
успешно записал в нее адрес и считал байт (08 18 28 28 10 40 58), а потом
отправил его другому контроллеру (08 18 30).
А отслеживать прохождение отдельных байт помогал осциллограф.
Показывая что творится на шине, есть ли там NACK/ACK и когда идет
ответы от Slave.
Кстати, пробовал, ради прикола, погонять пример в Proteus — выдал какую
то неадекватную муть. I2C анализатор вообще половину обмена прошляпил.
Хотя, по логам в терминалах, вторая половина все же был. Хотя и через
заднее место, и не до конца. Плюс еще были интересные баги от того, что
Proteus контроллер при старте запускает в нули, а реальный процессор может
иметь неопределенное значение в некоторых регистрах. Так что был
прикольный баг, когда прошивка в Proteus работает, а в реале нифига
подобного. В общем, диодиком помигать сгодится, но пытаться отлаживать в
нём что-либо серьёзное – это надо быть сильно просветленным. Т.к. в железе
все оно будет вести себя совсем по-другому.
Доработки
Глюки я вроде бы поотлавливал. В разных режимах мастеров посталкивал.
Но кое-что надо доработать. Например, избавиться от полчища буферов и
первести все на указатели. Чтобы в функции запуска/инициализации
передвались только указатели на произвольный массив. Также было
предложение все параметры согнать в структуры. Так что версию я может
еще и обновлю. Но пока не до нее. Еще интересные вещи есть, с которыми
стоит поковыряться.
AVR. Учебный Курс. Кусочно-линейная аппроксимация
Часто бывает так, что приходится обрабатывать жутко нелинейные
величины, задаваемые каким-нибудь извращенным законом. Простейший
пример — датчики расстояния SHARP GP2D12. Только поглядите на его
характеристику:
Кто угодно ногу сломит, а ведь нам бы неплохо иметь выход в человеческих
величинах, ну или, хотя бы, линейно зависящие от расстояния. Что делать?
Вариантов тут, на самом деле, всего два. Первый очень быстрый, но жадный
до памяти ПЗУ — табличный.
То есть мы просто берем и эту кривулину расписываем в памяти. Например,
у нас с 8ми разрядного АЦП идет значение напряжения от 0 до 256, а мы на
каждое значение создаем в памяти значение расстояния. Тогда с АЦП сразу
гоним в индекс массива, где эти значения сохраняются и получаем
расстояние:
L=Curve[ADCH];
Недостаток один — прожорливость до памяти, растущая в геометрической
прогрессии с ростом разрядности АЦП.
Вариант второй — написать функцию, переводящую одну величину в
другую.
И вот тут можно поизвращаться. Дело в том, что если попытаться первести
данные напрямую, как нам это советует даташит, на этот дальномер, то мы
получим выражение вида:
L = k*X +b - уравнение прямой.
По даташиту видно, что характеристика становится линейной при
выворачивании её наизнанку (см. рис.)
То есть у нас получается:
V = 1/L*k+b
•
V — мы знаем, это показание с АЦП, помноженные на вес разряда:
ADC * digit_weight. АЦП в данный момент имеет опорное напряжение
в 3.3 вольта и 8 бит. Так что вес будет 3.3/255 = 0,013 вольта
•
k — судя по графику, равно около 13.
•
b — на вскидку, если продолжить график до нуля, выглядит примерно
на 0.1
Получили:
0.013*ADC = 1/L*13 + 0.1
Путем применения технологий жуткого матана :) мы получаем чистую
формулу расстояния:
L = 13/(0.013ADC-0.1)
Прикинув по исходному графику, убеждаемся, что нигде ничего не забыли и
не напутали.
Теперь покоцаем все на 0.013 и округлим результаты. Пока мы считаем сами,
нам доступна эта роскошь. МК же в целочисленных вычислениях округлять
не умеет.
L = 1000/(ADC-8)
Вот, совсем красиво получилось. Одна непрятность - деление то у нас
целочисленное, а значит, будут потери округления. Т.е. при целочисленном
вычислении 9.9 и 9.1 округляются до 9. Непорядок.
Наиболее точный результат целочисленного деления выражения А=B/C дает
формула A = (B+C/2)/C
L = (1000+(ADC-8)/2)/(ADC-8)
В принципе, так можно и оставить и в таком виде скормить компилятору. Но
можно и пооптимизировать. Во-первых, что в первую очередь просится под
нож, так это операция деления — самая мерзкая и тормозная из
арифметических операций.
Как минимум одно деление можно оптимизировать:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
u08 conversion (u08 _ADC)
{
u08 Half_DIV;
u16 Result;
if(_ADC<15) return 255; // Очень далеко. Или ошибка датчика.
Half_DIV = _ADC-8;
Half_DIV >>=1; // Делим пополам сдвигом.
Result = 1000+(u16)Half_DIV;
return (u08)(Result/(_ADC-8));
}
Зачем в самом начале проверку на минимальное значение? Да на всякий
случай, чтобы не было деления на ноль, например. Или каких-то
космических значений. Видишь же, что характеристика датчика по
напряжению не опускается ниже 0.2 вольт. А 0.2 вольта в наших показаниях
АЦП это 15. Можно и вообще ограничить зону точкой четкого определения
расстояния, скажем, 30 сантиметров. Это 0.4 вольта, тогда ограничивать
можно сразу от 30 АЦПшных попугаев.
Аппроксимация кусочно-линейными функциями.
Но это нам повезло с тем, что форма и параметры кривой оказались такими,
что все легко само порубилось и упростилось. А если не выходит каменный
цветок? Нет, разумеется, можно засунуть все как есть, и посчитать в лоб.
Даже если сделать это в целых числах будет весьма жирная процедура, а уж
про плавающую точку я и не заикаюсь. Процессорного времени оно скушает
тоже будь здоров, даже не сомневайся.
Что делать? А тут на помощь опять придет злой матан в лице аппроксимации
кусочно-линейными функциями. За злой терминологией скрывается, на
самом деле, примитивнейшая вещь: мы любую кривулину бьём на отрезки и
отрисовываем ее линейными функциями. А дальше, в зависимости от
величины входного значения, считаем по нужному нам отрезку. Возьмем
опять наш злосчастный график характеристики оптического датчика. Я
оставил от него только активную часть, ту, что нам нужна на практике.
Я отрисовал его по точкам и забросил в маткад, взяв только активные
области.
Вот только не понравилось мне то, что входное значение меняется от 0 до
255, а выходное от 0 до 30. Да, на выходе сантиметры, но я бы предпочел
полный размах от 0 до 255. Зачем? А шумы фильтровать проще будет.
А еще повернул так, чтобы по оси Х были данные из АЦП, а по оси У
расстояние в наших попугаях (1 попугай = 1/7см).
Итак, возьмем и отмасштабируем нашу кривулину до 256, просто помножив
на 7 с копейками.
Теперь на глаз прикинем наиболее линейные участки и наложим три
функции. Подбирая коэффициенты, наложим их максимально точно на нашу
кривую. Чем больше линейных участков, тем больше памяти будет занимать
наша обработка, но тем точней будет результат. Однако, скорость обработки
от этого почти не зависит, ведь сколько бы у нас не было линейных участков,
в каждый конкретный прогон обрабатывается только один!
Я взял три куска, описав их следующими функциями:
•
X = -4Y + 320 при Y от 0 до 56
•
X = -Y + 150 при Y от 56 до 118
•
X = -0.25Y +60 при Y от 118 до 250
Коэффициенты я старался подобрать такие, чтобы прямая не только
максимально плотно легла на исходную кривую, но и чтобы они были как
можно ближе к степени двойки. Чтобы можно было делить и умножать
сдвигами. Если не удается подобрать степень двойки, то можно близкие к
ней. Например, Y*3 = (Y<<1)+Y.
Ну, и в таком духе.
Создание Bootloader’a