WinAvr в вопросах и ответах

[veso74]

ARV, как в том анекдоте про программный код и "Красную площадь" .
(пишу это с добрыми намерениями)

[ARV]

да, рекомендую все функции, которые не вызываются из других модулей, делать static

и еще: у вас очень много "магических" чисел в коде - то какие-то неочевидные lcd_data[temp_variable+5][3] = 0x25 - почему +5? почему [3]? и что за 0x25?!
то и того похлеще:

Код: Выделить всё

void LCD_XY (uint8_t x, uint8_t y)
{
	if (y>2) 
	{
		y-=2;
		x+=20;
	}
	Lcd_Comand(63+x+(y*64));
}

вы считаете, что это будет работать для ЖКИ другого "размера"? вы вспомните об этом при смене ЖКИ?

и почему бы вообще не использовать готовые библиотечки для этого?!

Добавлено after 4 minutes 28 seconds:
код работает...

я тут вчера внезапно узнал, что моя программа управления симисторным регулятором уехала в Канаду, а там сеть 60 Гц... и ко мне обратились с просьбой поправить. как вы считаете, если бы у меня все было на магических числах, как долго я бы решал эту задачу? а так я дольше разыскивал архив проекта (начинался еще в 2018 году), чем вносил в него изменения. сам себя не похвалишь - сидишь, как оплеванный... но я был горд сам собой, что в своё время написал код аккуратно и с соблюдением всех тех принципов, о которых я тут распространялся.

чего и всем желаю. лучше 5 раз код переписать заново, чем потом через 5 лет паниковать...

[Just_Fluffy]

Про то, что стек может наползать на данные, у меня закрадывалась мысль, а ответ Just_Fluffy полностью утвердил меня в моих предположениях.

Я просто предупредила, что такое может быть, когда занято почти все ОЗУ. Сама на такое натолкнулась один раз на восьмой меге.
Но на тот момент вы еще не указали, сколько у вас израсходовано ОЗУ, поэтому было такое предположение.
Если у вас свободно 85% оперативки - то забить ее стеком - это еще нужно постараться.... Какой то глубокой рекурсией, например.

Но я рада, что вы нашли место, где ваш код наползал на "чужие" данные - тоже выстрел себе в ногу )))).

[BDDW]

Всем доброго времени суток!
Извините но буду отвечать и задавать вопросы по мере появления свободного времени. Все сразу не осилю...
[uquote="ARV",url="/forum/viewtopic.php?p=4641211#p4641211"]1. Вот у вас есть функция PZEM_request, которая в свою очередь использует в цикле Uart_Transmit, которая, даже судя по названию работает с "медленным" USART (и по факту, это так)... и что, спросите вы? а то, что PZEM_request у вас вызывается из обработчика прерывания INT0!!!
вот и скажите мне, чем это отличается от ранее предвиденного мною?[/uquote]
На прерывании INT0 у меня висит синхронизация ШИМ с сетью. По этому это прерывание не должно "задерживаться", а тем более "пропадать".
Вы правильно заметили, что Я
[uquote="ARV",url="/forum/viewtopic.php?p=4641211#p4641211"]вместо медленного ЖКИ вы выводите в еще более медленный USART...[/uquote]
Прерывание INT0 происходит с частотой 100Гц или 0,01 секунды. Время на посылку запроса модулю PZEM-004t составляет ~0,009 сек. Так же для реализации ПИД регулятора требуется переменная "время". Именно по этому (с моей точки зрения) запрос в USART должен следовать сразу за синхронизацией ШИМ. В моем случае запрос модулю PZEM-004t 1 раз в 0,5 сек.
Ничего другого я не придумал. И пока не понимаю как можно от этого избавится или решить эту задачу иначе?

[ARV]

Я не могу вам сказать, как надо делать. Но я могу практически с уверенностью утверждать, что ждать окончания передачи символа по UART внутри обработчика прерывания не надо! Возможно, вот именно сейчас это не приводит к проблемам, так же, как я 100500 раз перебегал через рельсы перед несущейся электричкой, но ведь очевидно, что так делать нельзя!

Общее правило таково: в обработчике прерываний выставили флаг, в главном цикле посмотрели на этот флаг и, если он установлен, долго и медленно обрабатываем его, а потом сбрасываем.

[BDDW]

[uquote="codenamehawk",url="/forum/viewtopic.php?p=4641219#p4641219"]

Значит остальное может занимать стек.
Про то, что стек может наползать на данные, у меня закрадывалась мысль, а ответ Just_Fluffy полностью утвердил меня в моих предположениях.

У вас обоих неправильное предположение.[/uquote]

[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4641394#p4641394"]

Про то, что стек может наползать на данные, у меня закрадывалась мысль, а ответ Just_Fluffy полностью утвердил меня в моих предположениях.

Я просто предупредила, что такое может быть, когда занято почти все ОЗУ. Сама на такое натолкнулась один раз на восьмой меге.
Но на тот момент вы еще не указали, сколько у вас израсходовано ОЗУ, поэтому было такое предположение.
Если у вас свободно 85% оперативки - то забить ее стеком - это еще нужно постараться.... Какой то глубокой рекурсией, например.
Но я рада, что вы нашли место, где ваш код наползал на "чужие" данные - тоже выстрел себе в ногу )))).[/uquote]
Большое спасибо. Вы меня не правильно поняли. Просто когда не работает, ты уже бьёшься головой об стенку, начинаешь проклинать тот день и тот час, когда пришла в голову мысль сделать сей девайс, а 10 чувство тебе подсказывает, что где то данные бьются или друг на друга наезжают... А тут такое сообщение. И мысль полностью выкристаллизовывается, тебе уже не важно, что это было: утверждение, предположение, предупреждение... Все, в заднице факел, а в глазах огонь - ЭТО ОНО!!!
Еще раз большое спасибо! Уцепившись за эту мысль, я начал внимательно смотреть на события предшествующие сбою и вышел на ту функцию, про которую раньше и не мог подумать... Но это пока не точно. Сейчас я ее переделал. Надо провести полные испытания.
[uquote="codenamehawk",url="/forum/viewtopic.php?p=4641219#p4641219"]

Пожалуйста, не пинайте меня сильно, но я не знаю как это сделать.

То был вопрос, а не совет подключить.[/uquote]
Так библиотека для работы с float подключена? Как ее подключить? Пожалуйста, помогите мне поставить раз и навсегда точку в этом вопросе.

[ARV]

Поддержка float всегда есть, отдельно надо подключать только библиотеку поддержки ввода-вывода float средствами stdio, т.е. если надо выводить при помощи printf

Добавлено after 58 seconds:
И/или вводить при помощи scanf

Добавлено after 2 minutes 15 seconds:
Ну или использовать std::cin и std::cout для этого, если С++

[BDDW]

[uquote="ARV",url="/forum/viewtopic.php?p=4641221#p4641221"]почитайте мою статью (правда, там движок сайта попорчен и код не красивый) о нисходящем программировании: https://simple-devices.ru/articles/7-so ... 0-16-40-05
может быть, на какие-то мысли вас натолкнет.[/uquote]
Это подходит в том случае, если есть четкое или какое-нибудь Т.З. А если такового нет?
Используя Ваш пример с покупкой колбасы, моя реальность выглядит так:
Теплый солнечный день. Выходной. Отличное настроение и хочется выйти из дома прогуляться. Но куда и зачем?
И тут вспоминаешь, что на работе кто то говорил про нового мужика на рынке, который торгует отличной колбасой. Именно туда и надо идти.
Ходишь по рынку, смотришь что продают, интересуешься ценами. Доходишь до колбасных рядов и видишь один прилавок отличающийся ассортиментом от других. Правда торгует не мужик, а женщина, но зато продукцией домашнего изготовления.
Пробуешь. Разыгрывается аппетит. Но колбаса - хорошо, а хочется к ужину чего-нибудь "горячего". Она тебе предлагает домашние купаты, которые изготовлены по тому же рецепту что и колбаса, но только сырые. Их можно поджарить как на мангале, так и на сковородке. По этому покупаешь и колбасу и купаты... Ну, надо же сравнить.
И вот тут в голове начинает вырисовываться меню на ужин. По этому покупаешь еще картошку и молоко для пюре.
По пути домой с рынка встречаешь знакомого, который тебе сообщает, что в КБ появилась великолепная водка из Белоруссии. И стоит дешево. Поэтому тут же заходишь в ближайший КБ и еще покупаешь бутылочку.
[uquote="ARV",url="/forum/viewtopic.php?p=4641221#p4641221"]в общем, моё мнение однозначно: нужен глубокий рефакторинг кода. чтобы и собственное понимание задачи и пути её решения выкристаллизовалось лучше.[/uquote]
Это следствие выше описанных действий. Т.е. когда у тебя еще нет абсолютно никакого представления о том, что будет дальше.
А так, бы (возвращаясь к выше описанному) сразу бы на рынке купил бы еще малосольных огурчиков и маринованных грибов. Но когда на столе все стоит горячее, а рядом запотевшая бутылочка.... уже нет желания бежать на рынок за огурчиками и грибочками.
[uquote="ARV",url="/forum/viewtopic.php?p=4641221#p4641221"]у вас в коде намешаны низкоуровневые операции типа обращения к портам с высокоуровневыми действиями типа расчетов полученных извне значений.
то же самое касается и "деления" кода на функции: складывается впечатление, что это делалось не путем разработки алгоритма, а путем вычленения кусков "гладкого кода" в отдельные кусочки, чтобы просто хоть как-то можно было уследить за ходом процессов... но так писать не стоит.[/uquote]
Думаю, что ярким примером того будет функция измерения температуры - Meas_Temperatura. (она описана в ds18b20.с и использует wire.h)

Спойлер

Код: Выделить всё

float Meas_Temperatura (void)
{
	uint16_t DS18b20;											//переменная для считывания регистров DS18b20
	uint8_t _1Wire = 0;
	_1Wire = Wire_init();										//инициализация датчика 1-Wire
	Wire_sendComand(0xCC);										//Skip ROM пропуск ROM команда всем устройствам на шине 
	Wire_sendComand(0x44);										//все датчики одновременно считали температуру (температурное преобразование)
	_1Wire = Wire_init();
	Wire_sendComand(0xCC);										//Skip ROM пропуск ROM команда всем устройствам на шине 
	Wire_sendComand(0xBE);										//чтение памяти
	_1Wire = Wire_ButeRead();									//читаем 1 из 2х байт
	DS18b20 = Wire_ButeRead();									//читаем 2 из 2х байт
	DS18b20 <<=8;
	DS18b20 |=_1Wire;
	_1Wire = Wire_init();
	return (float)DS18b20/16;
}

И тут мне не понятно, как правильно было бы ее реализовать?
Сделать так, что бы эта функция возвращала uint16_t Raw_Temperatura, которая получается из двух байтов ответа датчика DS18b20. А потом float temperatura = (float)Raw_Temperatura/16;
Так?
[uquote="ARV",url="/forum/viewtopic.php?p=4641221#p4641221"]чем отличаются функции в следующем коде:

Код: Выделить всё

//Вычисление Тока
uint32_t PZEM_Current (void)
//Вычисление мощности
uint32_t PZEM_Power (void)
//Вычисление потребленной энергии
uint32_t PZEM_Energy (void)

три функции, которые делают абсолютно одинаковые действия! разница лишь в том, с какими ячейками массивов они работают! но ведь тут очевидно напрашивается ОДНА функция, которая получает в параметре номер первой рабочей ячейки, а уж остальное делает относительно этого адреса... поправьте меня, если это не так:[/uquote]
Вы абсолютно правы! Переделал эти три и еще три: вычисление частоты PZEM_Frequency, вычисление коэффициента мощности PZEM_PowerFactor и вычисление напряжения PZEM_Voltage.
Я когда отдельно изучал на практике модуль PZEM-004T, долго не мог получить от него "правильный" ответ. Вот и начал писать "по мануалу".
А когда все заработало, не задумался об оптимизации кода.
Большое спасибо! Очень помогло Ваше замечание.

[uquote="ARV",url="/forum/viewtopic.php?p=4641221#p4641221"]не знаю, что именно делает ваша программа, но, имхо, функция main должна выглядеть примерно так (кода нет, одни комменты к несуществующим функциям

Код: Выделить всё

int main(void){
  // инициализация всей периферии
  // обращение к внешней аппаратуре и инициализация её
  // подготовка данных (считывание из EEPROM? поиск там каких-то адресов и т.п.)
  // вывод на ЖКИ приветствия (или меню, заставки и т.п.)
  // запуск прерываний (это не обязательно, может, только некоторых из них)
  while(1){
    // измерения 
    // обработка измерений
    // вывод результатов
    // опрос событий EVENT (пришли данные по UART? нажаты кнопки? повернут энкодер? и т.п.)
    switch(EVENT){
      case EV_USART: // обработка данных из USART
        break;
      case EV_KBD: // обработка нажатий кнопок
        break;
      // и так далее, все события
    }
  }
}

и функции у вас должны работать с одними и теми же сущностями: если функция вычисляет, то она в порты не лезет, а если лезет в порты, то не вычисляет. как-то так.[/uquote]
Об этом я много где читал, но до конца не все понятно с прерываниями. Иными словами, если возвращаться к Вашему примеру с колбасой, то будет это выглядеть примерно так:
- утром срабатывает прерывание по таймеру - "проснуться, поставить чайник".
Ставишь чайник - кружишься в общем цикле: достать кружку, подготовить заварку, приготовить бутерброд с колбасой, поесть, одеться и т.д.
- Срабатывает внешнее прерывание - "чайник закипел"
Выключаешь чайник, - кружишься в общем цикле: достать кружку, подготовить заварку заварить чай. приготовить бутерброд с колбасой, поесть одеться и т.д.
- Срабатывает прерывание по таймеру "до автобуса на работу N минут".
Одеваешь ботинки, куртку и на остановку. А далее 8 часов ты не доступен для других прерываний. Точнее пока не выполнишь

Код: Выделить всё

case Perform_Work: // выполнение обязанностей на производстве 
        break; 

другие прерывания становятся в очередь.
Но ведь раньше может сработать внешнее прерывание "нет колбасы" и ты можешь уйти в

Код: Выделить всё

case Shopping_Trip: // поход за покупками
        break;

по выходу из которого вставшее в очередь обработки прерывание "до автобуса на работу N минут" - будет уже бесполезно, точнее в

Код: Выделить всё

case Perform_Work: // выполнение обязанностей на производстве 
        break; 

повиснешь до следующего дня стоя на остановке в ожидании автобуса на работу.
Как тут быть? Я не представляю, как сделать так, что бы пришло "самое главное прерывание", которое бы прервало текущую операцию в основном цикле и заставило бы там же (в основном цикле) исполнить

Код: Выделить всё

case Perform_Work: // выполнение обязанностей на производстве 
        break; 

после чего вернулось обратно к выполнению прерванной операции.

Код: Выделить всё

case Shopping_Trip: // поход за покупками
        break;

после работы по пути домой.
Мне очень хотелось бы понять, как с точки зрения гуру, следует строить программу прерывания. К примеру возьмем энкодер с кнопкой. Тут возможны следующие варианты:
1) читаем в переменную состояние порта;
2) обрабатываем считанное состояние (инвертирование, сдвиг в право, наложение маски);
3) производим распознование воздействие на энкодер (вращение или нажатие на кнопку) и взводим соответствующую переменную - press_button или rotating_control
4) распознаем действие: кнопка нажата "коротко", "долго" или "двойное нажате". Энкодер вращаем вправо или влево.
Я думаю, что все эти действия следует включать в прерывание. Или можно сделать как то по другому?
[uquote="ARV",url="/forum/viewtopic.php?p=4641221#p4641221"]не бойтесь сервиса, который предоставляет вам Си: ввод-вывод стандартными средствами сделан там вполне прилично, и, уверяю вас, сильно упростит вам жизнь.

https://simple-devices.ru/articles/7-so ... -interface вот так можно красиво работать "стандартными средствами" с ЖКИ
https://simple-devices.ru/articles/7-so ... console-io а вот так с USART

последним способом я пользуюсь уже много лет, и ни разу не пожалел. согласитесь, гораздо проще написать

printf("U=%d\nI=%d\n", U, I);

и тем самым отправить в USART две строки с значениями напряжения и тока, чем городить то же самое с помощью кучи массивов, циклов и т.п. неочевидных преобразований... 2 килобайта FLASH ради такого - не великая цена. ну и еще 2К, если никак без float в этом случае не обойтись... нервы дороже.[/uquote]
Согласен. Но боюсь. На выше приведенном примере я уже "вступил" в dtostrf. Кто бы мог подумать, что ему для вывода числа из N цифр, требуется массив размером N+1.
А так, я изучая LCD изучил его команды и написал свою библиотеку, которой теперь пользуюсь. И по мере необходимости ее изменять и адаптировать под свои задачи.

[ARV]

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

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

в большинстве случаев любая программа для МК взаимодействует с пользователем, что-то индицирует и что-то обрабатывает из внешних сигналов.
всё, к чему прикасается человек - медленное, поэтому я эти штуки делаю в главном цикле: обрабатываю нажатия кнопок, обновляю содержимое индикаторов, формирую всякие тексты и т.п. почти все, с чем МК имеет дело в плане остального - это вещи, не особо терпящие задержки, например, обмен по USART или обработка датчиков. поэтому эти вещи я обрабатываю по прерываниям.


где баланс? тут каждый раз надо искать золотую середину. например, USARТ: можно принимать по прерываниям байты в буфер, а в главном цикле периодически смотреть в этот буфер и извлекать оттуда данные. достаточно сложно в реализации.
можно не просто принимать данные в буфер, но и делать там же в прерывании первичную обработку, например, определять начало и конец пакета или конец строки... и сигнализировать в главный цикл только тогда, когда строка или пакет приняты целиком. сложность не выше предыдущего варианта, но программа получится намного проще в итоге! в главном цикле остается только та часть анализа данных, которую можно отнести к верхнему уровню, например, анализ значения введенного пользователем (а "низ" - выделение отдельных символов, преобразование в числа и т.п. уже сделаны где-то там, в прерывании).

и так далее.

но, разумеется, всегда есть нюансы. например, динамическая индикация - это штука, которая может попортить жизнь очень сильно, т.к. хоть сам процесс вроде и не главный, но крайне критичный к времени - кроме как по прерываниям, его не сделать, но из-за постоянных прерываний могут быть проблемы с другими критичными участками кода, например, с той же 1-wire. недавно пришлось делать чарлиплексинг (разновидность динамической индикации) аж для 48 светодиодов, и малейшее изменение периода индикации приводило к изменению яркости отдельных светодиодов - а ведь для 1-wire минимум на 60 микросекунд надо прерывания запрещать! и пришлось привычные функции работы с 1-wire модифицировать для работы по прерываниям - на каждом цикле динамической индикации обмениваться по 1 биту с датчиком температуры 1-wire... в итоге то, что раньше всегда было в главном цикле, перешло в фоновый режим, а в главном цикле остался только разбор значений...

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


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

Добавлено after 6 minutes 7 seconds:
P.S. в некоторых случаях можно очень многое сделать вообще без прерываний. например, я сделал автомат световых эффектов (я тут выкладывал проект) - там идет выдача данных на светодиоды WS2812b, работа с CD-картой, интерпретация текстовых скриптов - и в итоге внешне выглядит все, как непрерываное и одновременное, а на самом деле все делается строго последовательно: считали текстовую строку - распарсили её, исполнили команду, подготовили массив для вывода, когда весь массив заполнен - выдали его на светодиоды, считали следующую строку и т.д.

это стало возможным именно благодаря тому, что незаметный для человека интервал в 10 мс - это достаточно для выполнения поочередно всего вышеописанного, и даже еще 2-3 миллисекунды остается в резерве. так что без анализа задачи и продумывания алгоритма будет даже не колбаса, а фарш...

[OKF]

Обычно, делаешь как удобнее тебе, что бы было проще и меньше телодвижений. И тут во всём приходится искать компромисс. К примеру, индикация требует 500 мкс обновления, нормально, обходимся без прерываний. Остальные процессы шустренькие, а те которые нет, типа ds18b20 разбиваем на части. Да, беда в том что на запись в ЕЕПРОМ уходит много времени - ничего, это происходит редко, на это время индикацию можно выключить, это не будет заметно. Примерно так. Да, можно индикацию сделать по прерываниям, но там другие проблемы.) Вот так и находишь какой то свой компромисс. Понятно, что если делаешь что то универсальное, нужно учитывать все возможные варианты, а если конкретно, зачем уродоваться? Да и людЯм понятнее.)

[ARV]

А как связана индикация и запись EEPROM?! Ожидание завершения записи безболезненно может быть прервано на любое время для целей индикации или чего-то неотложного! Поэтому ваши заявления крайне непонятны!

Динамическая индикация всегда по прерываниям, и практически никогда ничему другому не мешает. Никогда не делал динамическую индикацию в основном цикле и никому не посоветую это делать! Ни-ког-да.

[OKF]

Не делал ты - не значит не делали другие. Ещё раз. Всегда стараюсь для себя делать проще. Если без прерываний, то индикация в основном цикле. Там же и запись в ЕЕПРОМ. Да, запись можно прерывать, но зачем, если она происходит крайне редко. Поэтому используется стандартная функция записи в ЕЕПРОМ.
Динамическая индикация по прерыванию зачастую мешает некоторым процессам. Например, при пассивном питании DS18b20 - тут надо изгаляться что бы никто не мешал вовремя подать питание на датчик.

[ARV]

Другие могут и штаны через голову надевать, но я другим никогда такого не посоветую, и не одобрю.

[OKF]

Слушаюсь. Впредь буду равнять только на тебя.) ППЦ, если серьёзно.

[ARV]

Да ни боже мой! Я ваще не эталон. Но собственное мнение имею, и не стесняюсь его озвучить.

[OKF]

[uquote="ARV",url="/forum/viewtopic.php?p=4659808#p4659808"]Но собственное мнение имею, и не стесняюсь его озвучить.[/uquote]
А если есть возражения, укажи конкретно, без этих афоризмов "через голову"и пр., не смеши.

[ARV]

Я, по-моему, вполне четко написал свои возражения. Но могу и разжевать: первичное с т.з. решаемой задачи просится в главный цикл, чтобы глядя на него был виден алгоритм. Вторичное просится куда-то "в фон": как минимум в функции и модули. Но некоторые фоновые задачи идеально ложатся на прерывания, и динамическая индикация - одна из них. Единожды сделанная, она не привлекает к себе внимание, ничему не мешает, и никак не портится извне. Чего не скажешь про вариант, когда она реализована в главном цикле.

Достаточно понятно изложил?

[OKF]

Ну вполне нормально. А чем плохо, в главном цикле:
- индикация
- измерения
- кнопки (интерфейс)
Как раз всё на виду.

[ARV]

Ну блин... О 5 25.
Динамическая индикация чувствительна к искажениям интервалов времени. Стоит в главном цикле появиться какому-нибудь немаленькому циклу или условию с неравными по затратам времени ветвями, как динамическая индикация превратится в тыкву. Или потребуются неслабые усилия по её адаптации к нововведениям. И так на любые добавки.

[OKF]

Да. Я же говорю, как себе удобнее!
А зато легко отлаживается. И понятна любому начинающему.