Application entry point and RTOS scheduler startup helpers. More...

Functions
void	ove_main (void)
	Application-defined entry point called after board and console init.

void	ove_run (void)
	End the init phase: lock the heap (zero-heap mode) and launch the RTOS scheduler.

int	ove_app_run (void)
	Platform entry point: initialise the board and then run the application.

void	ove_heap_lock (void)
	Lock the kernel heap after init (zero-heap mode safety net).

Detailed Description

Application entry point and RTOS scheduler startup helpers.

The typical call chain is: platform main() → ove_app_run() → ove_main() → ove_run()

Function Documentation

◆ ove_main()

void ove_main ( void )

extern

Application-defined entry point called after board and console init.

The application must implement this function. It is responsible for creating all RTOS resources (threads, queues, timers, …) and then calling ove_run() to start the scheduler.

Note: This function must not return before calling ove_run().; Object lifetime: anything that worker threads access after ove_main() returns (audio graphs, DSP state, long-lived buffers) must have storage that outlives this function. In C terms: give it static storage class — either a static local or a file-scope static — or allocate it on the heap. Plain automatic locals are popped when ove_main() unwinds; any pointer a worker kept into them becomes dangling. This is the same rule that applies whenever a function hands out a pointer to a local, it's just more visible here because workers outlive the scope. On FreeRTOS the failure is immediate (scheduler reclaims the main stack); on POSIX/NuttX/Zephyr it is latent but still UB.

See also: ove_run, ove_app_run

◆ ove_run()

void ove_run ( void )

End the init phase: lock the heap (zero-heap mode) and launch the RTOS scheduler.

Call this from ove_main() after every static resource has been declared and every boot-time helper task spawned. In zero-heap mode ove_run calls ove_heap_lock immediately before kicking off the scheduler, so any subsequent malloc / kmm_malloc / pvPortMalloc traps via DEBUGASSERT (or returns NULL in test mode). Apps whose runtime structurally requires post-init dynamic allocation (the benchmark suite, dynamic worker pools, etc.) skip ove_run and call ove_thread_start_scheduler directly to opt out of the lock.

On most platforms the scheduler never returns and this function blocks forever.

See also: ove_main, ove_heap_lock, ove_thread_start_scheduler

◆ ove_app_run()

int ove_app_run ( void )

Platform entry point: initialise the board and then run the application.

Called by the platform-specific main() after registering any necessary backends. Internally it performs board and console initialisation and then calls ove_main().

Returns: 0 on success. On most platforms the scheduler never returns so this function never actually reaches its return statement.

See also: ove_main

◆ ove_heap_lock()

void ove_heap_lock ( void )

Lock the kernel heap after init (zero-heap mode safety net).

On RTOSes whose kernel-side static configuration cannot fully eliminate boot-time mm allocations (notably NuttX, where task_create / pthread_create allocate TCBs and stacks from kernel mm), call this after every static resource has been declared. Subsequent kernel allocations trip a DEBUGASSERT and abort the binary, so a stray malloc / kmm_malloc surfaces immediately during testing instead of hiding behind a sized heap.

The function is a no-op on RTOSes whose zero-heap configuration is already provably static (FreeRTOS with configSUPPORT_DYNAMIC_ALLOCATION=0, Zephyr with no kernel heap pool). NuttX implements the lock by setting a flag tested by a --wrap=malloc trampoline in backends/nuttx/nuttx_heap_lock.c.