ความล้มเหลวในการอ่าน / เขียน I2C ภายใต้ภาระการขัดจังหวะอย่างหนัก


10

ในระบบของฉันฉันใช้ I2C และฉันรู้ว่ามีภาระมากขัดจังหวะ (จากแหล่งอื่น ๆ ) การสื่อสาร I2C หยุดชะงักได้อย่างง่ายดาย นี่เป็นพฤติกรรมที่คาดหวังสำหรับ I2C หรือไม่ ฉันคาดว่าจะมีการโหลดอินเตอร์รัปต์ แต่ก็ยังใช้ได้เนื่องจาก I2C ไม่ใช่เวลาที่สำคัญสำหรับอินเตอร์เฟซที่สำคัญนาฬิกามีข้อมูล

ปรับปรุง:

โปรเซสเซอร์คือ STM32 อินเตอร์รัปต์เกิดจาก ADC ฉันไม่สามารถปิดการใช้อินเตอร์รัปต์ในระหว่างการอ่านเหตุการณ์ได้ดังนั้นฉันต้องหาวิธีแก้ปัญหาที่ทำให้การสื่อสาร i2c มีเสถียรภาพมากขึ้น STM32 เป็นอุปกรณ์ตัวหลักและตัวต่อเป็นอุปกรณ์อื่น (accelerometer)

Update2:

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


1
คำถามของคุณทั่วไปมากเพราะทุกอย่างขึ้นอยู่กับการออกแบบระบบของคุณ วิธีที่ I2C จัดการขึ้นอยู่กับอุปกรณ์บนบัสอย่างแท้จริง คุณสามารถเพิกเฉยต่อมันและเข้ามาภายหลังได้หรือไม่? ใน FPGA คุณสามารถออกแบบตรรกะเพื่อดูแลมากมายสำหรับคุณและหลีกเลี่ยงปัญหานี้ อีกครั้งเราต้องการข้อมูลเพิ่มเติมเกี่ยวกับไมโครคอนโทรลเลอร์และสิ่งอื่น ๆ ที่คุณมี โดยปกติแล้วทางออกที่ดีที่นี่คือการใช้ RTOS และออกแบบงานอย่างเหมาะสม
Gustavo Litovsky

สองสิ่งที่ควรมองหา Voltage ลดลงใน pullups หรือพลังงานกับ i2c master และ slave ของคุณหรือปัญหา emi หรือความจุ สำหรับการโหลดขัดจังหวะคุณหมายถึงว่าเจ้านายของคุณกำลังหยุดการขัดจังหวะหรือไม่? ชิปบางตัวจะไม่อนุญาตให้ยืดเวลาไม่สิ้นสุด
Passerby

@GustavoLitovsky คุณถูกต้อง แต่ 80% ของรอบการทำงานของ CPU กำลังให้บริการอินเตอร์รัปต์ ADC และไม่มีเวลาเพียงพอที่จะทำรอบการอ่านระหว่างหน้าต่างที่ไม่ใช่ ISR ดังนั้นการอ่านจะถูกขัดจังหวะไม่ว่าฉันจะออกแบบระบบปฏิบัติการดีแค่ไหน
Ktc

@Passerby คุณอาจพูดถูก ปัญหาหายไปเมื่อฉันแนบโพรบของตัววิเคราะห์เชิงตรรกะกับสายนาฬิกา
Ktc

มูลค่าปัจจุบันของคุณสำหรับการดึงขึ้นคืออะไร คุณลองเปลี่ยนเป็นค่าอื่นหรือไม่? (ลอง 10k หรือ 4k7 หรือ 2k เพียงแค่เดาคำแรก)
Tom L.

คำตอบ:


9

นี่เป็นปัญหาซอฟต์แวร์คุณใช้เวลามากเกินไปในการให้บริการขัดจังหวะและรูทีน I2C ของคุณไม่สามารถจัดการได้ (ดังนั้นจึงเป็นสองสิ่งที่ไม่ถูกต้อง) ฉันเคยผ่านสถานการณ์ที่คล้ายกันหลายครั้ง

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

ประการที่สอง: ตรวจสอบ DMA เพื่อทำให้สิ่งต่าง ๆ เป็นอัตโนมัติดังนั้นการขัดจังหวะของคุณจึงกลายเป็นกระบวนการอัตโนมัติเบื้องหลัง

ข้อที่สาม: ถ้า I2C มีความสำคัญให้ใส่นั่นในการขัดจังหวะด้วย แต่ให้แน่ใจว่าคุณได้จัดลำดับความสำคัญ!

ข้อที่สี่: หาสาเหตุว่าทำไมรูทีน I2C ของคุณถึงล้มเหลวตัว I2C ​​เองสามารถตั้งเวลาได้ไม่ต่อเนื่องหยุดชั่วคราวและรอเป็นต้นดังนั้นคุณอาจต้องแก้ไขเพื่ออนุญาต

ที่ห้า: ดูว่าคุณสามารถ "หยุด" การขัดจังหวะคุณอาจพบว่าคุณสามารถให้บริการ ADC อ่านได้อย่างมีประสิทธิภาพมากขึ้นหรือทำให้ ADC อยู่ในโหมดอื่นที่มันทำงานได้ดีกว่าสำหรับคุณก่อนที่จะขัดจังหวะ (EG รอให้การอ่านทั้งหมดพร้อมใช้งาน จากนั้นอ่านทั้งหมดในหนึ่งครั้งมากกว่า 8 อินเตอร์รัปต์แยกสำหรับการอ่านแชนเนล ADC 8 รายการ)

หก: ใช้ออสซิลโลสโคปหรือลอจิกวิเคราะห์และสำรองพิน IO บนบอร์ดเพื่อติดตามจำนวนเวลาที่คุณใช้ไปกับโค้ดแต่ละบิตเพื่อดูว่าคุณสามารถเร่งความเร็วได้หรือไม่ (ตั้งค่าพินสูงเมื่อคุณเข้าสู่ฟังก์ชั่น / ISR ตั้งค่าให้ต่ำลงอีกครั้งเมื่อออก)

ที่เจ็ด: ตัดสินใจว่าคุณจำเป็นต้องอ่าน ADC มาก ๆ จริง ๆ ไหมการทำให้ ADC ช้าลงจะทำให้สิ่งเลวร้ายลงหรือไม่ มันตอบโต้ได้ง่าย แต่บางครั้งการทำงานช้าลงจริง ๆ แล้วให้ผลลัพธ์ที่ดีกว่าการทำการเฉลี่ยสัญญาณให้คุณและลดการใช้ spikes / transients ซึ่งอาจทำให้เกิดปัญหาหรือต้องการการประมวลผลเพิ่มเติมเพื่อลบ เราปรับปรุงชุดคำสั่ง PID ควบคุมมอเตอร์โดยเพียงแค่เรียกใช้ความเร็ว 1/4 ซึ่งช่วยลดเวลาในการโหลด CPU ในกระบวนการ


ขอบคุณสำหรับคำแนะนำ ปัญหาชี้ไปที่ฮาร์ดแวร์
Ktc

4

ทาสบัสที่กำลังยุ่งอยู่กับสิ่งอื่นมีความสามารถในการยืดเวลาในการซื้อนาฬิกาจนกว่าจะสามารถสื่อสารได้ ทำได้โดยไม่ส่งพัลส์นาฬิกา ACK / NACK ทันทีทำให้การสื่อสารอยู่ในสถานะกลางจนกว่าจะพร้อมตอบ

การยืดนาฬิกาเป็นวิธีที่เหมาะสมในการจัดการกับสถานการณ์เช่นนี้ อุปกรณ์ที่ไม่ยืดและทำสิ่งเลวร้ายอื่น ๆ (บัสแฮงค์ / รีสตาร์ท NACKs ที่อยู่ที่ถูกต้องหรือคำสั่ง ฯลฯ ) อาจเป็นปัญหาได้และทำให้ภาระเพิ่มเติมเกี่ยวกับต้นแบบเพื่อแยกสิ่งต่าง ๆ ออก (มันต้องทำซ้ำคำสั่ง ติดตาม NACKs ฯลฯ )


คุณพูดถูก แต่ปัญหาคือโฮสต์ โฮสต์กำลังยุ่งกับสิ่งอื่นไม่ใช่ทาส ดังนั้นไม่แน่ใจฉันสามารถยืดนาฬิกาได้
Ktc

คุณใช้ฮาร์ดแวร์ I2C ของออนบอร์ดหรือกัดโปรโตคอลออกจากสาย GPIO หรือไม่? ไม่มีช่วงเวลาการหมดเวลา I2C เฉพาะที่กำหนดไว้ในมาตรฐานดังนั้นทาสควรรออย่างไม่มีกำหนดเพื่อให้ต้นแบบเสร็จสิ้นแพ็กเก็ต
อดัมอเรนซ์

ฉันใช้ STM32 IC2 APIs โปรดดูการปรับปรุงดูเหมือนว่าปัญหาความจุ
Ktc

1

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

  • การขัดจังหวะเพื่อสิ่งใดสามารถปิดใช้งานได้ มีอินเตอร์รัปต์ Non-Maskable ได้ไม่เกินหนึ่งหรือสองตัวในตัวควบคุมปกติใด ๆ ซึ่งหนึ่งในนั้นถูกรีเซ็ต หากคุณไม่ต้องการการควบคุมบางสิ่งบางอย่าง (ADC หรือ I2C ในกรณีของคุณ) ให้เปลี่ยนรหัสอุปกรณ์ต่อพ่วงนั้นเป็นรหัสที่ไม่ใช้การขัดจังหวะแล้วปิดใช้งานการขัดจังหวะ

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

  • หากคุณมีอุปกรณ์ต่อพ่วง DMA ให้ใช้สิ่งนั้นแทนการขัดจังหวะที่แต่ละไบต์ โดยทั่วไปแล้วจะเป็นการง่ายกว่าที่จะวาง ADC บน DMA ซึ่งตรงข้ามกับ I2C แต่ชิปที่แตกต่างกันมีการใช้งานที่แตกต่างกัน ฉันจะไม่แปลกใจถ้ามีวิธีที่สะอาดในการแลกเปลี่ยน I2C กับ DMA เช่นกัน DMA ช่วยให้คุณลดจำนวนการขัดจังหวะและทำให้แกนประมวลผลของคุณปลอดจากการจัดการกับข้อมูลทุก ๆ บล็อก

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

แก้ไข: หมายเหตุเฉพาะบางประการเกี่ยวกับปัญหานี้จากความคิดเห็นของคุณเกี่ยวกับคำถาม:

  • การมี CPU 80% ที่ใช้ในการอ่าน ADC มักจะไม่ใช่สิ่งที่คุ้มค่าที่จะทำ การรวบรวมข้อมูลนั้นไร้ประโยชน์หากคุณไม่สามารถดำเนินการต่อหรือแม้แต่บันทึกข้อมูล
  • แม้ว่าคุณจะกำลังรวบรวมข้อมูลจำนวนมาก (อย่างมีประโยชน์) การขัดจังหวะของ ADC ไม่ควรนานเท่าที่จะระงับอุปกรณ์ต่อพ่วง I2C ได้อย่างสมบูรณ์เป็นเวลานานพอที่จะทำให้ข้อมูลสูญหาย I2C ทำงานที่ความเร็วสูงสุด 100 / 400KHz คุณต้องการการขัดจังหวะที่ยาวนานและยาวนานเพื่อหยุดชะงักนานพอที่จะทำให้ดูเหมือนสิ่งที่ร้ายแรงยิ่งกว่าการสั่นสะเทือนของนาฬิกาบน I2C

ขอบคุณ ระบบของเราต้องการ ISR ที่ซับซ้อนและยาว ISR มันเป็นเรื่องยาว คุณพูดถูก I2C ต้องรักษาไว้แม้ในขณะที่อินเตอร์รัปต์โหลดไม่สามารถทำได้ ฉันสงสัยว่าปัญหาอยู่ในฮาร์ดแวร์ดูการอัปเดต
Ktc

สำหรับประสบการณ์ของฉันสิ่งที่คุ้มค่าในกรณีที่ใช้งานมากที่สุดซึ่งดูเหมือนว่าจะได้รับคำสั่ง ISR ที่ยาวอย่างไม่น่าเชื่อก็คือกรณีที่สมควรได้รับ RTOS และใช่ตามการแก้ไขล่าสุดของคุณดูเหมือนว่าปัญหาฮาร์ดแวร์ ลองใส่ตัวเก็บประจุขนาดเล็กในบรรทัดที่ตัววิเคราะห์ลอจิกของคุณอยู่และคุณอาจจะสบายดี ทำไมถึงเป็นสิ่งจำเป็น แต่ค่อนข้างยากที่จะตอบ ฉันจะตรวจสอบตัวต้านทาน pullup ของ I2C (อาจต่ำเกินไปสำหรับความจุบัสของคุณ) และตรวจสอบเอกสารข้อมูลทางเทคนิคของบัฟเฟอร์ I2C / ตัวทำซ้ำที่คุณอาจใช้
Chintalagiri Shashank

0

ในระบบที่กำหนดอาจมีเสียงดังเข้าสู่นาฬิกาและบัสข้อมูล ความจริงที่ว่าตรรกะของคุณ anlayser ลบปัญหาแสดงให้เห็นนี้ สำหรับการนำไปใช้งานจริงและรวดเร็วที่สุดให้ทำตามคำแนะนำที่คุณได้รับ บนบัส i2c ที่มีการใช้งาน 400kbits / วินาทีขึ้นอยู่กับการสังเกตที่คล้ายกันฉันเชื่อมต่อ 2M ขนานกับ 12pf กับพื้นจากจุดนาฬิกาและข้อมูลและพบว่าปัญหาได้รับการแก้ไขแล้ว สิ่งนี้จะลบ / กรองสัญญาณรบกวนนอกย่านความถี่ที่จำเป็นสำหรับการสื่อสาร i2c เฉพาะ กรุณาลองและให้คำแนะนำ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.