Ну дак в энтот кусок кода и подбирал/перебирал задержки.
В процессе крутил программную шестерню с отключенным мотором и выяснил, что оказывается нужна еще и пауза в работе соленоида..
В других режимах просто импульс 50=назад и 300=плей. Опять 50 - стоп.
Интересно так то.
Бывает. Крайне редко, но иногда и самому приходится ТУПО подбирать какое то значение. Например OSCCAL. Ставишь кнопку (а лучше две) и вперёд. Пока не увидишь вменяемый результат. Затем находишь среднее и доволен.
Коду? Это что имеется ввиду? Понятно что мы все догадливые, но хотелось бы пококретнее.
Не хотел писать, все же решил отписаться. Вчера на просторах интернета случайно связался с программистом. Задал ему тот же самый вопрос с 3-мя светодиодами при одной постоянно нажатой кнопки. Дал ему ссылку на обсуждение мною с вами данного вопроса и попросил его написать скетч как можно проще. Буквально через полчаса пришел ответ со скетчем. Собрал на макетной плате - заработал но через раз, причина дребезг контакта кнопки хотя подтянул входа резисторами и конденсаторами. Т.к. в моем магнитофоне используется фотодатчик , проблема дребезга исчезла. На днях воплощу его в основной скетч и я думаю должно все получиться. Я не жадный, вот эта программка, возможно кому то пригодится
bool stateButPinA2 = HIGH; // запомненное состояние кнопки (нажата / не нажата)
в основной функции loop нужно изменить код так:
if( digitalRead(ButPinA2) == HIGH )
{ stateButPinA2 = HIGH; } // кнопка не нажата - запоминаем состояние кнопки
else // если низкое и кнопка сейчас нажата
if( stateButPinA2 == HIGH) // если на прошлом цикле работы микроконтроллера кнопка не была нажата,
{ digitalWrite(Led_Pin1,HIGH); // а сейчас ее нажали, то выполняем действия
digitalWrite(Led_Pin2,LOW);
digitalWrite(Led_Pin3,LOW);
delay(1000);
digitalWrite(Led_Pin1,LOW);
stateButPinA2 = LOW; // запоминаем, что кнопка уже нажата и действие выполнено и больше сюда не попадем,
} // пока кнопка не отожмется и не выполнится stateButPinA2 = HIGH; };
// кнопка не нажата - запоминаем состояние кнопки
Никакой фантазии, всегда одно и то же: “Вы здесь все …, а вот в интернете один человек мне за полчаса помог…” 
Сильно сомневаюсь 
Черт побери, ну помог же.. Я ведь эту прграммку не с неба взял
Как сказать, профессионалам возможно и не нужно, а таким как я, начинающим, возможно и пригодится
Это стандартная ситуация.
Самое сложное для исполнителя - вытянуть из бестолкового заказчика информацию, что же ему на самом деле нужно.
Когда эта работа проделана (или почти проделана), остается уже самое элементарное.
Самое сложное - это не написать программу, а понять заказчика.
А подобный код здесь размещать действительно не следовало - это по сути не рабочая программа, а лишь демонстрация общего алгоритма непригодная для работы в реальных условиях.
Собственно, это код того уровня, которого Вы могли написать и сами.
andriano, и что тут было непонятного и и почему не рабочая программа? Если вместо постоянно нажатой кнопки, как я уже писал использовать фотодатчик (через кнопку срабатывает через раз, виной тому, видимо, дребезги) , все работает, я без проблем переключаю другие светодиоды. Я не знаю как он поведет себя в основной программе, буду работать с тем, что имею. Для меня написать такой код, несмотря на простоту, пока сложно, возможно через год, два …
Что непонятно, я написал в последнем абзаце сообщения №38.
Вот, например:
Что имеется в виду?:
Это разные вещи.
Это два независимых предложения.
Или Вы забыли слово “если”?
И такие двусмысленные все формулировки.
В программировании нет второстепенных деталей.
Это очень пессимистичная оценка.
Нет, чтобы научиться программировать, Вы назвали адекватный срок, но для этого простейшего алгоритма…
В общем, там надо было реализовать всего-навсего две простенькие мысли:
Для реализации этого не нужно учиться два года.
Рабочей принято называть программу, которая работает всегда. А если программа иногда работает, а иногда - нет, либо не всегда работает, как ожидалось, либо только демонстрирует некоторые признаки работоспособности, такую программу рабочей не называют.
Хотя такой программы и бывает достаточно, чтобы, например, снять видео. Чем и пользуются некоторые блогеры. А потом пользователи удивляются, почему им не удается заставить работать опубликованную программу как надо.
Вот и я говорю, что заказчики это просто ДЕБИЛЫ, которые не могут сформулировать свою задачу. Лишний раз в этом убеждаюсь.
Особенно впечатляет их уверенность в том что ты должен всё тоже самое иметь в голове что у них и по нескольким деталям восстановить всё. А попытку узнать детели воспринимают как личное оскорбление.
Ну да. А как же! Ну что тут может быть непонятного!)
А бывает, по своему пониманию начинаешь делать - СТОЛЬКО обид, ну типа я же чётко всё сказал). ППЦ!
У нас, технарей, почему-то есть убеждение, что заказчик должен на нашем языке уметь формулировать свои требования.
Нет.
Мы так хотим, чтобы нам было легче. Но в большинстве случаев это не так.
Не надо выдумывать. Никакого убеждения. Формулируй своими словами, лишь бы логика была.
Не согласен! Пусть формулирует на любом понятийном языке. Вот только сформулированы должны быть все состояния!
А как быть если светодиод горит а кнопка снова нажимается? А если не отпустили кнопку а светодиод погас - снова зажигать или не давать гаснуть пока кнопка нажата? Можно ещё придумать состояния. Но и так понятно что описание не полное и если взяться за работу при таком описании то потом получишь кучу претензий.
Я объяснил как смог, по другому не могу. Да и тема уже не актуальна, код написан и он меня вполне удовлетворяет
Из всей этой дискуссиии я получил полезный совет от andriano
Вот этим я и займусь в свободное время
Учитесь. Иначе в программировании никак
Вы опять идеализируете заказчика. Заказчик приходит не с ТЗ и не с логикой. Он приходит от того, что испытывает дискомфорт от некой своей проблемы. И это все.
Та же фигня.