การตั้ง timer ทำให้งานที่ต้องเรียกเป็นระยะดูจัดการง่ายขึ้น เราระบุช่วงเวลาแล้วให้ callback ทำงานเมื่อครบกำหนด แต่การมีตัวนับละเอียดไม่ได้หมายความว่าโค้ดใน callback จะได้เริ่มตรงจังหวะเดียวกันทุกครั้ง
ระหว่างเวลาถึงกำหนดกับโปรแกรมเริ่มทำงานยังมีขั้น dispatch และทรัพยากรที่ต้องใช้ หาก callback ตัวหนึ่งทำงานยาว หรือระบบมีงานสำคัญกว่าอยู่ จังหวะที่อีกตัวได้รันก็อาจต่างจากเวลาที่ตั้งไว้
จึงควรแยกว่าต้องการนับเวลา เรียกงานภายหลัง หรือสร้างสัญญาณทางกายภาพครับ ข้อกำหนดต่างกันทำให้คำว่า timer ที่เหมาะอาจเป็นคนละกลไก
ESP Timer ของ ESP-IDF รองรับ software timer แบบ one-shot กับ periodic และมีวิธี dispatch ตามที่ตั้งค่า ในแบบที่ส่งงานให้ ESP Timer task การเรียก callback จะทำเรียงกัน ไม่ได้เปิดให้ทุก callback วิ่งอิสระพร้อมกันเอง
ถ้าตัวแรกใช้เวลานาน ตัวที่อยู่ถัดไปก็ต้องรอ และงานอื่นที่มี priority สูงกว่าสามารถทำให้ task นี้ยังไม่มีโอกาสรันได้ ความละเอียดของตัวนับจึงต่างจากความคลาดของเวลาที่โค้ดเริ่มจริง
ตัวอย่างสมมติคือ callback สำหรับปรับหน้าจอไปอ่านเครือข่ายที่ตอบช้า แล้ว timer อีกตัวสำหรับตรวจสถานะต้องรออยู่ข้างหลัง แม้ตั้ง period สั้นไว้ การเปลี่ยนตัวเลข period ของตัวหลังอย่างเดียวก็ไม่ได้เอาการรอในตัวแรกออก
ก่อนกล่าวว่า timer ไม่ตรง ควรแยกเวลาเป้าหมาย เวลาเข้า callback และเวลาจบงานหลัก หากเก็บเพียงเวลาหลังส่งข้อมูลสำเร็จ เราอาจรวมเวลารอเครือข่ายเข้าไปแล้วโทษกลไกนับเวลาผิดจุด
เอกสาร ESP Timer แนะนำให้ callback สั้น และส่งงานที่มากกว่านั้นไป task ที่เหมาะสมผ่านกลไกของ FreeRTOS แทนการ block หรือ yield ภายในทาง dispatch ที่ต้องเรียงกัน
การส่งต่อยังต้องบอกว่างานแต่ละครั้งมีความหมายอย่างไร หาก callback แค่แจ้งว่าได้เวลาตรวจข้อมูลล่าสุด การรวมสัญญาณบางช่วงอาจเป็นนโยบายที่ยอมรับได้ แต่ถ้าต้องเก็บทุกเหตุการณ์ ต้องมีทางรักษาข้อมูลที่เกิดจริงและความจุที่เพียงพอ
Queue ช่วยแยกผู้เรียกกับผู้ทำ แต่ไม่ได้เพิ่มความเร็วให้ผู้รับเอง ต้องตรวจผลส่งคิวและนโยบายเมื่อเต็มด้วย ไม่ทำ callback ให้สั้นด้วยการโยนงานออกไปแล้วทิ้งหลักฐานว่าผู้รับยังตามไม่ทัน
หากใช้ interrupt dispatch กติกาของบริบทก็เปลี่ยนไป ต้องใช้ API กับวิธีขอให้ task ทำงานตามที่ ESP-IDF ระบุ ไม่ย้าย callback ที่มี mutex หรือการรอจาก task ไป ISR เพียงเพื่อหวังให้ latency ลดโดยไม่ดูว่าเรียกฟังก์ชันเหล่านั้นได้หรือไม่
ระหว่าง light sleep ตัวนับกับ callback ของ ESP Timer ถูกพักตามกลไก และหลังตื่นระบบชดเชยช่วงเวลาที่หลับจาก RTC ก่อนกลับมาทำงาน จึงอาจมี periodic timeout หลายรอบที่ผ่านไประหว่างไม่ได้ dispatch
ตามพฤติกรรมปกติที่เอกสารอธิบาย ระบบพยายาม dispatch callback ที่ยังไม่ได้จัดการเมื่อกลับมา หากมีจำนวนมากก็อาจสร้างงานค้างต่อเนื่องหลังตื่น แทนที่จะเริ่มรอบใหม่อย่างที่แอปคาดไว้
ESP Timer มีทางเลือกอย่างหยุด timer ก่อนหลับ หรือใช้ skip_unhandled_events ตามสัญญาของ periodic timer เพื่อไม่เรียกทุกช่วงที่ข้ามมา ต้องเลือกจากความหมายของงาน ไม่เปิดข้ามทุกอย่างเพื่อให้คิวว่างแล้วถือว่าข้อมูลยังครบเหมือนเดิม
ที่สำคัญ การเรียก callback หลายครั้งหลังตื่นไม่ได้ย้อนกลับไปวัดอุณหภูมิในช่วงที่หลับ หาก task ไปอ่านเซนเซอร์สดตอนนั้นหลายรอบ ผลก็ยังเป็นการอ่านหลังตื่น ต้องไม่ใส่เวลาเป้าหมายเก่าให้ดูเหมือนมี sample จริงครบช่วงย้อนหลัง
หลัง deep sleep แอปเริ่มทำงานใหม่ และ ESP Timer เดิมไม่ได้ดำเนินต่อราวกับ process ไม่เคยหยุด หากต้องจำกำหนดงานข้ามรอบ ต้องมีข้อมูลกับการฟื้นสถานะที่ออกแบบไว้ภายนอกตัว timer นั้น
จึงควรแยกหน้าที่ว่า timer ใน boot ปัจจุบันเป็นเพียงเครื่องมือปลุกงานภายในรอบ ส่วนกำหนดที่ต้องรักษาข้ามรอบเป็นข้อมูลของแอป ซึ่งต้องมีฐานเวลาที่ใช้ได้และสถานะว่างานยังมีผลหรือไม่
การบันทึก handle หรือค่าตัวนับก่อนหลับโดยไม่รู้ขอบเขตหลังตื่นไม่ได้ฟื้นกลไกเดิมให้ใช้ต่อ ต้องสร้างและตั้งค่าตามวงจรชีวิตที่ API รองรับ แล้วตรวจว่ามีการเรียกซ้ำงานที่ทำเสร็จหรือถูกยกเลิกไปแล้วหรือไม่
หากต้องกำเนิด pulse หรือรับขอบสัญญาณด้วยเงื่อนไขเวลาที่เข้ม การใช้ software callback ทุกครั้งอาจไม่เหมาะ ควรพิจารณา peripheral เช่น GPTimer หรือ RMT ตามความสามารถของชิปและรูปแบบงาน แทนการเพิ่ม priority ไปเรื่อยๆ
การใช้ hardware ก็ยังต้องออกแบบ clock การป้อนข้อมูลและ buffer ให้ตรง ไม่ได้ให้ผลดีที่สุดอัตโนมัติเพียงเพราะเปลี่ยนชื่อ API ควรระบุข้อกำหนดที่ต้องวัด เช่น ความคลาดของขอบหรือช่วงขาด แล้วเก็บจากอุปกรณ์จริงก่อนรับรองผล
ตัวเลขความละเอียดหรือค่าประมาณในเอกสารเป็นเงื่อนไขของระบบที่เอกสารระบุ ไม่ใช่ผลวัดจากบอร์ดของเรา การเลือกกลไกจึงต้องมีการตรวจภายใต้ภาระที่ใช้จริง เช่น มีงาน flash หรือเครือข่ายร่วมด้วยตามโครงการ
ชุดตรวจควรมีหลาย timer ทำงานร่วมกัน callback ที่ส่งต่อแล้วผู้รับทำช้า และการกลับจาก sleep โดยเก็บจำนวนครั้งกับเวลาเข้าทำงานตามฐานเดียวกัน จะได้เห็นว่าความคลาดเกิดก่อน dispatch หรือในงานปลายทาง
ไม่ควรเพิ่ม log หนักในบริบทที่กำลังตรวจจนมันกลายเป็นต้นเหตุใหม่ เลือกหลักฐานที่พอผูก deadline การเข้า callback และผลของงาน แล้ววิเคราะห์นอกช่วงเวลาที่ต้องการรักษาเมื่อเหมาะสม
Timer ช่วยกำหนดว่าเมื่อไรควรมีงาน แต่เวลาที่ callback รันขึ้นกับวิธี dispatch ภาระและวงจร sleep เมื่อแยกงานสั้นที่รับจังหวะออกจากงานหนัก พร้อมนโยบายรอบที่พลาด เราจะใช้ timer ได้ตรงหน้าที่และรักษาความหมายของข้อมูล โดยไม่เอาจำนวน callback หลังตื่นไปแทนสิ่งที่ไม่ได้วัดในอดีต