roboforum.ru

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

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

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

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

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

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

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

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