พื้นฐานการวิเคราะห์ digital image

การจัดการรูปภาพโดย คอมพิวเตอร์ เราใช้ algorithm ในการปรับแต่งภาพและเลือกเอาข้อมูลที่ต้องการบางข้อมูลที่เป็นประโยชน์ออกมาใช้

 

วิธีการมีสามแบบ

  1. นำเข้ารูปภาพ
  2. วิเคราะห์จัดการรูปภาพ
  3. แสดงผลของรูปภาพที่เปลี่ยนแปลงและรายงานผลการวิเคราะห์

 

อะไรคือภาพ

ภาพกำหนดด้วยสองมิติรูปแบบ function F(x,y) ที่ x และ y พิกัดพืื้นที่ และ F คืิอความหนาแน่นของจุดในภาพ เมือ x,y มีค่าเป็นแอมพลิจูดของ F มีค่าจำกัด เราเรียกว่า digital image

บ้างก็ว่า รูปภาพสามารถกำหนด array สองมิติ จัดเรียงอยู่ในรูปแบบแถวและคอลัม ประกอบด้วยตัวเลขที่จำกัดแต่ละสมาชิกมีค่าที่เกี่ยวข้องกันอ้างอิงเป็น pixel

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

เปรียบเทียบกับภาพจริงที่ขยายเห็น Pixel

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ชนิิดของภาพมีดังนี้

  1. Binary Image pixel มีค่าแค่สองค่า 0 และ 1 0 คือดำ 1 คือขาว เรียกว่า MonoChrome
  2. Black and white image ประกอบด้วยสีดำและขาวเท่านั้น เรียก white and black image
  3. 8 bit color image ประกอบด้วยสีที่แตกต่างกัน 0-255 แบบ 0 คือสีดำ 255 คือสีขาว 127 คือสีเทา ที่รู้จักกันในแบบ grayscale image
  4. 16 bit color image ประกอบด้วยสีที่แตกต่างกัน 65536 แบบ high color format รูปการกระจายสีไม่เหมือน grayscale 16 bit ใช้จริงจะแบ่งอีกสามรูปแบบ คือ แดง เขียว ฟ้า RGA format

                                       

                                   

โดยทั่วไปนำเสนอและคำนวณโมเดลคณิตศาสตร์ในรูป matrix

 

                                                                              

บทนำ

     พูดอย่างกว้างๆ คุณสามารถแบ่งภาษาได้สี่กลุ่ม ต่ำสุดคือ machine code จำนวนตัวเลขดิบๆ ที่สามารถถอดรหัส ชุดคำสั่งได้และทำงาน หนึ่งก้าว คือ assembly มีความจำเป็นต่อ machine code แต่ละคำสั่งของ assembly พิจารณาเป็นหนึ่งชุด machine code ทั้งหมดที่กล่าวเหมือนโปรแกรมที่ compile แล้วของภาษา C  C ใช้โครงสร้างภาษาที่มนุษย์ สามารถอ่านได้เหมือนภาษาอังกฤษ แต่ต้อง compile เป็น machine code เพื่อรัน สุดท้ายมีภาษา script อย่างเช่น PHP เหมือน VB JAVA  มี interpreter ปรับแต่งละรัน machine code ที่ถูกต้อง

    ทุกๆความก้าวหน้าเป็นผลดีต่อความเข้าใจและเป็นภาษามนุษย์ที่อ่านได้และยึดหยุ่น การใช้เวลารันและขนาดโปรแกรมในสมัยเก่าโปรแกรมเมอร์คือผู้ควบคุมโปรแกรมจริงๆทำและให้ machine code ทำงานได้ตามข้อจำกัดของ clock speed และ memory สำหรับ PC ถูกจัดการและทำงานได้โดยองค์ประกอบของภาษาระดับสูง เป็นสิ่งที่ดีเพราะเขียนได้รวดเร็วและจัดการง่าย

อย่างไรก็ตาม ภาษาระดับสูง ข้อจำกัดบางอย่างที่ยังไม่สามารถทำได้เพียงพอ Gameboy ด้วย CPU 16.7MHz RAM น้อยกว่า 1MB ทำงานได้ภาษาสูงอาจจะไม่มีประสิทธิภาพเพียงพอ ไม่สามารถรันได้ทั้งหมด ทำไม Gameboy ทำได้งานใน C/C++ บางครั้งด้วยความเสน่หาเรียกภาษานี้ว่า portable assembly เพราะมันสามารถเข้าถึง memory ได้โดยตรง แต่ยังมีบางอย่างที่ไม่เพียงพอ จริงๆถ้าคุณต้องการจะทำทุกๆอย่างตามการนับ cycle ของ CPU อาจจะตัองการใช้ assembly ในการเขียน

   ตอนนี้ในบางกลุ่มเรียก assembly คือภาษาโปรแกรมที่เล็กที่สุด เพราะใกล้ชิดและผูกกับ CPU คุณสามารถทำได้ทุกอย่าง และต้องจัดการทุกอย่างทั้งหมด คุณอยู่ใกล้ hardware คุณสามารถลัดขั้นตอนคุณสมบัติที่ป้องกันความปลอดภัยของภาษาระดับสูงได้ อาจจะทำงานง่ายต่อการทำลายและอันตรายมากขึ้น เหมือนอยู่ในโลกของการผจญภัย

    โปรแกรม assembly คุณต้องรู้และเข้าใจว่า CPU ทำงานอย่างไรถึงจะเขียนโปรแกรมได้ มากกว่าการแปลผลจาก complier และ interpreter ไม่มีโครงสร้าง while loop หรือ กิ่ง if/else มีแค่ goto ไม่มีโครงสร้างคลาสและการสืบทอด ไม่มีแปลชนิดข้อมูล สิ่งเหล่านี้ทำให้ code สามารถรันได้เร็วทีสุดเท่าที่เป็นไปได้

   ความเร็วและขนาดโปรแกรมเป็นประเด็นหนึ่ง ไม่มีเหตุผลอื่นที่ว่าทำไมไม่เรียนรู้ assembly เพราะสามารถทำได้ดี สามารถอธิบายให้คุณทราบการทำงานของ CPU function และคุณสามารถใช้ความรู้ในภาษาซีได้เหมือนกัน ตัวอย่างที่ดีทีสุดของชนิดของข้อมูลคือ int เพราะ ARM processor คือ32 bit ถูกให้ใช้มากกว่าทุกๆสิ่ง เพราะชนิดข้อมูลอื่นจะช้าลง และบ้างครั้งช้ามาก เป็นพื้นฐานของ CPU และความรู้ทางภาษา assembly จะแสดงให้ว่าทำไมช้าลง

   ทุกอย่างๆ ที่เกี่ยวกับบทนี้ เอกสารแนะนำที่เกี่ยวกับ assembly ที่สมบูรณ์ คงหนีไม่พ้น คู่มือ CPU ฉบับเต็ม สิ่งสำคัญอยากให้เน้นไปที่ชุดคำสั่ง ARM และ Thumb รวมไปถึงอยากให้ดูการใช้งาน GCC assembler เครื่องที่สามารถสร้าง C และ assembly ไปพร้อมๆกัน เอกสารที่เตรียมศึกษามีดังต่อไปนี้

ทำความรู้จัก CPU ทางกายภาพ 

สรุปชุดคำสั่งของ Thumb และ ARMแบบคร่าวๆ

ชุดคำสั่งหลัก GAS /ARM/ Thumb2

คู่มือการใช้ GNU assembler

  หลายคนอาจจะงงว่า ทำไม ARM มี ชุดคำสั่ง Thumb ด้วย จุดมุ่งหมายของชุดคำสั่ง Thumb เป็นรูปพิเศษบีบอัดชุดคำสั่งให้น้อยลง เพื่อให้ opcode ที่ใช้ใน memory น้อยลง ลดการเปรียบเทียบลงในแต่ละคำสั่งของการทำงาน มีหลายแบบแตกต่างกันไปตามสถาปัตยกรรม series ของ ARM อาทิ เช่น Thumb Thumb2  ThumbEE ส่วนชุดคำสั่ง ARM นั้นเป็นคำสั่งทั่วไปของ ARM

  ปกติแล้วใน CPU จะมีส่วนสำคัญคือ register หน่วยความจำที่ไว้พักข้อมูลอ่านเขียนเร็วที่สุด เพื่อใช้คำนวณ ส่วน ALU คือหน่วยประมวลทางคณิตศาสตร์  หลักการรันชุดคำสั่งสรุปได้ดังแผนภาพ

ความสำคัญของปัญหา

ด้วยsoftwareที่มีการเปลี่ยนแปลงรวดเร็ว ทำให้ระบบจัดการโปรเจคแบบปกติ ไม่สามารถทำต่อไปได้อีก นั่นก็หมายความว่า มือโปทางด้าน ไอที ต้องหาหนทางใหม่เพื่อจัดการกับงานพัฒนาที่มีการเปลี่ยนแปลงบ่อยๆ

 

การนำเสนอที่เน้นไปในทางการเพิ่มการพัฒนาทางด้านเทคนิค 17 ผู้เชี่ยวชาญทางด้าน software แนะนำให้ใช้ agile development ในปี 2001 ทฤษฎีที่ยึดหยุ่นรวดเร็วการรวมศูนย์กลางความร่วมมือการพัฒนา software กลายข้อสรุปสั้นๆที่เรียกว่า agile manifesto

 

software engineering ken back แนะนำ Xp-programmingในปี 1990 จุดมุ่งหมายเพื่อเพิ่มคุณภาพของการพัฒนา software ได้อย่างรวดเร็ว รองรับการเปลี่ยนแปลงของลูกค้าในปี 1999 ได้มีการกำหนด xp ในหนังสือ extreme programming explained embrace change

 

คุณค่าและทฤษฤีของ Extreme Programming มีกฎพื้นฐานที่ง่ายห้าอย่างดังนี้

 

การติดต่อสื่อสาร(communication) ทุกคนของทีมทำงานร่วมกันต้องมีการติดต่อสื่อสารกันทุกขั้นตอนของโปรเจค

ความเรียบง่าย (simplicity) นักพัฒนามุ่งมั่นที่จะเขียน code ง่ายๆแต่สามารถให้คุณค่าแก่ผลิตภัณฑ์ และประสิทธิภาพของเวลาที่ใช้น้อยลง

ข้อเสนอแนะ (feedback) นักพัฒนาต้องปล่อย software บ่อยๆ เพื่อดูการตอบรับและเพื่อปรับปรุงผลิตภัณฑ์ตามความต้องการใหม่

ความเคารพ (respect) ทุกคนกำหนดให้เป็นผู้แนะนำเกี่่ยวกับโปรเจค เพื่อจุดมุ่งหมายความสำเร็จเดียวกัน

ความกล้าหาญ (courage) Programmer มีจุดประสงค์เพื่อประเมินผลในตัวเองโดยปราศจากข้อแก้ตัวและพร้อมจะเปลี่ยนแปลง

 

ค่านิยมดังกล่าวนี้จะช่วยให้ทีมมีแรงจูงใจไปถึงเป้าหมายได้และสะท้อนให้เห็นอย่างเป็นรูปธรรมมากขึ้น

 

นักพัฒนาวิจัยเห็นคุณค่าของ 5 ค่าของ XP ดังนี้

rapid feedback (การตอบสนองรวดเร็ว )สมาชิกของทีมต้องเข้าใจว่าให้ทำอะไร และต้องตอบสนองให้ถูกต้อง

Assumed simplicity (กำหนดให้ง่าย) นักพัฒนาต้องมุ่งเน้นงานที่สำคัญในขณะนั้น ตามรูปแบบ YAGNI (You aren’t Gonna Need It) จะไม่เพิ่ม function ใน source code เมื่อมันไม่มีความจำเป็นต้องทำ don't repeat yourself (DRY) จะไม่ประมวลข้อมูลที่เหมือนกันและการทำกระทำแบบเดียวกันช้ำๆหลายครั้ง ควรใช้ข้อมูลชุดเดียวหรือ functionชุดเดียวในการประมวลผลของโปรแกรมในจุดมุ่งหมายเดียวกัน

Incremental changes (การเพิ่มการเปลี่ยนแปลง) ค่อยเปลี่ยนแปลงที่ละเล็กๆน้อยๆ เพือให้ผลิตภัณฑ์ดีขึ้น ดีกว่าทำทีเดียวให้ดีทั้งหมด

Embracing change (เกาะติดการเปลี่ยนแปลง) ถ้าลูกค้าต้องการจะเปลี่ยนรูปแบบผลิตภัณฑ์ programmer ควรให้การสนับสนุนการติดสินใจนี้ว่าควรวางแผนและนำไปใช้อย่างไร

Quality work (คุณภาพของงาน) ทีมควรทำงานร่วมกันได้ดี สร้างคุณค่าผลิตภัณฑ์และมีความรู้สึกภาคภูมิใจในผลงาน

 

Extreme Programming ในทางปฎิบัติ

XP นำเสนอแนวทางปฎิบัติ 12 แบบ นักพัฒนาปฎิบัติตามทฎษฎีและค่่านิยม มีแนวทางปฎิบัติจริงจะแบ่งออกได้เป็นสี่กลุ่ม

 

feedback (การตอบกลับ)

Test driven development :เป็นได้ไหมว่าที่จะเขียน code ให้ดูรวดเร็วเข้าใจง่าย ตอบได้เลยว่าได้ ตามหลักของ XP software ต้องมีคุณภาพและควรพัฒนาเป็นช่วงสั้นๆ และปล่อย software บ่อยๆ เพื่อดูการตอบรับ การมีการตอบรับเข้ามาเป็นสิ่งดีที่สำหรับการทดสอบ ทีม XP ควรฝึกการเขียน TDD (test driven development) เป็นการเขียน unit-test แบบอัตโนมัติก่อนเขียน code จริง เพื่อแน่ใจว่าทุกส่วนของ code ผ่านการทดสอบก่อน ปล่อย software ออกมา ดังนั้น นักพัฒนาควรรออกแบบ function ที่ต้องการให้สามารถทดสอบได้ TDD จึงเป็นหนทางที่สามารถทดสอบการตอบกลับของ function software ได้ทันทีและสร้างผลิตภัณท์softwareที่เชื่อถือได้

 

The Planing game (เกมวางแผน): นี่เป็นการประชุมเกี่ยวการเริ่มการพัฒนาของทีม และลูกค้าเข้ามาช่วยอภิปรายและปรับปรุงคุณสมบัติของผลิตภัณฑ์ ในตอนท้ายของเกมวางแผนทีมต้องกำหนดงานแผนการพัฒนาในคุณสมบัติต่างและช่วงเวลาการปล่อย software กำหนดงานที่จะทำในแต่ละอย่าง

 

onsite-customer(อยู่กับลูกค้า) ตามหลัก XP ลูกค้าควรมีปฏิสัมพันธ์เต็มรูปแบบตลอดการพัฒนา และให้คำตอบของสถานะปัจจุบันตลอดเวลา ระบุความสำคัญ แก้ไขข้อขัดแย้งตามความจำเป็น

 

pair programming (จับคู่่เขียนโปรแกรม)ในทางปฎิบัติ เป็นการทำงานร่วมเขียน code เดียวกัน คนแรกเน้นการขียน code คนที่สองเน้นให้แนะนำ และปรับปรุงและแก้ไข ข้อผิดพลาดระหว่างทาง ผลของทีมคือได้งานที่มีคุณภาพ มีการแชร์ความรู้ที่รวดเร็ว ใช้เวลา 15 ถึง 60 % หรือมากกว่า ตามการพิจารณาระยะยาว วิธีการนี้น่าจะเหมาะโปรเจคที่มีเวลาพัฒนายาวนาน

 

continual process (การดำเนินการที่ต่อเนื่อง)

code refactoring การส่งคุณค่าทางธุรกิจ การออกแบบที่ดีในทุกๆขั้นตอน ทีม XP ยังสามารถใช้ refactoring จุดมุ่งหมายของเทคนิคเพื่อปรับปรุงcode Refactoring จะลบการทำซ้ำๆ ลบ function ที่ไม่จำเป็น เพิ่มความสอดคล้องของ code ในเวลาเดียวกันสามารถแยกองค์ประกอบ รักษา code ให้สะอาด และดูง่าย ดังนั้น codeจะง่ายต่อความเข้าใจและแก้ไขมันได้เมื่อสมาชิกทุกคนในทีม XP แนะนำให้แก้ไข

 

continuous Integration (การดำเนินการต่อเนื่องและรวมกันทั้งหมด) นักพัฒนาต้องรักษาระบบรวมแบบเต็ม XP ทีมอาจจะมีการวนการพัฒนาไปในหลายระดับการ commit code หลายครั้งต่อวัน จะต้องปล่อย software ได้อย่างต่อเนื่อง ผู้ปฎิบัติXP ต้องเข้าใจความสำคัญของการสื่อสาร โปรแกรมเมอร์อภิปรายส่วน code ที่สามารถนำกลับมาใช้ใหม่และแชร์ แนวทางนี้ต้องรู้ว่า function อะไรเป็นฟังก์ชันที่ต้องการจริงๆในการพัฒนา นโยบายการแชร์ code จะช่วยลดปัญหาที่เกิดซ้ำ อีกทางเพิ่มการทดสอบอัตโนมัติใน code จะช่วยให้นักพัฒนาสามารถค้นหาและแก้ไขข้อผิดพลาดได้ทัน ก่อนที่จะนำไปใช้งาน

 

small releases (ปล่อยทีละน้อยๆ) ในทางปฎิบัติแนะนำว่าควรปล่อย version แรกให้เร็วที่สุด และเพิ่มเติมการพัฒนาของผลิตภัณฑ์ทีละน้อยๆ และปล่อย software ออกมาบ่อย จะได้มีการตอบรับจากในกลุ่มนักพัฒนาบ่อยๆ สามารถตรวจสอบบัคได้ในตอนแรกๆ และสามารถดูการทำงานได้ของผลิตภัณฑ์ หนึ่งในวิธีการทำคือ วิธีการก่อนหน้านี้ที่กล่าวมา CI (continuous integration practice)

 

 

code understanding (ความเข้าใจ code)

Simple Design (ออกแบบง่ายๆ) การออกแบบที่ดีที่สุดของ software คือง่ายที่สุดและทำงานได้ ถ้ามีความซับซ้อน มันควรจะลบออกไป การออกแบบที่ถูกต้องควรผ่านการทดสอบทั้งหมด ไม่มีการทำ code ซ้ำ มีส่วน class และ method น้อย และแสดงเจตนาการทำงานของโปรแกรมชัดเจน

 

ผู้ร่วมงาน xp เน้นการออกแบบง่ายๆ หลังจากที่ได้ผลิตผลิตภัณฑ์มาระยะหนึ่งแล้ว Don well แนะนำการเขียน code ตามคุณสมบัติที่ได้วางแผนไว้มากกว่าสร้างคุณสมบัติต่างๆไว้รอในอนาคต วิธีการที่ดีที่สุดคือสร้าง code เฉพาะที่คุณใช้เท่านั้น ขณะนั้นคุณต้องค้นหาความรู้เพียงพอที่จะออกแบบให้ง่ายที่สุด จากนั้นค่อย refactor เรื่อยๆ จนนำไปใช้ทำเป็นความเข้าใจใหม่และออกแบบ

 

Coding standards ทีมต้องมีจิตสำนักทั่วไปในการตั้งค่า code ที่นำไปใช้ ใช้รูปแบบเดียวกับของการเขียน application เป็นมาตราฐานให้ทีมสามารถอ่าน แชร์และ refactor code ได้อย่างง่ายดาย เพื่อให้คนที่ติดตาม code ปัจจุบัน สามารถเรียนรู้ได้รวดเร็วที่สุด สำหรับ โปรแกรมมือคนใหม่ code ที่เขียนของมีกฎการเขียนถือครองเหมือนกัน

 

Collective Code Ownership (การถือครอง code ร่วมกัน)

แนวทางปฎิบัตินี้ประกาศว่าทีมต้องมีความรับผิดชอบในการออกแบบระบบ โปรแกรมเมอร์แต่ละคนต้องสามารถทบทวน และปรับปรุง code นักพัฒนาต้องสามารถเข้าถึง code โดยปราศจากความไม่รู้ว่าสิ่งไหนคือคุณสมบัติใหม่ที่เพิ่มเข้าไป การกระทำนี้ช่วยหลีกเลี่ยงการทำ codeที่ซ้ำกัน การนำ code ถือครองทั้งหมดไปใช้ จะกระตุ้นให้ทีมมีความร่วมมือกันมากขึ้นและรู้สึกอิสระนำมาซึ่งความคิดใหม่ๆ

 

System metaphor(อุปลักษณ์ของระบบ)

อุปลักษณ์ของระบบยืนอยู่บนความง่ายของการออกมีปริมาณคุณลักษณะที่แน่นอน ประการแรก ออกแบบ โครงสร้างต้องสามารถเข้าใจได้กับบุคคลใหม่ๆ คนเหล่านั้นไม่ควรจะใช้เวลามากไปสำหรับการเริ่มงานและตรวจสอบสเปค ประการที่สอง ชื่อของ class และ method ควรจะเชื่อมโยงกัน นักพัฒนาควรตั้งชื่อ object ถ้ามันมีอยู่แล้วควรทำออกแบบระบบทั้งหมดให้เข้าใจได้

 

Programmer’s work conditions

40 ชั่วโมงต่อสัปดาห์ xp โปรเจค ต้องการนักพัฒนาที่ทำงานเร็วและมีประสิทธิภาพ รักษาคุณภาพของผลิตภัณฑ์ เพื่อให้ได้ผลตามกำหนด นักพัฒนาได้พักผ่อนและรู้สึกดี รักษาความสมดุลระหว่างความเป็นมือถืออาชีพกับการทำงานไม่หนักเกินไป ใน xp จำนวนที่ดีทีสุดของชั่วโมงการทำงานไม่ควร 45 ชั่วโมงต่อสัปดาห์ ทำงานล่วงเวลาในหนึ่งสัปดาห์เท่านั้นไม่ควรจะมีในสัปดาห์ต่อมา

 

เมื่อไหร่ควรใช้ XP

สิ่งที่สำคัญคือต้องแน่ใจเกี่ยวกับขนาดของบริษัท เจ้าที่เชี่ยวชาญที่จะนำ XP ไปใช้ควรคำนึงถึงปัจจัยสำคัญต่างๆดังต่อไปนี้

มีการเปลี่ยนการพัฒนาค่อยข้างสูง Xp จะให้ทีมสามารถจัดการเปลี่ยนที่รวดเร็วของความต้องการลูกค้าได้

Risky projects โปรเจคที่มีความเสี่ยง ทีมสามารถนำไปใช้หลีกเลี่ยงปัญหาที่เกิดขึ้นจากเชื่อมต่อระบบงานใหม่ๆโดยเฉพาะผลิตภัณท์ที่มีการกำหนดวันส่งงานอย่างเข้มงวด

ทีมเล็กๆ เพื่อความมีประสิทธิภาพทีมไม่ควรเกิน 12 คน

มีการทดสอบแบบอัตโนมัติ ปัจจัยอื่นที่ทำให้ นักพัฒนาสามารถสร้างและรัน unitest ได้

ลูกค้าสามารถมีปฎิสัมพันธ์ได้ ต้องแน่ใจว่าลูกค้ามีเวลาเขามาจัดการและสังเกตการณ์ จนจบโปรเจคได้

อะไรคือ RTOS(ระบบปฎิบัติการตามเวลาจริง)

RTOS มาจากสองคำ RT กับ OS

(Real time) Real time เวลาจริง หรือเวลาตามความเป็นจริง ระบบที่ตอบสนองต่อการตอบรับสัญญาณหรือคำสั่งงานภายนอกที่มีกำหนดขอบเขตของเวลาที่จำกัดแน่นอน

(OS )operating system โปรแกรมระบบที่จัดสรรการเข้าถึงระหว่าง hardware กับ application โดยมีคุณสมบัติทั่วไปดังนี้

  • Multitasking

  • synchronization

  • Interrupt และ event handing

  • Input/Output

  • Inter-task communication

  • Timer และ Clock memory management

ทั้งหมดนี้เพื่อตอบสนองตามความต้องการทั้งหมดที่ใช้ใน application program

ดังนั้น RTOS คือระบบปฎิบัติการที่สนับสนุนการทำงานของ application ตามเวลาจริง ที่สามารถกำหนดขอบเขตของจุดสิ้นสุดเวลาและทรัพยากรของระบบ

ทำไมต้องเป็น application ที่ทำงานตามเวลาจริง

RTOS ไม่ได้ต้องการ application ตามเวลาจริงทั้งหมดในระบบ Embedded system Embedded system ในหม้อหุ้งข้าว อิเล็กทรอนิค ไม่ได้ต้องการ RTOS แต่เป็นเพราะความต้องการการใช้งานที่ซับซ้อนของ application ที่เกี่ยวกับงานต่างๆ ที่ต้องการเวลาที่แน่นอน จึงต้องมี RTOS นำไปใช้ในงาน อาทิเช่น ควบคุมเครื่องจักร เครื่องบิน ยานอวกาศ ฯลฯ

embedded system มีการพัฒนาระบบ hardware ที่ซับซ้อนในทุกรุ่น มีคุณสมบัติที่ถูกใส่เข้าไปมากขึ้น application program ที่รันใน embedded system จึงต้องมีการเพิ่มควาซับซ้อนมากขึ้นตาม hardware RTOS เป็นระบบปฎิบัติการเวลาจริงถูกออกแบบและอธิบายการใช้งานได้ตามรูปภาพด้านล่าง

 

การแบ่งกลุ่มของ RTOS

RTOS แบ่งออกได้สามชนิดคือ

 

Hard-real time

ระบบที่กำหนดเวลาการตอบสนอง การตอบสนองหากเกินกว่าหรือเท่ากับเวลาที่กำหนดไว้ระบบจะเสียหาย

 

Firm-real time

ระบบที่กำหนดเวลาการตอบสนอง หากการตอบสนองเกินกว่าเวลาที่กำหนด ระบบไม่สามารถยอมรับ คุณภาพระบบลดลง

 

Soft-real time

ระบบที่กำหนดเวลาการตอบสนอง หากการตอบสนองเกินกว่าเวลาที่กำหนด ระบบสามารถยอมรับได้ คุณภาพระบบลดลง และสามารถเรียกคืนระบบกลับได้

 

ความเข้าใจผิดเกี่ยวกับ RTOS

RTOS ต้องเร็ว

การตอบสนองของ RTOS ขึ้นอยู่การกำหนดพฤติกรรมของการประมวลผล ความสามารถของ RTOS ที่จะต้องสนองขึ้นกับการกำหนดเวลาภายใน ไม่ได้หมายความว่าต้องเร็ว

 

กล่าวว่า RTOSใช้ CPU เกินขีดจำกัด

RTOSโดยปกติมีความต้องการใช้ CPU 1%-4% ของCPU time

 

RTOS ทั้งหมดเหมือนกัน

RTOS ถูกออกแบบในสามชนิดของ ระบบปฎิบัติการเวลาจริง hard firm soft อาจจะมีเพิ่มเติมในส่วนของชนิดของ hardware 8 bit 16 bit 32bit MPU

 

คุณสมบัติของ RTOS

RTOS ออกแบบตามความจำเป็นของ application และความต้องการตามเหตุผล ตามการพัฒนาและการนำไปใช้ ตามความต้องการให้สามารถทำนายเวลาที่ต้องการใช้ตอบสนองได้ พื้นฐาน RTOS จะมีเครื่องมือดังต่อไปนี้

 

multitasking และ Preemptibility (ทำได้หลายงานและมีการขัดจำหวะได้)

RTOSต้องทำงานหลายๆงานพร้อมกันและสามารถขัดจังหวะใน real-time application การจัดการต้องมีการขัดจังหวะงานที่ทำอยู่ได้ เมื่องานนั้นมีภาระที่ต้องทำให้เร็วที่สุด

 

Task priority (ลำดับความสำคัญของงาน)

การขัดจังหวะถูกกำหนดความต้องการ โดยกำหนดงานที่ความสำคัญสุงสุด จะให้ยึดถือครองทรัยากรณ์ของระบบได้มากที่สุด ใน RTOS ภาระงานถูกกำหนดตามงานเฉพาะและระดับที่เหมาะสม ดังนั้นเครื่องมือนี้ถือว่าเป็นเครื่องมือที่สำคัญ

 

Reliable และ Sufficient Inter Task Communication Mechanism (ความเชื่อถือได้ของความสามารถเพียงพอสำหรับการติดต่อสื่อสารกันระหว่างงาน)

สำหรับในหลายงาน ต้องการติดต่อสื่อสารกันทันเวลา และแน่ใจว่าข้อมูลสามารถรวมเข้ากันได้และการตอบสนองกันตามจังหวะเวลาที่เหมาะสมตามความต้องการ

 

Priority Inheritance (การสืบทอดความสำคัญของงาน)

เพื่อใช้งานได้ตามระดับความสำคัญของงาน RTOS ต้องมีจำนวนระดับความสำคัญที่เพียงพอกับการจัดการงาน

 

Predefine short Latencies (การกำหนดสถานะเมื่อเกิดความล่าช้า)

RTOS ต้องมีความแม่นยำของกำหนดเวลาสั้นๆที่ใช้ใน system call มีพฤติกรรมดังนี้

 

Task switching Latency

เวลาที่ต้องบันทึกสถานะงานปัจจุบันก่อนไปทำงานอื่น

 

Interrupt latency

เวลาของงานที่ถูกขัดจังหวะครั้งหลังสุด ถึงการเริ่มขัดจังหวะ

 

Interrupt dispatch latency

เวลาจากการรันท้ายสุดของการขัดจังหวะถึงก่อนที่จะไปงานถัดไป

 

Control of Memory Management

เพื่อให้แน่ใจว่าสามารถทำนายพฤติกรรมของการขัดจังหวะได้ RTOS ควรมีการล็อคงานที่ทำอยู่ code และ data ที่อยู่ใน memory จริง

 

RTOS Architecture

สถาปัตยกรรมของ RTOS ขึ้นอยู่กับเรานำไปใช้งาน RTOS ที่ต้องสามารถปรับให้เข้ากับความแตกต่างของการนำไปใช้งาน ยกตัวอย่าง application ง่ายๆ RTOS ประกอบด้วย Kernel ความซับซ้อนของ library ที่รวมใน kernel ขึ้นอยู่กับการนำไปใช้งานต่างๆ ยกตัวอย่างเช่น network protocol stack

และส่วนประกอบอื่นๆ ตามภาพ

 

 

ระบบปฎิบัติการประกอบด้วยสองส่วน kernel space (kernel mode )และ User space (User mode)

kernel เป็นส่วนที่เล็กที่สุดและเป็นศูนย์กลางของระบบปฎิบัติการมี service ในการจัดการ memory และ device และยังช่วยในการจัดการการเชื่อมต่อระหว่าง software และทรัพยากร hardware อาจจะมี service เพิ่มเติมของ program ในการจัดการเรื่อง multi-tasking ขึ้นอยู่กับการสถาปัตยกรรม hardware

มีสามรูปแบบ

Monolithic kernel

Service พื้นฐานของระบบทั้งหมดทุกอย่างอยู่ใน kernel space อาทิเช่นmemory management ,interrupt handling และ I/O communication file system และอื่น monolithic kernel มีประสิทธิภาพในส่วนการจัดการข้อความติดต่อการระหว่าง hardwareได้เร็ว ทำให้มีความสามารถในการรันได้เร็วกว่า micro kernel นำไปใช้ใน Linux และ Window

Microkernel

รันโดยระบบพื้นฐานของการติดต่อการด้วย process ส่งข้อความเพื่อควบคุม I/O file system และ network อยู่ใน user space ในรูปแบบของ daemon server ดังนั้น micro kernel จึงเล็กในเรื่องของการเข้าถึง hardware และมีความเสถียรมากกว่า monolithic kernel ไม่ผลกระทบหาก server ล้มเหลว ยกตัวอย่าง เมื่อใช้ file system ใน server ถูกนำไปใช้ใน AmigaOS และ QNX

Exokernel

เป็นรูปแบบผสมระหว่าง micro กับ monolithic kernel ให้ application ควบคุม hardware รันเฉพาะ service เท่านั้นที่ปกป้องทรัพยากรเท่านั้น เช่นการ สิทธิ์การเป็นเจ้าของ การปัองการใช้ การเข้าถึง ทรัยากรและอื่น และยกเลิกการจัดการของ applicationโดยใช้ Lowel level libraryสำหรับระบบปฎิบัติการ (libOSes)

 

โดยปกติ RTOS จะหลีกเลี่ยงการใช้ Kernel ที่มีขนาดใหญ่อย่าง monolithic program kernel จะใช้ micro kernel แทนที่เพราะสามารถตั้งค่าตามรูปแบบที่ต้องการ การใช้แบบนี้จะมีผลดีเพราะสามารถตั้งค่าในแต่ละ embedded application ที่ต้องการได้

kernel ของ RTOS จะมีส่วนประกอบต่างๆ ที่ใช้เกี่ยวกับ application กับ hardwareเจ็ดอย่างหลัก ตามรูป

Task management (การจัดการงาน)

ตัวจัดการงาน ให้ Programmer สามารถออกแบบ software ตามจำนวนของการแยกของ chunk (Heap memory management )เพื่อจัดการจุดมุ่งหมายและจุดเส้นตายของงาน service นี้ใช้ในตัวจัดการงาน (scheduler)

Task object

เพื่อให้งาน Real-time applicationทำงานได้ application ถูกแบ่งเป็นส่วนเล็กๆ scheduler และลำดับของหน่วย program ที่เรียกว่า task ในรูปแบบของ real-time มีพื้นฐานการรัน มีรูปแบบเวลาที่สำคัญสามแบบ

release time: เวลาก่อนงานเริ่ม

deadline time: เวลาที่งานต้องสมบูรณ์

execution time เวลาที่รันงานรัน

ใน task object มีการกำหนดดังนี้

task control block โครงสร้างข้อมูลของงานที่อยู่ภายใน RAM เข้าถึงโดย RTOS

โครงสร้างของ TCB

 

task stack ข้อมูลที่อยู่ในโปรแกรม RAM เข้าถึงโดย stack pointer

task routine คือ program code ที่อยู่ใน ROM

การรันงานใน CPU จะมีแค่หนึ่งงาน เมื่อ cpu กำลังทำงานอยู่แล้วเปลี่ยนไปทำงานอื่นจะมีการบันทึกสถานะถ้างานนั้นยังทำไม่เสร็จและเรียกคืนรายละเอียดทั้งหมดเพื่อทำงานต่อ เรืยกว่า context switchingแต่ละงานที่รันมีสี่สถานะ

  • running CPU กำลังรันงานนั้นอยู่

  • ready รองานการขัดจังหวะจากงานที่ลำดับสำคัญสูงกว่ารันอยู่

  • dormant งานสร้างขึ้นรอไว้แต่ไม่เปิดใช้งาน

  • blocked งานที่หยุดรอการกระตุ้นจากการ event ภายนอก

    Scheduler(ตัวจัดการงาน)

    การจัดตารางงานจะบันทึกสถานะของแต่ละงานเพื่อเลือกนำงานที่พร้อมรันเข้าใช้ใน CPU schedulerจะช่วยให้การใช้ CPU มีประโยชน์สุงสุด ในหลายรูปแบบการทำงาน multi-tasking ที่การสูญเสียเวลาการรอน้อยที่สุด โดยปกติ scheduler มีสองรูปแบบ

    Non-preemptive คือจัดการงานแบบ multi-tasking โดยเรียงคิวเข้าทำงาน งานใหม่ที่มีความสำคัญมากต้องรองานปัจจุบันให้เสร็จก่อนจึงรันต่อไป

     


     

    preemptive มีการขัดจังหวะและหยุดพักงานปัจจุบันได้เมื่องานลำดับความสำคัญใหม่เพิ่มเข้ามาเมื่อเสร็จแล้วกลับไปทำงานก่อนหน้าจนเสร็จ

     

      

Task Synchronization (การประสานข้อมูลของงาน)

การประสานข้อมูลมีความสำคัญในใช้ทรัพยากรร่วมกัน อย่างเช่น device หรือ buffer การให้ task หลายๆ ถูกรัน ยกตัวอย่าง Task A ต้องผลจาก Task B ดังนั้น Task A สามารถรันจนกระทั้ง Task B ทำให้ผลให้ A ประสานข้อมูลมีสองรูปแบบ

Event object 

ประสานข้อมูลกันโดยไม่ใช้ทรัพยากรร่วมกัน ใช้ในหนึ่งงานหรือมากกว่า กำหนดการรอ event ที่เกิดขึ้น Task object ที่มีอยู่มีสองสองสถานะกระตุ้นกับไม่ถูกกระตุ้น ขึ้นกับการกำหนดว่าตั้งค่าให้ถูกกระตุ้นหรือไม่ถูกกระตุ้นการหยุดรอ event ที่เกิดขึ้น เมื่อ event สถานะเปลี่ยนแปลงจึงรันต่อไป

 

การใช้ข้อมูลร่วมกันหลังการกระตุ้นอาจไม่ดีพอ task A ยังไม่ประมวลผลเสร็จ task B เข้าประมวลซ้ำทำให้ข้อมูลเสียหายได้ RTOS จึงมี service semaphore ที่เป็นการรองรับข้อมูลที่ใช้ร่วมกันอีกแบบ

semaphore คือการเข้าถึงทรัพยากรด้วยการนับรอคิว การนับเป็นการบอกว่าทรัพยากรสามารถเข้าถึงได้ตามการรอคิวของ semaphore semaphore เป็น function ที่ใช้เป็น key ในการเข้าถึง resource ที่ต้องการ มีวิธีการนับ semaphore สามรูปแบบ

binary semaphore (ค่าsemaphore =0 หรือ 1 ให้เข้าถึงได้และไม่ได้)

counting semaphore (ค่า semaphore=0 หรือมากกว่า สามารถได้รับและปล่อยให้เข้าถึงได้หลายๆ ครั้ง)

mutually exclusion Semaphore ( ค่าsemaphore =0 หรือ 1 , ล็อคคือ 0 และมากกว่า 0 คือล็อคแบบวนซ้ำ)

 

 

Intertask communication (การติดต่อสื่อสารระหว่างงาน)

 

การติดต่อกันระหว่างจะใช้ข้อมูลที่แชร์ระหว่างหน่วยความจำสื่อสารข้อมูลได้ในสามรูปแบบ

  • Message queues
  • Pipes
  • Remote procedural call (RPC)

 

message queues เป็น object ที่ใช้ติดต่อสื่อสารระหว่างงานที่มีการส่งรับรับข้อความถูกวางใน shared memory งาน และ ISRs จะส่งและรับข้อความผ่านคิวใน kernel งานจะมองหาข้อความจากคิวที่ว่างและระยะเวลาจนกระทั่งได้รับข้อความ การส่งข้อความและรับมีรูปแบบคิวดังต่อไปนี้

1 First in First Out (FIFO) ข้อมูลมาก่อนเข้าก่่อน ข้อมูลมาก่อนออกก่อน

2 last in Fist out (LIFO) ข้อมูลมาที่หลังเข้าก่อน ข้อมูลมาก่อนออกก่อน

3 Priority sequence (PRI) ตามลำดับความสำคัญ

โดยปกติ การเปรียบเทียบข้อความ เรียกว่า queue control block(QCB) มีรายละเอียดข้อมูล คือ ชื่อ , ID เฉพาะ,memory buffer,ขนาดความยาวมากที่สุดต่อข้อความ บางทีหนึ่งงานหรือรอมากกว่าหนึ่งงาน message queue จะมีขนาดของคิวเท่ากับ 1 หรือที่รู้จักกันว่าเป็น mailbox

 

Pipes เป็น object เป็นสื่อสารแบบท่อไม่มีโครงสร้างของข้อมูล แลกเปลี่ยนกันระหว่าง task , pipes สามารถเปิด ปิด เขียน อ่าน เป็นท่่อสตรีมข้อมูล ไม่มีโครงสร้างข้อมูลเหมือน message queue อ่านผ่าน pipe เป็นแบบ FIFO การไหลของข้อมูลไม่สามารถจัดการลำดับความสำคัญได้

 

Remote procedural call (RPC) เป็นส่วนประกอบที่อนุญาตให้มีการกระจายข้อมูล การคำนวณระหว่างกันได้เกี่ยวกับ รันงานอื่นในเครื่องคอมพิวเตอร์ remoteเครื่องอื่นงานเดียวกับเครื่องคอมพิวเตอร์ที่ใช้

 

Memory management (การจัดการหน่วยความจำ)

โดยปกติ RTOS ออกแบบใช้ความจำที่น้อยตามความจำเป็นของ user application จะมี memory สองชนิดที่มีการจัดการใน RTOSคือ Heap และ stack

ในงาน multi-tasking จะจองหน่วยความจำแต่ละงานต้องการเก็บ context ของตัวเอง (สถานะของตัวเอง) เรียกว่า TCB task control block ดังที่กล่าวมาแล้วในหัวข้อ task management ใช้เก็บข้อมูล เช่น ค่าregister program counter ฯลฯ สำหรับ context switching กลุ่มของ memory นี้เรียกว่า kernel stack กระบวนการจัดการ memory เหล่านี้เรียกว่า stack management

เมื่อโปรแกรมเริ่มรันสมบูรณ์ program code program data และ system stack โหลดลงใน physical memory ของ MPU หรือ MCU ที่เหลือเป็น heap memoryเพื่อให้ kernel ได้จองหน่วยความจำของข้อมูลที่จะใช้ในงาน แบ่งขนาดตายตัวเป็น block สามารถเลือกใช้ได้ เมื่อสิ้นสุดงาน memory ส่วนนี้จะถูกปล่อยคืนสู่่ระบบ กระบวนการนี้เรียกว่า heap management

 

Timer management (การจัดการเวลา)

ในระบบ embedded system งานที่ผู้ใช้ บ่อยครั้งการจัดการงานจะทำ หลังจากกำหนดช่วงเวลาแล้ว การจัดการงาน ต้องการขัดจังหวะเป็นช่วงๆ เพื่อรักษาช่วงเวลาที่กำหนดเลยไปและจุดสิ้นสุนเวลา RTOS กำหนดหน่วย timer ที่เกี่ยวกับหน่วยเวลา มีหน่วยเป็น tick และ “absolute time” เป็นเวลาของปฏิทินในแต่ละ ชนิด timer task delay service หรือ อาจเรียกว่า task alert service จะมีการกลไกส่งสัญญาณเพื่อบอกสถานะของ event Timer service อื่นก็จะหาจุดเวลาที่พบกันของงานภายใต้ จุดสิ้นสุดเวลาที่กำหนด เพื่อพิจารณาความเป็น real-time

 

Interrupt และ event handing (จัดการงานเมื่อมีการขัดจังหวะ)

การขัดจังหวะของ hardware ใช้เพื่อแจ้ง CPU เกี่ยวกับ ว่ามีเหตุการณ์ไม่ตรงกันเกิดขึ้น พื้นฐานที่ท้าทายของ RTOS ต้องออกแบบให้สนับสนุนการขัดจังหวะ การเข้าถึงที่ไม่ตรงกันของการเข้าถึงโครงสร้างข้อมูลภายใน RTOS การจัดการขัดจังหวะ มีกลไกการจัดการดังต่อไปนี้

  • กำหนดงานเกี่ยวกับการจัดการขัดจังหวะที่มีเข้ามา
  • สร้างและลบเส้นทางของการขัดจังหวะ (ISR)
  • อ้างอิงใหม่เกี่ยวกับสถานะของเส้นทางการขัดจังหวะ(ISR)
  • เปิดและปิดใช้งานของการขัดจังหวะ
  • เปลี่ยนแปลงแล้วอ้างอิงใหม่เกี่ยวกับ interrupt mask (mask bit เพื่อไม่รับการขัดจังหวะได้ )

เพื่อให้แน่ใจว่า

ความสมบูรณ์ของข้อมูลที่ประมวลผลอยู่หลังจากเกิดการขัดจังหวะ

ความล่าช้าสั้นที่สุดของการปิดใช้งานการขัดจังหวะในกรณีที่ RTOSต้องทำงานที่สำคัญที่สุดก่อน

การขัดจังวะที่เป็นไปได้เร็วที่ใช้ทดสอบ ประสิทธิภาพ preemptive ของ RTOS

ระยะเวลาการขัดจังหวะที่สั้นที่สุดที่เป็นไปได้และใช้ CPUต่ำสุด

 

Device I/O management (การจัดการอุปกรณ์ input และ output)

RTOS kernelมีเครื่องมือที่ไว้จัดการ device I/O serviceเป็น รูปแบบframework ให้ใช้ตาม application programmer ‘s interface -API

เพื่อการจัดการระบบอุปกรณ์ hardware จำนวนมาก อย่างไรก็ตาม driver API ทั้งหมดส่วนที่เป็นตัวจัดการสูงสุดจะเป็นไปตามรูปมาตราฐานตาม RTOS กำหนด