TF ยังใช้เรียก microSD คู่มือนี้สำหรับ TF ส่วน SD ขนาดเต็มต้องตรวจอินเทอร์เฟซและชุดเฉพาะ
01
YOULEN จัดหาอะไรให้โครงการได้บ้าง?
ชุดส่วนประกอบที่เสนอและขอบเขตเตรียมงานชัดเจน งานที่มีอิมเมจระบบจะกำหนดเวอร์ชัน การเขียน การตรวจสอบ และการยอมรับบนอุปกรณ์จริงในขั้นตัวอย่าง
ประสิทธิภาพ ความทนทานการเขียน และอุณหภูมิขึ้นกับชุดที่เลือก ชื่อแบรนด์แฟลชอย่างเดียวไม่ยืนยันคุณสมบัติเหล่านี้
ภาพแสดงแบบ 32GB A1/U1 ความจุและคลาสอื่นเป็นไปตามชุดที่เสนอ
| รายการ | การจัดหาและเตรียมงาน |
|---|---|
| ความจุ | ปัจจุบันจัดหา 2GB–256GB โดยเสนอให้เหมาะกับอุปกรณ์และพื้นที่ที่ต้องใช้ |
| ประสิทธิภาพ | ยืนยันว่ามีชุดที่รองรับคลาสความเร็ว การเข้าถึงแบบสุ่ม หรือการเขียนต่อเนื่องตามเป้าหมายหรือไม่ พร้อมระบุผลอ้างอิงที่มี ประสิทธิภาพในอุปกรณ์ประเมินด้วยตัวอย่าง |
| ส่วนประกอบ | ชุดปกติใช้แฟลช Micron และ SK hynix เป็นหลัก สามารถเปิดเผยส่วนประกอบที่เสนอ |
| สั่งซ้ำ | เปิดเผยบัญชีวัสดุ (BOM) และควบคุมชุดตามข้อตกลงของคำสั่งซื้อ |
| อิมเมจระบบ | ตกลงอิมเมจต้นทาง วิธีเขียน/ตรวจสอบ การขยายพาร์ทิชัน และขอบเขตยอมรับอุปกรณ์ |
| เปลี่ยน BOM | หากการจัดหาชิ้นส่วนทำให้ต้องเปลี่ยน เราส่งตัวอย่างใหม่อย่างน้อยหนึ่งเดือนก่อนการเปลี่ยนที่เสนอเพื่อทดสอบและยืนยัน |
| รับประกัน | รับประกันหนึ่งปี จัดการการ์ดเสียตามเงื่อนไขที่ตกลง |
02
YOULEN มีประสบการณ์งานฝังตัวอะไร?
เมื่อไม่นานนี้ YOULEN ได้รับคำสั่งซื้อการ์ดบูต TF 50,000 ใบสำหรับโครงการอุปกรณ์ฝังตัวในสหรัฐฯ และมีคำถามด้านนี้เพิ่มขึ้น
ในงาน Armbian อีกงานหนึ่ง เราตรวจอิมเมจที่เขียนแล้วพบ EXT4 ขนาด 4.4 GB กับพื้นที่ยังไม่จัดสรร 24.6 GB ต้องเลือกว่าจะคงโครงสร้าง ขยายส่วนระบบ หรือเพิ่มส่วนข้อมูลเมื่อส่งมอบ
บันทึกด้านล่างมาจากงานเตรียมแยกนี้ ไม่ใช่คำสั่งซื้อสหรัฐฯ แสดงขั้นเตรียม ไม่ใช่ผลยืนยันความเร็วบูตหรือความเชื่อถือได้ภาคสนาม
03
เมื่อใดควรใช้การ์ด TF?
เป็นทางเลือกที่ดีสำหรับบอร์ดพัฒนาที่รองรับ ระบบเฉพาะทางเน้นอ่าน และสื่อติดตั้งที่ถอดเปลี่ยนได้ งานเขียนหนักต้องประเมินในเครื่อง ส่วน swap หนักหรือเก็บค่าตั้งไม่กี่ค่าไม่ใช่ตัวเลือกแรกของการ์ดทั่วไป
คำแนะนำเป็นแนวทางเลือกวิธีจัดเก็บ การ์ดสุดท้ายขึ้นกับอุปกรณ์ ภาระงาน และผลตัวอย่าง
| งาน | คำแนะนำเบื้องต้น | เหตุผลและสิ่งตรวจ |
|---|---|---|
| บอร์ดพัฒนา ต้นแบบ เปลี่ยนอิมเมจบ่อย | น่าพิจารณา | เตรียมและเปลี่ยนง่าย ตรวจบอร์ดกับอิมเมจที่รองรับ |
| ระบบเฉพาะอ่านมากเขียนน้อย | น่าพิจารณา | สมดุลต้นทุน/ประสิทธิภาพ ตรวจเขียนพื้นหลัง อุณหภูมิ ไฟเลี้ยง |
| ตัวเก็บข้อมูล ตัวรวม เกตเวย์ | ประเมินบนอุปกรณ์ | ความจุ/เปลี่ยนได้มีประโยชน์ ระบุปริมาณเขียน ระยะเก็บ การกู้คืน |
| หลายแอป ไฟล์เล็ก ฐานข้อมูลบ่อย | ประเมินบนอุปกรณ์ | การเข้าถึงสุ่มและความหน่วงสำคัญ ไม่ใช่แค่ความเร็วต่อเนื่อง |
| ค่าตั้งหรือตัวนับเล็กน้อย | ไม่ใช่ตัวเลือกแรก | หน่วยความจำในบอร์ดขนาดเล็กอาจเพียงพอ |
| ใช้ swap หนัก | ไม่ใช่ตัวเลือกแรก | ทบทวน RAM จริง ภาระเขียน และสื่ออื่น |
| ติดตั้ง อัปเดต กู้คืน | น่าพิจารณา | ช่วยแจกจ่ายและซ่อมบำรุงหากรองรับอิมเมจ/ขั้นตอน |
| ไม่มีคนเฝ้าและเสียหายร้ายแรงเมื่อขัดข้อง | ประเมินบนอุปกรณ์ | ให้ความสำคัญกับสภาพแวดล้อม ไฟเลี้ยง ระบบสำรอง การบำรุง |
04
ทำไมเลือก TF แทนสื่อบนบอร์ด?
โหลดล่วงหน้า เปลี่ยนได้ และเลือกความจุได้ยืดหยุ่นคือข้อดีหลัก เปรียบเทียบทั้งการส่งมอบและบำรุงรักษาก่อนตัดสินต้นทุน
เตรียมการ์ดระบบล่วงหน้าแยกการเขียนอิมเมจออกจากประกอบขั้นสุดท้าย เก็บเวอร์ชันที่อนุมัติเพื่อจัดการซอฟต์แวร์ที่ส่งไปได้ง่าย
หากเข้าถึงสล็อตได้และเครื่องรองรับบูตจากการ์ด การ์ดสำรองที่เตรียมแล้วเป็นส่วนหนึ่งของการบำรุงได้ นักพัฒนาเปลี่ยนการ์ดเพื่อสลับระบบได้
ภายในขอบเขตที่เครื่องรองรับ ฮาร์ดแวร์เดียวใช้ความจุต่างกันเพื่อระบบ เนื้อหา หรือระยะเก็บข้อมูลได้
สื่อบนบอร์ดก็มีข้อดีในการรวมและผลิต ต้องเทียบสื่อ ออกแบบ โปรแกรม ทดสอบ ซ่อม TF ไม่ได้ถูกกว่าเสมอ และปกติเป็นที่เก็บถาวร ไม่แทน RAM โดยตรง
05
ใช้การ์ดบูต รันระบบ หรือเก็บข้อมูล?
สื่อบูตเริ่มเครื่อง ส่วนระบบให้บริการ OS ขณะทำงาน ส่วนข้อมูลเก็บเนื้อหา การ์ดเดียวอาจทำหลายหน้าที่
เครื่องอาจบูตจากในบอร์ดแล้วเขียน log ลง TF หรือบูต TF แล้วเก็บข้อมูลใหญ่ที่อื่น คำว่า 'การ์ดบูต Linux' อย่างเดียวไม่พอ การทำงานหลังบูตก็สำคัญ
| หน้าที่ | การใช้ | จุดสำคัญ |
|---|---|---|
| บูต | อ่านโค้ด/เนื้อหาเริ่มต้นเมื่อเปิดไฟ | รองรับบูต การอ่าน โครงสร้างอิมเมจ |
| ระบบ | ให้บริการ OS และแอปที่ทำงาน | เข้าถึงสุ่ม ความหน่วง เขียนพื้นหลัง |
| ข้อมูล | เก็บ log บันทึกเสียง/วิดีโอ ข้อมูลงาน | ความจุ รูปแบบเขียน ป้องกัน ระยะเก็บ |
06
แต่ละระบบต้องเตรียมต่างกันหรือไม่?
ใช่ ซอฟต์แวร์เริ่มต้นกำหนดการบูต OS และไดรเวอร์กำหนดระบบไฟล์ที่รองรับ แอปกำหนดภาระอ่าน/เขียน ชื่อ OS อย่างเดียวไม่กำหนดโครงสร้างการ์ด
ตัวอย่างเช่น Zephyr มีเอกสารเข้าถึง SD และเชื่อมระบบไฟล์ เป็นข้อมูลด้านเก็บข้อมูล ไม่ยืนยันว่าทุกบอร์ด Zephyr บูตจากการ์ดได้ [1]
| แพลตฟอร์ม | ผลต่อการ์ด | รายละเอียดโครงการ |
|---|---|---|
| MCU ซอฟต์แวร์ bare-metal และ FreeRTOS | ระบบปฏิบัติการเวลาจริง (RTOS) ไม่กำหนดวิธีบูต TF กลาง การเข้าถึงไฟล์แยกจากรองรับบูต | ไมโครคอนโทรลเลอร์ (MCU) bootloader และไดรเวอร์กำหนดว่าจะเก็บโค้ดเริ่มต้น แพ็กเกจอัปเดต หรือข้อมูล |
| Orange Pi, Armbian และ Linux ฝังตัว | อิมเมจทั้งอุปกรณ์มีโครงสร้างในตัว การเขียนต่างจากคัดลอกไฟล์ลงการ์ดฟอร์แมตแล้ว [3] | อิมเมจตรงบอร์ด พาร์ทิชัน และการขยายเมื่อบูตครั้งแรก |
| Raspberry Pi | ตัวเลือกบูตต่างตามรุ่น ต้องเตรียมตรงรุ่นและเส้นทางบูต [7] | รุ่นที่แน่นอน อิมเมจ และลำดับบูตที่ตั้ง |
| แพลตฟอร์มเฉพาะผู้ผลิต เช่น Novatek, Ambarella, Realtek | ขั้นตอนบอร์ดและซอฟต์แวร์ผู้ผลิตกำหนดการเตรียม การ์ดบันทึก อัปเดต และระบบมีหน้าที่ต่างกัน | ชิป บอร์ด เวอร์ชัน บทบาทการ์ด และคู่มือผู้ผลิต |
| Android: เก็บข้อมูลภายนอก | adoptable storage ถูกฟอร์แมตและเข้ารหัสสำหรับเครื่องเดียว เป็นโหมดข้อมูล ไม่ใช่เตรียมอิมเมจบูต [2] | แบบพกพาหรือ adoptable ส่วนบูต TF ต้องมีขั้นตอนเริ่มต้นเฉพาะบอร์ดแยกต่างหาก |
07
ควรใช้ FAT32 หรือ EXT4?
ไม่มีรูปแบบเดียวสำหรับทุกเครื่อง อิมเมจทั้งเครื่องที่อนุมัติมีโครงสร้างมาแล้ว ส่วนข้อมูลแยกเลือกตามเครื่องรองรับ
ระบบไฟล์จัดระเบียบไฟล์และไดเรกทอรี การ์ดมีหลายพาร์ทิชันใช้คนละระบบได้
| การเตรียม | เลือกระบบไฟล์ |
|---|---|
| ไฟล์/ข้อมูลทั่วไป | ตามเครื่องและข้อกำหนดไฟล์ |
| อิมเมจทั้งระบบ | รักษาโครงสร้างที่อนุมัติ |
| ระบบเฉพาะ | ตามบอร์ด ซอฟต์แวร์บูต อิมเมจ |
| ข้อมูลแยก | ยืนยัน OS/แอปรองรับ |
บางระบบใช้ FAT สำหรับบูตและ EXT4 สำหรับระบบ แต่ไม่ใช่โครงสร้างกลางของ Linux ฝังตัว [3][7]
08
คัดลอก IMG เหมือนเขียนอิมเมจบูตหรือไม่?
ไม่เหมือน คัดลอกเก็บเป็นไฟล์ แต่เขียนทั้งอุปกรณ์เตรียมสื่อตามโครงสร้างอิมเมจ
อิมเมจเต็มอาจมีโค้ดเริ่มต้น ตารางพาร์ทิชัน ระบบไฟล์ ลาก .img ลงพาร์ทิชันเดิมโดยทั่วไปไม่ใช่การเตรียมการ์ดที่ต้องเขียนทั้งอุปกรณ์
ขั้นตอนทางการ Armbian มีเลือกบอร์ด/อิมเมจในเครื่อง เขียน และตรวจข้อมูล [3]
บันทึก YOULEN นี้แสดงอิมเมจ Orange Pi Zero3 เขียนเสร็จ
ก่อนล็อต แยกอิมเมจทั้งเครื่อง อิมเมจพาร์ทิชัน ไฟล์ทั่วไป และแพ็กเกจอัปเดตที่มีขั้นตอนเฉพาะ นามสกุลอย่างเดียวไม่กำหนดวิธี
09
ทำไมเหลือพื้นที่ไม่ใช้หลังเขียน?
อิมเมจอาจใช้เพียงส่วนหนึ่ง ที่เหลืออยู่นอกพาร์ทิชัน/ระบบไฟล์ ไม่ใช่หลักฐานความจุเสียโดยตัวมันเอง
บันทึก YOULEN ล่าสุดแสดง EXT4 ประมาณ 4.4 GB และพื้นที่ยังไม่จัดสรร 24.6 GB
| ทางเลือก | สิ่งที่ตกลง |
|---|---|
| ขยายเมื่อบูตแรก | อิมเมจมีฟังก์ชันและตรวจบนเครื่องแล้ว |
| ขยายก่อนส่ง | ตกลงวิธี ผลต่อบูต ผลที่คาด |
| คงโครงสร้าง | ลูกค้ายอมรับพื้นที่เดิม |
| เพิ่มข้อมูลแยก | OS/แอปรองรับและลูกค้าอนุมัติ |
ขยายพาร์ทิชันกับระบบไฟล์เกี่ยวข้องแต่คนละขั้น อิมเมจเฉพาะอาจไม่คงพฤติกรรมขยายอัตโนมัติแรกเริ่ม
ต้องยืนยันโครงสร้างพื้นที่ตอนส่ง ไม่หยุดเพียงข้อความเขียนเสร็จ
10
ความจุบนฉลากเท่ากันใส่อิมเมจเดียวได้เสมอหรือไม่?
ไม่เสมอ ป้าย 32GB เหมือนกันไม่พอ อิมเมจและขอบเขตพาร์ทิชันต้องอยู่ในพื้นที่ที่ระบุที่อยู่ได้จริงของการ์ดปลายทาง
ตรวจด้วยชุดที่เสนอ หากข้ามชุด/ล็อต ต้องตกลงความจุจริงและพื้นที่เผื่อในขั้นตัวอย่าง
เผื่อระบบ แอป อัปเดต log ข้อมูล ไม่ใช่แค่อิมเมจตั้งต้น
11
การ์ดบูต Linux ต้อง A2 หรือไม่?
ไม่จำเป็นเสมอ ขึ้นกับภาระและโฮสต์ ระบบเน้นอ่านต่างจากฐานข้อมูลที่เข้าถึงบ่อย
A1/A2 เป็นคลาสประสิทธิภาพแอปของ SD Association ส่วน IOPS คือจำนวนปฏิบัติการรับ/ส่งข้อมูลต่อวินาที ค่าสุ่มด้านล่างใช้ปฏิบัติการ 4 KB
| คลาส | อ่านสุ่มเฉลี่ยขั้นต่ำ | เขียนสุ่มเฉลี่ยขั้นต่ำ | ประสิทธิภาพต่อเนื่องขั้นต่ำ |
|---|---|---|---|
| A1 | 1,500 IOPS | 500 IOPS | 10 MB/s |
| A2 | 4,000 IOPS | 2,000 IOPS | 10 MB/s |
เป็นเกณฑ์คลาสในเงื่อนไขกำหนด ไม่ใช่เวลาบูตหรืออายุการ์ด โฮสต์ต้องรองรับคุณสมบัติ A2 ด้วย [4]
ไฟล์ใหญ่/บันทึกต่อเนื่องเน้นการโอนต่อเนื่อง ระบบ/ฐานข้อมูลต้องประเมินสุ่มและความหน่วงด้วย C10, U3, V30 ไม่ยืนยัน A2
12
เขียนน้อยรับประกันใช้ได้นานหรือไม่?
ลดสึกหรอ แต่แปลงเป็นจำนวนปีรับประกันไม่ได้ อุณหภูมิ ไฟเลี้ยง เขียนพื้นหลัง การเก็บข้อมูล และบำรุงก็มีผล
ไฟล์งานเล็กไม่ได้แปลว่าเขียนน้อย เพราะมี log ฐานข้อมูล แคช และ metadata เพิ่ม
มิเตอร์น้ำ/ไฟต้องแยกเครื่องเก็บค่าตั้งน้อยออกจากตัวรวมข้อมูลหลายเครื่อง หน่วยความจำในบอร์ดเล็กอาจพอสำหรับแรก ส่วนตัวรวมอาจได้ประโยชน์จากความจุและการเปลี่ยน TF
ความทนเขียนกับเก็บข้อมูลเมื่อไม่จ่ายไฟเป็นคนละคุณสมบัติ [5]
13
หากไฟดับทันทีจะเกิดอะไร?
ประเมินการ์ด ไฟเลี้ยง การเขียน และกู้คืนร่วมกัน คลาสความเร็วอย่างเดียวไม่แก้ไฟดับ
เครื่องเน้นอ่านอาจใช้ root อ่านอย่างเดียวและแยกข้อมูลเขียน คู่มือ Raspberry Pi อธิบายวิธีนี้ แต่ไม่ทำให้การ์ดทั้งใบปลอดจากความเสียหาย [6]
หากระบุป้องกันไฟดับ ต้องบอกว่าปกป้องข้อมูลกำลังเขียน ข้อมูลเก็บแล้ว การจัดการภายใน หรือสภาพเครื่องหลังรีสตาร์ต
14
TF แทน RAM หรือ ROM ได้หรือไม่?
ไม่ได้ TF เป็นที่เก็บถาวร ไม่แทนหน่วยความจำทำงานจริง (RAM) หรือหน่วยความจำบูตอ่านอย่างเดียวในชิป (ROM)
คำว่า 'ความจุ ROM' อาจหมายถึงพื้นที่ระบบ แอป ไฟล์ ต้องดูหน้าที่จัดเก็บจริง
swap ของ Linux ย้ายหน้าเมมโมรีลงสื่อ ไม่เพิ่ม RAM ประสิทธิภาพเท่ากัน paging บางครั้งกับ swap หนักต่อเนื่องต่างกัน กรณีหลังต้องทบทวนหน่วยความจำ/สื่อ
15
ตกลงอะไรจากตัวอย่างสู่ล็อต?
กำหนดชุดและอิมเมจ ตรวจยอมรับในเครื่อง แล้วจึงยืนยันเงื่อนไขส่งล็อต
ตรวจการเขียน ทดสอบการ์ด และยอมรับอุปกรณ์ตอบคนละคำถาม การทำสำเนาต้องแยกเนื้อหาร่วมออกจาก ID กุญแจ และข้อมูลตั้งต้นที่ต้องสร้างเฉพาะเครื่อง
| ขั้น | ผลตกลง |
|---|---|
| โครงการ | เครื่อง หน้าที่ สภาพแวดล้อม ความจุ จำนวน |
| ชุด | ความเร็ว แฟลช ความทน อุณหภูมิ |
| อิมเมจ | เวอร์ชันอนุมัติ checksum เขียน ขยาย |
| เขียน/การ์ด | ขอบเขต วิธี บันทึก |
| ยอมรับตัวอย่าง | บูต ทำงาน ข้อมูล กู้คืนที่ต้องใช้ |
| ยืนยันล็อต | ชุด อิมเมจ จำนวน บรรจุ กำหนดเวลา รับประกัน |
| เปลี่ยนภายหลัง | อนุมัติส่วนประกอบ/อิมเมจอีกครั้ง |
แหล่งข้อมูลและขอบเขต
คู่มือรวมแหล่งเทคนิคสาธารณะ ความต้องการโครงการล่าสุด และบันทึก YOULEN ไม่ใช่รายงานทดสอบข้ามแพลตฟอร์ม ข้อกำหนดขึ้นกับเครื่อง/เวอร์ชันซอฟต์แวร์จริง ชุดและการส่งตามตัวอย่าง/คำสั่งซื้ออนุมัติ
- Zephyr — SD-card access, drivers and file-system integration
- Android — adoptable storage, formatting and encryption
- Armbian — image writing and verification
- SD Association — A1 and A2 application performance
- Swissbit — endurance, retention and storage technology
- Raspberry Pi — making a more resilient file system
- Raspberry Pi — hardware and boot mechanisms