Разработка кроссплатформенного (микроконтроллер-ПК) алгоритма - PullRequest
0 голосов
/ 20 декабря 2010

Меня попросили разработать алгоритм для сетевого приложения на C. Этот проект будет разработан для Linux для ПК, а затем будет переведен на более портативную платформу, которая будет включать микроконтроллер. Есть много микроконтроллеров / компаний, которые предоставляют очень хорошие и большие библиотеки для TCP / IP. Это программное обеспечение будет хранить статистику о производительности сети.

Сама идея кроссплатформенности (uC - PC) кажется мне чепухой, потому что в конечном итоге код должен быть написан для платформы более специфично для микроконтроллера, но я все равно не эксперт, чтобы судить.

Есть ли какой-нибудь умный способ сделать это или есть кто-то, кто делал это раньше? В моем мозговом штурме есть «Библиотека Wrapper» и «Matlab» ... Есть идеи?

Thx!

Ответы [ 3 ]

1 голос
/ 20 декабря 2010

Предположим, вы можете использовать стандартную библиотеку сокетов BSD (системные вызовы: socket (), bind (), accept (), connect (), recv (), send (), с различными опциями)) Любая ОС со стеком TCP / IP будет поддерживать этот стандартный API.

Возможно, вы столкнетесь с некоторыми оговорками, если ваша встроенная система будет использовать стек TCP / IP типа выполнения до завершения, например * u * IP, но они будут легко решаемы.

Также используйте только файловый ввод / вывод POSIX (fopen, fread, fwrite, printf и т. Д.). Но имейте в виду, что ваша цель может не иметь файловой системы.

1 голос
/ 20 декабря 2010

Я в некоторой степени согласен с вами - вы хотите, чтобы целевая система и система, на которой вы разрабатываете в промежуточный период, должны быть как можно ближе (лучше, если они могут совпадать).Тем не менее, идея кроссплатформенности состоит в том, чтобы вы начали разработку прошивки во время разработки аппаратного обеспечения.Вместо того, чтобы делать это в Linux - я бы использовал симулятор Embedded OS.Вот шаги
- Шаг 1: Определите ОС для встроенной системы;убедитесь, что в ОС есть симулятор, работающий на ПК (Win или Linux). Типичные встроенные ОС с симулятором включают VxWorks, µC / OS-II, QNX, uClinux ... Соглашение об ОС означает, что команда разработчиков оборудования знает, что ОСявляется правильным соответствием для проектируемого оборудования, и существует консенсус в отношении того, что проектируемое оборудование + ОС + будет удовлетворять требованиям разрабатываемой системы.
- Шаг 2: Используйте этот симулятор для разработкиприложение до тех пор, пока не будет запущено проектируемое оборудование.
- Шаг 3. После того, как первая версия оборудования будет готова и включена - вы можете запускать приложение с минимальными изменениями - в основном без изменений в коде, но возможны изменения в используемом компоновщике / библиотеке.

Идея кроссплатформенности, если все сделано правильно, имеет огромные преимущества - она ​​помогает устранить сериализацию действий по разработке вашего проекта.

Учитывая, что вы упоминаете, что это приложение TCP / IP - проверьте наличие сокетов Berkeleyподдержите и вы им пользуетесь.Обычно этот API не должен иметь значения, если вы используете симулятор, в крайнем случае, если вам нужно сменить ОС по какой-либо причине, ваше приложение на основе сокетов Berkeley, вероятно, будет лучше переносимым.

0 голосов
/ 21 декабря 2010

Если бы использование симулятора не было вариантом, я бы попытался обернуть функции Linux в интерфейсы, которые, по возможности, соответствуют интерфейсам встроенной системы. Таким образом, любая дополнительная масса в системе будет в системе разработки Linux (которая не ограничена в ресурсах). Различные встроенные ОС и стеки TCP / IP могут иметь совершенно разную архитектуру, поэтому насколько легко это может варьироваться от почти невозможного до вообще без работы.

Если окажется, что написание библиотек-оболочек для того, чтобы Linux выглядел как встроенная система, было слишком сложным, тогда я предлагаю хотя бы попытаться помнить о встроенной ОС при написании версии для Linux, чтобы вы могли попытаться хотя бы написать некоторые функции, чтобы они работали в обеих системах.

Если написание Linux-версии хотя бы части кода не займет слишком много времени, это поможет вам, по крайней мере, устранить некоторые недостатки в общем дизайне. Самое большее, это позволит вам быстрее тестировать изменения в системе, поскольку загрузка кода на встроенное устройство часто занимает больше времени, чем вы хотели бы. Это также может быть проще для отладки на компьютере разработчика.

Некоторые встроенные ОС будут работать на x86, и меня не удивит, если у некоторых из них будут драйверы, позволяющие запускать их на виртуальных машинах, так что это может быть и вариант.

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

...