Форум РадиоКот

{Да не. Ну правда? Всегда?}
ВСЕГДА. Если это не так, это не программа.
За 13 лет не найти как сделать задержку…
Снимаю перед Вами шляпу.

DrLithium, я больше склоняюсь к позициям dgrettа,
~ 27кБ прошивка для простого контроля состояний- это много (обычно объёмные прошивки получаются при добавлении шрифтов или другой графики для ЛСД дисплеев). (у меня трмостат влез в тини2313, там и опрос дс18б20, и дин. индикация и настройка кнопками уставок включения-выключения, коррекции показаний датчика , яркости дисплея, сохранение настроек в ЕЕПРОМ, переключение типа исп. мех-ма холод/нагрев... при том, что писал на С, а памяти у этого МК совсем не много...)
~ механика - штука медленная и вешать МК программными задержками пока она отрабатывает не очень логично - для долгих задержек правильней применять аппаратный таймер (при правильном применении он не "израсходуется"), можно даже сделать подобие многозадачности, тогда, пока механика перенастраивается, МК останется способным к выполнению других задач (например опрос кнопок, дин. индикация).
~ на С программы не всегда получаются больше, чем на ассемблере - автоматические оптимизаторы сейчас тоже весьма неплохи.
~ не надо думать, что твое мнение единственно правильное - можешь упустить много интересного... (сам этим одно время страдал...)
~ по провалу ВЧ - для выяснения причины надо более тесно обследовать механику, возможно пленка не ровно ложится или её рывок происходит и задний ролик обгоняет и 3-5 секунд пленка по голове без натяжения идёт... возможно вариант решения - останавливать перемотку до перехода на воспроизведение...

DrLithium писал(а):А что такое прерывания знаете?

прерывание потому и называется прерыванием, что оно прерывает бесконечный цикл.

DrLithium писал(а):Я о бесконечном цикле в МК, узнал ещё в 2008-м году, когда только начал изучать.

узнать мало, нужно еще суметь понять, что это такое.
а 27 кБ на примитивную программу на ассемблере - кроме тебя, я думаю, никто не способен на такой дурдом.

Ivanoff-iv писал(а):на С программы не всегда получаются больше, чем на ассемблере - автоматические оптимизаторы сейчас тоже весьма неплохи.

ВСЕГДА больше и значительно больше. ни один автомат не может сравниться с человеком.

DrLithium, опять прошу прощения, но
{А если мне ИК-дистанцию подрубить надо будет, то тут будет заюзан таймер. На автостоп другой. Таймер на автоотключение по бездействию - третий. И т.п. ,т.ч. Delay актуален, для остальных работ}
это всё можно повесить на один единственный таймер. Тем более задержки могут выполняться параллельно, в ЛЮБОЙ момент можно инициировать сколько угодно задержек и они будут отрабатываться асинхронно. У Вас же работать может только одна. В прерывании никаких обработок нет, только выставление флага «задержка окончена».
На таймер 5 команд, не распухнет Ваша прошивка.
И ещё. Неужели впрямь думаете, что японец свою программу писал на тупых задержках?
Поймите, 100, 200 мС для мк - это вечность
PS Если всё таки хочется тупых задержек, akl показал правильную задержку.

[uquote="Starichok51",url="/forum/viewtopic.php?p=4048637#p4048637"]27 кБ на примитивную программу на ассемблере - кроме тебя, я думаю, никто не способен на такой дурдом.
___________
ВСЕГДА больше и значительно больше. ни один автомат не может сравниться с человеком.[/uquote] пожалуй
Наверно это от мастерства программиста зависит...
у меня иногда С прошивка получалась легче, но я себя гурой ассемблера и не считаю...

Ivanoff-iv писал(а):Наверно это от мастерства программиста зависит

от мастерства и только от мастерства.

За 13 лет не найти как сделать задержку…
Снимаю перед Вами шляпу.

Детектив, а вы сие из чего вывели? Улики где?

Вот вам факты: спустя пару лет после начала изучения, мне попался на глаза генератор AVRdelayloop.exe (дата создания папки 01.07.10).

Т.ч. уважаемый. прислушайтесь к просьбе, по поводу моей персоны: фантазии на офф!

А теперь вопрос в студию: вам надо получить задержки 10 30 40 100 120 140 150 220 270 320 330 340 360 750 960 и что, будете каждый раз генерировать код индивидуальной задержки? Это только для работы ЛПМ вам 14-ь разных понадобиться, а не деле больше! До последнего времени я так и пользовался, сгенерённые Delay + таймеры. Но вот вам красноречивый пример когда старый и привычный подход не удобен в корне! Будете возражать? На здоровье! Я себе времени сбёрег и кучу программного кода! А вы упирайтесь до последнего, главное же это противостояние здравому смыслу?

~ 27кБ прошивка для простого контроля состояний- это много

Да сколько раз вам говорить? Не 27-ь, а 11! 16КБ это код макроса многократно вызванного нуба запостившего свое "творение" на Хабр! Читайте внимательно.

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

Как раз не логично вешать таймер. Он вообще в данном случае ни каких преимуществ не даёт. Вот вам пример, что б вы осознали:
Идёт задержка аппарата при включении 7 секунд для устаканивания всех процессов и тут же проверяется наличие сигнала "Power_Off". Т.е. пока не обнаружено исправное питание, дальше цикла тестирования питания с задержкой, аппарата не пойдёт. Какое тут ещё нужно прерывание? Зачем оно тут? SEI ещё не объявлено для реакции на датчики состояния и кнопки! Это понятно?

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

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

~ не надо думать, что твое мнение единственно правильное - можешь упустить много интересного... (сам этим одно время страдал...)

Где я такое писал? Ссылку в студию! Очередной фантазёр? От реальности не отрываемся и кроем голыми фактами. И убедительных я что-то у вас не вижу. А интересного у меня и так избыток, да и ваши "аргументы" я разбиваю с большим интересом! Лишите меня этой возможности, это будет лучший для меня интерес.

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

Не надо ни чего обследовать. Тут давно всё ясно, просто это демонстрация того, что программисту без практики (не в теме) тут вообще не место, т.к. ТЗ в чистом виде ему ни кто на блюдечке не преподнесёт. Из перемотки в плей и так происходит промежуточный стоп! Но в случае перехода из перемотки назад и в плей, пропадания ВЧ не происходит, а после перемотки вперёд происходит. От вас, программистов скрыт факт: в аппарате закрытый тракт. В курсе что это такое? Последствия представляете для кода решающего задачу? Понимание подобных тонкостей отсекает возможность использования программиста со стороны. Это ясно?

узнать мало, нужно еще суметь понять, что это такое.
а 27 кБ на примитивную программу на ассемблере - кроме тебя, я думаю, никто не способен на такой дурдом.

Цирк заканчивайте. У меня нет 27-и, у меня 11КБ. Мозг есть, что б осознать масштаб? А в СИ при использовании чужого кода такого не происходит? Дак почему в ассемблере это прям бЯда? Когда я заметил, что код распух, тут же решил проблему. Боюсь вы бы вообще не заметили, что у вас это произошло. Да и написать о подобном побоитесь - засмеют. А я не боюсь и в этом разница, потому вы беситесь и хамите.

ВСЕГДА больше и значительно больше. ни один автомат не может сравниться с человеком.

Здравая мысль! Тут я полностью солидарен!

А теперь вопрос в студию: вам надо получить задержки 10 30 40 100 120 140 150 220 270 320 330 340 360 750 960...."
это чего микросекунд? миллисекунд? секунд? а может ещё каких попугаев?
если не микросекунд, то сложности вообще не вижу... даже если их все одновременно запустить придётся...
и... я надеюсь вы из них не "пирамиду" строите...(когда большая задержка собирается из суммы маленьких, а потом ещё довесок...)
—————
"в аппарате закрытый тракт."
что-ж, значит я не угадал... (закрытый... это про наличие/отсутствие развязывающих по постоянке конденсаторов?)
у меня лежит без дела дека техникс... чего с ней делать не знаю, кассет хороших нет, да и сам я не аудиофил хоть и слухом не обделён... (от моей штатной гамнитолы, например, тошнит, так хреново она играет).
—————
"У меня нет 27-и, у меня 11КБ."
проведена большая работа по оптимизации, но для простой переключалки (ни разу не интерактивной) это всё-равно много...

это чего микросекунд? миллисекунд? секунд? а может ещё каких попугаев?

Если посмотрите выше по ветке, то увидите диаграмму в скрине, где значения явно в миллисекундах.

то сложности вообще не вижу... даже если их все одновременно запустить придётся...

Здесь не стоит задача просто справиться с задачей. Нужно внедрить задел для дополнительных функций на ближайшее или далёкое будущее. Кроме того, ни кто не утверждает, что это нельзя сделать на таймерах. Здесь вопрос подхода: есть ли смысл усложнять себе задачу и мучиться с таймерами, когда можно использовать макрос с простым вызовом: DELAY_MS 65535 и тем более когда вам не нужно прерываться. Да и разгрузить голову, для решения ёмкой задачи весьма как полезно! Не сложной, т.к. всё решаемо, но большой по объёму, а отсюда и кода до фига!

закрытый... это про наличие/отсутствие развязывающих по постоянке конденсаторов?

Нет. Это когда лента в зоне контакта с головками, с обоих сторон контачит с тонвалами. Коих два, для обеспечения нужного прилегания ленты к головкам. Подушка кассеты отводится "падлифтером" полностью, и она не давит на ленту и головку совсем. Лента в подобных трактах, если её чуть вытянуть, выбирается за несколько секунд. Это обеспечивается разностью вращения тонвалов. Поэтому минимальное захлёстывание ленты перед остановкой, рождает проблему. Решается это смешение по времени момента остановки самой перемотки по отношению к повороту программной шестерни и как следствие тормозов. Но если тормоза срабатывают не одновременно, то можно ввести уже в начале плея подмотку чуть раньше. Просто надо знать что крутить, т.е. не сложно.

"У меня нет 27-и, у меня 11КБ."
проведена большая работа по оптимизации, но для простой переключалки (ни разу не интерактивной) это всё-равно много...

Мне бы проект скинуть для разбора по косточкам, но боюсь конкуренты упрут и будут продавать вместо меня. Просто поверьте, много определений, много пересечений режимов и состояний, много чем нужно точно, до 10мСек, управлять. Ужать можно в 2-3-и раза, но эта задача не стоит. Уверен, что в Японии над запихиванием подобного функционала в маленький LM6402A, целый отдел работал. При этом надо было отточить код до безукоризненного состояния. В данном случае важнее:
подробное описание всех жестов обречённых в функции, кои вызываются часто;
возможность добавления модулей для управления по - USART, ИК, I²C;
скорость исполнения, в данном случае, ни как не важна;
точность задержек так же.

Тут у меня и так до фига чего работает, те же PCINT для 4-х портов обслуживают 13-ь пинов, естественно на оба перепада. Флаги, которые можно менять прерываниями PCINT или в зависимости от данных, полученных по протоколам Т.ч. вес проекта не от плохого написания, а от объёма самой задачи, вес который вы уверен да же близко не понимаете. Это не часики знаете ли, это серьёзный аппарата не малой цены, до 200т.р.! Каждая новая функция д.б. расписана во всех места с которыми пересекается, т.ч. местами прогрессия геометрическая, а не арифметическая.

Т.ч. "но для простой переключалки (ни разу не интерактивной)" и близко не стояло!

Так! Короче хватит разглагольствовать. Раз уж все подтянулись, вот вам ТЗ для реализации DELAY_MS:
1. Отполировать идею и код, аргумент в миллисекундах 1-65535 или около того (решено - макросом)
2. малый вес
3. минимальное кол-во используемой программной памяти за вызов
4. PUSH-POP, что б не париться нубам (решено)
5. точность по времени
6. простой вызов в одну строку (решено)
7. зависимость от частоты (решено - XTAL)
8. учёт времени входа-выхода.

Надеюсь армия нубов, во главе со мной , вам спецы, скажут спасибо!

Думаю, что как-то так:
цикл1 на 1 мСек при условии, если аргумент >1 мСек (XTAL/1000 - кол-во тактов на вызов);
настраиваемый цикл2 на <1 мСек, т.е. с компенсацией вход-выход (XTAL/1000 - кол-во тактов на вход-выход самого макроса) для последней миллисекунды;
основной цикл, запускает цикл1 N-1 кол-во раз и в конце цикл2;

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

и ещё вопрос, вот есть задержки 10, 20... 120 мс, а начинает их событие внутри мк или какое-то внешнее?
просто они все кратны 10, напрашивается подобие диспетчера задач с шагом 10мс если задача поставила паузу 10 мс, она вызовется при следующем запуске цикла диспетчера, если пауза 50 мс, то пропустив 4 цикла...

Добавлено after 1 minute 54 seconds:
если знаешь АлгоритмБилдер - могу пару примеров скинуть (один мой один с гетчипа) сам я уже от ассемблера отвык... только читаю, а писать лень...

{8. учёт времени входа-выхода}
В макрос? Так его нет. Вот если бы Вы использовали процедуру Delay и вызывали её, тогда добавляются такты на вызов и возврат. Кстати она одна (процедура, её Вам akl дал ) а не тыща макросов, как у Вас. Уверен, знаете отличия. А вызывается также одной строкой.
Да ладно, у Вас уже много кода написано, не осмелюсь предложить начать с нуля, так как по моему подход неверный. Мне раза два пришлось проект, сделанный и работающий разрабатывать снова, с нуля, так как в принципе неправильно реализовал алгоритм. И получалось проще, нагляднее и легко расширяемый функционал. И кода - меньше! Просто не в лоб решать, а посидеть, подумать. Как ни крути, но это автомат. И точно не из самых сложных.

и ещё вопрос, вот есть задержки 10, 20... 120 мс, а начинает их событие внутри мк или какое-то внешнее?

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

просто они все кратны 10, напрашивается подобие диспетчера задач с шагом 10мс

Можно, но опять же удобнее просто подождать, скомандовав одной командой с аргументом кратным 1-у, т.к. можем себе позволить.
Если всегда нужно кратно 10-и, то это можно задать в функции сразу. Но зачем если диапазона 1-65535 хватит с головой и для 1-миллисекундного варианта?

Кстати она одна (процедура, её Вам akl дал ) а не тыща макросов, как у Вас.

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

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

Не верный? Что м.б. не верного в отлично работающем, стабильном и хорошо сдобренным комментариями коде? Тут верна именно идеология подхода к решению подобных задач! Всё наглядно, легко правится и настраивается.
В вашем сухом коде очень тяжело разбираться. Вряд ли вспомните через год, что имели ввиду. Я от подобной практики давно отошёл. Всегда пишу комменты так, что б и через много лет было понятно, что тут происходит и как решается. Не говорю, что у вас плохой код, но для меня это прошлое. Я оперирую процедурами, а не сухим кодом ассемблера. При этом чётко представляю как у меня построена архитектура программы и легко в ней ориентируюсь.

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

Сочувствую. Иногда сам пока пишу, то делаю промежуточные версии (10-15-20), но что б в корне менять целиком... Было, что надо что-то менять, но только блоки, т.к. во что-то упирался. Как-то пришёл к тому, что плейер(озвучка для часов) на attiny861 с СИ-шным кодом для работы с флешкой, управляемой с какой-то меги по I²C, пришлось после проигрывания тупо перезагружать по WDR. Оказалось проще и надёжнее, чем разбираться с кривостью чужой библиотеки. По этому больше люблю ассемблер! Пятый год где-то работает без нареканий...

Просто не в лоб решать, а посидеть, подумать. Как ни крути, но это автомат. И точно не из самых сложных.

А о сложности и проблемах ни кто не говорил и тут всё далеко не в лоб, и подумано при этом многократно. Тут тупо просто много. Охватить сразу и всё - нет смысла. Сделал минимум, проверил, поправил, довёл, делай новую версию с добавление остальных функций. Что б просто запустить аппарат, пришлось писать весь жир, а нашвырять функционал не составит труда.
Пример: есть кусок схемы с сигналом Power_Off. Нужно написать кусок, проверяющий питание, но что д.б. на этом сигнале при неисправном питании ни где не сказано. И тут ни чего не правильного быть не может, как ни крути и думать тут нечего. т.к. всё элементарно. Такая работа. Просто вам надо принять, что каждый пишет в своём стиле и после собственного плачевного опыта. Единственный тест, на верно - не верно, это работает и так как надо или же нет.

ну, наверно не критично, если реакция на открытие кассетоприемника будет с задержкой 0-10 мс... а кнопка - это вообще не событие... её ещё от дребезга очистить надо, тогда она станет источником управляющего сигнала - задержка до начала реакции на него может быть вообще космической по меркам мк... до 0,1-0,3 с.
А "многозадачность" это удобно - один поток обеспечивает индикацию, второй - кнопки опрашивает, третий - моторами рулит... и.т.д. и задержки в разных потоках могут разом идти и при этом друг-другу не мешать...
и код этих потоков тоже друг с другом не пересекается - части кода взаимодействуют через флаги, которые легко отслеживать при отладке.

27 кБ...
у меня в них влез полноценный сат-прибор, написанный на чистом Си
с граф.дисплеем (ks0107 или st7920 на выбор), панорамой, узалсом, компасом, акселерометром, криптованием
программная USB, шоб на мост не тратиться
и еще место осталось для баловства

Я вот не понял, ИК, i2c тоже будут на делаях?
Мой прибор уже 5 лет работает в станке, а я его всё-таки переделал с нуля. Алгоритм тот же, реализацию поменял в корне. Сочувствий не люблю.

27 кБ... 27 кБ... 27 кБ...
Для тех кто в танке: 27 кБ - это кол-во вызовов умноженное на запросы кривого и чужого макроса + сама программа.
Для особо внимательных напоминаю, размер текущий прошивки после лечения бага равен: 11297 байт. Существенного роста не ожидается, т.к. весь обслуживающий жир уже написан.

До сих пор смешно? Взял чужой код, проверил - работает, заметил необычно большой размер прошивки, отыскал в чём дело, исправил, всё!

...с граф.дисплеем (ks0107 или st7920 на выбор), панорамой, узалсом, компасом, акселерометром, криптованием
программная USB, шоб на мост не тратиться
и еще место осталось для баловства

Поздравляю! Но наверное не надо забывать, что основная часть протоколов реализована аппаратно? Чему там весить? Опрашивать по I²C или SPI периферию мегазатратно? Не знал! Ваше сравнение для нубов сойдёт.

Я вот не понял, ИК, i2c тоже будут на делаях?

А понимать и не надо, т.к. на чём и как, я не упоминал. Но, если есть желание сделать на делеях, милости прошу, продемонстрируйте ваше кунг-фу. Или может уже закончим дурака валять, т.к. ТЗ поставлено и до дела дошло, а все сразу в кусты? Только ля-ля и ха-ха все могут? Задача элементарная, ваши предложения по реализации и результаты в студию!

DrLithium писал(а):27 кБ - это кол-во вызовов умноженное на запросы кривого и чужого макроса + сама программа.

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

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

Странное т.з.... часть пунктов с подписью решено...

Это просто отговорки.

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

Выше ешё раз прочитайте чей костыль. А 800-й раз пишу: ВЗЯТО С ХАБРА! Читать умеем?

не взирая на то, что в замен автомобиль (ну ии может мотоцикл ) предлагают...

Что за чушь? Вас просят оформить в "инструмент" кусок крошечного и рабочего кода! Что тут сложного?

Есть тут настоящие программеры?

Хотя... кто знает, какой там сложности алгоритм...
для справки размер ПЗУ аполлона-11 составлял 64кБ... (прошивка занимала не весь объём, да ещё часть (около 7% этого объёма) была израсходована под контроль четности)...
____________
Раз переживаешь за авторские права на свой алгоритм (хотя кому он без аппарата нужен?) можешь создать синтетический тест (мигать лампочками по условиям, опрашивать кнопки, конечники) выложить сюда правила, реализованные в алгоритме и сам алгоритм, я постараюсь тоже по твоим условиям написать алгоритм (может ктото ещё захочет...) и сравним подходы, их плюсы и минусы...

Добавлено after 1 minute 25 seconds:
я тебе предлагал "инструмент - кусок крошечного рабочего кода" - диспетчер задач...