No, I expect that someone is just being clever. At startup, the USB device generates an init event. The author then brings up everything that is needed.
Out of the various people I have done a sanity check with, everybody agrees that malloc should not be called in an ISR. I’ll see what I can do about writing it up and sending a message to ST. Thanks, Andrei > On 2017-December-11, at 19:12, Joel Sherrill <j...@rtems.org> wrote: > > > > See cpukit/libcsupport/src/malloc_deferred.c. It is definitely returning NULL > because > you shouldn't malloc from an ISR. malloc() is a non-deterministic operation. > I am > surprised that code was designed to do that. > > Perhaps this code assumes the USB interrupt is serviced from a thread. The raw > interrupt unblocks a thread to run this code. > > --joel > > On Mon, Dec 11, 2017 at 6:36 PM, Mr. Andrei Chichak <gro...@chichak.ca > <mailto:gro...@chichak.ca>> wrote: > (sorry if this ended up on the Devel list.) > > I’m working with ST’s HAL USB stack, and to initialize the various > structures, they use a USB interrupt as a trigger. > > In this interrupt, they malloc some space for a descriptor (504 bytes). > > The RTEMS malloc always returns 0. > > Is there a guard against calling malloc in an interrupt context? > > I managed to get around the problem by doing a static allocation, but I was > just wondering. > > > Andrei > > _______________________________________________ > users mailing list > users@rtems.org <mailto:users@rtems.org> > http://lists.rtems.org/mailman/listinfo/users > <http://lists.rtems.org/mailman/listinfo/users>
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
