Дело в том, что ртос бареметал и пр. как правило прошиты внутрь проца и обновляются бутлодырем, а так да, ничем особым не отличаются



Возможно, не являюсь спецом в этом, другое дело, вы свою прогу защитить от копирования сможете? В ртосах и бареметалах опять же, программы пишутся во флеш, есть технология защиты... Понятно, все это ломается, но стоит немалых денег, а тут просто копируй и все...

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

Ну я не знаю, как вам доказать. Вот есть даташит Написано, что все сделано в hardware. Да и какой там процессор, если гарантируется задержка не более 100ns? Это только в железе, только хардкор. Сами в другом проекте на ПЛИС отрабатываем аналогичные вещи в реальном времени, только не TCP/IP, а IEC61850 Goose + SV + EtherCAT полностью в ПЛИСе без каких либо процессорных ядер, поэтому я склонен им верить. Но это другая тема.

Прочитали бы некро-статью и поняли как это делается.
Доказать то конечно не докажете. Это же закрытая технология. Вам там никто ничего расписывать не будет.
У тех ребят особый слэнг, они hardware называт все что закрыто в их дизайне.
Тогда создается ложное впечатление, что у них нет кода и следовательно нечего хакать.

Приветствую!


Вот Вам TCP/IP_offload место для тык... взрыва стереотипов - чисто логика - никакого софт-процессора гы-гы-гы.

Успехов! Rob.

А что все привязались к этому тисипи айпи?
Ведь протокол то дермовенький. И если Вам ктырнету девайс подключать не надо, то что мешает свой протокол сваять?

Еще какой дерьмовенький. Если его програмно исполнять, то точно хуже чем CAN. CAN хоть работать будет. Но недостаток обоих безусловно в том, что их придется изучать.

Ну ладно. Не осилили Ethernet. Сделайте такой реал-тайм. Видео камерy 720p надо обжать в h264 и отправить по RTP другому реал-тайм компьютеру, который и отобразит это на дисплее.
Видео самый что ни на есть реалтайм. Даже простой PAL 25 раз в секунду кадры меняются, а строки каждые 64 микросекунды. Пиксели с частотой 13.5 мегагерца. Осилит ваша крутая ось? Или без специализированного железа не обойдетесь?
Такую задачу на Линуксе я минут за 20 исполню. На малине делал.



Ну и что? Разве кто-то спорит, что используется специальное железо? Я как раз именно за такой подход к реал-тайму. Мне как разработчику системы филолетово как оно сделано. Я сам не собираюсь это разрабатывать. Моя задача сделать такую систему, чтобы она использовала все достоинства этого специального железа. А если и придется, то на ПЛИСке сделаю.

Может все же на процессоре и на на линупсе?

Вы тут немного поторопились. Это не TCP/IP, а его недоделанные куски.
Да и дизайн на RTL основан.
Эт все равно что программу зашить в ПЗУ и кричать, что все сделанно на логике.


Это не ралтайм.
Видео может к клиенту придти с секундной задержкой и никто не заметит, могут выпадать кадры и т.д.
И такие референсные аппликации у TI идут исключительно под управлением RTOS DSP/BIOS.
В разы надежней работают чем под линукс.

А линукс вам скорее всего был нужен потому что либо:
а) вы не имели документации на железо ,
б) не осилили запуск RTP из lwIP либо еще что-то из промежуточного софта.

И чего тут особенного? Или у вас все эти пиксели программно формируются и жмутся? Тоже ведь спец железо используете, хоть и встроенное в контроллер, не?

А за 20 минут... При условии, что взяли 90% референса, который уже кто-то делал до вас - тогда поверю, а вот попробуйте туда "подсунуть" какую-нить доп. информацию в кадр?
И кстати да, видео не реалтайм, а стриминг, разница есть...

Сообщение отредактировал mantech - Nov 28 2017, 08:30

Приветствую!


Но при этом они даже работают - ARP адрес определяет, connect устанавливает, данные передает, ретрейны, таймауты, че еще надо?


RTL транслируется в HDL, который затем мапится в логические примитивы, (информация о которых затем зашивается в ПЗУ - облом ).
Но процессора все же нет - кто ж тогда трудится?


Вон с Марса или Розетты видео транслировали с задержкой десяток мин - и считают что это реалтиме.

Читая эту трансляцию чемпионата по длине и диаметру задаюсь вопросом о критерии "реалтайм".
Каков у каждого участника ЭТОТ (не подумаете плохого ) критерий по которому можно однозначно сказать что это rel-time ?

Удачи! Rob.

Ну так и процессор транслируется в HDL. Понимаете мысль?

А риалтайм это не о времени, а о технологии - расстановки приоритетов, декомпозиция на задачи, прогнозирование реакции на поток асинхронных событий, критерии планируемости и т.д. и т.п.
По быстродействию тоже не определились.
Я считаю, что i.MX RT уделает линукс на малине любой версии по количеству обработанных прерываний за единицу времени.
Так что мерится тут и мерится. Присоединяетесь.

Приветствую!


Ага - но процессор это же наброр регистров и логики ...


Это не реалтиме - это просто грамотный инженерный подход к проектированию системы IMHO.


Нее - я пытаюсь имеющемся у наличии инструментом парвильно распоряжатся - доставля удовольствие и себе и партнер...
Да и сейчас у меня другая весовая категория - успел за 100 нс - и ты REALtime не успел - полезай в буфер лузер и дергай за я.. прерывание reltime-щика выше Это лет 5-7 назад меня за прерывания дергали в основном в DSP.

Поэтому современный критерий reltime все ж интересно узнать.

Удачи! Rob.

Не, у вас значит не "REALtime", а просто DSP, только доступ к DSP теперь замаскирован от вас уровнем RTL.

К примеру задачей типовой риалтайм embedded системы является обслуживание 10 и более типов периферии включая интерфейсы UART, I2C, SPI, sBUS, USB, Wi-Fi, SDIO
Поверх этих интерфейсов система обеспечивает работу протоколов высокого уровня как: HTTP, MQTT, профили дивайсов USB, файловые системы, отладочные логи...
И все это должно работать когда прикладная задача позиционирует дивайс в пространстве с точностью 0.05 град c помощью кучки не самых точных электроприводов.
Умный робот-пылесос назовем это условно.

И с какой скоростью должен реагировать этот робот? Скажем так, 50 раз в сек. частота принятия решений вполне устроит, ибо он у вас не со сверхзвуковой скоростью ездит. Следовательно реалтайм тут на уровне среднего ПЛК получается.



Зачем неточным приводам получать координаты 0.05град? Если они все равно не смогут так спозиционироваться?