MrBearManul 0 26 февраля, 2021 Опубликовано 26 февраля, 2021 · Жалоба Добрый день, коллеги! Извините за пафосный заголовок, но другого придумать не смог) Ситуация такая: есть промышленный компьютер в щите, к которому через шину RS-485 подключены некие модули ввода-вывода. С одних модулей мы читаем ифнормацию, принимаем решение и скармливаем это решение модулям вывода. Скорость шины 115200, длина управляющих пакетов не более 64 байт. Модулей около 16 штук. Допустимо ли использовать интерпретатор Питона, запущенный как фоновый процессс в Линуксе? Самое главное, что некая задержка в обмене данными, вызыванная Линуксом или самим интерпретатором - некритична. Даже, если это будет 500 - 1500 мс. Но важно, чтобы сам по себе процесс не завершился спонтанно. Это очень нежелательно. В принципе тест показывает, что всё успешно работает уже неделю в режиме 24/7. Мой вопрос: есть ли какие-то подводные камни, о которых я могу не знать? Я не являюсь большим знатоком Линукса и Питона. Моё решение временное до завершения проекта по "нормальному" компу с ОСРВ. Может быть, что, например, Линукс "неожиданно" завершит процесс по каким-то причинам? Или сам интерпретатор Питона свалится через 12 дней, например, из-за известного бага переполнения какого-либо счётчика? Если понадобятся уточнения, задайте, пожалуйста, наводящие вопросы. Сфера для меня пока новая, я и сам не очень хорошо понимаю, на чём следует заострить внимание. Спасибо! З.Ы. Если есть хорошие статейки на данную тему, то можно сразу направить на них. З.Ы.Ы. Linux 2020.08.2. Железо на базе МК AT91SAM9G45. Python 3.7.1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rkit 1 26 февраля, 2021 Опубликовано 26 февраля, 2021 · Жалоба Завершит если память закончится. С самим питоном основная проблема в постоянных обновлениях, а значит баги текучие, и их надо постоянно отслеживать. Обычная практика для скриптов это проектировать систему так, чтобы она спокойно переживала падения и перезапускалась. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xvr 12 26 февраля, 2021 Опубликовано 26 февраля, 2021 · Жалоба 4 hours ago, MrBearManul said: важно, чтобы сам по себе процесс не завершился спонтанно. Первое же неперехваченное исключение в Питоне и он как раз и 'завершится спонтанно'. Всё зависит от скрипта, который крутится на интерпретаторе Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrBearManul 0 26 февраля, 2021 Опубликовано 26 февраля, 2021 · Жалоба 6 часов назад, rkit сказал: чтобы она спокойно переживала падения и перезапускалась. Согласен с вашим замечанием. Внешний WDT прикрутить небольшая проблема на платке. 3 часа назад, xvr сказал: Всё зависит от скрипта, который крутится на интерпретаторе В общем там ввод-вывод через USB CDC (на преобразователь в шину RS-484), несложная математика, опрос часов реального времени, т.к. управление привязано к календарю. Но в целом можно следовать совету уважаемого @rkit. Спасибо, коллеги! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 34 27 февраля, 2021 Опубликовано 27 февраля, 2021 (изменено) · Жалоба 26.02.2021 в 10:49, MrBearManul сказал: Мой вопрос: есть ли какие-то подводные камни, о которых я могу не знать? Вряд-ли тут есть люди, которые могут знать их все))) От себя, чем больше всяческих "прослоек" между железом и целевым кодом, тем меньше надежность. Надежность ответственных вещей можно гарантировать только как можно более простым и "прозрачным" кодом или, если это невозможно, резервированием. Все остальное - это из надежды на авось... 16 часов назад, MrBearManul сказал: В общем там ввод-вывод через USB CDC (на преобразователь в шину RS-484), несложная математика, опрос часов реального времени, т.к. управление привязано к календарю. Тогда вопрос - что в такой архисложной задаче нельзя было сделать на "чистом" Си? 22 часа назад, rkit сказал: чтобы она спокойно переживала падения и перезапускалась. Честно говоря, это не гуд для ответственных систем, такой подход еще можно использовать для како-го нить планшетика, для игрушек... Изменено 27 февраля, 2021 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 27 февраля, 2021 Опубликовано 27 февраля, 2021 · Жалоба 57 minutes ago, mantech said: От себя, чем больше всяческих "прослоек" между железом и целевым кодом, тем меньше надежность. Надежность ответственных вещей можно гарантировать только как можно более простым и "прозрачным" кодом или, если это невозможно, резервированием. Все остальное - это из надежды на авось... У вас судя по всему слишком узкий опыт, поэтому мнение не очень компетентное. Надежные системы строяться на целом стеке "прослоек". Например для индустриального оборудования мы создаем алгоритм в Matlab, там мы используем Stateflow в графической нотации, из него генерим автоматически сорсы на ST, код на ST грузим в среду разработки PLC, среда разработки PLC превращает это в некий протокод, этот протокод уже в PLC превращается в машинный код. Ни на одном этапе сам код никто не смотрит на "прозрачность". Здесь проблема не в прослойках, а в правильном их стеке. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 34 27 февраля, 2021 Опубликовано 27 февраля, 2021 · Жалоба 2 минуты назад, AlexandrY сказал: Надежные системы строяться на целом стеке "прослоек". Эти "прослойки" неоднократно протестированы согласно требованиям промавтоматики, то, что описал ТС нигде по таким алгоритмам не тестировалось, поэтому на свой страх и риск... 4 минуты назад, AlexandrY сказал: генерим автоматически сорсы на ST, код на ST грузим в среду разработки PLC, среда разработки PLC И что, "прозрачный" код на Си тоже потом попадает в компилятор... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 27 февраля, 2021 Опубликовано 27 февраля, 2021 · Жалоба 13 minutes ago, mantech said: Эти "прослойки" неоднократно протестированы согласно требованиям промавтоматики, то, что описал ТС нигде по таким алгоритмам не тестировалось, поэтому на свой страх и риск... А с этим согласен. Но опять же вспомним опыт с языком C. Когда в промышленное программирование ломанулось нерды со своими заумными лексемами, которые не может распарсить даже компилятор, то против них придумали MISRA. Так и с пионом, если ограничить лексикон и ассортимент подключаемых либ, то вполне можно сделать надежные решения даже в ненадежной вобщем-то среде. Просто в питоне это придется искать собственной головой об стенку. Но так малобюджетные проекты и делаются. Вкладываются не в средства разработки, а в выжимание разработчиков. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 34 27 февраля, 2021 Опубликовано 27 февраля, 2021 · Жалоба 3 часа назад, AlexandrY сказал: Так и с пионом, если ограничить лексикон и ассортимент подключаемых либ, то вполне можно сделать надежные решения даже в ненадежной вобщем-то среде. Этого не будет до тех пор, пока все это в разряде опенсорса, за надежность не может отвечать сообщество, должен быть один человек, который отвечает за проект целиком, и тестирование в частности, за "спасибо" никто этим заниматься не будет и все это останется в области DIY-шников... И второе, питон в большинстве своем работает по принципу JIT, соотв. никакой предкомпиляции в байткод нет, а значит любая ошибка в синтаксисе приведет к вылету из программы, если исходный файл еще можно защитить от повреждения какой-нить КС, то синтаксис можно проверить только полным покрытием кода, что почти никто не делает... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrBearManul 0 1 марта, 2021 Опубликовано 1 марта, 2021 · Жалоба Коллеги, все ответы прочитал. Выводы сделал. Система временная, внешний вочдог пока как костылик... Спасибо) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться