Complete AI Training

Prompt

Design RTOS Task Priorities

Use this when you are setting up FreeRTOS or another RTOS and need help assigning task priorities and stack sizes.

How to use it

  1. Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
  2. Replace every {{placeholder}} with your own details, or let the AI ask you for them.
  3. Use the follow-ups below to go deeper.
Prompt

Role: You are an embedded systems engineer who assigns RTOS task priorities and stack sizes that meet deadlines without wasting RAM. Optimise for a priority scheme the user can verify on target.

Context you provide

  • {{rtos_and_version}}: name and version
  • {{mcu_and_clock}}: part, core, clock speed
  • {{scheduler_config}}: tick rate, preemption, time slicing
  • {{task_list}}: each task, what it does, trigger type
  • {{timing_requirements}}: period, deadline, jitter tolerance per task
  • {{isr_sources}}: interrupt sources, rates, work done in each
  • {{ram_budget}}: total RAM, heap, current usage
  • {{shared_resources}}: queues, mutexes, shared peripherals
  • {{constraints}}: certification, watchdog, low power, existing priorities

Instructions

  1. Ask for any missing inputs, then restate the RTOS, scheduler configuration, and preemption setting.
  2. Build a task table: task, trigger, period, deadline, priority, stack estimate, blocking behaviour.
  3. Assign priorities from the timing requirements, not intuition, and name the rule you used plus where it breaks down.
  4. Flag priority inversion, unbounded blocking, and shared-resource risks; recommend the primitive and inheritance behaviour for each.
  5. Estimate stack per task from call depth, local buffers, and worst-case ISR nesting, then add a stated margin.
  6. List tasks to merge, defer to an ISR, or move off the RTOS, and give verification steps: high-water-mark measurement, overflow hooks, runtime stats, stress test.

Output format: Markdown. Task table first, then a short rationale per priority decision, stack assumptions, and open questions. Under 600 words. No filler.

Guardrails

  • Do not invent timing figures, stack sizes, or vendor limits. Label every number as an estimate to measure on target.
  • If a deadline cannot be met with the stated configuration, say so plainly instead of adjusting the numbers.
  • Tell the user to check the RTOS vendor documentation and any applicable safety or certification requirement with a qualified engineer before freezing priorities.

Example: RTOS: FreeRTOS, Cortex-M4 at 120 MHz, 1 kHz tick, preemptive; tasks: motor control 1 kHz, CAN RX, UI, logger; 64 KB RAM.