Если надо иметь на выходе функции единицу, если хоть один флаг выставлен, то используйте или лог.ИЛИ или даже побитное ИЛИ.
Или можно сразу объявить структуру с полями flag_up и flag_dn, тогда return сможет вернуть оба значения одновременно. Правда нужно помнить, что вызов функции в условии, где поочередно проверяются поля структуры возвращаемой функцией, сама функция будет вызываться столько раз, сколько полей проверяется (тут два поля). Что не торт. Поэтому лучше сначала значение функции буферизовать в локальную переменную того же типа.
ЗЫ. По существу вопроса. А зачем вообще возвращать значение функции, если ГЛОБАЛЬНЫЕ переменные имеют это самое значение? Бессмыслица.
У Вас очень плохо организован опрос кнопок Опросить пин ... подождать 15 миллисекунд - чтобы ещё раз опросить .... (см. скрин 1) хм...
Далее, Вам нужно ДВА флага для ваших кнопок. Зачем используете ДВА байта ? Далее, Вы используете всего ОДИН флаг кнопок - или ПЛЮС или МИНУС, зачем тогда используете ДВА байта, и не исключаете использование второго - в случае если кнопка ПЛЮС зафиксирована?
Далее, Вы пришли в основной (майн) код. Вы собираетесь только этим заниматься, или там будет ещё куча всяких действий?
Так может не нужно просиживать по 15 - 100 миллисекунд без всяких других действий? Может просто организовать некий тайминг с прерыванием на основе ЛЮБОГО свободного таймера, настроить его на некую константу прерываний, а всё остальное (включая задержки) пусть пляшет от того тайминга (см. скрин 2).
всем привет ) сразу,у меня это одно из хобби.экспериментатор(как в песенке группы Алиса) это в общем то не совсем по языку Си ,но про Pic мк.я решил не создавать новую тему,если что сделаем.
вопрос по такому. в МК есть аппаратные сбросы по WDT/POR/BOR,флаги их.. как мне правильно это все обрабатывать?
например мк(устройство работало штатно) произошел сброс по снижению напряжения питания.1секунда потери например. цель - для пользователя это просто моргнул индикатор,все работает ка и было. возьмем что то,часы пусть. при сбросе адрес выполнения программы переходит на 0x0000,получатся начало ?
Код:
main(_) {...
т.е. проверять флаги,ЧП сброса в начале программы,до основного цикла ( while)) правильно я понимаю ? в общем случаем как тут быть,писать флаг что все,хорошо,затем при сбросе его проверить-если что то запуск индикатора и т.д.(часы) но если это более серьезное ,например эбу авто. как узнавать что на 1сек был затык ,и вернуться к норм работе? (это конечно грубый пример,там все серъезн)
получается я могу программно проверить только в главных функциях main() isr (interrupt )? как понять что система работала-сброс-опа,питание упало поднялось,это было включено.это нет ,идем сюда...?
После ресета, до main() проверить регистр PCON: POWER CONTROL REGISTER -> Determining the Cause of a Reset Будет ли МК что-то делать или нет потом, зависит от поставленных задач.
Код:
The Power Control (PCON) register contains flag bits to differentiate between a: • Power-on Reset (POR) • Brown-out Reset (BOR) • Reset Instruction Reset (RI) • MCLR Reset (RMCLR) • Watchdog Timer Reset (RWDT) • Stack Underflow Reset (STKUNF) • Stack Overflow Reset (STKOVF)
вопрос по такому. в МК есть аппаратные сбросы по WDT/POR/BOR,флаги их.. как мне правильно это все обрабатывать?
например мк(устройство работало штатно) произошел сброс по снижению напряжения питания.1секунда потери например. цель - для пользователя это просто моргнул индикатор,все работает ка и было. возьмем что то,часы пусть. при сбросе адрес выполнения программы переходит на 0x0000,получатся начало ?
Добрый вечер!
POR и BOR это флаги сброса мк. Т.е. вы запустили проц, проверили бит "POR" - если там НОЛЬ, то проц потерял питание. Обрабатываете сброс, этот флаг устанавливаете. При следующем старте проца с нуля (с адреса 0х0000) опять смотрите этот флаг. Если он равен НУЛЮ, то у вас пропало напряжение. Опять устанавливаете для себя ... ну... если нужно ... "BOR" - это типа пересброс проца при снижении напряжения до определённого уровня, уровень выбирается в конфигурации проца. Принцип работы такой-же: установили в софте, при сбросе - проверили. Вообще - это всё описано в даташите на конкретный проц, в пунктах "Reset" или "Device Configuration", и отличается от проца к процу.
А WDT - это контроль работы проца, т.е. если вы находитесь в стандартном там цикле работы (while) и периодически сбрасываете этот таймер, то проц работает нормально. А если по каким-то причинам прога ушла куда-то ... то вы уже не сбрасываете этот таймер, и тогда автоматический сброс проца по этому таймеру - вотчдогу. Вы можете его сбрасывать чисто в майне, можете сбрасывать в несколькиз местах, где программа бывает постоянно. Суть этого таймера - если что-то пошло не так, и вы не в основном коде, значит вы софтово не сбросите таймер-собачку и проц сбросится, и работа начнётся с нуля. А часы.... А часы чисто на пик16/18 делать смысла нет, проще отдельно поставить микросхему типа DS1302/DS1307/MCP7941x с отдельной батарейкой 2032 к примеру... Когда считываешь оттуда время - туда же в свободную память ОЗУ это же время и записываешь. Если очередной раз считал время из микросхемы, и предыдущее записанное не соответствует - значит - был сброс по каким-то причинам... Т.е. POR и BOR использовать не обязательно, а WDT желательно при неуверенности в качестве своей прошивки. Бывают сбои внешние, типа некого электромагнитного импульса, ну или что-то наподобие ... При этом проц может потерять некие рабочие данные. Но при этом, не будет внутреннего сброса. Для таких целей можно через энное время ( к примеру час) обновлять некую запрограммированную инфу из ЕЕПРОМ проца. Но это всё индивидуально, и каждый решает сам для себя - какой важности устройство, и что нужно периодически обновлять... К примеру, есть ребята (фирмы) которые любят приинициализации (запуске) их устройства - забросить статическую инфу в индикатор (некие названия), а после - обновлять только данные. В результате - приходишь на объект - а там кракозябры на индикаторе! Влево-вправо страницами меню передёрнул - инфа восстановилась. Вот как-то так.
А часы.... А часы чисто на пик16/18 делать смысла нет, проще отдельно поставить микросхему
Смысл в том, чтобы не было еще одной микросхемы. Просто потому, что она не нужна. Контроллер вполне справится с менеджментом своего питания в зависимости от режима работы. Для этого есть специальные версии чипов с ультрамалым потреблением PIC16LF. Но можно и на обычных делать. При питании от элементов 2032 нет никакого смысла брать LF. Саморазряд выше потребления.
А часы.... А часы чисто на пик16/18 делать смысла нет, проще отдельно поставить микросхему
Смысл в том, чтобы не было еще одной микросхемы. Просто потому, что она не нужна. Контроллер вполне справится с менеджментом своего питания в зависимости от режима работы. Для этого есть специальные версии чипов с ультрамалым потреблением PIC16LF. Но можно и на обычных делать. При питании от элементов 2032 нет никакого смысла брать LF. Саморазряд выше потребления.
Ну с одной стороны Вы правы, а с другой стороны ... микрочип почему-то не хочет делать в своих мк отдельную ножку питания ?!? А тогда, заглядываем в раздел "Electrical Charasteristics", и находим там минимальный режим потребления. Можно поискать в начале даташита, где указаны "Low Power Features", и тогда окажется - что если работает некий таймер-генератор 32768, то проц почему-то жрёт очень много
К примеру из сегодня используемых мной мелкочипов (12F629, 12F1822, 16F15214) для пультов с нормальным потреблением от батареек подходит только первый.
А в режиме работы вторичного генератора на 32768 Герц и при этом с потреблением 300 нА (DS1307) - мк у Микрочип вообще не найти ....
И тогда встаёт законный вопрос: батарейка и DS1307 за один бакс, или мучаться с выбором проца с характеристиками, которые практически недостижимы
Я не люблю скакать как блоха, меня устраивает продукция Микрочип, ну и соответственно - мне проще поставить стороннюю микросхему часов, да даже не стороннюю а микрочиповскую, но я буду знать - что напряжение пропало, а часы ещё тикают лет так 6-10
К примеру из сегодня используемых мной мелкочипов (12F629, 12F1822, 16F15214) для пультов с нормальным потреблением от батареек подходит только первый. А в режиме работы вторичного генератора на 32768 Герц и при этом с потреблением 300 нА (DS1307) - мк у Микрочип вообще не найти ....
Начнем с того, что ваш выбор МК Микрочипа в принципе не подходит для часов. И дело тут даже не в потреблении, а в количестве ног и наличии отдельного LP генератора с внешним кварцем ОДНОВРЕМЕННО. По количеству ног подходит PIC16F15214, но у него вообще нет осциллятора под внешний кварц. А по поводу потребления у вас странные аргументы. Часы изначально предполагают 99% работы чипа в режиме PD. То есть в слипе. Внешний кварц работает на первый таймер, который генерирует прерывания с периодом в секунду или две секунды (зависит от наличия секундных показаний часов). Вычисление времени и вывод делаются НА ПРЕДЕЛЬНОЙ СКОРОСТИ возможной для внутреннего генератора без PLL (обычно это 8 или16 МГц - зависит от МК). Все остальное время МК находится в слипе и потребляет ток этого режима. Для чипов LF это примерно 70 нА при напряжении питания 3 В. Если написать код на АСМе и работать с интервалом прерываний 1 сек, можно получить скважность работы в активном режиме порядка 30000...50000. Эта скважность является деноминатором тока потребления на частоте работы МК (8 или 16 МГц). Делим этот ток на деноминатор-скважность и прибавляем ток слипа. Гарантирую кратно меньшее потребление по сравнению с отдельным чипом. Ну и про срок работы от таблетки 2032. Ее емкость составляет примерно 100 мАч доступных для разряда без извращений. Номинальная емкость 145 мАч. Таким образом, при токе в 1 мкА она будет разряжаться 100000 часов. Это составляет 11 лет. Эта таблетка имеет срок хранения меньше этой величины. Поэтому говорить о токе меньше 1 мкА как о необходимой величине просто смешно. Даже 3 мкА вполне отличный результат для такого питания. Потребление порядка 100...200 нА применяется при питании устройств от слабых солнечных элементов в условиях искусственного освещения.
Последний раз редактировалось КРАМ Сб ноя 29, 2025 19:37:11, всего редактировалось 1 раз.
правда внутри это не STM32 от слова - совсем но зато на ОЗОНе продают - недорого
Вы правы Это имелось ввиду PIC12F629/1822/15214 - которые работают в качестве пультов и пики не продаются на Озоне в отличие от стм32 А то что чуть выше, в комментах то конечно не на пик12 И если смотреть на потребление, то к примеру пик18LFx5k22 ... там собакен 300 нАмпер, а 32768 всего-то 800 нАмпер Но я спорить не собираюсь https://drive.google.com/file/d/17c7gX2 ... sp=sharing
А когда людям посылаешь (предлагаешь) некие данные ... они обязательно должны быть курсами по учёбе ? Я ранее считал, что если здесь люди учаться работать с микроконтроллерами pic, то курсы не обязательны ... Человек Darkmaster спрашивает, кто-то помогает. В идеале - модератор - как самый знающий, а если нет, то люди со стороны. Или я не прав?
Заголовок сообщения: Re: Програмирование pic на СИ.
Добавлено: Вс дек 28, 2025 14:15:55
Модератор
Карма: 90
Рейтинг сообщений: 1432
Зарегистрирован: Чт мар 18, 2010 23:09:57 Сообщений: 4599 Откуда: Планета Земля
Рейтинг сообщения:0 Медали: 1
ALEKS1102X писал(а):
они обязательно должны быть курсами по учёбе ?
Нет. Но Вы, похоже, не заметили, что у меня был вопрос, а не утверждение. Качать архив без описания, чтобы посмотреть что там - такое себе занятие. Не проще было Вам дать описание, чтобы избавить людей от лишних скачиваний ?
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения