Реинициализация экрана.

[san]

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

[alx]

Мне удалось найти в драйвере функцию fbtft_init_display(), при вызове которой дисплей инициализируется. Однако процесс инициализации дисплея длится почти 200 мс. Не помешает ли такое длительное занятие шины SPI работе установки (например опросу датчиков)?

Если нет, буду думать дальше - каким образом сообщить драйверу, что надо выполнить эту функцию...

[san]

Думаю что помешает.

[alx]

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

[san]

Наверное стоит обсудить это с директором, предложившим тикет.

[alx]

Replying to san:

Думаю что помешает.

А, кстати, не мог бы ты более подробно написать, чем именно помешает?

[san]

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

[san]

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

[alx]

Согласен. Но вариант "ручной" инициализации мне тоже кажется полезным. Представь себе, что оператор работает с установкой, и вдруг дисплей "испортился" - отображает мусор. Без ручного сброса оператору придется ждать пять минут прежде чем он сможет продолжить работу. Вместо этого он мог бы, например, подержать "ОТМ" 5 секунд - и все...

[san]

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

[alx]

Replying to san:

"чтобы оператор ничего не заметил".

В таком случае, предложение тикета нереализуемо.

[andrei]

А за RESET его подергать не достаточно?
Было бы хорошо на столе поймать этот баг.

[san]

Так после резета, "настройки" дисплея сбросятся и без инициализации он корректно работать не будет.

[andrei]

Если кабель DB-9/DB-9 соединяющий панель оператора с контроллером отключить и подключить обратно дисплей перестает отображать информацию. Ресетом вылечить не получилось. Перезагрузка процессора SAM5 помогает.

[andrei]

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

[san]

Тикет создан мной по просьбе директора(смотри описание), предлагаю узнать что по этому поводу думает автор тикета.

[alx]

Поторопился я, оказывается, Саша уже ответил, почти теми же словами... :)

[andrei]

Саша, раз уж ты от директора принес этот тикет, тебе и обсуждать с директором его актуальность.
А мы ждем решения.

[san]

Директор добавлен в копию этого тикета.

[andrei]

Директор подтвердил актуальность задачи.
Думаем.
Реализуем.

[san]

Если ты не заметил, мы зашли в тупик. Читай комменты.

[alx]

Replying to san:

Если ты не заметил, мы зашли в тупик.

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

[san]

Это я понял.
Но закончили мы диалог этим:

В таком случае, предложение тикета нереализуемо.

Это я и назвал тупиком, каким образом предлагается реализовать нереализуемое?

[alx]

Под "таким случаем" подразумевалось и "чтобы оператор ничего не заметил", и чтобы задержка 200 мс ничему не помешала. С такими условиями задача, получается, нереализуема. Следовательно, необходимо чем-то пожертвовать: либо наплевать на возможность "проскочить" датчик положения, либо выбирать для инициализации дисплея "безопасный" с точки зрения работы датчиков момент (см. comment:8) или "оживлять" дисплей вручную (см. comment:3), при этом смирившись с тем, что это будет заметно для оператора.

[andrei]

В тупик, Саша, ты сам это завел наводящими комментариями.
Только инициализация нас спасет? Сброс питания я пока не рассматриваю.
Тогда предлагаю два варианта инициализации дисплея: 1- Ручками, удерживая какую-либо кнопку. 2- Автоматически.
Если речь о 200 мс, то это не так страшно.
Можно инициализировать в автомате при выводе дисплея из "ждущего режима". Нужно понять когда это не помешает работе станции (а может придумать как обойти это и инициализировать с приоритетом ниже опроса датчиков).
А если он сломается в активном состоянии, то оператор подержит кнопку и оживит его.

[andrei]

Сколько времени длится сработанное состояние датчика положения при наиболее быстром движении штока?
Наверно можно это посмотреть осциллографом в гтп.

[san]

инициализировать в автомате при выводе дисплея из "ждущего режима"

Я считаю что намеренно "тупить" 200 мс. в практически произвольный момент времени неправильно и даже опасно: решая мизерную проблему мы создаём потенциальную дыру в алгоритме.

Ручками, удерживая какую-либо кнопку.

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

необходимо чем-то пожертвовать

На мой взгляд Андрей и должен решить чем жертвовать.

[andrei]

это точно не то что хотел директор.

Не тебе это знать

На мой взгляд Андрей и должен решить чем жертвовать.

А это знать тебе, да.

[san]

Андрей, хватит превращать тикеты во флуд.

[san]

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

[san]

Т.к. за время эксплуатации жалоб на "зависшие экраны" не поступало, директор предложил закрыть тикет.