Là lập trình nhúng gần hơn với kỹ thuật điện hoặc phát triển phần mềm? [đóng cửa]

Tôi đang được tiếp cận với một công việc để viết C nhúng trên bộ điều khiển vi mô. Lúc đầu, tôi có thể nghĩ rằng việc nhúng lập trình quá thấp đối với chồng phần mềm đối với tôi, nhưng có lẽ tôi đang nghĩ về nó sai.

Thông thường tôi sẽ bỏ qua một cơ hội để viết mã nhúng, vì tôi không coi mình là một kỹ sư điện. Đây có phải là một giả định xấu? Tôi có thể viết phần mềm thú vị và hữu ích cho các hệ thống nhúng hay tôi sẽ tự đá mình vì đã giảm quá thấp trên ngăn xếp phần mềm?

Tôi đã đi học về khoa học máy tính và thực sự thích viết một trình biên dịch, suy nghĩ về các thuật toán đồng thời, thiết kế cấu trúc dữ liệu và phát triển các khung công tác. Tuy nhiên, tôi hiện đang làm nhân viên phát triển web, không hét lên những điều thú vị mà tôi vừa mô tả. (Tôi hiện đang xử lý các vấn đề như: "hộp kiểm này cần có 4 pixel ở bên trái" và "ngày này được định dạng sai".)

Tôi đánh giá cao đầu vào của mọi người. Tôi biết tôi phải đưa ra quyết định cho chính mình, tôi chỉ muốn làm rõ một chút về ý nghĩa của một lập trình viên nhúng, và nếu nó phù hợp với những gì tôi thấy là thú vị.

Nếu bạn muốn giỏi làm việc trên các hệ thống nhúng, thì có, bạn cần phải suy nghĩ như một EE trong một thời gian. Đó là nói chung khi bạn đang viết mã để giao tiếp với các thiết bị ngoại vi khác nhau (các bus nối tiếp như UART, SPI, I2C hoặc USB), bộ định thời 8 và 16 bit, bộ tạo xung nhịp, và ADC và DAC. "Datasheets" cho các bộ vi điều khiển thường chạy vào hàng trăm trang khi chúng mô tả từng bit của mỗi đăng ký. Nó giúp có thể đọc sơ đồ để bạn có thể thăm dò một bảng với máy hiện sóng hoặc máy phân tích logic.

Lúc khác, nó chỉ là viết phần mềm. Nhưng trong những ràng buộc chặt chẽ: thường thì bạn sẽ không có HĐH chính thức hoặc khung khác và bạn có thể chỉ có một vài KB RAM và có thể là 64 KB bộ nhớ chương trình. (Các giới hạn này giả định rằng bạn đang lập trình trên micros 8 hoặc 16 bit nhỏ hơn; nếu bạn đang làm việc với Linux nhúng trên bộ xử lý 32 bit, bạn sẽ không gặp phải các ràng buộc bộ nhớ tương tự nhưng bạn vẫn sẽ phải xử lý mọi tùy chỉnh phần cứng ngoại vi mà bản phân phối Linux của bạn không cung cấp trình điều khiển cho.)

Tôi có một nền tảng trong cả EE và CS vì vậy tôi thích cả hai mặt của đồng tiền. Tôi cũng làm một số chương trình web (chủ yếu là PHP) và ứng dụng máy tính để bàn (C # và Delphi), nhưng tôi luôn thích làm việc với các dự án nhúng nhất.

Câu trả lời của @ tcrosley là tuyệt vời. Bạn không cần phải là một kỹ sư điện, nhưng biết những điều cơ bản sẽ giúp.

Tôi không nghĩ bạn cần phải sợ "quá thấp trong chồng phần mềm". Tôi đã phải giải quyết nhiều vấn đề rất thú vị khi là một kỹ sư nhúng. Bạn đề cập đến một danh sách các nhiệm vụ bạn thích:

• Các thuật toán đồng thời - Xử lý các ngắt cấp phần cứng không đồng bộ có nhiều thách thức thú vị như sử dụng mô hình luồng hệ điều hành.

• Thiết kế cấu trúc dữ liệu - Kiểm tra. Thiết kế cho sự nhỏ gọn và truy cập hiệu quả.

• Phát triển khung - Kiểm tra. Trên các hệ thống xương trần, cuối cùng bạn có thể thiết kế một hệ điều hành mini.

• Viết một trình biên dịch - có thể không, nhưng cuối cùng bạn có thể thực hiện tối ưu hóa mã mức thấp tương tự như bước tạo lắp ráp của trình biên dịch.

Tôi sẽ chọn làm việc trên các hệ thống nhúng qua mã hóa UI bất kỳ ngày nào. Bạn sẽ không bao giờ quên lần đầu tiên bạn xem một chiếc máy bắt đầu di chuyển theo cách bạn đã lập trình. Đó là cách thỏa mãn hơn là đẩy pixel.

Là một lập trình viên nhúng, công việc của tôi là làm cho phần cứng tùy chỉnh hoạt động. Thông thường, tôi đã phát triển một loạt phần mềm trên bảng dev hoặc phiên bản phần cứng trước đó. Khi hội đồng quản trị mới vào, công việc của tôi là đưa phần mềm của tôi lên bảng và chứng minh rằng mọi thứ đều hoạt động.

Bởi vì hầu như luôn luôn có một vấn đề nào đó, kỹ năng sửa lỗi là rất cần thiết. Nếu thiết bị ngoại vi bên ngoài không hoạt động, đó có phải là chip xấu, kết nối kém với chip, mã lỗi hoặc sử dụng sai thiết bị ngoại vi trên chip không? Cách duy nhất để nói là với gỡ lỗi rộng rãi. Điều này có nghĩa là thoải mái với máy hiện sóng, máy phân tích mạng, máy phân tích logic và trình gỡ lỗi mục tiêu. Quá trình gỡ lỗi trở nên gần như khoa học. Tôi phát triển một giả thuyết, thiết kế một thí nghiệm để cung cấp bằng chứng cho hoặc chống lại giả thuyết của tôi và thử nghiệm.

Khi đánh giá thực tập sinh hoặc kỹ sư nhúng mới, kỹ năng này là quan trọng nhất. Tất cả các phần mềm đều có vấn đề, nhưng một khi bạn bắt đầu giao tiếp với thế giới vật lý, sự đa dạng của những vấn đề đó tăng theo cấp số nhân. Bản chất công việc của tôi là giải quyết một loạt vấn đề dài giữa khái niệm và thực tế.

Theo kinh nghiệm của tôi, người ta có được kết quả tốt hơn khi tiếp cận phát triển phần mềm hệ thống nhúng với mũ "nhà phát triển phần mềm" thay vì mũ "kỹ sư điện tử". (thực hành như TDD & CI ít phổ biến hơn trong kỹ thuật phần cứng)

Mặt khác, tôi nghĩ rằng kinh nghiệm phát triển cho một hệ thống nhúng làm cho một hệ thống tốt hơn; nhà phát triển phần mềm hoàn thiện hơn.

Tôi đã ở trong một tình huống tương tự khoảng 8 năm trước. Tôi đã có 7 năm phát triển phần mềm trong môi trường ứng dụng và máy chủ. Kinh nghiệm duy nhất của tôi đối phó với mức độ thấp với phần cứng trước đây đã được viết bằng trình biên dịch Z80 khi còn là một thiếu niên trên phổ ZX.

Đó chắc chắn là một thử thách. Tôi thấy việc đối phó với các bộ chip trong trình biên dịch chương trình rất thú vị và tôi chắc chắn đã học được rất nhiều về phần cứng. Một phần đáng kể trong vai trò của tôi là kiểm tra phần cứng bằng phần mềm, vì vậy học cách đối phó với lập trình và nhận ra rằng lỗi phần mềm của bạn thực sự là một lỗi phần cứng. Trên thực tế đôi khi có thể mất khá nhiều công sức của người phần mềm và phần cứng để xác định xem lỗi có phải là phần cứng hay phần mềm hay không.

Một khía cạnh mà tôi không thể cung cấp trên là trình điều khiển thiết bị làm việc. Tôi chưa bao giờ thực sự nắm bắt được điều này, đó là một điều mà bản thân tôi và giám đốc công ty không bao giờ hiểu tại sao. Nó chỉ trở thành một thực tế được chấp nhận.

Làm quen với máy soi và ion hàn sẽ rất cần thiết. nhớ rằng khi một anh chàng phần cứng nói số 26 anh ta LUÔN có nghĩa là 0x26 là hữu ích. Nhận ra rằng các kỹ sư phần cứng thấy việc xử lý phần mềm rất khó chịu, nhưng sau đó, một dự án phần cứng không liên quan đến phần mềm được gọi là cáp.

Tôi giữ vai trò đó trong 4 năm và chỉ rời đi vì tôi đã bị săn trộm vì một cơ hội thực sự tuyệt vời.

Giống như mọi thứ, nó đòi hỏi một cách tiếp cận cân bằng. Tôi thích làm việc với các hệ thống nhúng trong công việc hàng ngày của tôi. Họ làm cho tôi tốt hơn về kỹ thuật điện. Máy tính vật lý và tự động hóa rất thú vị. Mặt khác, xây dựng các ứng dụng web và mày mò với điện toán đám mây là tuyệt vời.

Nếu bạn làm đúng, phía phần mềm của bạn sẽ tìm cách để làm mọi thứ thông minh hơn và tốt hơn. Phần cứng của bạn sẽ giúp bạn chú ý đến tài nguyên và siêu hiệu quả.

Tôi không phải là Kỹ sư Điện, nhưng tôi đã thực hiện một số lượng nhỏ phát triển phần mềm nhúng. Vấn đề lớn nhất mà tôi tìm thấy là tôi có một nền tảng cơ bản hơn về toán học, và vì vậy tôi không biết làm thế nào để dễ dàng chia một loạt các thuật toán toán học tiên tiến thành mã mà không cần nhiều sự trợ giúp.

Đối với tất cả những thứ mà tôi cần để chơi với tín hiệu, đọc các giá trị từ đầu vào, gửi dữ liệu đến đầu ra và tất cả những thứ đó, tôi thấy nó khác biệt một chút về mặt khái niệm với những gì tôi làm hàng ngày Nhà phát triển phần mềm lỗi thời. Viết phần mềm thực sự là những gì nó là. Đó là khi bạn cần vượt ra ngoài phần mềm thực tế mà tôi thấy mọi thứ trở nên tồi tệ bởi vì tôi không có kiến ​​thức để làm hỏng trực tiếp với phần cứng. Điều này thường xảy ra khi cố gắng gỡ lỗi hoặc kiểm tra mã. Nếu bạn có một chuỗi công cụ thực sự tuyệt vời, bạn có thể đã tích hợp môi trường gỡ lỗi và mô phỏng để loại bỏ hầu hết nỗi đau, nhưng ngay cả với tất cả những điều đó để giúp bạn, đôi khi bạn cần quay lại cơ bản và kiểm tra mã của mình một số loại máy phân tích và thực tế là hầu hết các nền tảng nhúng không '

Từ quan điểm này, tôi không nghĩ rằng trở thành một kỹ sư điện là điều cần thiết cho lập trình nhúng nếu các tác vụ đơn giản và các yêu cầu cụ thể về phần cứng thực tế là tối thiểu. Ngoài ra, tôi nghĩ việc trở thành một EE sẽ giúp cuộc sống dễ dàng hơn nhiều khi làm việc trong môi trường nhúng, đặc biệt là khi khoa học thực sự được yêu cầu để tìm ra vấn đề ở đâu.

Tôi chưa thực hiện bất kỳ chương trình nhúng cấp độ kinh doanh nào, nhưng Cử nhân của tôi chủ yếu là về các hệ thống nhúng, từ đó tôi có một vài năm kinh nghiệm thực tế. Chúng tôi đã sử dụng C trên Atmel AVR và chạm vào một số chip Texas Cụ với VHDL và có một số nội dung lý thuyết về ARM.

Trong những gì chúng tôi có, đó là khoảng 50-60 phần trăm lập trình (C), lập kế hoạch / thiết kế 20 phần trăm (UML) và phần còn lại là điện tử vật lý (hàn, đo, nối dây, làm dây cáp, v.v.). Tôi cũng đồng ý rằng nó rất thú vị và thú vị để làm, và tôi thực sự ước mình cũng sẽ có một sự nghiệp trong các hệ thống nhúng. Than ôi, với một thị trường rất nhỏ trong các hệ thống nhúng, tôi đã phải dùng đến Java EE cũ.

Nhưng tôi lạc đề; Tôi muốn nói rằng tỷ lệ phần trăm được đề cập ở trên khá gần với công việc trong thế giới thực, vì giáo viên của chúng tôi có doanh nghiệp riêng của họ, và cũng đề cập rằng họ sẽ cố gắng làm cho nó thực tế nhất có thể. Chúng tôi thậm chí đã có những bước ngoặt 180 độ ngẫu nhiên trong yêu cầu giữa dự án, heh heh.

Đối với ngăn xếp. Biết lập trình nhúng sẽ mang đến cho bạn cơ hội lớn để tạo ra các sản phẩm phần cứng rất thật của riêng bạn mà bạn có thể sản xuất tại các nhà máy thực ở Châu Á, sau đó lắp ráp chúng tại cơ sở của bạn (có thể ở nhà hoặc tại công ty của bạn). Nó rất thú vị! Bạn cũng có thể tạo ra nhiều tiện ích hữu ích ở nhà, chẳng hạn như vỏ điều khiển chuyển động, bộ hẹn giờ cho máy pha cà phê để tự động chuẩn bị đồ pha chế buổi sáng của bạn, v.v. Công cụ thú vị thực sự!