den_po

Менеджер памяти обычно не знает, расположение чего он знает. Без правки хотя бы части операционки (тоже костыль) "посмотреть на ходу что где находится и чем и насколько зянято" (выделенную операционкой память) вы не сможете, вы узнаете только, что есть вот столько-то выделенных кусочков памяти. Жду от вас пару поучительных историй о том, как вам на практике безмерно помогло подобное знание. Нередко многократное пересоздание объектов операционки нафик ненужно. В этом случае именно отказ от использования кучи позволит сэкономить. Ну да, ну да, стоит взять менеджер памяти, и сразу памяти станет завались. Вы опять, как и в другой дискуссии, придумываете за меня, о чём я думаю. Я не предлагаю полностью отказаться от менеджера памяти. У меня есть проекты с ним, частично с ним (куча используется только внутри FreeRTOS) и вообще без него. Но если есть возможность обойтись без него там, где он нафик не нужен, я буду этой возможностью пользоваться.

Так пользуйтесь теми вариантами, к которым вы привыкли. Оттого, что ВЫ будете говорить операционке, где хранить данные, контроль над данными не уменьшается, а даже наоборот, ведь структуры FreeRTOS от пользователя скрыты, а значит и добраться до внутренних данных, выделенных операционкой, можно только через костыли. Никто ничего не убирал. Вместо одного способа стало три - динамическое выделение памяти функциями FreeRTOS, динамическое выделение пользователем, выделение компилятором (с подсказкой пользователя, конечно). В одном случае я могу узнать, что перестал влезать в допустимый объём памяти, только после запуска, а в другом на этапе сборки. Вы же не будете спорить, что чем раньше обнаружится проблема, тем лучше?

Ничего не мешает. Просто присутствует иногда лишняя сущность. Глупости же. То был ответ на "посмотреть на ходу что где находится и чем и насколько зянято". Смотреть, что где находится, теперь не обязательно "на ходу". И это действительно удобно. В остальном абсолютно ничего не мешает ВАМ смотреть то же самое точно так же, как вы делали с динамическим выделением. Да и использовать статические буферы вас никто не заставляет. Чем же на сосне динамическое выделение внутрях FreeRTOS, по-вашему, так сильно превосходит статическое? Затем, что удобней. Можно раньше проблему найти.

Лично я ждал эту фишку как раз ради объектов, которые живут вечно. Но и удалить тоже ничто не мешает. Или я чего-то не знаю? .map, отладчик Отличное приобретение. Особенно когда оно помогает распределять память на этапе сборки.

УРА!

Это если речь о конструкторах глобальных объектов или статических членов классов. А выше разговор шёл об использовании new. Обычно достаточно снять галочку возле "main"

Если IAR - ограниченная версия, то в техподдержке вроде как пошлют. Всякоразные баги IAR (а таких действительно хватает) иногда лечатся отключением оптимизации.

Будут

а что там, собственно, решать? void* operator new(size_t sz) { return pvPortMalloc(sz); } void* operator new[](size_t sz) { return pvPortMalloc(sz); } void operator delete(void* p) { vPortFree(p); } void operator delete[](void* p) { vPortFree(p); } void* operator new(size_t size, void* p) { (void)size; return p; } void* operator new[](size_t size, void* p) { (void)size; return p; } void operator delete(void*, void*) { } void operator delete[](void*, void*) { }

0?

Ещё есть хорошая штука - astyle, которая форматирует исходники (бесценно, когда получаешь исходники от иных мастеров), а ещё умеет и конец строки заменять.

Не увидел в цитатах ничего про то, кому требуется.

Хм. А разве pragma required не перед определением используется?

#define ABS_WORD(x) (*((volatile uint16_t*)x))

Как это не умеют?

Года 3 назад делал библиотеку шаблонов для LPC 2119/2368/2468. Кому-то такие объявления могут показаться избыточными, но мне самому пользоваться очень нравилось. CPU::WATCHDOGTIMER<> wdt( CPU::PLL::PeriodToTicks(10), CPU::WATCHDOGTIMER<>::DEBUG ); CPU::TIMER<0> ustimer( CPU::PLL::FreqToTicks(1000000) ); CPU::CALLBACKTIMER<1, MEASURETIMERCB, IRQP_MEASURETIMER> measuretimer( CPU::PLL::FreqToTicks(FADC) ); CPU::GPIO0::PINGROUP<0,2> _uartusb_rx_tx(1); USBQUEYECLASS usbq(115200); CPU::GPIO0::PINGROUP<8,2> _uartrs485_rx_tx(1); CPU::GPIO0::PIN<10> uartrs485_txen(0, CPU::GPIO0::OUTPUT); RS485QUEYECLASS rs485q(19200, 8, RS485QUEYECLASS::EVEN, 1); CPU::GPIO1::PIN<23> disp_d7_busy(0, CPU::GPIO1::OUTPUT); CPU::GPIO0::PIN<13> disp_rs(0, CPU::GPIO0::OUTPUT); CPU::GPIO0::PIN<BUTTON1PIN, CPU::GPIO0::PININVERTED> button1_pressed(0, CPU::GPIO0::INPUT); CPU::GPIO0::PIN<17> spi_sck(2); CPU::GPIO0::PIN<18> spi_miso(2); CPU::GPIO0::PIN<19> spi_mosi(2); CPU::SPI<1> spi(2000000, CPU::SPI<1>::MASTER, CPU::SPI<1>::MSB, 16); AD7656< CPU::SPI<1>, spi, CPU::GPIO0::PIN<5>, adc_st, CPU::GPIO0::PIN<20>, adc_cs1, CPU::GPIO0::PIN<3>, adc_busy1> adc_gen_out; AD7656< CPU::SPI<1>, spi, CPU::GPIO0::PIN<5>, adc_st, CPU::GPIO0::PIN<4>, adc_cs2, CPU::GPIO0::PIN<7>, adc_busy2> adc_gen_excitation; Естественно, пины можно и в рантайме перенастроить. Сейчас выкладывать библиотеку стыдновато, я уже тогда хотел всё переделать =) Для тех камней, на которых сейчас сижу, такого не делал - у иаровского оптимизатора глюки наблюдались, а без оптимизации результат очень печальный. Но может и сделаю когда-нибудь.

V8.2.3 наконец-то включили фикс для ренесасовских 78k

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

В совете же говорится только о макросах, вот и оставляйте в файле только макросы

То есть вы НИКОГДА не использовали иаровский стартап и его же конфиги линкера по умолчанию?

Они оба - один и тот же сегмент. Просто сишный компилятор не знает о нём, если ему не подсказать.

попробуйте добавить: __weak void nvic_wwdg_isr(void);

__segment_begin("CSTACK") __segment_end("CSTACK") и нужно не забыть заранее сделать так: #pragma segment = "CSTACK"

Объявлениями (declaration) функций. Вторая из них заодно и прототип, первая - нет.

Такой синтаксис до сих пор разрешается стандартом, значит это си. В си есть возможность ПЕРЕДАВАТЬ функции любое число аргументов. Как и зачем их ПРИНИМАТЬ в функции (не обязательно написанной на си, к слову) - совсем другой вопрос. Ну покажите уж, где это он строго требует? Не надо за меня решать, что я себе в голову вбил, телепат из вас никакой. Прототипы я вообще не упоминал до прошлого сообщения. Не "можно отключить", а "можно не включать", оно по умолчанию выключено. И не "требование соблюдать стандарт", а "строгие" требования. Ещё раз, объявление функции с пустыми скобками разрешено стандартом. С примечанием об устаревании, но разрешено. А где я говорил, что считаю эти костыли чем-то хорошим? Оно просто есть, и я ничего с этим поделать не могу.