1 คะแนน โดย GN⁺ 2025-04-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มุ่งทำคอมพิวเตอร์ขั้นต่ำที่ประกอบเองที่บ้านได้ โดยสร้างระบบระดับ RAM 8MB·1 MIPS ที่รัน Debian Linux, vi, gcc, make ได้ ด้วยชิ้นส่วนแบบ 8 พินเท่านั้น
  • บอร์ดสุดท้ายประกอบด้วยชิป 3 ตัวคือ STM32G031, SPI PSRAM 8MB และบริดจ์ USB-serial PL2303GL โดยข้อจำกัดของแพ็กเกจ 8 พินทำให้มี I/O ใช้ได้เพียง 6 ขา
  • การขาดแคลนขาเป็นความยากหลักของการออกแบบ โดย RAM ใช้ SPI ปกติ, SD card ใช้ 1-bit SDIO ที่แชร์ขากับ RAM และการส่ง UART ใช้ bit-banging
  • ซอฟต์แวร์นำ MIPS emulator เดิมที่ใช้แอสเซมบลี ARMv6M กลับมาใช้ และ bootloader 8KB อัปเดต firmware จาก FIRMWARE.BIN ในระบบไฟล์ FAT บน SD card
  • STM32G031 ถูก overclock เกิน 64MHz ตามสเปกด้วยการตั้งค่า VOS0 และที่ host CPU 148MHz จะได้ระดับ MIPS R3000 ราว 1.65MHz สามารถบูต Debian ได้ภายในประมาณ 1 นาที

คอมพิวเตอร์ Linux ขั้นต่ำที่สร้างจากชิป 8 พินเท่านั้น

  • เป้าหมายคือการสร้าง คอมพิวเตอร์ยุคใหม่แบบ kit ที่ประกอบได้ง่ายที่บ้าน โดยใช้ชิป 8 พินเท่านั้น
  • เกณฑ์ขั้นต่ำของคอมพิวเตอร์ยุคใหม่กำหนดจากการรัน Debian Linux, vi, gcc, make ได้หรือไม่
  • จากการทดลองก่อนหน้า กำหนดสเปกขั้นต่ำที่จำเป็นต่อการรัน Linux เป็น RAM 8MB และ CPU 1 MIPS
  • อุปกรณ์เก็บข้อมูลใช้ SD card และการเชื่อมต่อคอนโซลใช้ USB-serial
  • บอร์ดมีรูปทรงกลมขนาดเล็ก และมี คอนเนกเตอร์ USB-C แบบขอบบอร์ดอยู่ด้านบน
  • ลดจำนวนชิ้นส่วนและจำนวนขา เพื่อให้แม้คนที่แทบไม่มีประสบการณ์บัดกรีก็สามารถประกอบได้ด้วยหัวแร้งบัดกรี 45W

การเลือกชิ้นส่วน

  • สำหรับการเชื่อมต่อ USB เลือกใช้ PL2303GL
    • เป็นบริดจ์ USB-serial ที่ทำงานได้โดยไม่ต้องมีชิ้นส่วนภายนอก และยังให้เอาต์พุต regulator 3.3V 100mA ด้วย
    • มี driver สำหรับระบบปฏิบัติการหลัก ๆ และบน macOS ต้องติดตั้งผ่าน App Store
  • มีการพิจารณาทางเลือกเป็นการทำ USB ด้วย ATTINYx5 และ V-USB ด้วย
    • ตามสเปกแล้ว USB low-speed ไม่สามารถใช้ bulk endpoint ได้ แต่ OS หลัก ๆ ไม่ได้บังคับข้อนี้ จึงทำ ACM serial port ให้ใช้งานได้
    • V-USB ใช้เวลา CPU, flash และ RAM มาก จึงเป็นภาระสูงสำหรับโปรเจกต์นี้
  • RAM ใช้ SPI PSRAM แบบ SOIC-8
    • ISSI, APMEMORY, Vilsion และรายอื่น ๆ ผลิตชิ้นส่วนที่เกี่ยวข้อง และชิ้นส่วน 8MB หาได้จากช่องทางจำหน่ายทั่วไป
    • ผู้ผลิตหลายรายเคยสัญญาชิป 16MB ไว้ แต่ประเมินว่าไม่ได้มีการจัดหาออกมาจริง
  • เปรียบเทียบไมโครคอนโทรลเลอร์หลายตระกูล ได้แก่ PIC16F, RL78, PSoC1, eZ8, S08CPUv2, STM8, MSP430, AVR, PSoC4, MSPM0C, CH32V003, CH570E, STM32G0
  • ตัวเลือกสุดท้ายคือสาย STM32G031J4M6/STM32G031
    • มีคอร์ Cortex-M0+, ความเร็วทางการ 64MHz, flash 32KB และ RAM 8KB
    • ในแพ็กเกจ 8 พิน ได้เปรียบผู้สมัครอื่นทั้งด้านประสิทธิภาพและหน่วยความจำ
    • แม้คุณภาพเอกสาร errata ของชิป STM จะน่ากังวล แต่เนื่องจากการออกแบบใช้ peripheral บนชิปให้น้อยที่สุด จึงเลือกใช้ได้

การออกแบบฮาร์ดแวร์ที่ยัดลงใน I/O 6 ขา

  • Console UART

    • UART RX และ TX ผนวกกับฟังก์ชันอื่นได้ยาก
    • ถ้าแชร์ RX อาจพลาดข้อมูลรับเข้าระหว่างทำงานอย่างอื่น และถ้าแชร์ TX แม้ pulse low สั้น ๆ ก็อาจถูก PC มองเหมือนเป็นตัวอักษรได้
    • ด้วยเหตุนี้ I/O 2 จาก 6 ขาจึงถูกจัดสรรให้กับ UART console
    • ในผังขาสุดท้าย ใช้ pin 8 เป็น USART2 RX และ pin 7 ใช้ bit-banging สำหรับ UART TX
    • ระหว่างส่ง UART การทำงานทั้งหมดจะหยุด จึงใช้ความเร็ว 115,200bps ที่เร็วที่สุดเท่าที่เป็นไปได้
    • การส่งอักขระหนึ่งตัวใช้เวลาประมาณ 87 ไมโครวินาที และบอร์ดไม่ได้ส่งเอาต์พุตเป็นส่วนใหญ่ จึงเป็นวิธีที่ยอมรับได้
  • การเชื่อมต่อ RAM

    • SPI PSRAM รองรับ QSPI แต่ QSPI ต้องใช้ 6 ขา จึงใช้ไม่ได้
    • dual-SPI อาจเร็วกว่า SPI ปกติ 2 เท่าโดยไม่เพิ่มจำนวนขา แต่ STM32G031 ไม่รองรับ dual-SPI
    • ประเมินว่าแม้จะ bit-bang dual-SPI ด้วย CPU ก็ยากจะเหนือกว่าการผสม hardware SPI กับ DMA
    • ผลคือ RAM เชื่อมต่อด้วย SPI ปกติ และการเชื่อมต่อนี้ใช้ขาที่เหลือทั้งหมด 4 ขา
  • การเชื่อมต่อ SD card

    • หากใช้ SD card ในโหมด SPI ต้องมีขา chip select เพิ่มอีก 1 ขา แต่ไม่มีขาเหลือ
    • วิธีกลับสัญญาณ RAM nCS ด้วย inverter เพื่อนำไปใช้เป็น SD card nCS มีปัญหากับ card บางรุ่น และยังต้องมีชิ้นส่วนเพิ่ม
    • มีการพิจารณาวิธีแชร์ขา UART TX เป็น SD card nCS พร้อม low-pass filter ด้วย แต่ต้องใช้ UART 300bps หรือต่ำกว่า และเปราะบางเมื่อ SD card ช้า
    • ทางออกสุดท้ายคือ implement โปรโตคอล 1-bit SDIO ของ SD card เองโดยตรง
    • แชร์ RAM nCS เป็น SD CLK, RAM CLK เป็น SD CMD, RAM MOSI เป็น SD DAT
    • การเข้าถึง RAM จะดูเหมือนบิต idle สถานะ 1 จากฝั่ง SD card และการเข้าถึง SD จะดูเหมือนการเลือกและปล่อยซ้ำ ๆ จากฝั่ง RAM จึงทำงานได้อย่างปลอดภัย
    • แต่ไม่สามารถแทรกการเข้าถึง RAM กลาง SD transaction ได้ จึงใช้ multi-block read/write ไม่ได้
    • จากการจัดขาของ STM32G031 ไม่สามารถใช้ SDIO เป็นอุปกรณ์ hardware ได้ การเข้าถึง SD จึงใช้ bit-banging ทั้งหมด
    • implementation แบบ assembly ทำ throughput ได้ประมาณ 14 CPU cycles/bit

Bootloader และลำดับการบูต Linux

  • Emulator

    • นำ MIPS emulator จากโปรเจกต์ LinuxCard เดิมกลับมาใช้
    • emulator เขียนด้วย assembly ARMv6M และสามารถบูต Linux ได้
    • มีการเขียน MIPS-to-ARMv6M JIT เพื่อให้รันเร็วขึ้นด้วย แต่ขนาดโค้ด 46KB ใหญ่เกินไป และประโยชน์ด้านความเร็วใน cache แปลง 6KB ก็ไม่เพียงพอ จึงไม่ใช้
    • flash 32KB ของ STM32G031 แบ่งเป็น bootloader 8KB และโค้ดหลัก 24KB
  • Bootloader สำหรับอัปเดต firmware

    • เนื่องจากไม่สามารถเหลือขา debug ไว้ได้ จึงต้องมี bootloader ที่อัปเดต firmware จาก SD card
    • bootloader มี SDIO driver, FAT filesystem driver, โค้ดเขียน flash, logging และโค้ดส่ง UART แบบ bit-banging
    • ขนาดจริงประมาณ 6.5KB แต่ใช้พื้นที่ 8KB เนื่องจากหน่วย block ของ flash
    • ค้นหา FIRMWARE.BIN บน SD card และนำ update ไปใช้เมื่อผ่านการตรวจสอบพื้นฐานและเงื่อนไขว่า version เพิ่มขึ้น
    • ใช้ word ที่ offset 16 ของ application image เป็นหมายเลข version
    • byte ที่ offset 8 ของ bootloader คือ version ของ bootloader และไม่ได้ใช้นอกจากแสดงข้อความตอนบูต main app
    • bootloader ยังค้นหาไฟล์หรือไดเรกทอรีในระบบไฟล์ FAT ที่ชื่อขึ้นต้นด้วย CLOCK
    • ใช้ตัวเลขที่ตามมาเป็นความเร็ว clock ของ main application และหากอยู่นอกช่วง 32–200MHz หรือไม่มีค่า จะใช้ 132MHz
  • Partition ของ card และการโหลด kernel

    • ลำดับการบูตจัดให้คล้ายกระบวนการบูตของ PC
    • อ่าน sector แรกของ SD card เข้าไปที่ส่วนต้นของ RAM แล้ว jump ไป
    • โค้ดขั้นแรกค้นหา partition type 0xBB โหลดไปยัง 0x80001000 แล้ว jump ไป
    • bootloader ขั้นที่สอง mount partition ที่ทำเครื่องหมาย active เป็น FAT16 และโหลดไฟล์ VMLINUX เป็น ELF
    • kernel command line ฝังอยู่ใน bootloader
    • root คือ /dev/pvd3, init คือ /sbin/uMIPSinit
    • พยายาม mount /dev/pvd1 เป็น /boot
    • ลำดับ partition ของโปรเจกต์คือ FAT partition, bootloader partition, rootfs
    • Windows และ macOS จะ mount partition แรก จึงใส่และนำไฟล์ออกผ่าน FAT partition ได้ง่าย
    • ใน Linux ที่บูตขึ้นมาแล้ว partition ดังกล่าวก็จะเห็นเป็น /boot ด้วย

ประสิทธิภาพและการ overclock

  • ความเร็วทำงานทางการของ STM32G031 คือ 64MHz แต่ทดลอง clock ที่สูงขึ้นโดยใช้การตั้งค่าแรงดันภายใน
  • เอกสาร STM มีการตั้งค่า VOS2 1.0V และ VOS1 1.2V และที่ VOS1 จะไม่เสถียรเหนือประมาณ 75MHz
  • เมื่อใช้การตั้งค่า VOS0 1.35V ที่ปรากฏในเอกสารเก่าและเอกสารของชิปที่คล้ายกัน จะมีช่องให้ overclock เพิ่มขึ้นมาก
  • ชิปส่วนใหญ่ทำงานได้ดีที่ 136MHz และบางตัวไปถึง 180MHz
  • เนื่องจาก flash memory ไม่ได้เร็วขึ้น จึงต้องจัดการ flash wait states ให้ถูกต้อง
  • ที่ host CPU 148MHz, MIPS CPU ที่ emulate จะใกล้เคียง MIPS R3000 ราว 1.65MHz เมื่อปิด FPU
  • ระบบบูตได้ภายในประมาณ 1 นาที และ vi, make, objdump, gcc ทำงานได้
  • เนื่องจากเป็นระบบ Debian เต็มรูปแบบ จึงนำแพ็กเกจ .deb เข้ามาที่ /boot แล้วติดตั้งได้

การประกอบและการเริ่มใช้งานครั้งแรก

  • ขั้นตอนการประกอบ

    • มีไฟล์ออกแบบให้เพื่อให้ทำบอร์ดเองได้ และกำลังมองหาบริษัทที่จะขาย kit
    • การประกอบทำตามลำดับคือ socket SD card, capacitor, resistor, STM32G031, PL2303GL
    • R101, R102, R201, R202 ไม่ต้องใส่ในตอนแรก
    • ต้องเขียน bootloader ลง STM32 ก่อน
    • bridge R101 และ R201 เพื่อจัดสาย serial สำหรับ ROM bootloader
    • ดำเนินการโดยยังไม่เสียบ SD card และยังไม่บัดกรีชิป RAM
    • หลังเขียน bootloader แล้ว ให้ถอด bridge R101/R201 และ bridge R102/R202 แทน
    • จากนั้นบัดกรีชิป RAM APS6408 หรือ VTI7064 ที่ตำแหน่ง U2 ก็เสร็จสิ้นการประกอบ hardware
  • Firmware และการบูตครั้งแรก

    • SD card ต้องมีขนาดอย่างน้อย 1GB และเขียน disk image ที่ให้มา
    • image มี partition ที่บรรจุ MIPS bootloader ขั้นที่ 1, MIPS bootloader ขั้นที่ 2, Linux kernel และสำเนา firmware รวมถึง Debian rootfs
    • หากใส่ FIRMWARE.BIN ไว้ใน FAT partition ตอนบูตครั้งแรก bootloader จะ flash ตัวเอง
    • ตั้ง serial terminal เป็น 115,200bps, 8N1
    • ตอนรันครั้งแรก STM32 fuse จะถูกโปรแกรม และอาจต้องถอดสาย USB-C แล้วเสียบใหม่
    • หลังประมาณ 20 วินาที ข้อความบูตของ Linux kernel จะเริ่มขึ้น และการบูตทั้งหมดใช้เวลาประมาณ 1 นาที
    • เนื่องจากมี RAM เพียง 8MB จึงแนะนำอย่างยิ่งให้รัน swapon /swapfile เป็นคำสั่งแรก
    • การเปิดใช้ swap ใช้เวลาหลายสิบวินาที แต่หลังจากนั้นจะรันโปรแกรมได้มากขึ้น

ไฟล์ดาวน์โหลดและการใช้งาน

  • ดาวน์โหลดหลักคือ uMIPS.8PL.zip
  • archive มีไฟล์ที่จำเป็นสำหรับการผลิตบอร์ดและการรัน
    • schematics: แผนผังวงจร
    • gerbers: ไฟล์ Gerber สำหรับผลิตบอร์ด
    • srcs: source ของ emulator และ bootloader
    • binaries/SD.img: image สำหรับเขียนลง SD card
    • BOOTLOADER.BIN: bootloader ที่ต้องเขียนลงชิประหว่างประกอบ
    • FIRMWARE.BIN: firmware image ที่ build ไว้ล่วงหน้า
  • หลังบูตแล้ว shell พื้นฐานคือ sh และ bash ก็รันได้ด้วย
  • เพื่อหลีกเลี่ยงปัญหา RAM ไม่พอ ควรเปิดใช้ swapfile ที่รวมอยู่ใน image ด้วย swapon /swapfile
  • หากสมมติว่า MCU รันที่ 120MHz ความเร็ว CPU ที่มีผลจริงจะประมาณ 1.5MHz
  • การ compile โปรแกรม C ง่าย ๆ ด้วย gcc ใช้เวลาหลายนาที แต่ทำงานได้
  • มีตัวอย่างตัวสร้าง Mandelbrot แบบ floating-point และ fixed-point ให้ทั้งในรูป source และ binary
  • เครื่องมือที่ติดตั้งไว้มี vim, make, gcc และสามารถเพิ่มแพ็กเกจ Debian ผ่าน FAT16 partition ที่แชร์อยู่บน SD card ได้

1 ความคิดเห็น

 
GN⁺ 2025-04-06
ความคิดเห็นใน Hacker News
  • ส่วนที่เล่าว่าหลังจากคิดอยู่ว่าพินไหนสามารถใช้ร่วมกับสามพินของ SDIO ได้บ้าง แล้วได้คำตอบว่าใช้ nCS ของ RAM เป็น CLK ของ SD card, CLK ของ RAM เป็น CMD ของ SD card และ MOSI ของ RAM เป็น DAT ของ SD card นั้นเป็น การแฮ็กที่ยอดเยี่ยม จริง ๆ
    เมื่อพิจารณาปฏิสัมพันธ์ที่เป็นไปได้กับอุปกรณ์แต่ละตัวแล้ว ยังน่าเชื่อด้วยว่ามันทำงานได้อย่างปลอดภัย และคุ้มค่ามากพอที่จะขึ้น Hacker News

    • วลีที่ว่า “พอคิดอยู่นาน คำตอบก็ชัดเจน” เอาไปทำเป็น ข้อความบนเสื้อยืด ได้เลย
  • เห็นทีไรก็รู้สึกเสียดายนิดหน่อยที่การใช้ชิปแยกเพื่อเชื่อมต่อกับ USB กลายเป็นตัวเลือกพื้นฐาน
    USB เป็นโปรโตคอลที่ซับซ้อนเกินไป พอเกินระดับ V-USB พื้นฐานที่รัน USB 1.1 ความเร็วต่ำแล้ว โดยทั่วไปดูเหมือนจะทำได้ยากถ้าไม่มีฮาร์ดแวร์เฉพาะกับซอฟต์แวร์สแต็กที่ค่อนข้างใหญ่
    ในทางกลับกัน SPI นั้นเรียบง่ายอย่างเหลือเชื่อ ฮาร์ดแวร์ขั้นต่ำที่ต้องใช้ก็แค่ประมาณ shift register ที่รับ clock ได้เร็วพอ
    คิดถึงยุคที่เดสก์ท็อปกับโน้ตบุ๊กสมัยก่อนมีพอร์ต serial/parallel เปิดออกมาภายนอก ทำให้สื่อสารระดับต่ำแบบนี้ได้
    ถ้าอุปกรณ์ต่อพ่วงง่าย ๆ ใช้ UART, I2C, SPI แบบ multidrop ในระยะสั้น ๆ ด้วย clock มาตรฐานไม่กี่แบบและคอนเนกเตอร์เดียว ส่วนอุปกรณ์ที่มีข้อมูลเยอะอย่างจอภาพหรือไดรฟ์ภายนอกก็ข้ามไปใช้ IEEE 802.3 Ethernet โดยตรง บางทีอาจไม่จำเป็นต้องรองรับทั้ง USB และ Ethernet แยกกัน แค่รองรับลิงก์ Ethernet ก็พอ

    • จริงที่ SPI เรียบง่าย และเดิมทีก็เป็นโปรโตคอลที่ออกแบบมาให้ใช้ซิลิคอนน้อยที่สุดเท่าที่เป็นไปได้เพื่อประหยัดงบทรานซิสเตอร์
      SPI ไม่ได้คำนึงถึงความสะดวกหลายอย่างที่ USB มีให้ เช่น การจ่ายไฟ, hot-plug, การค้นพบอุปกรณ์, ข้อผิดพลาดของบิต
      การที่นักพัฒนาซอฟต์แวร์เข้าใจ สำนวนการใช้ SPI และวิธีที่นักออกแบบฮาร์ดแวร์ใช้ SPI นั้นมีคุณค่า
      โดยปกติ SPI ใช้สำหรับเติมค่า register ของอุปกรณ์ต่อพ่วง และมีลักษณะต่างจากการสื่อสารแบบ asynchronous ระดับสูงที่พบบ่อยใน USB หรือ Ethernet รวมถึงชั้น abstraction ด้านบน
      SPI frame ไม่มีมาตรฐานสากล แต่มีแพตเทิร์นที่นิยมใช้กัน และนั่นก็เพียงพอสำหรับการใช้งานนับไม่ถ้วนแล้ว
    • ฟังดูเหมือนกำลังเสนอให้เปลี่ยน USB PHY เป็น ตัวแปลง serial-to-Ethernet กับ Ethernet PHY
      ในความเป็นจริง โปรโตคอลเรียบง่ายอย่าง SPI และ I2C นั้นไม่เพียงพอ
      มันไม่เร็ว ใช้สัญญาณแบบ single-ended จึงไวต่อสัญญาณรบกวนมาก และไม่มีการแก้ไขข้อผิดพลาด
      โปรโตคอลเหล่านี้เหมาะมากกับการใช้งานที่ตั้งใจไว้ คือเชื่อม IC เข้าด้วยกันบน PCB แต่ถ้าเปิดพอร์ตที่ไม่มี termination ออกไปภายนอก ก็แทบรับประกันอะไรไม่ได้
      ใน PC สมัยใหม่ก็ยังใช้โปรโตคอลเหล่านี้และรูปแบบดัดแปลงอยู่มาก แต่เป็นบัสภายในเท่านั้น
      ยังไม่ได้ดูสเปก USB อย่างละเอียด แต่ปัญหาหลักของ bit-banging น่าจะเป็นความเร็วที่ต้องการ
      ไมโครคอนโทรลเลอร์ไม่เร็วพอที่จะ toggle พินไปพร้อมกับถอดรหัสโปรโตคอลและจัดการการแก้ไขข้อผิดพลาด จึงต้องใช้ฮาร์ดแวร์เฉพาะ
      แม้แต่ bit-banging I2C ก็อาจเจอปัญหาเดียวกัน
      clock สูงสุดที่ได้จาก CPU 20MHz อยู่ที่ราว 250KHz ซึ่งมากกว่าครึ่งหนึ่งของความเร็วสูงสุดทั่วไป 400KHz เพียงเล็กน้อย และเวอร์ชัน 1MHz แทบเป็นไปไม่ได้
      เหตุผลที่มี PHY ก็เพราะการย้ายโปรโตคอลสื่อสารไปทำในฮาร์ดแวร์นั้นถูกกว่ามากอย่างท่วมท้น
      ไม่เช่นนั้นต้องเผื่อ CPU ให้แรงเกินจำเป็นเพื่อให้มีทรัพยากรจัดการการสื่อสารด้วยมือ และนั่นคือเหตุผลที่ไมโครคอนโทรลเลอร์สมัยใหม่มีฮาร์ดแวร์สำหรับ I2C, SPI และ serial communication มาให้
      สรุปคือโปรโตคอล serial แบบง่าย ๆ อย่าง SPI, I2C, UART เป็นตัวเลือกที่แย่มากสำหรับอุปกรณ์ต่อพ่วงภายนอก
      มันทำงานที่ความเร็วเหมาะสมได้ยาก และทนสายยาวกับสัญญาณรบกวนไม่ได้
      แม้จะยกเว้น RS-232 ไว้เพราะไม่ใช่ UART แต่ด้วยลักษณะและการออกแบบของโปรโตคอลเหล่านี้ มันใช้ในลักษณะนี้ไม่ได้ และถ้าจะแก้สเปกให้รองรับ สุดท้ายก็จะกลายเป็นการประดิษฐ์ USB ขึ้นมาใหม่อยู่ดี
    • ในวงการ AV แม้ฮาร์ดแวร์ใหม่จะราคาเกิน 10,000 ดอลลาร์ RS-232 ก็ยังเป็นราชาสำหรับสัญญาณควบคุมระหว่างอุปกรณ์
      ป้ายดิจิทัลหรือจอทีวีสำหรับห้องประชุมก็มักมี RS-232 ให้ใช้เพื่อการควบคุมที่ยืดหยุ่นกว่า HDMI-CEC
      หลายกรณีไม่จำเป็นต้องใช้ bitrate สูงกว่า 9600bps และคอนเนกเตอร์ที่พบบ่อยที่สุดคือ terminal block แบบสกรู 3 พินสำหรับ Tx, Rx, GND
      การติดตั้งยุคนี้มักมีอะแดปเตอร์ RS232-USB อย่างน้อยหนึ่งตัวอยู่ที่ไหนสักแห่ง และในห้องขนาดใหญ่ก็ bridge RS232 ผ่าน Ethernet
      ตอนเข้ามาทำงานสายนี้ครั้งแรกก็รู้สึกแปลกใจ แต่พอนึกว่าการติดตั้งจำนวนมากมีอายุหลายสิบปีและค่อย ๆ เปลี่ยนส่วนประกอบทีละชิ้น ก็เข้าใจได้
    • บทความไล่ดูชิป 8 พินค่อนข้างยาว แต่กลับขาด CH32V003 ที่ได้รับความนิยมมาก
      ชิปนี้อยู่ระดับ 0.10 ดอลลาร์ มี RAM 2KB, Flash 16KB, 48MHz และทำงานที่ 1 CPI
      CH570 รุ่นใหม่ก็อยู่ระดับ 0.10 ดอลลาร์ในแพ็กเกจ SOIC8 แต่มี 100MHz, RAM 16KB, Flash 256KB, USB และวิทยุแพ็กเก็ต 2.4GHz ด้วย และผมสั่งบอร์ดพัฒนาไว้แล้ว
    • มีไมโครคอนโทรลเลอร์จำนวนมากที่ทำงานเป็นอุปกรณ์ USB ได้ แต่ครั้งนี้ถูกตัดออกเพราะ ข้อจำกัดด้านแพ็กเกจ
  • สำหรับคนที่อยากทำบอร์ดเอง น่าจะระบุ ความหนาของแผ่น PCB ที่ต้องใช้ไว้ด้วย
    ถ้าจำไม่ผิดน่าจะประมาณ 0.8mm และ “USB-C edge connector” ต้องใช้ความหนานั้นถึงจะพอดีกับปลั๊ก

  • เป็นบทความที่ยอดเยี่ยม แต่ก็อดสงสัยไม่ได้ว่าถ้ายืดหยุ่นกับข้อกำหนด 8 พินขึ้นอีกนิด มันอาจง่ายกว่านี้มากหรือเปล่า
    แค่มีพินเพิ่มอีกไม่กี่พินก็น่าจะลดความซับซ้อนของโปรเจกต์ได้มาก และเพิ่มเวลาบัดกรีเพียงนิดเดียวเท่านั้น

    • ถ้าอย่างนั้นก็ไม่ใช่ความท้าทายและคงไม่สนุกเลย
      มีชิปที่เร็วกว่าเยอะและมี USB ในตัวมากมาย
      Allwinner V3s ก็บัดกรีด้วยมือได้ มี RAM ในตัว และบูต Linux แบบเนทีฟได้ดี
      RP2350 ก็เป็นตัวเลือกที่ดี และมีอินเทอร์เฟซ QSPI RAM ที่ยอดเยี่ยมพร้อม cache ในตัว รวมถึงรองรับ USB
  • แทบจะเรียกได้ว่าเป็นโปรเจกต์ที่ใช้ชิปแค่ 2 ตัว
    ตัวหนึ่งก็เป็นแค่ IC USB-to-serial และถ้าไม่นับการ์ด SD พอนับรวมการ์ด SD เข้าไปก็กลับมาเป็น 3 ตัว
    จำนวนขาทั้งหมดมีน้อยมากจนทำให้อยากลองประกอบแบบ dead bug

    • ยังไม่มีใครทำเวอร์ชัน dead bug ดังนั้นถ้าทำก็จะเป็นตัวอย่างแรก
      อะแดปเตอร์ microSD-to-SD ใช้เป็นช่องใส่ microSD ที่บัดกรีได้ค่อนข้างดี
    • ในการ์ด SD เองก็มีโปรเซสเซอร์ที่ทรงพลังพอสมควรอยู่ด้วย และน่าจะเป็น ARM 32 บิต
      การทำทริกคล้าย ๆ กันโดยเล็งไปที่ตัวนั้นก็น่าจะเป็นแฮ็กที่น่าสนุก
    • ถ้าแยก IC USB-to-serial ไปอยู่ฝั่งสายเคเบิลที่คนอื่นทำไว้ ก็ “ไม่นับ” ได้ คล้ายกับการไม่นับ microSD
  • ในเชิงเทคนิคเป็นโปรเจกต์ที่เจ๋งมาก แต่ดูเหมือนไปสุดทางจนค่อนข้างหลุดจากเป้าหมายที่จะทำคิทคอมพิวเตอร์ใหม่สำหรับมือใหม่
    สำหรับมือใหม่ การบัดกรี SOIC8 กับ SOIC28 ไม่ได้ต่างกันมากนัก
    ผมมองว่า SOIC28 ก็ง่ายหรือยากพอ ๆ กับ SOIC8
    ถ้าใช้ชิปที่ใหญ่ขึ้น ก็สามารถเพิ่มเสียงพื้นฐาน คีย์บอร์ด และภายหลังแม้แต่เอาต์พุตจอจริงแบบ VGA ได้ ทำให้กลายเป็นคอมพิวเตอร์ที่มีประโยชน์กว่ามาก
    โดยที่ความยากในการบัดกรีแทบไม่เพิ่มขึ้น และยังเป็นฐานที่ดีให้ผู้ใช้ที่เริ่มสนใจนำไปต่อยอดได้

    • ใช่
      ถ้าอยากทำไปในแนวนั้น ใช้โค้ดของผมได้เลย
      ผมทำแบบนี้เพราะสนุกกับ ข้อจำกัดที่ตั้งขึ้นเองว่าต้องมี 8 ขา
  • เกิดแรงกระตุ้นแปลก ๆ ที่อยากตัดแม้แต่แผงวงจรออก แล้วทำเป็น ประติมากรรมวงจร

    • ถ้าทำแบบนั้น IC ตัวหนึ่งควรสกรีนคำว่า “555” ไว้ด้วย
    • ถ้าทำได้ก็น่าจะดี
      ผมไม่ใช่ศิลปินหรือประติมากร เลยไม่กล้าลอง
  • ถ้าใช้ SPI Flash แบบ 8 ขา แทนการ์ด SD เป็นสตอเรจ ก็น่าจะน่ารักดี

    • เคยพิจารณาแล้ว แต่ถ้าทำแบบนั้น วิธีใส่และเอาไฟล์ออก จะยุ่งยากขึ้น
  • บอกว่า “แพ้ RISC-V ด้วยเหตุผลส่วนตัว” เลยสงสัยว่าเหตุผลคืออะไร

    • ไม่ชอบชุดคำสั่ง
      ไม่ได้อยากเปิดศึก flamewar และนี่ก็เป็นแค่ความเห็นส่วนตัว แต่เป็นความเห็นที่ค่อนข้างแรง
      RISC-V ถูกออกแบบมาช้ามากพอในเชิงประวัติศาสตร์จนควรจะใช้ความรู้เดิมที่มีอยู่ได้มากมาย แต่ผมมองว่ามันแทบไม่ได้ใช้สิ่งเหล่านั้นเลย
      ดังนั้นตอนนี้จึงมีส่วนขยายหลายอย่างถูกเสนอขึ้นมาเพื่อแก้สิ่งที่ควรทำให้ถูกต้องตั้งแต่แรก
      เมื่อมีการเพิ่มสิ่งต่าง ๆ เข้ามาเรื่อย ๆ ผ่านไป 10 ปี มันจึงค่อย ๆ เข้าใกล้รูปแบบที่พอสมเหตุสมผล
      ผมก็ไม่ยอมรับข้ออ้างว่าจำเป็นต้องมีช่วงเรียนรู้
      ข้อมูลที่จำเป็นมีอยู่ตั้งแต่แรก และข้อผิดพลาดก็ชัดเจนสำหรับพวกเราส่วนใหญ่
      ส่วนขยายบางอย่างเป็นเพียงพลาสเตอร์แปะปัญหาการออกแบบพื้นฐาน
      เช่น shadd2 เป็นพลาสเตอร์ที่ใช้ปะปัญหาการไม่มีโหมด addressing ที่เหมาะสมสำหรับการเข้าถึงอาร์เรย์
      คำตอบที่พบได้บ่อยต่อเรื่องนี้คือการสัญญาว่าจะมีการ fuse คำสั่งแบบเวทมนตร์ภายในคอร์ ซึ่งถูกสัญญาอยู่บ่อย ๆ แต่แทบไม่ถูกส่งมอบจริง
      โดยเฉพาะในโปรเซสเซอร์ราคาถูกที่ดูเหมือนจะเป็นเป้าหมายเดียวของ RISC-V ยิ่งไม่ใช่เลย
      การไม่มีคำสั่งสำหรับดึงและแทรก bitfield ก็เป็นความผิดพลาดแบบสมัครเล่น และจึงมีส่วนขยายที่แก้เรื่องนี้เช่นกัน
      แต่ความจำเป็นของฟีเจอร์แบบนั้นควรชัดเจนตั้งแต่แรก
      คำสั่ง branch ตามบิตเฉพาะในเรจิสเตอร์ก็พบได้บ่อย จึงเป็นฟีเจอร์ชัดเจนที่ควรถูกพิจารณาตั้งแต่แรก
      แค่วิเคราะห์ซอฟต์แวร์สมัยใหม่เล็กน้อยก็น่าจะเห็นแล้ว
      สิ่งที่น่าหงุดหงิดคือข้อมูลเหล่านี้มีอยู่แล้ว
      เรารู้ว่าซอฟต์แวร์สมัยใหม่ทำอะไรบ้าง แต่กลับถูกมองข้ามทั้งหมด และผลลัพธ์ที่ได้ผมมองว่าเป็น MIPS-1 ที่อัปเดตขึ้นมานิดหน่อย
      ตอนนี้เมื่อมีส่วนขยายติดพ่วงเข้ามาเต็มไปหมด ก็เกิด fragmentation อย่างหนัก
      อาจตั้งเป้าไปที่ผลลัพธ์สุดท้ายที่ค่อนข้างสมเหตุสมผลอย่าง RV23 ได้ แต่ก็ไม่มีฮาร์ดแวร์ที่ implement มัน หรือไม่ก็ต้องตั้งเป้าไปที่ตัวหารร่วมต่ำสุดที่รันได้ทุกที่แต่ทำงานได้แย่
      เวลาพยายามใช้ RISC-V กับงานคอมพิวติ้งประสิทธิภาพสูงจริง ๆ ยังมีปัญหาการออกแบบที่ร้ายแรงกว่านี้อีก แต่ขอยกไปไว้ใน rant ครั้งหน้า
      มีชุดคำสั่งอีกตัวที่ออกแบบในช่วงเวลาใกล้เคียงกัน ซึ่งใช้ความรู้เกี่ยวกับหน้าตาของซอฟต์แวร์สมัยใหม่จริง ๆ และผลลัพธ์ก็เห็นได้ชัด: aarch64
  • ตัวโปรเจกต์เองก็เจ๋งมาก แต่หน้านี้ยังเป็นแหล่งข้อมูลที่ยอดเยี่ยมสำหรับข้อมูลไมโครคอนโทรลเลอร์ขนาดเล็กด้วย
    แม้จะไม่มีตระกูล WLCSP แต่ยังเชื่อมไปยังหน้าอีมูเลเตอร์ MIPS สำหรับ ARM https://dmitry.gr/?r=05.Projects&proj=33.%20LinuxCard ซึ่งก็ดูน่าสนใจทีเดียว