Kiểm tra dung lượng bộ nhớ trong Arduino


7

Tôi đang làm việc trên một dự án đơn giản với Arduino của tôi. Gần đây tôi đã phải chuyển đổi một trong các biến của mình thành một biến dài thay vì int và để giữ cho mọi thứ đơn giản, tôi chỉ cần di chuyển qua tất cả các số mà nó tương tác (vì vậy tôi không phải lo lắng về so sánh chéo và toán khác). Điều này có vẻ lãng phí, nhưng nó chỉ là một chiếc đồng hồ cho bản thân tôi và tôi không quan tâm đến điều đó.

Tuy nhiên, nó làm tôi tự hỏi về việc tôi đang sử dụng bao nhiêu bộ nhớ. Tôi nghi ngờ đó là một vấn đề, nhưng tôi nhận ra tôi không biết cách nào để kiểm tra.

Vậy, có cách nào để kiểm tra dung lượng bộ nhớ đang được sử dụng bởi Arduino không?

Lý tưởng nhất là tôi muốn in ra bộ nhớ hiện tại / tổng số có sẵn qua kết nối nối tiếp.


BTW, tôi đã hỏi điều này trên stackoverflow trước đó ( stackoverflow.com/q/8649174/502816 ) và lời giới thiệu duy nhất tôi nhận được là hỏi ở đây
MrGlass

Câu trả lời:


8

Rất nhiều thứ arduino được xử lý bên dưới. Bạn sẽ thấy bộ nhớ (chương trình) sẽ mất bao nhiêu bộ nhớ khi biên dịch, nhưng không phải là bộ nhớ SRAM. Gần đây tôi đã phải khám phá điều này là tốt, và đây là cách tôi đã làm nó.

Trong thư mục arduino IDE có trình biên dịch avr-gcc. Nó cũng chứa một công cụ có tên là 'avr-size'. Đi đến phần cứng / công cụ / avr / bin / và nó sẽ ở đó.

Khi biên dịch, IDE sẽ tạo một thư mục tạm thời trong thư mục tạm thời của bạn và sao chép tất cả các tệp C (++) vào đó. Nó sẽ biên dịch các thư viện, bản phác thảo của bạn (nó cũng thêm những thứ cần thiết để làm cho nó hoạt động) và tạo một tệp hex và elf. Những gì bạn cần làm là biên dịch bản phác thảo của bạn (bằng cách nhấp vào tải lên hoặc xác minh) và tìm thư mục build [hash hash] trong thư mục tạm thời của bạn. Bạn cần chạy avr-size.exe và trao cho nó tệp elf.

Giao diện điều khiển khá tẻ nhạt, nhưng tôi thường điều hướng đến thư mục bin, chạy avr-size.exe và nhập đường dẫn đến thư mục tạm thời của tôi. Đây là C: \ Users [tên người dùng của bạn] \ AppData \ Local \ Temp \ build [thẻ ngẫu nhiên] [Tên phác thảo] .cpp.elf (Windows 7)

Bạn có thể có thể tạo một số tập lệnh (bó) cho việc này, nhưng vì thư mục xây dựng không đổi trên mỗi phiên arduino, tôi không bận tâm.

Đầu ra của kích thước avr trông rất giống với điều này (tôi đã biên dịch một chương trình ví dụ Xbee). Bảng điều khiển đầu ra

Ở đâu:

  • văn bản - dữ liệu flash được sử dụng cho mã
  • dữ liệu - Bộ nhớ có dữ liệu khởi tạo (giá trị ban đầu cũng phải được lưu trong FLASH!)
  • bss - Bộ nhớ được khởi tạo bằng 0 (trình biên dịch sẽ thêm một số mã để nó sẽ khởi tạo dữ liệu & bss)
  • dec & hex là màn hình thập phân và hex của kích thước RAM và FLASH kết hợp của chương trình của bạn.

Arduino IDE đã báo cáo với tôi chương trình này là 3956 byte lớn (FLASH). Điều đó liên quan đến 3924 (mã flash) + 32 (giá trị RAM ban đầu) = 3956 byte FLASH. Việc sử dụng RAM là dữ liệu + bss kết hợp (!) = 32 + 320 = 352 byte sử dụng SRAM.

Lưu ý rằng ATMEGA328 chỉ có 2KiB SRAM và các sự cố có thể xảy ra nếu bạn ở dưới mức đó (Tôi đã có những hành vi không mong muốn ở mức 1700 byte trong số 2048). ATMEGA168 có 1KiB SRAM. Tất cả Arduino mega đã có 8KiB SRAM.

Như một lưu ý bổ sung. Ngoài ra còn có mã 'chỉ số bộ nhớ miễn phí'. Những gì họ làm là cố gắng phân bổ càng nhiều bộ nhớ, đếm xem nó lớn như thế nào và giải phóng nó (malloc () & free ()). Nếu ban đầu bạn chưa sử dụng malloc, điều này sẽ thêm nhiều mã hơn vào chương trình của bạn, đôi khi bạn không có không gian cho. Điều này không lý tưởng và tôi cũng không tìm thấy nó để cho kết quả ổn định. Trong dự án của riêng tôi, tôi đã có ethernet + xbee + thẻ SD + mã thư viện riêng chạy trên Atmega328. Không có đủ SRAM và FLASH cũng trở nên khan hiếm).

Và cuối cùng nhưng không kém phần quan trọng, chỉ báo này không chiếm bộ nhớ được cấp phát với malloc ().


Vì vậy, đó là phân bổ RAM lý thuyết ứng dụng biên dịch sẽ có? hấp dẫn. Vẫn hy vọng có một số phương pháp để chỉ cần kéo RAM được phân bổ trong một bản phác thảo.
MrGlass

2
Đây là một câu trả lời tốt cho việc phân bổ RAM cố định, tuy nhiên điều quan trọng là phải nhận ra rằng nó không tính RAM được sử dụng bởi các biến tự động cục bộ cho một chức năng hoặc khối được phân bổ trên ngăn xếp khi bắt đầu thực hiện chức năng đó và được xử lý tại kết thúc. Điều đó chỉ có thể được xác định bằng cách thực hiện (hoặc mô phỏng) một đường dẫn cụ thể thông qua chương trình - có thể với đệ quy hoặc con trỏ hàm để tạo ra một tình huống bệnh lý của các lệnh gọi lồng nhau trong đó mức tiêu thụ bộ nhớ sẽ phụ thuộc vào đầu vào bên ngoài và có khả năng không giới hạn.
Chris Stratton

Tôi vừa thêm một số nhận xét bổ sung về chương trình sử dụng malloc để tìm hiểu mức sử dụng bộ nhớ. Tôi không thực sự tin tưởng vào những điều này và tôi nghĩ đối với ATMEGA328 bạn cũng không nên sử dụng malloc (chip nhỏ).
Hans

1
@Hans - Tôi thậm chí không nói về malloc (mặc dù điều đó rõ ràng cũng có thể là một vấn đề). Thay vào đó, khi bạn tạo một biến cục bộ trong một hàm, nó được phân bổ trên ngăn xếp trong thời gian chạy, không phải lúc biên dịch. Nếu hàm trả về bộ nhớ được giải phóng, nhưng nếu hàm tự gọi thì phải phân bổ một bản sao khác. Có thể phân tích một số chương trình và đặt giới hạn cho điều này, nhưng đối với các chương trình khác nơi đường dẫn của cuộc gọi phụ thuộc vào đầu vào thời gian chạy, nó có khả năng không giới hạn và không thể được xác định mà không biết đầu vào. Điều này có thể dẫn đến tràn ngăn xếp.
Chris Stratton

2
@Hans - có, phân bổ cố định giải phóng bạn khỏi những bất ngờ, tuy nhiên chúng có nghĩa là bạn không thể sử dụng lại bộ nhớ đó cho mục đích khác trong một chức năng khác, trừ khi bạn thực hiện thủ công. Làm điều đó và bạn đi vào lãnh thổ nơi mong muốn tối ưu hóa kim loại và mong muốn CS về hệ thống phân cấp sạch sẽ xảy ra xung đột. Độ phân giải thông thường dường như mua chip có hơn 2K RAM khi tác vụ vượt quá mức đơn giản và mang tính quyết định và xem xét các nỗ lực để loại bỏ các tính năng cấp cao ra khỏi các chip bị hạn chế để trở thành phiên bản lập trình của thể thao khắc nghiệt.
Chris Stratton

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.