Вопросы начинающих PIC ASM

[yor]

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

Код:

Init:
--
Start: call Delay
--
GOTO TrueFalse
PostTrFls: --
--
TrueFalse: --
--
goto Start
--
goto Start
--
GOTO PostTrFls
Delay:
--
return

Только лишнюю метку добавить.

[BOB51]

Ежли по флаг-битам как результату исполнения проверки (или по битам STATUS как частный случай) то есть весьма удобненькие
btfsc f,b / btfss f,b обход последующей инструкции при выполнении условия.
А ежли неверно - исполняется следующая команда.

[КРАМ]

yor писал(а):

вызов процедуры тут совсем не нужен

Еще раз предлагаю ознакомить почтеннейшую публику со своей КОНЕЧНОЙ задачей.
Копания типа"нужен-не нужен" не имеют никакого смысла.
Структура кода должна позволять легко оперировать сущностями алгоритма, а не состоять из сплошных "конгениальных" заплаток, разобраться в которых невозможно уже на следующий день самому автору. О модификации кода тут даже речи не идет.

[BOB51]

Разговоры о "как может быть" без учета конкретики в недавнем прошлом стали основой моей "винной"
(https://radiokot.ru/forum/viewtopic.php?f=62&t=94201) - программы без схемы и конкретной задачи НЕ БЫВАЕТ.
Поскольку один и тот же алгоритм может иметь множество прикладных реализаций - зависит от того, что в данном конкретном случае удобнее. Даже в рамках одного семейства (не говоря уже о различных).
Вот потому и "затык" - без конкретики обсуждать наиболее удобное решение бессмысленно.
Ибо ВСЕ ПРАВЫ будут.

[FIREBALL_1984]

yor писал(а):

Ну с высоты профессионализма Вы можете, конечно, смотреть свысока Как это не экономит, )

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

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

[yor]

Здравия!
Правильно ли я понимаю, что 16-и разрядный таймер TMR1 (pic16f627/628/648) можно использовать как 8-и разрядный, эксплуатируя только младший байт, а старший заполнив единицами? Вроде больше тонкостей нет?

[Alexey1969]

Вроде больше тонкостей нет?

Вроде нет.

[yor]

А правильно ли я понимаю, что запретив прерывания глобально, но разрешив по таймерам, по окончании счёта PC не уйдёт по вектору прерывания 0x04, а выставятся флаги прерывания TMRxxIF (как-то так), и можно их проверкой установить факт переполнения? Чтобу не читать сами таймеры. pic16f628-648

[КРАМ]

Флаги взводятся независимо от разрешения прерываний.
Разрешения прерываний расположены в контроллере прерываний, а флаги генерирует периферия.
Поэтому прежде,чем разрешить прерывания, нужно сбросить флаги.
Иначе вы получите генерацию прерываний по всем ранее взведенным флагам.

[Alexey1969]

А также сбрасывать флаги при обработке прерываний.

[valentinovich]

можно их проверкой установить факт переполнения? Чтобу не читать сами таймеры. pic16f628-648

Данный вопрос (как собственно его же и предыдущий) говорят лишь о том, что человек, увы, совсем не разобрался как работать с таймерами и как правильно их использовать.
Правда это так же относиться и к общему пониманию составления алгоритма программы, исходя из возможностей выбранного МК.

[asvhmao]

По поводу алгоритма. А как правильно всё расставлять если процессы по времени часто пересекают друг друга? Например задержка от дребезга контактов (кнопок, энкодера) и обработка формирования меандра (с регулируемой частотой).
С пиками знакомлюсь несколько дней (16f628 и т.п.), но похожих примеров на ассемблере пока не попадалось.

[uldemir]

Правильное планирование - наше всё. Разделить процессы по степени критичности по времени и соответственно реализовывать. Особо критичные по времени процессы делать или аппаратно, или по прерыванию от аппаратуры. Кнопки/энкодеры и дребезг - это не те процессы, которыми надо заморачиваться. Обычно их можно сделать как машину состояний, которую можно вызывать где угодно и сколько раз угодно и совсем не обязательно со строгой периодичностью. А вот чтобы это привязать ко времени, достаточно чтобы в системе был один таймер, который просто отбивал такт. Например в прерывании от TMR0 можете просто инкрементировать переменную systime или/и декрементировать переменную kbd_delay, если она имеет не нулевое значение. И их значения проверять в подпрограмме, которая и сообщит нажата ли кнопка или сделал ли шаг энкодер.

Вообще, представляя ваши затеи, скажу что уж больно тоскливый вы кристалл выбрали. Ну чтобы поучиться писать на ассемблере еще ничего, но когда надо будет перейти на C - вас ждёт разочарование из-за жлобства микромела - потому как нормального бесплатного инструмента для создания программ у них нет.

примеров на ассемблере не будет - я уже давно на нём не пишу, а старые сырцы где-то канули в лету.

[КРАМ]

asvhmao писал(а):

По поводу алгоритма.

Перечисленные вами функции сами по себе мешать друг другу не будут.
Обработка энкодера и кнопок вообще не является функцией реального времени. Никаких задержек там не требуется. Защита от дребезга достигается простым чтением портов с интервалом превышающим время дребезга. Для кнопок это примерно 20мс, для энкодера - примерно 3...5мс.
Управление частотой меандра зависит от скорости управления. То есть как часто и с какой задержкой допустимо изменять параметры ШИМ.

Добавлено after 8 minutes 18 seconds:

uldemir писал(а):

нормального бесплатного инструмента для создания программ у них нет.

Комбинируя код на С и ассемблере можно очень эффективно программировать 8-битные ПИКи в бесплатной версии компилятора. Это очень простая платформа, поэтому ничего сверхестественного от компилятора не требуется. Скажем, задачи озвученные автором можно сделать на ХС8 с нулевой оптимизацией. И без всякого ассемблера. Можно и на голом ассемблере...

[yor]

valentinovich писал(а):

Данный вопрос говорят о том, что человек совсем не разобрался как работать с таймерами и как правильно их использовать.

Истинно так! Но я ж не трясу дипломом, тема для начинающих. Учусь, люди помогают, а сообщение Ваше хоть и правильное, но бесполезное.

uldemir писал(а):

Разделить процессы по степени критичности по времени и соответственно реализовывать. Особо критичные по времени процессы делать или аппаратно, или по прерыванию от аппаратуры.

А если критичность одинакова? От одного зависит другой, и могут пересекаться? Вот например, от периода зависит время задержки. Аппаратно недоступно, не хватит входов прерываний, да и уже спаяно, использую старую базу. Использовать не экстенсивный подход (другой мощный богатый контроллер), а интенсивный? Пища для ума, предвосхищая справедливые обвинения))

КРАМ писал(а):

Защита от дребезга достигается простым чтением портов с интервалом превышающим время дребезга. Для кнопок это примерно 20мс, для энкодера - примерно 3...5мс.

А оптопара с модулятором-шторкой, надеюсь, не имеет дребезга?

[КРАМ]

Зависит от помех. В такой конфигурации скорость нарастания фронта мала и потому помехи могут создавать дребезг.

[BOB51]

МК штука вредная.
Для того, чтобы чего-то обсуждать на уровне ассемблерных программ надо не "теорию с потолка" иметь в обсуждении, а конкретную схему устройства и описание того, что данное устройство должно выполнять.
Ибо возможных решений огромное множество.
Посему - делаем схемку, закладываем МК и алгоритм желаемой работы устройства - выкладываем для обсуждения.
Далее на уже проработанный материал начинаем программу прилаживать (и, вполне возможно, схемку править) с учетом использования особенностей системы команд МК и его аппаратной начинки.
Так что...

Антидребезг можно и "внешний" - к примеру на R-S триггерах, собранных на 555ЛА3 да "перекидных" кнопках
https://img.radiokot.ru/files/20529/1ci6nvk6db.JPG
Да много еще чего (смотри к примеру https://sunduk.radiokot.ru/view/?id=1487946626 )... Зачем весь функционал на МК вешать при возможности внешней аппаратной предобработки данных?

[КРАМ]

BOB51 писал(а):

Зачем весь функционал на МК вешать при возможности внешней аппаратной предобработки данных?

Хотя бы из эстетических соображений. Зачем иметь лишнюю комплектацию на схеме?

[valentinovich]

Учусь, люди помогают, а сообщение Ваше хоть и правильное, но бесполезное

Для того, чтоб понять про что было моё замечание, см. очень верное:

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

Причём алгоритм желателен не описанием типа словесного ля-ля и даже не в каком либо языке, а сначала, к примеру, в виде графа. И когда решение вашей задачи будет соответствовать нужной логике процесса в данном виде, вот тогда уже можно будет давать какие-то рекомендации. Хотя замечу, что в данном случае (при достаточной самостоятельной подготовке вопрошающего ) частенько уже помощи почти и не требуется. Ну если только чуть-чуть.

[КРАМ]

valentinovich писал(а):

в виде графа. И когда решение вашей задачи будет

Это имеет смысл для машины состояний. Я пока ни в каком месте не увидел для нее шансов.