roboforum.ru

1. Системы могут быть автономными или нет, но очень часто есть и быстродействие, и Ethernet и требования к удалённой настройке/калибровке/изменениям параметров работы, тут казалось бы RPC - идеальное решение, но оно не используется, свои соображения почему я уже высказал;

2. Встраимаемые системы сегодня используют железо в разы быстрее и лучше, чем было на моём первом компьютере 8 лет назад, возможность быстрой смены прошивки закладывается на этапе проектирования. На счёт "работает - не трогай" это клиника, надо менять программиста;

3. Ок, общего стандарта нет, но что мешает Атмелу или TI создать свою библиотеку на радость пользователям (стандарта общения с DSP тоже нет, но библиотеки есть)? Не додумались до сих пор?

Я говорю про случаи, когда все предпосылки для использования RPC в приборах есть (да, контроллеру лифта и калькулятору использовать RPC нет смысла), но он почему-то не используется. Почему? Я объяснил.

P.S. Я говорю про RPC, а не про Вашу библиотеку. Ваша библиотека вполне хороша в плане быстрого освоения AVR и быстрого получения результатов (после нажатия магической кнопки).

mgalemin писал(а):2. Встраимаемые системы сегодня используют железо в разы быстрее и лучше, чем было на моём первом компьютере 8 лет назад, возможность быстрой смены прошивки закладывается на этапе проектирования. На счёт "работает - не трогай" это клиника, надо менять программиста;

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

свои соображения почему я уже высказал;

Вы привели в качестве примера передачу потокового видео/аудио. Честно говоря я не знаю зачем там RPC.
Далее вы свалили в кучу быстродействие и скорость передачи данных по каналу, UART и TCP (они из разных уровней OSI) и это вызвало у меня непонимание.
Поясните пожалуйста как незначительное увеличение скорости отработки команд может сказаться и стать причиной отказа от RPC при решении задач нанастройки/калибровки/изменении устройств?
Можете привести содержательный пример хотелось сделать то-то и то-то применив RPC, но не вышло, т.к. RPC оказался медлителен? Это не отрицание в виде вопроса, мне действительно интересно.

Хотелось сделать программу для PC для чтения/записи параметров прибора, но от RPC пришлось отказаться, т.к. это сказалось бы на снижении быстродействия программы при сотнях запросов с потерями пакетов, усложнении архитектуры и решил сделать проще (как следствие надежнее и в конечном итоге быстрее). Выбирая из стандартных средств предпочтение отдал SNMP, т.к. не вижу смысла применять кустарный RPC для реального коммерческого прибора когда можно применить что-то стандартное и распространенное.

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

Вышла новаz версия нашего инструмента.
В отличие от предыдущей версии улучшена работа GUI Arduino, памятью AVR, а также исправлены мелкие недочеты в кодогенераторе.