Так судя по тому, что у вас в проекте не было заглушек, в нём не использовался printf? Вот поэтому и работало наверное.
end - это конец используемой памяти. Начиная с него _sbrk() начинает выдавать свободную память для malloc().

В любом случае - попробуйте, хуже не будет

ЗЫ. . = ALIGN(32 / 8); перед _end = .; не забудьте.



Так вы ж её переименовали вроде? Давайте решать проблемы по очереди Пусть сейчас будет putChar(), тот вариант, который скомпилировался и выдавал циферки, но где не работал printf.


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


Да у меня всё больше под stm32. Но попробую поискать.

нет. Всё тоже: 12висим
----
попробовал так:



результат:


некашерно. но жить уже можно. Вроде раз sprintf работает, то проблемма не в malloc

Далеко не факт. У него там какая-то своя хитрая логика

Я тут посмотрел ещё раз, оказывается я перепутал. В _sbrk() используется не _end, а _heap!

Попробуйте добавить в конец скрипта линкерного



Должно задышать

нет. Всё тоже: 12висим

Да, грустно. У меня закончились предположения.

Вот мой рабочий проект под stm32, я как раз разбирался с printf:
 printf_test_09_09_23_23_27_53.rar ( 56.73 килобайт ) Кол-во скачиваний: 245


Попробуйте сделать такую же отладочную выдачу как в main.c (функция show_linker_vars() ).
Ну и в _sbrk() тоже. Сразу увидите, что не так. По крайней мере, мне это помогло

Да, вспомнил ещё один глюк. У меня не инициализировались инициализированные переменные в стартапе, и в результате heap был сразу не ноль, и поэтому _sbrk() не работал.

-----
А! Вспомнил что было

Короче, этот arm-none-eabi- c ключом -fdata-sections помещает инициализированные переменные не просто в bss, а в bss.имя_переменной. А в линкерном скрипте указано просто (.bss).
Исправил на


Это не ваш случай, у вас нет ключа -fdata-sections, но это так, на всякий случай.

А вам действительно newlib нужен? Если просто printf надо, так возмите какую-нибудь минимальную реализацию, которая инты да строки выводить умеет (гугль -> printf embedded).

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

Если вы действительно используете printf из newlib, то он не имеет никакого отношения к putchar. В newlib printf сделан по-честному - он эквивалентен fprintf(stdout, ...), и бэк-эндом для него является системный вызов write. Соответственно, для использования printf stdout должен содержать открытый для записи поток (newlib-овский stdout допускает прямое присваивание ему значения), а собственно вывод в последовательный порт должен выполняться внутри write.

Не сбивайте человека У него нет системы, потому системный вызов _write() вместе с другими необходимыми системными вызовами пришлось добавлять самому (см. мой аттач к посту №5). И в этом самодельном _write() - таки вызывается putChar().

А, прошу прощения. Я поначалу не заметил, что это putChar, а не putchar...

ИМХО, недавно нашёл более прямой способ (при использовании newlib):
При линковке добавить -lnosys
и в скрипте линкера добавитьТогда не нужно ваш файл цеплять к проекту.

Ну и ещё очень полезным оказался ключик:
Посмотрел исходники ScmRtos:
Чтобы с LTO собиралось стоит поправит стартап файл в части таблицы векторов, добавив used:
Хотел спросить зачем вы переименовали стандартные имена обработчиков векторов и дали им нестандартные имена?
Я потратил массу времени пытаясь понять почему не вызывается SysTick_Handler...

О, появилась реализация заглушек в тулчейне? В каком? Как там должен называться putchar()? Есть ли в _sbrk() проверка на перекрытие кучи и стека?

Насколько я понял, это пока не портабельно. А где можно почитать, что это даёт?

В примерах для F2xx и F4xx это уже есть.
ЕМНИМС, имена поменял не я, а ST:) Я взял их из какого-то совсем старого ST-шного стартапа.

4.7.4 с launchpad.net
Кстати этот тулчейн заметно быстрее собирает проекты инфа.

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

В доке на newlib. Использует nano реализацию newlib, у меня чуть-ли не минус 15К с проекта ушло.
Проблем с портабельностью пока не встретил.

Понятно.
ИМХО стоит привести в соответствие с последним CMSIS'ом.

gcc-arm-embedded? Понятно. Что-то у меня не получилось ничего, ругается на отсутствие _sbrk, _write, _close и проч. (Тестовый проект с printf). Версия вроде свежая:

--specs=nano.specs работает прекрасно (первая строчка без этого ключа, вторая - с ним):

Осталось узнать, что мы при этом теряем

Ну вот, например, kgp-тулчейн не знает ничего про --specs=nano.specs.

Зачем? Всё равно CMSIS-овский стартап не подходит, он не вызывает конструкторы. К тому же, потеряется совместимость с имеющимися проектами.

Странно... У меня не ругается. Да и вы сами можете убедиться что всё это есть в либе libnosys.a.


безтеряем возможность форматировать float.

У него видимо newlib не той системы вкрячен
Это решается его пересборкой.

Дело хозяйское, но лично я бы всё-равно поменял.