2010-04-16 33 views
5

Tôi đang viết các ứng dụng nhúng cho các phần cứng khác nhau (avr, arm7, tms55xx ...) và các rtoses khác nhau (freeRTOS, rtx, dsp/bios). Và mỗi giây trong số họ cần giao tiếp với PC hoặc một thiết bị kỹ thuật số khác. Đôi khi tương tác logic rất tiên tiến. Vì vậy, tôi rất thú vị trong phương pháp phổ biến (như kiểu lập trình nhà nước), đặc tả giao thức hoặc thư viện, có thể đơn giản hóa việc phát triển những thứ như vậy.Có bất kỳ tương tự nhẹ nào với CORBA/RPC cho các chương trình nhúng không?

Trả lời

6

Tôi đã rất hài lòng với google protocol buffers trên các hệ thống nhúng cho cả cơ chế truyền dữ liệu và RPC. Chúng nhẹ hơn một chút so với các hệ thống dựa trên XML vì dữ liệu được truyền đi được mã hóa nhị phân và giải mã dữ liệu được gửi yêu cầu xử lý tối thiểu, đó là một lợi thế lớn về việc sử dụng CPU ở bên được nhúng của liên kết.

Có sẵn các thư viện có sẵn cho các ngôn ngữ khác nhau nhưng quan trọng nhất là C đối với các ứng dụng được nhúng.

+0

Bạn có thể giới thiệu bất kỳ triển khai cụ thể nào cho nhúng C không? –

+0

http://code.google.com/p/protobuf-c/ – Mark

1

Here là một bài viết trên Embedded.com về CORBA trên các hệ thống nhúng và triển khai 'nhẹ' hoặc tối thiểu. Các giải pháp thương mại được đề cập là dành cho QNX, VxWorks và LynxOS. Và another article trên RPC trên Embedded.com (tác phẩm này do một giảng viên TI DSP biên soạn và tham khảo cụ thể DSP, vì vậy có thể liên quan đến DSP/BIOS).

Tôi đặc biệt khuyên bạn nên sử dụng tìm kiếm bài viết của Embedded.com, có thể có nhiều bài viết tương tự mà bạn sẽ thấy hữu ích.

VxWorks supports RPC, cũng như QNX Neutrino.

"Cuộn của riêng bạn" luôn là giải pháp của tôi, nơi tuân thủ tiêu chuẩn và khả năng tương thích giữa các hệ thống không phải là vấn đề (tức là hệ thống của tôi đang nói chuyện với hệ thống của tôi). Chỉ thực hiện chính xác những gì bạn cần là cách tốt nhất để đạt được 'trọng lượng nhẹ' có lẽ là do chi phí linh hoạt và bảo trì.

+0

Tôi đã đọc những bài viết này. CORBA dành cho các tương tác nâng cao hơn nhiều so với các chương trình của tôi. Giao thức RPC từ công cụ codec của TI đủ nhẹ, nhưng rất cụ thể và không phù hợp với các ứng dụng của tôi. – Mtr

0

Các giao thức là sự phù hợp tự nhiên cho các máy trạng thái, vì vậy có lẽ bạn có thể sử dụng các khung máy trạng thái QP nguồn mở rất nhẹ (state-machine.com). Sẵn sàng để sử dụng các cổng QP và các ví dụ cho các trình biên dịch khác nhau có sẵn cho AVR, MSP430, ARM7/ARM9, TMS320C28x, PSoC, HC08, M16C/R8C, H8, 8051, PIC18, PIC24/dsPIC, ARM Cortex-M3/M0 và nhiều khác.

Lưu ý: Tôi làm việc cho http://state-machine.com

+0

Không hoàn toàn là spam. Tuy nhiên, Miro, chúng tôi không sử dụng chữ ký trên SO. Tôi đã chỉnh sửa câu trả lời của bạn để hiển thị một cách để có được cùng một thông tin trên. Tôi cũng sẽ downvote câu trả lời bởi vì tôi không nghĩ rằng nó trực tiếp giải quyết các câu hỏi. –

+0

Có, đó là ý định của tôi để chỉ ra rằng tôi làm việc cho state-machine.com. –

2

OpenJAUS.

Đó là phản chiếu, có thể tổng hợp và được chuẩn hóa (ish) Hoạt động xuyên suốt nhiều ngôn ngữ.

Cung cấp nhiều khung hơn so với Bộ đệm giao thức (là ngăn xếp nhắn tin gọn gàng) Nó tập trung vào rô-bốt, nhưng hoạt động cho các hệ thống điều khiển.

Về mặt lý thuyết, giao diện người dùng JAUS có thể vận hành bất kỳ thiết bị tuân thủ JAUS nào và các hệ thống JAUS được dự định để tạo thành hệ thống syste.

Nếu những điều đó không có ý nghĩa thì vui lòng bỏ qua đề xuất này.

Các vấn đề liên quan