Самодельный круиз-контроль

[gnomon72]

gnomon72, понял. В топку его (ДЖСС то есть).

А уже пофиг в топку или не в топку - память закончилась окончательно и вариантов нет.

[hardlock]

gnomon72, я думаю, что это будет последняя верси под 168, т.к. больше улучшать нечего (ну кроме упраления - длинных нажатий). Надо переходить на 328-ю.

[gnomon72]

Обдумывал длинные нажатия - не получается никак. Специфика обработки кнопок по моменту нажатия, а не отпускания в главном 500 мс цикле не позволяет. Раньше было по отпусканию, и это вызывало ряд проблем с задержками в обработке. Т.е. если ждать пока пользователь отпустит кнопку, то с большой вероятностью проскакивался текущий цикл и реакция на кнопку отрабатывалась только в следующем, т.е. получалась неприятная нефиксированная задержка от 0 до 1000 мс на нажатие кнопки.

Чтобы переходить на 328 надо какие то идеи, а их пока вроде нет.

[OKLiK]

В топку его (ДЖСС то есть).

Тебя в топку, вещь прикольная!

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

[kapitan76]

Тебя в топку, вещь прикольная!

Расскажи как ты реализавал у себя ДЖСС это на задние поворотники что ли выход или дополнительные желтые светодиоды (куда устанавливал)

[OKLiK]

Расскажи как ты реализавал у себя ДЖСС это на задние поворотники что ли выход или дополнительные желтые светодиоды (куда устанавливал)

В дублирующий фонарь стоп сигнала!

[Andry_MA]

Обдумывал длинные нажатия - не получается никак. Специфика обработки кнопок по моменту нажатия, а не отпускания в главном 500 мс цикле не позволяет. Раньше было по отпусканию, и это вызывало ряд проблем с задержками в обработке. Т.е. если ждать пока пользователь отпустит кнопку, то с большой вероятностью проскакивался текущий цикл и реакция на кнопку отрабатывалась только в следующем, т.е. получалась неприятная нефиксированная задержка от 0 до 1000 мс на нажатие кнопки.

В своём КК длинные нажатия использовал только для 4-х кнопок из 6-ти. Соответственно 2 кнопки реагируют по моменту нажатия, 4-ре - по отпусканию.

[gnomon72]

Andry_MA, у тебя всё намного проще, т.к. кинул за десяток микросекунд данные на ЦАП и "свободен", а на тросовом дросселе ещё и приводом надо рулить, а перемещение привода всё время разное и время на перемещение требуется разное и всегда существенное - вплоть до 500 мс, т.е. это по сути всю длительность цикла управления занимает.

[Alex_Sss]

gnomon72, Это можно делать в фоне. Не в основном цикле. Тогда все получается проще, и один таймер с периодом 10 или 100мс может обслуживать сотню разных задач параллельно.

[gnomon72]

Alex_Sss, нельзя так. Обслуживать можно только некритические по времени задачи, а у нас все критические. Сейчас в основном цикле критический замер интервалов по импульсам позиционирования привода, в прерываниях критический замер периодов с ДС и критическая обработка вывода на UART. Плюс "дрыгается" прерывание по systick, где обрабатываются события нажатия кнопок, антидребезг, фоновая работа биппера и светодиодов.
Фоновая работа в прерываниях существенно снижает точность отчета временных интервалов. У меня кратность импульсов в управлении приводом от 4 мс, а точность позиционирования привода заложена порядка 0,1%, т.е. мне придется либо прерывания гонять с безумной частотой, если в них дискреты времени отсчитывать либо, наоборот, делать редкие прерывания с минимальными затратами времени на их обработку, если время в основном цикле мерять. Ни тот ни другой вариант не прокатывают, т.к. либо время криво начинаем мерять, либо скорость, либо передачу по UART "выносит" от задержек по чужим прерываниям.
И так уже с определенной частоты с ДС прекращается передача данных по UART.
Всё это уже давно пройденный и проверенный на опыте этап. Можно конечно сделать оптимизированную по временным параметрам прошивку на асме под какую то конкретную машину, но очень проблематично тоже самое сделать под абстрактную универсальную машину.