Кросс-компиляторный шаблон (EC++, IAR, GCC), Попытка правильного проектирования сверху Опции

[uni]

Доброго, уважаемый форумчане.

Хочу предложить вашему вниманию пробный проект на C++ для объединения в одно целое процесса проектирования для микроконтроллеров AVR.

Я пытаюсь «подружить»: SVN (VisualSVN для VS2008), Proteus 7.6 (ISIS), Enterprise Architect, VS2008, IAR 5.51, WinAVR-20100110, AVR Studio 4 и AVR Studio 5… ух, короче, всё это в одном проекте.

Думается мне, что если писать на чистом C++, без особых выкрутасов, то можно иметь кросс-компиляторный проект в одном почти флаконе. Конкретно этот у меня компилируется и в IAR 5.51 и в WinAVR-20100110.

Цели:
1. Проектирование сверху (UML2).
2. Использование удобной IDE VS2008.
3. Рабочая виртуальная модель для тестов.

Ссылка на хранилище (svn): https://mysvn.ru/cop/Example/ (доступ: чтение)
Клиент для SVN под Windows: TortoiseSVN

Краткое описание есть там в readme.txt.

Отлаживаю одновременно в: ISIS, IAR и AVR Studio (через ubrof8, который генерится IAR'ом специально для этого).

Я пишу «образ» проекта в EA, используя редактор UML2, потом генерю образ(ы) класса(ов) в виде исходников и подключаю их в VS2008. Там же в студии через Makefile компилирую. Отладку, симуляцию можно делать где угодно.

Переключение компилятора в Defines.h (одном месте).
Моделируемая схема: Example.dsn — Proteus ISIS 7.6.

Вся необходимая инфа по сборке исходника в плане используемых портов и пинов находится в файле: Configuration.h

Хочу собрать вирутальную модель модуля АСУТП, работающего по MODBUS (припомощи com2com или аналога).
После этого:
- найти свободный OPC сервер и установить на компе;
- подключить модель Proteus к OPC серверу через COM-порт и MODBUS;
- взять китайску подделку а-ля iPad с версией Android не менее 1.6;
- найти OPC-клиент на Java для Android;
- написать самопальный HMI, который по WiFi будет подсоединяться через OPC-клиент к OPC-серверу;
- повесить планшетник на стенку, приделать в модели Протеуса 1-Wire термометр и любоваться на планшетнике температуру в модели.

------------------------------------

Кто-нить занимался чем-то подобным? В смысле кросс-компиляторности. Интересует использование строк, которые хранятся в памяти программ, т.е. универсальный подход для IAR и GCC.




Просто когда-то я был привлёчён вот к такому проектик для AVR'ки. Мягко говоря, он мне показался слегка запутанным и кроме самого кода никаких больше доков. Эту схемку нарисовала уже студия 2008.
Самый крайний правый класс - это пример того как не надо проектировать классы он у меня в несколько экранов даже в таком виде не помещается.




Сообщение отредактировал uni - Jul 17 2011, 21:07

[ig_z]

Цели:
1. Проектирование сверху (UML2).
2. Использование удобной IDE VS2008.
3. Рабочая виртуальная модель для тестов.

При таком подходе следовало бы опереться на методологию TDD.
Пунктом 1.а создавать тест, пунктом 1.б создавать тестируемый модуль.
Пунктом 2.а запускать сборку модульных тестов и выполнять их. При успешном прохождении модульных тестов, делать тестовую сборку всего приложения, и опять запускать тесты (или тестера ).

[uni]

При таком подходе следовало бы опереться на методологию TDD.
Пунктом 1.а создавать тест, пунктом 1.б создавать тестируемый модуль.
Пунктом 2.а запускать сборку модульных тестов и выполнять их. При успешном прохождении модульных тестов, делать тестовую сборку всего приложения, и опять запускать тесты (или тестера ).

Принято По поводу тестирования. Понятия не имею как писать тесты под МК, но думается мне, что если что-то подобное делать, то можно тестировать ПО через Proteus (эмулируемый COM порт), либо через реальный интерфейс с реальным железом. Не знаю как это будет выглядеть. Не тестировать же классы на ПК - среда не та.

--------------------------------

neiver, я прочитал Вашу статью про указатели. Получается, что перегрузка методов в avr-gcc не пашет именно для такого случая? В IAR'е я могу написать просто дополнительный метод с другим типом параметра для чтения, без использования шаблонов.

Жалко, однако, это больше на костыль похоже для моего случая. Буду думать.

--------------------------------

Что касаемо OPC, то он нужен не для Android, а для Java. Какая разница вообще платформа. Это открытый интерфейс для работы в промышленности. Я потому к нему и веду. Если будет завязка: MODBUS + OPC, то можно будет эту поделку вполне реально применять совместо с огромной кучей имеющегося софта АСУТП верхнего уровня. Вот в чём смысл то. Поделки на AVR типа зажигания светодиодов, чтения температуры и т.д. уже пора оставить в прошлом Давай-те чё-нить посерьёзней.

К тому же, если я смогу реализовать эту свою задумку, то применение такого "шаблона" проектирования на C++ можно будет использовать и в простых проектах. Не обязательно совмещать такую кучу всего в одном проекте. Зато, если ты знаешь, что ЭТО работает в сложном проекте, то в малом будет и подавно.

Смысла в этом нету никакого, поскольку ОРС под андроид нету вообще. Ввиду нахренникомуненужности.
Видал статейку однажды, как в андроид встраивают драйвера FTDI. Вот это ещё можно прикрутить. Либо через ВТ.
Ещё раз повторюсь: смысл ОРС сервера в стандартном сопряжении с ОРС-клиентами. При отсутствии готовых клиентов смысл сервера теряется напрочь.
Или возможно я чего-то недопонял.

Сервер будет не на планшетнике, а на стационарном компе. Смысл в том, чтобы использовать дешёвый ПК с тачскрином (можно КПК, хотя он и есть смартфон на Линуксе) в качестве клиента OPC. Там на борту есть всё: тачскрин, ява, wifi - что ещё нужно для написания юзабельного интерфейса для доступа к промышленной сети? Никто не мешает купить нормальную панель с Windows для тех же целей и писать на WinCC или Intouch. Без разницы будет. Дело в том, что я хочу показать на "простом" примере. А WinCC и Intouch - это не совсем просто

[neiver]

Не тестировать же классы на ПК - среда не та.

Почему нет? БОльшую часть встроенного приложения можно успешно тестировать на ПК - модульные тесты рулят. На целевой платформе нужно тестировать тоько низкоуровневый код, работающий непосредственно с железом. Тестирование на целевой платформе должно быть сведено к разумному минимуму.

По поводу OPC и COM/DCOM в частности, те, кто использовал эти технологии 10 лет назад сейчас активно от них избавляются в пользу веб служб. У DCOM очень большие проблемы обеспечения безопасности в распределённых сетях - админы с него волками воют. COM/DCOM, которые лежат в основе OPC слишком сложные и "замшелые" технологии.
То для чего Вы хотите использовать MODBUS + OPC + Android сейчас обычно делается так:
Промышленное устройство, которым нам надо управлять удалённо, имеет какой либо стандартный сетевой интерфейс (Ethernet, Wi-fi или еще что-нибудь) и подключено к корпоративной сети. На нём работает веб-служба (не путать в веб пользовательским итерфейсом), позволяющая управлять устройством. Далее, имеется большой и масштабируемый веб-сервер, который знает все устройства в сети и умеет с ними работать. Он предоставляет веб пользовательским итерфейс (WEB-UI), которым работают пользователи. Клиент такой системы может быть на любой платформе - главное, чтоб был браузер, а что это будет не важно - ПК, Android, iPhone, что угодно.

И вообще пусть Accessor::Read() сразу принимает указатель на uint8_t, раз уж он по-uint8_t-шно читает.

Согласен.

[ar__systems]

Почему нет? БОльшую часть встроенного приложения можно успешно тестировать на ПК - модульные тесты рулят. На целевой платформе нужно тестировать тоько низкоуровневый код, работающий непосредственно с железом. Тестирование на целевой платформе должно быть сведено к разумному минимуму.

+1. При грамотном проектировании прикладная часть прекрасно отлаживается на компе.