[defunct 0]

Наползание стека на данные это одна из самых трудновылавливаемых ошибок при программировании МК.

Дык возникает она потому что

делают маленький стек

В отличие от Heap'а и его проблем фрагментации, для стека где фрагментация впринципе невозможна (по природе LIFO) - объем можно оценить еще до run-time.

Помножить это число на два, и будет щастье. Если посчитать заранее тяжело - заполнение стек памяти патерном, прогон программы с последующим дампом памяти для оценки использования стека в run-time тоже никто не отменял.

 

Много ли толку от менеджера, когда в heap нет блока требуемого объема и менеджер возвращает NULL? А "гениальный программист" привыкший, что на PC память есть всегда, даже не соизволит проверить что вернул этот malloc, и сразу начинает туда что-то писать?

[demiurg_spb 0]

А "гениальный программист" привыкший, что на PC память есть всегда, даже не соизволит проверить что вернул этот malloc, и сразу начинает туда что-то писать?

Да, да. Я читал где-то что по современным веяниям проверять на NULL malloc и иже с ним - моветон.

Причём и с аргументациеё всё вроде как чики-поки... Но всё это естественно в контексте ПО под ПК.

[rezident 0]

defunct, было бы хорошо, если все было бы так просто. Только в топике речь шла вроде про embedded-программирование, где априори ОЗУ маловато, мало или совсем мало. :laughing:

[defunct 0]

defunct, было бы хорошо, если все было бы так просто. Только в топике речь шла вроде про embedded-программирование, где априори ОЗУ маловато, мало или совсем мало. :laughing:

Дык, куда уж проще, чем совсем без heap'а, когда ОЗУ априори маловато, мало или совсем мало ;>

Heap на мой взгляд, имеет хоть какой-то маломальский смысл когда в наличии есть хотя бы 32KB ОЗУ, и то только для объектов с большИм и очень большИм временем жизни.

[MrYuran 18]

Спасибо, теперь работает float и строки и целые числа, и места много не занимает :) :)

Может кому пригодится uselib.zip

Интересно, и как же флоат выводится, если там вот что:

case 'f':
    
    break;

Вчера коллега пыхтел весь день.

Пытался в mspgcc полномерный флоат вывести.

Попробовал ваш вариант, потом от Сергея Борща, потом ещё что-то...

Я ещё глянул было в avr-libc, но там своя специфика, макросы доступа к флеши на асме написаны.

Хотя конечно можно переопределить..

В конце концов установили из закромов IAR и начали потрошить его либы

 

Float вообще в IAR не выводит, после обработки в массиве пусто

Там есть "переключатель скоростей", поищите галочку в настройках.

По умолчанию printf обрезанный.

[skripach 5]

IAR float32 без проблем.

[fox1 0]

Добрый день ! Кто нибудь использует sprintf с выводом float с MSPGCC ???

В IARе все работает ...

Но не в MSPGCC .......

 

потрошу либы IARа .....

Код огромный ....

Куча definов .....

И все равно на выходе нули .... хотя и в формате ......

[demiurg_spb 0]

Включите в makefile поддержку расширенной printf.

Примерно так:

# Floating point printf version (requires MATH_LIB = -lm below)
PRINTF_LIB_FLOAT = -Wl,-u,vfprintf -lprintf_flt
# If this is left blank, then it will use the Standard printf version.
PRINTF_LIB = $(PRINTF_LIB_FLOAT)
MATH_LIB = -lm

 

[fox1 0]

Включите в makefile поддержку расширенной printf.

Примерно так:

# Floating point printf version (requires MATH_LIB = -lm below)
PRINTF_LIB_FLOAT = -Wl,-u,vfprintf -lprintf_flt
# If this is left blank, then it will use the Standard printf version.
PRINTF_LIB = $(PRINTF_LIB_FLOAT)
MATH_LIB = -lm

 

Не поможет ....

В исходниках нет поддержки sprintf для float ....

 

http://mspgcc.bzr.sf.net/bzr/mspgcc/mspgcc...tf.c?remember=3

 

ch=='f' нет .....

[demiurg_spb 0]

Понятно.

Тогда поищите по форуму.

Недавно тут кто-то искал/предлагал подходящие Вам исходники, было вроде как в ветке про ARM, точно не помню.

[Wano 0]

Малость не в тему. Смотрю человек работает с текстовым LCD. МЭЛТ я не использовал, но пробовал 3 других типа от разных производителей. Стандартная либа в codevision-е рано или поздно повисала. Писал сам. Через пару годиков в Keil-е использовал их примерчик, аналогичная проблема. Неясно почему , но через некоторое время(минуты-часы) busy флага можно ждать пока свет закончится. Может шум, может ещё чего, спасает реинит. А когда sprintf идёт прям перед выводом на экран, всегда кажется, что косяк в sprintf - экран же работает (так было у меня на avr-е).

 

p.s. Сейчас ,наверно, посыпятся сообщения типа : да у меня годами работает и ничего и тд...

 

[fox1 0]

Ну вобщем ... взломался printf с float от IARа ... даже работает с mspgcc ... полный набор ... тяжеловат конечно ...

жаль получился не совместим со стандартным printf от mspgcc ...

[koluna 0]

Столкнулся с определенными проблемами, используя маленький и слабенький процессор.

Немного поковырялся, обобщил результаты и решил вставить свои 5 копеек :)

 

При сборке проекта (процессор STM32F100C4), содержащего вызов стандартной библиотечной функции sprintf() линковка не удается по двум причинам:

- Отсутствуют некоторые системные функции (ошибка ”undefined reference to `_sbrk'” или ей подобные).

- Код не помещается во FLASH.

 

Первая проблема обусловлена тем, что в тулчейнах для встраиваемых систем отсутствуют требуемые системные функции ( https://sourceware.org/newlib/libc.html#Syscalls ), которые необходимы для работы библиотеки newlib (эти функции обеспечиваются полноценной ОС). Их необходимо реализовать самостоятельно или взять готовый вариант ( http://electronix.ru/forum/index.php?showt...mp;#entry651990 ).

 

Вторая проблема обусловлена нехваткой FLASH памяти выбранного микроконтроллера, ”объемной” реализацией функции sprinft() и всего, что с ней связано. Поэтому оптимальное решение в сложившейся ситуации - поиск менее ”объемного” варианта этой функции.

 

Протестировал несколько вариантов функций sprintf() от различного производителя :)

Тестирование проводилось с помощью простого приложения, написанного на языке C с использованием библиотеки SPL. Приложение осуществляет циклический вывод форматированной строки через USART микроконтроллера. Результаты тестирования приведены ниже (перечислены не все секции выходного файла). В итоге было установлено, что наиболее ”легкий” вариант реализации функции sprintf() от ChaN.

 

Функции sprintf() в стандартных библиотеках тулчейнов бывают в нескольких вариантах (или просто разные функции или разные библиотеки, часто с ограниченным функционалом). Часто функции, реализованные в стандартной библиотеке, требуют приличного количества ОЗУ, поэтому при их использовании необходимо обеспечить достаточный объем для стека (кучи).

 

ПО с использованием стандартной библиотечной функции sprintf().

Чтобы проект собрался пришлось увеличить в скрипте линкера размер региона FLASH до 32 кБ.

.text 27048

.ARM.exidx 8

.data 1436

.bss 80

 

ПО с использованием стандартной библиотечной функции sniprintf().

Это облегченный вариант sprintf(), работающий только с целыми числами.

.text 12092

.ARM.exidx 8

.text.align 4

.data 1436

.bss 80

 

ПО без использования форматированного вывода (без каких-либо функций sprintf()).

.text 1604

.text.align 4

.data 20

.bss 16

 

Реализация от ChaN (целые числа).

http://elm-chan.org/fsw/strf/xprintf.html

.text 2368

.data 20

.bss 28

 

Реализация от Georges Menie (целые числа).

http://www.menie.org/georges/embedded/index.html

.text 7656

.data 1308

.bss 80

 

Доработанный вариант от Сергея Борща (оригинал неизвестен)

http://electronix.ru/forum/index.php?showt...mp;#entry746084

.text 7952

.data 24

.bss 16

 

Вариант от sergey_sva

http://electronix.ru/forum/index.php?s=&am...st&p=746563

.text 13600

.ARM.exidx 8

.data 268

.bss 16

 

makefile и скрипт линкера использовался из комплекта scmRTOS. Тулчейн - Sourcery CodeBench Lite ARM EABI.

 

А, с Новым Годом всех! :)

Изменено 2 января, 2014 пользователем koluna