defunct 0 16 июня, 2010 Опубликовано 16 июня, 2010 · Жалоба Наползание стека на данные это одна из самых трудновылавливаемых ошибок при программировании МК. Дык возникает она потому что делают маленький стек В отличие от Heap'а и его проблем фрагментации, для стека где фрагментация впринципе невозможна (по природе LIFO) - объем можно оценить еще до run-time. Помножить это число на два, и будет щастье. Если посчитать заранее тяжело - заполнение стек памяти патерном, прогон программы с последующим дампом памяти для оценки использования стека в run-time тоже никто не отменял. Много ли толку от менеджера, когда в heap нет блока требуемого объема и менеджер возвращает NULL? А "гениальный программист" привыкший, что на PC память есть всегда, даже не соизволит проверить что вернул этот malloc, и сразу начинает туда что-то писать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 16 июня, 2010 Опубликовано 16 июня, 2010 · Жалоба А "гениальный программист" привыкший, что на PC память есть всегда, даже не соизволит проверить что вернул этот malloc, и сразу начинает туда что-то писать?Да, да. Я читал где-то что по современным веяниям проверять на NULL malloc и иже с ним - моветон. Причём и с аргументациеё всё вроде как чики-поки... Но всё это естественно в контексте ПО под ПК. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 16 июня, 2010 Опубликовано 16 июня, 2010 · Жалоба defunct, было бы хорошо, если все было бы так просто. Только в топике речь шла вроде про embedded-программирование, где априори ОЗУ маловато, мало или совсем мало. :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
defunct 0 16 июня, 2010 Опубликовано 16 июня, 2010 · Жалоба defunct, было бы хорошо, если все было бы так просто. Только в топике речь шла вроде про embedded-программирование, где априори ОЗУ маловато, мало или совсем мало. :laughing: Дык, куда уж проще, чем совсем без heap'а, когда ОЗУ априори маловато, мало или совсем мало ;> Heap на мой взгляд, имеет хоть какой-то маломальский смысл когда в наличии есть хотя бы 32KB ОЗУ, и то только для объектов с большИм и очень большИм временем жизни. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 27 17 июня, 2010 Опубликовано 17 июня, 2010 · Жалоба Спасибо, теперь работает float и строки и целые числа, и места много не занимает :) :) Может кому пригодится uselib.zip Интересно, и как же флоат выводится, если там вот что: case 'f': break; Вчера коллега пыхтел весь день. Пытался в mspgcc полномерный флоат вывести. Попробовал ваш вариант, потом от Сергея Борща, потом ещё что-то... Я ещё глянул было в avr-libc, но там своя специфика, макросы доступа к флеши на асме написаны. Хотя конечно можно переопределить.. В конце концов установили из закромов IAR и начали потрошить его либы Float вообще в IAR не выводит, после обработки в массиве пусто Там есть "переключатель скоростей", поищите галочку в настройках. По умолчанию printf обрезанный. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
skripach 6 17 июня, 2010 Опубликовано 17 июня, 2010 · Жалоба IAR float32 без проблем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fox1 0 7 июля, 2010 Опубликовано 7 июля, 2010 · Жалоба Добрый день ! Кто нибудь использует sprintf с выводом float с MSPGCC ??? В IARе все работает ... Но не в MSPGCC ....... потрошу либы IARа ..... Код огромный .... Куча definов ..... И все равно на выходе нули .... хотя и в формате ...... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 7 июля, 2010 Опубликовано 7 июля, 2010 · Жалоба Включите в 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 8 июля, 2010 Опубликовано 8 июля, 2010 · Жалоба Включите в 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 8 июля, 2010 Опубликовано 8 июля, 2010 · Жалоба Понятно. Тогда поищите по форуму. Недавно тут кто-то искал/предлагал подходящие Вам исходники, было вроде как в ветке про ARM, точно не помню. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Wano 0 9 июля, 2010 Опубликовано 9 июля, 2010 · Жалоба Малость не в тему. Смотрю человек работает с текстовым LCD. МЭЛТ я не использовал, но пробовал 3 других типа от разных производителей. Стандартная либа в codevision-е рано или поздно повисала. Писал сам. Через пару годиков в Keil-е использовал их примерчик, аналогичная проблема. Неясно почему , но через некоторое время(минуты-часы) busy флага можно ждать пока свет закончится. Может шум, может ещё чего, спасает реинит. А когда sprintf идёт прям перед выводом на экран, всегда кажется, что косяк в sprintf - экран же работает (так было у меня на avr-е). p.s. Сейчас ,наверно, посыпятся сообщения типа : да у меня годами работает и ничего и тд... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fox1 0 22 июля, 2010 Опубликовано 22 июля, 2010 · Жалоба Ну вобщем ... взломался printf с float от IARа ... даже работает с mspgcc ... полный набор ... тяжеловат конечно ... жаль получился не совместим со стандартным printf от mspgcc ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koluna 0 2 января, 2014 Опубликовано 2 января, 2014 (изменено) · Жалоба Столкнулся с определенными проблемами, используя маленький и слабенький процессор. Немного поковырялся, обобщил результаты и решил вставить свои 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться