Tôi đang tìm các ngôn ngữ lập trình thay thế (từ assembly, C, C++ và basic) tới chương trình được nhúng (vi điều khiển).Các ngôn ngữ thay thế cho lập trình được nhúng
Có thể, ví dụ, để lập trình bộ vi điều khiển trong C# hoặc Java? Có lẽ Ruby hay Python?
Nếu có thể, vui lòng đăng các công cụ phát triển và phần cứng được sử dụng.
Ngoài ra còn có Lua. Xem eLua.
+1. Lua được biết đến cụ thể là một ngôn ngữ cấp cao gọn nhẹ, có thể nhúng. Xem thêm: http://www.lua.org/about.html và http://www.eluaproject.net/en_overview.html –
Tôi hy vọng bạn không nghĩ rằng "có thể nhúng" trong ngữ cảnh đó có liên quan đến việc nhúng hệ thống. –
Nếu bạn đang lập trình vi điều khiển, bạn sẽ hầu như luôn luôn muốn C hoặc Embedded C++, bất cứ điều gì khác chỉ mất quá nhiều giá trị trên flash chip. Đó là hai ngôn ngữ duy nhất tôi muốn giới thiệu, nếu bạn không lắp ráp mọi thứ (và thực sự, ai làm những điều đó trong những ngày này?)
Tôi sử dụng Embedded C++ giống như mọi người khác, trên Arduino chẳng hạn, tôi cũng sử dụng C cho hầu hết các phần trên một bảng ARM tôi sử dụng.
Nếu bạn đếm JavaCard làm vi điều khiển, thì bạn có thể lập trình nó bằng Java.
Bạn có thể viết mã số C# dưới .NET. Bạn phải sử dụng .NET Micro Framework. Nhưng tôi sử dụng ngôn ngữ C cho nội dung này như mọi thứ. Tôi viết bằng C trên bộ xử lý ARM7Cortex-M3 với Keil Framework và điều này hoạt động tốt, khung công tác này hỗ trợ nhiều giao diện lập trình và bộ xử lý.
Lưu ý: Micro Framework là KHÔNG phải là một hệ điều hành thời gian thực (Matthew Whited từ comments)
OK, nhưng vi điều khiển đích nào thực hiện .NET vi Framework? – RHaguiuda
@RHaguiuda, nếu nó không nhắm mục tiêu một mà bạn muốn bạn luôn có thể biên dịch của riêng bạn với bộ chuyển đổi. –
Cảm ơn Matthew. Bạn có thể giải thích nhanh cách hoạt động của cổng không? Tôi có thể chuyển sang Microchip PIC chẳng hạn? – RHaguiuda
FORTH đã được phổ biến trong các hệ thống nhúng trong một thời gian dài. Tôi không có kinh nghiệm cụ thể với nó nhưng nó được thiết kế rất khéo léo để cung cấp rất nhiều chức năng trong một lượng nhỏ không gian ngay cả trên các bộ điều khiển vi xử lý khó, bằng cách sử dụng các phương thức giải thích mã luồng. Nó thậm chí còn khá nhanh cho những gì số tiền cho một thông dịch viên. Nó rất dễ dàng để có được môi trường phát triển cho FORTH, và nó là khá dễ dàng để chuyển nó vào hệ thống mới.
Mọi người yêu thích hoặc ghét nó, bởi vì nó khẳng định rằng bạn viết mã theo một ký pháp đánh bóng ngược (về cơ bản là một máy xếp chồng với một chồng lớn các toán tử được xác định trước).
Chủ đề SO này có vẻ liên quan: https://stackoverflow.com/questions/122292/forth-love-if-honk-then
Tôi đã từng sử dụng chương trình Zilog Z180 trong FORTH. Tôi sẽ không muốn làm điều đó nữa!
C# có thể được sử dụng trên .NET Micro, nhưng bạn sẽ cần một bộ xử lý 32 bit có ít nhất 256Kb RAM và không tốt cho các ứng dụng thời gian thực. Tuy nhiên, năng suất cao cho việc áp dụng đúng cách, và có thể sử dụng các lập trình viên mà không có chuyên môn nhúng rộng rãi nếu đó là nguồn cung ngắn và chuyên môn C# thì không.
Java là khả thi, đặc biệt là trên một phần với phần cứng bytecode thực hiện như đơn vị Jazelle trên một số ARM9 và các thiết bị ARM cao cấp hơn. Tuy nhiên nó vẫn cần một cổng JVM và có thể tốn kém. Nó thường được sử dụng như một phần của một cổng Linux nhúng, vì vậy bạn có tất cả những chi phí trên, vì vậy có lẽ thậm chí còn nhiều tài nguyên đói hơn .NET Micro.
Intel sử dụng để tạo ra một ngôn ngữ rất đơn giản gọi là PL/M (ngôn ngữ lập trình cho máy vi tính) cho bộ xử lý Intel khác nhau từ 4004 đến 803.286 nhưng nó không còn có sẵn hoặc được hỗ trợ, và không có lợi ích hơn C.
Ada được sử dụng rộng rãi, đặc biệt là trong các ứng dụng quan trọng về quân sự, hàng không và an toàn.
Embedded Pascal khả dụng cho một số mục tiêu.
Bạn có thể sử dụng NI LabView làm trình tạo mã cho các hệ thống nhúng. Trong thực tế đó là những gì Lego Mindstorms được dựa trên. Phiên bản công nghiệp có phần phức tạp hơn và đầy đủ tính năng hơn so với phiên bản đồ chơi tuy nhiên! Tương tự, bạn có thể tạo mã nhúng bằng MATLAB và SimuLink. Đây không nhất thiết là hiệu quả nhất, nhưng nhiều hơn nghĩ như điều khiển động cơ chính xác và xử lý tín hiệu, SimuLink có thể đạt hiệu quả cao.
:) Tôi phải già vì bộ xử lý 32 bit w/256KB của ram, không cảm thấy như uController. – kenny
@kenny: Một thiết bị thường được coi là vi điều khiển nếu thiết bị có bộ xử lý lõi * và * trên chip và bộ nhớ. Tăng mật độ Flash và SRAM cho phép các tài nguyên bộ nhớ đáng kể được đưa vào một khuôn đơn. – Clifford
Đầu tiên, asm và C là các lựa chọn chính và vì lý do chính đáng. Bắt đầu ở đó và xây dựng một nền tảng để rơi trở lại.
Chúng tôi nhận thấy thiết bị đọc sách, được điều khiển thứ tư hoặc ít nhất có một số thành phần. Một ngôn ngữ tôi chưa bao giờ học được nhưng có thể một ngày nào đó.
Bảng TINI bán dẫn Dallas (dallas semi đã được đồng hóa bởi maxim) là mục đích được xây dựng để trở thành bảng JAVA được nhúng. Kết quả là họ đã phải đưa tấn ram và flash trên nó liên quan đến một vi điều khiển bình thường/hội đồng quản trị. Tôi nghĩ những bảng đó vẫn còn ở ngoài kia.
Vào thời điểm TINI xuất hiện, đối số ở đó có thể nhúng java. Có lẽ nó có thể. Sự hiểu biết của tôi là Python tương tự như java theo nghĩa là nó được diễn dịch hoặc biên dịch xuống một mã byte hoặc mã máy chung. Trong trường hợp của JAVA, jvm là bộ giả lập của ngôn ngữ máy phổ biến đó cho một mục tiêu cụ thể. Nếu đó là trường hợp với python thì trong lý thuyết python có thể được nhúng như java. Tôi được cho biết rằng ra là chồng dựa trên hoặc ngăn xếp như đó là những gì java là, do đó cũng sẽ ngụ ý rằng ra có thể làm việc nhúng cũng java có thể. Vì vậy, miễn là bạn có đủ ram cho ngăn xếp và không gian chương trình đủ và băng thông cho vm/giả lập. Và đó chính là vấn đề. Và đó chính là vấn đề. ram và rom là đắt tiền, giá cả chi phối và người tiêu dùng quyền lực của một phần. Ai muốn trả $ 10 cho một cái gì đó để nó có thể sử dụng java khi họ có thể nhận được nhiều hơn từ một phần $ 1 bằng cách sử dụng C/asm? Ít nhất đó là những gì thị trường sẽ nói với bạn.
Mặt khác, có khái niệm rằng linux có thể được nhúng và mọi người đang sử dụng nó theo cách đó. Điều đó có nghĩa là mega hoặc gigabyte, nơi kilobyte sẽ thực hiện công việc nhanh hơn, tốt hơn và đáng tin cậy hơn (mặc dù được cho là có chi phí phát triển cao hơn trước). Vì vậy, một số ARM và mips được nhúng mới hơn sẽ có các tài nguyên mà bạn đang tìm kiếm.
Sự hiểu biết của tôi là gcc và có lẽ cuối cùng nếu chưa có llvm có thể có java và các giao diện người dùng khác (ví dụ như ada, có thể là pascal). có nghĩa là bạn có thể viết trong java ví dụ nhưng có nó biên dịch xuống mã máy cho bộ xử lý đích và không phải là mã byte java chung hay bất cứ thứ gì nó được gọi. Đó sẽ là tình huống lý tưởng của bạn để nhận được từ ngôn ngữ scripty để hướng dẫn thực sự máy (giả sử bạn tiếp tục theo đuổi một cái gì đó khác hơn là C/asm).
Câu trả lời ngắn: Có thể? Có thể. Dallas TINI là hoặc là một ví dụ cụ thể sử dụng java. Nhìn vào wikireader là tốt, sử dụng những gì dường như được ra.
Nếu bạn có thể phát triển sản phẩm nhanh hơn hoặc ít lỗi hơn thì việc tiết kiệm chi phí sử dụng C có thể không quan trọng. Nếu sản phẩm phần lớn là phần mềm, thì thời gian bạn tiết kiệm có thể đáng giá. –
Quyết định được thúc đẩy bởi khối lượng sản phẩm và kinh tế gây ra. Nếu bạn sẽ bán một triệu thiết bị, $ 1 với chi phí bổ sung để hỗ trợ nhiều RAM/ROM hơn, chỉ để các lập trình viên có thể sử dụng Java hoặc bất cứ thứ gì, sẽ tốn thêm một triệu đô la trong sản xuất và tăng giá sản phẩm khoảng 3 - 4 đô la. Với kinh tế như vậy dễ dàng để xem lý do tại sao một trang phục kỹ thuật sẽ trả một lập trình $ 100K để mã trong một cái gì đó icky như assembler thay vì chi tiêu thêm buck cho mỗi đơn vị. –
Bạn có thể thử python-on-a-chip, được hỗ trợ trên nền tảng mbed hoặc STM32, di động sang các nền tảng khác.
Giống như hầu hết mọi thứ trong thế giới được nhúng, các tùy chọn của bạn phụ thuộc vào các ràng buộc của bạn. Bạn đã cam kết với một nền tảng chưa? Bạn có bao nhiêu không gian mã/RAM? Chip của bạn có thể hỗ trợ hệ điều hành không?
Tôi đã sử dụng thông dịch viên máy tính tùy chỉnh trên các máy nhỏ hơn để tiết kiệm không gian mã.
Hầu hết các hệ thống nhúng có một số phần có thể có hiệu suất cao và rất nhiều nội dung chạy hiếm khi hoặc hiệu suất nào không quan trọng.
Tôi đã triển khai một số ứng dụng trong đó công cụ nhanh lõi cứng được viết trong trình biên dịch (vì đó là tất cả những gì tôi có thể làm như một công cụ phát triển), và sau đó mã hóa một thông dịch viên cho bộ lệnh riêng của tôi định hướng máy xếp chồng. Khá nhiều tất cả những gì bạn cần để bắt đầu là các opcodes cho toán hạng PUSH/POP (8 hoặc 16 byte), ADD/SUB/MUL/DIV, CMP, IF/GOTO và cuộc gọi, và chúng dễ dàng được mã hóa ngay cả trong bộ chỉ dẫn xấu. Sau đó, bạn cố gắng viết các chương trình con bằng cách sử dụng CALL và chỉ thêm các mã opcode để thực hiện những điều mà pcode không thể thực hiện được (thiết bị I/O), hoặc yêu cầu một số tính toán nhanh hơn.
Mã hóa trong trình thông dịch pcode như vậy là khá dễ dàng ngay cả với trình biên dịch; bạn chỉ cần viết "BYTE" chỉ thị lắp ráp xen kẽ với chỉ thị "WORD" tùy thuộc vào những gì opcode muốn.
Câu trả lời này về cơ bản là biến thể của người nghèo về câu trả lời FORTH mà tôi đã đưa ra trước đó.
Có một số thiết bị nhỏ thể chất chạy phiên bản đầy đủ hoặc ít hơn của Linux. Bạn có thể lập trình chúng bằng nhiều ngôn ngữ lập trình chạy trên Linux, tức là, thực tế là bất kỳ ngôn ngữ lập trình nào được biết đến cho nhân loại.
Đối với bộ vi điều khiển có lượng RAM nhỏ, quá nhỏ để chạy Linux, hãy xem StackOverflow: "What are the available interactive languages that run in tiny memory?".
FORTH có đức tính trên các máy nhỏ, nhưng có một chút đường cong học tập.
FORTH có nhiều mặt, bất kỳ hoặc tất cả đều có thể được sử dụng để phát triển nhúng.
Một phần của cuộc đấu tranh với FORTH là đối phó với sự phân đôi được trình bày.
Trên trang web có, các FORTH nhỏ, thô tục, bạn cũ Z-80 FigForth phiên dịch luồng, là rất thấp về môi trường mà họ cung cấp cho bạn, nhà phát triển. Họ chắc chắn là cao hơn so với lắp ráp, nhưng, được cho là, (trong một số trường hợp) hơn C.
Ví dụ, ra khỏi hộp, FORTH (những đứa trẻ lớn tuổi hơn nhiều người nghĩ về CPU nhỏ) không cho phép bạn phân bổ bộ nhớ động hoặc làm số học con trỏ (dễ). Nó thậm chí không có "cấu trúc" như một khái niệm ngôn ngữ. Về cơ bản bạn có thể chơi với các offset thông qua các hằng số. Ban đầu, bạn thậm chí không thể làm đệ quy. Có thể cho rằng, hạn chế lớn nhất là nó không có loại dữ liệu thực. Nó không được gõ ở tất cả, đó là tất cả các con số mà có thể hoặc có thể không được con trỏ đến bộ nhớ có thể hoặc có thể không phải là dữ liệu hoặc ký tự hoặc bất cứ điều gì.
Tất nhiên, đồng thời, bạn có thể có được toàn bộ hệ thống, với một trình biên tập và trình soạn thảo, v.v. tất cả trong phạm vi 8K RAM.
Vì vậy, theo cách đó, đó là, vâng, mức cao hơn so với lắp ráp, nhưng thấp hơn so với C.
Nhưng (và đó là một lớn Nhưng) ...
Trong khi nó có thể bắt đầu ở mức độ thấp, bạn, với tư cách là lập trình viên, có thể nâng nó lên bất kỳ mức độ trừu tượng nào mà bạn hài lòng - bạn có thể lấy nó khá nhiều như bạn muốn.
Bạn muốn cấu trúc? Bạn muốn một đống để malloc từ? Bạn muốn có một hệ thống đối tượng? Đó là tất cả có sẵn cho các tòa nhà trên nền tảng.
Bạn muốn hỗ trợ lớp học đầu tiên, ở cấp độ ngôn ngữ, cho hệ thống bản ghi dựa trên ISAM nhỏ của bạn? Dễ dàng.
Cân nhắc chung Lisp. Hai trong số các tính năng mạnh mẽ nhất của nó là Macros và Reader, cho phép bạn chuyển đổi văn bản tùy ý thành mã sau đó được biên dịch.
FORTH có cùng khả năng, chỉ có thể đi xa hơn. Trong các FORTH cũ hơn, bạn thậm chí có quyền truy cập vào trình biên dịch, không chỉ là đầu vào cho trình biên dịch. Trình thông dịch có luồng khá đơn giản và dễ sửa đổi. Bạn có quyền truy cập "thô" vào hình ảnh bộ nhớ, bạn thực sự có thể làm bất cứ điều gì bạn muốn - tất cả đều từ chính hệ thống FORTH.
Đây là cách FORTH có thể "tự chuyển" các kiến trúc khác một cách dễ dàng, cách chúng có thể tối ưu hóa cấu trúc dữ liệu cụ thể. Nhiều FORTH cũ hơn là Thông dịch viên được tạo luồng, nhưng không có lý do gì họ phải làm. Bạn có thể biên dịch FORTH thành mã máy thuần túy (ví dụ: không có thông dịch viên) nếu bạn muốn.
Tất nhiên, trên bộ điều khiển "vi mô" hiện đại, bạn có thể dễ dàng chuyển toàn bộ môi trường dev sang thiết bị. Không bao giờ sao chép một hình ảnh trên dây một lần nữa (cho đến khi bạn trở lại nó lên tất nhiên).
Tất cả điều này đều có tác dụng, tất nhiên. Có lẽ quá nhiều công việc, đó là tùy thuộc vào nhà thiết kế/lập trình viên để quyết định. Đó là một bộ công cụ nguyên thủy có thể được sử dụng để tạo ra những thứ rất mạnh mẽ.
Tôi nghĩ rằng có (ít nhất) hai câu trả lời cho câu hỏi này. Đầu tiên tôi muốn nhấn mạnh rằng nếu bạn đang lập trình gần phần cứng và với tài nguyên hạn chế, bạn sẽ thấy rằng C hoặc C++ là công cụ sẽ giúp bạn tốt nhất. Các ngôn ngữ cấp cao không làm cho việc thao tác ở cấp độ bit trở nên dễ dàng, nhưng những thứ này dễ thực hiện trong C. Một phần của giải pháp là tìm ra công cụ nào là tốt nhất cho công việc và cho các công cụ cấp thấp Python hoặc Ruby không phải là thứ bạn muốn.
Mặt khác nếu những gì bạn muốn làm chỉ đơn giản là viết một ứng dụng chạy trên bộ điều khiển vi mô, thì bạn có thể có một số tùy chọn tùy thuộc vào mục tiêu bạn đang làm việc. Nhiều cái gọi là nền tảng nhúng mạnh hơn rất nhiều so với chỉ một vài máy trạm cũ và do đó chạy cổ phiếu Linux mang lại cho bạn một số lượng lớn các tùy chọn ngôn ngữ.
Đối với Python, trước đây từng là một dự án thú vị: Deeply Embedded Python, nhưng tôi nghĩ nó đã chết trong một thời gian.
Bạn có thể xem qua AvrCo Multitasking Pascal rất mạnh mẽ dành cho AVR. Bạn có thể thử tại http://www.e-lab.de. Phiên bản MEGA8/88 hoàn toàn miễn phí. Có rất nhiều trình điều khiển và giả lập với trình gỡ lỗi JTAG và hình ảnh trực quan hoặc mô phỏng tốt đẹp của tất cả các thiết bị tiêu chuẩn (LCD, 7SEG, 14SEG, LEDDOT, KEYBOARD, RC5, SERVO, STEPPER ...).
Đối với PIC có JAL, nó đi kèm với một số thư viện đẹp.
Từ một kickstarter, Micro Python tại là ra ngoài và được thiết kế cho các thiết bị nhúng http://micropython.org/ https://mail.python.org/pipermail/python-list/2014-June/672994.html
"Hỗ trợ gần như đầy đủ Python 3 cú pháp, trong đó có năng suất (biên dịch 99,99% của thư viện Python 3 tiêu chuẩn)."
Một vài tháng trước đã bắt đầu dự án RubimC - Trình biên dịch Ruby và khung công tác cho vi điều khiển với bộ nhớ nhỏ. Phiên bản hiện tại đang hoạt động nhưng nhận ra không phải tất cả các tính năng của Ruby.
Hầu hết các ngôn ngữ "hiện đại" như C#, Java, Ruby, Python * yêu cầu * bộ sưu tập rác trong quá trình triển khai. Điều đó rất khó thực hiện trong một bộ vi xử lý nhỏ và có tác động xấu đến hiệu năng thời gian thực. Các chàng trai Java đã định nghĩa Java "RealTime", nhưng nó không phải là rất phổ biến và bạn vẫn cần một thời gian chạy khá lớn để thực thi nó, vì nó có * cả bộ sưu tập rác và phân bổ lưu trữ xác định. Bạn có thể sử dụng các ngôn ngữ này trong "hệ thống nhúng" dựa trên x86 và có số lượng RAM lớn. Nhưng nếu không C, C++ và FORTH thích hợp hơn. –
Tại sao bạn quan tâm, tò mò? Lập trình nhúng gần như luôn luôn rất gần với máy, cho thấy rằng một ngôn ngữ cấp thấp như C hoặc C++ sẽ phù hợp. Python là một ngôn ngữ rất tốt, nhưng yêu cầu hỗ trợ thời gian chạy nhiều hơn và cố tình tránh xa silicon. –
Chỉ cần thêm một số thông tin về Python: Bộ sưu tập rác có thể được kiểm soát rõ ràng, việc đếm tham chiếu được sử dụng cho hầu hết các trường hợp trong quá trình thực hiện tham chiếu và có một triển khai thay thế nhỏ tại đây: http://www.tinypy.org/ Lua là tốt. –