Eddy_Em 1 19 января, 2016 Опубликовано 19 января, 2016 · Жалоба процедур, которые могут длительно выполняться (десятки мсек) и блокировать процесс Фигасе, это где ж такое видано — блокировать на бешеное время? Если нужно что-то долгое делать, то выполнять порциями по значению таймера. Но лучше все на аппаратную реализацию спихнуть, тогда никаких тормозов не будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 19 января, 2016 Опубликовано 19 января, 2016 · Жалоба Вы не поняли. Я не говорю, что это нельзя делать. Я говорю, что в этот цикл (в котором опрашивается кнопка) лучше не включать вызовы других процедур, которые могут длительно выполняться (десятки мсек) и блокировать процесс скана кнопок на десятки мсек ибо будет некомфортно работать с такими кнопками из-за задержек их реакции. RC-цепочка никак не поможет в борьбе с дребезгом сама по себе. Она поможет только если сигнал после неё поступает на вход, имеющий гистерезис (триггер Шмидта). А самая надёжная аппаратная защита от дребезга - парафазный вход set/reset (RS-триггер). Понятно теперь. Но я всегда писал все процедуры на проход, чтобы как можно быстрее вылетали и все ставил в этот цикл. Проблема была только один раз, когда вычисление занимало 60 миллисекунд, но я разбил на стадии по 5 миллисекунд (AVR8535) и оформил как машину состояний. Кстати если использовать технику "резинового времени", то одноразовые переборы не будут играть роли если интегрально нет перебора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HHIMERA 0 19 января, 2016 Опубликовано 19 января, 2016 · Жалоба Если нужно что-то долгое делать, то выполнять порциями по значению таймера. Но лучше все на аппаратную реализацию спихнуть, тогда никаких тормозов не будет. 100% !!! Пнул... и пусть молотит... Ну потеряется каких-то там 100-150 байт флэша на сквозной реализации 1-wire... ну и фиг с ними... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Eddy_Em 1 19 января, 2016 Опубликовано 19 января, 2016 · Жалоба Ну потеряется каких-то там 100-150 байт флэша на сквозной реализации 1-wire... ну и фиг с ними... Если потеряются, значит, камушек неправильно выбран. Или слишком высокая скорость "общения". Как оно может потеряться? Заполнили быстренько буфер с данными, пнули DMA/TIM, выполняем что-то. Как только увидели, что флаг окончания передачи данных выставлен, обработали принятые данные. И так далее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 21 января, 2016 Опубликовано 21 января, 2016 · Жалоба Фигасе, это где ж такое видано — блокировать на бешеное время? Если нужно что-то долгое делать, то выполнять порциями по значению таймера. Но лучше все на аппаратную реализацию спихнуть, тогда никаких тормозов не будет. Это хорошо Вам если Вы целиком всё ПО пишете сами. А если у Вас команда из нескольких человек, которые пишут помодульно? И потом нужно в этом общем цикле (а-ля корпоративная многозадачность) собрать вызовы разных чужих функций, каждая написанная в своём стиле и когда не каждый член команды в состоянии адекватно построить алгоритм с ограничением времени работы функции. Элементарная ситуация: Есть ресурс с блокирующим доступом к нему (например - драйвер обмена по какому-то интерфейсу, например - SPI, на котором висит несколько разных устройств). К этому ресурсу обращается одна из функций из этого общего цикла для того, чтобы считать скажем пару байт по SPI с одного из устройств на шине. Транзакция вроде короткая и обычно занимает мало времени. Но!... Если ресурс оказывается занят (из другой задачи ОС другая функция в этот момент осуществляет длительную транзакцию с другим устройством на этой-же самой SPI), то вышеуказанная функция из общего цикла будет теперь ждать длительное время освобождения ресурса. Вот тут и будут происходить редко случающиеся длительные задержки в этом общем цикле приводящие к редким сбоям в опросе клавиш. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 21 января, 2016 Опубликовано 21 января, 2016 · Жалоба Это хорошо Вам если Вы целиком всё ПО пишете сами. А если у Вас команда из нескольких человек, которые пишут помодульно? И потом нужно в этом общем цикле (а-ля корпоративная многозадачность) собрать вызовы разных чужих функций, каждая написанная в своём стиле и когда не каждый член команды в состоянии адекватно построить алгоритм с ограничением времени работы функции. Элементарная ситуация: Есть ресурс с блокирующим доступом к нему (например - драйвер обмена по какому-то интерфейсу, например - SPI, на котором висит несколько разных устройств). К этому ресурсу обращается одна из функций из этого общего цикла для того, чтобы считать скажем пару байт по SPI с одного из устройств на шине. Транзакция вроде короткая и обычно занимает мало времени. Но!... Если ресурс оказывается занят (из другой задачи ОС другая функция в этот момент осуществляет длительную транзакцию с другим устройством на этой-же самой SPI), то вышеуказанная функция из общего цикла будет теперь ждать длительное время освобождения ресурса. Вот тут и будут происходить редко случающиеся длительные задержки в этом общем цикле приводящие к редким сбоям в опросе клавиш. Да у вас организационная проблема. Нужен архитектор или кто-то еще кто бы принуждал писать правильно. Сочувствую вам. Мне приходилось работать в подобных коллективах с иррационально мыслящим начальством. Вы не сможете ничего изменить. Я бы на вашем месте поискал работу в более здоровом коллективе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Eddy_Em 1 21 января, 2016 Опубликовано 21 января, 2016 · Жалоба Вы не сможете ничего изменить. Я бы на вашем месте поискал работу в более здоровом коллективе. ++ Жутко подобное читать! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 21 января, 2016 Опубликовано 21 января, 2016 · Жалоба ++ Жутко подобное читать! Вам просто везло. Такое довольно часто встречается если начальство неумное. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 22 января, 2016 Опубликовано 22 января, 2016 · Жалоба Да у вас организационная проблема. Нужен архитектор или кто-то еще кто бы принуждал писать правильно. Сочувствую вам. Мне приходилось работать в подобных коллективах с иррационально мыслящим начальством. Вы не сможете ничего изменить. Я бы на вашем месте поискал работу в более здоровом коллективе. Начальник уже сам начал это понимать. Сам на днях сказал, что в новых проектах будет по другому. Так что - есть надежда ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Eddy_Em 1 22 января, 2016 Опубликовано 22 января, 2016 · Жалоба Такое довольно часто встречается если начальство неумное. Если начальник — идиот, надо постараться перетащить его на свою сторону и объяснить, как надо правильно. Если он упорот совершенно и ни в какую не хочет меняться, то только один выход остается — свалить нафиг с такого гадюшника! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 22 января, 2016 Опубликовано 22 января, 2016 · Жалоба Если начальник — идиот, надо постараться перетащить его на свою сторону и объяснить, как надо правильно. Если он упорот совершенно и ни в какую не хочет меняться, то только один выход остается — свалить нафиг с такого гадюшника! Я не знаю. Мне не удавалось убедить начальника. Или упоротые были или свою игру вели. Рациональные аргументы не достигали мозга. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
