Vi điều khiển 8 bit khác với vi điều khiển 32 bit như thế nào khi lập trình chúng


19

Đúng vậy, hiện tại chúng ta có bộ vi điều khiển 8 bit, 16 bit và 32 bit trong thế giới này. Tất cả chúng thường được sử dụng. Làm thế nào khác nhau để lập trình vi điều khiển 8 bit và 16 bit? Ý tôi là, nó đòi hỏi kỹ thuật hay kỹ năng khác nhau? Hãy lấy vi mạch chẳng hạn. Những điều mới mà một người cần phải học nếu họ muốn chuyển đổi từ vi điều khiển 8 bit sang vi điều khiển 32 bit?


Không. Chắc chắn có những mối quan tâm khác nhau, nhưng những điều đó phần lớn nằm ở mức độ chi tiết cụ thể của thiết bị. Ví dụ, có được phép truy cập từ không được phép? (Trên ARM thì không - trên x86 là vậy). Câu hỏi này không thực sự đủ cụ thể.
Chris Stratton

Wow các bạn, cảm ơn vì câu trả lời. Vì vậy, có những khác biệt thực sự rất quan trọng mà chúng ta cần xem xét khi lập trình bộ xử lý 32 bit so với bộ xử lý 8 bit. Ở đây tôi đã đề cập đến C vì tôi nghĩ rằng hầu hết mọi người không đào sâu vào hội để lập trình vì lý do tất cả chúng ta đều biết rất rõ. Cảm ơn đã trả lời chi tiết, tôi thực sự đánh giá cao nó.
quantum231

Với uc 32 bit, có rất nhiều tùy chọn và rất nhiều đăng ký mà bạn phải có. Tôi đoán nó phụ thuộc vào những gì bạn đang làm. Điều đó nói rằng, những ngày này bạn có thể nhận được một ban phát triển, trình biên dịch, trình gỡ lỗi, IDE với giá khoảng 50 đô la. Trở lại trong ngày sẽ có giá gần 1000 đô la.

Câu trả lời:


33

Nói chung, đi từ 8 đến 16 đến 32 bit vi điều khiển có nghĩa là bạn sẽ có ít hạn chế hơn về tài nguyên, đặc biệt là bộ nhớ và độ rộng của các thanh ghi được sử dụng để thực hiện các phép toán số học và logic. Các đơn vị 8, 16 và 32 bit thường đề cập đến cả kích thước của các dữ liệu bên trong và bên ngoài cũng như kích thước của (các) thanh ghi bên trong được sử dụng cho các phép toán số học và logic (trước đây chỉ là một hoặc hai được gọi là bộ tích lũy , bây giờ thường có ngân hàng đăng ký 16 hoặc 32).

Kích thước cổng cổng I / O nói chung cũng sẽ tuân theo kích thước bus dữ liệu, do đó, micro 8 bit sẽ có cổng 8 bit, 16 bit sẽ có cổng 16 bit, v.v.

Mặc dù có bus dữ liệu 8 bit, nhiều bộ vi điều khiển 8 bit có bus địa chỉ 16 bit và có thể giải quyết 2 ^ 16 hoặc 64K byte bộ nhớ (điều đó không có nghĩa là chúng có bất kỳ nơi nào được triển khai gần đó). Nhưng một số micros 8 bit, như PIC cấp thấp, có thể chỉ có không gian RAM rất hạn chế (ví dụ 96 byte trên PIC16).

Để giải quyết sơ đồ địa chỉ giới hạn của họ, một số micros 8 bit sử dụng phân trang, trong đó nội dung của thanh ghi trang xác định một trong nhiều ngân hàng bộ nhớ sẽ sử dụng. Thông thường sẽ có sẵn một số RAM phổ biến cho dù đăng ký trang được đặt thành gì.

Vi điều khiển 16 bit thường bị giới hạn ở 64K bộ nhớ, nhưng cũng có thể sử dụng các kỹ thuật phân trang để khắc phục điều này. Tất nhiên, vi điều khiển 32 bit không có hạn chế như vậy và có thể giải quyết tới 4GB bộ nhớ.

Cùng với các kích thước bộ nhớ khác nhau là kích thước ngăn xếp. Trong micros micros end thấp hơn, điều này có thể được thực hiện trong một vùng bộ nhớ đặc biệt và rất nhỏ (nhiều PIC16 có ngăn xếp cuộc gọi sâu 8 cấp). Trong micros 16 bit và 32 bit, ngăn xếp thường sẽ ở mức RAM chung và chỉ bị giới hạn bởi kích thước của RAM.

Cũng có sự khác biệt lớn về dung lượng bộ nhớ - cả chương trình và RAM - được triển khai trên các thiết bị khác nhau. Micros 8 bit có thể chỉ có vài trăm byte RAM và vài nghìn byte bộ nhớ chương trình (hoặc ít hơn nhiều - ví dụ PIC10F320 chỉ có 256 từ flash 14 bit và 64 byte RAM). Micros 16 bit có thể có vài nghìn byte RAM và hàng chục nghìn byte bộ nhớ chương trình. Micros 32 bit thường có hơn 64K byte RAM và có thể bằng 1/2 MB bộ nhớ chương trình trở lên (PIC32MZ2048 có 2 MB flash và 512KB RAM, PIC32MZ2064DAH176 mới được phát hành, được tối ưu hóa cho đồ họa có 2 MB flash và một con số khổng lồ 32 MB RAM trên chip).

Nếu bạn đang lập trình bằng ngôn ngữ lắp ráp, các giới hạn kích thước thanh ghi sẽ rất rõ ràng, ví dụ: thêm hai số 32 bit là một việc vặt trên vi điều khiển 8 bit nhưng không quan trọng trên vi điều khiển 32 bit. Nếu bạn đang lập trình bằng C, điều này sẽ phần lớn trong suốt, nhưng tất nhiên mã được biên dịch cơ bản sẽ lớn hơn nhiều cho 8-đắng.

Tôi đã nói phần lớn minh bạch, bởi vì kích thước của các loại dữ liệu C khác nhau có thể khác nhau từ một kích thước vi mô khác; ví dụ, trình biên dịch nhắm vào micro 8 hoặc 16 bit có thể sử dụng "int" để có nghĩa là biến có chữ ký 16 bit và trên micro 32 bit, đây sẽ là biến 32 bit. Vì vậy, rất nhiều chương trình sử dụng #defines để nói rõ ràng kích thước mong muốn là gì, chẳng hạn như "UINT16" cho biến 16 bit không dấu.

Nếu bạn đang lập trình bằng C, tác động lớn nhất sẽ là kích thước của các biến bạn. Ví dụ: nếu bạn biết một biến sẽ luôn nhỏ hơn 256 (hoặc trong phạm vi -128 đến 127 nếu được ký), thì bạn nên sử dụng 8 bit (char hoặc char không dấu) trên micro 8 bit (ví dụ PIC16 ) vì sử dụng kích thước lớn hơn sẽ rất kém hiệu quả. Tương tự như vậy lại biến 16 bit trên micro 16 bit (ví dụ PIC24). Nếu bạn đang sử dụng micro 32 bit (PIC32), thì nó không thực sự tạo ra bất kỳ sự khác biệt nào vì tập lệnh MIPS có các lệnh byte, word và double-word. Tuy nhiên, trên một số máy vi tính 32 bit, nếu chúng thiếu các hướng dẫn như vậy, thao tác với biến 8 bit có thể kém hiệu quả hơn so với biến 32 bit do mặt nạ.

Như thành viên diễn đàn vsz đã chỉ ra, trên các hệ thống mà bạn có một biến lớn hơn kích thước thanh ghi mặc định (ví dụ: biến 16 bit trên micro 8 bit) và biến đó được chia sẻ giữa hai luồng hoặc giữa luồng cơ sở và một trình xử lý ngắt, người ta phải thực hiện bất kỳ thao tác nào (bao gồm chỉ đọc) trên nguyên tử biến , điều đó làm cho nó dường như được thực hiện như một lệnh. Đây được gọi là một phần quan trọng. Cách tiêu chuẩn để giảm thiểu điều này là bao quanh phần quan trọng bằng cặp ngắt / vô hiệu hóa.

Vì vậy, việc chuyển từ các hệ thống 32 bit sang 16 bit, hoặc 16 bit đến 8 bit, mọi hoạt động trên các biến thuộc loại này hiện lớn hơn kích thước thanh ghi mặc định (nhưng trước đây không cần phải được coi là quan trọng phần.

Một sự khác biệt chính khác, đi từ bộ xử lý PIC này sang bộ xử lý PIC khác, là việc xử lý các thiết bị ngoại vi. Điều này ít liên quan đến kích thước từ và nhiều thứ khác liên quan đến loại và số lượng tài nguyên được phân bổ trên mỗi chip. Nói chung, Microchip đã cố gắng làm cho việc lập trình cùng một thiết bị ngoại vi được sử dụng trên các chip khác nhau giống nhau nhất có thể (ví dụ: timer0), nhưng sẽ luôn có sự khác biệt. Sử dụng các thư viện ngoại vi của họ sẽ che giấu những khác biệt này ở một mức độ lớn. Một sự khác biệt cuối cùng là việc xử lý các ngắt. Một lần nữa có sự giúp đỡ ở đây từ các thư viện Microchip.


Có thể đáng chú ý rằng ở cấp độ ngôn ngữ lắp ráp, bộ xử lý 8 bit có xu hướng có ít thanh ghi hơn và ít hướng dẫn trực giao hơn (AVR là ngoại lệ RISCy nhiều hơn), hậu quả của các ràng buộc thiết kế khi chúng được phát triển. Bộ xử lý 32 bit có xu hướng là hậu duệ của RISC (Renesas 'RX, một CISC hiện đại, là một ngoại lệ và ColdFire của Freescale xuống từ m68k).
Paul A. Clayton

9
Để không bắt đầu một câu trả lời mới chỉ cho phần bổ sung này, tôi nghĩ rằng điều quan trọng là thêm sự chuyển đổi từ 32 bit sang 16 của 16 sang 8 có thể gây ra những bất ngờ khó chịu vì các nhà nghiên cứu không còn là nguyên tử. Nếu bạn thêm hai số 16 bit trên vi điều khiển 8 bit và sử dụng chúng trong một ngắt, bạn phải cẩn thận làm cho chúng an toàn theo luồng, nếu không bạn có thể chỉ thêm một nửa số đó trước khi kích hoạt ngắt, dẫn đến một giá trị không hợp lệ trong thói quen dịch vụ ngắt của bạn.
vsz

2
@vsz - Điểm hay, quên cái đó đi. Nói chung, người ta nên vô hiệu hóa các ngắt xung quanh bất kỳ quyền truy cập nào (bao gồm chỉ đọc) bất kỳ biến dễ bay hơi nào lớn hơn kích thước thanh ghi mặc định.
tcrosley

1
Có đúng là uC 32 bit thường có giao diện I / O 32 bit không? Tôi nghĩ rằng dù sao nó thường chỉ là giao tiếp nối tiếp.
clabacchio

1
@clabacchio Kinh nghiệm của tôi là tất cả các thanh ghi cổng I / O được định nghĩa là 32 bit, nhưng đôi khi 16 bit trên 16-31 không được sử dụng, do đó một cổng song song vẫn là 16 chân vật lý. Trong các trường hợp khác, như thanh ghi RTCC, tất cả 32 bit được sử dụng.
tcrosley

8

Một điểm khác biệt chung giữa các bộ vi điều khiển 8 bit và 32 bit là các bộ vi điều khiển 8 bit thường có phạm vi bộ nhớ và không gian I / O có thể được truy cập trong một lệnh, bất kể bối cảnh thực thi, trong khi các bộ vi điều khiển 32 bit sẽ thường xuyên yêu cầu một chuỗi đa hướng dẫn. Ví dụ, trên một vi điều khiển 8 bit thông thường (HC05, 8051, PIC-18F, v.v.), người ta có thể thay đổi trạng thái của một bit cổng bằng một lệnh đơn. Trên ARM thông thường (32 bit), nếu nội dung thanh ghi ban đầu không xác định, sẽ cần một chuỗi lệnh bốn lệnh:

    ldr  r0,=GPIOA
    ldrh r1,[r0+GPIO_DDR]
    ior  r1,#64
    strh r1,[r0+GPIO_DDR]

Trong hầu hết các dự án, bộ điều khiển sẽ dành phần lớn thời gian để thực hiện các công việc khác ngoài cài đặt hoặc xóa các bit I / O riêng lẻ, do đó, các hoạt động như xóa một chân cổng đòi hỏi nhiều hướng dẫn thường không thành vấn đề. Mặt khác, có những lúc mã sẽ phải "nổ tung" rất nhiều thao tác cổng và khả năng thực hiện những điều đó chỉ với một lệnh có thể chứng minh khá có giá trị.

Mặt khác, bộ điều khiển 32 bit luôn được thiết kế để truy cập hiệu quả nhiều loại cấu trúc dữ liệu có thể được lưu trữ trong bộ nhớ. Nhiều bộ điều khiển 8 bit, bằng cách so sánh, rất không hiệu quả trong việc truy cập các cấu trúc dữ liệu không được phân bổ tĩnh. Bộ điều khiển 32 bit có thể thực hiện trong một lệnh, một truy cập mảng sẽ mất nửa tá hoặc nhiều lệnh trên bộ điều khiển 8 bit thông thường.


Tôi giả sử bạn có nghĩa là "bit-bang". Có thể đáng chú ý rằng ARM hỗ trợ các vùng băng bit (trong đó hoạt động từ là hoạt động bit đơn) và Tiện ích mở rộng cụ thể cho ứng dụng MCU cho MIPS cung cấp Set / Clear Bit nguyên tử trong các hướng dẫn Byte (ASET / ACLR).
Paul A. Clayton

@ PaulA.Clayton: Tôi đã không thực sự nhìn vào MIPS trong 20 năm qua; đối với các vùng băng tần bit, tôi chưa bao giờ tìm ra cách sử dụng chúng trong mã có giao diện hợp lý và ngay cả khi tôi có thể sử dụng chúng, họ sẽ chỉ lưu một lệnh trừ khi sử dụng một số mánh khóe lập trình điên rồ, trong trường hợp đó họ có thể lưu hai [tải R0 với một địa chỉ chẵn hoặc lẻ dựa trên việc bit nên được đặt hoặc xóa, và điều chỉnh bù trên hướng dẫn lưu trữ khi thích hợp để bù]. BTW, bạn có biết tại sao vùng băng tần sử dụng địa chỉ từ không?
supercat

@supercat: Địa chỉ từ cho phép bạn truy cập các vùng băng tần từ C hoặc C ++ thông qua đăng ký con trỏ ( region_base[offset])
Ben Voigt

@BenVoigt Và tại sao người ta không thể làm điều đó với địa chỉ byte? (Có lẽ một lý do có thể là loại bỏ kỳ vọng / hy vọng rằng các hoạt động hai bit và bốn bit sẽ được hỗ trợ.)
Paul A. Clayton

@BenVoigt: Phải chia tỷ lệ số bit theo hệ số 4 thường sẽ tốn thêm một hướng dẫn. Trên thực tế, những gì tôi muốn thấy, thay vì một vùng băng bit, sẽ là một tập hợp các khu vực nằm ở vị trí bù cố định so với truy cập bộ nhớ "thông thường", nhưng chỉ định rằng ghi vào một vùng sẽ chỉ nếu có thể "thiết lập" các bit và ghi vào các bit khác sẽ chỉ "xóa" các bit. Nếu xe buýt có các bit điều khiển "write-one-enable" và "write-zeroes-enable", người ta có thể đạt được những điều mà dải bit cho phép, nhưng trong nhiều trường hợp tránh đọc-sửa-ghi.
supercat

6

Sự khác biệt thực tế lớn nhất là số lượng tài liệu, thực sự, để hiểu hoàn toàn toàn bộ chip. Có những bộ vi điều khiển 8 bit ngoài kia đi kèm với gần 1000 trang tài liệu. So sánh với khoảng 200-300 trang có giá trị cho CPU 8 bit của năm 1980 và các chip ngoại vi phổ biến mà nó sẽ được sử dụng. Một thiết bị 32 bit giàu ngoại vi sẽ yêu cầu bạn phải xem qua 2000-10.000 trang tài liệu để hiểu phần này. Các phần có cạnh đồ họa 3D hiện đại trên 20k trang tài liệu.

Theo kinh nghiệm của tôi, phải mất khoảng 10 lần để biết mọi thứ cần biết về bộ điều khiển 32 bit hiện đại nhất định như với phần 8 bit hiện đại. Theo "mọi thứ", ý tôi là bạn biết cách sử dụng tất cả các thiết bị ngoại vi, thậm chí theo những cách độc đáo và biết ngôn ngữ máy, trình biên dịch nền tảng sử dụng cũng như các công cụ khác, ABI (s), v.v.

Không thể tưởng tượng được rằng nhiều, rất nhiều thiết kế được thực hiện với sự hiểu biết một phần. Đôi khi nó không quan trọng, đôi khi không. Việc chuyển đổi nền tảng phải được thực hiện với sự hiểu biết rằng sẽ có một mức giá ngắn hạn và trung hạn về năng suất mà bạn phải trả cho việc tăng năng suất nhận thức từ một kiến ​​trúc mạnh mẽ hơn. Làm siêng năng của bạn.


3

Cá nhân tôi sẽ không lo lắng quá nhiều về việc nâng cấp (8 bit-> 32 bit) uC của cùng một gia đình và bạn đang tăng thông số kỹ thuật trên bảng. Nói chung, tôi không làm bất cứ điều gì ngoài định mức với các loại dữ liệu vì có thể khó duy trì hoạt động.

Hạ cấp mã thiết bị là một câu chuyện khác.


3
Kích thước của các loại dữ liệu được xác định bởi trình biên dịch, không phải kiến ​​trúc bộ xử lý. Bộ xử lý 8 bit có thể có int 32 bit, mặc dù nó sẽ mất nhiều hướng dẫn để thao tác chúng.
Joe Hass

bình luận tốt- Tôi đã xóa dòng đầu tiên do sự điều chỉnh.
Nick Tullos

@JoeHass: Một trình biên dịch cho một bộ xử lý 8-bit có thể xác định intđược 32 bit, hoặc thậm chí 64 cho rằng vấn đề, nhưng tôi không biết về bất kỳ trình biên dịch 8-bit hiện có mà thực sự làm xác định intlà lớn hơn 16 bit, hoặc quảng bá Giá trị 16 bit cho bất cứ điều gì lớn hơn.
supercat

-1

MCU 32 bit sẽ ăn nhiều năng lượng hơn cho một. Và yêu cầu nhiều mạch hỗ trợ hơn.

Người ta không thực sự chuyển sang 32 bit từ 8 bit ... Bạn sẽ tiếp tục sử dụng cả hai, thường xuyên cùng nhau. Điểm mấu chốt là bạn nên sử dụng (và tìm hiểu) bất cứ điều gì phù hợp với công việc. Tìm hiểu ARM bởi vì nó làm rung chuyển thế giới nhúng ngay bây giờ và sẽ tiếp tục làm điều đó. Cũng tìm hiểu AVR hoặc PIC vì chúng là bộ điều khiển bảng tuyệt vời.

Bạn có thể sẽ gặp nhiều khó khăn khi chuyển đổi từ AVR sang ARM như khi chuyển từ ARM sang x86, kích thước của xe buýt thực sự không tạo ra nhiều sự khác biệt. Tất cả các phần cứng tiên tiến thêm mặc dù. Đi từ các ngắt tiêu chuẩn đến một mảng ngắt có vectơ với 6 mức ưu tiên sẽ khó hơn nhiều so với việc tìm ra cách tính đến bốn tỷ.


4
Tôi không biết liệu có chính xác khi yêu cầu MCU 32 bit thực sự đói nhiều hơn không. Ít nhất một dòng sản phẩm của công ty ( micro micro ) là MCU công suất cực thấp và tất cả chúng đều dựa trên lõi ARM 32 bit.
Sói Connor

3
Chỉ cần thực hiện một mạch stm32l1 sẽ chạy trong 7 năm trên một chiếc cr2032
Scott Seidman

2
Bạn có thể biện minh cho nhận xét rằng MCU 32 bit cần nhiều "mạch hỗ trợ" hơn không? Tôi nghĩ rằng bạn đang bày tỏ một số ý kiến ​​không chính đáng ở đây.
Joe Hass

1
Ngoài ra, nhận xét ngắt theo vectơ của bạn không có ý nghĩa gì nhiều, vì bạn có thể nhận được nhiều mức độ ưu tiên trong bộ vi điều khiển 8 bit (xem MCU Atmel xmega, có 3 mức ưu tiên) và việc ngắt vectơ là không liên quan khi mọi thiết bị phần cứng đều có vectơ độc lập dù sao đi nữa.
Sói Connor

2
Tôi đang sử dụng bộ xử lý Cortex-M0 32 bit để điều khiển bộ sạc pin thông minh cho xe điện. Nó sử dụng một nguồn cung cấp 3,3 V. Nó có một bộ dao động nội và PLL vì vậy tôi thậm chí không cần một tinh thể. Tôi đang sử dụng gói DIP 28 chân nhưng tôi có thể nhận được Cortex-M0 trong một DIP 8 chân nếu muốn. Làm thế nào điều đó có thể phức tạp hơn một PIC hoặc AVR thông thường?
Joe Hass
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.