Ежли по флаг-битам как результату исполнения проверки (или по битам STATUS как частный случай) то есть весьма удобненькие btfsc f,b / btfss f,b обход последующей инструкции при выполнении условия. А ежли неверно - исполняется следующая команда.
Еще раз предлагаю ознакомить почтеннейшую публику со своей КОНЕЧНОЙ задачей. Копания типа"нужен-не нужен" не имеют никакого смысла. Структура кода должна позволять легко оперировать сущностями алгоритма, а не состоять из сплошных "конгениальных" заплаток, разобраться в которых невозможно уже на следующий день самому автору. О модификации кода тут даже речи не идет.
Разговоры о "как может быть" без учета конкретики в недавнем прошлом стали основой моей "винной" (https://radiokot.ru/forum/viewtopic.php?f=62&t=94201) - программы без схемы и конкретной задачи НЕ БЫВАЕТ. Поскольку один и тот же алгоритм может иметь множество прикладных реализаций - зависит от того, что в данном конкретном случае удобнее. Даже в рамках одного семейства (не говоря уже о различных). Вот потому и "затык" - без конкретики обсуждать наиболее удобное решение бессмысленно. Ибо ВСЕ ПРАВЫ будут.
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Ну с высоты профессионализма Вы можете, конечно, смотреть свысока Как это не экономит, )
памяти для команд хватит с лихвой. вообще нет смысла экономить при написании алгоритма. оптимизация должна происходить позже. да и то не всегда оправдана. так как МК уже не те что были раньше. просто подбираете под свои нужды нужны контроллер. особенно важно если этим зарабатываете на хлеб. где время решающий фактор.
памяти может не хватить лишь при использовании графики, аудио или еще каких то массивов данных. где оптимизация почти не поможет, так как этот тупо данные. вряд ли у вас что то подобное.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Здравия! Правильно ли я понимаю, что 16-и разрядный таймер TMR1 (pic16f627/628/648) можно использовать как 8-и разрядный, эксплуатируя только младший байт, а старший заполнив единицами? Вроде больше тонкостей нет?
А правильно ли я понимаю, что запретив прерывания глобально, но разрешив по таймерам, по окончании счёта PC не уйдёт по вектору прерывания 0x04, а выставятся флаги прерывания TMRxxIF (как-то так), и можно их проверкой установить факт переполнения? Чтобу не читать сами таймеры. pic16f628-648
Флаги взводятся независимо от разрешения прерываний. Разрешения прерываний расположены в контроллере прерываний, а флаги генерирует периферия. Поэтому прежде,чем разрешить прерывания, нужно сбросить флаги. Иначе вы получите генерацию прерываний по всем ранее взведенным флагам.
можно их проверкой установить факт переполнения? Чтобу не читать сами таймеры. pic16f628-648
Данный вопрос (как собственно его же и предыдущий) говорят лишь о том, что человек, увы, совсем не разобрался как работать с таймерами и как правильно их использовать. Правда это так же относиться и к общему пониманию составления алгоритма программы, исходя из возможностей выбранного МК.
По поводу алгоритма. А как правильно всё расставлять если процессы по времени часто пересекают друг друга? Например задержка от дребезга контактов (кнопок, энкодера) и обработка формирования меандра (с регулируемой частотой). С пиками знакомлюсь несколько дней (16f628 и т.п.), но похожих примеров на ассемблере пока не попадалось.
_________________ „Выживает не самый сильный и не самый умный, а тот, кто лучше всех приспосабливается к изменениям.“ — Чарлз Дарвин
Правильное планирование - наше всё. Разделить процессы по степени критичности по времени и соответственно реализовывать. Особо критичные по времени процессы делать или аппаратно, или по прерыванию от аппаратуры. Кнопки/энкодеры и дребезг - это не те процессы, которыми надо заморачиваться. Обычно их можно сделать как машину состояний, которую можно вызывать где угодно и сколько раз угодно и совсем не обязательно со строгой периодичностью. А вот чтобы это привязать ко времени, достаточно чтобы в системе был один таймер, который просто отбивал такт. Например в прерывании от TMR0 можете просто инкрементировать переменную systime или/и декрементировать переменную kbd_delay, если она имеет не нулевое значение. И их значения проверять в подпрограмме, которая и сообщит нажата ли кнопка или сделал ли шаг энкодер.
Вообще, представляя ваши затеи, скажу что уж больно тоскливый вы кристалл выбрали. Ну чтобы поучиться писать на ассемблере еще ничего, но когда надо будет перейти на C - вас ждёт разочарование из-за жлобства микромела - потому как нормального бесплатного инструмента для создания программ у них нет.
примеров на ассемблере не будет - я уже давно на нём не пишу, а старые сырцы где-то канули в лету.
Перечисленные вами функции сами по себе мешать друг другу не будут. Обработка энкодера и кнопок вообще не является функцией реального времени. Никаких задержек там не требуется. Защита от дребезга достигается простым чтением портов с интервалом превышающим время дребезга. Для кнопок это примерно 20мс, для энкодера - примерно 3...5мс. Управление частотой меандра зависит от скорости управления. То есть как часто и с какой задержкой допустимо изменять параметры ШИМ.
нормального бесплатного инструмента для создания программ у них нет.
Комбинируя код на С и ассемблере можно очень эффективно программировать 8-битные ПИКи в бесплатной версии компилятора. Это очень простая платформа, поэтому ничего сверхестественного от компилятора не требуется. Скажем, задачи озвученные автором можно сделать на ХС8 с нулевой оптимизацией. И без всякого ассемблера. Можно и на голом ассемблере...
Разделить процессы по степени критичности по времени и соответственно реализовывать. Особо критичные по времени процессы делать или аппаратно, или по прерыванию от аппаратуры.
А если критичность одинакова? От одного зависит другой, и могут пересекаться? Вот например, от периода зависит время задержки. Аппаратно недоступно, не хватит входов прерываний, да и уже спаяно, использую старую базу. Использовать не экстенсивный подход (другой мощный богатый контроллер), а интенсивный? Пища для ума, предвосхищая справедливые обвинения))
Защита от дребезга достигается простым чтением портов с интервалом превышающим время дребезга. Для кнопок это примерно 20мс, для энкодера - примерно 3...5мс.
А оптопара с модулятором-шторкой, надеюсь, не имеет дребезга?
МК штука вредная. Для того, чтобы чего-то обсуждать на уровне ассемблерных программ надо не "теорию с потолка" иметь в обсуждении, а конкретную схему устройства и описание того, что данное устройство должно выполнять. Ибо возможных решений огромное множество. Посему - делаем схемку, закладываем МК и алгоритм желаемой работы устройства - выкладываем для обсуждения. Далее на уже проработанный материал начинаем программу прилаживать (и, вполне возможно, схемку править) с учетом использования особенностей системы команд МК и его аппаратной начинки. Так что... Антидребезг можно и "внешний" - к примеру на R-S триггерах, собранных на 555ЛА3 да "перекидных" кнопках https://img.radiokot.ru/files/20529/1ci6nvk6db.JPG Да много еще чего (смотри к примеру https://sunduk.radiokot.ru/view/?id=1487946626 )... Зачем весь функционал на МК вешать при возможности внешней аппаратной предобработки данных?
Учусь, люди помогают, а сообщение Ваше хоть и правильное, но бесполезное
Для того, чтоб понять про что было моё замечание, см. очень верное:
BOB51 писал(а):
Для того, чтобы чего-то обсуждать на уровне ассемблерных программ надо не "теорию с потолка" иметь в обсуждении, а конкретную схему устройства и описание того, что данное устройство должно выполнять. Ибо возможных решений огромное множество. Посему - делаем схемку, закладываем МК и алгоритм желаемой работы устройства - выкладываем для обсуждения.Далее на уже проработанный материал начинаем программу прилаживать ...
Причём алгоритм желателен не описанием типа словесного ля-ля и даже не в каком либо языке, а сначала, к примеру, в виде графа. И когда решение вашей задачи будет соответствовать нужной логике процесса в данном виде, вот тогда уже можно будет давать какие-то рекомендации. Хотя замечу, что в данном случае (при достаточной самостоятельной подготовке вопрошающего ) частенько уже помощи почти и не требуется. Ну если только чуть-чуть.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 10
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
Как это не экономит, )
совсем не разобрался как работать с таймерами и как правильно их использовать. 
