Làm thế nào để bạn cấu trúc các dự án nhúng lớn? [đóng cửa]

Bối cảnh :

Kỹ sư điện tử Junior R & D ( EE duy nhất trong công ty ) - phần cứng và mã hóa không phải là vấn đề. Vấn đề lớn nhất của tôi là có được một cái nhìn tổng quan đúng đắn về dự án, và bắt đầu từ đâu.

Cho đến nay tôi chỉ thực hiện các dự án phần mềm nhỏ (500 dòng mã), nhưng tôi không thể hình dung mình sẽ thực hiện các dự án lớn hơn mà không mất tổng quan về chức năng hoặc thiếu chức năng.

Làm thế nào để bạn cấu trúc tốt nhất / bạn sử dụng công cụ nào để cấu trúc các hệ thống phần mềm nhúng lớn?

Những gì tôi đang làm :

Tôi thường bắt đầu, bằng cách phác thảo chức năng của dự án. Nó có thể là một đến nhiều biểu đồ dòng phân lớp hoặc sơ đồ liên quan (sơ đồ khối, v.v.) và thực hiện một số nghiên cứu về các thành phần / chip. Sau đó, tôi nhảy thẳng vào mã hóa (tôi đoán là không nhanh) trong khi tham khảo bảng dữ liệu / Internet, Mã hóa một chức năng tại một thời điểm và kiểm tra nó với dữ liệu giả hoặc thử nghiệm tương tự. Nó có thể ghi dữ liệu vào chip MEM, và sau đó nếu nó hoạt động thì đó có thể là trình điều khiển SPI giữa chip chính và chip MEM.

Câu trả lời tôi đang tìm kiếm :

Cái gì đó thật sự. Tôi sẽ sắp xếp những gì tôi thấy hợp lý. Nó có thể là một cuốn sách, một bài báo, kinh nghiệm cá nhân, khuyến nghị, v.v.

Tôi rất quan tâm đến việc biết người cao niên giải quyết vấn đề này như thế nào.

Chỉnh sửa

Trước hết, cảm ơn bạn đã chia sẻ kinh nghiệm nhiều năm của bạn! Tất cả các câu trả lời được nhiều đánh giá cao. Tôi lấy từ đây là;

• Tạo một tài liệu đặc tả rõ ràng và chính xác.
• Tạo một tài liệu thiết kế phần mềm. (Bây giờ tôi sẽ thêm) Thiết kế mẫu tài liệu
• Hãy suy nghĩ trong các mô-đun bao giờ có vẻ dư thừa. (Một cái gì đó tôi cần tập trung hơn vào)
• Thực hiện theo một tiêu chuẩn mã hóa để cấu trúc các tệp tiêu đề / nguồn. (Chưa bao giờ làm điều này) Tiêu chuẩn Barr Group C
• Tập trung vào việc tạo ra các triển khai cấp thấp đầu tiên. (Truyền thông, v.v.)
• Thực hiện các mẫu thiết kế bất cứ khi nào có thể / hợp lý. Mẫu thiết kế
• Thiết lập một cái gì đó để kiểm soát sửa đổi (Github, v.v. - không bao giờ sử dụng nhiều)
• Nghiên cứu tích hợp liên tục / triển khai liên tục (Một cái gì đó mới mà tôi tình cờ phát hiện ra) Khái niệm cơ bản về CI & CD

Có một số khía cạnh ảnh hưởng đến mức độ chi tiết của cấu trúc của một nhu cầu dự án. Đối với tôi, một trong những yếu tố chính là liệu tôi có phải là người duy nhất viết mã hay không (có vẻ như là trường hợp của bạn khi bạn viết bạn là EE duy nhất) hoặc nếu có người khác tham gia. Sau đó, có câu hỏi về "lớn" thực sự có nghĩa là gì. Thông thường tôi chia quá trình thiết kế thành các bước sau:

Định nghĩa yêu cầu Nếu bạn có được đặc tả phần mềm thích hợp để làm việc với nhiều kế hoạch đã được thực hiện. Nếu bạn chỉ nhận được những yêu cầu mơ hồ, điều đầu tiên bạn phải làm là sắp xếp những gì khách hàng thực sự muốn (đôi khi họ không thực sự biết ngay từ đầu). Tôi biết rằng thật hấp dẫn khi chỉ cần nhảy ngay vào mã hóa, nhưng điều đó có nguy cơ thiếu một tính năng quan trọng có thể không rõ ràng ngay từ đầu và không thể dễ dàng bị ép vào mã của bạn ở đâu đó ngay giữa quá trình phát triển.

Ranh giới hệ thống và khả năng bảo trì Trong các hệ thống nhúng, bạn thường có một số giao diện hệ thống, một số bên ngoài (toán tử) nhưng cũng ở bên trong. Xác định tốt những điều này và cố gắng giữ sự phụ thuộc càng thấp càng tốt, điều này sẽ đơn giản hóa kỹ thuật liên tục và khả năng bảo trì. Ngoài ra nhận xét / mã tài liệu khi cần, bạn sẽ không bao giờ biết ai sẽ phải làm việc với nó, anh ta sẽ rất vui khi không phải đào qua hàng tá lớp mã trước khi thực sự biết chức năng làm gì.

Xác định các tác vụ có thể kiểm chứng Đặc biệt là nếu các nhà phát triển khác đang làm việc trên cùng một cơ sở mã, không thể tránh khỏi việc xác định các tác vụ (tính năng) rõ ràng và các giao diện bắt buộc giữa chúng. Bất cứ khi nào có thể, các tính năng riêng lẻ nên được kiểm tra / xác minh độc lập với các tính năng khác, đó là nơi bạn cần các giao diện được xác định rõ để bạn có thể xác định các trường hợp thử nghiệm của mình.

Một tính năng sau khi những người khác thích tiến bộ, vì vậy nếu bạn có nhiều nhiệm vụ khác nhau, họ thường làm việc trên bất cứ điều gì hứa hẹn tiến bộ nhất. Tôi thường cố gắng hoàn thành một nhiệm vụ và đưa nó đến trạng thái được xác minh và thử nghiệm trước khi tôi bắt đầu với nhiệm vụ tiếp theo. Điều này cho phép mã của bạn được kiểm tra bởi người khác và cuối cùng bạn không quên điều gì.

Kiểm soát sửa đổi Trong vòng đời của một dự án, đôi khi bạn cần các phiên bản cũ hơn, có thể để xác định một lỗi được giới thiệu với một số bản phát hành mới hoặc chỉ để xây dựng một thiết bị hoạt động giống hệt như cách bạn đã vận chuyển 3 năm trước. Hãy chắc chắn rằng bạn có các bản sửa đổi và thẻ xây dựng rõ ràng trong mã của mình. Git chắc chắn là bạn của bạn ở đây.

Humpawumpa đã viết một câu trả lời tuyệt vời ! Tôi chỉ muốn bổ sung một số điểm của anh ấy, nhưng vì quá dài để nhận xét, tôi sẽ viết một câu trả lời riêng.

Tôi đã từng ở vị trí của OP - không phải EE duy nhất, mà là EE duy nhất đã thực hiện bất kỳ sự phát triển MCU nào trong một công ty nhỏ.

Tôi không thể nhấn mạnh tầm quan trọng của tính mô đun đủ, ngay cả khi bạn là nhà phát triển duy nhất. Đó là cách duy nhất để duy trì sự tỉnh táo khi dự án phát triển. Bạn cần nghiêm ngặt về việc viết các mô-đun chỉ xử lý một khái niệm chức năng và giữ các giao diện bên ngoài của chúng tối thiểu nhất có thể. Các mô-đun cấp cao sẽ tương ứng với các yêu cầu chức năng, trong khi các mô-đun cấp thấp sẽ có mối quan hệ chặt chẽ với tài nguyên phần cứng (ví dụ: trình điều khiển thiết bị).

Tôi đã dành rất nhiều thời gian để duy trì sơ đồ luồng dữ liệu chi tiết ¹ , cho thấy chính xác cách thức các mô-đun chia sẻ thông tin. Một số tính năng sẽ có các yêu cầu rất khác nhau về hiệu suất thời gian thực; hãy chắc chắn rằng bạn biết cách chia sẻ thông tin ảnh hưởng đến điều đó. Sơ đồ có các ranh giới được vẽ trên nó để tách mã không ngắt khỏi các miền điều khiển ngắt khác nhau.

¹ Rất khác với lưu đồ, tập trung vào luồng điều khiển .

Đối với bất kỳ dự án lớn nào, tôi lập kế hoạch cho nó như thể có nhiều nhà phát triển tham gia ngay cả khi tôi có ý định tự mình làm toàn bộ.

Những lý do rất đơn giản:

1 Độ phức tạp. Một dự án lớn sẽ luôn có sự phức tạp liên quan. Có kế hoạch dự án như thể có nhiều nhóm tham gia có nghĩa là sự phức tạp đã được xem xét và ghi lại . Số lần tôi thấy các dự án lớn gặp vấn đề rất cao và thường là do có gì đó 'trượt qua vết nứt'. Đừng quên rằng lắp ráp cơ học cũng phải được xem xét và không chỉ đơn giản là kích thước của hộp - sẽ có nhu cầu tản nhiệt? Hộp phải được nối đất cho an toàn? Có rất nhiều câu hỏi trong danh mục này một mình.

2 Yêu cầu. Giả sử có nhiều người tham gia có nghĩa là các yêu cầu cấp cao nhất (mà tôi thường thách thức vì chúng có thể mang lại sự phức tạp và chi phí không cần thiết) phải được chia thành các nhiệm vụ nhỏ hơn và có thể đạt được (có thể được cung cấp cho một nhóm khác trong một tổ chức lớn hơn ) thay vì chỉ nhìn vào một đốm màu.

3 Phân vùng. Có hai loại phân vùng chính; chức năng phần cứng và phần cứng / phần mềm. Loại đầu tiên là xác định những khối chức năng riêng biệt (nhưng giao tiếp) cần phải có mặt. Thứ hai là sự đánh đổi giữa phần cứng và phần mềm đơn giản (đôi khi) nhưng hãy nhớ rằng chỉ cần chuyển nhiều thứ hơn sang phần mềm sẽ không nhất thiết phải khắc phục sự cố phần cứng. Di chuyển nhiều hơn vào phần mềm thực sự có thể làm tăng đáng kể độ phức tạp phần cứng trong một số trường hợp (xử lý nhiều mã lực hơn, giao diện phức tạp hơn và nhiều hơn nữa).

4 Giao diện. Quá trình phân vùng sẽ giúp xác định các giao diện nội bộ; giao diện bên ngoài thường là một phần của các yêu cầu tổng thể (mặc dù không phải lúc nào cũng vậy). Có nhiều cách để các bộ phận khác nhau của một hệ thống hợp tác có thể là một giao thức truyền thông phức tạp hoặc đơn giản là tín hiệu tốt / xấu.

5 Xác minh. Đây là một hỗn hợp của thử nghiệm cấp thấp (đối với phần cứng và trình điều khiển) và cấp độ hệ thống. Việc thực hiện dự án trong các khối được xác định rõ sẽ cho phép xác minh mạnh mẽ (có thể bằng phân tích hoặc thử nghiệm thực tế và thường là hỗn hợp của cả hai; cập nhật cho thiết kế có thể sử dụng các đối số tương tự).

6 Tiêu chuẩn. Tôi sử dụng mã hóa và tiêu chuẩn vẽ như thể đó là một đội lớn hơn. Tôi sử dụng các tiêu chuẩn mã hóa của nhóm Barr vì chúng không quá nặng nề nhưng không ngăn được nhiều loại lỗi trong mã. Đối với tài liệu đầu ra PCB, tôi tuân theo IPC-D-326 (gọi IPC-D-325) vì đó là một phương pháp đã được chứng minh để truyền đạt ý định của tôi tới các nhà chế tạo và lắp ráp PCB. Điều này có vẻ lạ nhưng có kỷ luật để tuân theo một số tiêu chuẩn có nghĩa là chất lượng là phù hợp.

7 Kiểm soát phiên bản. Tôi sử dụng kiểm soát sửa đổi cho tất cả các phần của dự án (hệ thống, phần cứng, phần mềm. Cơ khí, yêu cầu kiểm tra - mọi thứ). Các công cụ CAD tôi sử dụng hỗ trợ tạo phiên bản như làm tất cả các công cụ xây dựng phần mềm và đồ họa.

Tôi đã làm việc trên nhiều dự án nhúng (cũng như nhiều người dân có kinh nghiệm ở đây) và quy mô nhóm đã thay đổi từ 1 (bản thân tôi) đến hàng chục (hoặc hàng trăm trên một tập hợp dự án cụ thể) trải rộng trên nhiều lĩnh vực và đôi khi từ xa về mặt địa lý các trang web. Sử dụng cùng một cách tiếp cận quá cong (được biết là có tác dụng) có nghĩa là tôi có thể nhận một nhiệm vụ cụ thể trong sự cô lập tương đối và hoàn thành nó và kiểm tra kỹ lưỡng nó như một phần độc lập của dự án lớn hơn. Nó cũng có nghĩa là tôi có thể phụ một số thứ trong dịp nếu cần thiết.

Làm tất cả những điều này thêm một chút thời gian trước nhưng cuối cùng là một tuyến nhanh hơn cho các hệ thống nhúng phức tạp.

Các câu trả lời khác cho nhiều lời khuyên tuyệt vời. Đây là hai điều mà tôi thấy quan trọng nhất trong sự nghiệp phát triển nhúng của mình:

1. Tạo càng nhiều mã thành các mô-đun riêng biệt, được xác định rõ càng tốt.
2. Làm cho các mô-đun tự động kiểm tra trên PC.

Đó là những gì bạn cần để thực hiện phát triển kiểu "tích hợp liên tục" trên các hệ thống nhúng. Sẽ luôn có một số lượng mã được gắn quá chặt vào phần cứng để kiểm tra tự động, nhưng hãy cố gắng giảm thiểu nó. Bạn có thể đi khá xa bằng cách sử dụng dữ liệu mô phỏng hoặc dữ liệu được chụp từ phần cứng thực tế, sau đó bạn đưa vào hệ thống kiểm tra.

Để thêm vào câu trả lời hiện có ...

Tôi luôn bắt đầu từ dưới lên. Từ thiết kế phần cứng của bạn, bạn biết I / O của bạn là gì. Bắt đầu bằng cách xây dựng các mô-đun trình điều khiển đóng gói I / O đó, để mã cấp cao của bạn không phải biết quá nhiều về nội dung cấp thấp.

Khi bạn đang xây dựng các giao diện cấp thấp, tất nhiên bạn cần một bộ kiểm tra khai thác. Nếu bạn thiết kế cái này để kết nối với PC ngay từ đầu (có thể với cổng RS-232, có thể là USB, có lẽ là telnet qua Ethernet) thì bạn có thể giữ giao diện khai thác thử nghiệm này khi bạn xây dựng ứng dụng của mình. Bạn có thể tiếp tục thêm nhiều móc khai thác thử nghiệm khi ứng dụng hình thành và điều đó sẽ cho phép bạn kiểm tra hồi quy mã của mình khi bạn tiếp tục.

Tôi có xu hướng suy nghĩ trong bốn câu hỏi. Hai cái đầu tiên thuộc về sự bắt đầu của một dự án hệ thống, hai cái tiếp theo về cuối.

1. Họ có thực sự muốn hệ thống? Hệ thống sẽ giải quyết vấn đề của khách hàng, ở quy mô thời gian và chi phí họ sẽ chấp nhận? Một vấn đề phổ biến là xây dựng các hệ thống mà khách hàng sẽ không sử dụng.

2. Chúng ta thực sự có thể xây dựng hệ thống đó không? Nó sẽ có thể cung cấp hiệu suất cần thiết, độ chính xác, sử dụng năng lượng, ...?

Tạo các nguyên mẫu sớm là một cách tốt để trả lời hai câu hỏi đầu tiên này. Giảm thiểu rủi ro là vô cùng quan trọng trong giai đoạn đầu.

Hai câu hỏi tiếp theo được nhắm mục tiêu nhiều hơn vào các giai đoạn sau của dự án:

3. chúng ta thực sự đã hoàn thành? Tất cả mọi thứ được thiết kế, mã hóa, thử nghiệm, giao hàng

4. Họ có thực sự sử dụng hệ thống?