Hi @EdwinHz ,
Thank you for the clarification. However, I must admit I find this position somewhat surprising.
In many professional environments, strict compilation settings such as -Werror, -Wextra, and even static analysis tools are standard practice for production firmware, not just for robustness but also for compliance, safety, and long-term maintainability. Under these conditions, the SDK drivers in their current form do not build cleanly, which makes their direct use problematic.
While I understand that some warnings may not indicate functional defects in evaluation scenarios, they can still represent real risks in production contexts, especially when code is integrated into larger systems with stricter quality requirements. Treating them as “unconsequential” shifts the burden entirely onto the user, who must then audit, patch, or fork vendor code to meet basic build policies.
Could you please clarify NXP’s intended positioning of these drivers?
Are they meant only as reference implementations for evaluation?
Is there any plan to provide production-quality builds that are warning-clean under common strict flags?
What is the recommended approach for customers who need to use the SDK in safety-critical or high-reliability products?
Rewriting or maintaining private patches for core drivers significantly increases engineering cost and undermines the value of an official SDK. Clear guidance on best practices for production use would be very helpful.
Best regards,
Max