Релиз встраиваемой системы реального времени Embox 0.4.1

Поздравляю!

1 апреля вышел

Специально подгадали? А то у нас тут сегодня трэш и угар с никами…

Поздравляю!

Спасибо!

Специально подгадали?

Может быть :)

А то у нас тут сегодня трэш и угар с никами…

Да ники веселые :)

Нововсть феёковая спасибо ХОББИТу, а то бы я лоханулся.

Хм, почему файковая?

Анонимус натужно шутит :)

На ЛОР 1 апреля лучше не заходить. И так весело, а тут ещё шутки шутить админы изволили. Сидел минут 5 думал, что за фигня с ником сделалась. Думал, только у меня такое)). Подловили …

Присоединяюсь к поздравлениям. Успехов проекту и авторам. Проект из списка несбыточных мечт. Никогда я не доберусь его пощупать. А интерес гложет.

а что с никами?

Ты разве не видишь, что ты теперь цХЕКпУК?

Присоединяюсь к поздравлениям. Успехов проекту и авторам.

Спасибо!

Ники, то отображаются нормально, То какая то кириллическая чушь :)

День смеха же:)

Меня обделили. Пойду в ООН жаловаться. Весь день ники нормально показывает. И только под вечер наткнулся на обсуждение нововведения. Я в шоке. Видимо я слишком саарикхту обидел, когда говорил, что его кои7 (или 8?) нигде ненужен.

У вас тот баг с отсутствием проверки на NULL про который я в прошлой новости упоминал Релиз встраиваемой системы реального времени Embox v0.4.0 (комментарий) до сих пор не исправлен.

У тебя случаем не установлен lorify-ng? Просто у меня тоже все нормально с никами. Еще возможно из-за uBlock Origin с включенным игнорированием косметических фильтров.

Спасибо за напоминание.

Да не исправили. Как Вы сами отметили нужно разобраться поподробнее со стеком.

Вообще проверка на ноль никак не проявляется и следовательно особо не мешает. Меня лично больше заботит ваш комментарий.

Тут к нам попытались затащить js на основе проекта duktape и может быть всякие stack_push_str влияют.

Мы исправили две или три ошибки которые были описаны в комментариях к предыдущей новости, а ваша к сожалению оказалась более серьезной. Не могли бы Вы завести issue, чтобы мозолила глаз? Ну, или я заведу, чуть позже.

Еще раз спасибо, за баг репорт!

А есть для ESP8266 и ESP32?

К сожалению нет! Переодически спрашивают, даже купили где-то лежит, но руки не доходят

К сожалению нет! Переодически спрашивают, даже купили где-то лежит, но руки не доходят

Жаль, очень жаль. Хотелось бы что-то поинтереснее micropython'а.

Зачем микропитон, когда есть Си?

Не могли бы Вы завести issue, чтобы мозолила глаз? Ну, или я заведу, чуть позже.

Лучше вы заведите, я сейчас немного занят другими делами, да и к тому же вы с кодовой базой лучше знакомы. Может быть закоммичу исправление, если будет время и желание.

Зачем микропитон, когда есть Си?

Зачем мне дрочево с Си, когда есть микропитон?

Лучше вы заведите

Хорошо!

Может быть закоммичу исправление, если будет время и желание.

Спасибо!

Зачем мне дрочево с Си, когда есть микропитон?

Почему вы отвечаете вопросом на вопрос?

Использование питона и прочих скриптовых языков в микроконтроллерах я считаю плохой идеей по причине низких вычислительных ресурсов самого контроллера, малого объема ОЗУ и ПЗУ. А от скриптовых языков много оверхеда.

Использование питона и прочих скриптовых языков в микроконтроллерах я считаю плохой идеей по причине низких вычислительных ресурсов самого контроллера, малого объема ОЗУ и ПЗУ. А от скриптовых языков много оверхеда.

Частично соглашусь.

Почему частичто. Мы тут как раз запилили, lua с сетью на STM32 (скоро статью выложим), для чего это нужно, просто прототипы очень легко клепать с помощью скриптовых языков. Но в продакшене конечно такому не место.

С другой стороны упомянутый ESP32 в принципе встроенный интерпретатор micropython имеет, и для энтузиастов это вполне себе хорошее решение.

240 мгц и 512 кб озу есть куда реально использовать? Да и микропитон очень экономичный.

240 мгц и 512 кб озу есть куда реально использовать?

Конечно есть, например c Embox в эту память уместили аж целый SIP телефон :)

Зачем?

240 мгц и 512 кб озу есть куда реально использовать?

Конечно есть. Вполне можно найти этим ресурсам более разумное применение, чем затраты на интерпретацию питонового байткода. Было б интересно посмотреть сравнение производительности, ну скажем, AES-128 на этом питоне и на Си.

Конечно есть, например c Embox в эту память уместили аж целый SIP телефон :)

STM32F7 это прям очень жирно, SIP телефон можно реализовать на куда более скромных ресурсах, если постараться. Я вот ковырял либу https://github.com/creytiv/re и из нее просто утаскивал разные функции, вот даже есть свидетельства этому Как правильно посчитать HMAC_SHA1 для SRTP пакета? - например функцию srtp_derive я оттуда утащил https://github.com/creytiv/re/blob/38e17f90870c02bed4e50ee883372a1932a4cb67/s....

Для меня в Embox будет слишком много лишнего, я вижу что у вас всякие позикс-совместимые штуки, загрузка ELF файлов, какие-то интерпретаторы, мне это совершенно не нужно, какого-нибудь FreeRTOS вполне достаточно (да и то, можно без нее обойтись).

Но видимо суть этого Embox в том, чтоб можно было на контроллеры легко портировать существующий POSIX-совместимый софт от более мощных ЭВМ, пусть даже ценой определенных накладных расходов - для определенных применений вполне оправдано

Офигенный файлик. И это еще называется опенсорс?

https://raw.githubusercontent.com/embox/embox/v0.4.1/src/arch/e2k/boot.S

У них же ассемблер засекречен, что вы хотели? Даже если б там были мнемоники ассемблера, документации на них в открытом доступе нет, так что формально это такая же проприетарщина будет

Про эту часть мы написали в статье (Раздел «Пара технических вопросов»). Все что нам известно об этом мы рассказали. К сожалению, в Эльбрусе все закрытое, а то что мы нарыли (см. другие статьи и код в репозитории) было сделано почти в слепую.

В принципе, какое то описание ассемблера (инструкций) отдают под подписку о неразглашении.

У нас же поддержаны прерывания это описано в статье или контекст свитч описано в статье. Они на ассемблере, но кроме набора команд, нужно еще и хоть какого то понимания архитектуры, у Эльбруса она нетривиальная.

Но Вы правы в том, что МЦСТ похоже видит в политике закрытости какой то смысл.

Зачем?

Простите, что «зачем».

Вероятно потому что если у аппаратуры меньше ресурсов она:

• во первых, стоит дешевле,
• во вторых, меньше потребляет,
• в трьетьих, надежнее.

Этого недостаточно?

Есть какие-то реальные данные сравнения производительности micropython'а и си?

Но Вы правы в том, что МЦСТ похоже видит в политике закрытости какой то смысл.

Да ладно бы закрытость, они например не выкладывают в свободный доступ исходники пропатченного ими GNU binutils (там например есть objdump с дизассемблером, емнип)

Да кстати, бинарники компилятора и бинутилсов можно оттуда http://212.59.102.250/opensource/heap/instrumental/toolchains/spo-20/cross/ скачать

Файл /lcc-1.20.17.e2k-generic.3.14/binutils/bin/e2k-linux-objdump - явно основан на иcходниках GNU Binutils (лицензия GNU GPL v3), исходников нет

alexanius, почему исходников GNU Binutils для Эльбрусов нет?

STM32F7 это прям очень жирно, SIP телефон можно реализовать на куда более скромных ресурсах, если постараться. Я вот ковырял либу https://github.com/creytiv/re и из нее просто утаскивал разные функции, вот даже есть свидетельства этому Как правильно посчитать HMAC_SHA1 для SRTP пакета? - например функцию srtp_derive я оттуда утащил https://github.com/creytiv/re/blob/38e17f90870c02bed4e50ee883372a1932a4cb67/s….

Сколько у Вас в итоге получилось потребление ОЗУ, если не секрет? Я к тому, что в SIP телефоне должны быть реализованны как минимум две подсистемы, IP стек и аудио подсистема (вход выход). обе эти подсистемы требуют буферов. Добавляем к этому все остальное, многозадачность, синхронизация, какая то файловая подсистема и так далее.

Для меня в Embox будет слишком много лишнего, я вижу что у вас всякие позикс-совместимые штуки, загрузка ELF файлов, какие-то интерпретаторы, мне это совершенно не нужно, какого-нибудь FreeRTOS вполне достаточно (да и то, можно без нее обойтись).

Это все можно подключить по требованию. Пока не подключите ничего подобного не будет. В статье Показана работа приложения на 8кб ОЗУ цитата из статьи.

На самом деле, характеристики STM32VL позволяют запустить Embox с этой игрой и с вытесняемыми потоками: 8кб RAM и 128кб flash.

Ну и видео работы можно посмотреть. Еще мы запускались на EFM32zg там вообще 32кб ПЗУ и 4 кб ОЗУ. Правда из функционала там была конандная строка с одной или двумя командами.

Но видимо суть этого Embox в том, чтоб можно было на контроллеры легко портировать существующий POSIX-совместимый софт от более мощных ЭВМ, пусть даже ценой определенных накладных расходов - для определенных применений вполне оправдано

Да Вы правы, не только портировать, но и позволяет сначала разработать и отладить на Linux, а потом перенести на любую аппаратную платформу. И да Вы правы, определенные накладные расходы при этом есть. Просто идея Embox, сделать их достаточно маленькими.

Вот к примеру, приведенный Вами подход к SIP телефону. В библиотеке есть протоколы RTP, SIP, и так далее. Есть даже версия с шифрованием, но нужен еще аудио стек и IP стек. IP стек LWIP, но с аудио подсистемой прийдется повозиться. Плюс сколько Вы сделаете ошибок, ведь это будет новое ПО. В случае Embox берем уже готовые решения, например, можете использовать libre, если не хотите PJSIP, отлаживаете по максимуму на Linux (или сразу в qemu на Embox). И затем переносите на целевую платформу, причем затраты на перенос вполне умеренные.

Безусловно, Embox избыточен если требуется помигать лампочкой, но если нужно помигать лампочкой под управлением интернета, то уже можно задуматься, хотя тут может проще использовать FreeRTOS. Но при переходе на более сложный уровень, использование Embox, очень даже обоснованно. Baremetal можно сделать, но затраты с увеличением функционала растут экспоненциально. Да и про переносимость не стоит забывать.

Есть какие-то реальные данные сравнения производительности micropython’а и си?

Не знаю, может и есть, но зачем они Вам. Я говорил, что на micropython нельзя реализоавть SIP телефон влезающий в 512 Кб ОЗУ. То есть я не сравнивал производительность, скорее затраты на память.

Более того, я считаю применение скриптовых языков оправданным, например для прототипирования.

Сколько у Вас в итоге получилось потребление ОЗУ, если не секрет? Я к тому, что в SIP телефоне должны быть реализованны как минимум две подсистемы, IP стек и аудио подсистема (вход выход). обе эти подсистемы требуют буферов. Добавляем к этому все остальное, многозадачность, синхронизация, какая то файловая подсистема и так далее.

Оно там еще не закончено до конца, да и там не совсем SIP, в качестве сигнального протокола применяется (S)MQTT, но вообще это можно и на SIP сделать, просто не люблю я парсить текстовые протоколы.

Ну в целом там как получается - есть звуковой чип, он по I2S отдает звук с микрофона и одновременно воспроизводит (притом с DMA), передача звуковых семплов в кодек из контроллера и передача из кодека в микроконтроллер происходит синхронно, там еще два кольцевых буфера, один под микрофон, другой под то что надо воспроизвести. В обработчике прерываний от I2S он напрямую читается-пишется. Еще есть поток, который периодически мониторит кольцевой буфер с семплами от микрофона, и если на буфере с микрофона накопилось достаточно байтов чтоб его в RTP отправить по сети, он берет и отправляет (хотя наверное в обработчике прерываний можно что-то такое хитрое сделать, чтоб планировщик сразу же по выходу из прерывания прыгал куда надо, но это сложно). Ну и там когда прилетает RTP пакет, срабатывает код который его записывает в очередь на воспроизведение с динамика.

какая то файловая подсистема и так далее.

Какая-то файловая подсистема тут по-моему совершенно не требуется

alexanius, почему исходников GNU Binutils для Эльбрусов нет?

Пользователи, которые их запрашивают исходники получают.

Могу ли я запросить исходники, раз я скачал бинарники из http://212.59.102.250/opensource/heap/instrumental/toolchains/spo-20/cross/ ? Или мне надо обязательно иметь у себя дома работающий Эльбрус? Зачем запрашивать, почему бы их просто не выложить открыто, чтоб кто угодно мог скачать?

Могу ли я запросить исходники, раз я скачал бинарники из http://212.59.102.250/opensource/heap/instrumental/toolchains/spo-20/cross/ ?

Если есть документ, подтверждающий поставку оборудования, то да. МЦСТ не занимается поставкой ПО как такового.

Или мне надо обязательно иметь у себя дома работающий Эльбрус?

Да.

Зачем запрашивать, почему бы их просто не выложить открыто, чтоб кто угодно мог скачать?

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

Ну значит МЦСТ нарушает условия GNU GPL v3, поздравляю вас с этим.

Ну значит МЦСТ нарушает условия GNU GPL v3, поздравляю вас с этим.

Какие?

Такие, что вы не предоставляете мне исходный код, хотя у меня есть бинарник.

abondarev может Вы выложите исходники GNU Binutils для Эльбрусов куда-нибудь на гитхаб? Или вам их тоже не дают? Или может NDA запрещает?

Такие, что вы не предоставляете мне исходный код, хотя у меня есть бинарник.

Можно представить конкретный пункт лицензии, который нарушается?

Во-первых вот ссылка на FAQ: https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic

The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.

But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.

Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.

Непосредственные цитаты из текста лицензии GNU GPL v3 https://www.gnu.org/licenses/gpl-3.0.en.html

6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.

b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.

c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.

d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.