Atmega8A и АЦП скачут показания

goldenandy писал(а):

Самсусамыч, на два сообщения выше вашего вопроса про 8 мс

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

[RUNA]

goldenandy, АЦП и так все время включено.
Окончание преобразование я не жду в прерываниях. Обработку делаю в основном цикле(выше показал sbi ADCSRA,ADIF).
akl, Временно убрал среднее, считываю сумму значений.
Самсусамыч, каждые 8мс 1 преобразование и так 64 раза

Поменял мк, повесил кондер на AREF, все так же. Буду думать, видимо накасячил где то с программой.

Понял.

RUNA писал(а):

Поменял мк, повесил кондер на AREF, все так же. Буду думать, видимо накасячил где то с программой.

Ну раз и с другим МК тот же баг значит однозначно ошибка в программе…

[GoldenAndy]

RUNA, АЦП и так все время включено, откуда нам это знать? Полной инициализации АЦП и работы с ним мы так и не увидели....

убирайте всё, оставляйте только инициализацию и работу с АЦП в тупом цикле, без прерываний.... Считали, выплюнули в УАРТ, опять считали, опять выплюнули. Без прерываний, всё на тупых проверках флагов. По минимуму. Всё остальное уберите.

У вас получится ВЕСЬ листинг на страничку-полторы.

И потом проверяйте... Чудес не бывает.

[RUNA]

Буду разбираться. Потом сообщу что получилось.

[RUNA]

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

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

[RUNA]

Это я в курсах. Только SREG не сохронял.

[COKPOWEHEU]

Если у вас меньше 20% запаса по средней (не пиковой!) производительности и памяти - стоит подумать о смене контроллера или оптимизации. Просто на случай дальнейших расширений, исправлений ошибок или просто модификаций.

[GoldenAndy]

RUNA, ваше право.
но. Си - не медленный. И код при должном написании ненамного больше ассемблерного. Но пишется гораздо быстрее.
А если не хватает МК - то проще взять следующий, как советует COKPOWEHEU, нежели мучиться с асмом.
Сам на атмегах начинал на ассемблере. Когда пришлось писать под Мегу32 - сказал себе - ну его лесом. Я уже не пионер, что бы преодолевать трудности.

ЗЫ. По выбору языка программирования развивать тему не буду, ибо оффтоп и холивар.

[COKPOWEHEU]

goldenandy писал(а):

А если не хватает МК - то проще взять следующий, как советует COKPOWEHEU, нежели мучиться с асмом.

Вы меня неправильно поняли. Запас по производительности не зависит от языка и даже от задачи. Это просто страховка на исправление багов или добавление функционала. Тут уместно вспомнить рассказ "История одного байта".
С переходом на Си немного другой аспект. Действительно критичных к скорости мест в коде немного. И вот в них имеет смысл упарываться в оптимизацию, ассемблерные вставки, неопределенные поведения и прочее. А, скажем, инициализация периферии, которая выполняется один раз при старте программы - да пусть хоть секунду выполняется, суммарный вклад будет ничтожным.
Так вот, часть из "запаса на расширение" вполне можно потратить на менее экономный язык. Причем потеря не будет существенной: при грамотном подходе разница между Си и Асмом может вообще отсутствовать (сам код, правда, будет малочитаемым...). Если же без фанатизма, то вполне высокоуровневый код прекрасно можно уместить в тот же 10-20% запас. Причем, что интересно, запас при этом никуда не денется: если возникнет необходимость, соответствующие места все так же можно переписать на Асме.
.
Сразу же предостерегу от опасности языков высокого уровня. Они старательно прячут детали реализации под слоями абстракций. С одной стороны, это хорошо: невозможно одновременно держать в голове и развесистый алгорим, и менеджмент регистров, и смещения указателей на поля классов. С другой, почти всегда слои абстракции это потеря эффективности. Иногда незаметная (скажем, макрос только увеличивает время компиляции на долю процента), а иногда на порядки. И вот тут хорошо бы иметь хотя бы общее представление во что развернется та или иная конструкция. Скажем, какой скорости можно в принципе достичь на Ардуиновском digitalWrite(...)? Уместно ли его использование? Если достаточно дернуть релюшкой примерно раз в вечность, то почему бы и нет, а вот в программный SPI его будут ставить только слабоум ардуинщики. А что на счет дробных чисел?

[GoldenAndy]

COKPOWEHEU, я вас прекрасно понял.
Использование ЯВУ не освобождает от понимания работы МК и его периферии....
Но зачастую нехватка производительности и нехватка памяти под программу идут рядышком.
В этом плане голый Си тем и хорош, что он достаточно низкоуровневый. И если не использовать монстроподобные андурино-библиотеки, а писать свое - то приближается к ассемблеру плюс 10% накладных расходов.
В ЯВУ больше накладных расходов скрыто от юзера - сохранение регистров при входе в прерывание, например....

Но в общем правильно - всё зависит от цели. Ногодрыг релюхой можно и на андурине сделать через digital_write.
Более сложное что то, использующее кучу аппаратных ресурсов - тут всё писать самому. Если быстро писать - то ЯВУ. Если задача критична ко времени исполнения и уже находится "на грани" возможностей МК - тут да, асм. (но правильней взять следующий в линейке МК ).

Добавлено after 2 minutes 29 seconds:
А по поводу слоёв абстракции - вот чем мне нравится Си, который gcc в АтмелСтудии - нет там практически никаких обёрток, кроме PROGMEM, EEPROM и прерываний...

[NStorm]

Если задача критична ко времени исполнения и уже находится "на грани" возможностей МК - тут да, асм. (но правильней взять следующий в линейке МК ).

Или другой МК. И вообще обычно это единственно правильный путь - выбирать МК под задачу, а не страдать над оптимизацией кода настолько дотошно. 2020 год на дворе - МК на 480 МГц дешевле $5 купить можно.

А по поводу слоёв абстракции - вот чем мне нравится Си, который gcc в АтмелСтудии - нет там практически никаких обёрток, кроме PROGMEM, EEPROM и прерываний...

Да и PROGMEM уже устарел и можно заменить на const __flash.

[RUNA]

Или другой МК. И вообще обычно это единственно правильный путь - выбирать МК под задачу, а не страдать над оптимизацией кода настолько дотошно. 2020 год на дворе - МК на 480 МГц дешевле $5 купить можно.


Если мне надо 20 входов и если приложить голову к мк то мне с запасом хватит и 16 мгц. То по вашей логике, мне нужно взять камень на 400мгц с 100 ногами (пусть будет запас по ногам и скорости). Так что ли. А еще к этому камню купить ПО что бы писать программы.

[COKPOWEHEU]

А эти "МК на 480 МГц" бывают в человекопаяемом корпусе? То есть менее 64 выводов и шаг хотя бы 1 мм.

[GoldenAndy]

COKPOWEHEU, при должном желании стм32 с шагом 0.5 мм легко паяется. Главное, припоя не переборщить.
И кста, Мега 32/64/128 с шагом 0,8 мм...
RUNA, зачем утрировать. Вы же сами написали - мк подбирается под задачу.
Просто под большую и сложную задачу нужен мк потолще, под простую - попроще.
Другое дело, что изделие может получать данные по двум проводам, обрабатывать их, писать результат на флешку по четырем и еще по двум (и2ц) рисовать картинку на дисплее.
Вроде как мега 8 пойдет. А вот увы - поддержка файловой системы, маломальские ресурсы для дисплея и код обработки уже от вас захотят мегу 328 или 32...
Можно и в восьмую попробовать на асме утрамбоваться. Но это будет мозголомство, не стоящее дельты цены между М8 и М328...
так что утверждение, что надо брать проц на 400 МГц и 100 ног не лишено некоего смысла.... Если камень на 48 ног и 64к памяти стОит 0.8$, а такой же, но на 128к 0.85$ - то смысла экономить нет...
Кстати, те же меги - мега 328, мега 32 и мега 128 у китайцев стоят в районе доллара.

И, кстати, АтмелСтудия - бесплатна. Равно как и АтолликСтудия для СТМ.

[COKPOWEHEU]

С шагом 0,5 вполне паяется, но ИМХО это предел ЛУТа, плюс уже нужен неплохой скил, зрение и терпение. Не для новичков это.
На счет компилятора - чем обычный gcc не устраивает? Мне так хватает...

[GoldenAndy]

COKPOWEHEU, так gcc и используется. Что в Атоллике, что в Атмел студии.
Не путайте компилятор и среду разработки.
Можно и голый gcc, писать в блокноте, make звать вручную...
Но в студии в большинстве случаев - удобнее. Проект создал в несколько кликов мышем, код написал, F7 нажал и получил хекс.
ЗЫ. Скатываемся в холиварчик-с

[COKPOWEHEU]

я потому и ушел от AVRStudio что она не смогла с ходу правильно запуститься под wine. А потом оказалось, что без IDE удобнее

Две страницы флуда… парни, выясняйте это в личке... модераторы почистите пожалуйста тему.