Ну и да. Если у контроллера 190К ОЗУ (это не считая 2М флэша) — уже можно подумать на тему работы с динамической памятью, если быстродействие не сильно поджимает. А если ещё и припаяно 8М SDRAM — и подавно. Есть такая макетка от ST, а у меня на столе есть и реальная плата с ОЗУшкой такой. То есть, динамическая память — это, конечно, зло (так как время работы операций new и delete неизвестно, а также возможна фрагментация адресного пространства), но кому она нравится — почему бы и не воспользоваться ею? На свой страх и риск. Но само собой, это всё вторично. Первична — именно структурированность кода.
В целом — внутренние разработки на микроконтроллерах, мы теперь делаем на базе своей ОС. Причём не везде нужно ядро, но драйверы нужны везде. Идея драйверов позаимствована у Константина Чижова и его библиотеки mcucpp. Результирующий код получается сверхоптимальным без каких-либо усилий со стороны прикладного программиста.
Сейчас поддерживается один язык и три компилятора. Само собой, «прошивка» собирается одним компилятором. Но исходники можно скормить одному из трёх.
В целом — все RTOS подобного уровня собираются монолитно с приложением. Мы решили пойти тем же путём. Начинать лучше с реальных вещей, а уже потом — расширять, по мере надобности.
И ещё. Объектно ориентированный подход чаще всего используется с динамической моделью выделения памяти.
В дальнейших частях будет глава о том, что динамическое выделение и ОС реального времени — две вещи несовместных. Но не будем забегать вперёд. В целом, ООП здесь — это скорее методика организации классов. А объекты этих классов достаточно просто либо раскидать по глобальной памяти и стеку, либо — выделить в куче при инициализации системы.
В общем, от ООП мы взяли именно организацию. Скажем, меня всегда бесила функция потока. Её надо знать, в неё можно передать только один параметр. А в нашей ОС — функция потока является всего лишь виртуальной функцией, которую можно перекрыть, а в классе потока можно хранить что угодно. Но опять, я-то знаю дальнейший текст… Предлагаю дождаться его…
Итого — ООП здесь для структурированности. И потому что виртуальные функции — это здорово. Они тоже придают структурированности (это чтобы не было желания уйти в дебри, что структуры есть и в чистых Сях).
А когда начнётся описание драйверов — там ещё будут шаблоны, которые не только не усложняют результирующий ассемблерный код, но и здорово его оптимизируют…
По поводу истории, падающей в Outlook — можно обойти дополнительной софтинкой — Historage. Сохраняет историю и показывает в том же окне линка. Работает, удобно. grovety.com/products/historage
Сейчас выложили ещё одно приложение (сохраняет историю в Skype for Business) в Windows Store: https://www.microsoft.com/ru-ru/store/p/historage/9pdd46kq9w77
Спасибо за отзыв!
Надеемся, что наш опыт Вам поможет )
В феврале думаем выложить ещё пару приложений, посмотрим что изменится в процедуре, обязательно напишем.
Кстати, ссылка на само приложение в магазине. Но пригодится только тем, у кого есть Skype for Business
Алексей, еще раз спасибо! Сегодня наше приложение появилось в Windows Store (https://www.microsoft.com/ru-ru/store/p/easyly-corp/9nblggh4v7n6 ). С 13 сентября бились )
Decker, нашли подходящий вариант? Очень интересно.
Сейчас делаем сервис, который Вы описываете — клиент может писать «откуда угодно», а оператор отвечает «откуда удобно» — в том числе из Телеграм, но всё ещё «сильно в процессе».
Черновик видео по продукту здесь: https://youtu.be/9saqPDSwuhM
Это оно? ))
Спасибо!
Алексей, спасибо за статью!
Не так давно мы тоже «связались» с Windows Store — ну, как «не так давно», уже год пытаемся опубликовать наше десктопное приложение. Дело движется, вроде MS дали такую возможность с августа этого года.
Но выложить сконвертированное приложение так и не выходит:
— Мы создали APPX.пакет нашего приложения.
— Попробовали загрузить, получаем ошибки:
a. Package acceptance validation error: You don't have permissions to specify the following namespaces in the appx manifest file of the package EasyLy.s.appx: http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities
b. Package acceptance validation error: Your developer account doesn’t have permission to submit apps converted with the Desktop App Converter at this time
Может быть есть опыт, как получить эти права? Или что мы делаем неверно?
Спасибо!
Мы пилим свое приложение для SfB, которое уже решило эти проблемы. 19-го сентября выйдет очередная бета, к 3 октября планируем релиз.
Если интересно, старые версии есть на сайте, но работает нестабильно, да и новый вариант будет работать чуть по другому принципу…
Пожалуйста! За вопрос спасибо — он сложный.
С AppSDK ещё толком не работали, но, судя по тому, что пишут на msdn, он действительно мало что умеет.
UCWA, там, насколько я помню, нет шаринга и видео, по работе на мобильных — не пробовали, нужно смотреть.
UCMA точно не заработает, библиотек на смартфоны нет.
Есть Xavy SDK – Damaka, но насколько поддерживается проект и его работоспособность не знаю. Вот ссылка на их приложение из гугла (https://play.google.com/store/apps/details?id=com.damaka.ucc.XavySP.ui) и sdk (http://damaka.com/xavy/xavysdk.jsp)
ОК, понял, спасибо! Да, мы это не учли — правим. Исправленное окно авторизации будет вместе с новой версией (без супрешн мода). Я тогда здесь напишу, когда выйдет.
Спасибо! да, мы рискнули.
— потрогать можно (и даже приветствуется), склад версий здесь
Сейчас решили уйти от Supression mod, EasyLy и S4B работают параллельно, но мы Мы скрываем все окна Lync (кроме окна Conversations) вручную, при помощи изменений ключей реестра и при помощи методов WinAPI, пользователь их не видит. Эта версия ещё не выложена, доводим до ума — часть шоустопперов удалось таким образом обойти.
перспективы open source — пока не думали, вряд ли.
— опыт с Server SDK — есть (в другом продукте — Support Center Software), если есть интерес, то можно описать
В целом — внутренние разработки на микроконтроллерах, мы теперь делаем на базе своей ОС. Причём не везде нужно ядро, но драйверы нужны везде. Идея драйверов позаимствована у Константина Чижова и его библиотеки mcucpp. Результирующий код получается сверхоптимальным без каких-либо усилий со стороны прикладного программиста.
В целом — все RTOS подобного уровня собираются монолитно с приложением. Мы решили пойти тем же путём. Начинать лучше с реальных вещей, а уже потом — расширять, по мере надобности.
В дальнейших частях будет глава о том, что динамическое выделение и ОС реального времени — две вещи несовместных. Но не будем забегать вперёд. В целом, ООП здесь — это скорее методика организации классов. А объекты этих классов достаточно просто либо раскидать по глобальной памяти и стеку, либо — выделить в куче при инициализации системы.
В общем, от ООП мы взяли именно организацию. Скажем, меня всегда бесила функция потока. Её надо знать, в неё можно передать только один параметр. А в нашей ОС — функция потока является всего лишь виртуальной функцией, которую можно перекрыть, а в классе потока можно хранить что угодно. Но опять, я-то знаю дальнейший текст… Предлагаю дождаться его…
Итого — ООП здесь для структурированности. И потому что виртуальные функции — это здорово. Они тоже придают структурированности (это чтобы не было желания уйти в дебри, что структуры есть и в чистых Сях).
А когда начнётся описание драйверов — там ещё будут шаблоны, которые не только не усложняют результирующий ассемблерный код, но и здорово его оптимизируют…
grovety.com/products/historage
для простых задач.
Надеемся, что наш опыт Вам поможет )
В феврале думаем выложить ещё пару приложений, посмотрим что изменится в процедуре, обязательно напишем.
Кстати, ссылка на само приложение в магазине. Но пригодится только тем, у кого есть Skype for Business
Сейчас делаем сервис, который Вы описываете — клиент может писать «откуда угодно», а оператор отвечает «откуда удобно» — в том числе из Телеграм, но всё ещё «сильно в процессе».
Черновик видео по продукту здесь: https://youtu.be/9saqPDSwuhM
Это оно? ))
Спасибо!
Не так давно мы тоже «связались» с Windows Store — ну, как «не так давно», уже год пытаемся опубликовать наше десктопное приложение. Дело движется, вроде MS дали такую возможность с августа этого года.
Но выложить сконвертированное приложение так и не выходит:
— Мы создали APPX.пакет нашего приложения.
— Попробовали загрузить, получаем ошибки:
a. Package acceptance validation error: You don't have permissions to specify the following namespaces in the appx manifest file of the package EasyLy.s.appx: http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities
b. Package acceptance validation error: Your developer account doesn’t have permission to submit apps converted with the Desktop App Converter at this time
Может быть есть опыт, как получить эти права? Или что мы делаем неверно?
Спасибо!
Если интересно, старые версии есть на сайте, но работает нестабильно, да и новый вариант будет работать чуть по другому принципу…
С AppSDK ещё толком не работали, но, судя по тому, что пишут на msdn, он действительно мало что умеет.
UCWA, там, насколько я помню, нет шаринга и видео, по работе на мобильных — не пробовали, нужно смотреть.
UCMA точно не заработает, библиотек на смартфоны нет.
Есть Xavy SDK – Damaka, но насколько поддерживается проект и его работоспособность не знаю. Вот ссылка на их приложение из гугла (https://play.google.com/store/apps/details?id=com.damaka.ucc.XavySP.ui) и sdk (http://damaka.com/xavy/xavysdk.jsp)
— потрогать можно (и даже приветствуется), склад версий здесь
Сейчас решили уйти от Supression mod, EasyLy и S4B работают параллельно, но мы Мы скрываем все окна Lync (кроме окна Conversations) вручную, при помощи изменений ключей реестра и при помощи методов WinAPI, пользователь их не видит. Эта версия ещё не выложена, доводим до ума — часть шоустопперов удалось таким образом обойти.
перспективы open source — пока не думали, вряд ли.
— опыт с Server SDK — есть (в другом продукте — Support Center Software), если есть интерес, то можно описать