โปรเจกต์ที่มีจอกับ SD card มักชวนให้ใช้ SPI bus ร่วมกัน เพราะทั้งสองอย่างมี interface ชื่อนี้ และการเพิ่ม chip select คนละขาก็ดูเหมือนเลือกอุปกรณ์ได้ครบแล้ว แต่พอเรียกจอกับบันทึกไฟล์พร้อมกัน กลับอาจเริ่มเจอข้อมูลผิดหรือบางครั้งเปิดระบบไม่ผ่าน
Chip select เป็นส่วนสำคัญของการเลือกอุปกรณ์ แต่ยังมีเรื่องการตั้งค่าแต่ละ transaction ลำดับเริ่มอุปกรณ์ และพฤติกรรมทางไฟฟ้าของวงจรที่แชร์สัญญาณเดียวกันด้วย การต่อแยกแล้วใช้งานได้จึงยังไม่รับรองว่ารวมกันจะรักษาเงื่อนไขเดิมทั้งหมด
ก่อนเพิ่มการล็อกหรือเปลี่ยน clock ควรทำแผนเจ้าของ bus ให้ชัดก่อนครับ ว่าใครเริ่ม peripheral ใครตั้งค่าอุปกรณ์ และ task ใดมีสิทธิ์ใช้ handle ไหน แล้วค่อยตามหลักฐานของส่วนที่มีปัญหา
SPI แบบที่มีหลายอุปกรณ์ตามรูปแบบทั่วไปใช้สัญญาณ clock กับ data ร่วม และเลือกอุปกรณ์ผ่าน CS ของแต่ละตัว เมื่อไม่ถูกเลือก อุปกรณ์ต้องมีพฤติกรรมที่ไม่รบกวนเส้นร่วมตามข้อกำหนดของมัน รวมถึงวงจรบนโมดูลที่นำมาใช้ด้วย
จึงควรดูทั้ง datasheet ชิปกับ schematic ของ breakout ไม่ใช่เฉพาะรายการขา โมดูลที่มีวงจรแปลงสัญญาณหรือ buffer เพิ่มอาจมีเงื่อนไขของ MISO และการปล่อยสัญญาณต่างจากชิปเปล่า ต้องตรวจว่าร่วม bus ตามที่ออกแบบได้จริง
จำนวนขา CS ที่เหลือเป็นอีกทรัพยากรที่ต้องนับ แต่การเลือก GPIO ยังต้องอยู่ภายใต้ข้อจำกัดของบอร์ดและการบูต ภาพในบทนี้จึงใช้ชื่อ CS-A กับ CS-B แทนการชี้ว่าขาเลขหนึ่งเหมาะกับทุกบอร์ด
เมื่อเพิ่มอุปกรณ์ จำนวนโหลดของสัญญาณกับรูปแบบการเดินสายก็เปลี่ยนไปด้วย การใช้ clock เดิมที่เคยผ่านกับอุปกรณ์เดียวจึงยังต้องตรวจใหม่ในระบบรวม ไม่รับรองระยะสายหรือความเร็วจากชื่อ SPI เพียงอย่างเดียว
อุปกรณ์แต่ละตัวอาจต้องใช้ clock กับ mode ต่างกัน Driver ที่รองรับหลาย device จะมีวิธีผูกค่ากับอุปกรณ์ตาม API ที่ใช้ จึงควรให้ทุกไลบรารีใช้โครงสร้าง bus ที่เข้ากันได้ ไม่ต่างฝ่ายต่างเริ่ม peripheral หรือเปลี่ยนค่าร่วมโดยไม่รู้กัน
ใน ESP-IDF 5.4 SPI Master มีแนว bus กับ device handle ให้จัดอุปกรณ์หลายตัว การแยก handle ช่วยบอกว่า transaction นี้ใช้การตั้งค่าของตัวใด แต่โค้ดที่ครอบอยู่ยังต้องใช้ API และวงจรการส่งให้ตรงตามข้อกำหนด
หากนำไลบรารีจอกับไลบรารี storage คนละชุดมารวม ต้องตรวจว่ารับ bus ที่เริ่มแล้วได้หรือไม่ ใครถือครองการ initialize และทำลาย resource เมื่อจบงาน ไม่สรุปว่าไลบรารีทั้งคู่ใช้ SPI เหมือนกันแล้วจะจัดการร่วมกันเองเสมอ
คำสั่งหนึ่งของอุปกรณ์อาจประกอบด้วยหลายช่วงที่ต้องรักษา CS หรือครอง bus ตาม protocol การล็อกจึงต้องตรงกับขอบเขตที่อุปกรณ์ต้องการ ไม่ปล่อยให้ task อื่นแทรกระหว่างส่วนที่ต้องต่อเนื่อง แล้วหวังว่า byte แต่ละตัวส่งถูกก็จะได้คำสั่งครบ
เอกสาร Espressif สำหรับการแชร์ SPI กับ SD card ระบุเรื่องลำดับ initialization เพราะ card ต้องถูกนำเข้าสู่ SPI mode ให้ถูกก่อนการสื่อสารกับอุปกรณ์อื่นบน bus เดียวกัน พร้อมจัด CS ของอุปกรณ์อื่นให้อยู่ในสถานะ idle ตามกติกา
ถ้าเริ่มคุยกับจอก่อนโดยยังไม่ได้จัดขั้นของ card ให้ถูก card อาจยังอยู่ในโหมดที่ตอบสนองต่างจากที่คาด การสลับลำดับจึงมีผลตั้งแต่ตอนเปิดระบบ ไม่ใช่ปัญหาที่ mutex ระหว่าง task หลังบูตจะแก้แทนได้ทั้งหมด
การทดสอบต้องรวมการตัดแล้วจ่ายไฟใหม่จริงในชุดทดลองตามขอบเขตที่ควบคุมได้ด้วย เพราะการ reset เฉพาะ controller อาจไม่ได้คืนสภาพ card เหมือนเริ่มจากไม่มีไฟ เอกสารมีข้อสังเกตเรื่องการคงโหมดจนถึง power cycle ซึ่งเกี่ยวกับการอ่านผลช่วงนี้โดยตรง
ควรเก็บว่าแต่ละรอบเป็น cold start หรือ reset ส่วนใดไว้กับผล เพื่อไม่ให้การเปิดผ่านหลังจาก card เคยถูกเริ่มแล้วถูกนำไปยืนยันว่าลำดับบูตจากศูนย์ถูกต้องเหมือนกัน
สำหรับ SPI Master ตามเอกสารที่อ้าง การใช้หลาย device ภายใต้เงื่อนไขที่แต่ละ device ถูกเข้าถึงจาก task เดียวมีการรองรับด้าน thread safety แต่ถ้าหลาย task ใช้ device เดียวกัน ต้องมีการจัดการเพิ่มเติมตามแนวทางของ driver
จึงควรกำหนดเจ้าของ handle หรือใช้กลไก serialize ที่เหมาะสม ไม่เข้าใจว่ามี bus driver แล้วทุกโครงสร้างภายในไลบรารีจอหรือ filesystem จะปลอดภัยจากการเรียกพร้อมกันทั้งหมด ขอบเขตของ driver กับขอบเขตของไลบรารีแอปเป็นคนละส่วน
ถ้าใช้การส่งแบบ queue หรือ DMA ยังต้องรักษาอายุของ buffer กับ transaction descriptor จนงานจบตาม API ไม่คืนหรือแก้ข้อมูลที่ระบบยังใช้ส่งอยู่ การมี mutex ครอบเฉพาะตอนเรียกเริ่มไม่ได้ยืนยันว่า resource เหล่านี้ใช้เสร็จแล้ว
ส่วนประสิทธิภาพควรดูเวลาที่อุปกรณ์ครอง bus และงานที่ต้องรอร่วมกัน การส่งภาพยาวชุดหนึ่งอาจทำให้งานบันทึกต้องรอ แม้แต่ละ transaction ถูกต้อง จึงอาจต้องแบ่งงานตามขอบเขตที่ protocol ยอมรับ ไม่ย้ายตัวเลข clock อย่างเดียว
เริ่มจากจอเดี่ยวกับ card เดี่ยวให้ผ่านกระบวนการที่ต้องใช้ แล้วรวมโดยยังเรียกทีละส่วนตามลำดับ ก่อนเพิ่มงานพร้อมกัน วิธีนี้ช่วยแยกปัญหาสัญญาณหรือลำดับเริ่มจากปัญหา concurrency ที่เพิ่งเข้ามาภายหลัง
หากลด clock แล้วอาการเปลี่ยน ให้ใช้เป็นหลักฐานสำหรับตรวจ timing กับโหลดเพิ่ม ไม่สรุปทันทีว่ารู้สาเหตุทางไฟฟ้าครบ หากมีเครื่องมือวัดควรดูสัญญาณจริงร่วมกับข้อกำหนดของอุปกรณ์ และไม่ใช้ waveform วาดขึ้นแทนผล
ในงานทดสอบ storage ใช้ข้อมูลแยกและตรวจไฟล์หลังเขียนด้วย ไม่ดูเพียงว่าฟังก์ชันคืน success เพราะปัญหาบางแบบอาจปรากฏเมื่ออ่านกลับ ส่วนกรณี error ต้องดูว่าการปล่อย CS, bus และ resource กลับสู่สภาพที่งานถัดไปเริ่มได้หรือไม่
การแชร์ SPI ต้องจัดทั้งสายร่วม CS ลำดับเริ่ม และเจ้าของ transaction ให้ตรงกัน โดยเฉพาะ SD card กับหลาย task ที่เพิ่มเงื่อนไขนอกเหนือจากการเลือกอุปกรณ์ เมื่อไล่ตรวจจากชุดเดี่ยวไปสู่ระบบรวมและรักษาอายุ resource ตาม API เราจะรู้ว่าปัญหาอยู่ที่สัญญาณ การเริ่มต้น หรือการใช้งานร่วม แล้วแก้ได้ตรงขอบเขตของมัน