Thông báo

Collapse
No announcement yet.

Hệ thời gian thực và điều khiển thời gian thực

Collapse
X
 
  • Lọc
  • Giờ
  • Show
Clear All
new posts

  • Hệ thời gian thực và điều khiển thời gian thực

    Theo tạp chí TĐHNN. Tác giả TS: Hoàng Minh Sơn.

    Trước tiên, tôi muốn đưa ra hai ví dụ minh họa đơn giản để trả lời câu hỏi về sự liên quan giữa một giải pháp điều khiển với cái gọi là xử lý thời gian thực.
    Ví dụ thứ nhất, từ lý thuyết điều khiển tự động, ta đã hiểu rõ thuật toán điều chỉnh PID. Câu hỏi đặt ra là phải lập trình như thế nào để cài đặt thuật toán trên nền một hệ vi xử lý, hoặc chỉ đơn thuần mô phỏng thời gian thực trên máy tính cá nhân? Nếu ta cứ bỏ qua các chi tiết như gián đoạn hóa, lọc nhiễu, chuẩn hóa vào/ra và chống reset-windup, thì vẫn có hàng loạt các câu hỏi khác cần phải trả lời:

    * Làm thế nào để tạo các chu kỳ trích mẫu hay chu kỳ điều khiển một cách chính xác (ví dụ 0.01s hoặc 0.5s) trong chương trình theo đúng yêu cầu của lý thuyết điều khiển số?

    * Ngay cả khi ta đã biết sử dụng các ngắt thời gian để tạo chu kỳ trích mẫu, nhưng nếu phải thực hiện nhiều vòng điều chỉnh PID với chu kỳ trích mẫu khác nhau thì giải pháp sẽ phải thế nào? Khi nào và làm thế nào để một vi xử lý có thể đáp ứng đồng thời yêu cầu thực hiện nhiều thuật toán điều chỉnh? Thêm vào đó, nếu một số sự kiện khác xảy ra cần xử lý ngay thì việc tổ chức thực hiện trong chương trình ra sao?

    * Khi một vòng điều chỉnh không được đáp ứng về yêu cầu thời gian (chu kỳ trích mẫu không chính xác, thời điểm đưa ra kết quả tính toán chậm hơn thời điểm trích mẫu tiếp theo), thì chất lượng điều khiển sẽ bị ảnh hưởng như thế nào?

    Rõ ràng, việc đưa ra lời giải đáp cho những câu hỏi trên không đơn thuần chỉ dựa vào những kiến thức của lý thuyết điều khiển, mà liên quan nhiều hơn tới cơ chế xử lý thông tin trong thiết bị điều khiển. Đó là cơ chế xử lý thời gian thực, một nội dung mang tính chất nền tảng cho mọi thiết bị điều khiển.

    Ví dụ thứ hai, giả sử một công ty nào đó muốn tự phát triển một hệ điều khiển (PLC, DCS hay gì đó) trong nước. Ngoài các kiến thức và hiểu biết về cấu trúc phần cứng, thiết kế vi mạch, ngôn ngữ lập trình phần mềm và lý thuyết điều khiển, hàng loạt các vấn đề khác cần phải được làm rõ:

    * PLC hay DCS là một hệ điều khiển chia sẻ, có nghĩa là nó đảm nhiệm nhiều “tác vụ” đồng thời. Việc quản lý và thực thi “đồng thời” một số lượng không nhỏ các “tác vụ” như vậy được thực hiện theo cơ chế nào để đáp ứng được các yêu cầu về thời gian do người sử dụng định nghĩa? Làm thế nào để giữa các tác vụ đó không chanh chấp sử dụng bộ nhớ, cổng vào/ra, timer,...

    * Làm thế nào để lập trình sử dụng bộ nhớ, sử dụng các cổng vào/ra, và giao tiếp với các thiết bị trong mạng được thuận tiện? Làm thế nào để có thể hỗ trợ người sử dụng truyền nạp cấu hình phần cứng và chương trình ứng dụng, thậm chí từng phần chương trình xuống bộ điều khiển một cách dễ dàng?

    * Cơ chế cảnh giới, giám sát lỗi bộ nhớ, lỗi các cổng vào ra và lỗi các module được thực hiện như thế nào để nó độc lập với các chương trình ứng dụng.

    Câu trả lời chung cho các câu hỏi trên là sự cần thiết phải phát triển một hệ điều hành thời gian thực. Có thể nói, cơ chế xử lý thời gian thực trong mỗi bộ điều khiển công nghiệp như trong các hệ PLC hoặc DCS là do một hệ điều hành thời gian thực đảm nhiệm.

    ( Còn nữa )

  • #2
    Hệ thống thời gian thực

    Bây giờ ta quay trở lại làm rõ khái niệm “hệ thời gian thực”. Trong các tài liệu cũng như trong thực tế, khái niệm thời gian thực và hệ thời gian thực không phải lúc nào cũng được hiểu một cách thống nhất. Nhiều người cho rằng, hệ thời gian thực là một hệ phải làm việc với yêu cầu thời gian rất nhanh (trong phạm vi một vài micro-giây gì đó), ví dụ các hệ thống điều khiển tay máy, điều khiển động cơ, ... Không ít ý kiến cho rằng, khái niệm thời gian thực luôn gắn với các hệ nhúng, điều khiển thời gian thực là một vấn đề của riêng điều khiển nhúng, tức là các giải pháp sử dụng vi điều khiển, DSP, v.v... Lại cũng có quan niệm rằng thời gian thực là thời gian tuyệt đối, hệ thời gian thực là một hệ có khả năng làm việc với thời gian tuyệt đối theo giờ-phút-giây của ngày tháng. Vậy chúng ta nên hiểu như thế nào đây?

    Một quan điểm được ủng hộ và trích dẫn nhiều nhất là của Stankovic (John A. Stankovic et al.: “Strategic Directions in Real-Time and Embedded Systems”. ACM Computing Surveys, Vol. 28, No. 4, December 1996):

    “A real-time system is one in which the correctness of the system depends not only on the logical results, but also on the time at which the results are produced”.

    Như vậy, một hệ thời gian thực là một hệ thống mà sự hoạt động tin cậy của nó không chỉ phụ thuộc vào sự chính xác của kết quả, mà còn phụ thuộc vào thời điểm đưa ra kết quả, hệ thống có lỗi khi yêu cầu về thời gian không được thoả mãn.

    Trong một bài báo nổi tiếng khác (“Misconceptions About Real-Time Computing”, IEEE Computer, 21(10), Oct. 1988.), Stankovic cũng đã chỉ ra một số quan niệm sai lầm về khái niệm thời gian thực. Ví dụ, khái niệm hệ thời gian thực không đồng nghĩa với khái niệm hệ xử lý tốc độ cao, xử lý nhanh. Nếu ta cho rằng, phải là các ứng dụng điều khiển có yêu cầu thời gian tính toán rất nhanh mới gọi là điều khiển thời gian thực, thì một câu hỏi sẽ được đặt ra là: như thế nào mới được gọi là nhanh? Ta có thể thống nhất là, cỡ một vài micro-giây là rất nhanh, tuy nhiên nếu một vài chục micro-giây thì sao, một trăm micro-giây thì sao? Nếu một trăm micro-giây mới gọi là nhanh, thì 101, 102, ... có nhanh không? Các hệ điều khiển với chu kỳ trích mẫu 5ms, 6 ms, 7ms có được gọi là hệ thời gian thực hay không?

    Có thể nói một cách nôm na, tính thời gian thực là khả năng đáp kịp thời và chính xác. Và ta hoàn toàn có thể định nghĩa như thế nào là kịp thời theo bốn yêu cầu khác nhau, như minh họa trên hình 1.

    Last edited by PPIICC; 12-09-2005, 01:03.

    Comment


    • #3
      Một hệ thống thời gian thực có các đặc điểm tiêu biểu sau:

      * Tính bị động: Hệ thống phải phản ứng với các sự kiện xuất hiện vào các thời điểm thường không biết trước. Ví dụ, sự vượt ngưỡng của một giá trị đo, sự thay đổi trạng thái của một thiết bị quá trình phải dẫn đến các phản ứng trong bộ điều khiển.

      * Tính nhanh nhạy: Hệ thống phải xử lý thông tin một cách nhanh chóng để có thể đưa ra kết quả phản ứng một cách kịp thời. Tuy tính nhanh nhạy là một đặc điểm tiêu biểu, nhưng một hệ thống có tính năng thời gian thực không nhất thiết phải có đáp ứng thật nhanh mà quan trọng hơn là phải có phản ứng kịp thời đối với các yêu cầu, tác động bên ngoài.

      * Tính đồng thời: Hệ thống phải có khả năng phản ứng và xử lý đồng thời nhiều sự kiện diễn ra. Có thể, cùng một lúc một bộ điều khiển được yêu cầu thực hiện nhiều vòng điều chỉnh, giám sát ngưỡng giá trị nhiều đầu vào, cảnh giới trạng thái làm việc của một số động cơ.

      * Tính tiền định: Dự đoán trước được thời gian phản ứng tiêu biểu, thời gian phản ứng chậm nhất cũng như trình tự đưa ra các phản ứng. Nếu một bộ điều khiển phải xử lý đồng thời nhiều nhiệm vụ, ta phải tham gia quyết định được về trình tự thực hiện các công việc và đánh giá được thời gian xử lý mỗi công việc. Như vậy người sử dụng mới có cơ sở để đánh giá về khả năng đáp ứng tính thời gian thực của hệ thống.

      Xử lý thời gian thực

      Xử lý thời gian thực là hình thức xử lý thông tin trong một hệ thống để đảm bảo tính năng thời gian thực của nó. Như vậy, xử lý thời gian thực cũng có các đặc điểm tiêu biểu nêu trên như tính bị động, tính nhanh nhạy, tính đồng thời và tính tiền định. Để có thể phản ứng với nhiều sự kiện diễn ra cùng một lúc, một hệ thống xử lý thời gian thực sử dụng các quá trình tính toán đồng thời.

      Quá trình tính toán là một tiến trình thực hiện một hoặc một phần chương trình tuần tự do hệ điều hành quản lý trên một máy tính, có thể tồn tại đồng thời với các quá trình khác kể cả trong thời gian thực hiện lệnh và thời gian xếp hàng chờ đợi thực hiện.

      Các hình thức tổ chức các quá trình tính toán đồng thời:

      * Xử lý cạnh tranh: Nhiều quá trình tính toán chia sẻ thời gian xử lý thông tin của một bộ xử lý.

      * Xử lý song song: Các quá trình tính toán được phân chia thực hiện song song trên nhiều bộ xử lý của một máy tính.

      * Xử lý phân tán: Mỗi quá trình tính toán được thực hiện riêng trên một máy tính.

      Trong các hình thức trên đây thì hình thức xử lý cạnh tranh có vai trò chủ chốt. Mặc dù hệ thống điều khiển có thể có nhiều trạm, và mỗi trạm có thể là một hệ đa vi xử lý, số lượng các quá trình tính toán cần thực hiện thường bao giờ cũng lớn hơn số lượng vi xử lý. Trong khi một vi xử lý không thể thực hiện song song nhiều lệnh, nó phải phân chia thời gian để thực hiện xen kẽ nhiều nhiệm vụ khác nhau theo thứ tự tùy theo mức ưu tiên và phương pháp lập lịch.

      Trong các hệ thống điều khiển, khái niệm tác vụ (task) cũng hay được sử dụng bên cạnh quá trình tính toán. Có thể nói, tác vụ là một nhiệm vụ xử lý thông tin trong hệ thống, có thể thực hiện theo cơ chế tuần hoàn (periodic task) hoặc theo sự kiện (event task). Các dạng tác vụ qui định trong chuẩn IEC 61131-3 (Programmable Controllers – Part3: Programming Languages) được minh họa trên hình 2. Ví dụ, một tác vụ thực hiện nhiệm vụ điều khiển cho một hoặc nhiều mạch vòng kín có chu kỳ trích mẫu giống nhau. Hoặc, một tác vụ có thể thực hiện nhiệm vụ điều khiển logic, điều khiển trình tự theo các sự kiện xảy ra. Tác vụ có thể thực hiện dưới dạng một quá trình tính toán duy nhất, hoặc một dãy các quá trình tính toán khác nhau.

      Comment


      • #4
        (Tiếp)

        Phương pháp lập lịch (Scheduling)

        Để tổ chức việc thực hiện các tác vụ được hiệu quả, một hệ điều hành thời gian thực cần các phương pháp lập lịch. Trước hết, cơ chế lập lịch thực hiện cho các tác vụ có thể được thực hiện theo hai cách:

        * Lập lịnh tĩnh: thứ tự thực hiện các tác vụ không thay đổi mà được xác định trước khi hệ thống đi vào hoạt động.

        * Lập lịnh động: hệ điều hành xác định lịnh sau khi hệ thống đã đi vào hoạt động.

        Sau khi xác định được cơ chế lập lịch, hệ điều hành cần sử dụng một sách lược lập lịnh (strategy) để áp dụng đối với từng tình huống cụ thể. Có thể chọn một trong những cách sau:

        * FIFO (First In First Out): một tác vụ đến trước sẽ được thực hiện trước.

        * Mức ưu tiên cố định/động: tại cùng một thời điểm, các tác vụ được đặt các mức ưu tiên cố định hoặc có thể thay đổi nếu cần.

        * Preemptive: còn gọi là sách lược chen hàng, tức là chọn một tác vụ để thực hiện trước các tác vụ khác.

        * Non-preemptive: còn gọi sách lược không chen hàng. Các tiến trình được thực hiện bình thường dựa trên mức ưu tiên của chúng.

        Việc tính mức ưu tiên của mỗi tiến trình được thực hiện theo một trong số các thuật toán sau:

        * Rate monotonic: tác vụ nào càng diễn ra thường xuyên càng được ưu tiên.

        * Deadline monotonic: tác vụ nào càng gấp, có thời hạn cuối càng sớm càng được ưu tiên.

        * Least laxity: tác vụ nào có tỷ lệ thời gian tính toán/thời hạn cuối cùng(deadline) càng lớn càng được ưu tiên.

        Bên cạnh phương pháp lập lịch, cơ chế xử lý thời còn đặt ra nhiều vấn đề khác nữa như quản lý và đồng bộ hóa việc sử dụng tài nguyên, giao tiếp liên quá trình, ... Tuy nhiên trong khuôn khổ bài báo này, ta sẽ không đi sâu vào các chi tiết đó.

        Mỗi hệ thống điều khiển là một hệ thời gian thực

        Có thể nói, tất các các hệ thống điều khiển là hệ thời gian thực. Ngược lại, một số lớn các hệ thống thời gian thực là các hệ thống điều khiển. Không có hệ thống điều khiển nào có thể hoạt động bình thường nếu như nó không đáp ứng được các yêu cầu về thời gian, bất kể là hệ thống điều khiển nhiệt độ, điều khiển áp suất, điều khiển lưu lượng hay điều khiển chuyển động. Một bộ điều khiển phải đưa ra được tín hiệu điều khiển kịp thời sau một thời gian nhận được tín hiệu đo để đưa quá trình kỹ thuật về trạng thái mong muốn. Một mạng truyền thông trong một hệ thống điều khiển có tính năng thời gian thực phải có khả năng truyền tin một cách tin cậy và kịp thời đối với các yêu cầu của các bộ điều khiển, các thiết bị vào/ra, các thiết bị đo và thiết bị chấp hành. Tính năng thời gian thực của một hệ thống điều khiển phân tán không chỉ phụ thuộc vào tính năng thời gian thực của từng thành phần trong hệ thống, mà còn phụ thuộc vào sự phối hợp hoạt động giữa các thành phần đó.

        Trong thực tế, yêu cầu về tính thời gian thực đối với mỗi ứng dụng điều khiển cũng có các đặc thù khác nhau, mức độ ngặt nghèo khác nhau. Ví dụ, các hệ thống điều khiển nhúng thường được ứng dụng với các sản phẩm chế tạo hàng loạt, chi phí phần cứng cho từng sản phẩm cần được giảm thiểu, vì vậy dung lượng bộ nhớ cũng như hiệu năng vi xử lý thường thấp. Hơn nữa, điều khiển nhúng lại là giải pháp đặc thù trong các ứng dụng nhanh, tiêu biểu là điều khiển chuyển động, dẫn đến các yêu cầu ngặt nghèo hơn về hiệu suất phần mềm. Trong khi đó, các hệ điều khiển công nghiệp như PLC hoặc DCS đặt ra yêu cầu cao về khả năng lập trình và đưa vào vận hành thuận tiện cho các bài toán lớn. Các hệ thống ứng dụng PLC và DCS cũng thường chậm hơn (ví dụ trong điều khiển các quá trình công nghệ) Nhưng như vậy không có nghĩa là các giải pháp PLC hoặc DCS không phải là các hệ thời gian thực. Điều gì sẽ xảy ra trong một nhà máy điện nguyên tử hay trong một nhà máy lọc dầu, nếu thuật toán điều khiển mặc dù rất hiện đại nhưng bộ điều khiển không có khả năng đưa ra kết quả đáp ứng kịp thời vào những thời điểm trích mẫu, hay khi không đưa ra được các quyết định dừng khẩn cấp một cách kịp thời trong những tình huống bất thường?

        TS. Hoàng Minh Sơn (Theo:Tạp chí TĐHNN)

        Comment


        • #5
          Đây là bài viêt hay và tổng quan về Hệ thời gian thực, điều khiển theo thời gian thực.

          Comment


          • #6
            Cám ơn PPiiCC mình sẽ nghiên cứu bài viết này.

            Comment


            • #7
              Về vấn đề đáp ứng thời gian tác động tui có ý kiến như thế này. uP chỉ có 1 lõi xử lý, PLC cũng vậy. Cái mà ta đang gọi là thời gian thực chỉ mang ý nghĩa cách viết chương trình mà thôi. Khi đó các sự kiện xảy ra đồng thời cũng vẫn được xử lý tuần tự, do vậy bắt buộc có trễ xử lý. Vấn đề là ta không thể lấy 1 con 1MIPS để xử lý song song 3 sự kiện 100 kHz và giao tiếp LCD và giao tiếp Keys và giao tiếp máy tính được. Nếu muốn chạy ngon trong trường hợp này cần con 30-50MIPS cơ. Khi đó trễ sẽ rất nhỏ và có thể bỏ qua được. Nếu đem con 1MIPS trên xử lý 3 tiến trình 500Hz song song thì có lẽ sẽ chẳng có gì phải phàn nàn cả. Ticktime của các HĐH cho uP hiện nay đều ở mức 10ms (Keil for 51...), nhanh lắm là 1 ms mà thôi . Do vậy cứ sau 10ms thì nó chuyển sang task khác, giả sử dùng 10 task thì mỗi task có 1MIPS/10=0,1MIPS.
              Hiện nay kiến trúc Pentium và DSP có 2 hay nhiều bộ xử lý tính toán song song khiến năng lực tính toán nhanh hơn. VD DSP đời C6000 của Texas chạy 200MHz nhưng có 8 lõi xlý số học nên công suất tính toán là 1600 MIPS. Tuy có 8 lõi nhưng không xử lý song song 8 sự kiện được mà vẫn phải thông qua hệ điều hành phân phát quyền. Để tăng tốc độ tính toán đã dẫn tới các hệ thống đa lõi xử lý chạy song song toàn diện (như trong chip Xeon của intel chẳng hạn có 2 lõi), khi đó nếu một ứng dụng có vài ngàn thread sẽ được chặy đồng thời trên vài ngàn lõi CPU và HĐH sẽ combine kết quả.Tính thời gian thực đã được tăng lên nhờ công suất tính toán đã được phân tán ra. Việc nghiên cứu các HĐH này càng ngày càng mang tính lý thuyết, mình nghĩ chưa nên đi sâu vào các HĐH này trong thời điểm hiện tại.
              ! ! you can win if you want ! !

              Comment


              • #8
                Theo tôi, riêng về phần xử lý thời gian thực thì National Instruments đã có các thiết bị và phần mềm đi kèm rất hoàn thiện. Trong đó có bộ CompactRIO có thể xử lý các tác vụ song song và đáp ứng thời gian đến nano giây. Nếu bạn nào cần catalog hoặc mua thiết bị của NI thì liên hệ với tôi.
                Tôi sẽ cung cấp đầy đủ vì tôi là đại diện bán hàng của NI tại Việt Nam.
                Rất hân hạnh được giúp các bạn.

                Phùng Quang Khải
                phungquangkhai@hn.vnn.vn
                0903203425

                Comment


                • #9
                  anhtuan133 nói rất đúng! Tốc độ không phản ánh thời gian thực nhưng để có đặc tính thời gian thực thì phụ thuộc rất nhiều vào tốc độ. Tốc độ càng cao thì sai số càng nhỏ và càng dễ thực hiện các tác vụ thời gian thực.
                  Cũ người mới ta!

                  Comment


                  • #10
                    Để làm thời gian thực cho các MCU thì
                    1. Dùng RTOS chỉ đễ viết, vậy người bình thường vẫn dùng được. Song đòi hỏi MCU tốc độ cao vì có nhiều chu trình xử lý không cần thiết.
                    2. Nếu RT đến 10ms thì dùng OK.
                    Nhung 125uS thì sao, 50uS thì sao. Tăng tốc MCU cũng OK, Nhung nếu tự viết thì khỏi cần tăng tốc MCU.

                    Bạn nào đã thấy các sản phẩm của Nga về DK thì biết. Nó chạy con 4 MIPS nhưng hiệu quả như con 100MIPS của các công ty Mỹ. Trong cùng 1 bài toán
                    Nhà sản xuất chuyên nghiệp các sản phẩm OEM cho gia dụng và công nghiệp.

                    Biến tần
                    Máy giặt
                    Lò vi sóng
                    Bếp từ.
                    Tủ lạnh.
                    Điều hòa

                    Comment


                    • #11
                      Nguyên văn bởi MinhHa
                      Để làm thời gian thực cho các MCU thì
                      1. Dùng RTOS chỉ đễ viết, vậy người bình thường vẫn dùng được. Song đòi hỏi MCU tốc độ cao vì có nhiều chu trình xử lý không cần thiết.
                      2. Nếu RT đến 10ms thì dùng OK.
                      Nhung 125uS thì sao, 50uS thì sao. Tăng tốc MCU cũng OK, Nhung nếu tự viết thì khỏi cần tăng tốc MCU.

                      Bạn nào đã thấy các sản phẩm của Nga về DK thì biết. Nó chạy con 4 MIPS nhưng hiệu quả như con 100MIPS của các công ty Mỹ. Trong cùng 1 bài toán
                      Cái này thì em chưa thấy!!!

                      Nhưng em cũng đã từng chạy con AVR 16MIPS thay cho con 8051 2MIPS trong cùng một bài toán để lấy thêm tiền

                      Comment


                      • #12
                        Hi hi thế bác kiếm được thêm mấy MIDS
                        (MIllion Dong S)
                        Nga nó viết thế nhưng rồi bọn Mỹ nó ra thị trường rồi mass production từ lâu trông khi Nga chắc chỉ đang demo ???
                        Vẫn biết mỗi lần xa là một lần về lại...

                        Comment


                        • #13
                          RTOS chỉ vài MIDS thôi à. Vài MIDS thì làm giúp người ta sau có cái khó hơn thì lấy tiền cho bõ công lấy.

                          Thương mại 1 chút: Có những sản phẩm đang bán 10 T ( vì họ lại bán được 30 T nên phải bán như thế) Vậy mà có chú làm 8051 xong bán chỉ 500K có chết không cơ chứ. Công rẻ như chạy xe ôm luôn.
                          Vấn đề không phải là 8051 17K + PCB 50K +... = 200K. Bán 500K là sướng quá rồi.

                          Vấn đề kỹ thuật chứ không phải thương mại.
                          Các nhà máy thủy điện của VN mới xây dựng như YALY, SESAN 1,3 vẫn dùng điều khiển của Nga đấy chứ. Mua phần cứng của Mỹ và Nga làm phần mềm.Chỉ dùng 386 thôi, mới đây thấy đến 486DX2-66. Chắc là dòng 386 không còn nên thay bằng 486.
                          Còn làm ăn ngay thì thay 8051 bằng ATMEGA hay ARM. Đắt hơn không bao nhiêu nhưng khỏi cần tối ưu. Vậy cần gì đến những công trình toán. FFT chậm thì thay con TMS 6000 1000 MIPS khỏi cần DFT trên TMS3202x.
                          Vấn đề là với cùng 1 MCU thì làm thế nào. RTOS càng dễ dùng bao nhiêu thì càng chậm bấy nhiêu.
                          Nhà sản xuất chuyên nghiệp các sản phẩm OEM cho gia dụng và công nghiệp.

                          Biến tần
                          Máy giặt
                          Lò vi sóng
                          Bếp từ.
                          Tủ lạnh.
                          Điều hòa

                          Comment


                          • #14
                            Một bài toán tối ưu không chỉ là bài toán về tốc độ tiệm cận kết quả. Khi lập trình giải quyết một bài toán không phải cứ nghĩ làm sao cho tối ưu nhất về giải thuật, tốc độ tính toán thì là người viết code giỏi. Theo tôi chúng ta nên cân nhắc về hiệu quả thời gian, khả năng mở rộng và nâng cấp phần cứng cũng như phần mềm. Chứ viết 1 cái chương trình chạy nhanh gấp 10 lần 1 chương trình khác chưa hẳn chương trình đó đã là tốt. Viết bằng ASM chạy nhanh kinh khủng và code nhỏ kinh hồn. Hệ đơn nhiệm bao giờ cũng ổn định hơn rất nhiều so với hệ đa nhiệm. Vậy sao vẫn ra đời Windows, Linux và hệ nhúng là RTLinux. Đơn giản vị nó có thể khả chuyển trên nhiều nền hardware, tiện ích cho người sử dụng và lập trình. Chậm thì nó tăng tốc VXL là xong.

                            Còn thằng NGA vẫn dùng x386 chắc chắn thứ nhất là đã có sản phẩm ổn định trên nền 386 viết bằng ASM hoặc C. Thay đổi một chút là có thể đáp ứng được bài toán tương tự. Chẳng dại gì no đi học cái mới rồi kỳ cạch viết cả tháng trời để ra một đời DSP gì đó cho oai.

                            Thế hệ trẻ tiếp cận công nghệ nhanh hơn khi mới bắt tay vào làm chẳng dại gì chọn hệ x386 để lập trình!!!! Nên vấn đề thằng này dùng tốc độ cao hay thằng kia dùng tốc độ chậm không quan trọng. Quan trọng là họ đã giải quyết được bài toán trong vòng bao lâu và chi phí bảo trì cho hệ thống đó là bao nhiêu???

                            Comment


                            • #15
                              Sau 1 năm quay trở lại topic này.
                              Dạo nay forum bùn quá, chẳng có bài nào mới, chỉ có mấy bác bán linh kiện còn hoạt động!
                              Sau khi sử dụng RTOS vào một số việc mình có nhận xét thế này:
                              - RTOS giúp cho chương trình viết sáng sủa hơn, mang tính phân chia nhiệm vụ rõ ràng hơn.
                              - Có thể gộp chung các công việc chạy nhanh, chạy chậm trong 1 chương trình. Cái này thì cách viết nào cũng làm được nhưng với task thì sẽ còn dễ hơn.
                              - Những ứng dụng mà tương đối cỡ vài chục K (như khi dùng ATMEGA128 hay PIC24, dsPIC) thì hầu như có đủ điều kiện và nên dùng RTOS. Các ứng dụng nhỏ như PIC16,51 thì viết theo tree là hay nhất.
                              - Ở cấp độ cao hơn RTOS, với những ứng dụng đòi hỏi kế thừa cao, sử dụng free code được ngay, nhiều người phát triển thì nên dùng linux. Linux chạy chậm và tốn kém hơn rất nhiều nhưng bù lại nó được rất nhiều người viết, cả kernel và code cho các device khó như điều khiển disk, pci, bluetooth..... Thông thường với các ứng dụng single chip có thể dùng linux như một task của RTOS sẽ cho đáp ứng thời gian thực cao hơn. Cái này rất có ý nghĩa nếu vừa làm dsp vừa làm quản lý.
                              - Cái khó trong RTOS là đồng bộ giữa các ngắt không đồng bộ với chương trình. Với các ngắt xảy ra nhanh thường dẫn tới việc quá tải. Với những ngắt yêu cầu phát ra mà có sai số thời gian nhỏ thì lại càng khó cho RTOS. Mình làm một cái PID position điều khiển động cơ servo có thời gian đáp ứng 1/100ms chạy trên con ATMEGA128 mà thấy nó rất hay bị trễ, khiến việc đưa kết quả ra bị gai và nhảy bậc. Cái ADC1KHz cũng rắc rối phết, cứ phải đặt buffer to vật nếu không lại mất dữ liệu. Nói chung RTOS nặng nền về phần thủ tục nên nó chạy chậm.
                              - RTOS và compiler có quan hệ mật thiết với nhau. Nếu dùng mấy cái gnu thì hiệu năng của chip giảm hẳn. Ví dụ WinAVR chỉ sử dụng có mấy thanh ghi để tính toán thôi, còn mấy thanh ghi kia thì chỉ pop và push (!), hầu hết đều tính toán trên stack. Do vậy dùng cái FreeRTOS dịch bằng WinAVR thì con ATMEGA 16 MIPS cũng chỉ bằng con PIC 10 MIPS là cùng.
                              - Ý của bác MH cũng rất đúng. Sở dĩ 100MIPS Mỹ=10MIPS của nga là do lập trình hiện đại đi theo xu hướng object oriented. Dễ thấy là các chương trình .NET ngốn nhiều RAM và chạy chậm hơn, nhưng bù lại viết bằng .NET thì quá sung sướng.
                              Bài cuối topic này là 8/2006, tới nay đã gần một năm. Chắc giờ đây đã đủ chín chắn để tranh lận tiếp.
                              Lâu lâu nổ phát cho vui.
                              ! ! you can win if you want ! !

                              Comment

                              Về tác giả

                              Collapse

                              PPIICC Tìm hiểu thêm về PPIICC

                              Bài viết mới nhất

                              Collapse

                              Đang tải...
                              X