Официальный сайт компании Arduino по адресу arduino.cc
Как отключить прерывание ISR(ADC_vect)
- Войдите или зарегистрируйтесь, чтобы получить возможность отправлять комментарии
Втр, 22/10/2019 - 16:58
Здравствуйте !
Возможно неправильное название темы.
Смысл в том, что для высокой скорости опроса аналогового входа использую ISR(ADC_vect) с режимом скользящей выборки. Но требуется это не всё время.
То есть, в основном цикле идёт обычный опрос через AnalogRead(A7), но в какой-то момент (пусть будет по кнопке) необходимо включить режим быстрого опроса, а потом также выключить в любой момент, чтобы опять начал работать обычный AnalogRead в цикле.
Как это можно сделать ?
Пробовал так ADCSRA = 0x00 и потом заново инициализировать регистр. Отключается и включается нормально. Но в отключённом состоянии AnalogRead начинает просто показывать последнее значение, которое было в прерывании, независимо от реальности.
Пробовал так ADCSRA = 0x00 и потом заново инициализировать регистр. Отключается и включается нормально. Но в отключённом состоянии AnalogRead начинает просто показывать последнее значение, которое было в прерывании, независимо от реальности.
сдается мне, что "обычный AnalogRead" тоже работает через это прерывание.
А зачем выключать? разве с включенным прерыванием AnalogRead не работает?
А зачем выключать? разве с включенным прерыванием AnalogRead не работает?
Почему-то при включённом прерывании из Loop вообще не срабатывают Serial.write и Serial.print. При этом он способен отлавливать Serial.available и выполнять Serial.read. Стоит выключить прерывание, как в порт начинают идти данные из Loop с помощью Serial.write и Serial.print, но AnalogRead при этом неадекватен.
Вот код.
Так с чего бы ему работать, если Вы ADCSRA обидели - ноль туда впихнули? Дело в том, что при инициализации туда пишется "что надо", чтобы работал analogRead (посмотрите функцию void init() в файле wiring.c ). Вы же туда запихали ноль и чего-то ждёте.
Попробуйте перед включением режима "по прерыванию" аккуратненько сохранить регистр, а после восстановить его. Тогда скорее всего должно заработать.
Так с чего бы ему работать, если Вы ADCSRA обидели - ноль туда впихнули? Дело в том, что при инициализации туда пишется "что надо", чтобы работал analogRead (посмотрите функцию void init() в файле wiring.c ). Вы же туда запихали ноль и чего-то ждёте.
Попробуйте перед включением режима "по прерыванию" аккуратненько сохранить регистр, а после восстановить его. Тогда скорее всего должно заработать.
Как сохранить регистр я не знаю. Залез в файл wiring.c - для меня это тёмный лес. Но тем не менее понял, что после ADCSRA = 0x00 всего лишь надо добавить
ADCSRA |= (1 << ADPS2)|(1 << ADPS1) | (1 << ADPS0); // коэффициент деления 128 по-умолчанию
ADCSRA |= (1 << ADEN); // Включаем АЦП
Я бы мог попытаться Вам помочь, если бы Вы выложили реальный код. Чем короче, тем лучше, но реальный - чтобы компилировался, работал и показывал проблему. То, что Вы выложили - не компилируется.
Да, кстати, контроллер ATMega328?
Контроллер ATMega168PA.
Сейчас пересоздал проект, убрал всё лишнее и он совсем сломался.
В общем, сейчас он просто непрерывно шлёт данные из ISR(ADC_vect), а в loop ничего не работает, даже если там оставить только две строчки Serial.write(120); Serial.print(analogRead(A7)).
Он сломался из-за ошибки в строке №13, там явно лишнее "0<<MUX3".
В общем вот "Ваш" код с комментариями насчёт Ваших ошибок, там же показано как регистры сохранять. Всё нормально работает, я проверял, проверьте сами еще.
Только этот код для 328 !!! А то я сейчас в гостинице. 328 у меня есть с собой, а 168 - нету.
По идее, на 168 должен работать, но если не сумеете запустить для 168 уж совсем никак, пишите - я попробую на симуляторе в протеусе.
ЕвгенийП, надо удочку товарищу давать , а не рыбу :) Он вон чо пишет-то, загляденье одно.
надо удочку товарищу давать , а не рыбу :)
да, я так всегда и делаю, Вы же знаете. Но тут сижу, блин, в гостинице, делать ну настолько нечего ... даже срамных девок поблизости нет :)
Упал гостиный сервис. Даже срамных девок в нумера не поставляют. Скоро народ гостиницы посещать не будет.
Не надо с регистрами ацп ничего делать. Достаточно запретить прерывания или разрешить. Всё будет работать. Вот только при максимальной выборке данных ацп на остальное не останется времени. Читайте аналогрид сколько надо и выводите. Когда понадбится максимальная выборка нужно перейти в подпрограмму которая будет только считать количество данных и заполнять массивы по прерыванию. Иначе смысла переходить на прерывания нет. Сериалпринт съест весь выигрыш от применения прерывания.
Где, в Анапе?????
1. https://www.youtube.com/watch?v=X_qaiazq_rc
2. https://www.youtube.com/watch?v=ViRKJ0Pt4Fs
А чего не приехал-то, ловец? Приезжай и лови. А я лучше с ардуиной потрахаюсь :-)
Через прерывания ни разу не быстрее прямой работы с портами. Вход и выход в прерывание - это уже 10 тактов !!! Обращение к Serial внутри прерывания, созданного для ускорения работы с АЦП - это вообще КАЛАМБУР !!!
А по теме - надо замаскировать прерывания от АЦП.
А я лучше с ардуиной потрахаюсь :-)
Месье знает толк!
----------------
Литр самогонки подходил к концу....
Ах, для чего же вам чужая Аргентина,
Когда присутствует простая Ардуина?
....
дальше не придумал...
То есть, в основном цикле идёт обычный опрос через AnalogRead(A7), но в какой-то момент (пусть будет по кнопке) необходимо включить режим быстрого опроса, а потом также выключить в любой момент, чтобы опять начал работать обычный AnalogRead в цикле.
Для увеличения скорости АЦП надо не прерывания использовать, а поднять частоту сэмплирования. Делается это путем изменения делителя в регистре ADCSRA
Прерывания имеет смысл использовать когда мы хотим делать что-то еще пока происходит преобразование.
Месье знает толк!
Первое видео, что мне дали (где Михалыч говорит: "Рыба есть") напомнило историю года 2005-2006 где-то. Идёт хоккейный матч в Тольятти, ворота сдвинулись и дырка под стойку забилась, судья позвал работника стадиона. Тот вышел с дрелью и стал высверливать дырку - обычное дело, почти в каждой игре бывает. Но тут, только он ткнулся дрелью в лёд, диджей, вместо музыки, включил фразу Кузьмича "Рыбы здесь здесь нет, практически нет". Там вся арена легла, включая игроков и тренеров обеих команд.
ЕвгенийП, большое спасибо за код.
На 168 работает.
Он сломался из-за ошибки в строке №13, там явно лишнее "0<<MUX3".
Я руководствовался этой таблицей:
MUX[3:0] (Multiplexer Selection Input) — биты выбора аналогового входа. Значения:
Этот кусок у Вас был сдублирован дважды
это всегда плохая идея, лучше сделать его функцией
Это понятно, просто, когда что-то изучаю, стараюсь делать "в лоб", чтобы меньше ошибок было.
У Вас был делитель 16. Можете вернуться к нему, только если Вы точно знаете, что делаете!!!
Делитель 16 - для ускорения работы. Сейчас вообще выставил 4. С 2 почему-то начинает возвращать просто 1023.
Для этих же целей использую serial.write, вместо serial.print. Например, чтобы отправить число 1022 write потребуется отправить 2 байта, а print - 4 байта. По крайней мере, я думаю, что это так. :)
И скорость порта - 1000000.
ADCSRA = bit(ADPS0) | bit(ADPS1) | bit(ADPS2)
Как это работает я, к сожалению, вообще не понял. Поэтому решил писать так: ADCSRA = 0b11101010; // Коэф. 4.
В прерывании лучше лишнего не делать
Как раз-то в прерывании я и произвожу отправку данных, чтобы она происходила максимально быстро. Из цикла получается медленней.
Для чего здесь переменная объявляется константой ? И почему её не сделать глобальной ? Тоже самое с currentTime и result.
static
volatile uint16_t lastResult = 0;
const
uint32_t result = lastResult;
Почему lastResult имеет тип uint16_t, а result - uint32_t ?
Зачем останавливаются прерывания ? ШИМ ведь тоже потухнет ?
В общем, сейчас изменил Ваш код, под свои нужды. Получилось так.
В таком виде данные выводятся быстро, но отключалка не работает.
Если Serial.write(bt, 2) перенести из ISR(ADC_vect) в loop, то работает немного медленней и отключалка работает. Такое впечатление, что если Serial.write(bt, 2) в прерывании, то до loop вообще очередь не доходит.
ЕвгенийП, надо удочку товарищу давать , а не рыбу :) Он вон чо пишет-то, загляденье одно.
Это должна была быть очень хорошая удочка. :) До сохранения регистров я бы ещё долго не додумался.
Вообще, я сам стараюсь готовую рыбу никому не давать, но в этом случае всё равно мне потребуется здорово редактировать код под свою задачу, поэтому придётся разобраться.
Достаточно запретить прерывания или разрешить.
Вообще все прерывания ? Так не получится. Вернее, так нельзя, они мне нужны будут.
О, кажется я додумался, как здорово ускорить. Теперь я в прерывании накапливаю данные в массиве на 500 байт, а потом их скопом отправляю. Только надо какую-то синхронизацию придумать, а то данные теряются.
Я руководствовался этой таблицей:
Не похоже. В этой таблице написано
Вы всунули туда 1111 и читаете потенциал земли. Вы этого хотели?
Делитель 16 - для ускорения работы. Сейчас вообще выставил 4. С 2 почему-то начинает возвращать просто 1023.
Т.е. Вы уже поняли, что чем меньше делитель, тем хуже точность, и точность с делителем 4 Вас устраивает? Дело Ваше.
Как раз-то в прерывании я и произвожу отправку данных, чтобы она происходила максимально быстро.
Это пожалуйста, только работать не будет (см. ниже)
Константой - потому, что её никто не планирует изменять, а не глобальной - потому, что она нужна только в этой функции, так нафига её делать доступной для остальных? Кроме того, в данном случае, она ещё и память не будет занимать (будет, но не всё время, а только внутри своих фигурных скобок).
Читайте мои посты про память в разделе "программирование" их там три штуки сверху приколоты.
Почему lastResult имеет тип uint16_t, а result - uint32_t ?
По невнимательности. Должно быть 16
Зачем останавливаются прерывания ? ШИМ ведь тоже потухнет ?
ШИМ? С какого перепугу? Он нормально будет работать.
А прерывания закрываются. чтобы переменная не изменилась пока её вычитываем из памяти. Если не закрывать прерывания, то иногда (нечасто) будут пролетать необъяснимые глюки (а виноваты в глюках, разумеется, будут криворукие китайцы, которые неправильную ардуину сделали)
В общем, сейчас изменил Ваш код, под свои нужды. Получилось так.
В таком виде данные выводятся быстро, но отключалка не работает.
Такое впечатление, что если Serial.write(bt, 2) в прерывании, то до loop вообще очередь не доходит.
Ну, вот, что и следовало доказать. Как я Вам уже писал, нефиг в прерывании длительные операции делать. У Вас прилетает новое прерывание, когда ещё старое не обработалось полностью, вот лупу времени и не остаётся..
Вы всунули туда 1111 и читаете потенциал земли. Вы этого хотели?
Нет, не этого хотел. Теперь понял.
Т.е. Вы уже поняли, что чем меньше делитель, тем хуже точность, и точность с делителем 4 Вас устраивает? Дело Ваше.
Да, это понятно. Ищу компромисс. Сейчас ещё сделал чтение только одного ADCH бита через ADLAR = 1. Вроде неплохо.
Константой - потому, что её никто не планирует изменять, а не глобальной - потому, что она нужна только в этой функции, так нафига её делать доступной для остальных? Кроме того, в данном случае, она ещё и память не будет занимать (будет, но не всё время, а только внутри своих фигурных скобок).
Читайте мои посты про память в разделе "программирование" их там три штуки сверху приколоты.
Доступной для всех, действительно не нужно. И если объявление переменной при каждом проходе не тормозит программу, то можно и так. То что не будет глобально занимать память это может и хорошо, а может и нет. Не возникнет ли там ситуация, что ей просто не хватит места из-за переполнения ? Просто, если все переменные глобальные, то под них уже точно выделена память.
В общем, про память почитаю, спасибо.
ШИМ? С какого перепугу? Он нормально будет работать.
Где-то читал, что тоже отключится. Наверное, обманули. Или с таймерами перепутали.
Ну, вот, что и следовало доказать. Как я Вам уже писал, нефиг в прерывании длительные операции делать. У Вас прилетает новое прерывание, когда ещё старое не обработалось полностью, вот лупу времени и не остаётся..
Сделал так.
И скорость увеличилась и отключалка работает. Правда, почему то ещё очень долго поступают данные в программу на ПК. Наверное ещё надо с буферами разбираться.
И массив много памяти занимает, мне на остальное не хватит. Надо наверное динамически выделять и освобождать, если это возможно.
Сделал так.
Ну, толком-то работать не будет, будет глючить, но если Вам так нравится - делайте.
Неясно ещё как и где описана i.
Скорость передачи сериала 11520 байт в секунду на скорости 115200 бит. Это 40 раз медленнее чем может оцифровывать 10 битная ардуина. После заполнения буфера сериала может произойти всё что угодно, в том числе потеря данных. Вывод из прерывания в сериал это большая глупость, выполняемая из за не понимания процессов обработки данных. Аналогрид без всяких прерываний будет работать точно с такой же скоростью. Как уже писали, прерывание нужно только если в этот момент делать что то ещё. У Вас нет никаких параллельных работ. Зачем все эти телодвижения?
Сделал так.
И
Тут уже не раз говорили - так делать нельзя! Использовать Serial в прерывании крайне нежелеательно. Делать это надо в крайнем случае (например при отладке) и только хорошо понимая как именно там все происходит под капотом, а вы до этого не дошли еще.
Может вы попробуйте описать в чем состоит ваша изначальная задая ичто именно вы хотете получить (абстрагируюясь от ардуины), а вам подскажут каким путем это лучше сделать.
Скорость передачи сериала 11520 байт в секунду на скорости 115200 бит. Это 40 раз медленнее чем может оцифровывать 10 битная ардуина. После заполнения буфера сериала может произойти всё что угодно, в том числе потеря данных. Вывод из прерывания в сериал это большая глупость, выполняемая из за не понимания процессов обработки данных. Аналогрид без всяких прерываний будет работать точно с такой же скоростью. Как уже писали, прерывание нужно только если в этот момент делать что то ещё. У Вас нет никаких параллельных работ. Зачем все эти телодвижения?
Так работает быстро.
А так работает медленней.
Да, мне до понимания всех процессов очень далеко. Но тот код проверено работает. Можете объяснить, почему первое быстрей второго ? Под быстротой я понимаю увеличение частоты дискретизации непрерывного изменяющегося сигнала. Перенос Serial.write(bt, 2) в loop снижает эту частоту более чем на 10%.
Параллельных работ нет только сейчас, потому что для тестирования скорости и возможности включения/выключения быстрой выборки они не нужны.
Тут уже не раз говорили - так делать нельзя! Использовать Serial в прерывании крайне нежелеательно. Делать это надо в крайнем случае (например при отладке) и только хорошо понимая как именно там все происходит под капотом, а вы до этого не дошли еще.
Может вы попробуйте описать в чем состоит ваша изначальная задая ичто именно вы хотете получить (абстрагируюясь от ардуины), а вам подскажут каким путем это лучше сделать.
Целиком задача большая. То, что здесь обсуждается будет лишь маленьким кусочком всего кода. Абстрагироваться вряд ли получится. Если коротко, то на всех восьми входах будет считываться напряжение от разных источников и неспешно передаваться на ПК. Четыре раза в секунду будет достаточно. Периодически, оператору будет нужно видеть форму сигнала на каком-нибудь входе и для этого будет производится максимально быстрое считывание. В этом режиме не будет происходить ничего, кроме считывания сигнала. Частота сигнала от 0 Гц до примерно 5 кГц, но, чем больше будет частота дискретизации, тем лучше. В остальное время, когда данные передаются медленно, будет выполняться много всяких вычислений и управление периферией, в том числе 10 разрядным ШИМ с изменением частоты.
Если есть возможность увеличить разрядность ШИМ больше 10, буду рад узнать как это сделать.
Ну, толком-то работать не будет, будет глючить, но если Вам так нравится - делайте.
Неясно ещё как и где описана i.
Слово "Нравится" здесь не совсем уместно. Как получается, на что ума хватает, так и делаю.
Если есть способ ещё больше увеличить скорость выборки, поделитесь им, пожалуйста.
Так работает быстро.
А так работает медленней.
Ваша беда в том, что Вы не понимаете почему и плетёте вокруг этого какую-то ересь.
тот код проверено работает
Вы проверять не умеете.
Я Вам уже писал, что тот код глючный до безобразия. Не верите - дело Ваше.
Под быстротой я понимаю увеличение частоты дискретизации непрерывного изменяющегося сигнала.
Вы можете для начала объяснить пару вещей
1) какая частота дискретизации нужна?
2) насколько критично точно выдерживать эту частоту? И насколько точно?
Так работает быстро.
А так работает медленней.
Ваша беда в том, что Вы не понимаете почему и плетёте вокруг этого какую-то ересь.
Да, я не понимаю (хоть и догадываюсь). Но ведь быстрее работает, это факт.
тот код проверено работает
Вы проверять не умеете.
Я Вам уже писал, что тот код глючный до безобразия. Не верите - дело Ваше.
Да почему же не верю ? Какого рода глюки я должен наблюдать ? Если периодические "провалы" сигнала до нуля и случающиеся потери целый кусков сигнала по времени, то это я уже видел. Дело в том, что приёмная сторона на ПК примерно в такой же стадии, что и программа для Ардуино и не имеет нормальной привязки ко времени, поэтому четко отследить все потери не получается. Сейчас я пытаюсь, если можно так сказать, пощупать все возможности контроллера и потом принять решение о допустимых предельных параметрах работы будущего прибора.
Под быстротой я понимаю увеличение частоты дискретизации непрерывного изменяющегося сигнала.
Вы можете для начала объяснить пару вещей
1) какая частота дискретизации нужна?
2) насколько критично точно выдерживать эту частоту? И насколько точно?
1. Максимально возможная. Нет предела совершенству. Чем выше будет разрешение, тем лучше.
2. Критично. Про точность затрудняюсь ответить. Опять же, чем точнее, тем лучше, но во всём приходится искать компромисс. Могу сказать, что если где-то произойдёт сбой при рисовании сигнала, хоть по времени, хоть по величине - трагедии не произойдёт, ничего не сломается и все будут живы и здоровы. Просто, при подозрении на брак, будет проведено повторное считывание.
1. Максимально возможная. Нет предела совершенству. Чем выше будет разрешение, тем лучше.
2. Критично. Про точность затрудняюсь ответить. Опять же, чем точнее, тем лучше,
Это не разговор. Это означает, что Вы сами не знаете чего хотите. Когда узнаете - скажете.
Начинать надо как раз с этого: определиться "что нужно". А потом уже думать, как делать. Может ардуина в принципе для этой задачи не подходит.
Второй вариант - ЧУШЬ !!! Выводить надо только новые данные - значит нужен флаг обновления.
1. Максимально возможная. Нет предела совершенству. Чем выше будет разрешение, тем лучше.
2. Критично. Про точность затрудняюсь ответить. Опять же, чем точнее, тем лучше, но во всём приходится искать компромисс. Могу сказать, что если где-то произойдёт сбой при рисовании сигнала, хоть по времени, хоть по величине - трагедии не произойдёт, ничего не сломается и все будут живы и здоровы. Просто, при подозрении на брак, будет проведено повторное считывание.
АЦП у ардуины может делать почти 80 тысяч измерений в секунду. И что вы с таким потоком данных делать будете? Ну хорошо, при работе АЦП с максимальным разрешением он дает 15 тысяч измерений в секунду. Для контроля формы сигнала в 5 КГц это маловато, а для передачи по сериал порту - многовато. Можно поднять скорость передачи и выше чем 115200, но тут тоже есть свои подводные камни.
И не надо использовать прерывания для получения большой скорости. По крайней мере так как это делаете вы.
Если хоти получить нормальное устройство - надо начинать с ТЗ где продумать какие данные, с какой точностью и с какой частотой надо измерять и передавать. Вполне возможно что ардуино и не потянет и надо будет брать что нибудь из STM32
nik182, да, прошу пардону, я сослепу на планшете нолик лишний разглядел. тама 11520 было, а я 115200 увидел.
Аsam! Просто с языка снял. Блюпил может 8 каналов со скоростью 100000 сэмплов в секунду по каждому каналу выдать в компьютер по своему USB без задержек на скорости 12 МБит. Вся программа займёт 10 строк своего текста и сколькото строк куба.
для передачи по сериал порту - многовато. Можно поднять скорость передачи и выше чем 115200, но тут тоже есть свои подводные камни.
У меня сейчас на 1000000 работает.
И для этого же использую write, а не print. Это-то хоть разумное решение ?
И не надо использовать прерывания для получения большой скорости. По крайней мере так как это делаете вы.
Какие есть ещё варианты ? Какой вообще предел скорости (дискретности) для оцифровки сигнала ?
Если хоти получить нормальное устройство - надо начинать с ТЗ где продумать какие данные, с какой точностью и с какой частотой надо измерять и передавать.
Частоту я назвал - 0-5кГц, большую часть времени будет середина диапазона. Если при этом 1 миллисекунда будет представлена 100 точками - это будет вполне себе здорово. Собственно, при такой вводной и частота уже не так важна, на сколько я понимаю. Вот только вряд ли это удастся осуществить. 50 точек на миллисекунду тоже вполне не плохо. Но и такого результата, наверное, не достичь. Поэтому придётся довольствоваться любым разрешением, которое только удастся получить.
Вполне возможно что ардуино и не потянет и надо будет брать что нибудь из STM32
Понимаете, я только учусь работать с МК. Это для меня совершенно новое направление. Только вместо стандартных уроков по миганию лампочками я взял реальную задачу. Ардуино удобно тем, что по ней много информации. А так-то, конечно я бы предпочёл МК с большими возможностями. К тому же, аппетит приходит во время еды. Вначале задача была намного скромнее.
Напрасно. Ну и коль ты только начал, почему бы сразу не прочитать за матчасть умные книшки, а не сыпать дебильными вопросами на форумах?
Напрасно. Ну и коль ты только начал, почему бы сразу не прочитать за матчасть умные книшки, а не сыпать дебильными вопросами на форумах?
Во-первых, читал. С чего ты взял что не читал ? (сейчас последует вопрос, что именно я читал)
Во-вторых, если всё решается чтением книжек, то как ещё существуют форумы ? Только чтобы хвастаться достижениями ?
В-третьих, какой вопрос дебильный и почему ?
О каких форумах ты говоришь ? И что напрасно: что учусь или что лампочками не мигаю ? (вообще, мигаю, только через ШИМ и контролируя ток при этом).
Во-первых, читал. С чего ты взял что не читал ? (сейчас последует вопрос, что именно я читал)
Во-вторых, если всё решается чтением книжек, то как ещё существуют форумы ? Только чтобы хвастаться достижениями ?
В-третьих, какой вопрос дебильный и почему ?
О каких форумах ты говоришь ? И что напрасно: что учусь или что лампочками не мигаю ? (вообще, мигаю, только через ШИМ и контролируя ток при этом).
Ах, виноват, боярин, не признал учёного.
Классическое развитие событий.
Классическое развитие событий.
Абсолютно точно! Очередной свежеиспеченный умник со своими бредовыми идеями, который не хочет слушать то, что ему говорят опытные люди.
Классическое развитие событий.
Абсолютно точно! Очередной свежеиспеченный умник со своими бредовыми идеями, который не хочет слушать то, что ему говорят опытные люди.
Вообще-то главный вопрос, ради которого была создана тема, был решён практически сразу, за что я поблагодарил Евгения. Затем, пойдя по своему пути я столкнулся с ещё одной проблемой из-за незнания происходящих процессов, и причину которой также удалось понять благодаря Евгению.
А вот потом все в один голос начали говорить, что так (как я потом сделал) делать нельзя и что это не правильно. Но, я разве с кем-то спорил ?! Хоть раз сказал, что так можно и правильно ? Я сказал, что так работает быстрее, какой получил результат, о таком и объявил. И даже, напротив, на неоднократные просьбы рассказать как добиться скорости и сделать правильно, ответа не последовало. И вместо вразумительных объяснений, звучала старая пластинка про "нельзя". Ни об отсутствии глюков, ни о сохранности данных я не от утверждал.
Так за что же меня обозвали дебилом ? А умником не за то ли, что после тщетных попыток объяснить всем что я делаю и что требуется, я резко ответил на хамство DetSimen ? Если на этом форуме принято слепо копировать предоставленный код, не разбираясь в нём, и довольствоваться им, то это печально. Так уж сложилось, что я не приемлю ультимативных рекомендаций, мне нужно объяснение. Если не беру слепо ваш код, это не означает, что я с вами не согласен. О чем разгорелся спор в этой теме - не понятно. Спора-то нет.
Хоть раз сказал, что так можно и правильно ?
Что бы сказать как правильно, надо понять что именно вам нужно, а вы не колетесь. Если брать вашу аналогию "Решил я купить машину, чтобы ездить на работу и на дачу" то в той же ценовой категории можно купить и грузовичек и кабриалет. Вот вас и спрашивают "а на дачу вы собираетесь навоз возить или баб", а в ответ никакой конкретики.
Да плюс вы и не читаете что вам пишут. Вот в #36 я писал "АЦП у ардуины может делать почти 80 тысяч измерений в секунду.... при работе АЦП с максимальным разрешением он дает 15 тысяч измерений в секунду", а в #39 вы спрашиваете " Какой вообще предел скорости (дискретности) для оцифровки сигнала ? "
Работа на максимальной скорости снижает точность измерения, вот вас и спрашивают "какая точность требуется" и где конкретный ответ??
От атмеги 168 или 328 вы можете получить максимум 77 КГц выборки с низкой точность. При 5 КГц сигнале это вам даст не сто и даже не 50 а всего около 15 точек на период. Вас это устроит?
Ну а если надо сделать 100 измерений на максимальной скорости, то да нужно будет использовать прерывания, но ни в коем случае не вызывать там SerialPrint, поскольку это сильно все будет тормозить. А надо
-Поставить минимальный делитель
-Перевести АЦП во Free Running Mode
-Разрешить прерывание по окончанию оцифровки
-В прерывании ни делать ничего кроме считывания данных с АЦП и складывания в память
-А уж после окончания 100 или сколько там еще циклов запрещаем прерывания от АЦП и передаем полученные данные в сериал порт.
Но все равно больше 77К на вашем чипе не выйдет. Поэтому стоит подумать о STM32
Да плюс вы и не читаете что вам пишут. Вот в #36 я писал "АЦП у ардуины может делать почти 80 тысяч измерений в секунду.... при работе АЦП с максимальным разрешением он дает 15 тысяч измерений в секунду", а в #39 вы спрашиваете " Какой вообще предел скорости (дискретности) для оцифровки сигнала ? "
Я каждое сообщение перечитываю по многу раз.
А вопрос был ответом на это "Для контроля формы сигнала в 5 КГц это маловато, а для передачи по сериал порту - многовато. Можно поднять скорость передачи и выше чем 115200, но тут тоже есть свои подводные камни. " Но без вводных данных он глупый, я понимаю. Предполагал, что кто-нибудь сошлётся на свой опыт подобной работы и скажет с каким сигналом реально работать для тех или иных задач.
Работа на максимальной скорости снижает точность измерения, вот вас и спрашивают "какая точность требуется" и где конкретный ответ??
От атмеги 168 или 328 вы можете получить максимум 77 КГц выборки с низкой точность. При 5 КГц сигнале это вам даст не сто и даже не 50 а всего около 15 точек на период. Вас это устроит?
Да, меня это устроит. Если это предел, то с ним и буду работать. Я несколько раз об этом говорил. Получить максимум скорости. Это для меня будет отправной точкой. По ходу испытаний будут проводится корректировки - снижаться скорость в угоду точности и наоборот, пока не будет достигнут компромисс. Но он будет достигаться опытным путём в реальных условиях, с реальным сигналом.
Ну а если надо сделать 100 измерений на максимальной скорости, то да нужно будет использовать прерывания, но ни в коем случае не вызывать там SerialPrint, поскольку это сильно все будет тормозить. А надо
-Поставить минимальный делитель
-Перевести АЦП во Free Running Mode
-Разрешить прерывание по окончанию оцифровки
-В прерывании ни делать ничего кроме считывания данных с АЦП и складывания в память
-А уж после окончания 100 или сколько там еще циклов запрещаем прерывания от АЦП и передаем полученные данные в сериал порт.
Да, я тоже к этому пришёл, а Вы подтвердили это направление. И nik182 об этом же говорил в сообщении №12, только тогда это было совершенно непонятно.
Но все равно больше 77К на вашем чипе не выйдет. Поэтому стоит подумать о STM32
Наверняка так и будет. Но гораздо позже. Пока учусь на Ардуино.
Большое спасибо за разъяснения !
Программы arduino написанные расширением arduino работают как родные на stm32, только быстрее и с большей памятью и разрешением АЦП. Там для Вашей задачи analogRead и serialPrint выведут всё что Вы хотите без всяких прерываний и даже больше. Плата блюпил за 120 руб.
Классно ! Спасибо.
Почитал немного про STM. Интересная штуковина. Только, как я понял, в ней нет EEPROM-а, придётся отдельно прикручивать.
Теперь работа затормозится, буду думать переходить или нет. :)
Епрома завались. Не много больше. Называется только по другому, но это не мешает сохранять десятки килобайт.