www.open-tager.ru http://www.open-tager.ru/forum/ |
|
Система Caustic http://www.open-tager.ru/forum/viewtopic.php?f=5&t=4128 |
Страница 99 из 108 |
Автор: | Pingvin [ 19 янв 2017, 06:38 ] |
Заголовок сообщения: | Re: Система Caustic |
Я вот хочу попробовать все таки разбить проект на функциональные библиотеки. Пользователю оставить только главный цикл с игровой логикой и API функции библиотек. Это же удобно - подключаешь библиотеку в проект, инклюдиш хедер - и пользуйся. Но тямы пока не хватает. Как решается вопрос, если нужно присвоить значение глобальной переменной из либы, а переменная объявлена в коде пользователя? Через указатель? Можно ли симофоры отдавать из либы, если симофоры у нас объявлены как глобальные переменные в коде пользователя? Может объявить их глобальными переменными в либах, а в коде пользователя объявить как extern? Как реализовывать callback функции? Буду искать, пробовать... И вообще - иметь набор библиотек для различных железяк, которые можно легко подключить к любому проекту - разве плохо? Порог вхождения в сообщество "прошивкописателей" снизился бы. Эдакая лазертаг-ардуино... Пробовал вчера собрать Андроид приложение из проекта Каустик - что то ему не понравилось, версия чего то там... |
Автор: | Alexies [ 19 янв 2017, 13:08 ] |
Заголовок сообщения: | Re: Система Caustic |
LTagKirov писал(а): Код для передачи пакетов по радио через nrf пока не смотрел, насколько он изолирован от железа радиомодулей, трудно ли его будет переделать на другие чипы, например LoRa ? Код полностью изолирован. "Сетевой уровень" с одной стороны работает через интерфейс с радиомодулем, с другой - через интерфейс с "клиентом сети". Единственное ограничение - пока что размер пакета захардкожен в 32 байта (как у NRF), но это просто число, его можно поменять. Вот интерфейс физического уровня. Можно создать новый класс, работающий с другим радиомодулем и наследующий этот интерфейс, и подсунуть его "сетевому уровню". (Тут некоторые вещи лишние, я ещё немного упрощу интерфейс) Код: class IRadioPhysicalDevice : public IInterrogatable { public: using DataReceiveCallback = std::function<void(uint8_t/* channel*/, uint8_t*/* data*/)>; using TXDoneCallback = std::function<void(void)>; constexpr static unsigned int defaultRFPhysicalPayloadSize = 32; virtual ~IRadioPhysicalDevice() {} virtual void printStatus() = 0; virtual UintParameter getPayloadSize() = 0; virtual void setDataReceiveCallback(DataReceiveCallback callback) = 0; virtual void setTXDoneCallback(TXDoneCallback callback) = 0; virtual void setRXAddress(uint8_t channel, uint8_t* address) = 0; virtual void setTXAddress(uint8_t* address) = 0; virtual void sendData(uint8_t size, uint8_t* data) = 0; }; Вот интерфейс "клиента сети". Клиент проверяет адрес, ему ли пакет, предоставляет адрес обратной связи и обработчик пакета. Код: class INetworkClient { public: virtual ~INetworkClient() {} virtual void connectNetworkLayer(NetworkLayer& nl) = 0; virtual void connectPackageReceiver(IPackageReceiver* receiver) = 0; /// Test if device address is acceptable virtual bool isForMe(const DeviceAddress& addr) = 0; /// Returns address for ack sending from virtual const DeviceAddress* mainBackAddress() = 0; /// Returns callback that will process given payload of package, accepted by isForMe() virtual ReceivePackageCallback getReceiver() = 0; /// Send package using connected network layer virtual PackageId send( DeviceAddress target, uint8_t* data, uint16_t size, bool waitForAck = false, PackageSendingDoneCallback doneCallback = nullptr, PackageTimings timings = PackageTimings() ) = 0; }; Вся работа с очередью пакетов на передачу и на прием, посылке подтверждения приема, повторной пересылке и т.п. лежит на плечах "сетевого уровня", он тут: https://github.com/DAlexis/caustic-lase ... -layer.hpp |
Автор: | Alexies [ 19 янв 2017, 15:20 ] |
Заголовок сообщения: | Re: Система Caustic |
Pingvin писал(а): Я вот хочу попробовать все таки разбить проект на функциональные библиотеки. Пользователю оставить только главный цикл с игровой логикой и API функции библиотек. Это же удобно - подключаешь библиотеку в проект, инклюдиш хедер - и пользуйся. То, что вы описываете - это нормальная архитектура любого проекта, а не какая-то особая идея. Любой хороший код состоит из библиотек (статических, или просто пар .c/.h), максимально изолированных друг от друга (а ещё на эти библиотеки пишут юнит-тесты, советую ознакомиться). Парадигма ООП развивает такой подход дальше: есть объекты, и пользователь их использует. Объекты можно подключать друг к другу, заставлять взаимодействовать через интерфейсы. Именно так в Caustic и сделано. Просто берем класс, например, отвечающий за парсинг MilesTag2, подсоединяем к нему класс, принимающий ИК-сигнал с одной стороны и класс, обрабатывающий "системные вызовы" с другой, и готово, всего несколько строк на стороне пользователя, и заработал датчик. Хотим зоны поражения - ещё один уровень абстракции, пара интерфейсов - и снова 10 строк кода активируют всё, что нужно. Если говорить таким языком - просто возьмите мой код. Там всё уже сделано, разделено на библиотеки и изолировано. Разве только не скомпилировано в отдельные статические либы (хотите - можно разделить на либы, это тривиально, но ухудшает компактность прошивки на выходе). Насчет одного "главного цикла", в котором "пионер" напишет "игровую логику" - это только самую простую игровую логику получится описать. Для сложной нужна асинхронная обработка множества событий, несколько стейт-машин (aka конечных автоматов). Для этого нужны свои уровни абстракции, фреймворки. Иначе получится адский спагетти-код. Чтобы научиться строить правильную архитектуру приложения (даже самого простого), нужно знать и уметь применять основные шаблоны проектирования (design patterns) для данного языка и нужен опыт. ИМХО, где-то после сотни тысяч строк написанного кода приходит понимание, и архитектура становится нормальной. В целом написать правильно структурированную программу проще на C++, чем на C. Для того его и придумали. Pingvin писал(а): Но тямы пока не хватает. Как решается вопрос, если нужно присвоить значение глобальной переменной из либы, а переменная объявлена в коде пользователя? Через указатель? Во-первых, должен быть самый минимум глобальных переменных в любом коде. Каждая глобальная переменная увеличивает связанность разных частей программы непрозрачным образом. Ну и много других причин, почему не должно быть глобальных переменных. Если либа должна использовать внешнюю переменную, лучше передать в либу указатель на неё на стадии инициализации. Либа будет хранить указатель приватно (в static-переменной). Тогда глобальной переменной не будет, и из кода инициализации либы будет явно следовать: либа использует вот эту вот переменную, и все. На худой конец можно определить переменные в этой либе, а снаружи брать их через extern. Тогда при линковке они будут взяты из того места, где определены. Pingvin писал(а): Можно ли симофоры отдавать из либы, если симофоры у нас объявлены как глобальные переменные в коде пользователя? Может объявить их глобальными переменными в либах, а в коде пользователя объявить как extern? Семафоры - это такие же переменные, с ними всё то же самое можно делать. Просто посмотрите, как они реалиованы во FreeRTOS, благо кода не много. Pingvin писал(а): Как реализовывать callback функции? Буду искать, пробовать... Если хотите писать принципиально на чистом C, то коллбэки - это просто функциональные указатели, про них есть много где информация. Если все-таки на C++, то правильнее использовать функторы (std::function<>). Про это тоже много где написано. Pingvin писал(а): И вообще - иметь набор библиотек для различных железяк, которые можно легко подключить к любому проекту - разве плохо? Порог вхождения в сообщество "прошивкописателей" снизился бы. Эдакая лазертаг-ардуино... На самом деле любой проект X в идеале представляет из себя X-ардуино, даже если там нет микроконтроллера Про это писал выше. Мой проект вполне себе ардуина - просто берем и используем классы, как хотим. Так, например, я за короткое время сделал контрольную точку без копипасты кода, описав только логику её работы и использовав классы, написанные ранее (правда сейчас временно забросил точку за более интересными задачами) Pingvin писал(а): Пробовал вчера собрать Андроид приложение из проекта Каустик - что то ему не понравилось, версия чего то там... Если правильно понял - там в сообщении об ошибке появляется что-то типа ссылки - кликайте на неё, и среда сама установит нужные компоненты. |
Автор: | Pingvin [ 19 янв 2017, 16:41 ] |
Заголовок сообщения: | Re: Система Caustic |
Error:(1, 0) Cause: com/android/build/gradle/AppPlugin : Unsupported major.minor version 52.0 Может я его неправильно импортировал? Мне что интересно... Что из себя карта представляет для позиционирования? Растровая картинка с привязкой к координатам? Или векторная? Или какой-нибудь готовый сервис? |
Автор: | LTagKirov [ 19 янв 2017, 17:07 ] |
Заголовок сообщения: | Re: Система Caustic |
Alexies писал(а): Чтобы научиться строить правильную архитектуру приложения (даже самого простого), нужно знать и уметь применять основные шаблоны проектирования (design patterns) для данного языка и нужен опыт. Что больше всего раздражает в типичном программном АПИ ?! Нельзя вызывать функции как попало - важен порядок вызова функций(а это надо читать доки, которых может и не быть ), нельзя обратится к методу класса не создав его экзкмпляр и тд. А по идее это "бред" искуственный барьер пока недостаточно параметров(данных) для работы процедуры - почему она вообще вызывается и выдаёт результат? Компутер "умный, пусть сам и думает": АПИ нужен более высокого уровня: "насовали" данных в произвольном порядке, как всё что нужно насобиралось - замок сработал - вышел результат. Успех ардуино примерно к такому уровню и приближается, вызвали один раз инициализацию, а дальше можно вызывать функции как попало. А когда 100500ый класс без класса имени2513, имени5613 и ещё 200500шт разных классов-родителей не работает: это не АПИ, а сплошное упражнение Где почитать как проектировать такие АПИ, какие паттерны здесь использовать ? Сейчас продвигают всякие реактивные, событийные и прочие модели, а вот серьёзных работ по классификации событийных шаблонов/паттернов/событийных моделей для ООП что-то несильно наблюдается... Alexies писал(а): Насчет одного "главного цикла", в котором "пионер" напишет "игровую логику" - это только самую простую игровую логику получится описать. Тогда как прокоментируете факт существования ПЛК ? Почему тогда у больших контор получается продавать ПЛК и делать на них весьма сложные промышленные системы ? Типичный ПЛК это явно выделенный "главный цыкл" + "событийные обработчики". Цитата: Мой проект вполне себе ардуина - просто берем и используем классы, как хотим. Практически желаемая лазертаг-библиотека и есть самый настоящий ПЛК-фреймворк: есть определённый список железных устройств и функций работы с ними, новых интерфейсов не понадобится пока железо не поменяется. Логику поведения выделить в отдельный модуль, а все обвёртки-классы спрятать от "пионеров" настолько глубоко как только возможно.
|
Автор: | Alexies [ 20 янв 2017, 16:01 ] |
Заголовок сообщения: | Re: Система Caustic |
Pingvin писал(а): Error:(1, 0) Cause: com/android/build/gradle/AppPlugin : Unsupported major.minor version 52.0 Может я его неправильно импортировал? Странно. Версия Android Studio последняя? Под какой операционной системой пробуете? Pingvin писал(а): Мне что интересно... Что из себя карта представляет для позиционирования? Растровая картинка с привязкой к координатам? Или векторная? Или какой-нибудь готовый сервис? Стандартный гугловский виджет для отрисовки карт и разных слоев поверх карт. Источником может быть и google maps, и любой другой онлайн-сервис, и локальные карты, и картинка с привязкой по координатам. Вот для начала: https://developers.google.com/maps/docu ... tart?hl=ru (как делать что-то такое на Qt - понятия не имею). Гугловскую карту можно стилизовать, как захочется. Вот так примерно пока выглядит приложение: Вложение: Экраны статистики и карты.png [ 149.61 KiB | Просмотров: 9422 ] Пока-что так сделано: цвет маркера игрока каждый игрок может задать любым, цвет ободка - цвет команды. У мертвых пропадает ободок. Но это чисто для прототипа, потом будут красивые пиктограммы. |
Автор: | Pingvin [ 20 янв 2017, 17:07 ] |
Заголовок сообщения: | Re: Система Caustic |
Любопытно! |
Автор: | Alexies [ 20 янв 2017, 17:37 ] |
Заголовок сообщения: | Re: Система Caustic |
LTagKirov писал(а): Что больше всего раздражает в типичном программном АПИ ?! Нельзя вызывать функции как попало - важен порядок вызова функций(а это надо читать доки, которых может и не быть ), нельзя обратится к методу класса не создав его экзкмпляр и тд. И не говорите Чтобы управлять автомобилем, нужно завести машину, нажимать разные педали по ситауции, переключать передачи и ещё одновременно крутить руль. Вот меня очень раздражает, что для поворота вправо приходится крутить руль вправо, а не откидывать сиденье назад. Также не нравится, что нельзя из машины выйти два раза подряд не заходя в неё. А то, что машину ещё нужно сначала купить (создать экземпляр класса) - ну просто бесит LTagKirov писал(а): Компутер "умный, пусть сам и думает": АПИ нужен более высокого уровня: "насовали" данных в произвольном порядке, как всё что нужно насобиралось - замок сработал - вышел результат. Успех ардуино примерно к такому уровню и приближается, вызвали один раз инициализацию, а дальше можно вызывать функции как попало. А когда 100500ый класс без класса имени2513, имени5613 и ещё 200500шт разных классов-родителей не работает: это не АПИ, а сплошное упражнение Если бы любое программирование с готовым АПИ можно было свести к "насовыванию данных в произвольном порядке", мир бы был другим. Программировать вообще говоря сложно. Нужно иметь как минимум подходящее образование и опыт. LTagKirov писал(а): Где почитать как проектировать такие АПИ, какие паттерны здесь использовать ? Сейчас продвигают всякие реактивные, событийные и прочие модели, а вот серьёзных работ по классификации событийных шаблонов/паттернов/событийных моделей для ООП что-то несильно наблюдается... Не замечал, чтобы кто-то активно продвигал это. Событийное и реактивное программирование стары, как мир и используются для решения определенных задач несколько десятилетий. Как лучше реализовывать событийную модель на ООП - можно посмотреть на примере boost::asio и Qt. Не сказал бы, что есть какие-то принципиальные трудности. Просто берем принципы ООП и решаем с их помощью задачу событийного программирования. А вообще, чтобы научиться программировать "правильно", нет рецепта "прочитать эту и ту книги". Нужно поработать в большом проекте с хорошим кодом, пообщаться с более опытными коллегами, а не вариться в собственном соку. Я другого пути не знаю, сам именно так учился и учусь. |
Автор: | LTagKirov [ 20 янв 2017, 18:48 ] |
Заголовок сообщения: | Re: Система Caustic |
Alexies писал(а): в большом проекте с хорошим кодом, пообщаться с более опытными коллегами, а не вариться в собственном соку. К сожалению сок получается хоть и нЕ собственный, но не очень то и вкусный, какой бы хороший код не был То что делатся на работе это промышленная муть, и занимаемся мы этим только из необходимости зарабатывать деньги, выбираем инструменты не те которые захотим, а те которые использует мейнтстрим, текущие производственные процессы создания ПО(да написание программ за деньги это ремесло и не более), чтобы любого 25летнего программиста "из-за забора, по объявлению" можно было побыстренькому прибавить в проект, прогнав по списку установленных абревиатур. Контингент весьма забавный, они так смешно и горячо обсуждают архитектуру, патТерны, мартиновфаулеров и тд, а на самом деле это всё чепуха и наняты они только чтобы перепродать их труд немножко дороже Может быть в стартапах немножко по другому, не знаю не работал. Через пару-тройку лет ООП станет не модным и все шаблоны и бусты положат на дальнюю полочку, а они 25летние кроме общения с опытными коллегами своих идей не имели и остались никем Alexies писал(а): А то, что машину ещё нужно сначала купить (создать экземпляр класса) - ну просто бесит. Вопрос про ПЛК вы всё-таки проигнорировали ) Вот бы там найти хотя-бы парочку функций выделения памяти, сборщиков мусора, создания экземпляров классов, библиотечку boost::asio или следы Qt - ничего из этого нет, может где-то внутри и есть, но снаружи всё спрятано Программирование это не цель, а средство достижения результата. Программировать сложно только потому что инфраструктура для программирования создаётся для программистов и программистами, а у них мозги не для нормальных людей сделаны, "онижбольные" ) В случае ПЛК потребителями являются не программисты, а те кто решает конкретную задачу для народного хозяйства, и результат получается гораздо более приятный. Программировать вообще говоря сложно. Цитата: Чтобы управлять автомобилем, нужно завести машину, нажимать разные педали по ситауции, переключать передачи и ещё одновременно крутить руль. Если бы любое программирование с готовым АПИ можно было свести к "насовыванию данных в произвольном порядке", мир бы был другим. К этому нужно стремится и это возможно - автомобили Тесла ездят по реальным дорогам! Итак, Для кого мы пишем лазертаг-прошивку для личного пользования (спрятать в шкаф), для программистов или для простых людей которые иногда захотят добавить парочку функций в игровой процесс ?ЗЫ. Сейчас на казённом оборудовании балуюсь FPGA вариантом лазертага, в академических целях, занимательно получается, очень "вкусный сок" хоть никто и не оценит, зато творчество так сказать |
Автор: | Pingvin [ 20 янв 2017, 18:52 ] |
Заголовок сообщения: | Re: Система Caustic |
Map Viewer (QML) http://doc.qt.io/qt-5/qtlocation-mapviewer-example.html ArcGIS Runtime SDK for Qt https://developers.arcgis.com/qt/ https://www.google.ru/url?sa=t&rct=j&q= ... 4172,d.bGs https://youtu.be/h-felfjzhw0?t=1098 |
Страница 99 из 108 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |