[0x435641 0]

столкнулся со странными вылетаниями программы в swi_handler и data_handler

в проекте активно используется динамическая память, Ethernet, USB

долгими мучительными копаниями удалось найти причину - параллельное выполнение сабжевых операторов, которые используются как в основном цикле, так и в прерываниях

 

на данный момент решил вопрос отключением прерываний, если new и delete вызываются вне прерывания

 

в нете не нашел инфы по спицифике использования этих операторов в IAR

 

если кто-то обладает знаниями - просьба поделиться

[Johnny81 0]

Насчет iar - не знаю, gcc - newlib под bare metal содержит нереентерабельные malloc/free (на которых основаны new/delete)

 

У тебя вероятно то же самое.

 

Как вариант, можешь переопределить глобальные new и delete (как обычные, так и для массивов) и лочить прерывания перед вызовом malloc/free.

 

Возможно, в iar есть готовые заглушки, переопределив которые можно добиться реентерабельности

[0x435641 0]

Насчет iar - не знаю, gcc - newlib под bare metal содержит нереентерабельные malloc/free (на которых основаны new/delete)

 

У тебя вероятно то же самое.

 

Как вариант, можешь переопределить глобальные new и delete (как обычные, так и для массивов) и лочить прерывания перед вызовом malloc/free.

 

Возможно, в iar есть готовые заглушки, переопределив которые можно добиться реентерабельности

 

это вероятные догадки... хотелось бы документального подтверждения

[Johnny81 0]

читай доку :)

к иару кстати исходники библиотек прилагаются, посмотри их

[KSN 0]

Почитайте "IAR C/C++ Compiler Compiling and Linking", там и про new и про delete есть. Использование динамического выделения памяти в прервываниях - не лучший вариант с позиции оптимизации. Лучше избегать этого.

[Гость MALLOY2]

это вероятные догадки... хотелось бы документального подтверждения

На странице 390 мануала все написано, что эти функции не реентерабельны. Защищайте их сами семафорами или мутексами ну или свой менагер.

 

REENTRANCY

A function that can be simultaneously invoked in the main application and in any

number of interrupts is reentrant. A library function that uses statically allocated data is

therefore not reentrant.

Most parts of the DLIB library are reentrant, but the following functions and parts are

not reentrant because they need static data:

● Heap functions—malloc, free, realloc, calloc, and the C++ operators new

and delete

● Locale functions—localeconv, setlocale

● Multibyte functions—mbrlen, mbrtowc, mbsrtowc, mbtowc, wcrtomb,

wcsrtomb, wctomb

● Rand functions—rand, srand

● Time functions—asctime, localtime, gmtime, mktime

● The miscellaneous functions atexit, strerror, strtok

● Functions that use files or the heap in some way. This includes printf, sprintf,

scanf, sscanf, getchar, and putchar.

Functions that can set errno are not reentrant, because an errno value resulting from

one of these functions can be destroyed by a subsequent use of the function before it is

read. This applies to math and string conversion functions, among others.

Remedies for this are:

● Do not use non-reentrant functions in interrupt service routines

[0x435641 0]

нашел, спасибо за наводку!

 

выходит при вызове sprintf так же нужно запрещать прерывания(если в них присутствуют new/delete) ???

или здесь имеется ввиду параллельный вызов sprintf из основного потока и прерывания?

Изменено 19 марта, 2013 пользователем 0x435641

[Johnny81 0]

ты не должен вызывать new/delete (malloc/free) прямо или опосредованно одновременно из нескольких потоков. Если ты так делаешь - добавляй средства синхронизации - к примеру запрещай прерывания

[0x435641 0]

>выходит при вызове sprintf так же нужно запрещать прерывания(если в них присутствуют new/delete) ???

>или здесь имеется ввиду параллельный вызов sprintf из основного потока и прерывания?

 

меня интересует сейчас конкретно sprintf. он в основном потоке. я могу в прерывании пользовать new/delete, или тоже синхронизация нужна? в потрохах sprintf не ковырялся

[Гость MALLOY2]

для new/delete синхронизация нужна полюбому, и для sprintf нужна если он вызывается с нескольких мест (задач или прерываний) он может не долько динамичсескую использоватьи татическую тоже дак что new/delete сам посибе и sprintf тоже.

[jcxz 192]

sprintf не использует динамическую память - не надо фантазий.

Но использует много стека, так что использовать его в ISR-ах, имхо, - моветон.

Да и вообще имхо - надо всегда стараться избегать динамической памяти в эмбеддед.

 

для new/delete синхронизация нужна полюбому, и для sprintf нужна если он вызывается с нескольких мест (задач или прерываний) он может не долько динамичсескую использоватьи татическую тоже дак что new/delete сам посибе и sprintf тоже.

Тоже фантазии. sprintf не использует ни динамическую ни статическую память, все хранит в автоматической, т.е. - полностью реерентерабелен. Но объём на стеке использует большой.