Flash và RAM: Thực thi mã


13

Gần đây tôi đã bắt đầu học lắp ráp và biết về các tập lệnh liên kết và các chi tiết cấp thấp khác về lập trình phần cứng. Tôi cũng đang tự dạy kiến ​​trúc máy tính và ở đâu đó dọc theo con đường tôi đã lo sợ rằng hình ảnh của tôi về mô hình bộ nhớ có thể đã sai hoàn toàn.

Theo những gì tôi hiểu hiện tại, tất cả mã và dữ liệu nằm trên bộ nhớ không bay hơi ngay sau khi chúng tôi 'ghi' nhị phân vào bộ xử lý - RAM không ổn định không chứa gì khi thiết lập lại. Khi chương trình bắt đầu 'thực thi', nó sẽ thực hiện từ địa chỉ 0x0000 gần như luôn luôn (AFAIK), địa chỉ thấp nhất trong Flash. Vì vậy, các hướng dẫn được chốt trên xe buýt kết nối Flash với lõi CPU và đó là nơi diễn ra thực tế thực tế. Tuy nhiên, khi chúng ta nói về việc truy xuất CPU hoặc lưu trữ dữ liệu từ bộ nhớ, chúng ta thường nói về RAM - Tôi biết rằng chúng ta cũng có thể đọc / ghi dữ liệu từ bộ nhớ chương trình (Tôi đã thấy điều này được thực hiện trên các AVR) Nhưng nó không phải là phổ biến? Có phải vì RAM nhanh hơn ROM mà chúng tôi muốn lưu trữ dữ liệu ở đó?

Câu trả lời được chấp nhận cho câu hỏi này nói rằng hầu hết các đoạn mã thực thi hết RAM.

Điều này có nghĩa là mã thời gian chạy khởi động (tự thực thi từ Flash) phải sao chép tất cả các mã chương trình từ Flash sang RAM và bằng cách nào đó ánh xạ các địa chỉ trong Flash để trỏ đến RAM để CPU tìm nạp mã từ đó? Nó có giống với quá trình chúng ta di chuyển các phần .data từ ROM sang RAM khi khởi động không?

Tôi có thể tưởng tượng điều này đơn giản hơn trong các kiến ​​trúc von Neumann nơi các bộ nhớ chương trình và dữ liệu chia sẻ một chiếc xe buýt nhưng trong các kiến ​​trúc Harvard không có nghĩa là tất cả các mã và dữ liệu phải đi qua các thanh ghi CPU trước?

Như bạn có thể đoán, tôi hơi bối rối bởi toàn bộ doanh nghiệp này. Luôn luôn được lập trình ở mức độ trừu tượng cao hơn, tôi dễ gặp rắc rối với những chi tiết như vậy. Bất kỳ trợ giúp được đánh giá cao.


2
Trong các bộ vi điều khiển đơn giản, không cần phải sao chép từ bộ nhớ chương trình (thường là flash hiện nay) sang RAM để thực thi.
David

Tất cả chỉ vì RAM nhanh hơn Flash, nhưng vì nó mất dữ liệu sau khi mất điện, nên có Flash bộ nhớ không bay hơi. Khi bật nguồn, dữ liệu được tải từ Flash sang RAM và CPU bắt đầu hoạt động, tất cả những điều đó lặp lại.
Lazar

Câu trả lời:


13

Điều này phụ thuộc vào thiết bị.

RAM có thể được xây dựng nhanh hơn Flash; điều này bắt đầu trở nên quan trọng trong khoảng 100 MHz.

Vi điều khiển đơn giản

Các bộ vi điều khiển nhỏ chậm thực thi trực tiếp từ Flash. Các hệ thống này thường có nhiều Flash hơn SRAM.

Hệ thống tầm trung

Một khi thiết bị của bạn trở nên nhanh hơn thì tình hình sẽ khác đi một chút. Các hệ thống ARM tầm trung cũng có thể làm điều đó hoặc chúng có thể có bộ tải khởi động ROM mặt nạ làm điều gì đó thông minh hơn: có thể tải mã từ USB hoặc EEPROM bên ngoài vào SRAM bên trong.

Hệ thống lớn

Các hệ thống lớn hơn, nhanh hơn sẽ có DRAM bên ngoài và Flash bên ngoài. Đây là điển hình của một kiến ​​trúc điện thoại di động. Tại thời điểm này, có rất nhiều RAM có sẵn và nó nhanh hơn Flash, vì vậy bộ tải khởi động sẽ sao chép và thực thi nó. Điều này có thể liên quan đến việc đưa nó qua các thanh ghi CPU hoặc nó có thể liên quan đến việc chuyển DMA nếu có sẵn một đơn vị DMA.

Kiến trúc Harvard thường nhỏ, vì vậy đừng bận tâm với giai đoạn sao chép. Tôi đã thấy một ARM với "máy gặt lai", đó là một không gian địa chỉ duy nhất chứa nhiều ký ức khác nhau nhưng hai đơn vị tìm nạp khác nhau. Mã và dữ liệu có thể được tìm nạp song song, miễn là chúng không nằm trong cùng một bộ nhớ. Vì vậy, bạn có thể tìm nạp mã từ Flash và dữ liệu từ SRAM hoặc mã từ SRAM và dữ liệu từ DRAM, v.v.


1

RAM thường nhanh hơn flash, nhưng nó không thực sự quan trọng cho đến khi bạn đạt tốc độ xung nhịp vượt quá 80-100 MHz hoặc lâu hơn - miễn là thời gian truy cập flash nhanh hơn thời gian để chạy một lệnh, nó không nên quan trọng

Cấu trúc vật lý của RAM cho phép chúng ta chế tạo các thiết bị rất nhanh; nhanh hơn nhiều so với đèn flash. Tại thời điểm này, việc sao chép các khối mã vào RAM trước khi thực hiện là điều hợp lý. Điều này cũng mang lại lợi ích bổ sung cho nhà phát triển, chẳng hạn như có thể sửa đổi mã khi chạy.

trong các kiến ​​trúc von Neumann nơi các bộ nhớ chương trình và dữ liệu chia sẻ một chiếc xe buýt nhưng trong các kiến ​​trúc của Harvard, điều này có nghĩa là tất cả các mã và dữ liệu phải đi qua các thanh ghi CPU trước?

Không cần thiết. Đây là nơi gửi địa chỉ ảo . Thay vì mã chương trình đề cập đến các địa chỉ RAM phần cứng thô, nó thực sự tham chiếu một không gian địa chỉ ảo. Các khối không gian địa chỉ ảo được ánh xạ tới các thiết bị bộ nhớ vật lý, có thể là RAM, ROM, flash hoặc thậm chí là bộ đệm thiết bị.

Ví dụ: khi bạn tham chiếu địa chỉ 0x000f0004 trên micro, bạn có thể đang đọc địa chỉ 0x0004 từ đèn flash. Các địa chỉ ảo là 0x000f0004, nhưng địa chỉ vật lý chỉ 0x0004 là - toàn bộ không gian địa chỉ 0x000fxxxx được ánh xạ tới một thiết bị 4KB bộ nhớ vật lý. Tất nhiên, đây chỉ là một ví dụ và phương pháp quản lý và tổ chức không gian địa chỉ ảo khác nhau rất nhiều trên các kiến ​​trúc.

Như vậy, khi bạn nói rằng "chương trình bắt đầu thực thi [...] từ địa chỉ 0x0000 gần như luôn là địa chỉ thấp nhất trong flash", bạn không được đảm bảo là chính xác. Trong thực tế, nhiều vi điều khiển bắt đầu từ 0x1000.


3
Tôi đã có thể nói rằng sự khác biệt trở nên có liên quan khoảng 20-40 MHz, chứ không phải 100Mhz, vì hầu hết các thiết bị flash tôi đã thấy bắt đầu yêu cầu trạng thái chờ xung quanh điểm đó. Trong nhiều trường hợp, mã flash sẽ bao gồm mạch để mỗi lần tìm nạp sẽ lấy được nhiều từ chỉ dẫn, do đó, đối với nhiều loại mã, "hình phạt" cho việc chạy từ flash sẽ chỉ khoảng 5-10%, nhưng đối với một số loại khác mã (ví dụ với nhiều lần nhảy) hình phạt có thể nghiêm trọng hơn nhiều.
supercat

Đó không phải là địa chỉ ảo, đó là I / O được ánh xạ bộ nhớ (vùng bộ nhớ ánh xạ tới I / O bằng thiết bị ngoại vi, tên trên nhiều MCU là "Bộ điều khiển bộ nhớ tĩnh"). Tất nhiên, I / O tiếp cận với một bộ nhớ khác, vì vậy đôi khi chúng ta không nghĩ đó là I / O. Nhưng nó chắc chắn không phải là một bản đồ bộ nhớ ảo.
Ben Voigt

1

Những gì bạn đang nói không hoàn toàn đúng hay sai. Có nhiều kịch bản khác nhau cho việc này.

Điều đó phụ thuộc vào việc bạn đang lập trình trên phần cứng thô hay phần cứng được cài đặt với HĐH.

Hệ điều hành của bạn chạy trên máy tính đa năng lấy mã từ ổ cứng và lưu nó vào RAM để truy cập nhanh hơn. Nếu bộ xử lý của bạn cố gắng tìm nạp trực tiếp từ ổ cứng trên cơ sở liên tục thì các hoạt động sẽ chậm hơn nhiều do tốc độ không khớp giữa hai. Vì vậy, RAM của bạn phát huy tác dụng khi đoạn mã lặp đi lặp lại của bạn được lưu trữ để truy cập nhanh hơn. Và điều đó thậm chí còn được cung cấp thêm trên bộ nhớ cache của bộ xử lý để làm cho nó nhanh hơn nữa.

Bây giờ khi bạn đang làm việc trên bộ điều khiển vi mô, điều đó hoàn toàn phụ thuộc vào bạn định vị dữ liệu của mình trên chip. Nếu dữ liệu là tĩnh, bạn có thể muốn xác định vị trí của nó trên bộ nhớ mã, điều này sẽ tiết kiệm RAM của bạn, tương đối nhỏ hơn nhiều so với bộ nhớ Mã. Trong ngôn ngữ C khi bạn khởi tạo kiểu dữ liệu bằng cách sử dụng tĩnh hoặc trong một số trình biên dịch, dữ liệu tiền tố sẽ được lưu trữ trên bộ nhớ mã nếu không sẽ được lưu trữ trong RAM. Và trong hội đồng, bạn trực tiếp sử dụng DB (Xác định Byte trong trường hợp Basic 8051) để khởi tạo dữ liệu trên vị trí cụ thể. Bây giờ ngay cả trong một số bộ điều khiển như PIC ARM, bạn có thể ghi ROM trong thời gian chạy nhưng việc tìm nạp dữ liệu sẽ mất nhiều thời gian.

Ngoài ra, còn có các phần cứng bộ tải khởi động trong các bộ điều khiển trung bình và tinh vi cho bộ điều khiển hoặc bộ xử lý biết nơi thực thi mã khởi động hoặc chính nó là mã khởi động thực sự được phân đoạn vào bộ nhớ Vì vậy, có rất nhiều khả năng do sự tiến bộ , Tôi muốn nói rằng sự tiến bộ lai trong ngành công nghiệp này làm xáo trộn toàn bộ khái niệm về RAM & bộ nhớ RAM thông thường. Vì vậy, về cơ bản sự nhầm lẫn của bạn là hợp lệ.

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.