Đếm chu kỳ với CPU hiện đại (ví dụ ARM)


14

Trong nhiều ứng dụng, CPU có thực thi lệnh có mối quan hệ thời gian đã biết với các kích thích đầu vào dự kiến ​​có thể xử lý các tác vụ yêu cầu CPU nhanh hơn nhiều nếu không xác định được mối quan hệ. Ví dụ, trong một dự án tôi đã sử dụng PSOC để tạo video, tôi đã sử dụng mã để xuất một byte dữ liệu video cứ sau 16 đồng hồ CPU. Vì việc kiểm tra xem thiết bị SPI có sẵn sàng và phân nhánh hay không, nếu không, IIRC sẽ mất 13 đồng hồ, và tải và lưu trữ dữ liệu đầu ra sẽ mất 11, không có cách nào để kiểm tra thiết bị có sẵn sàng giữa các byte hay không; thay vào đó, tôi chỉ đơn giản sắp xếp để bộ xử lý thực thi chính xác mã có giá trị 16 chu kỳ cho mỗi byte sau lần đầu tiên (tôi tin rằng tôi đã sử dụng tải được lập chỉ mục thực, tải được lập chỉ mục giả và lưu trữ). Viết SPI đầu tiên của mỗi dòng xảy ra trước khi bắt đầu video, và cho mỗi lần ghi tiếp theo, có một cửa sổ 16 chu kỳ trong đó việc ghi có thể xảy ra mà không bị tràn hoặc tràn bộ đệm. Vòng lặp phân nhánh tạo ra một cửa sổ 13 chu kỳ không chắc chắn, nhưng việc thực hiện 16 chu kỳ có thể dự đoán được có nghĩa là độ không đảm bảo cho tất cả các byte tiếp theo sẽ phù hợp với cùng một cửa sổ 13 chu kỳ (lần lượt phù hợp với cửa sổ 16 chu kỳ khi ghi có thể chấp nhận được xảy ra).

Đối với CPU cũ hơn, thông tin về thời gian hướng dẫn rõ ràng, khả dụng và không rõ ràng. Đối với các ARM mới hơn, thông tin về thời gian có vẻ mơ hồ hơn nhiều. Tôi hiểu rằng khi mã được thực thi từ flash, hành vi bộ đệm có thể khiến mọi thứ khó dự đoán hơn nhiều, vì vậy tôi hy vọng rằng bất kỳ mã được tính theo chu kỳ nào sẽ được thực thi từ RAM. Ngay cả khi thực thi mã từ RAM, thông số kỹ thuật có vẻ hơi mơ hồ. Việc sử dụng mã đếm chu kỳ vẫn là một ý tưởng tốt? Nếu vậy, các kỹ thuật tốt nhất để làm cho nó hoạt động đáng tin cậy là gì? Ở mức độ nào người ta có thể giả định một cách an toàn rằng một nhà cung cấp chip sẽ không âm thầm trượt vào một con chip "cải tiến mới", giúp loại bỏ một chu kỳ thực thi các hướng dẫn nhất định trong một số trường hợp nhất định?

Giả sử vòng lặp sau bắt đầu trên một ranh giới từ, làm thế nào người ta sẽ xác định dựa trên thông số kỹ thuật chính xác sẽ mất bao lâu (giả sử Cortex-M3 với bộ nhớ trạng thái chờ không; không có gì khác về hệ thống trong ví dụ này).

myloop:
  di r0, r0; Hướng dẫn đơn giản ngắn để cho phép thêm hướng dẫn được tìm nạp trước
  di r0, r0; Hướng dẫn đơn giản ngắn để cho phép thêm hướng dẫn được tìm nạp trước
  di r0, r0; Hướng dẫn đơn giản ngắn để cho phép thêm hướng dẫn được tìm nạp trước
  di r0, r0; Hướng dẫn đơn giản ngắn để cho phép thêm hướng dẫn được tìm nạp trước
  di r0, r0; Hướng dẫn đơn giản ngắn để cho phép thêm hướng dẫn được tìm nạp trước
  di r0, r0; Hướng dẫn đơn giản ngắn để cho phép thêm hướng dẫn được tìm nạp trước
  thêm r2, r1, # 0x12000000; Hướng dẫn 2 từ
  ; Lặp lại như sau, có thể với các toán hạng khác nhau
  ; Sẽ tiếp tục thêm các giá trị cho đến khi thực hiện
  itcc
  addscc r2, r2, # 0x12000000; Hướng dẫn 2 từ, cộng thêm "từ" cho itcc
  itcc
  addscc r2, r2, # 0x12000000; Hướng dẫn 2 từ, cộng thêm "từ" cho itcc
  itcc
  addscc r2, r2, # 0x12000000; Hướng dẫn 2 từ, cộng thêm "từ" cho itcc
  itcc
  addscc r2, r2, # 0x12000000; Hướng dẫn 2 từ, cộng thêm "từ" cho itcc
; ... vv, với các hướng dẫn hai từ có điều kiện hơn
  phụ r8, r8, # 1
  bpl myloop

Trong khi thực hiện sáu lệnh đầu tiên, lõi sẽ có thời gian để tìm nạp sáu từ, trong đó ba từ sẽ được thực thi, do đó có thể có tới ba từ được tìm nạp trước. Các hướng dẫn tiếp theo là tất cả ba từ mỗi từ, do đó, lõi sẽ không thể tìm nạp các hướng dẫn nhanh như khi chúng được thực thi. Tôi hy vọng rằng một số hướng dẫn "nó" sẽ có một chu kỳ, nhưng tôi không biết làm thế nào để dự đoán những hướng dẫn nào.

Sẽ thật tuyệt nếu ARM có thể chỉ định một số điều kiện nhất định theo đó thời gian của lệnh "it" sẽ mang tính xác định (ví dụ: nếu không có trạng thái chờ hoặc tranh chấp bus-code, và hai hướng dẫn trước là hướng dẫn đăng ký 16 bit, v.v.) nhưng tôi chưa thấy thông số nào như vậy

Ứng dụng mẫu

Giả sử một người đang cố gắng thiết kế bảng con cho Atari 2600 để tạo đầu ra video thành phần ở 480P. 2600 có xung nhịp 3,579 MHz và xung nhịp CPU 1,19 MHz (đồng hồ chấm / 3). Đối với video thành phần 480P, mỗi dòng phải được xuất hai lần, ngụ ý đầu ra xung nhịp chấm 7.158 MHz. Do chip video của Atari (TIA) tạo ra một trong 128 màu sử dụng tín hiệu luma 3 bit cộng với tín hiệu pha có độ phân giải khoảng 18ns, nên sẽ khó xác định chính xác màu chỉ bằng cách nhìn vào đầu ra. Một cách tiếp cận tốt hơn sẽ là chặn ghi vào các thanh ghi màu, quan sát các giá trị được ghi và cung cấp cho mỗi thanh ghi trong các giá trị độ chói TIA tương ứng với số thanh ghi.

Tất cả điều này có thể được thực hiện với một GPU, nhưng một số thiết bị ARM khá nhanh có thể rẻ hơn nhiều so với một GPU có đủ RAM để xử lý bộ đệm cần thiết (vâng, tôi biết rằng đối với các khối lượng như vậy có thể được sản xuất thì chi phí không phải là ' t một yếu tố thực tế). Yêu cầu ARM để xem tín hiệu đồng hồ đến, tuy nhiên, sẽ làm tăng đáng kể tốc độ CPU cần thiết. Số lượng chu kỳ dự đoán có thể làm cho mọi thứ sạch hơn.

Một cách tiếp cận thiết kế tương đối đơn giản là để CPLD xem CPU và TIA và tạo tín hiệu đồng bộ RGB + 13 bit, sau đó ARM DMA lấy các giá trị 16 bit từ một cổng và ghi chúng sang cổng khác với thời gian thích hợp. Tuy nhiên, sẽ là một thử thách thiết kế thú vị để xem liệu một ARM giá rẻ có thể làm mọi thứ hay không. DMA có thể là một khía cạnh hữu ích của cách tiếp cận tất cả trong một nếu có thể dự đoán được tác động của nó đối với số lượng chu kỳ CPU (đặc biệt là nếu chu kỳ DMA có thể xảy ra theo chu kỳ khi bus bộ nhớ không hoạt động), nhưng tại một số điểm trong quá trình ARM sẽ phải thực hiện các chức năng tra cứu bảng và xem xe buýt. Lưu ý rằng không giống như nhiều kiến ​​trúc video nơi các thanh ghi màu được ghi trong các khoảng trống, Atari 2600 thường ghi vào các thanh ghi màu trong phần hiển thị của khung,

Có lẽ cách tiếp cận tốt nhất là sử dụng một vài chip logic rời rạc để xác định ghi màu và buộc các thanh ghi màu thấp hơn đến các giá trị phù hợp, sau đó sử dụng hai kênh DMA để lấy mẫu dữ liệu đầu ra của bus CPU và TIA và một kênh DMA thứ ba để tạo dữ liệu đầu ra. CPU sau đó có thể tự do xử lý tất cả dữ liệu từ cả hai nguồn cho mỗi dòng quét, thực hiện dịch thuật cần thiết và đệm nó cho đầu ra. Khía cạnh duy nhất trong nhiệm vụ của bộ điều hợp sẽ xảy ra trong "thời gian thực" sẽ là ghi đè dữ liệu được ghi vào COLUxx và có thể được sử dụng hai chip logic thông thường.

Câu trả lời:


7

Tôi bỏ phiếu cho DMA. Nó thực sự linh hoạt trong Cortex-M3 trở lên - và bạn có thể thực hiện tất cả các loại điều điên rồ như tự động lấy dữ liệu từ một nơi và xuất ra nơi khác với tốc độ được chỉ định hoặc tại một số sự kiện mà không tốn bất kỳ chu kỳ CPU nào. DMA đáng tin cậy hơn nhiều.

Nhưng nó có thể khá khó để hiểu chi tiết.

Một tùy chọn khác là lõi mềm trên FPGA với phần cứng thực hiện những thứ chặt chẽ này.


1
Tôi thích khái niệm DMA. Tuy nhiên, tôi không nghĩ rằng lõi Cortex M3 có bất kỳ DMA nào - đó là chức năng của chip của các nhà sản xuất riêng lẻ và tất cả họ dường như thực hiện nó theo cách khác. Một điều tôi thấy khó chịu với ít nhất một triển khai mà tôi thực sự đã chơi với (STM32L152), là tôi không thể tìm thấy bất kỳ cách nào để có một bước chân khi dữ liệu DMA được xuất ra. Cũng không rõ những yếu tố nào có thể ảnh hưởng đến tính kịp thời của DMA.
supercat

1
Trong mọi trường hợp, liên quan đến một trong những ứng dụng đầu tiên tôi đang cân nhắc cho việc đập chu kỳ chính xác, tôi đã đăng thêm thông tin trong câu hỏi ban đầu. Tôi tò mò bạn nghĩ gì. Một tình huống khác khi tôi đang cân nhắc việc đập chu kỳ sẽ làm nổ dữ liệu hiển thị sang màn hình LCD màu. Dữ liệu sẽ được đệm trong RAM bằng màu 8 bit, nhưng màn hình cần màu 16 bit. Cách nhanh nhất mà tôi nghĩ đến để xuất dữ liệu sẽ là sử dụng phần cứng để tạo ra các ngăn ghi, vì vậy CPU sẽ chỉ phải xử lý dữ liệu. Sẽ tốt hơn nếu dịch 8-> 16 bit thành một bộ đệm nhỏ ...
supercat

1
... Và sau đó sắp xếp DMA để chuyển nó, hoặc cách tiếp cận tốt nhất là gì?
supercat

4

Thông tin về thời gian có sẵn, nhưng, như bạn đã chỉ ra, đôi khi có thể mơ hồ. Có rất nhiều thông tin về thời gian trong Phần 18.2 và Bảng 18.1 của Tài liệu tham khảo kỹ thuật cho Cortex-M3, ví dụ, ( pdf tại đây ) và một đoạn trích ở đây:

trích đoạn 18.2

trong đó đưa ra một danh sách các điều kiện cho thời gian tối đa. Thời gian cho nhiều hướng dẫn phụ thuộc vào các yếu tố bên ngoài, một số trong đó không để lại sự mơ hồ. Tôi đã nhấn mạnh từng điều mơ hồ mà tôi tìm thấy trong đoạn trích sau từ phần đó:

[1] Chi nhánh mất một chu kỳ cho hướng dẫn và sau đó tải lại đường ống cho hướng dẫn đích. Các nhánh không lấy là tổng số 1 chu kỳ. Các nhánh được thực hiện ngay lập tức thường là 1 chu kỳ tải lại đường ống (tổng cộng 2 chu kỳ). Các nhánh lấy với toán hạng đăng ký là bình thường 2 chu kỳ tải lại đường ống (tổng cộng 3 chu kỳ). Tải lại đường ống dài hơn [Bao lâu?] Khi phân nhánh theo hướng dẫn 32 bit không được phân bổ ngoài việc truy cập vào bộ nhớ chậm hơn. Một gợi ý nhánh được phát ra trên bus mã cho phép hệ thống chậm hơn [chậm hơn bao nhiêu?] Để tải trước. Điều này có thể [Đây là tùy chọn?] Giảm [Bao nhiêu?] Hình phạt mục tiêu chi nhánh cho bộ nhớ chậm hơn, nhưng không bao giờ ít hơn hiển thị ở đây.

[2] Nói chung, hướng dẫn lưu trữ tải có hai chu kỳ cho lần truy cập đầu tiên và một chu kỳ cho mỗi lần truy cập bổ sung. Các cửa hàng với sự bù đắp ngay lập tức mất một chu kỳ.

[3] UMULL / SMULL / UMLAL / SMLAL sử dụng kết thúc sớm tùy thuộc vào kích thước của các giá trị nguồn [Kích cỡ nào?]. Đây là những gián đoạn (bị bỏ rơi / khởi động lại), với độ trễ trường hợp xấu nhất của một chu kỳ. Các phiên bản MLAL mất bốn đến bảy chu kỳ và các phiên bản MULL mất từ ba đến năm chu kỳ . Đối với MLAL, phiên bản đã ký dài hơn một chu kỳ so với không dấu.

[4] Hướng dẫn CNTT có thể được gấp lại . [Khi nào? Xem ý kiến.]

[5] Thời gian DIV phụ thuộc vào cổ tức và ước số . [Vấn đề tương tự như MUL] DIV bị gián đoạn (bị bỏ / khởi động lại), với độ trễ trường hợp xấu nhất trong một chu kỳ. Khi cổ tức và ước số tương tự nhau [Làm thế nào giống nhau?] Về kích thước, sự phân chia chấm dứt nhanh chóng. Thời gian tối thiểu dành cho các trường hợp ước số lớn hơn cổ tức và ước số bằng 0. Một ước số của 0 trả về 0 (không phải là lỗi), mặc dù bẫy gỡ lỗi có sẵn để bắt trường hợp này. [Phạm vi, được đưa ra cho MUL là gì?]

[6] Ngủ là một chu kỳ cho hướng dẫn cộng với càng nhiều chu kỳ ngủ càng phù hợp. WFE chỉ sử dụng một chu kỳ khi sự kiện đã qua. WFI thường là nhiều hơn một chu kỳ trừ khi một ngắt xảy ra chính xác khi vào WFI.

[7] ISB mất một chu kỳ (hoạt động như một nhánh). DMB và DSB mất một chu kỳ trừ khi dữ liệu đang chờ xử lý trong bộ đệm ghi hoặc LSU. Nếu một ngắt xuất hiện trong một rào chắn, nó bị bỏ qua / khởi động lại.

Đối với tất cả các trường hợp sử dụng, nó sẽ phức tạp hơn "Hướng dẫn này là một chu kỳ, hướng dẫn này là hai chu kỳ, đây là một chu kỳ ..." có thể tính trong các bộ xử lý cũ đơn giản hơn, chậm hơn. Đối với một số trường hợp sử dụng, bạn sẽ không gặp phải bất kỳ sự mơ hồ nào. Nếu bạn gặp phải sự mơ hồ, tôi đề nghị:

  1. Liên hệ với nhà cung cấp của bạn và hỏi họ thời gian hướng dẫn cho trường hợp sử dụng của bạn.
  2. Kiểm tra để xác định hành vi mơ hồ
  3. Kiểm tra lại cho bất kỳ sửa đổi bộ xử lý và đặc biệt là khi trải qua các thay đổi của nhà cung cấp.

Những yêu cầu này có thể làm cho câu trả lời cho câu hỏi của bạn, "Không, đó không phải là một ý tưởng hay, trừ khi những khó khăn gặp phải là đáng giá" - nhưng bạn đã biết điều đó.


1
Tôi sẽ coi những điều sau đây là mơ hồ: "Tải lại đường ống dài hơn khi phân nhánh thành các lệnh 32 bit không được phân bổ ngoài việc truy cập vào bộ nhớ chậm hơn" không cho biết liệu có thêm chính xác một chu kỳ hay không và "có thể gập lại các hướng dẫn CNTT" 'T chỉ định trong những điều kiện họ sẽ hoặc sẽ không.
supercat

1
Thời gian "CNTT" có vẻ đặc biệt rắc rối, vì đó là một hướng dẫn thường được sử dụng trong một vòng lặp được tính theo chu kỳ chặt chẽ và tôi khá chắc chắn rằng nó không thể luôn luôn bị gấp lại. Tôi đoán rằng nếu một người luôn phân nhánh bắt đầu một vòng lặp nhạy cảm với thời gian, buộc vòng lặp bắt đầu tại một ranh giới từ, tránh mọi tải hoặc điều kiện lưu trữ trong vòng lặp và không đặt bất kỳ lệnh "CNTT" nào ngay lập tức sau khi tải hoặc cửa hàng cập nhật đăng ký, thời gian "CNTT" sẽ nhất quán, nhưng thông số kỹ thuật không làm rõ điều đó.
supercat

1
Tôi đoán là CNTT có thể (thực sự) lưu ý điều gì đó như: "Trong trường hợp không có trạng thái chờ hoặc tranh chấp mã-bus, việc gấp IT được đảm bảo nếu (1) lệnh trước đó là lệnh 16 bit không truy cập được bộ nhớ hoặc bộ đếm chương trình và (2) hoặc lệnh tiếp theo là lệnh 16 bit hoặc lệnh trước không phải là mục tiêu của nhánh "không được phân bổ". Việc gấp IT cũng có thể xảy ra trong các trường hợp không xác định khác. " Một thông số kỹ thuật như vậy sẽ cho phép một người viết các chương trình với thời gian hướng dẫn CNTT có thể dự đoán được bằng cách đảm bảo mã được sắp xếp như đã chỉ ra.
supercat

1
Wow - Tôi thú nhận rằng tôi chỉ trải qua các chu kỳ trong trường hợp xấu nhất đơn giản, thay vì thực sự vật lộn với những lời cảnh báo bên dưới bàn. Câu trả lời cập nhật của tôi làm nổi bật một số sự mơ hồ khác.
Kevin Vermeer

1
Có rất nhiều tình huống mà một người quan tâm đến số đếm trường hợp xấu nhất và một số hợp lý trong đó một người quan tâm đến số lượng trường hợp tốt nhất (ví dụ: nếu một cổng SPI có thể xuất ra một byte cứ sau 16 chu kỳ, thì mỗi byte sẽ mất 14 chu kỳ trường hợp tốt nhất và kiểm tra mức độ sẵn sàng sẽ mất 5 chu kỳ, kiểm tra mức độ sẵn sàng mỗi byte sẽ giới hạn tốc độ ở mức một byte trong mỗi 19 chu kỳ tốt nhất, viết mù với hai NOP được thêm vào sẽ cho phép tốc độ một byte trong mỗi 16 chu kỳ ). Các trường hợp cần thời gian chính xác không phải là phổ biến, nhưng chúng có thể phát sinh.
supercat

3

Một cách để khắc phục vấn đề này là sử dụng các thiết bị có thời gian xác định hoặc có thể dự đoán được, chẳng hạn như chip Parallax Propeller và XMOS:

http://www.parallaxsframuctor.com/multicoreconcept

http://www.xmos.com/

Tính năng đếm chu kỳ hoạt động rất tốt với Propeller (phải sử dụng ngôn ngữ lắp ráp), trong khi các thiết bị XMOS có tiện ích phần mềm rất mạnh, Bộ phân tích thời gian XMOS, hoạt động với các ứng dụng được viết bằng ngôn ngữ lập trình XC:

https://www.xmos.com/doad/public/XMOS-Timing-Analyzer-Whitepaper%281%29.pdf


1
Tôi bắt đầu nghĩ rằng Leon có cổ phần trong XMOS ... ;-)
Federico Russo

1
Tôi chỉ thích chip của họ, và những người làm việc ở đó. Parallax là một công ty tốt với các sản phẩm tốt.
Leon Heller

1
Vâng, không có hành vi phạm tội. Tôi nhận ra rằng tất cả các câu trả lời (trừ một) trong đó XMOS được đề cập là từ bạn. Không có gì sai khi nhiệt tình về một cái gì đó.
Federico Russo

@Federico, @Leon - Đó chính xác là điều khiến tôi lo lắng một chút về XMOS: tại sao chỉ có 1 người dùng trên thế giới (ít nhất là như vậy)? Nếu nó tuyệt vời như vậy, tại sao nó không phải là cuộc nói chuyện của thị trấn? Tôi chưa bao giờ nghe ai nói về nó, ít sử dụng nó.
stevenvh

Hãy dùng thử các diễn đàn XMOS: xcore.com
Leon Heller

2

Việc đếm chu kỳ trở nên rắc rối hơn khi bạn thoát khỏi các bộ vi điều khiển cấp thấp và vào các bộ xử lý điện toán có mục đích chung hơn. Việc đầu tiên thường có thời gian hướng dẫn cụ thể, một phần vì lý do bạn trang web. Đó cũng là vì kiến ​​trúc của họ khá đơn giản, vì vậy thời gian hướng dẫn là cố định và có thể biết được.

Một ví dụ điển hình của việc này là hầu hết các PIC Microchip. Sê-ri 10, 12, 16 và 18 có thời gian hướng dẫn được ghi chép lại rất tốt. Đây có thể là một tính năng hữu ích trong các loại ứng dụng điều khiển nhỏ mà các chip này dành cho.

Khi bạn thoát khỏi chi phí cực thấp và do đó, nhà thiết kế có thể dành nhiều diện tích chip hơn để có tốc độ cao hơn từ một kiến ​​trúc kỳ lạ hơn, bạn cũng tránh xa khả năng dự đoán. Hãy xem các biến thể x86 hiện đại là những ví dụ cực đoan về điều này. Có một số cấp độ của bộ nhớ cache, tăng cường sinh lực của bộ nhớ, tìm nạp dữ liệu, đường ống, và nhiều hơn nữa, khiến cho việc đếm chu kỳ hướng dẫn gần như không thể. Trong ứng dụng này, điều đó không quan trọng mặc dù khách hàng quan tâm đến tốc độ cao, không phải là dự đoán thời gian hướng dẫn.

Bạn thậm chí có thể thấy hiệu ứng này tại nơi làm việc trong các mô hình Microchip cao hơn. Lõi 24 bit (sê-ri 24, 30 và 33) có thời gian hướng dẫn phần lớn có thể dự đoán được, ngoại trừ một vài trường hợp ngoại lệ khi có đăng ký tranh chấp xe buýt. Ví dụ, trong một số trường hợp, máy sẽ chèn một gian hàng khi lệnh tiếp theo sử dụng một thanh ghi với một số chế độ địa chỉ gián tiếp có giá trị được thay đổi trong lệnh trước đó. Loại gian hàng này là không bình thường trên một DSPIC và hầu hết thời gian bạn có thể bỏ qua nó, nhưng nó cho thấy những thứ này xuất hiện như thế nào do các nhà thiết kế cố gắng cung cấp cho bạn bộ xử lý nhanh hơn và có khả năng hơn.

Vì vậy, câu trả lời cơ bản là, đó là một phần của sự đánh đổi khi bạn chọn một bộ xử lý. Đối với các ứng dụng điều khiển nhỏ, bạn có thể chọn một cái gì đó nhỏ, rẻ, công suất thấp và với thời gian hướng dẫn dự đoán. Khi bạn yêu cầu nhiều sức mạnh xử lý hơn, kiến ​​trúc thay đổi để bạn phải từ bỏ thời gian hướng dẫn dự đoán. May mắn thay, đó không phải là vấn đề khi bạn có được các ứng dụng chuyên sâu và tính toán tổng quát hơn, vì vậy tôi nghĩ rằng sự đánh đổi hoạt động khá tốt.


Tôi đồng ý rằng nhìn chung các ứng dụng chuyên sâu về tính toán trở nên ít nhạy cảm hơn với thời gian hiển vi, nhưng có một số tình huống có thể cần xử lý nhiều hơn một chút so với PIC-18 nhưng cũng cần dự đoán. Tôi đang tự hỏi đến mức độ nào tôi nên nỗ lực để tìm hiểu những thứ như kiến ​​trúc PIC 16 bit, hoặc ở mức độ nào tôi nên nghĩ rằng ARM sẽ có khả năng đầy đủ.
supercat

0

Có, bạn vẫn có thể làm điều đó, ngay cả trên ARM. Vấn đề lớn nhất với ARM là ARM bán lõi không phải chip và thời gian cốt lõi được biết đến, nhưng những gì nhà cung cấp chip bao bọc xung quanh nó khác nhau tùy theo nhà cung cấp và đôi khi từ họ chip đến nhà cung cấp khác. Vì vậy, một con chip cụ thể từ một nhà cung cấp cụ thể có thể khá xác định (ví dụ nếu bạn không sử dụng bộ nhớ cache), nhưng trở nên khó chuyển hơn. Khi xử lý 5 đồng hồ ở đây và 11 đồng hồ ở đó sử dụng bộ hẹn giờ là vấn đề vì số lượng hướng dẫn cần thiết để lấy mẫu bộ hẹn giờ và tìm hiểu xem thời gian chờ của bạn đã hết hạn. Từ âm thanh của kinh nghiệm lập trình trước đây của bạn, tôi sẵn sàng đặt cược bạn có thể gỡ lỗi bằng máy hiện sóng như tôi, vì vậy bạn có thể thử một vòng lặp chặt chẽ trên chip ở tốc độ xung nhịp, xem spi hoặc i2c hoặc bất kỳ dạng sóng nào, thêm hoặc loại bỏ nops, thay đổi số lần thông qua vòng lặp và về cơ bản điều chỉnh. Như với bất kỳ nền tảng nào, việc không sử dụng các ngắt giúp hỗ trợ rất nhiều cho tính chất quyết định của việc thực hiện lệnh.

Không, nó không đơn giản như PIC, nhưng vẫn hoàn toàn có thể thực hiện được, nếu độ trễ / thời gian đạt đến tốc độ xung nhịp của bộ xử lý. Một số nhà cung cấp dựa trên ARM cho phép bạn nhân tốc độ xung nhịp và giảm 60 MHz so với tham chiếu 8 mhz, vì vậy nếu bạn cần giao diện 2 mhz thay vì thực hiện 4 hướng dẫn, bạn có thể tăng xung nhịp (nếu bạn có ngân sách năng lượng) và sau đó sử dụng một bộ đếm thời gian và cung cấp cho mình rất nhiều đồng hồ để làm những việc khác là tốt.

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.