xvr

Сам процессор ничего на стеке не сохраняет. Что сохраните вы при входе в прерывание зависит только тот вас 🙂 Смотрите в коде обработчика прерывания вашей ОС, что она сохраняет.

Google lens умеет переводить с катринки

Может немного оффторик, но лучше всего AVR c PCI сопрягать как в том анекдоте: Могу посоветовать синюю изоленту 🙂

Да, действительно. Но он и на -O0 умудряется что то наоптимизировать 😞 https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Ваши вопросы аналогичны вопросу "Хочу самую бьструю и маневренную машину. Подскажите, какого цвета должен бьть салон?" Размеры и скорость программы зависят то компилятора (а он один - GCC для Tensilica) и опций компиляции, и не зависят от среды. Если для обращения к переферии используется библиотека, то максимальная частота ногодрыга будет зависить от библиотеки, и практически не будет зависить от самого процессора. Если вам важна скорость, то переходите на ассемблер. Что касается Ардуино, то это ещё один слой библиотек поверх IDF - он скорости точно не прибавит, но прибавит дружелюбности IDE. Решайте, что вам важнее - скорость или удобство разработки. Лично я для ESP8266 писал программы прямо в командной строке (точнее в FAR'е), и ничего, всё работало. Что касается отладки, то стандартное средство - gdb (все IDE - это обвёрки вокруг него). ESP32 подключается к нему через JTAG (через аппаратный адаптер на FT232 например + OpenOCD). Не уверен, что у ESP8266 есть JTAG (давно это было) У GCC по умолчанию -O2 кажется (если не -O3 вообще)

Поставьте logrotate

Пункты 1 и 2: template<class Type> struct TypeTraits {}; template<> struct TypeTraits<float> {using IntAType = int;}; template<> struct TypeTraits<double> {using IntAType = long long;}; template<typename T> void CalcSinCos(T a, T &s, T &c) // a должно быть больше 0 и меньше 1 { const int BL = ((sizeof(T)==4))?24:53; typename TypeTraits<T>::IntAType IntA = 0; ... }

Это SPIKE - до недавнего времени использовался как golden симупятор. Недавно в этом качестве стал использоваться QEMU - https://www.qemu.org/docs/master/system/target-riscv.html

USB PD (https://www.usb.org/usb-charger-pd) не оно?

Я помню тему где человек собирался делать свой процессор. Причём он собирался выращивать монокристалический кремний для подложек кристаллов на подоконнике и делать маски для литографии на лазерном принтере. Вот не помню, полетела ли его конструкторская мысль дальше - к собственно литографии и легированию.

Самый главный - это ручное присваивание ID полям сообщения. Приходится следить за всеми полями вручную. Второе уже упоминал - ручное отслеживание backward compatible изменений (если они нужны). В остальном одни плюсы

В мою бытность работы в Яндекс насмотрелся на оба формата. Первый закапывали, переходили на второй. BSON в частности применяется в MongoDB Protobuf применялся повсюду (я работал в Картах, у них для связи клиентской программы и бэкэндов везде он). Из преимуществ автоматические биндинги в любые языки программирования и возможность делать расширения уже существующих протоколов в back compatible виде (но это не автоматом - требуется тщательное ручное вмешательство) Ну и стандартизированное описание форматов.

Всё придумано до нас: http://bjson.org/ https://developers.google.com/protocol-buffers И не надо велосипеды изобретать

Именно. Yield и вызывает переключение контекстов. Откуда он при этом пришёл все равно. Мог из таймера, мог из нити исполнения. Этот порт поддерживает только вложенность yield прерывания в чего угодно (в том числе и в другие прерывания). Вложенность других прерываний друг в друга не поддерживает (да их там и нет - один таймер, нечему вкладываться) Полная поддержка вложенности прерываний подразумевает возможность произвольной вложенности (на любую глубину) любых прерываний (возможно с некоторыми ограничениями в виде приоритетов). Возможна ограниченная поддержка в виде групп прерываний, при этом группы могут как то вкладываться друг в друга (у вас как раз такая). yield - одна группа, остальные прерывания - вторая. В некоторых других портах FreeRTOS есть полная поддержка вложенных прерываний. Например в ESP32 - там есть отдельный стек для ядра и отслеживание уровня вложенности прерываний. Можете посмотреть, для общего развития 🙂

В том же самом, что и для не вложенных. Даже больше - это одно и тоде сохранение контекста. Ваш код влоденные прерывания не поддерживает 😞 Манипуляции с контекстом находятся в файле ISR_Support.h - это макросы portSAVE_CONTEXT/portRESTORE_CONTEXT и portYIELD_SAVE/portYIELD_RESTORE (при этом само сохранение находится в макросах _gpctx_load/_gpctx_save в файле ctx.S) Первая пара (portSAVE_CONTEXT/portRESTORE_CONTEXT) используется для прерываний из которых нельзя стелать таск свитч. Эти макросы не перключают стек, и всё было бы хорошо, но они сохраняют и восстанавливают стек поинтер через одну глобальную переменную - uxSavedTaskStackPointer. Соотвественно вложенное прерывание перепишет эту пременную и менее вложенное прерывание снесёт стек к чертям :( Вторая пара макросов при входе в прерывание переключает стеки процессов при входе/выходе. Отдельный стек для ядра вообще не используется - ядро пасётся на стеке текущего процесса. В общем, если убрать uxSavedTaskStackPointer (заменить стеком или вообще убрать - не совсем понятно для чего указатель стека сохраняли, он не должен меняться) то наверное вложенные прерывания будут работать Нет, там только yield

В port.c нет никаких вложенных прерываний. Да, особенность архитектуры FreeRTOS. Контекст сохраняется при входе в прерывание, и восстанавливается при выходе. Других мест сохранения/восстановления нет. Поэтому для переключения задач нужно войти в прерывание (иначе контект текущей задачи не сохранить и контект другой не восстановить)

Немного поторопились с советом - через пару недель теме как раз год бы исполнился 🙂

Протоколу HTTP - 26 лет. Как то не попадает он под 'новомодные штучки'

SDCC - бесплатно

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

Вкратце - если вы не понимаете, зачем они нужны, то они вам не нужны 🙂 К ним приходят с другой стороны - когда совсем прижмёт, что без них никак, тогда и начинают разбираться. Их использование очень часто вызывает головную боль разработчика, а уж портирование в RTOS - вообще постоянную мигрень. Не только На пальцах всё очень просто - одни прерывания могут возникнуть во время обработки других. Дальше начинаются детали - Обработчики прерываний более не атомарны Время обработки прерывания становится менее детерминированно Если есть стеки прерываний, то придётся заводить разные стеки либо делать более изощрённое переключение стеков RTOS в принципе должна понимать, что прерывания у неё могут вложиться друг в друга Плюс один - более критичные по времени прерывания будут обрабатываться с минимальной и более детерминированной задержкой

А где ТС её брать будет? По ссылке '0 in Stock'. Ну и по ресурсам она впритык (хотя это самое простое - сделать схему и попробовать отсинтезировать - синтезатор сам скажет, подойдёт или нет)

20 десятичное (в org) это 14 в хексе (как в листинге). так что всё правльно

Если у вас gcc еще рекомендую поставить -Og gcc умдряется даже на -O0 что то наоптимизировать

Всё у вас как просили - первая команда по запрошенному смещению. А то, что метка до него - так вы .org после метки поставили 🙂