-
- Вот, сложилось - Evgeny_CDАрхитектор(11.07.2020 19:13, ссылка)
- Можно писать свое моделирование, а можно все-таки взять готовые
продукты в которые уже вложены миллионы человеко-часов труда. У
многих есть интерфейс с embedded средами и электронным
оборудованием. Simulink, Stateflow, LabView RxTx(37 знак., 11.07.2020 18:58, ссылка, ссылка)
- И заплатить за это...? - Evgeny_CDАрхитектор(11.07.2020 19:01)
- Ну не начинай. И написать всё это самому? Скупой платит дважды. Там
есть и Free/OpenSrc продукты ,посмотри на странице симулинка ниже
ссылки. - RxTx(11.07.2020 19:04)
- Написать что? Платить за что? Зачем вообще нужен LabView? Я описал технологию, там места сторонним монстрообразным программным продуктам -- нет. "Синтетический порт" -- это в первую очередь ОТЛАЖИВАЕМАЯ программа на C, отлаживаемая на ПК, а потом переносимая на МК. LabView там не нужен СОВСЕМ. Впрочем как и всё перечисленное Евгением. Там просто нужно сесть и написать код на языке, на котором тебе проще (мне было проще на Tcl, но можно на голом C, можно на питоне). fk0легенда(109 знак., 11.07.2020 19:24)
- Разумеется, все, до чего можем дотянуться, надо использовать. Но нельзя закладывать критическую зависимость от того, что не контролируешь никак. - Evgeny_CDАрхитектор(11.07.2020 19:14)
- Все - не надо. Нужно только то, что ведет к решению задачи. Это сильно меньше, чем все. - Evgeny_CDАрхитектор(11.07.2020 19:13)
- Ну не начинай. И написать всё это самому? Скупой платит дважды. Там
есть и Free/OpenSrc продукты ,посмотри на странице симулинка ниже
ссылки. - RxTx(11.07.2020 19:04)
- И заплатить за это...? - Evgeny_CDАрхитектор(11.07.2020 19:01)
- Раньше было все просто и понятно - программа, написанная на С или
Борланд Паскаль работала и на целевом устройстве, и на PC без
дополнительных сущностей, называемых синтетическими портами. Это
было удобно и полезно, т.к. отладочных средств практически не было.
Сейчас они есть, и закрывают практически все потребности.
Изобретать кросс - проверку наличия сигнала CS ? При минимальной
иерархии ПО это отлавливается за 5 минут. Другое дело - какая-то
сложная математика, но тогда VLLV(293 знак., 11.07.2020 18:26)
- Все просто. Evgeny_CDАрхитектор(1503 знак., 11.07.2020 18:49)
- Синтетический порт должен быть простым и понятным. Нужно вначале четко определить иерархию сущностей. Иначе все зря. Evgeny_CDАрхитектор(1500 знак., 11.07.2020 18:00, ссылка)
- Посмотри сюда как на инструментальную платформу - Evgeny_CDАрхитектор(11.07.2020 17:35, ссылка)
- В своих идеях я вдохновлялся GNU Radio и Pothos Ware evgeniy1294(151 знак., 11.07.2020 18:17)
- Pothosware - сильно, спасибо! - Evgeny_CDАрхитектор(11.07.2020 18:27, ссылка)
- В своих идеях я вдохновлялся GNU Radio и Pothos Ware evgeniy1294(151 знак., 11.07.2020 18:17)
- Вдогонку: я бы очень советовал иметь скриптовый язык с динамической
типизацией, для быстрого перепрограммирования "окружения". На C/C++
его писать муторно и долго. Более того, может быть удобно иметь
консоль с командами, чтоб потыкать руками за какие-то ручки,
которые в явном виде выводить (в GUI, или ещё куда) не хочется, ибо
нужно на один раз. Да, в том же Tcl на самом Tcl можно сделать GUI.
Впрочем, в питоне тоже можно, но там внутри будет спрятанный Tcl (в fk0легенда(55 знак., 11.07.2020 13:16)
- Скриптовый язык рассматриваю, так как действительно удобнее. - evgeniy1294(11.07.2020 14:10)
- Начиная с virtual environment смешалось всё. JSON и всё такое
прочее -- это детали реализации конкретной системы, а не
высокоуровневое описание. Да есть управляющее ПО перенесённое на
ПЦ, есть слой драйверов, который на ПЦ реализован иначе (но имеет
общий, с точки зрения управляющего ПО, интерфейс с драйверами на
таргете). И драйвера могут непосредственно реализовать виртуальное
окружение, либо выступать интерфейсной частью к нему. Я, например,
делал так, что драйвера fk0легенда(1838 знак., 11.07.2020 13:12)
- Я подразумеваю, что слой, где происходит разделение на
виртуальный/реальный драйвер может архитектурно быть несколько
выше. Не обязательно симулировать I2C на уровне ножек SCL и SDA. И
не обязательно на уровне посылок пакетов через I2C. Если известно,
что к I2C подключена память и ещё микросхема способная выполнить
пяток разных команд, то делаются два (виртуальных) драйвера -- один
для памяти (на уровне чтения-записи блоков), другой для микросхемы
с пятью функциями. fk0легенда(602 знак., 11.07.2020 13:40, ссылка)
- "Я подразумеваю, что слой, где происходит разделение на виртуальный/реальный драйвер может архитектурно быть несколько выше. Не обязательно симулировать I2C на уровне ножек SCL и SDA." - это изначально и предполагалось. Симуляцию того же I2C я предполагал с помощью пакетов, например I2C-устройство получит сообщение с содержанием <ADDR> <REG> <DATA> (или похожее). Аналогично с PWM или SPI. - evgeniy1294(11.07.2020 13:57)
- Я подразумеваю, что слой, где происходит разделение на
виртуальный/реальный драйвер может архитектурно быть несколько
выше. Не обязательно симулировать I2C на уровне ножек SCL и SDA. И
не обязательно на уровне посылок пакетов через I2C. Если известно,
что к I2C подключена память и ещё микросхема способная выполнить
пяток разных команд, то делаются два (виртуальных) драйвера -- один
для памяти (на уровне чтения-записи блоков), другой для микросхемы
с пятью функциями. fk0легенда(602 знак., 11.07.2020 13:40, ссылка)
- Пример реализации системы evgeniy1294(1 знак., 11.07.2020 12:34, картинка)