Подсветка днища автомобиля ночью.

Gregory: Ничего подобного.

Имелась в виду разница между TMR0 и TMR1.
Первый реализован как предделитель и однобайтный таймер, второй - как 2-х байтный таймер.
Если в предделителе можно выбрать только определённые комбинации из ряда 1:2, 1:4,...,1:256, то в байты TMR1 - можно записать любое число от 0 до 255.

В результате, не смотря на одинаковую разрядность (оба таймера 8-и разрядные), TMR1 позволит выбрать коэффициент счёта более точно.

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

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

У Zandy опрос кнопок происходил после прерывания. Мне показалось это не очень удобным, и я сделал по другому. У меня два процесса (отработка паузы и опрос кнопок) происходят одновременно и параллельно.

DWD: У Zandy опрос кнопок происходил после прерывания. Мне показалось это не очень удобным, и я сделал по другому.

DWD, опрос кнопок происходил не после прерывания, а в процессе прерываний. Это был единственный интересный момент во всей программе, повышающий надежность защиты от дребезга Может вы не совсем поняли алгоритм?
Суть такая. Опрос кнопок проводился через равные промежутки времени, обеспечиваемые прерываниями по таймеру. На каждую кнопку был "заведен" отдельный счетчик. В каждом прерывании сравнивалось текущее состояние кнопок с состоянием в предыдущем прерывании. Если состояние кнопок неизменно, то кнопочные счетчики декрементируются. Если состояние кнопки изменилось, соответствующий счетчик сбрасывается (предустанавливается) и начинается счет по новой. Принятие решения о том, является ли кнопка нажатой или отпущенной, делается в том случае, когда кнопочный счетчик досчитывает до конца (до того числа, которое было задано), т. е., если в течение определенного количества тактов счета состояние кнопки не меняется. После этого счетчик также сбрасывался. В той программе, вроде как (уже не помню) было принято: период опроса кнопок (период прерываний) около 16 мс, счетчик считал до 5. Причем эти цифры не были привязаны ни к чему другому, и в шапке программы можно было их легко изменить. Таким образом производилась очень эффективная фильтрация дребезга и случайных импульсных помех и наводок, как при переходе из 1 в 0, так и из 0 в 1.

Выбирая низкую тактовую частоту 32 кГц вы все-таки немножко себя "загоняете в угол" в смысле многообразия различных вариантов алгоритмов построения программы. Надо четко отслеживать времена выполнения каждой команды. При высокой тактовой (4 МГц) и низкой выходной частотах можно пренебречь временем выполнения десятка - другого команд (+/- 10 мкс).

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

Но самое главное, что вы не стали повторять программу, а решили делать ее сами, своими силами. Это очень отрадно! Именно в этом и суть неоспоримой пользы, такой казалось бы, совсем никчемной игрушки.

DWD:
Использовать же для отсчёта паузы регистры МК
Тоже имелось ввиду немного другое. Таймер также выдаёт прерывания, а в ПП прерывания инкрементируется специально отведённый регистр.

Zandy: DWD, опрос кнопок происходил не после прерывания, а в процессе прерываний.

Это понятно. Я имел в виду после появления прерывания, как события.

Zandy: Может вы не совсем поняли алгоритм?

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

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

Но мне ещё рано "крутить финты" при программировании МК. Тут бы основы освоить, так сказать - классику.
Помню, как разбирался с прогой опроса матричной клавиатуры 3х4 кнопок (первый раз в жизни), и то быстрее разобрался, чем с Вашим алгоритмом опроса 2-х кнопок. А разбирался, ведь, из HEX-кода, а не из ассемблерной распечатки с комментариями...

Вторая причина - желание получить нижнее значение частоты 1Гц.
С Вашим алгоритмом это было бы неудобно - нажимаешь кнопку и держишь, пока секунда не закончится... Ведь прерывание будет возникать каждую секунду и только по прерыванию начнётся отработка нажатия кнопки. Согласитесь, это не очень удобно...
А может, я не правильно понял...
Собственно, к Вашему коду я уже почти не обращаюсь, голова занята своим...
Однако, он мне хорошо помог! Спасибо!

Zandy: Выбирая низкую тактовую частоту 32 кГц вы все-таки немножко себя "загоняете в угол"... Надо четко отслеживать времена выполнения каждой команды.

Согласен. Поправку придётся делать.
Однако, пока она не большая. А разница между 16Гц и 15,8Гц не такая уже и заметная...
Дальше будет видно.
Тут я преград не видел. И сейчас не вижу. А говоря "загнал себя в угол", я имел в виду способы изменения состояния портов, для зажигания одних светодиодов и выключения других. Мне не понятно было, как менять это состояние при каждом срабатывании таймера.
Теперь понятно. По крайней мере, однин эффект в виде бегущего огня уже реализован. Думаю, принцип отработан.

Добавление нового эффекта, практически, означает добавление новой таблицы комбинаций состояния портов.
Причём, самая большая таблица (11+11=22байта) уже реализована.
Для эффектов, в которых есть не один а сразу несколько одновременно горящих светодиодов, таблица будет меньше.
Например, для эффекта разбегающихся от центра в разные стороны огней, потребуется в 2 раза меньше байтов.
А следующие эффекты, как раз, и заключаются в увеличении комбинаций одновременно горящих светодиодов.

Прога, практически, написана. Остались эффекты. А с учётом большой оставшейся памяти (использовано пока 334 из 1714), можно организовать таблицы с довольно сложным алгоритмом переключения, не доступным при "математическом" способе вычисления. Например, все эффекты по кругу...
По крайней мере, я сомневаюсь, что бы можно было использовать функции в программе...
Можно, конечно, но места они займут явно много, если не больше, и будут сложнее при реализации их в виде кода.

Так что, как мне кажется, табличный способ в данном случае будет, наоборот, проще.

Zandy: Но самое главное, что вы не стали повторять программу, а решили делать ее сами, своими силами... Именно в этом и суть неоспоримой пользы...

Согласен. В своих глазах я "вырос".
Даже появилось желание самому написать прогу для МК, используемого в "интелектуальном" ИБП... Как то я говорил об этом в теме по блокам питания... Но тогда я "просил", что бы её кто-то написал...

DWD: Вторая причина - желание получить нижнее значение частоты 1Гц.
С Вашим алгоритмом это было бы неудобно - нажимаешь кнопку и держишь, пока секунда не закончится... Ведь прерывание будет возникать каждую секунду и только по прерыванию начнётся отработка нажатия кнопки. Согласитесь, это не очень удобно...
А может, я не правильно понял...
Конечно неправильно поняли. Период прерываний всегда постоянен и не зависит от того, какая частота на выходе.

DWD: Но мне ещё рано "крутить финты" при программировании МК. Тут бы основы освоить, так сказать - классику.
Какие финты? Все это мы "проходили" в ветке форума ликбез по пикам. Вы видать туда не заглядывали? И эту тему надо было туда же пристегнуть.
Кстати сейчас там организовывается ликбез по С для пиков. Не упустите момент.

Zandy: Конечно неправильно поняли.

Точно, у Вас же пауза организована отдельным счётчиком на регистрах!.. Забыл.

Zandy: Какие финты? Все это мы "проходили" в ветке форума ликбез по пикам.

Да, я ликбез не прошёл даже на двойку...
Интересно то, что когда начал его читать, уже имея в голове "свой" проект, то вижу, что чтение уводит меня в сторону... бросил.
Я сначала сделаю своё, а потом снова начну читать ликбез - тогда будет понятно, хоть, какой дорогой я пошёл и на сколько эта дорога хуже...
А на счёт "С" - нет, спасибо. Я и так сильно стал похож на "вечного студента".

Zandy: При высокой тактовой (4 МГц) и низкой выходной частотах можно пренебречь временем выполнения десятка - другого команд (+/- 10 мкс).

Только что специально сравнил, на сколько отличается реальная частота от выставленной при отработке разных эффектов.
Условия одинаковые - кнопки не трогаются, эффект и частота уже установлены и идёт циклическая отработка проги по прерыванию таймера.
Таблица в виде:
№ Эффекта_Пауза при 1Гц_Пауза при 16Гц
----------------------------------------------------------
1_999,88мс (1,00012Гц)_62,75мс (15,9Гц)
2_999,62мс (1,00038Гц)_62,5мс (16Гц)
3_1с_62,88мс (15,9Гц)
4_1с_62,88мс (15,9Гц)
5_1с_62,12мс (16,1Гц)
-----------------------------------------------------------

Видно, что отличие есть только на самой высокой частоте, но такой разницей можно пренебречь.
А ведь, эффекты отличаются сильно!
1-й - это все светодиоды включены, использовано 7 команд.
2-й - все светодиоды выключены, 5 команд.
3-й - "Бегущий огонь" (в одну сторону), 20 команд.
4-й - "Бегущий огонь" (в другую сторону), 22 команды.
5-й - "Бегущий огонь" (туда-сюда), 23 команды.

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

Пока руки "не дошли" исправить. Частоту эффекта можно отабатывать один раз при первом вызове данного эффекта, а у меня оно обновляется при каждом прерывании.
Исправлю, погрешность уменьшится. Ведь, это десяток команд. При длительности команды 0,125мс, выиграю 1 мс.

Сейчас мне приходится корректировать коэффициенты для таймера, прибавляя к его значению число 25. Выиграв десяток команд, можно будет и прибавку уменьшить до 15. Так и подберу...

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

Уже начал задумываться над способом реализации драйверов светодиодов.

Всего светодиодв - 22 штуки, включенных по 2 параллельно.
То есть, линейка из 11 светодиодов.
По 20мА на один - получится 40мА на один выход. МК такой ток не потянет, значит, нужен драйвер.

Большинство подходящих мс драйверов (в одном корпусе 16 выходов) расчитаны на подключение светодиодов к плюсу питания. А мне нужно, что бы все светодиоды сидели одним концом на корпусе - минусе.

Желательно, драйвер с параллельной загрузкой, что бы код не переписывать, а то читаю - все выполнены как регистры с последовательной загрузкой. С параллельной есть?

Кто подскажет, есть ли такие микросхемы, или самому лепить из дискретных элементов?

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

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

Кто ещё что подскажет или посоветует?

DWD: Сколько думаю - всё сильнее склоняюсь к простейшему варианту, в котором каждый светодиод подключен к отдельному источнику тока на 2-х транзисторах или транзисторе и диодах. Плюс, ещё два резистора - один подключается к выходу МК, а другой является токозадающим. В общем, классическая схема источника тока.

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

Если транзисторы p-n-p и управление от МК, значит, питание "драйверов" должно быть такое же, как и у МК - 5В.
0,5В - насыщение, 3,3В на светодиоде. Остаётся 5-0,5-3,3=1,2В.
Отсюда находим ограничительный резистор - 1,2В/40мА=30Ом.
Светодиоды хорошо работают, будучи соединёнными параллельно. А вешать по резистору на каждый светодиод, значит, тянуть в 2 раза больше жил кабеля - 22 вместо 11.

Теперь, предствим, что где-то коротнуло - светодиод "пробился" или замкнули его...
На ограничительном резисторе 30Ом упадёт напряжение 5-0,5=4,5В, и потечёт ток 4,5/30=150мА. Не очень много, и транзистор можно взять, что бы выдерживал такой ток. Но при этом на резисторе будет рассеиваться мощность 4,5В*0,15А=0,675Вт.
Его что, на радиатор ставить или ставить одноватные?..

Если же добавить к уже установленному транзистору и резисторам ещё один транзистор или два диода (или один стабилитрон), то получим источник тока, выдающий 40мА не зависимо от того есть замыкание в цепи светодиодов или нет.
В результате, при КЗ на транзисторе будет рассеиваться мощность 5В*40мА=200мВт. Эту мощность уже и КТ361 выдержит...

Но я хотел поставить транзисторы n-p-n, и питать этот "драйвер" от импульсного стабилизатора напряжением 4В. Уже при таком значении стабилизатор тока работает нормально.
Остальное всё точно так же, как и с p-n-p транзистором, но из-за меньшего напряжения, будут меньше потери и при КЗ меньше перегрузка.

Просто, для уменьшения размеров устройства хотелось бы использовать "монолитный" драйвер, если такой найдётся...
Если нет, то пожалуй, сделаю на транзисторных сборках.
Кстати, есть хотя бы сборки на большое число транзисторов и в малом корпусе?
Я знаю (и есть) только на 4 транзистора в одном корпусе.

В соседнем разделе прям по теме ссылка.