Serge77
инфо
инструменты
hcube
GOGI
Xan
Реклама Google — средство выживания форумов :)
-
![[image]](https://www.balancer.ru/cache/sites/s/6/s61.radikal.ru/i174/0903/ef/128x128-crop/af557db03d96.jpg)
Микроконтроллеры AVR - применение и Краткий Курс - часть 10
Теги:
pokos> Думаю, насчёт +50С ты погорячился....
На солнце чёрная микросхема может и нагреться. Электронику иногда под прозрачную крышку ставят, это ещё хуже.
pokos> В даташите обещают в районе 0,05% на градус.
Если при 20С выставить оптимальную частоту, то при -10 или +50 уход будет 1.5%. Вроде нормально.
На солнце чёрная микросхема может и нагреться. Электронику иногда под прозрачную крышку ставят, это ещё хуже.
pokos> В даташите обещают в районе 0,05% на градус.
Если при 20С выставить оптимальную частоту, то при -10 или +50 уход будет 1.5%. Вроде нормально.
Атмел выпустил новый контроллер - мега 48. Памяти 4к, оперативки 512, 8 каналов АЦП, 3 таймера - в общем, та же 8 мега, но с увеличенным количеством периферии. Серия из 3 контроллеров - 48, 88, 168. 48-я стоит процентов на 5 дешевле чем 8 мега и является самым дешевым АВР с ком-портом. И одним из самых компактных при этом.
Если же брать тини - то да, тини13 оптимум.
Комп-порт самосинхрится по стартовым битам, поэтому для решения проблемы надо просто снизить скорость до 9600 и сделать промежутки между байтами. Но лучше все-таки не делать программный ком-порт, а использовать аппаратный ком-порт в 48 меге. В которой к тому же есть аппаратный TWI для флешки, SPI, уйма таймеров и другие вкусности
.
Да - у атмела есть тини контроллеры в корпусе SO14. Называются - Tiny24/44/84 : http://www.atmel.com/dyn/resources/prod_documents/doc7701.pdf
Там ножек на все хватит, и не TQFP при этом.
Если же брать тини - то да, тини13 оптимум.
Комп-порт самосинхрится по стартовым битам, поэтому для решения проблемы надо просто снизить скорость до 9600 и сделать промежутки между байтами. Но лучше все-таки не делать программный ком-порт, а использовать аппаратный ком-порт в 48 меге. В которой к тому же есть аппаратный TWI для флешки, SPI, уйма таймеров и другие вкусности
.Да - у атмела есть тини контроллеры в корпусе SO14. Называются - Tiny24/44/84 : http://www.atmel.com/dyn/resources/prod_documents/doc7701.pdf
Там ножек на все хватит, и не TQFP при этом.
hcube> Комп-порт самосинхрится по стартовым битам, поэтому для решения проблемы надо просто снизить скорость до 9600
Там 4800.
hcube> и сделать промежутки между байтами
Какой длительности?
Там 4800.
hcube> и сделать промежутки между байтами
Какой длительности?
На 4800... ну... я думаю, 1 мсек будет достаточно - пауза должна быть сопоставима с шириной байта.
если первая треть всегда передается нормально, может просто разбить передачу на несколько частей?
hcube> 48-я стоит процентов на 5 дешевле чем 8 мега и является самым дешевым АВР с ком-портом.
Где ? efind.ru
Где ? efind.ru
Я брал в Терре - 48-я стоила 43, а 8 мега что-то около 48 рублей. Притом что 48-я, хотя и имеет меньший объем флеша, но функционально значительно богаче чем 8 мега. Собственно, последнюю атмел вообще полагает устаревшей и не советует использовать в новых дизайнах .
.
hcube> 48-я функционально значительно богаче чем 8 мега.
Потому и дороже.
Потому и дороже.
Вопрос. Допустим, частота осциллятора сильно отличается от нужной для правильной передачи по СОМ. Как именно это отразится на принятых данных? Будут пропадать целые байты, а те, что всё-таки приняты, будут правильные? Или некоторые байты будут неправильные, но все будут приняты? Или будут и пропавшие, и неправильные?
Судя по моим наблюдениям, у меня все принятые байты правильные, но не все принимаются (или не все передаются). Может это и не связано с частотой осциллятора и с передачей вообще? Может МК не может прочитать какие-то байты из флеша?
Судя по моим наблюдениям, у меня все принятые байты правильные, но не все принимаются (или не все передаются). Может это и не связано с частотой осциллятора и с передачей вообще? Может МК не может прочитать какие-то байты из флеша?
Нужно прошивку записать в МК которая просто шлет 3-4 числа бесконечно - и на ПК посмотреть.
Можно в этой проге подменить байт на свой, тот что отправляется на ПК
Можно в этой проге подменить байт на свой, тот что отправляется на ПК
Serge77> Вопрос. Допустим, частота осциллятора сильно отличается от нужной для правильной передачи по СОМ.
Вопрос в том, что такое "сильно"
Serge77> Как именно это отразится на принятых данных? Будут пропадать целые байты, а те, что всё-таки приняты, будут правильные?
Если скорость приёмника ровно в два раза больше скорости передатчика, то приниматься будут только каждый второй байт, причём, естественно, они будут мало иметь общего с переданными. Если скорость передатчика ровно в два раза больше скорости приёмника, то приниматься будут только байты, у которых младший бит равен нулю - и тоже, принятый код будет мало похож на переданный. Если разница дробная, возникают "всякие" искажения. При отличии порядка 10% обычно часть байт принимается правильно, часть - искажается.
Serge77> Или некоторые байты будут неправильные, но все будут приняты? Или будут и пропавшие, и неправильные?
Ну, смотри, типичный алгоритм приёма включается в момент начала старт-бита, отсчитывает половину его теоретической длины, если в этот момент то, что должно быть, т.е. ноль, то считается, что началась передача. Дальше отсчитывается теоретическая длина бита, фиксируется уровень, дальше опять пауза на длину бита и так до стоп-бита. Соответственно, критическая ошибка - 6,25%, при этом при приёме последнего бита набегает ошибка в пол-бита, и регистрация попадает на перепад на следующий бит.
Можно объяснить и пропуск байтов, если при этом передатчик передаёт быстрее, чем приёмник принимает и стоп-бит оказывается слишком коротким.
Serge77> Судя по моим наблюдениям, у меня все принятые байты правильные, но не все принимаются (или не все передаются). Может это и не связано с частотой осциллятора и с передачей вообще? Может МК не может прочитать какие-то байты из флеша?
Это может быть связано с пропуском прерываний во время обработки других прерываний. Это может быть связано с дефектами алгоритма - и не только алгоритма именно приёма. Тут пироман может помочь. Он недавно чинил очень похожую сбивку.
Вопрос в том, что такое "сильно"
Serge77> Как именно это отразится на принятых данных? Будут пропадать целые байты, а те, что всё-таки приняты, будут правильные?
Если скорость приёмника ровно в два раза больше скорости передатчика, то приниматься будут только каждый второй байт, причём, естественно, они будут мало иметь общего с переданными. Если скорость передатчика ровно в два раза больше скорости приёмника, то приниматься будут только байты, у которых младший бит равен нулю - и тоже, принятый код будет мало похож на переданный. Если разница дробная, возникают "всякие" искажения. При отличии порядка 10% обычно часть байт принимается правильно, часть - искажается.
Serge77> Или некоторые байты будут неправильные, но все будут приняты? Или будут и пропавшие, и неправильные?
Ну, смотри, типичный алгоритм приёма включается в момент начала старт-бита, отсчитывает половину его теоретической длины, если в этот момент то, что должно быть, т.е. ноль, то считается, что началась передача. Дальше отсчитывается теоретическая длина бита, фиксируется уровень, дальше опять пауза на длину бита и так до стоп-бита. Соответственно, критическая ошибка - 6,25%, при этом при приёме последнего бита набегает ошибка в пол-бита, и регистрация попадает на перепад на следующий бит.
Можно объяснить и пропуск байтов, если при этом передатчик передаёт быстрее, чем приёмник принимает и стоп-бит оказывается слишком коротким.
Serge77> Судя по моим наблюдениям, у меня все принятые байты правильные, но не все принимаются (или не все передаются). Может это и не связано с частотой осциллятора и с передачей вообще? Может МК не может прочитать какие-то байты из флеша?
Это может быть связано с пропуском прерываний во время обработки других прерываний. Это может быть связано с дефектами алгоритма - и не только алгоритма именно приёма. Тут пироман может помочь. Он недавно чинил очень похожую сбивку.
Serge77> Вопрос. Допустим, частота осциллятора сильно отличается от нужной для правильной передачи по СОМ. Как именно это отразится на принятых данных?
Если частота ниже, то нулевой старший бит будет вызывать в приёмнике ошибку "Break". И принятый байт может быть кривой.
Если частота выше, то может пропадать один из старших битов, а более старшие сдвигаться вправо, старший бит всегда будет единицей, например:
abcdefgh -> 1bcdefgh
abcdefgh -> 1acdefgh
abcdefgh -> 1abdefgh
Serge77> Судя по моим наблюдениям, у меня все принятые байты правильные, но не все принимаются (или не все передаются).
Это может винда помогать, кстати.
Или принимающая прога с её дровами.
Попробуй такое:
1. Во время приёма ничего не трогать, ни клаву, ни мышку. (Ну и другие проги остановить.)
2. Во время приёма взять окно принимающей проги за шкирку и мотать его по экрану.
Если во втором случае будет много потерь, то это "overrun" — прога не успевает забрать принимаемые байты.
Я такое в самодельной проге победил (но только с натуральным компортом).
Если частота ниже, то нулевой старший бит будет вызывать в приёмнике ошибку "Break". И принятый байт может быть кривой.
Если частота выше, то может пропадать один из старших битов, а более старшие сдвигаться вправо, старший бит всегда будет единицей, например:
abcdefgh -> 1bcdefgh
abcdefgh -> 1acdefgh
abcdefgh -> 1abdefgh
Serge77> Судя по моим наблюдениям, у меня все принятые байты правильные, но не все принимаются (или не все передаются).
Это может винда помогать, кстати.
Или принимающая прога с её дровами.
Попробуй такое:
1. Во время приёма ничего не трогать, ни клаву, ни мышку. (Ну и другие проги остановить.)
2. Во время приёма взять окно принимающей проги за шкирку и мотать его по экрану.
Если во втором случае будет много потерь, то это "overrun" — прога не успевает забрать принимаемые байты.
Я такое в самодельной проге победил (но только с натуральным компортом).
Serge77>> Судя по моим наблюдениям, у меня все принятые байты правильные, но не все принимаются (или не все передаются).
Оказывается, наблюдение неправильное, подробнее в следующем сообщении.
Xan> 1. Во время приёма ничего не трогать, ни клаву, ни мышку. (Ну и другие проги остановить.)
Пробовал конечно, не помогает.
Оказывается, наблюдение неправильное, подробнее в следующем сообщении.
Xan> 1. Во время приёма ничего не трогать, ни клаву, ни мышку. (Ну и другие проги остановить.)
Пробовал конечно, не помогает.
Результаты длительных экспериментов. Не знаю, нужны ли они кому-то, но надо же куда-то деть эту кучу цифр ;^))
Пробовал вручную подбирать оптимальный калибровочный байт осциллятора. Менял в прошивке цифру, прошивал МК, запускал на передачу данных в комп. Данные во флеше были одни и те же, т.е. принятые файлы все должны быть одинаковые.
Результаты приёма были трёх типов:
1. количество принятых байт 65536 (норма), данные не битые, в разных принятых файлах одинаковые.
2. количество принятых байт 65536 (норма), данные битые, в разных принятых файлах разные.
3. количество принятых байт меньше или больше 65536, данные битые, в разных принятых файлах разные.
Вариант 1 получился с калибровочным байтом 166 (здесь и далее значения десятичные), хотя родной байт 146.
Все результаты здесь:
(калибровочный байт и количество принятых байт в разных попытках)
50
75728
75678
98
66147
66086
66080
102
65194
65212
65169
106
65189
65211
65184
114
65140
65152
65190
65167
130
65171
65191
146
65179
65164
65139
65145
65135
65172
154
65172
65140
162
65536
65536 данные разные
164
65536
65536 данные разные
166
65536
65536
65536
65536
65536 данные одинаковые
168
56095
170
55460
55469
178
53429
53429
200
49343
49343
49343
Теперь стало понятно, почему данные с родным калибровочным байтом портились именно в районе одной трети файла. В этом месте находится пик поездки на лифте, при этом старший байт данных увеличивается на единицу, это и сбивало приём.
В общем, похоже, что проблемы именно в несовпадении временнЫх параметров передачи и приёма.
Меня удивляет, что правильная передача получилась только при такой тонкой настройке калибровочного байта. Всего на две единицы больше или меньше - и уже сбой. Интересно, на сколько эти две единицы изменяют частоту осциллятора? Никто не знает? В даташите не нашёл.
А может такая тонкая настройка понадобилась только потому, что в программе неточно заданы временнЫе задержки, т.е. это практически случайное совпадение, что удалось подобрать хоть какой-то калибровочный байт, с которым всё работает? Если это так, то малейшее изменение частоты осциллятора, например от температуры, будет приводить к сбоям.
Пробовал вручную подбирать оптимальный калибровочный байт осциллятора. Менял в прошивке цифру, прошивал МК, запускал на передачу данных в комп. Данные во флеше были одни и те же, т.е. принятые файлы все должны быть одинаковые.
Результаты приёма были трёх типов:
1. количество принятых байт 65536 (норма), данные не битые, в разных принятых файлах одинаковые.
2. количество принятых байт 65536 (норма), данные битые, в разных принятых файлах разные.
3. количество принятых байт меньше или больше 65536, данные битые, в разных принятых файлах разные.
Вариант 1 получился с калибровочным байтом 166 (здесь и далее значения десятичные), хотя родной байт 146.
Все результаты здесь:
(калибровочный байт и количество принятых байт в разных попытках)
50
75728
75678
98
66147
66086
66080
102
65194
65212
65169
106
65189
65211
65184
114
65140
65152
65190
65167
130
65171
65191
146
65179
65164
65139
65145
65135
65172
154
65172
65140
162
65536
65536 данные разные
164
65536
65536 данные разные
166
65536
65536
65536
65536
65536 данные одинаковые
168
56095
170
55460
55469
178
53429
53429
200
49343
49343
49343
Теперь стало понятно, почему данные с родным калибровочным байтом портились именно в районе одной трети файла. В этом месте находится пик поездки на лифте, при этом старший байт данных увеличивается на единицу, это и сбивало приём.
В общем, похоже, что проблемы именно в несовпадении временнЫх параметров передачи и приёма.
Меня удивляет, что правильная передача получилась только при такой тонкой настройке калибровочного байта. Всего на две единицы больше или меньше - и уже сбой. Интересно, на сколько эти две единицы изменяют частоту осциллятора? Никто не знает? В даташите не нашёл.
А может такая тонкая настройка понадобилась только потому, что в программе неточно заданы временнЫе задержки, т.е. это практически случайное совпадение, что удалось подобрать хоть какой-то калибровочный байт, с которым всё работает? Если это так, то малейшее изменение частоты осциллятора, например от температуры, будет приводить к сбоям.
Serge77> на сколько эти две единицы изменяют частоту осциллятора? Никто не знает? В даташите не нашёл.
стр 4 даташита Due to large initial variation (0.8 -1.6 MHz) of the internal Oscillator, a tuning capability
is built in. Through an 8-bit control register – OSCCAL – the system clock rate can
be tuned with less than 1% steps of the nominal clock.
Serge77> А может такая тонкая настройка понадобилась только потому, что в программе неточно заданы временнЫе задержки, т.е. это практически случайное совпадение,
Я ж говорю - запиши большой кусок передачи на звуковую карту ПК (через резистор 100 кОм например) и посмотри длину всей пачки.
Настраивать надо не калибровочный байт - это грубо ! - а в проге временные интервалы с шагов в длину одной инструкции NOP - т.е. в период такта процессора.
Это описаной у меня в курсе в задаче 6 по настройке точных интервалов таймера NOP-ами.
Тоже и я имел ввиду при самокалибровке кнопкой - конечно не OSCCAL надо было подстраивать и тайминги в программе.
стр 4 даташита Due to large initial variation (0.8 -1.6 MHz) of the internal Oscillator, a tuning capability
is built in. Through an 8-bit control register – OSCCAL – the system clock rate can
be tuned with less than 1% steps of the nominal clock.
Serge77> А может такая тонкая настройка понадобилась только потому, что в программе неточно заданы временнЫе задержки, т.е. это практически случайное совпадение,
Я ж говорю - запиши большой кусок передачи на звуковую карту ПК (через резистор 100 кОм например) и посмотри длину всей пачки.
Настраивать надо не калибровочный байт - это грубо ! - а в проге временные интервалы с шагов в длину одной инструкции NOP - т.е. в период такта процессора.
Это описаной у меня в курсе в задаче 6 по настройке точных интервалов таймера NOP-ами.
Тоже и я имел ввиду при самокалибровке кнопкой - конечно не OSCCAL надо было подстраивать и тайминги в программе.
termostat> стр 4 даташита Due to large initial variation (0.8 -1.6 MHz) of the internal Oscillator, a tuning capability
termostat> is built in. Through an 8-bit control register – OSCCAL – the system clock rate can
termostat> be tuned with less than 1% steps of the nominal clock.
Это я читал. Но если понять это буквально, то получается, что калибровочным байтом частоту можно менять от 0.8 до 1.6. Тогда калибровочный байт всегда должен быть 255, чтобы получить 1.6 МГц. А это не так. Значит калибровка меняет частоту не от 0.8 до 1.6, а где-то в области 1.6. Но ширина этой области неизвестна, поэтому и неизвестно, на сколько изменяется частота при изменении байта на единицу. Вот об этом я и спрашивал.
termostat> Я ж говорю - запиши большой кусок передачи на звуковую карту ПК (через резистор 100 кОм например) и посмотри длину всей пачки.
Я помню. Для начала попробую проверить интервалы в VMLab.
termostat> Настраивать надо не калибровочный байт - это грубо !
Это было самое простое. И всё-таки дало пользу, теперь хоть ясно куда копать.
termostat> is built in. Through an 8-bit control register – OSCCAL – the system clock rate can
termostat> be tuned with less than 1% steps of the nominal clock.
Это я читал. Но если понять это буквально, то получается, что калибровочным байтом частоту можно менять от 0.8 до 1.6. Тогда калибровочный байт всегда должен быть 255, чтобы получить 1.6 МГц. А это не так. Значит калибровка меняет частоту не от 0.8 до 1.6, а где-то в области 1.6. Но ширина этой области неизвестна, поэтому и неизвестно, на сколько изменяется частота при изменении байта на единицу. Вот об этом я и спрашивал.
termostat> Я ж говорю - запиши большой кусок передачи на звуковую карту ПК (через резистор 100 кОм например) и посмотри длину всей пачки.
Я помню. Для начала попробую проверить интервалы в VMLab.
termostat> Настраивать надо не калибровочный байт - это грубо !
Это было самое простое. И всё-таки дало пользу, теперь хоть ясно куда копать.
Serge77> Меня удивляет, что правильная передача получилась только при такой тонкой настройке калибровочного байта. Всего на две единицы больше или меньше - и уже сбой. Интересно, на сколько эти две единицы изменяют частоту осциллятора? Никто не знает? В даташите не нашёл.
В даташите на attiny13 графики есть, в конце. Вот например для частоты 9.6 МГц. Так очень резко меняет частоту
В даташите на attiny13 графики есть, в конце. Вот например для частоты 9.6 МГц. Так очень резко меняет частоту
Прикреплённые файлы:
GOGI> В даташите на attiny13 графики есть, в конце. Вот например для частоты 9.6 МГц. Так очень резко меняет частоту
Да, круто. Можно в два раза уменьшить или увеличить. Интересно, зачем так сделали? Лучше бы сделали более тонкую настройку.
Да, круто. Можно в два раза уменьшить или увеличить. Интересно, зачем так сделали? Лучше бы сделали более тонкую настройку.
termostat>> стр 4 даташита Due to large initial variation (0.8 -1.6 MHz)
Serge77> Это я читал. Но если понять это буквально, то получается, что калибровочным байтом частоту можно менять от 0.8 до 1.6.
А можно понять и по другому. Диапазон отклонения (не значение частоты, а поле отклонений от средней частоты)
0.8-1.6 MHz Т.е. при производстве получаются генераторы с F ± 0.4 до F ± 0.8 Мгц
Serge77> Это я читал. Но если понять это буквально, то получается, что калибровочным байтом частоту можно менять от 0.8 до 1.6.
А можно понять и по другому. Диапазон отклонения (не значение частоты, а поле отклонений от средней частоты)
0.8-1.6 MHz Т.е. при производстве получаются генераторы с F ± 0.4 до F ± 0.8 Мгц
Serge77> Лучше бы сделали более тонкую настройку.
Нет смысла более тонко настраивать если стабильность параметра не высока.
Общение с UART ПК или другого устройста ПРАВИЛЬНО делать либо на кварце либо с автоподстройкой, но тогда нужно иногда и принимать что-то от ПК чтоб подстраиваться.
Всего есть по-моему 5 поколений генераторов и стабильность новых сильно улучшена.
Вот на русском и поробно о встроеных RC генераторах AVR - апноут AVR053
// www.gaw.ru
Нет смысла более тонко настраивать если стабильность параметра не высока.
Общение с UART ПК или другого устройста ПРАВИЛЬНО делать либо на кварце либо с автоподстройкой, но тогда нужно иногда и принимать что-то от ПК чтоб подстраиваться.
Всего есть по-моему 5 поколений генераторов и стабильность новых сильно улучшена.
Вот на русском и поробно о встроеных RC генераторах AVR - апноут AVR053
Рекомендации по применению 8-разрядных микроконтроллеров AVR - AVR053: Калибровка внутреннего RC-генератора
Справочные данные - электронные компоненты, описания микросхем, жк дисплеи, микроэлектроника// www.gaw.ru
> но тогда нужно иногда и принимать что-то от ПК чтоб подстраиваться
Я это и имел в виду, когда предложил автокалибровку. А что, МК ничего от ПК не принимает?
Я это и имел в виду, когда предложил автокалибровку. А что, МК ничего от ПК не принимает?
termostat> Нет смысла более тонко настраивать если стабильность параметра не высока.
Да, пожалуй.
termostat> Всего есть по-моему 5 поколений генераторов и стабильность новых сильно улучшена.
termostat> Вот на русском и поробно о встроеных RC генераторах AVR - апноут AVR053
Я уже прочитал. Получается, что в тини15 старый нестабильный осциллятор, а например в тини 13 - гораздо лучше.
Да, пожалуй.
termostat> Всего есть по-моему 5 поколений генераторов и стабильность новых сильно улучшена.
termostat> Вот на русском и поробно о встроеных RC генераторах AVR - апноут AVR053
Я уже прочитал. Получается, что в тини15 старый нестабильный осциллятор, а например в тини 13 - гораздо лучше.
Non-conformist> А что, МК ничего от ПК не принимает?
Нет. Это не нужно (не считая калибровки), да и ног свободных нет.
Нет. Это не нужно (не считая калибровки), да и ног свободных нет.
Прочитал еще раз тему, ты оказывается заботишься не только о себе, но и о людях, которые пойдут по твоим стопам
Может тогда просто посоветовать им работать с программатором ponyprog, который кроме программирования МК умеет читать i2c флеши и вывести i2c на разъем?
Может тогда просто посоветовать им работать с программатором ponyprog, который кроме программирования МК умеет читать i2c флеши и вывести i2c на разъем?
Реклама Google — средство выживания форумов :)
GOGI> Может тогда просто посоветовать им работать с программатором ponyprog, который кроме программирования МК умеет читать i2c флеши и вывести i2c на разъем?
Мысль интересная, не знал. Надо подумать.
Правда хочется, чтобы принимающая программа сразу строила график полёта и выдавала высоту (эту программу я напишу). Лишний промежуточный этап не очень удобен.
Мысль интересная, не знал. Надо подумать.
Правда хочется, чтобы принимающая программа сразу строила график полёта и выдавала высоту (эту программу я напишу). Лишний промежуточный этап не очень удобен.
Copyright © Balancer 1997..2023
Создано 06.12.2007
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 06.12.2007
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
