Blog cộng đồng về Công nghệ thông tin

Đối với RTOS thì performance lại càng là vấn đề quan trọng vì yêu cầu đến phải được đáp ứng xử lý ngay lập tức. Trong quy trình phát triển phần mềm nhúng, ngoài việc hoạt động đúng chức năng (vượt qua pha testing) còn phải vượt qua pha đánh giá hiệu năng (performance evaluation). Có lẽ ng sử dụng ko thích thú gì khi sử dụng một sản phẩm mà để thực hiện một chức năng nào đó lại phải chờ trong một khoảng thời gian (dù chỉ 1 -> 2s) cả đúng ko nào ...

Hơn nữa, chip càng yếu, dùng càng ít bộ nhớ thì sản phẩm càng rẻ, càng dễ dàng đến tay ng tiêu dùng.

Còn nếu lập trình trên PC thì những vấn đề nói trên có lẽ hơi thừa chăng? Một số compiler (vd. Borland products) bản thân nó cũng có chức năng optimize cho VXL Intel nhưng nhiều khi sự thông minh kiểu máy móc lại là sự sai lầm...

Theo kinh nghiệm của lãnh vực software engineering, thì "Early optimization is evil", nên giai đoạn này luôn được làm sau cùng.

Chính xác là vậy, đó là lý do có paragraph cuối cùng...

Theo kinh nghiệm của lãnh vực software engineering, thì "Early optimization is evil", nên giai đoạn này luôn được làm sau cùng. Phần mềm OpenKH dùng để tạo trang web này cũng chưa được optimize.

Mấy năm trước tôi có mua dụng cụ về tự về mày mò tự học thử lập trình cho chip PIC 16F84 và FPGA đơn giản. Lúc đó có nghe qua về RTOS. Xin hỏi với phần cứng còn phải tỉ mẩn optimize thế này, thì chẳng thể nào cài RTOS?

RTOS là hệ điều hành, nên phải chăng các thao tác lằng nhằng tốn thời gian đã được làm sẵn và tối ưu sẵn, nên công việc viết chương trình giảm thiểu đáng kể?

Xin hỏi:

• Nói chung phần cứng cỡ nào thì chạy được RTOS nho nhỏ?
• Tính tổng tất cả layer từ cao nhất đến thấp nhất (OS), thì với chương trình embed, nói chung tỉ lệ phần ta phải viết/phần OS làm sẵn chiếm là bao nhiêu?
• Nghe nói phần cứng phát triển như vũ bão, cái thẻ nhớ USB đến 1GB bé tẹo móc vào chìa khóa được cũng rẻ như bèo, nên khi làm embed thì nói chung k đến nỗi khổ sở lắm như phần đầu bài viết đề cập "...đây là cả một vấn đề to lớn..."?
  

RTOS được tạo ra để đáp ứng thực hiện đáp ứng một số ít các tác vụ mà thường được tạo ra nhờ các interrupt handler vì vậy có priority rất cao. Lĩnh vực sử dụng của RTOS thưởng là ở lĩnh vực đo lường và điều khiển tự động chứ không nhằm mục đích xử lý ứng dụng phức tạp.

RTOS không đòi hỏi hệ thống cấu hình cao, lấy ví dụ một con vi điều khiển ví dụ PIC hoặc AVR có flash độ 8k, RAM 1k thì ổn rồi.

Ta không hề can thiệp vào mức HĐH. HĐH chỉ làm nhiệm vụ tạo hàng đợi cho các task và thực thi (schedule). Tỷ lệ bao nhiêu % code người dùng viết thì ko thống kê được vì tùy ứng dụng. Ví dụ ấn nút, sáng LED => 1 interrupt handler độ 2 ~ 3 dòng lệnh.

Vấn đề bộ nhớ tôi nói là bộ nhớ truy xuất tốc độ cao chứ không phải dung lượng lưu trữ. Bộ nhớ truy xuất càng nhanh, giá càng đắt.

Cache memory trên VXL bản chất là SRAM, tốc độ truy xuất chỉ thua thanh ghi nhưng giá cực đắt (xin lỗi vì tôi ko nhớ giá trên 1K là bao nhiêu), Intel Pentium 4 cũng chỉ có 512K. Hạn chế dung lượng của bộ nhớ này sẽ tăng khả năng cache miss và giảm hiệu năng phần mềm. Bởi vậy việc optimizing code là một trong những phương pháp để cải thiện tình hình.

Rõ ràng nếu giá bộ nhớ truy xuất tốc độ cao giảm thực sự thì đương nhiên việc optimize code cũng sẽ chỉ là giải pháp thứ cấp. Nhưng lúc đó không phải là hiện tại.

Chip của Intel giờ có Cache 8MB, 16MB? rồi, có thể lưu trọn 1 frame của hình ảnh màu trong nó nên xử lý ào ào, FPGA muốn thua đến nơi rồi.

Mình có cảm tưởng SRAM dần không còn là vấn đề rồi nên người ta phải suy nghĩ có nên bỏ thêm công sức (là tiền lương nhân công + thời gian sản phẩm ra đời trễ) để tối ưu hóa hay mua bén cái phần cứng đắt hơn chút xíu rồi bán giá cao hơn (Giai đoạn đầu sản phẩm mới bao giờ cũng bán được với giá cao). Sau đó giá sản phẩm đầu vào cũng hạ xuống, đầu ra mình hạ xuống vẫn có lãi như thường.

Chip của Intel giờ có Cache 8MB, 16MB? rồi, có thể lưu trọn 1 frame của hình ảnh màu trong nó nên xử lý ào ào, FPGA muốn thua đến nơi rồi.

Mình có cảm tưởng SRAM dần không còn là vấn đề rồi nên người ta phải suy nghĩ có nên bỏ thêm công sức (là tiền lương nhân công + thời gian sản phẩm ra đời trễ) để tối ưu hóa hay mua bén cái phần cứng đắt hơn chút xíu rồi bán giá cao hơn (Giai đoạn đầu sản phẩm mới bao giờ cũng bán được với giá cao). Sau đó giá sản phẩm đầu vào cũng hạ xuống, đầu ra mình hạ xuống vẫn có lãi như thường

Hi, điều bạn nói là đúng nhưng đối tượng của bài viết này ko tập trung nhiều vào các phần mềm trên PC. CPU và bộ nhớ sẽ quyết định giá của sản phẩm, nếu sử dụng không hợp lý những tài nguyên này sẽ tạo ra những sản phẩm một là giá quá đắt, hai là hiệu năng kém. Bạn có biết một chiếc điện thoại thông minh như iPhone với bao tính năng tuyệt vời lại sử dụng VXL ARM 620MHz & 16K cache memory?