Перейти к содержанию
    

Не могу собрать проект 'Hello Wirld !'

странно: этот кусок скрипта остался от freeRTOS- овского. Я его не менял потомучто не понял к чему это...

 

Так судя по тому, что у вас в проекте не было заглушек, в нём не использовался printf? Вот поэтому и работало наверное.

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

 

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

 

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

 

 

нет: как ругался на функцию

int putchar(int ch)

так и продолжает

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

 

init/serial.c:90: error: expected identifier or '(' before '--' token

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

Может наведёте на примерчики простеньких программ (желательно с printf) под gcc. На сайте atmel чтото всё под кеил да под иар.. Может ещё где видели. Чтото не подворачивается ничего. Мало информации..

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

----

попробовал так:

int main( void )
{
char a[100];
int i = 0;

       lowlevel_init();
       serial_init();

       serial_putc ('1');
       putChar('2');


sprintf(a, "Hello World !!");

putChar('3');

while(a[i])
  putChar(a[i++]);

putChar('4');

 

 

результат:

## Starting application at 0xA0000000 ...
123Hello World !!4

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

 

PROVIDE( _heap = _end );

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Вот мой рабочий проект под stm32, я как раз разбирался с printf:

printf_test_09_09_23_23_27_53.rar

 

Попробуйте сделать такую же отладочную выдачу как в main.c (функция show_linker_vars() ).

Ну и в _sbrk() тоже. Сразу увидите, что не так. По крайней мере, мне это помогло:)

 

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

 

-----

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

 

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

Исправил на

    .bss :
    {
        . = ALIGN(4);
        _sbss = .;
         *(.bss)
         *(.bss.*)
         *(COMMON)
        . = ALIGN(4);
        _ebss = .;
        _end = .;
        __end = .;
    } >RAM

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И в этом самодельном _write() - таки вызывается putChar().
А, прошу прощения. :) Я поначалу не заметил, что это putChar, а не putchar...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну это уже мелочи. Добавьте к проекту вот это: stf_syscalls_minimal.rar

 

Кстати, это я взял как раз из какого-то примера под FreeRtos...

ИМХО, недавно нашёл более прямой способ (при использовании newlib):

При линковке добавить -lnosys

и в скрипте линкера добавить

PROVIDE ( end = _end );
Тогда не нужно ваш файл цеплять к проекту.

 

Ну и ещё очень полезным оказался ключик:

LDFLAGS += --specs=nano.specs

Посмотрел исходники ScmRtos:

Чтобы с LTO собиралось стоит поправит стартап файл в части таблицы векторов, добавив used:

__attribute__ ((used, section(".isr_vector")))

Хотел спросить зачем вы переименовали стандартные имена обработчиков векторов и дали им нестандартные имена?

void PendSVC_ISR(void);

void SystemTimer_ISR(void);

Я потратил массу времени пытаясь понять почему не вызывается SysTick_Handler...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ИМХО, недавно нашёл более прямой способ (при использовании newlib):

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

Ну и ещё очень полезным оказался ключик:

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

Чтобы с LTO собиралось стоит поправит стартап файл в части таблицы векторов, добавив used:

Хотел спросить зачем вы переименовали стандартные имена обработчиков векторов и дали им нестандартные имена?

В примерах для F2xx и F4xx это уже есть.

ЕМНИМС, имена поменял не я, а ST:) Я взял их из какого-то совсем старого ST-шного стартапа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

О, появилась реализация заглушек в тулчейне? В каком?
4.7.4 с launchpad.net

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

 

Как там должен называться putchar()?

Есть ли в _sbrk() проверка на перекрытие кучи и стека?

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

 

Насколько я понял, это пока не портабельно. А где можно почитать, что это даёт?
В доке на newlib. Использует nano реализацию newlib, у меня чуть-ли не минус 15К с проекта ушло.

Проблем с портабельностью пока не встретил.

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4.7.4 с launchpad.net

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

arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.7.4 20130613 (release) [ARM/embedded-4_7-branch revision 200083]
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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

   text       data        bss        dec        hex    filename
  29692       2244        600      32536       7f18    ./exe/hello-stm32-printf.elf
   6720        236        552       7508       1d54    ./exe/hello-stm32-printf.elf

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

Проблем с портабельностью пока не встретил.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

    LDFLAGS = 
    LDFLAGS += $(patsubst %,-L%,$(EXTRALIBDIRS))
    LDFLAGS += -nostartfiles
    LDFLAGS += -nodefaultlibs
    LDFLAGS += --specs=nano.specs
    LDFLAGS += -Wl,--relax
    LDFLAGS += -Wl,--gc-section
    LDFLAGS += -Wl,--static
    LDFLAGS += -Wl,--start-group
    LDFLAGS += -lm -lc -lgcc -lnosys
    LDFLAGS += -Wl,--end-group
    LDFLAGS += -T$(LINKER_SCRIPT_FILE)
    LDFLAGS += -Wl,--Map=$(TARGET).map,--cref

 

--specs=nano.specs работает прекрасно

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

без
    LDFLAGS += -u _printf_float

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

 

Ну вот, например, kgp-тулчейн не знает ничего про --specs=nano.specs.
У него видимо newlib не той системы вкрячен:)

Это решается его пересборкой.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...