ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
21 ноября
О смысле всего сущего0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынокОбъявления
МикроконтроллерыPLD, FPGA, DSP AVRPICARM, RISC-VТехнологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты
1017434 Топик полностью
Связанные сообщения
Синтетический Порт
Требуется мнение об идее реализации синтетических портов, пока привожу основные тезисы: Синтетической порт(Synth port) представл...2020-07-11
Железо нужно симулировать не на уровне битов и фронтов сигналов, а на уровне высокоуровневых операций (например, чтение-запись б...2019-11-07
Спасибо, вообще в документе многие пункты достаточно разумны, я особо подчерку для некоторых здешних читателей:2019-10-30
Когда часть ПО, которая на стыке с железом, замещается на симулятор для ПК и вся программа запускается и отлаживается на ПК. В и...2019-10-02
Для этого не нужен именно ваш прибор, для этого может быть вообще не нужно железо (про "синтетический порт" и Evgeny_CD и я уже ...2019-10-02
Помимо прочего при нормальном программировании всегда делается какой-то "логгер" ведущий протокол работы программы. Потому, что ...2019-08-10
От проекта зависит. Насколько чётко выделена аппаратно-зависимая часть и насколько абстракции используемые в старом проекте реал...2019-05-24
Собственно можно код запускать в эмуляторе процессора (qemu), которому привязать симуляцию нужной аппаратуры, или заменить HAL н...2019-02-06
Жалкая паделка финских студентов написана на 100% на C, из ассемблера только вектора прерываний, crt и ещё мелочи, в C30 v3.31. ...2014-04-10
Кто о чем, а вшивый о бане я о кодевеломпенте софта-железа. Итак, пусть у нас есть Tcl, который позволяет прикручивать "в...2012-02-24
Кстати, про синтетические системы и реальное время. Все гораздо интереснее, чем кажется!2007-07-28
fk0, легенда (11.07.2020 13:12, просмотров: 745) ответил evgeniy1294 на Требуется мнение об идее реализации синтетических портов, пока привожу основные тезисы: Синтетической порт(Synth port) представляет собой программу, платформонезависимая логика которой запускается не на физическом устройстве, а в синтетическом (программном) окружении. Синтетическая периферия является высокоуровневой программной реализацией аппаратной части микроконтроллера (МК) и предназначена для отладки платформонезависимой логики. Синтетическая периферия не ставит
Начиная с virtual environment смешалось всё. JSON и всё такое прочее -- это детали реализации конкретной системы, а не высокоуровневое описание. Да есть управляющее ПО перенесённое на ПЦ, есть слой драйверов, который на ПЦ реализован иначе (но имеет общий, с точки зрения управляющего ПО, интерфейс с драйверами на таргете). И драйвера могут непосредственно реализовать виртуальное окружение, либо выступать интерфейсной частью к нему. Я, например, делал так, что драйвера 

содержали прослойку для связи C с Tcl, а "окружение" можно было допрограммировать на тикле. А некоторые вещи, ту же память, нет смысла протаскивать через Tcl, она сразу отображалась на файл в компьютере, прямо драйвером. И не нужны никакие роутеры, шины, соединения... собственно как и сервер -- всё работает в одном процессе, на одном компьютере. Тем более непонятно, какие там соединения возможны -- I2C не подключишь к UART'у, у них разные интерфейсы и логика работы... Симуляция сетей и радиоканала отдельный момент. Её проще реализовать поверх IP-сети, в рамках UDP multicast (если абонентов шины больше двух). Чтоб все слышали всех. Соответсвенно разные абоненты -- разные процессы/программы или даже компьютеры. Симуляция множественного доступа к среде передачи может осуществляться отбрасыванием принятых пакетов в течении какого-то времени после любой передачи, что реализуется непосредственно в драйвере, прилинкованном к каждому абоненту. По-моему у тебя архитектурный оверинжинеринг (на картинке, где сервер, роутер, и всё такое прочее). Зачем что-то выносить на какой-то сервер? Зачем вначале GPIO, UART и SPI попадают в роутер, клиент, потом на сервер, а потом обратно разбиваются на составляющие? Что мешает связать прямо в compile time с нужными элементами "виртуального окружения", намертво прикомпилированныи к "синтетическому порту". С сервером как минимум отлаживать невозможно: ты в gdb остановил (все потоки текущего процесса) -- а он молотит дальше. И кстати функция получения времени должна понимать, сколько она в gdb простояла, чтоб таймауты не срабатывали. У меня таймер в линуксе программировался на ~1000 раз в секунду и обработчик сигнала (как будто прерывания) просто инкрементировал переменную счётчика времени. Соответственно, в gdb пока стоит -- сигналы не обрабатываются, и время вперёд не идёт.

[ZX]
Ответить