Hướng dẫn thay thế Vi điều khiển tương thích chân cắm (Pin-to-Pin)

Việc thay thế vi điều khiển tương thích chân (pin-compatible) là một MCU khớp với cùng sơ đồ chân và đóng gói như linh kiện gốc, do đó nó có thể lắp trên cùng một bảng mạch, và đối với hầu hết các kỹ sư, phần khó hơn của câu hỏi là liệu nó có chạy cùng một mã code hay không. Không giống như bộ điều chỉnh điện áp hay chip logic, một vi điều khiển mang lớp tương thích thứ hai là firmware, và một linh kiện khớp với mọi chân cắm vẫn có thể làm hỏng dự án nếu lõi, bản đồ thanh ghi (register map) hoặc các ngoại vi của nó khác với bản gốc. Tuy nhiên, thế giới vi điều khiển lại có thị trường thay thế tương thích chân hoạt động sôi nổi nhất trong ngành điện tử, bởi vì một thiết bị thống trị như STM32F103 xác định một sơ đồ chân mà hàng loạt nhà sản xuất tái sản xuất, với các nhà sản xuất nội địa xây dựng các linh kiện tương thích chân và phần lớn tương thích mã code được kiểm định trên cùng một bảng mạch. Hướng dẫn này giải thích hai lớp tương thích, cách hệ sinh thái STM32 hoạt động như một ví dụ thực tế, cách kiểm tra sơ đồ chân và bản đồ thanh ghi, cách thực hiện quy trình khởi chạy firmware (bring-up) để kiểm định việc hoán đổi, và khi nào việc thay thế là không đủ, để việc thay thế vi điều khiển tương thích chân là một quyết định kỹ thuật được ghi chép đầy đủ thay vì là một canh bạc trên bàn thử nghiệm.

Lý do tại sao việc thay thế vi điều khiển xứng đáng có hướng dẫn riêng là vì các chế độ lỗi thường vô hình đối với việc kiểm tra sơ đồ chân. Một linh kiện thay thế dùng chung gói LQFP48 và tên chân có thể khác nhau về độ phân giải ADC, tính năng timer, các kênh DMA, các chân boot, hoặc cây xung nhịp (clock tree), và những khác biệt này sẽ lộ diện dưới dạng lỗi firmware, thiếu ngoại vi và các lỗi chập chờn ở nhiệt độ cao. Do đó, việc kiểm định là một quy trình xem xét ba lớp cộng với việc khởi chạy firmware: các chân vật lý, các thông số điện, khả năng tương thích thanh ghi và ngoại vi, và sau đó là firmware đã biên dịch và đang chạy trên một bảng mạch tham chiếu. Tin tốt là các ghi chú chuyển đổi của nhà sản xuất và các ma trận tương thích tồn tại chính xác cho mục đích này, lộ trình từ STM32 sang GD32 đã được tài liệu hóa, và một người mua đọc chúng có thể kiểm định một MCU thay thế trong vài ngày thay vì vài tháng. Hướng dẫn này biến lộ trình đó thành một phương pháp, và đó là phương pháp mà các kỹ sư của trang web này áp dụng cho mọi linh kiện vi điều khiển thay thế mà họ cung cấp.

Ý nghĩa của việc thay thế Vi điều khiển tương thích chân cắm (Pin-Compatible)

Thay thế vi điều khiển tương thích chân cắm là việc sử dụng một MCU có cùng cách bố trí các chân trên cùng một loại gói vỏ (package) như linh kiện gốc, và thuật ngữ này có ý nghĩa kỹ thuật chính xác làm nền tảng cho quy trình thay thế. Gói vỏ phải khớp nhau, ví dụ thay thế LQFP48 cho linh kiện gốc LQFP48, và sơ đồ chân (pinout) phải khớp, từ các chân nguồn, chân nối đất, chân dao động, chân reset, chân debug, cho đến mọi chân GPIO và ngoại vi đều phải mang cùng một chức năng tại cùng một vị trí, để bảng mạch có thể lắp linh kiện thay thế mà không cần thiết kế lại (re-layout). Sự tương thích chân cắm là lớp vật lý, nó là điều kiện cần nhưng chưa đủ, bởi vì giá trị của một vi điều khiển nằm ở những gì firmware điều khiển nó thực hiện, và firmware chạy trên lõi (core), bản đồ thanh ghi (register map), và các ngoại vi mà sơ đồ chân không hiển thị. Do đó, một linh kiện thay thế tương thích chân cắm phải được đánh giá trên cả hai lớp, và lớp thứ hai, sự tương thích mã nguồn (code compatibility), mới là yếu tố quyết định phần lớn các trường hợp hoán đổi MCU cuối cùng. Quy trình thay thế tương thích chân cắm là sự kết hợp của hai lớp: phần lắp vừa và phần chạy được, và tài liệu hướng dẫn này coi trọng cả hai lớp như nhau.

Hai lớp này cũng định nghĩa hai loại MCU thay thế mà thị trường cung cấp. Một giải pháp thay thế tương thích chân cắm khớp về chân và gói vỏ, nhưng có thể khớp hoặc không khớp về mã nguồn, vì vậy bảng mạch có thể lắp được nhưng firmware có thể cần phải chuyển đổi (porting). Một giải pháp thay thế tương thích cả chân cắm và mã nguồn sẽ khớp về chân và hướng tới sự tương thích phần mềm, cùng dòng lõi, cùng bản đồ thanh ghi, và cùng hành vi ngoại vi, nhờ đó firmware có thể biên dịch và chạy với rất ít hoặc không cần thay đổi, và đây là hình thức có giá trị cao hơn. Các nhà sản xuất nội địa trong hệ sinh thái STM32 xây dựng hình thức thứ hai, như các dòng GD32 và AT32, chúng không chỉ tương thích chân cắm mà còn tương thích thanh ghi và tập lệnh đủ để chạy phần lớn firmware gốc. Câu hỏi của người mua luôn là ứng viên thuộc hình thức nào, chỉ tương thích chân (pin-only) hay tương thích cả chân và mã (pin-and-code), và câu trả lời sẽ quyết định chi phí kiểm định: ứng viên chỉ tương thích chân yêu cầu nỗ lực chuyển đổi mã, còn ứng viên tương thích cả chân và mã yêu cầu nỗ lực xác minh. Tài liệu hướng dẫn kiểm tra hình thức trước khi kiểm định, và hình thức là yếu tố đầu tiên của mọi hoạt động thay thế MCU.

Tại sao vi điều khiển cần một lớp mã nguồn mà các IC khác không có

Lớp mã nguồn tồn tại vì vi điều khiển là một thiết bị có thể lập trình, và chương trình nó chạy là một phần của thiết kế tương đương như các chân cắm. Việc thay thế một bộ điều áp được đánh giá bằng hành vi điện tử, và một chip logic bằng chức năng của nó, nhưng việc thay thế một MCU được đánh giá bằng việc liệu firmware đã lưu trữ — tệp nhị phân đã biên dịch mà linh kiện gốc thực thi — có chạy chính xác trên ứng viên thay thế hay không. Firmware phụ thuộc vào kiến trúc lõi, tập lệnh, kích thước flash và SRAM, bản đồ thanh ghi của các ngoại vi, cây xung nhịp (clock tree), bộ điều khiển ngắt, và hành vi khởi động (boot), và bất kỳ sự khác biệt nào trong số đó cũng dẫn đến việc tệp nhị phân không chạy, ngoại vi không phản hồi, hoặc thời gian (timing) bị sai lệch. Lớp mã nguồn là lý do khiến việc thay thế MCU không thể được phê duyệt chỉ dựa trên sơ đồ chân, và đó là lớp mà quy trình kiểm tra vận hành firmware (firmware bring-up) tồn tại để xác minh. Người mua và kỹ sư hiểu rõ lớp mã nguồn sẽ đọc các ghi chú chuyển đổi (migration notes) và bản đồ thanh ghi trước khi xem xét các chân, bởi vì mã nguồn là phần của MCU mà bảng mạch thực sự sử dụng, và khả năng tương thích mã nguồn là điểm khác biệt giữa một linh kiện thay thế và một dự án mới.

Hệ sinh thái STM32 và các lựa chọn thay thế tương thích chân cắm

Hệ sinh thái STM32 là ví dụ điển hình về việc thay thế vi điều khiển tương thích chân cắm, bởi vì đây là dòng sản phẩm có nhiều lựa chọn thay thế được tài liệu hóa nhất và có thị trường thay thế năng động nhất. STM32F103, linh kiện Cortex-M3 cổ điển đã cung cấp năng lượng cho một thế hệ bo mạch, xác định sơ đồ chân LQFP48 mà nhiều thiết bị cùng chia sẻ, và các tài liệu di trú cũng như tính tương thích nêu rõ thiết bị nào tương thích chân cắm và những thay đổi mã nguồn nào cần thiết khi hoán đổi. Các nhà sản xuất nội địa đã xây dựng lớp thú vị nhất của hệ sinh thái: GD32F103 của GigaDevice và dòng GD32, AT32F403A của Artery, cùng phạm vi rộng lớn các linh kiện Cortex-M nội địa và tương thích chân cắm, vốn không chỉ nhắm mục tiêu vào các chân cắm mà còn cả phần mềm, với bản đồ thanh ghi và hệ sinh thái trình điều khiển được thiết kế để chấp nhận firmware của STM32 với việc chuyển đổi hạn chế. Hệ sinh thái này là lý do tại sao cụm từ thay thế vi điều khiển tương thích chân cắm tên gọi một thị trường thực tế thay vì một khả năng lý thuyết, và đó là lý do tại sao một người mua với thiết kế dựa trên STM32 có các lựa chọn thay thế thực sự khi STM32 khan hiếm, tăng giá hoặc ngừng sản xuất.

Hệ sinh thái cũng cho thấy hai lớp đang hoạt động, và ma trận tương thích là tài liệu ánh xạ chúng. Các datasheet của chính ST và các hướng dẫn di trú dòng sản phẩm nêu rõ thiết bị nào chia sẻ sơ đồ chân, bộ nhớ flash và tập hợp ngoại vi, còn các nhà sản xuất nội địa công bố bảng tương thích của riêng họ nêu rõ linh kiện của họ thay thế thiết bị STM32 nào và sự khác biệt là gì. Ma trận là điểm bắt đầu của mọi hoạt động thay thế, vì nó nêu tên ứng viên, mức độ tương thích và các điểm khác biệt trước khi việc xem xét datasheet bắt đầu. Người mua đọc ma trận cho thiết bị chính xác trên bo mạch, ví dụ STM32F103C8T6 và các ứng viên tương thích chân cắm và mã nguồn của nó, sau đó xác minh ma trận so với firmware thực tế và bo mạch thực tế, bởi vì ma trận là một khẳng định mà thử nghiệm khởi động (bring-up test) sẽ xác nhận. Hệ sinh thái là bản đồ, ma trận là lộ trình, và việc khởi động là bằng chứng, và cả ba cùng nhau tạo nên phương pháp mà hướng dẫn này áp dụng cho mọi trường hợp thay thế MCU.

Các lựa chọn thay thế GD32 và AT32 cho STM32

Dòng GD32 và AT32 là những lựa chọn thay thế tương thích chân cắm nổi tiếng nhất cho STM32, và việc hiểu rõ hình thái của chúng giúp người mua đọc được hệ sinh thái. GD32F103 của GigaDevice mô phỏng sơ đồ chân LQFP48 của STM32F103 và hướng tới khả năng tương thích phần mềm với lõi Cortex-M3, cùng dải flash và SRAM, và một bản đồ thanh ghi được thiết kế để chạy firmware STM32 với việc chuyển đổi hạn chế, và dòng sản phẩm của nó mở rộng mô hình này trên khắp danh mục GD32. AT32F403A của Artery và dòng AT32 cũng áp dụng cách tiếp cận tương tự, với các linh kiện tương thích chân cắm hướng tới cùng khả năng tương thích phần mềm và bổ sung các biến thể về hiệu suất và tính năng của riêng chúng. Các lựa chọn thay thế không được đảm bảo giống hệt nhau, ADC, bộ định thời (timers), cây xung nhịp (clock tree) và bản đồ thanh ghi ngoại vi có thể khác nhau ở các chi tiết mà firmware sử dụng, và những khác biệt đó chính xác là những gì ghi chú di trú và thử nghiệm khởi động làm lộ diện. Người mua khi đánh giá một linh kiện GD32 hoặc AT32 sẽ đọc ma trận tương thích, so sánh bản đồ ngoại vi mà firmware thực tế sử dụng, biên dịch và chạy firmware trên ứng viên, và thử nghiệm trên toàn bộ dải nhiệt độ. Các lựa chọn thay thế là câu trả lời của thị trường đối với sự khan hiếm và giá cả của STM32, và việc đánh giá chất lượng là kỷ luật giúp câu trả lời đó trở nên an toàn.

Cách kiểm tra tính tương thích của chân cắm (Pin Compatibility) cho Vi điều khiển

Việc kiểm tra tính tương thích của chân cắm cho một vi điều khiển là quy trình xem xét ba lớp giống như bất kỳ sự thay thế nào, nhưng được thực hiện ở quy mô của MCU. Đầu tiên, hãy xác nhận kiểu đóng gói, LQFP48, QFP64, hoặc BGA, và hậu tố đóng gói chính xác, vì kiểu đóng gói quyết định footprint và số lượng chân của MCU được cố định bởi kiểu đóng gói đó. Thứ hai, so sánh sơ đồ chân (pinout), từng chân một, các chân nguồn và chân đất (ground), các chân bộ dao động (oscillator), các chân reset và boot, các chân debug và test, cùng mọi chân GPIO và ngoại vi, sử dụng sơ đồ chân từ hai datasheet, và ghi lại chức năng của mỗi chân vào một bảng với kết luận về độ khớp. Thứ ba, xác nhận các chức năng của chân, vì một chân có chức năng thay thế (alternate function) trên linh kiện gốc có thể chỉ là chân GPIO hoặc là một chân được đa hợp (multiplexed) khác trên linh kiện thay thế, và firmware sử dụng chức năng thay thế đó phải tìm thấy nó trên cùng một chân. Việc kiểm tra tính tương thích của chân là cực kỳ tỉ mỉ vì các chân của MCU đảm nhiệm nhiều chức năng thông qua bộ đa hợp, và chỉ cần một chân chức năng khác biệt, như chân boot, chân VBAT, hoặc một kênh ADC, có thể làm hỏng việc thay thế mà sự tương thích về kiểu đóng gói đã hứa hẹn.

Việc kiểm tra chân cũng bao gồm đọc các chức năng đa hợp và chức năng thay thế, đây là lớp đặc thù của MCU mà một linh kiện đơn giản không có. Một chân vi điều khiển mang một chức năng chính và một tập hợp các chức năng thay thế thông qua bộ đa hợp chân, và firmware sẽ gán các chức năng thay thế trong các thanh ghi. Linh kiện thay thế tương thích chân phải đặt các chức năng thay thế mà firmware sử dụng trên cùng các chân đó, như USART, SPI, I2C, các kênh timer, và các kênh ADC, và việc so sánh sẽ đọc các bảng chức năng thay thế của hai linh kiện. Việc so sánh này là nơi GD32 và STM32 khác biệt ở các chi tiết, và là nơi các ghi chú chuyển đổi (migration notes) phát huy giá trị, vì các ghi chú này nêu rõ chức năng thay thế nào đã thay đổi và thanh ghi nào đã khác đi. Do đó, tính tương thích chân của một vi điều khiển là sự kiểm tra về kiểu đóng gói, kiểm tra chân và kiểm tra đa hợp, và ba yếu tố này cùng nhau tạo thành lớp đầu tiên của việc thẩm định thay thế. Một linh kiện vượt qua cả ba bước này là tương thích về mặt vật lý, và lớp mã nguồn (code) sẽ quyết định phần còn lại.

Cách đọc sơ đồ pinout của MCU để thay thế

Đọc sơ đồ pinout của MCU để thay thế là một quá trình so sánh có kỷ luật, và nó dựa trên một vài thói quen đáng tin cậy. Đặt hai sơ đồ chân cạnh nhau, đánh số từ chân 1, và đi dọc theo chu vi theo thứ tự, kiểm tra chức năng của mọi chân so với bản gốc. Đánh dấu các chân nguồn và chân đất trước, sau đó đến các chân bộ dao động, reset, và boot, tiếp theo là các chân debug, và sau đó là các chân GPIO và ngoại vi, rồi ghi lại từng chân vào bảng với kết quả khớp, không khớp, hoặc chỉ có nguồn. Đọc các bảng chức năng thay thế cho các chân mà firmware sử dụng, và xác nhận chức năng thay thế đó nằm trên cùng một chân ở linh kiện thay thế. Đọc hậu tố đóng gói, vì LQFP48, QFP48 và TQFP48 không mặc định có cùng footprint, và xác nhận kích thước thân linh kiện cũng như khoảng cách chân (pin pitch) so với hình học của pad trên bảng mạch. Thói quen này tạo ra bảng tương thích chân mà hồ sơ thay đổi cần có, và chính bảng này biến những tuyên bố của linh kiện thay thế thành bằng chứng cho người mua. Một lần so sánh pinout được thực hiện theo cách này mất khoảng một giờ cho một MCU, và nó phát hiện ra những điểm sai lệch mà việc khớp kiểu đóng gói có thể bỏ lỡ, đó chính là giá trị của tính kỷ luật.

Cách kiểm tra khả năng tương thích của Mã nguồn và Thanh ghi cho Vi điều khiển

Kiểm tra khả năng tương thích của mã nguồn là lớp quyết định hầu hết các trường hợp thay thế MCU, và nó được thực hiện qua ba phần mà hành vi của firmware quy định. Phần đầu tiên là lõi (core) và tập lệnh, xác nhận rằng lõi của ứng viên, như Cortex-M3, Cortex-M4 hoặc loại khác, khớp với lõi gốc, và tập lệnh cũng như toolchain mà firmware được xây dựng có được hỗ trợ hay không, bởi vì một kiến trúc lõi khác sẽ thay đổi mã nhị phân đã biên dịch ở cấp độ lệnh. Phần thứ hai là bản đồ bộ nhớ (memory map), xác nhận kích thước flash và SRAM đáp ứng nhu cầu của firmware, đồng thời địa chỉ gốc và bố cục bộ nhớ boot khớp với linker script, vì firmware mong đợi bản đồ bộ nhớ gốc sẽ bị lỗi (crash) trên một bản đồ khác. Phần thứ ba là ngoại vi và bản đồ thanh ghi, xác nhận các ngoại vi mà firmware sử dụng như clock tree, GPIO, timer, USART và SPI, ADC, DMA, và các ngắt (interrupts) có tồn tại trên ứng viên với cùng các thanh ghi và hành vi tương tự hay không. Ba phần này được đọc từ các ghi chú chuyển đổi (migration notes) và bản đồ thanh ghi, chúng là datasheet của lớp mã nguồn, tài liệu nêu rõ những gì firmware có thể mong đợi.

Khả năng tương thích thanh ghi là những chi tiết nhỏ của lớp mã nguồn, bởi vì firmware đọc và ghi trực tiếp vào các thanh ghi, và một thanh ghi bị di chuyển, thay đổi ý nghĩa hoặc không tồn tại sẽ làm hỏng mã nguồn chạm vào nó. Việc so sánh sẽ đọc bản đồ thanh ghi của từng ngoại vi mà firmware sử dụng, điều khiển xung nhịp, GPIO, timer, các ngoại vi giao tiếp, ADC và DMA, đồng thời xác nhận các thanh ghi, các bit và hành vi khớp với bản gốc. Các ghi chú chuyển đổi nêu rõ sự khác biệt, các thanh ghi đã thay đổi, các ngoại vi khác biệt và những thay đổi về driver mà việc hoán đổi ngụ ý, và chúng là nguồn tài liệu có thẩm quyền vì nhà sản xuất sở hữu silicon. So sánh thanh ghi là cầu nối giữa datasheet và quá trình bring-up firmware, vì nó dự đoán nơi quá trình bring-up sẽ thất bại, và bring-up sẽ xác nhận nơi dự đoán đó là đúng. Một ứng viên có bản đồ thanh ghi khớp với cách sử dụng của firmware là tương thích về mã nguồn trên lý thuyết, và thử nghiệm bring-up là bằng chứng cho thấy nó tương thích trong mã nguồn đang chạy.

Cách so sánh bản đồ ngoại vi mà firmware thực sự sử dụng

So sánh bản đồ ngoại vi là vấn đề biết firmware thực sự chạm vào những gì, và kiến thức đó đến từ mã nguồn thay vì từ datasheet. Hãy liệt kê các ngoại vi mà firmware khởi tạo và điều khiển, xung nhịp, các cổng và chân GPIO, các timer và kênh của chúng, USART, SPI và I2C, các kênh ADC, DMA, các ngắt và watchdog, và đối với mỗi loại, hãy liệt kê các thanh ghi mà mã nguồn đọc và ghi. So sánh bản đồ thanh ghi của ứng viên cho từng ngoại vi với bản gốc, và đánh dấu các thanh ghi cũng như các bit khác biệt, các timer có số lượng kênh khác nhau, ADC có độ phân giải hoặc sơ đồ kênh khác nhau, và DMA có bản đồ yêu cầu (request map) khác nhau. Việc so sánh là bản đồ của nỗ lực chuyển đổi (porting), bởi vì các ngoại vi khớp nhau thì không cần xử lý, các ngoại vi khác biệt cần thay đổi driver, và các ngoại vi không tồn tại cần phải thiết kế lại. So sánh bản đồ ngoại vi là câu trả lời chuyên nghiệp cho lớp mã nguồn, và đó là lý do tại sao người mua có thể ước tính chi phí chuyển đổi của một ứng viên chỉ tương thích về chân cắm trước khi quá trình bring-up bắt đầu. Bản đồ này biến firmware từ một chiếc hộp đen thành một danh sách kiểm tra, và danh sách kiểm tra đó là những gì thử nghiệm bring-up thực hiện.

Firmware Bring-Up: Sự Thẩm định Thực tế cho việc Thay thế MCU

Firmware bring-up là bài kiểm tra thẩm định việc thay thế MCU, và đây là bước mà datasheet cũng như việc xem xét thanh ghi không thể thay thế được. Quá trình bring-up chạy theo từng giai đoạn, mỗi giai đoạn xây dựng dựa trên giai đoạn trước đó. Giai đoạn đầu tiên là toolchain, xác nhận trình biên dịch (compiler), trình liên kết (linker), trình gỡ lỗi (debugger) và gói thiết bị (device pack) chấp nhận linh kiện thay thế và xây dựng firmware cho lõi của nó. Giai đoạn thứ hai là khởi động và xung nhịp (boot and clock), lập trình cho linh kiện và xác nhận nó khởi động, vector ngắt reset, mã khởi động (startup code) và cây xung nhịp (clock tree) tạo ra các mức xung nhịp như mong đợi. Giai đoạn thứ ba là bring-up ngoại vi, vận hành mọi ngoại vi mà firmware sử dụng, bao gồm GPIO, các bộ định thời (timers), USART và SPI, ADC, DMA, và các ngắt, sau đó so sánh hành vi và thời gian (timing) với thiết bị gốc. Giai đoạn thứ tư là kiểm tra hệ thống, chạy toàn bộ firmware trong ứng dụng thực tế, và giai đoạn thứ năm là chạy thử nghiệm độ bền (soak test), vận hành sản phẩm trong suốt dải điện áp và nhiệt độ hoạt động để làm lộ ra các khác biệt không liên tục. Quá trình bring-up là trọng tài của toàn bộ việc thay thế, và một linh kiện vượt qua nó là một sự thay thế hoàn hảo, trong khi linh kiện thất bại sẽ trở thành một dự án chuyển đổi mã nguồn (porting) hoặc một lựa chọn không khả thi.

Quá trình bring-up cũng tạo ra bằng chứng mà việc thay thế cần có, bởi vì sự thẩm định chỉ có giá trị khi nó được ghi chép lại. Hãy ghi lại kết quả toolchain, các phép đo khởi động và xung nhịp, kết quả bring-up ngoại vi, kết quả đạt kiểm tra hệ thống và nhật ký soak test, bên cạnh các phép đo của thiết bị gốc, và lưu giữ hồ sơ này cùng với ghi chú thay đổi. Hồ sơ này là những gì một quy trình quản lý theo tiêu chuẩn ISO chấp nhận và là điều mà một xưởng kỹ thuật đơn lẻ thậm chí còn coi trọng hơn, bởi vì nó biến việc thay thế từ một sự kiện tại bàn kỹ thuật thành một quyết định có tài liệu đối chứng. Quá trình bring-up cũng thiết lập mốc thời gian, vì một linh kiện tương thích về chân cắm và mã nguồn với sơ đồ ngoại vi rõ ràng có thể hoàn tất bring-up trong vài ngày, trong khi một linh kiện chỉ tương thích chân cắm với sơ đồ ngoại vi khác biệt sẽ mất nhiều tuần để chuyển đổi mã nguồn. Mốc thời gian là thực tế kinh tế của việc thay thế, và đó là lý do người mua đọc sơ đồ ngoại vi trước khi bring-up, để biết linh kiện nào xứng đáng dành ra vài ngày và linh kiện nào xứng đáng dành ra vài tuần. Bring-up là trái tim của sự thẩm định, và hồ sơ ghi chép là tiếng nói của nó.

Cách thực hiện bài kiểm tra bring-up khi thay thế MCU

Thực hiện bài kiểm tra bring-up cho việc thay thế MCU là một quy trình theo từng giai đoạn mà phòng thí nghiệm có thể thực hiện theo một trình tự lặp lại. Bắt đầu với toolchain, cài đặt hỗ trợ thiết bị của linh kiện thay thế vào IDE, và xây dựng firmware gốc cho linh kiện đó, sửa các lỗi khởi động và cấu hình xung nhịp mà trình biên dịch phát hiện. Nạp chương trình vào linh kiện trên bo mạch tham chiếu, và xác nhận việc khởi động, reset, kết nối gỡ lỗi và các đầu ra xung nhịp, sử dụng máy hiện sóng và trình gỡ lỗi. Vận hành các ngoại vi mà firmware sử dụng, từng cái một, điều khiển GPIO, các bộ định thời, các cổng nối tiếp, ADC và DMA, sau đó so sánh dạng sóng và các giá trị với thiết bị gốc. Chạy toàn bộ ứng dụng và xác nhận chức năng của sản phẩm từ đầu đến cuối. Sau đó, chạy thử nghiệm độ bền bo mạch trong suốt dải điện áp và nhiệt độ mà sản phẩm sẽ gặp phải, và ghi lại các lỗi. Quy trình từng giai đoạn này giúp cô lập từng điểm khác biệt khi chúng xuất hiện, và nó tạo ra bằng chứng cho thấy việc thay thế đạt yêu cầu hoặc danh sách những gì cần chỉnh sửa. Một quá trình bring-up đạt đến bước soak test mà không có sự khác biệt nào là sự hoàn tất của việc thẩm định, và một quá trình bring-up thất bại ở một giai đoạn nào đó là điểm bắt đầu của quyết định chuyển đổi mã nguồn.

Những khác biệt về ngoại vi và tương tự làm hỏng việc thay thế

Những khác biệt làm hỏng việc thay thế MCU tương thích chân cắm là những thứ mà việc kiểm tra sơ đồ chân không thể thấy được, và các chi tiết về tương tự (analog) cũng như ngoại vi là nơi đầu tiên chúng tồn tại. ADC là ví dụ điển hình: một ứng viên có cùng các chân cắm có thể có độ phân giải khác nhau, sơ đồ kênh khác nhau, điện áp tham chiếu khác nhau hoặc thời gian chuyển đổi khác nhau, và firmware vốn đọc một kênh cụ thể trên một chân cụ thể với độ phân giải cụ thể sẽ bị lỗi hoặc sai lệch trên ứng viên đó. Cấu trúc xung nhịp (clock tree) là một ví dụ khác: một ứng viên có cùng các chân thạch anh có thể có cấu hình PLL khác nhau, nguồn xung nhịp khác nhau hoặc tần số tối đa khác nhau, và firmware vốn tính toán tốc độ baud và các bộ định thời (timer) từ xung nhịp gốc sẽ chạy sai trên ứng viên. Các bộ định thời và PWM, các ngoại vi giao tiếp cùng hành vi FIFO và DMA của chúng, cũng như các chân khởi động (boot) và gỡ lỗi (debug), mỗi thứ đều mang những chi tiết khác biệt trong một nhóm các linh kiện tương thích chân cắm. Những khác biệt này là lý do tại sao việc so sánh bản đồ ngoại vi và thử nghiệm khởi chạy (bring-up test) là cốt lõi của việc thẩm định, và người mua bỏ qua chúng sẽ phê duyệt một sự thay thế hoạt động tốt trên bàn thử nghiệm nhưng thất bại trong thực tế.

Các khác biệt về tương tự xứng đáng được cảnh báo riêng, bởi vì chúng là những lỗi thầm lặng nhất. Nhiễu và độ tuyến tính của ADC, điện áp tham chiếu, trở kháng đầu vào, hành vi của bộ so sánh và hệ số khử nguồn cấp khác nhau giữa các nhà sản xuất và giữa các phiên bản silicon, và một thiết kế dựa trên hành vi tương tự của linh kiện gốc sẽ coi những khác biệt đó là lỗi đo lường, trôi ngưỡng hoặc nhiễu. Các bộ khuếch đại thuật toán và bộ so sánh bên trong một MCU, nếu linh kiện có chúng, cùng với DAC và các công tắc tương tự, đều mang cùng một rủi ro. Việc thẩm định đường truyền tương tự là sự so sánh với hành vi đo được của linh kiện gốc, chứ không chỉ dựa trên datasheet, và chính thử nghiệm ngâm (soak test) qua nhiệt độ và nguồn cấp sẽ làm lộ ra sự sai lệch. Các khác biệt tương tự là lý do tại sao quá trình khởi chạy phải chạy thử nghiệm sản phẩm thực tế và vượt qua kiểm tra nhiệt độ, và người mua coi việc thay thế MCU như một sự thay thế thuần kỹ thuật số sẽ gặp phải rủi ro tương tự mà datasheet không bao giờ cam kết.

Cách so sánh hành vi ADC và bộ định thời khi thay thế MCU

So sánh hành vi ADC và bộ định thời (timer) khi thay thế MCU là một bài tập đo lường, và nó được thực hiện trên bo mạch thực tế. Đối với ADC, hãy cấu hình ADC của ứng viên chính xác như firmware thực hiện, về độ phân giải, kênh, điện áp tham chiếu và việc lấy mẫu, đọc một điện áp đã biết và so sánh mã code, độ tuyến tính trên toàn dải, nhiễu và thời gian ổn định so với thiết bị gốc. Đối với các bộ định thời, hãy cấu hình bộ định thời của ứng viên như firmware thực hiện, về bộ chia tần (prescaler), chu kỳ, các giá trị so sánh và các kênh, sau đó đo tần số, chu kỳ nhiệm vụ (duty), độ chập chờn (jitter) và hành vi kích hoạt so với bản gốc. Đối với PWM, bắt tín hiệu đầu vào (input capture) và thời gian chết (dead-time) nếu thiết kế có sử dụng, hãy thực hiện cùng một phép so sánh. Các phép đo được ghi lại bên cạnh các phép đo của linh kiện gốc, và các khác biệt như một chút sai lệch ADC, sự trôi chu kỳ bộ định thời hoặc độ chập chờn cạnh PWM, sẽ được đánh giá dựa trên dung sai của sản phẩm. Một ứng viên có ADC và bộ định thời khớp với bản gốc trong phạm vi dung sai của sản phẩm sẽ được thẩm định đạt, và ứng viên có hành vi sai lệch vượt quá phạm vi đó sẽ cần thay đổi driver hoặc thiết kế lại. Việc so sánh đo lường là trọng tài của lớp ngoại vi, và nó là bằng chứng mà thử nghiệm khởi chạy tạo ra.

Ví dụ Thực tế: Chuyển đổi Firmware UART và GPIO sang Linh kiện Thay thế

Chuyển đổi firmware UART và GPIO sang linh kiện thay thế là ví dụ thực tế trình bày lớp mã nguồn trong thực tiễn, và một firmware sử dụng GPIO cùng một UART ở tốc độ 115200 baud sẽ bao phủ các khía cạnh điển hình. Bước toolchain sẽ thêm gói thiết bị (device pack) của linh kiện thay thế và file startup vào dự án, và firmware được biên dịch dựa trên định nghĩa thiết bị của linh kiện thay thế, với trình biên dịch và trình liên kết (linker) sẽ làm lộ ra các điểm khác biệt đầu tiên. Bước cấu hình xung nhịp (clock) chuyển đổi cấu hình system-clock sang các thanh ghi xung nhịp của linh kiện thay thế, vì sơ đồ PLL khác nhau trong bố cục thanh ghi, và xung nhịp hệ thống đo được trên chân đầu ra sẽ xác nhận việc chuyển đổi thành công. Bước ngoại vi chuyển đổi GPIO và UART sang thư viện của linh kiện thay thế, và UART là một ví dụ mang tính hướng dẫn cao, vì thanh ghi tốc độ baud (baud-rate register) có cách tính toán khác và giá trị của ST được sao chép sang sẽ tạo ra một luồng dữ liệu bị lỗi, do đó cấu hình 115200 được tính toán lại từ công thức của linh kiện thay thế và được xác nhận trên đường truyền bằng một terminal. Bước ứng dụng chạy vòng lặp hiện có, GPIO đảo trạng thái và UART truyền dữ liệu giống như bản gốc, và hồ sơ khởi chạy (bring-up record) bao gồm biên dịch, xung nhịp, ngoại vi và ứng dụng là bằng chứng cho thấy việc thay thế đã đạt chuẩn. Ví dụ thực tế này là mô hình cho lớp firmware, và nó là mô hình mà phần bản đồ ngoại vi (peripheral-map) đã thiết lập.

Ví dụ thực tế cũng chỉ ra trình tự giúp việc chuyển đổi ít thất bại hơn, vì toolchain trước xung nhịp, xung nhịp trước ngoại vi, và ngoại vi trước ứng dụng là trình tự giúp khoanh vùng các lỗi khi chúng xuất hiện. Một quá trình chuyển đổi được biên dịch trước và xác minh từng giai đoạn trước khi sang giai đoạn tiếp theo sẽ biến một chuỗi các bất ngờ thành một chuỗi các giai đoạn đã được xác nhận, và hồ sơ của mỗi giai đoạn là bằng chứng mà quy trình kiểm soát thay đổi chấp nhận. Ví dụ thực tế là bộ mặt cụ thể của lớp mã nguồn, và nó là bộ mặt mà phần khởi chạy của hướng dẫn này chính thức hóa, đây là bước hoàn tất thực tế của phương pháp thay thế MCU.

Khởi chạy Ngoại vi: Một Trình tự Thực tế cho ADC

Trình tự khởi chạy ngoại vi cho ADC là ví dụ thực tế cho thấy lớp tương tự (analog) của việc hoán đổi MCU, và đây là nơi mà việc thay thế tương đương chân (pin-clean replacement) thường thất bại. Cấu hình ADC của linh kiện thay thế chính xác như firmware yêu cầu, bao gồm độ phân giải, kênh, điện áp tham chiếu và việc lấy mẫu, sau đó đọc một điện áp đã biết, so sánh mã code, độ tuyến tính trên toàn dải, nhiễu và thời gian ổn định so với các kết quả đọc của thiết bị gốc. Một linh kiện ứng viên có ADC cấu hình khác, sơ đồ kênh bị thay đổi, điện áp tham chiếu khác biệt hoặc độ phân giải thay đổi sẽ làm lộ ra sự khác biệt trong các giá trị đọc được, và việc chuyển đổi sẽ điều chỉnh cấu hình cũng như trình điều khiển (driver) firmware. Việc đo lường, các mã code tại các mức điện áp đã biết, nhiễu và độ ổn định là hồ sơ chứng minh lớp ADC đã đạt chuẩn, và nó là hồ sơ mà phần thử nghiệm ngâm (analog-soak) dựa vào. Việc khởi chạy ADC là mô hình cho mọi ngoại vi mà firmware điều khiển, từ bộ định thời (timers), cổng nối tiếp, DMA cho đến ngắt (interrupts), và nó là mô hình biến bản đồ ngoại vi từ một danh sách thành một hành vi đã được xác minh.

Việc khởi chạy ADC cũng xem xét hành vi theo nhiệt độ, vì lớp tương tự bị trôi (drift) trên toàn dải nhiệt độ theo cách mà lớp kỹ thuật số không gặp phải. Chạy việc đọc ADC trên toàn dải nhiệt độ của sản phẩm và so sánh độ trôi so với bản gốc và so với dung sai của sản phẩm, vì một ứng viên có ADC trôi quá dung sai ở mức nhiệt độ cao hoặc thấp là ứng viên mà thử nghiệm ngâm sẽ loại bỏ. Việc vượt qua kiểm tra nhiệt độ khi khởi chạy ADC là lý do tại sao quá trình đánh giá năng lực chạy trên toàn dải của sản phẩm thay vì chỉ trong điều kiện lý tưởng tại bàn làm việc, và đó là lý do tại sao lớp tương tự được kiểm tra trên bo mạch thay vì chỉ dựa trên datasheet. Trình tự ADC thực tế này hoàn tất một nửa quy trình khởi chạy của việc thay thế MCU, và đó là một nửa mà các giai đoạn cuối cùng của quy trình làm việc thực hiện, đánh dấu sự kết thúc thực tế của phương pháp.

Khi Việc Thay Thế MCU Tương Thích Chân Cắm Là Chưa Đủ

Những giới hạn thực tế của việc thay thế MCU là những trường hợp mà sơ đồ chân và mã nguồn không thể cứu vãn được thiết kế, và việc hiểu rõ chúng sẽ ngăn chặn một quá trình kiểm định lãng phí. Giới hạn đầu tiên là khoảng cách tính năng thực sự: một ứng viên có cùng số chân và bản đồ thanh ghi tương tự vẫn có thể thiếu một ngoại vi, một tính năng, một nhân, hoặc một mức hiệu suất mà firmware yêu cầu, một ADC với độ phân giải thấp hơn, một bộ định thời với ít kênh hơn, một ngoại vi USB với cách triển khai khác, hoặc một nhân quá chậm so với khối lượng công việc, và khoảng cách này buộc phải chuyển đổi mã nguồn hoặc thiết kế lại bất kể sơ đồ chân. Giới hạn thứ hai là linh kiện đã được chứng nhận hoặc phê duyệt: một MCU nằm dưới sự phê duyệt của cơ quan chức năng, phân loại an toàn chức năng, kiểm định y tế hoặc hàng không vũ trụ, hoặc chứng nhận bảo mật sẽ không thể hoán đổi với một giải pháp thay thế tương thích chân cắm trừ khi giải pháp đó có cùng chứng nhận, và chứng nhận được cấp theo từng thiết bị, không phải theo sơ đồ chân. Giới hạn thứ ba là sự phụ thuộc vào nhà cung cấp cụ thể: một ngăn xếp firmware dựa trên thư viện của nhà sản xuất, một trình điều khiển, một đơn vị mã hóa, hoặc một công cụ gỡ lỗi mà ứng viên không hỗ trợ sẽ buộc phải thực hiện nỗ lực chuyển đổi mã nguồn có thể vượt quá cả việc thiết kế lại. Mỗi giới hạn cần được đọc trước khi kiểm định thay vì được phát hiện sau đó, và việc đọc này chính là quá trình xem xét datasheet và ma trận mà phương pháp này luôn thực hiện.

Phản ứng đối với các giới hạn cũng giống như phản ứng đối với mọi sự thay thế: tìm nguồn cung, thay thế, hoặc thiết kế lại. Tìm nguồn cung linh kiện gốc khi nó vẫn còn sẵn có, thông qua kênh ủy quyền và các nhà cung cấp độc lập. Thay thế bằng giải pháp tương thích chân cắm và tương thích mã nguồn khi các chân, thanh ghi và firmware đủ điều kiện, và ghi lại quá trình triển khai. Và thiết kế lại xung quanh một MCU hiện tại khi khoảng cách tính năng, chứng nhận, hoặc sự phụ thuộc loại trừ giải pháp thay thế, với đầy đủ quy trình kỹ thuật và kế hoạch chuyển đổi. Quyết định được ghi lại cùng với bằng chứng, ma trận, bản đồ ngoại vi, hồ sơ triển khai và kiểm tra chứng nhận, để lần xem xét tiếp theo có thể thấy được lý do. Một chương trình thay thế MCU tương thích chân cắm hiểu rõ các giới hạn của nó là một chương trình hoán đổi các linh kiện có thể hoán đổi và lập kế hoạch cho các linh kiện không thể, và các giới hạn đó là ranh giới sức mạnh của sơ đồ chân, được tôn trọng bởi người kỹ sư xem xét lớp mã nguồn trước khi tin vào các chân cắm.

Quy trình thay thế Vi điều khiển tương thích chân cắm (Pin-Compatible)

Toàn bộ phương pháp này được đưa vào một quy trình làm việc mà kỹ sư và nhân viên thu mua cùng thực hiện theo trình tự. Thứ nhất, nắm bắt thông tin gốc, thiết kế chính xác, kiểu đóng gói, bộ nhớ flash và RAM, cùng firmware đang chạy, sau đó tải datasheet và các ghi chú chuyển đổi (migration notes). Thứ hai, sàng lọc các ứng viên, bảng ma trận tương thích và bảng tra cứu chéo (cross-reference), các dòng GD32, AT32 và các dòng khác trên thị trường, xác định ứng viên nào tương thích chân cắm (pin-compatible) và ứng viên nào tương thích cả chân cắm lẫn mã nguồn (pin-and-code-compatible). Thứ ba, kiểm tra các chân, kiểu đóng gói, sơ đồ chân (pinout) và các chức năng thay thế (alternate functions), sau đó lập bảng so sánh chân. Thứ tư, kiểm tra mã nguồn, lõi (core), bản đồ bộ nhớ (memory map), bản đồ ngoại vi (peripheral map) và các thanh ghi mà firmware sử dụng so với ghi chú chuyển đổi, từ đó ước tính nỗ lực chuyển đổi mã (porting effort). Thứ năm, khởi chạy thử nghiệm ứng viên, bộ công cụ (toolchain), quá trình khởi động (boot), các ngoại vi, kiểm tra hệ thống và chạy thử tải (soak test), sau đó ghi lại các thông số đo đạc bên cạnh thiết bị gốc. Thứ sáu, đưa ra quyết định chọn nguồn hàng, linh kiện thay thế hoặc thiết kế lại dựa trên bằng chứng thử nghiệm và chứng nhận, sau đó ghi lại quyết định. Thứ bảy, quản lý quá trình chuyển đổi, sản xuất thử nghiệm (pilot), tăng sản lượng (ramp) và quản lý kho hàng cũ, đồng thời cập nhật BOM và bảng tra cứu chéo. Trình tự đó chính là phương pháp thay thế MCU tương thích chân cắm, và nó là phương pháp duy nhất dù thiết bị gốc là STM32F103, GD32 hay bất kỳ thiết bị nào khác trên thị trường.

Quy trình làm việc này là lý do tại sao việc thay thế vi điều khiển tương thích chân cắm là một hoạt động kỹ thuật có thể quản lý và có tài liệu đối chiếu, chứ không phải là một canh bạc trên bàn thí nghiệm. Với ma trận đã được sàng lọc, các ứng viên đã được xác định rõ. Với các chân đã được kiểm tra, bảng mạch được bảo toàn. Với mã nguồn đã được kiểm tra, nỗ lực chuyển đổi được ước tính cụ thể. Và với việc chạy thử nghiệm, linh kiện thay thế được chứng minh qua firmware đang hoạt động, chứ không chỉ trên datasheet. Toàn bộ giá trị của phương pháp này là sự thay đổi quan trọng nhất trong điện tử — thứ mang theo cả firmware, định thời (timing) và hành vi tương tự (analog) — được xử lý bằng quy trình xem xét hai lớp và kỷ luật dựa trên bằng chứng giống như việc hoán đổi linh kiện đơn giản nhất. Kỷ luật đó chính là thứ biến các lựa chọn thay thế trong hệ sinh thái STM32 thành một phương án cung ứng khả thi. Một đội ngũ thực hiện quy trình này sẽ thẩm định việc thay thế vi điều khiển tương thích chân cắm bằng bảng so sánh chân, bản đồ ngoại vi và hồ sơ thử nghiệm, đó chính là mục tiêu cốt lõi của một quá trình thay thế MCU được thực hiện đúng cách.