lập trình vi điều khiển và lập trình hướng đối tượng

Tôi đã thực hiện một số lập trình hướng đối tượng cơ bản với C ++ (tạo B-Tree, Thuật toán băm, Danh sách liên kết kép) và tôi đã thực hiện dự án nhỏ trong C (như tạo một máy tính khoa học, v.v.)

Lập trình phần cứng (cụ thể cho các bộ điều khiển vi mô) khác với lập trình hướng phần mềm / đối tượng như thế nào về tư duy và "tư duy" mà lập trình viên phải có?

Là một người thường được coi là khó khăn hơn so với những người khác của tôi?

Với nền tảng của tôi (như được mô tả ở trên) tôi sẽ cần nhiều sự chuẩn bị để đi vào lập trình phần cứng hay tôi có thể lao thẳng vào mà không cần chuẩn bị quá nhiều không?

Bạn sẽ phải từ bỏ hoàn toàn mô hình hướng đối tượng khi giao dịch với hầu hết các bộ vi điều khiển.

Các bộ vi điều khiển thường được đăng ký và giới hạn RAM, với tốc độ xung nhịp chậm và không có đường dẫn mã song song / đường ống. Bạn có thể quên Java trên PIC chẳng hạn.

Bạn phải đi vào một tư duy ngôn ngữ lắp ráp và viết theo thủ tục.

Bạn phải giữ mã của mình tương đối bằng phẳng và tránh đệ quy, vì các giới hạn RAM thường có thể dẫn đến các vấn đề về ngăn xếp.

Bạn phải học cách viết các thói quen dịch vụ ngắt hiệu quả (thường là bằng ngôn ngữ lắp ráp).

Bạn có thể phải cấu trúc lại các phần của mã theo cách thủ công, bằng ngôn ngữ hợp ngữ, để thực hiện chức năng mà trình biên dịch không hỗ trợ (hoặc hỗ trợ kém).

Bạn phải viết mã toán học có tính đến kích thước từ và thiếu khả năng FPU của hầu hết các bộ vi điều khiển (tức là thực hiện phép nhân 32 bit trên micro 8 bit = evil).

Đó là một thế giới khác. Đối với tôi, có một nền tảng khoa học máy tính hoặc lập trình chuyên nghiệp có thể gây trở ngại không kém gì việc không có kiến ​​thức gì cả khi làm việc với vi điều khiển.

Bạn cần suy nghĩ về một số điều:

• Bạn sẽ sử dụng C làm ngôn ngữ
• Bạn vẫn có thể tạo cảm giác hướng đối tượng bằng cách sử dụng các con trỏ hàm để bạn có thể ghi đè các hàm, v.v. Tôi đã sử dụng phương pháp này trong các dự án trước đây và hiện tại và hoạt động rất tốt. Vì vậy, OO là một phần ở đó nhưng không phải trong ý nghĩa C ++.

Có những hạn chế khác sẽ xuất hiện để chơi như tốc độ và bộ nhớ hạn chế. Vì vậy, như một hướng dẫn chung, tôi tránh:

• Sử dụng heap, nếu có cách giải quyết vấn đề mà không cần Malloc, tôi làm điều đó. Ví dụ, tôi preallocate bộ đệm và chỉ sử dụng chúng.
• Tôi cố tình giảm kích thước ngăn xếp trong cài đặt trình biên dịch để đối mặt với các vấn đề kích thước ngăn xếp từ sớm, tối ưu hóa điều đó một cách cẩn thận.
• Tôi giả sử rằng mỗi dòng mã sẽ bị gián đoạn bởi một sự kiện, vì vậy tôi tránh mã không được gửi lại
• Tôi giả sử ngay cả các ngắt được lồng nhau vì vậy tôi viết mã đó cho phù hợp
• Tôi tránh sử dụng HĐH trừ khi cần thiết. 70% các dự án nhúng không thực sự cần một hệ điều hành. Nếu tôi phải sử dụng HĐH, tôi chỉ sử dụng thứ gì đó có sẵn mã nguồn. (Freertos, v.v.)
• Nếu tôi đang sử dụng HĐH, tôi hầu như luôn luôn trừu tượng để có thể thay đổi HĐH trong vài giờ.
• Đối với trình điều khiển, v.v. Tôi sẽ chỉ sử dụng các thư viện do nhà cung cấp cung cấp, tôi không bao giờ trực tiếp sử dụng các bit, trừ khi tôi không có lựa chọn nào khác. Điều này làm cho mã có thể đọc được và cải thiện việc gỡ lỗi.
• Tôi nhìn vào các vòng lặp và các thứ khác, đặc biệt là trong ISR, để đảm bảo chúng đủ nhanh.
• Tôi luôn giữ một vài GPIO tiện dụng để đo lường công cụ, chuyển đổi ngữ cảnh, thời gian chạy ISR, v.v.

Danh sách tiếp tục, tôi có thể dưới mức trung bình về lập trình phần mềm, tôi chắc chắn có những thực tiễn tốt hơn.

Tôi làm cả hai, vì vậy đây là quan điểm của tôi.

Tôi nghĩ rằng kỹ năng quan trọng nhất từ ​​trước đến nay là khả năng sửa lỗi của bạn. Tư duy bắt buộc khác nhau ở chỗ rất nhiều điều có thể sai, và bạn phải rất cởi mở để xem xét tất cả các cách khác nhau mà những gì bạn đang cố gắng làm có thể đi sai.

Đây là vấn đề lớn nhất đối với các nhà phát triển nhúng mới. Người PC có xu hướng sử dụng nó khó khăn hơn, vì họ đã từng làm việc với họ rất nhiều. Thay vào đó, họ sẽ có xu hướng lãng phí nhiều thời gian để tìm kiếm các công cụ để làm việc cho họ (gợi ý: không có nhiều). Có rất nhiều cú đập đầu vào tường nhiều lần, không biết phải làm gì khác. Nếu bạn cảm thấy mình đang bị mắc kẹt, hãy lùi lại và tìm hiểu xem bạn có thể xác định được tất cả những gì có thể xảy ra không. Có hệ thống đi qua thu hẹp danh sách các vấn đề tiềm năng của bạn cho đến khi bạn tìm ra nó. Theo quy trình trực tiếp này, bạn nên giới hạn phạm vi vấn đề bằng cách không thay đổi quá nhiều cùng một lúc.

Những người nhúng có kinh nghiệm có xu hướng gỡ lỗi là điều hiển nhiên ... hầu hết những người không thể làm tốt điều đó không tồn tại lâu (hoặc làm việc trong các công ty lớn chỉ đơn giản chấp nhận "phần cứng là khó" như một câu trả lời cho lý do tại sao một tính năng nhất định là năm muộn)

Bạn đang làm việc với mã chạy trên một hệ thống bên ngoài cho hệ thống phát triển của bạn, với mức độ hiển thị khác nhau vào mục tiêu của bạn từ nền tảng đến nền tảng. Nếu dưới sự kiểm soát của bạn, hãy thúc đẩy các công cụ hỗ trợ phát triển để giúp tăng khả năng hiển thị này vào hệ thống mục tiêu của bạn. Sử dụng các cổng nối tiếp gỡ lỗi, đầu ra gỡ lỗi bit, đèn nhấp nháy nổi tiếng, v.v ... Chắc chắn ở mức tối thiểu tìm hiểu cách sử dụng máy hiện sóng và sử dụng chân I / O với phạm vi 'để xem khi nào một số chức năng vào / thoát, ISRs kích hoạt, v.v. . Tôi đã chứng kiến ​​mọi người đấu tranh trong nhiều năm theo nghĩa đen đơn giản hơn bởi vì họ không bao giờ bận tâm đến việc thiết lập / học cách sử dụng một liên kết trình gỡ lỗi JTAG thích hợp.

Điều quan trọng hơn nhiều là phải nhận thức chính xác những tài nguyên bạn có liên quan đến PC. Đọc dữ liệu cẩn thận. Xem xét tài nguyên 'chi phí' của bất cứ điều gì bạn đang cố gắng làm. Tìm hiểu các thủ thuật gỡ lỗi theo định hướng tài nguyên như lấp đầy không gian ngăn xếp với giá trị ma thuật để theo dõi việc sử dụng ngăn xếp.

Mặc dù một số mức độ kỹ năng sửa lỗi là cần thiết cho cả PC và phần mềm nhúng, nhưng nó quan trọng hơn nhiều với nhúng.

Tôi cho rằng trải nghiệm C ++ của bạn là dựa trên PC.

Một lỗi thường xảy ra bởi các lập trình viên chuyển từ PC sang vi điều khiển là họ không nhận ra tài nguyên có thể bị giới hạn như thế nào . Trên PC, không ai có thể ngăn bạn khi bạn tạo một bảng có 100 000 mục hoặc viết chương trình biên dịch thành 1MB mã máy.
Có những bộ vi điều khiển có rất nhiều tài nguyên bộ nhớ, đặc biệt là ở phân khúc cao cấp, nhưng nó vẫn khác xa so với những gì bạn sẽ sử dụng. Đối với một dự án sở thích, có lẽ bạn luôn có thể đạt được tối đa, nhưng trong một dự án chuyên nghiệp, bạn thường bị buộc phải làm việc với thiết bị nhỏ hơn vì nó rẻ hơn .
Trong một dự án tôi đã làm việc với TI MSP430F1101. Bộ nhớ chương trình 1KB, Flash cấu hình 128 byte, RAM 128 byte. Chương trình không phù hợp với 1K, vì vậy tôi đã phải viết hàm 23 byte trong cấu hình Flash. Với các bộ điều khiển nhỏ này, bạn tính theo byte . Trong một dịp khác, bộ nhớ chương trình là 4 byte quá nhỏ. Ông chủ sẽ không cho tôi sử dụng bộ điều khiển với nhiều bộ nhớ hơn, nhưng thay vào đó tôi phải tối ưu hóa mã máy đã được tối ưu hóa (nó đã được viết bằng trình biên dịch) để phù hợp với 4 byte bổ sung. Bạn có được hình ảnh.

Tùy thuộc vào nền tảng bạn đang làm việc, bạn sẽ phải đối phó với I / O ở mức rất thấp . Một số môi trường phát triển có chức năng ghi vào màn hình LCD, nhưng trên các môi trường khác bạn chỉ có một mình và sẽ phải đọc biểu dữ liệu của LCD từ đầu đến cuối để biết cách điều khiển nó.
Bạn có thể phải điều khiển rơle, điều đó dễ hơn LCD, nhưng nó sẽ yêu cầu bạn đi đến cấp độ đăng ký của vi điều khiển. Lại một bảng dữ liệu hoặc hướng dẫn sử dụng. Bạn sẽ phải làm quen với cấu trúc của vi điều khiển, mà bạn sẽ tìm thấy trong sơ đồ khối, một lần nữa trong biểu dữ liệu. Trong những ngày của bộ vi xử lý, chúng tôi đã nói về một mô hình lập trình, về cơ bản là một dòng các thanh ghi của bộ xử lý. Các bộ vi điều khiển ngày nay rất phức tạp đến nỗi một mô tả về tất cả các thanh ghi có thể chiếm phần tốt nhất trong bảng dữ liệu 100 trang. IIRC chỉ là mô tả của mô-đun đồng hồ cho MSP430 dài 25 trang.

$\mu$

Vi điều khiển thường được lập trình trong C . C ++ khá đói tài nguyên, vì vậy thường là hết. (Hầu hết các triển khai C ++ cho vi điều khiển đều cung cấp một tập hợp con C ++ giới hạn.) Như tôi đã nói, tùy thuộc vào nền tảng, bạn có thể có một thư viện chức năng mở rộng có thể giúp bạn tiết kiệm khá nhiều thời gian phát triển. Thật đáng để dành chút thời gian để nghiên cứu nó, nó có thể giúp bạn tiết kiệm rất nhiều thời gian sau này nếu bạn biết những gì có sẵn.

"lập trình phần cứng" có thể có nghĩa là rất nhiều thứ. Lập trình một con chip rất nhỏ (nghĩ 10F200, hướng dẫn 512, vài byte RAM) có thể gần giống như thiết kế một mạch điện tử. Mặt khác, lập trình vi điều khiển Cortex lớn (1 Mb FLASH, RAM 64 kB) có thể rất giống với lập trình PC / GUI, sử dụng bộ công cụ GUI lớn. IMHO một lập trình viên nhúng / thời gian thực tốt cần các kỹ năng cả từ phía phần mềm, ví dụ như từ phía thiết kế mạch. Đối với uC C ++ lớn hơn là một lựa chọn ngôn ngữ tốt, đối với những người rất nhỏ C có thể là lựa chọn duy nhất. Kiến thức lắp ráp có thể hữu ích, nhưng tôi không khuyên bạn nên thực hiện các dự án nghiêm túc hoàn toàn trong lắp ráp.

Tôi đã thực hiện công việc nhúng nghiêm túc với mọi người từ cả hai phía (SWI và EE). Tôi thường thích người SWI, miễn là họ có một số kinh nghiệm với lập trình đa luồng.

Câu hỏi của bạn có vẻ như bạn muốn đi sâu vào lập trình nhúng. Bằng mọi cách hãy làm như vậy. Đối với các khía cạnh cấp thấp (giao thoa các thiết bị ngoại vi trong chip của bạn và phần cứng xung quanh nó), bạn sẽ cần học một số kỹ năng mới, nhưng nó chỉ là rất nhiều công việc mà không có nhiều khái niệm mới. Đối với các lớp cao hơn của các dự án của bạn, bạn có thể vẽ trên knwoledge hiện tại của bạn.

Đối với mọi phương thức thư viện arduino mà bạn gọi, có rất nhiều mã C / C ++ có thể thực hiện được, nó chỉ đơn giản được đóng gói độc đáo để bạn sử dụng làm API. Hãy xem mã nguồn arduino trong phần cứng thư mục / arduino / * và bạn sẽ thấy tất cả C / C ++ được viết cho bạn, tương tác trực tiếp với các thanh ghi của vi điều khiển AVR. Nếu mục tiêu của bạn là học cách viết những thứ như thế này (trực tiếp cho phần cứng) thì có rất nhiều thứ để trang trải. Nếu mục tiêu của bạn là làm cho một cái gì đó hoạt động bằng thư viện của họ thì có lẽ không có gì nhiều để nói vì hầu hết công việc khó khăn được thực hiện cho bạn và thư viện và môi trường phát triển của họ rất dễ sử dụng.

Một số quy tắc mặc dù khi làm việc với các thiết bị bị hạn chế tài nguyên có thể áp dụng cho môi trường arduino hoặc các thiết bị khác:

Hãy nhận biết bao nhiêu bộ nhớ bạn đang sử dụng. Cả kích thước mã (đi vào bộ nhớ flash) và sử dụng RAM tĩnh (hằng số trong mã của bạn sẽ luôn tồn tại trong RAM). Tôi sẽ lập luận rằng việc sử dụng RAM tĩnh là quan trọng hơn một chút khi bắt đầu, vì nó dễ nhìn qua. Không có gì lạ khi bạn chỉ có 1000 byte để làm việc với stack, heap và hằng số của bạn. Hãy khôn ngoan trong cách bạn chi tiêu, vì vậy hãy tránh những thứ như mảng số nguyên dài (mỗi byte 4 byte) khi các byte hoặc ký tự không dấu (mỗi byte 1 byte) sẽ đủ. Một câu trả lời khác ở đây bao gồm một số điểm quan trọng khác rất tốt vì vậy tôi sẽ dừng lại ở đây, tôi chủ yếu muốn nhận ra rằng có rất nhiều điều cần phải giải quyết nếu bạn không sử dụng thư viện arduino và viết thư viện C của riêng bạn .

Về lập trình vi điều khiển và lập trình OOP, chúng không phải là một cái gì đó đối lập. Đúng là tất cả các thư viện của nhà cung cấp đều ở dạng C, nhưng tất cả các nền tảng cũng hỗ trợ C ++ OOP. Các nhà phát triển có thể xây dựng và xây dựng các thư viện cấp cao và phần mềm thiết bị C ++ trên đó. Ví dụ điển hình là các thư viện Arduino, được xây dựng chính thức và người dùng - chủ yếu là các lớp C ++. Có thể không phải tất cả các lợi thế OOP đều có thể được sử dụng đầy đủ trong môi trường nhúng, nhưng các lợi thế nổi tiếng của C ++ và C cũng có giá trị ở đây.

Về tư duy và suy nghĩ, như đã lưu ý trong các câu trả lời khác, vi điều khiển là các nền tảng bị hạn chế về tài nguyên (đặc biệt là RAM, ít về tốc độ) - những thứ như phân bổ bộ nhớ động, ngoại lệ C ++ thường bị loại trừ. Với phần cứng phù hợp được chọn, có thể dễ dàng chấp nhận những hạn chế này và sử dụng các kỹ thuật khác (cũng được sử dụng rộng rãi trong các nền tảng khác).

Theo quan điểm của tôi, thử thách khó hơn có thể là thêm một chiều nữa được tìm thấy trong lập trình nhúng - thời gian. Điều này là do phần mềm nhúng thường xử lý rất nhiều các sự kiện thời gian thực, các giao thức được định thời gian nghiêm ngặt để điều khiển phần cứng ngoại vi và nhiệm vụ chung (đây cũng là một số tương tự trong các nền tảng "cấp cao" khác, như các ứng dụng đa luồng).

Hãy chuẩn bị để đọc rất nhiều datasheets khi làm việc với phần cứng mới - Tôi đoán nó có thể liên quan đến phần câu hỏi "tư duy" :) Chắc chắn sẽ cần một số kiến ​​thức về EE và phần cứng.

Ngoài ra tôi muốn lưu ý rằng những ngày này phát triển phần mềm nhúng không yêu cầu ngôn ngữ lắp ráp. Trong thực tế Java (BTW, nó là OOP theo mặc định) đã ở đây và ngày càng mạnh hơn (ít nhất là đối với một số loại thiết bị nhúng, ví dụ như thiết bị IoT, nó có thể có tương lai rất tươi sáng).