พฤษภาคม 20, 2019, 04:38:49 am *
ยินดีต้อนรับคุณ, บุคคลทั่วไป กรุณา เข้าสู่ระบบ หรือ ลงทะเบียน
ส่งอีเมล์ยืนยันการใช้งาน?

เข้าสู่ระบบด้วยชื่อผู้ใช้ รหัสผ่าน และระยะเวลาในเซสชั่น
   หน้าแรก   ช่วยเหลือ เข้าสู่ระบบ สมัครสมาชิก  
หน้า: [1] 2   ลงล่าง
  พิมพ์  
ผู้เขียน หัวข้อ: ต้องลึกแค่ไหน ถึงจะเรียกว่า "รู้แล้วจริง"  (อ่าน 14972 ครั้ง)
0 สมาชิก และ 2 บุคคลทั่วไป กำลังดูหัวข้อนี้
ShadowMan
Administrator
Hero Member
*****
ออฟไลน์ ออฟไลน์

เพศ: ชาย
กระทู้: 8272


ShadowWares


| |
« เมื่อ: พฤศจิกายน 28, 2011, 11:59:30 am »

ต้องลึกแค่ไหน ถึงจะเรียกว่า "รู้แล้วจริง"
คำถามยอดฮิตจากอีเมล์ผม และเช่นเคยเมื่อมีคนถามด้วยคำถามเดียวกันมากกว่า 5 ครั้ง ก็ได้เวลาแจกแจง
เริ่มกันที่วงจรพื้นฐาน (ใช่ พื้นฐาน ใครที่ไม่ได้เริ่มจากนี่ แสดงว่า อาาจะเริ่มที่อะไรที่เกินพื้นฐานไปแล้ว)




หากดูวงจรนี้ไม่ออก ตอบโจทย์ได้แล้วว่า "ยังต้องอ่านอีกเยอะ"
ถ้าดูออก ชี้ชัดว่าได้ก้าวข้ามผ่านด่านแรกมาแล้ว คราวนี้มาเริ่มกันที่คำสั่งง่ายๆ แบบนี้ก็แล้วกัน


เช่นเดิม หากไม่รู้ หรือเกิดความสงสัยเกี่ยวกับอักษร หรือคำใดๆ แม้แต่คำเดียวจาก code ด้านบนตอบโจทย์ได้แล้วว่า "ยังรู้ไม่พอ"

ก่อนทำการ Compile ผมได้กำหนดให้ Compiler รับรู้แล้วว่ามีหน่วยความจำอยู่ที่ Address ไหน ขนาดเท่าไร่
ใช่แล้ว ถ้ายังไม่เข้าใจประโยคนี้ ชี้ชัดว่า "ข้อมูลที่ได้ศึกษามายังไม่พอ"


จาก code ด้านบน มาดูสัญญาณที่ขาต่างๆ ที่เกี่ยวข้องกับ code ข้างบนกันก่อน



สัญญาณนี้เป็นสัญญาณที่มีให้เห็นใน datasheet ทั่วไป ชื่อของสัญญาณด้านซ้ายปรากฎอยู่ที่วงจรด้านบนอยู่แล้ว ถ้าไม่รู้ว่าแต่ละสัญญาณทำอะไร "ต้องศึกษาเพิ่ม"

แล้วแบบไหนล่ะที่จะนิยามได้ว่า  "รู้แล้วจริง" ? อันนี้ก็แล้วแต่จะนิยามกันเอาเอง ผมไม่สามารถนิยามให้ได้ เพราะผมไม่ใช่ผู้รู้จริง
แล้วสัญญาณข้างบนมันออกอะไร? ผมขอสรุปแบบสั้นที่สุด ดังนี้:
สัญญาณข้างบนมันบอกว่า x++ หรือ x = x+1 มันเกิดอะไรขึ้นกับ Data bus, Address bus และ Control bus ของ CPU โดยสรุปคือ

นี่คือจุดๆเดียว อย่างสรุป ยังไม่รวมปลีกย่อย เช่น เกิดอะไรขึ้นข้างในตัว CPU หรือ ทำไมต้องต่อ GATE ต่างๆแบบนั้น ทำไมต้องต่อวงจรแบบนั้น อันนี้ต้องพูดกันยาวในเรื่องของ System Design แต่ผมเชื่อว่ารายละเอียดทั้งหมดที่เกริ่นมา คงพอที่จะทำให้เจ้าของคำถาม มีคำตอบให้ตัวเองแล้วว่า "รู้แล้วหรือยัง?"
 wink

บันทึกการเข้า

By SDW: Do No Wrong Is Do Nothing
          If you want to increase your success rate, double your failure rate
the_hen
Newbie
*
ออฟไลน์ ออฟไลน์

กระทู้: 29


| |
« ตอบ #1 เมื่อ: พฤษภาคม 05, 2012, 09:06:32 pm »

 cheesyก็คงจะมีไห้อ่านพร้อมคำอธิบายที่เป็นภาษาไทยที่เข้าใจง่ายๆก็ที่นี่แหละครับ azn
บันทึกการเข้า
supachai_ps
Newbie
*
ออฟไลน์ ออฟไลน์

กระทู้: 12


| |
« ตอบ #2 เมื่อ: ตุลาคม 29, 2012, 03:11:26 pm »

ของผมทดลองจับสัญญาณดูได้ดังนี้


ผมเข้าใจว่าในตอนเขียนข้อมูลกลับ ตำแหน่งข้อมูลน่าจะคนละส่วนกลับตอนที่อ่านอ่ะครับ เพราะดูจากขา A6 ในเวลาที่มีการ WR จะมีการส่ง low order address นี้ไปด้วย ยังหาข้อมูลไม่เจอว่าในการอ่านและการเขียนข้อมูลลงใน mem ตัว compiler มีการจัดการยังไง เลยคิดว่ายังศึกษาไม่เพียงพอ
บันทึกการเข้า
ShadowMan
Administrator
Hero Member
*****
ออฟไลน์ ออฟไลน์

เพศ: ชาย
กระทู้: 8272


ShadowWares


| |
« ตอบ #3 เมื่อ: ตุลาคม 29, 2012, 10:16:54 pm »

เยี่ยมเลยครับ
เรื่องสัญญาณในระดับ Hardware นี้ Compiler ไม่ได้เป็นตัวจัดการครับ วงจรถายใน MCU ล้วนๆ
บันทึกการเข้า

By SDW: Do No Wrong Is Do Nothing
          If you want to increase your success rate, double your failure rate
supachai_ps
Newbie
*
ออฟไลน์ ออฟไลน์

กระทู้: 12


| |
« ตอบ #4 เมื่อ: พฤศจิกายน 09, 2012, 09:39:58 am »

สอบถามคุณ ShadowMan นิดนึงสิครับ
ไม่ทราบเคยทดลองบนโปรแกรม Proteus ให้ C32 อ่าน Code จาก External Rom หรือไม่ครับ




เนื่องจากผมทดลอง โดยไม่ใส่ hex file ใน C32 แต่ไปใส่ใน 27256 แทน ปรากฎว่ามันไม่ทำงาน พอไปอ่านใน help ของโปรแกรมพบว่า จะต้องระบุ program file ลงไปอย่างน้อย 1 ไฟล์ เลยงงๆ ว่าจริงแล้วเราสามารถรัน program file ที่อยู่ใน Rom ได้เลยหรือไม่

หรือมีท่านใดทราบหรือไม่ครับ รบกวนขอคำแนะนำหน่อย




บันทึกการเข้า
ShadowMan
Administrator
Hero Member
*****
ออฟไลน์ ออฟไลน์

เพศ: ชาย
กระทู้: 8272


ShadowWares


| |
« ตอบ #5 เมื่อ: พฤศจิกายน 09, 2012, 12:32:38 pm »

อ้างถึง
สอบถามคุณ ShadowMan นิดนึงสิครับ
ไม่ทราบเคยทดลองบนโปรแกรม Proteus ให้ C32 อ่าน Code จาก External Rom หรือไม่ครับ
เคยเล่นอยู่บ้างเมื่อนานมาแล้วครับ

อ้างถึง
เนื่องจากผมทดลอง โดยไม่ใส่ hex file ใน C32 แต่ไปใส่ใน 27256 แทน ปรากฎว่ามันไม่ทำงาน พอไปอ่านใน help ของโปรแกรมพบว่า จะต้องระบุ program file ลงไปอย่างน้อย 1 ไฟล์ เลยงงๆ ว่าจริงแล้วเราสามารถรัน program file ที่อยู่ใน Rom ได้เลยหรือไม่
การใช้งาน External Memory (ROM, EEPROM, SDCard, ...) จะต้องสร้างเป็น Image File ครับ
สำหรับ MCS-51 Family นั้น Proteus อนุญาตให้เราทำการกำหนด Memory Space ได้ครับ แต่ต้องเลือก Model ที่มีความสามารถดังกล่าวด้วย
บันทึกการเข้า

By SDW: Do No Wrong Is Do Nothing
          If you want to increase your success rate, double your failure rate
supachai_ps
Newbie
*
ออฟไลน์ ออฟไลน์

กระทู้: 12


| |
« ตอบ #6 เมื่อ: พฤศจิกายน 09, 2012, 02:33:24 pm »

ขอบคุณครับ เจอแระครับ อ่านไม่ครบถ้วนเอง  tongue
ผมต้องไปกำหนดคุณสมบัติ DBG_FETCH ให้มีค่าเป็น TRUE เพื่อให้มันไป Fetch โปรแกรมจากภายนอก ส่วนที่ตัว 27256 ผมไม่ได้แก้อะไรเพิ่ม เพราะเท่าที่อ่านดูแล้วพบว่าเวอร์ชั่นที่ผมใช้มันรองรับ image file ทั้งหมด 3 แบบ ซึ่งฟอร์มแมตแบบ HEX-80 ก็รองรับเช่นกัน เลยสบายไป



พอลองจำลองการทำงานก็สามารถทำงานได้แล้วครับ

บันทึกการเข้า
ShadowMan
Administrator
Hero Member
*****
ออฟไลน์ ออฟไลน์

เพศ: ชาย
กระทู้: 8272


ShadowWares


| |
« ตอบ #7 เมื่อ: พฤศจิกายน 10, 2012, 07:39:08 am »

ยินดีด้วยครับ  smiley
บันทึกการเข้า

By SDW: Do No Wrong Is Do Nothing
          If you want to increase your success rate, double your failure rate
supachai_ps
Newbie
*
ออฟไลน์ ออฟไลน์

กระทู้: 12


| |
« ตอบ #8 เมื่อ: พฤศจิกายน 11, 2012, 05:48:23 pm »

เห็นการ Fetch - external program memory แล้ว ทำให้เข้าใจการทำงานมากยิ่งขึ้นครับ



ผมสังเกตุว่าในช่วงเริ่มต้นการทำงาน MCU จะไปทำการ Fetch program จาก xROM มาก่อน จากนั้นจึงค่อยรันโปรแกรม แต่ผมยังไม่ได้ลองจับสัญญาณดูการทำงานทั้งหมด เพราะข้อจำกัดของเครื่องคอมฯ แต่ก็ทำให้พอเข้าใจ การทำงานในเบื้องต้น  ตามที่คู่มือของ Intel MCS51 หัวข้อ Program Memory กล่าวไว้ว่า

1. It emits the low byte of the Program Counter (PCL) as an address, and then
2. goes into a float state awaiting the arrival of the code byte from the Program Memory.
3. During the time that the low byte of the Program Counter is valid on P0, the signal ALE (Address Latch Enable) clocks this byte into an address latch.
4. Meanwhile, Port2 emits the high byte of the Program Counter (PCH). Then
5. PSEN strobes the EPROM and the code byte is read into the microcontroller.



ดูจากกราฟเทียบกับขั้นตอนการทำงาน ก็ชัดเจนว่าอุปกรณ์ทำงานอย่างไรในการ Executing from xProgram Memory
บันทึกการเข้า
ShadowMan
Administrator
Hero Member
*****
ออฟไลน์ ออฟไลน์

เพศ: ชาย
กระทู้: 8272


ShadowWares


| |
« ตอบ #9 เมื่อ: พฤศจิกายน 11, 2012, 10:48:13 pm »

ยอดเยี่ยมมากครับ
เจอนักศึกษาตัวจริงเข้าแล้ว !!
  smiley
บันทึกการเข้า

By SDW: Do No Wrong Is Do Nothing
          If you want to increase your success rate, double your failure rate
supachai_ps
Newbie
*
ออฟไลน์ ออฟไลน์

กระทู้: 12


| |
« ตอบ #10 เมื่อ: พฤศจิกายน 12, 2012, 06:03:34 pm »

ยอดเยี่ยมมากครับ
เจอนักศึกษาตัวจริงเข้าแล้ว !!
  smiley

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

อันที่จริงผมต้องขอบคุณคุณ ShadowMan และกลุ่มผู้สอบถามหลายๆ ท่านที่ตั้งหัวข้อกระทู้นี้ขึ้นมา ทำให้เกิดความอยากรู้อยากเห็นเพิ่มขึ้น เลยหยุดไม่ได้ที่จะต้องหาคำตอบให้ตัวเอง

ผมขอรายงานความคืบหน้าต่อนะครับ หลังจากสังเกตการณ์ Fetch program จาก xRom แล้ว พบว่ารูปแบบข้อมูลที่ Fetch มานั้นก็คือ Instruction Code ที่เก็บไว้ใน ROM แต่รูปแบบการ Fetch จะเป็นลักษณะ Fetch และประมวลผลคำสั่ง

สำหรับ Code ที่ใช้ในการศึกษานี้ก็ใช้ Code ชุดเดียวกับที่คุณ ShadowMan เขียนไว้ในตอนนั้นกระทู้ โดย Compile ด้วย Keil uVision 4 ซึ่ง C Compiler คือ C51 v9.50.0.0 และ Assembler คือ A51 v8.02b

ในตอนต้น Keil ได้มีการรวมเอา Startup เข้าไปไว้ในผลลัพธ์จากการ Compile ด้วย ซึ่งเมื่อดูไฟล์ Startup.lst จะำพบข้อมูลในส่วนต้นของโปรแกรม ดังนี้
Code:
----                 125                     CSEG    AT      0
0000 020000   F      126     ?C_STARTUP:     LJMP    STARTUP1
                     127     
----                 128                     RSEG    ?C_C51STARTUP
                     129     
0000                 130     STARTUP1:
                     131     
                     132     IF IDATALEN <> 0
0000 787F            133                     MOV     R0,#IDATALEN - 1
0002 E4              134                     CLR     A
0003 F6              135     IDATALOOP:      MOV     @R0,A
0004 D8FD            136                     DJNZ    R0,IDATALOOP
                     137     ENDIF

เมื่อนำข้อมูลจากกราฟมาเปรียบเทียบกับคำสั่ง



จะพบรูปแบบการ Fetch คำสั่งดังนี้ 02 00 03 78 78 7F E4 F6 F6 D8 D8 FD 90 90 F6 หรือเรียงใหม่

1) 02 0003  ==> LJMP  0003        ; 2 cycles

2) 78           ==> MOV   R0, XXX   ;    <== เข้าใจว่า Fetch แต่คำสั่งก่อนหน้ายังประมวลผลไม่เสร็จ

3) 78 7F      ==> MOV   R0,#7F  ; เนื่องจากค่าของ IDATALEN คือ 80h;  1 cycle
4) E4           ==> CLR    A ; 1 cycle
5) F6           ==> MOV   @R0, A ;  1 cycle 
6) F6           ==> MOV   @R0, A ;    <=== เข้าใจว่า Fetch คำสั่งนี้มาก่อนหน้าแล้ว แต่ประมวลผลไม่เสร็จจึง Fetch มาประมวลใหม่อีกครั้ง

7) D8          ==> DJNZ  R0, XXXXX
8) D8 FD    ==> DJNZ  R0, IDATALOOP ;  2 cycles
9) 90          <== เข้าใจว่า Fetch มาแต่ยังประมวลผลคำส่งเดิมไม่เสร็จ
10) 90          <== เข้าใจว่า Fetch มาแต่ยังประมวลผลคำส่งเดิมไม่เสร็จ
11) F6          ==> MOV  @R0, A  <=== พอประมวลผลเสร็จหลังจากทำการ Decrease แล้วจึง Jump ไปที่ตำแหน่งของ IDATALOOP ซึ่งก็คือตำแหน่งคำสั่ง MOV @R0, A


ทั้งนี้ ผมเองยังไม่มั่นใจว่าที่เข้าใจเกี่ยวกับการ Fetch ซ้ำนั้นถูกต้องหรือไม่ แต่เมื่อมองรูปแบบการ Fetch แล้วจะพบว่าจะวนตามคำสั่งที่แสดงข้างต้น ถ้าได้ลองจับทั้งสัญญาณและค่า Register ในตัว MCU ได้โดยแสดงหน่วยเวลาเดียวกันได้ คงจะแจ๋วกว่านี้ครับ น่าจะช่วยทำให้เข้าใจได้ง่ายขึ้น


 
บันทึกการเข้า
ShadowMan
Administrator
Hero Member
*****
ออฟไลน์ ออฟไลน์

เพศ: ชาย
กระทู้: 8272


ShadowWares


| |
« ตอบ #11 เมื่อ: พฤศจิกายน 13, 2012, 10:25:28 am »

ต้องขอชื่นชมในความตั้งใจครับ

เพื่อความชัดเจนทั้งเชิงเวลา และสัญญาณในระดับบิต มากยิ่งขึ้น ผมแนะนำให้ใช้เครื่องมือสำหรับการ Debug ของ Proteus ครับ สั่งรันที่ละคำสั่งในระดับ ASM ได้เลย ตรงนี้รับรองได้เลยครับว่าจะได้รับความชัดเจนรอบด้าน



บันทึกการเข้า

By SDW: Do No Wrong Is Do Nothing
          If you want to increase your success rate, double your failure rate
supachai_ps
Newbie
*
ออฟไลน์ ออฟไลน์

กระทู้: 12


| |
« ตอบ #12 เมื่อ: พฤศจิกายน 14, 2012, 12:52:47 pm »

ขอบคุณมากครับ

อันที่จริง ผมได้ลอง Debug และเทียบดูไปบ้างแล้วครับ เห็นคำสั่งและค่าต่างๆ ภายใน MCU เป็นอย่างดี แต่เมื่อมาเทียบกับค่าของสัญญาณ Logic ที่จับได้จาก Data bus ก็เลยลังเลนิดๆ แต่คิดว่าไม่ผิดไปจากที่คิดไว้มากครับ

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

ตัวอย่างเช่น

Code:
     ORG   0000H
     LJMP  MAIN

MAIN:    ......
         ......
         LCALL   <Label>
   
 

แต่บางคนก็

Code:
     ORG  0000h
     JMP  MAIN

MAIN:     ......
          ......
          ACALL  <Label>



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

ยังไงถ้าเริ่มตกผลึกความเข้าใจและจะมารายงานให้ทราบครับ
บันทึกการเข้า
ShadowMan
Administrator
Hero Member
*****
ออฟไลน์ ออฟไลน์

เพศ: ชาย
กระทู้: 8272


ShadowWares


| |
« ตอบ #13 เมื่อ: พฤศจิกายน 14, 2012, 02:47:57 pm »

ที่เหลือก็เจาะรายลบะเอียดกันเป็นตัวๆ ไปครับ


บันทึกการเข้า

By SDW: Do No Wrong Is Do Nothing
          If you want to increase your success rate, double your failure rate
supachai_ps
Newbie
*
ออฟไลน์ ออฟไลน์

กระทู้: 12


| |
« ตอบ #14 เมื่อ: พฤศจิกายน 14, 2012, 10:04:20 pm »

ขอบคุณมากครับ


ผมค่อนข้างถูกใจตารางนี้มากเลยครับ ทำให้นึกถึง 8051 Micro-Reference Manual ของ ETT พอดีเพิ่งไปซื้อมา เล่มเล็กพกติดตัวดูได้เลย


ด้านในมีตารางแบบเดียวกันเลยครับ ส่วนลิงค์ของ Keil นี่ Useful มากๆ เลยครับ ช่วยให้เข้าใจได้ง่ายขึ้นเยอะ ขอบคุณอีกครั้งครับสำหรับ Resource ที่เตรียมให้ แค่นี้ก็เริ่มต้นได้สบายมากขึ้นแล้วครับ
บันทึกการเข้า
หน้า: [1] 2   ขึ้นบน
  พิมพ์  
 
กระโดดไป: