Phần này bàn tới việc thiết kế và phát triển một cách xử lí thời gian thực việc thu thập, sắp xếp các dữ liệu khác nhau trong bối cảnh tranh chấp nguồn tài nguyên hệ thống. Tức là bài toán với các hoạt động dữ liệu thời gian thực mà không có sử dụng phần mềm tinh xảo như RTOS để giải quyết. Ví dụ như điều khiển ôto ngày nay: lấy mẫu dữ liệu từ nhiều nguồn khác nhau khi xe chạy, lưu, xử lí, hiển thi, … Có nhiều phần mềm máy tính xử lí cài trên ô tô, như điều khiển động cơ (engine management unit (EMU)), hệ thống điều khiển sức kéo trong sự liên quan tới chuyển động của 4 bánh xe… EMU tương tác với các thành phần qua cổng với tốc độ 19,2 kbaub… hãy tính xem loại máy tính nào có thể sử dụng trên ô tô, đủ mạnh để thực các tác vụ như vậy. Đó là phạm trù phần cứng, một HTN đủ mạnh vậy.
§ Chọn môi trường phần mềm (software environment)
Vậy bắt đầu từ đâu với bài toán như trên ? Thông thường ta thiết kế phần cứng, phát triển phần mềm, cài đặt, thử nghiệm, sửa đổi …cài đặt thử chạy …. Tuy nhiên có một thực tế là các thành phần phần mềm như hệ điều hành, chương trình dịch thì không thể thay đổi và có thể phù hợp với phần cứng. Trong thực tế một quyết định thông minh là phải có sự hài hòa tính tới cả phần cứng và phần mềm, sau dó phần mềm có thứ tự ưu tiên cao nhất. Tại sao ? Có gì quan trọng hơn nếu ta dùng máy tính để điều và kiểm soát một hệ thống thực ? và câu hỏi tiếp theo: HĐH nào sẽ là phần mềm hệ thống như là ứng viên ? RTOS nào đó, MSDOS hay Windows CE …
? Cần 1 phần mềm thời gian thực thỏa mãn các thông số hạn chót (deadline) đẻ duy trì quá trình lấy mẫu dữ liệu, thông qua truy nhập trực tiếp cổng ghép nối (song song) và phải đơn giản, ổn định. Các kỉ sư ngay lập tức có vẽ sẽ chọn RTOS, tuy nhiên RTOS đắt và sẽ sử dụng thể nào để phát triển ở HTN đích. MS DOS có sẳn và cơ bản là cho phép truy nhập phần cứng dễ dàng, trong khi MS WINDOWS kềnh càng, không thể truy nhập trực tiếp phần cứng và tương đối phức tạp và cản trở việc truy cập làm quá tải nguồn tài nguyên, do vậy không hợp, trừ khi được xây dựng mới (WINDOWS CE). Vậy sự lựa chọn ở đây là MS DOS cùng với công cụ Borland C không phí, là thích hợp, mặc dù cả hai có vẽ củ kỉ, nhưng khả năng còn rất tiềm ẩn. Bộ biên dịch Borland C có hệ thư viện hổ trơ truy nhập cấp thấp và phần cứng và khai thác các trình chạy ở BIOS. Vậy MS DOS có thể thay thế cho một RTOS ? Cái này tùy thuộc vào sự chuyên nghiệp cho hệ đích phát triển. Nói vậy để nhắc tới đặc điểm là MS DOS chỉ thực thi một luồng tác vụ, cho dù có thể gọi các thủ tục và phần mềm có cấu trúc modular, thì vẫn chỉ có 1 thực thi mà thôi. Nếu phải cần tới đa luồng thực thi thì đây là vấn đề khó ! Nhưng có một việc là: hãy ‘gói’ các đa tác vụ đó vào một tác vụ đơn ! (WINDOWS là đa tác vụ, nhưng không phải là thời gian thực, nhưng nếu khéo tổ chức các phần mềm chạy phối hợp (co-operate) và chia sẻ thời gian xử lí với nhau, thì có thể xử lí thời gian thực được. Tuy nhiên nếu không duy trì được kỉ thuật này, hệ thống sẽ bị rối loạn vì các tranh chấp không thể điều hòa được, ví dụ như một tác vụ độc quyền CPU trong thời gian quá dài, không đáp ứng được yêu cầu hạn chót (deadline), các tác vụ chỉ có thể thoát bằng hết hạn (time-out) để tránh bế tắc hệ thống).
185
Dưới đât thử bàn về một số giải pháp để thực hiện thời gian thực hóa một hệ không thời gian thực.
§ Chuyển hóa hiệu năng thời gian thực sang hệ không thời gian thực. Trước hết hãy phân loại đặc trưng thời gian thực cần thực hiện và sau đó xác định mức độ năng lực xử lí cần thiết.
Nhắc lại là thời gian thực có nghĩa tác vụ phải hoàn thành trong khung thời gian đã định (hàng giây, hay phút). Hầu như vấn đề có tính tới hạn (critical) thường là ở các tác vụ thu thập dữ liệu, khung thời gian xử lí dữ liệu giữa hai lần lấy mẫu và điều này lại phụ thuộc vào tốc độ lấy mẫu. Vậy thời gian tối thiểu cho tác vụ này là bao nhiêu. Một tính toán khác là tốc độ của CPU: CPU sẽ thực hiện bao nhiêu lệnh giữa các lần lấy mẫu dữ liệu, mỗi lệnh chi phí bao nhiêu CPUCLK và qui ra thời gian toàn bộ. Ví dụ với CPU 80386 chạy ở CPUCLK = 30MHz (TCLK= 33 ns), tốc độ lấy mẫu là 30Hz (ts= 33ms), thì giữa 2 lần lấy mẫu sẽ trôi qua 106 TCLK
. Nếu 1 lệnh máy mất 10 TCLK, CPU có thể chạy 100.000 lệnh. Cho một tác vụ cụ thể nào đó, có thích nợp ? Nếu OK, CPU không nằm trong vấn đề, và ngược lại tốc độ CPU chưa thỏa mãn.
§ Chọn phần cứng. Chọn một phần cứng không có khó khăn. Những bộ vi điều khiển (microcontroller) không phải là lựa chọn do có định hướng thiết kế, vì các chức năng giới hạn, do bộ nhớ nhỏ, tốc độ chậm. Bo mạch máy tính (based micro-computer board) sẽ là lựa chọn phù hợp vì có bộ nhớ mở rộng, có thiết bị lưu trữ ngoài đa dạng (đĩa mềm, đĩa cứng, USB) đễ lưu dữ liệu cho các nhu cầu thống kê, phân tích. Các bo mạch này lại rất nhỏ, cấu trúc modular, dễ bổ sung, ví dụ loại PC 104 chuẩn công nghiệp (như đã giới thiệu ở chương 1). Hơn nữa là khả năng cài đặt các phần mềm.
§ Lập lịch lấy mẫu dữ liệu. Việc thu thập dữ liệu thường kì trong những khoản thời gian cố định cho các chu kì lấy mẫu là thông thường ở các hệ thống có định thời. Có nghĩa là các chu kì lấy mẫu phải kiên định sao cho thời gian lấy dữ liệu không bị sai lệch, như vậy dữ liệu sẽ đúng như hoài vọng (tức dữ liệu đúng các thời điểm cần lấy). Có thể có nhiều kỉ thuật đảm bảo bài toán này, ví dụ: chương trình lấy dữ liệu cho chạy tự do, còn số liệu thu được sẽ được so sánh và hiệu chỉnh với đồng hồ định thời lấy mẫu, hoặc phần mềm hiệu chỉnh thời điểm lấy mẫu chính xác hơn sau khi làm bước trước đó, tức có dự đoán khi nào sẽ có số liệu, thì chuẩn bị lấy mẫu. Từ đó chu kì lấy mẫu sẽ được tính sau bao lâu thì lấy số liệu và dự đoán khi nào nguồn sẽ có dữ liệu. Tuy nhiên cách này cũng có một vài vấn đề:
ü Chu kì lấy mẫu sẽ không giống nhau từ một hệ này sang hệ khác và phụ thuộc vào tốc độ CPU, điều khiển cổng ghép nối với nguồn dữ liệu.
ü Thời gian lấy mẫu phụ thuộc vào xử lí mẫu và chu kì lấy mẫu sẽ biến động và có ảnh hưởng tới độ chính xác mẫu lấy được.
ü Khi đề cập tới hiện thị kết quả, đặc biệt là giá trị tức thời sẽ có sự chênh lệch thời điểm (bị trễ).
ü Để khắc phục, việc sử dụng đồng hồ thời gian thực (real-time clock- RTC) trong hệ thống làm điểm qui chiếu là cần thiết, đặc biệt khi lập biểu. Các PC, PC 104 … đều
186
có đồng hồ này và dùng cách gọi hàm sẽ nhận được các giá trị biểu diễn ở cấp ms, là rất chính xác cho các sự kiện thực. Đọc được thời điểm hiện tại, so sánh với thời điểm trước đó, xác định thời gian đã trôi qua. Nếu thời gian này bé hơn chu kì lấy mẫu, đọc lại, so sánh… Nếu thời gian đó bằng với độ dài chu kì, lưu thời điểm này lại, chuyển điều khiển tới code lấy mẫu. Chu trình này sẽ được lặp lại trong suốt quá trình lấy dữ liệu. Tuy nhiên giải pháp này có thể sẽ có chênh lệch thời gian nếu chu kì lấy mẫu tính bằng ms, RTC trả lại cũng là ms ! Đây là câu hỏi dùng cái gì đo cái gì ! Nói cách khác nếu RTC trả lại ns, chắc sẽ tốt hơn. Hay nếu chu kì lẫy mẫu tính là giây, vài giây, thì sẽ tốt hơn. Nếu đồng hồ RTC của máy tính không đủ độ phân giải do đó không phải là lựa chọn, thì có giải pháp khác sẽ được sử dụng:
Cơ chế ngắt (DOS INT: INT 15 - AH = 86h SYSTEM - WAIT (às) mỏy AT,XT2,XT286,CONV,PS) đưa tác vụ vào trạng thái “ngủ” (sleeep) hay “đợi” (wait) một thời gian, sau đó đánh thức khi thời gian cần đã đạt giá trị. Thời gian tính sẽ qui vào lệnh, tớnh theo às, cho nờn cú độ chớnh xỏc cao. Chu kỡ thời gian sẽ tớnh cho từng hệ cụ thể. Giải pháp khác là dùng đồng hồ phần cứng độc lập (timer) phát sinh ngắt theo chu kì để lấy mẫu dữ liệu, ở đây cần viết code xử lí ngắt cẩn thận và tối ưu để có thể kết thúc sớm trước khi sang ngắt mới, không làm quá tải CPU cho các tác vụ khác ! (Ngoài ra DOS còn có một ngắt báo thời gian hệ thống, xẩy ra 18.2 lần/giây (18.2 Hz ), cũng là giải pháp cho cập nhật dữ liệu.
§ Lấy mẫu dữ liệu. Để lấy dữ liệu, cần lựa chọn kỉ thuật ghép nối từ các cảm biến vào hệ thống. Có vài kỉ thuật cơ bản, đó là dữ liệu được chuyển vào khi các bộ biến đổi đã chuyển từ tương tự sang số. Việc chọn tuyển số liệu vào hệ có ảnh hương rất lớn tới thời gian lấy dữ liệu toàn phần. Truyền thông có thể là nối tiếp (serial line), song song (parallel-bus), sau đó là cách kích hoạt chu trình phần mềm: chu kì (polling) theo đồng hồ như trình bày ở trên hay chủ động qua ngắt mối khi dữ liệu đã sẳn sàng ở đầu ra ADC. Đối với nhận dữ liệu nối tiếp, thường dữ liệu đã có định dạng kiểu gói với số byte nhất định, việc nhận các byte liên tiếp phụ thuộc nhiều vào tốc độ thu/phát, có hay không có đối thoại và khi hệ lấy từ nhiều nguồn (cảm biến) dữ liệu theo kiểu polling, chi phí thời gian sẽ là vấn đề lớn. Đối với các CPU tốc độ cao, việc này có thể giải quyết được. Trong khi dùng ngắt, cần code ở mức thấp để nhận biết số hiệu vector ngắt, kích hoạt chương trinh xử lí ngắt (ISR). Dùng ngắt có thể nhận cả khung dữ liệu, nhanh hay chậm là do bên phát dữ liệu. Các UART hiện tại thể chạy tới 115000 kbaud và để thích ứng cần một FIFO nhận dữ liệu đủ lớn. Việc quản lí FIFO sao cho không bị tràn và hoạt động trôi chảy, đặc biệt với polling khi cần lưu nhiều mẫu dữ liệu từ nhiều nguồn. Khi viết code cho polling, cần debug để tránh các sự cố khi khai thác FIFO.
§ Một số lưu ý.
ü Sai số tính toán thời gian do phần mềm thực hiện thông qua các phép biến đỗi hệ cơ số (ví dụ đưa vào số hexa, tính toán là số nguyên …), sai số tích lũy khi làm tròn ở các phép tính số học. cascv chương trình dịch thường dùng các phương pháp tiệm
187
cận gần đúng nên sai số rất đáng kể. Để tránh sai số, cần thực nghiệm các giá trị cần có để nạp các thông số chuẩn cho các hàm tính toán thời gian.
ü Dữ liệu bị xáo trộn cũng có thể xảy ra. Vì vậy trước một chu trình lấy mẫu dữ liệu mới, cần làm sạch bộ đệm (FIFO), kích thước bộ đệm đủ lớn để tránh bị tràn dữ liệu, quản lí con trỏ vào bộ đệm phải thật chính xác, tránh bị đảo lộn thứ tự của dữ liệu. Các thao tác xóa, tái khởi động phải thực hiện đúng vị trí. Khi sử dụng bộ đệm FIFO như các hàng đợi gán cho các tác vụ riêng biệt, việc truy cập đọc/ghi phải chính xác ứng với các nguồn cung cấp (sensor+ADC+UART) dữ liệu vào.