Một vi điều khiển lớn, hay rất nhiều vi điều khiển nhỏ?

Tôi thường làm những việc cơ bản và đơn giản với vi điều khiển, nói một cách tương đối. Những thứ như đèn LED lái xe, động cơ chạy, thói quen cơ bản, GUI trên màn hình LCD của nhân vật, v.v., nhưng luôn chỉ là một nhiệm vụ chính với nhiều nhất một vài nhiệm vụ phụ. Điều này đã đưa tôi xuống các sản phẩm cấp thấp vì đó thực sự là tất cả những gì cần thiết trong những trường hợp đó.

Tôi muốn bắt đầu thiết kế những thứ phức tạp hơn nhưng mặt trên của tính liên tục của vi điều khiển không phải là thứ tôi đã tiếp xúc tốt. Do đó, tôi đã có một thời gian rất khó khăn khi cố gắng chọn một vi điều khiển, nơi tôi sẽ thực hiện nhiều nhiệm vụ cùng một lúc - tôi không thể nói chỉ bằng một số MIPS và một pinout thỏa đáng nếu nó có đủ mã lực để làm những gì tôi muốn làm.

Ví dụ, tôi muốn điều khiển 2 động cơ BLDC với các thói quen PI, bên cạnh một số comms nối tiếp và USB, GUI và một loạt các tác vụ khác. Tôi mong muốn chỉ có một bộ vi điều khiển cho mỗi động cơ và sau đó là một bộ cho các nhiệm vụ linh tinh để tôi có thể đảm bảo rằng chi phí hoạt động từ những thứ linh tinh sẽ không làm tăng hoạt động của động cơ quan trọng. Nhưng tôi không biết đó thực sự là một ý tưởng hay một cách ngây thơ để đi về mọi thứ.

Tôi đoán câu hỏi của tôi thực sự hai lần:

1. Cách tiếp cận tất cả trong một có phải là một ý tưởng tốt khi phải thực hiện nhiều thao tác đa nhiệm hay tốt hơn là phân đoạn và cách ly, và

2. Làm thế nào tôi có thể tìm ra bằng trực giác nếu vi điều khiển mà tôi đang xem có đủ sức mạnh tính toán để làm những gì tôi cần dựa trên danh sách các nhiệm vụ của tôi không?

Tôi đang xem xét các DSPIC33 vừa phải cho đến các SoC ARM chạy RTOS. Một cách có hệ thống để giảm bớt những gì tôi cần sẽ giúp tôi rất nhiều.

Các câu trả lời cho câu hỏi của bạn là khác nhau tùy thuộc vào mục tiêu cuối cùng của bạn là gì. Nếu bạn cần một số ít hoặc ít hơn các thiết bị này, bạn nên làm cho việc phát triển dễ dàng hơn và không phải lo lắng về chi phí bộ phận. Nếu bạn sẽ tạo ra một nghìn hoặc nhiều trong số này, thì đáng để phân tích các yêu cầu của bạn và giảm chi phí cho phần cứng thiết bị.

Số lượng nhỏ

Nếu bạn đang thực hiện một hoặc một vài hoạt động nhỏ của các thiết bị này, thì những nỗ lực phát triển của bạn sẽ làm giảm chi phí cho mỗi mặt hàng của bạn và bạn nên tập trung vào những gì sẽ dễ nhất / nhanh nhất để bạn phát triển, thay vì chi phí / kích thước của vi điện tử.

Trong đóng gói chung có thể làm giảm sự phức tạp, tăng năng suất của bạn. Nếu bạn có một số yêu cầu thời gian thực khó khăn, chẳng hạn như điều khiển BLDC, vòng lặp PID, v.v. thì bạn có thể thấy nhanh hơn khi sử dụng các bộ điều khiển riêng biệt cho các tác vụ giao tiếp với bộ điều khiển trong đó bạn giữ giao diện người dùng và các giao diện không thực khác nhiệm vụ thời gian.

Vì vậy, trong trường hợp này, câu trả lời cho câu hỏi của bạn là:

Cách tiếp cận tất cả trong một có phải là một ý tưởng tốt khi phải thực hiện nhiều thao tác đa nhiệm hay tốt hơn là phân đoạn và cách ly, và

Các mẹo quy mô hơi hướng tới phân khúc và cô lập. Lý do chính là việc gỡ lỗi một hệ thống thời gian thực có thể rất tốn thời gian và việc giữ các tác vụ đó trên bộ xử lý của riêng chúng sẽ hạn chế các biến bạn phải đo hoặc kiểm soát khi cố gắng tìm ra lý do tại sao một cái gì đó không hoạt động đúng.

Làm thế nào tôi có thể tìm ra bằng trực giác nếu vi điều khiển mà tôi đang xem có đủ sức mạnh tính toán để làm những gì tôi cần dựa trên danh sách các nhiệm vụ của tôi không?

Trong trường hợp này, chênh lệch chi phí giữa bộ xử lý 32 bit có nhiều tài nguyên và bộ xử lý 8 bit có tài nguyên hạn chế là nhỏ so với lượng thời gian bạn sẽ dành cho việc phát triển. Có rất ít lý do để thử và tìm hiểu xem bạn cần bao nhiêu năng lượng - chỉ cần có bộ xử lý lớn nhất mà bạn cảm thấy bạn có thể phát triển và sử dụng. Nếu tại một thời điểm nào đó sau này bạn cần chi phí tối ưu hóa thiết kế, thì việc đo mức sử dụng tài nguyên bộ xử lý thực tế là tương đối dễ dàng, sau đó chọn bộ xử lý bên cho thuê có thể xử lý tải thực tế. Cho đến lúc đó, hãy sử dụng cái lớn nhất và đừng lo lắng về việc tìm kiếm "phù hợp nhất".

Sản xuất hàng loạt

Nếu bạn có kế hoạch sản xuất nhiều thiết bị này, thì phân tích cẩn thận sẽ mang lại hiệu quả tiết kiệm chi phí đáng kể. Nói chung, một vi điều khiển lớn hơn sẽ có giá thấp hơn hai vi điều khiển có khả năng thay thế vi điều khiển đơn, mặc dù chắc chắn có các ngoại lệ tùy thuộc vào các tác vụ cụ thể được yêu cầu. Với số lượng này, chi phí cho phần cứng có thể sẽ lớn hơn nhiều so với chi phí phát triển, do đó bạn nên dành nhiều thời gian để phân tích các yêu cầu của mình và thực hiện phát triển hơn so với nếu bạn chỉ thực hiện một số ít.

Là cách tiếp cận tất cả trong một là một ý tưởng tốt khi phải thực hiện nhiều thao tác đa nhiệm, hay tốt hơn là phân đoạn và cách ly?

Cách tiếp cận tất cả trong một nói chung sẽ ít tốn kém hơn trong suốt vòng đời của toàn bộ dự án so với nhiều bộ xử lý. Nó sẽ đòi hỏi nhiều thời gian phát triển và gỡ lỗi hơn để đảm bảo các tác vụ khác nhau không xung đột, nhưng thiết kế phần mềm nghiêm ngặt sẽ hạn chế gần như nhiều phần cứng riêng biệt.

Làm thế nào tôi có thể tìm ra bằng trực giác nếu vi điều khiển mà tôi đang xem có đủ sức mạnh tính toán để làm những gì tôi cần dựa trên danh sách các nhiệm vụ của tôi không?

Bạn sẽ cần hiểu các nhiệm vụ bạn muốn thực hiện và số lượng tài nguyên chúng thực hiện. Giả sử như sau là đúng:

Các thói quen BLDC PI của bạn sẽ tiêu tốn X chu kỳ thời gian của bộ xử lý 100 lần một giây và mỗi lần cần khoảng 50 byte RAM để hoạt động, 16 byte EEPROM để điều chỉnh và flash 1k cho mã. Mỗi người sẽ cần 3 thiết bị ngoại vi PWM mười sáu bit trong vi điều khiển. Bạn có thể cần chỉ định jitter, sẽ có các yêu cầu độ trễ ngắt cụ thể.

USB và các thói quen nối tiếp của bạn sẽ tiêu tốn Y chu kỳ thời gian của bộ xử lý trên cơ sở khi cần thiết, RAM 2k, EEPROM 64 byte và đèn flash 8k. Nó sẽ yêu cầu USB và thiết bị ngoại vi nối tiếp.

GUI của bạn sẽ tiêu thụ Z chu kỳ công suất bộ xử lý 30 lần một giây và sẽ cần 2k RAM, 128 byte EEPROM và flash 10k. Nó sẽ sử dụng 19 I / O để liên lạc với màn hình LCD, các nút, núm, v.v.

Khi bạn mới bắt đầu, có thể khó hiểu X, Y, Z thực sự là gì và điều này sẽ thay đổi một chút tùy thuộc vào kiến ​​trúc của bộ xử lý. Tuy nhiên, bạn sẽ có thể hiểu được, trong một ước tính sân bóng, bao nhiêu ram, eeprom và flash thiết kế của bạn sẽ cần, và những thiết bị ngoại vi nào bạn cần. Bạn có thể chọn một họ bộ xử lý đáp ứng các yêu cầu về bộ nhớ và ngoại vi của bạn và có nhiều tùy chọn hiệu năng trong họ đó. Tại thời điểm đó, để phát triển, bạn chỉ cần sử dụng bộ xử lý mạnh nhất trong gia đình. Khi bạn đã thực hiện thiết kế của mình, bạn có thể dễ dàng chuyển gia đình về quyền lực sang tùy chọn chi phí thấp hơn mà không thay đổi môi trường thiết kế hoặc phát triển của bạn.

Sau khi bạn thực hiện đủ các thiết kế này, bạn sẽ có thể ước tính X, Y và Z tốt hơn. Bạn sẽ biết rằng các thói quen BLDC PI, mặc dù chạy thường xuyên, khá nhỏ và yêu cầu rất ít chu kỳ. Các thói quen USB và nối tiếp đòi hỏi rất nhiều chu kỳ, nhưng xảy ra không thường xuyên. Giao diện người dùng yêu cầu một vài chu kỳ thường xuyên để tìm thay đổi, nhưng sẽ yêu cầu rất nhiều chu kỳ không thường xuyên để cập nhật màn hình.

Tôi sẽ tách điều khiển động cơ và có một bộ vi điều khiển riêng bao gồm PWM (có lẽ là PIC18) cho mỗi hai động cơ BLDC, vì điều khiển PI là một nhiệm vụ riêng biệt khi nó được khởi động và khi bạn viết mã cho bạn có thể sử dụng nó trên cả micros. Bạn có thể kết nối chúng trở lại vi điều khiển chính thông qua giao diện như I²C và tải xuống các tham số cho điều khiển PI từ đó nếu bạn muốn. Điều đó sẽ cho phép bạn sửa đổi chúng trong GUI của bạn.

Sau đó tôi sẽ chạy mọi thứ khác trong vi điều khiển chính, chẳng hạn như PIC24 (PIC32 có thể là quá mức cần thiết, dựa trên các tác vụ bạn đã liệt kê). Cộng với PIC24E nhanh nhất có thể chạy gần như nhanh như PIC32.

Khi chọn một vi điều khiển, trước tiên tôi ước tính lượng flash và RAM mà tôi cần, sau đó xem xét độ dài từ và tốc độ xử lý. Để sau này, thường thì yêu cầu khó nhất để đáp ứng là ngắt nhanh nhất mà bạn mong muốn xử lý. Ví dụ, nếu bạn đang phát ra âm thanh 16 KHz và bị gián đoạn cứ sau 62,5, thì tốt hơn hết bạn nên có một bộ vi điều khiển với thời gian hướng dẫn giảm xuống hàng chục nano giây, hoặc bạn sẽ không thể phục vụ nó và nhận được bất kỳ thứ gì khác công việc đã hoàn thành

Có một cách tiếp cận bán chính thức mà bạn có thể sử dụng để giúp bạn tạo câu trả lời. Tôi đặc biệt khuyên bạn nên đọc chương 2 của "Thiết kế hệ thống nhúng" của White, hầu hết trong số đó có sẵn tại Google Sách .

Chương này nói về thiết kế kiến ​​trúc hệ thống và đưa ra cách tiếp cận bán chính thức về cách bạn có thể gói gọn các nhiệm vụ tốt nhất. Mặc dù chương này chủ yếu nói về một hệ thống điều khiển, nó dễ dàng mở rộng ra nhiều bộ điều khiển. Nó sẽ giúp bạn hình dung những tài nguyên nào cần được chia sẻ và giúp bạn chọn mức độ đóng gói cho từng nhiệm vụ.

Cô ấy đưa ra nhiều quan điểm để xem xét, một trong số đó tôi trình bày dưới đây, nhưng có nhiều thao tác hữu ích. Điều này, tất nhiên, không có ý nghĩa gì nhiều, nhưng tôi hy vọng nó khuyến khích bạn xem chương này.

Đối với "làm thế nào để tôi biết nếu tôi có đủ bộ điều khiển", sở thích riêng của tôi là đưa càng nhiều năng lượng vào hộp cát thiết kế của mình càng tốt, và sau đó tìm ra có bao nhiêu tài nguyên tôi có thể cắt giảm khi thiết kế hoạt động tốt đường. Sự khác biệt về giá giữa vi điều khiển $ 10 và vi điều khiển $ 3 cho mục đích tạo mẫu có thể chỉ là vài tuần để trang bị lại và vặn ngón tay cái của bạn chờ đợi các bộ phận mới, trong khi thiết kế luôn có thể tiếp tục di chuyển nếu bạn có đủ năng lượng.

Tôi làm việc trên một hệ thống rộng rãi như những gì bạn mô tả - động cơ, IO, hiển thị, 3x UARTs + SPI + I2C chạy trên Coldfire 52259 (micro 32-bit ~ 80 MHz tầm trung) và không quá khó, mặc dù nhận được kiến trúc phần mềm rất quan trọng - chúng tôi có rất nhiều thứ chạy trên phần cứng và ngắt (mọi thứ mà phần cứng có thể tự xử lý, chúng tôi chạy trong phần cứng & dịch vụ có ngắt) để lại vòng lặp main () để thực hiện tất cả công việc vệ sinh.

Cá nhân tôi không thích hầu hết các RTOS mà tôi đã thấy, ở cấp thấp họ làm hỏng một dự án, thêm một thứ khác để học và bạn sẽ có được hiệu suất tốt hơn từ phần cứng bằng cách thực hiện trực tiếp (sử dụng các chức năng phần cứng có sẵn + ngắt) thay vì làm giả nó bằng phần mềm.

Ở cấp cao, những ngày này dường như có rất ít sự chênh lệch giữa MCU đủ phức tạp và đủ mạnh để thực sự hưởng lợi từ RTOS và thứ gì đó (SoC) chỉ chạy Linux nhúng.

Tuy nhiên, trong trường hợp đó tôi sẽ nói rằng có một số giá trị trong việc sử dụng kính hiển vi nhỏ giá rẻ để xử lý các chức năng quan trọng (điều khiển động cơ EG trong đó thời gian hoặc dừng ở giới hạn là rất quan trọng) theo lệnh của CPU "não" chính vì vậy bạn không dựa vào trên hệ điều hành "không phải thời gian thực" để làm việc gì đó kịp thời.

Mọi người elses trả lời là tốt hơn nhưng tôi có một chút để thêm có thể hữu ích. Điều này có thể hơi sai và tôi rất muốn thêm nó dưới dạng một nhận xét nhưng có một quy tắc 50 rep :(

Câu trả lời ngắn gọn là tùy thuộc, xem ở trên nhưng tại sao không nghĩ về lợi ích của bộ xử lý quá.

$\frac{1}{((1-p)+\frac{p}{s})}$

Tất nhiên, chi phí, dễ thực hiện; vv là quan trọng và thậm chí quan trọng hơn để xem xét là tốt.

Câu trả lời có thể phụ thuộc vào chi tiết thực hiện. Một số nhiệm vụ dễ thực hiện hơn một cách sạch sẽ và mạnh mẽ trên các bộ vi điều khiển riêng biệt. Tiêu thụ năng lượng cũng có thể là một sự cân nhắc - nói chung một xử lý vi mô đơn lẻ một số nhiệm vụ sẽ cần ít năng lượng hơn so với một số xử lý vi mô đơn lẻ.

"Mã lực" là thứ yếu để bạn có thể thực hiện các ràng buộc thời gian thực của mình hay không.

Nếu bạn có hai đầu ra PWM và cả hai cần phải chuyển đổi cùng một lúc, thì bạn cần phải có sự song song cần thiết để có thể làm điều đó. Nếu bạn có một bộ điều khiển PWM chuyên dụng đảm nhiệm thời gian chính xác, nó sẽ hoạt động, ngay cả với một vi điều khiển khá nhỏ, trong khi giải pháp dựa trên GPIO sẽ rất phức tạp ngay cả khi có nhiều năng lực tính toán.

Đối với hầu hết các giao thức, MCU hiện đại có nhúng các triển khai của các phần của giao thức có các ràng buộc thời gian thực, vì vậy nếu bạn có thể tìm thấy một MCU có các thiết bị ngoại vi cần thiết và có tốc độ CPU cần thiết để xử lý các luồng dữ liệu (nghĩa là yêu cầu thời gian thực cứng bị suy giảm vào một yêu cầu thời gian thực mềm của mẫu "sẽ có thể đọc từ FIFO trước khi nó đầy, và nhanh hơn khi nó đầy"), đó sẽ là lựa chọn tối ưu.

Nếu không có giải pháp nào như vậy, các tùy chọn của bạn sẽ chuyển các chức năng ra các bộ điều khiển riêng biệt, sử dụng giải pháp CPU + FPGA (ví dụ: FPGA với lõi ARM cứng) hoặc giải pháp thuần túy (tùy chọn với CPU mềm, tùy thuộc vào yêu cầu phức tạp).