এমবেডেড ও IoT ডিজাইনের সাধারণ ভুল

১ · volatile ভুলে যাওয়া (cross-ref মডিউল ৩/L09)

মডিউল ৩-এ শেখা হয়েছিল — একটি পেরিফেরাল রেজিস্টার বা হার্ডওয়্যার-স্পর্শ করা ভ্যারিয়েবলের মান কম্পাইলারের "পেছন থেকে" বদলে যেতে পারে (একটি ইন্টারাপ্ট বা বাহ্যিক হার্ডওয়্যার সেট করে দেয়)। volatile ছাড়া কম্পাইলার ধরে নিতে পারে ভ্যারিয়েবলটি নিজে থেকে বদলাবে না, আর তাই একবার রেজিস্টারে র‍্যাম/CPU-তে ক্যাশ করে পরবর্তী প্রতিটি রিডে সেই পুরনো মানই ব্যবহার করতে পারে — একটি স্টেল (বাসি) ভ্যালু বাগ। এই ভুলটি বিশেষভাবে বিপজ্জনক কারণ এটি প্রায়ই কম্পাইলার অপ্টিমাইজেশন লেভেল বদলালে (যেমন ডিবাগ বিল্ডে না দেখা দিয়ে রিলিজ বিল্ডে হঠাৎ দেখা দেওয়া) আবির্ভূত হয় — টেস্টিং-এ ধরা কঠিন।

# L09-এর volatile ধারণাটি এখানে "সাধারণ ভুল" হিসেবে পুনরায় দেখানো হচ্ছে

class HardwareRegister:
    """সিমুলেটেড হার্ডওয়্যার রেজিস্টার -- বাইরের হার্ডওয়্যার/ইন্টারাপ্ট যেকোনো সময় এর মান বদলে দিতে পারে"""
    def __init__(self):
        self.status_flag = 0

    def hardware_tick(self, tick, ready_at_tick):
        # রিয়েল হার্ডওয়্যার ঠিক ready_at_tick টিকে ফ্ল্যাগ সেট করে দেয় (যেমন একটি সেন্সর রেডি হওয়ার সংকেত)
        if tick == ready_at_tick:
            self.status_flag = 1


def poll_without_volatile(hw, ready_at_tick, max_ticks=20):
    """বাগযুক্ত -- volatile ছাড়া কম্পাইলার একবার রিড করে লোকাল ভ্যারিয়েবলে ক্যাশ করে রাখতে পারে বলে ধরা হচ্ছে"""
    cached_flag = hw.status_flag   # একবারই রিড হলো -- এরপর আর কখনো আসল রেজিস্টার রিড হচ্ছে না
    log = []
    for tick in range(max_ticks):
        hw.hardware_tick(tick, ready_at_tick)
        if cached_flag == 1:
            log.append((tick, "READY (cached)"))
            return tick, log
        log.append((tick, "not ready (cached, stale)"))
    return None, log


def poll_with_volatile(hw, ready_at_tick, max_ticks=20):
    """সঠিক -- volatile থাকলে কম্পাইলার প্রতিবার মেমরি থেকে আসল মান রিড করতে বাধ্য থাকে"""
    log = []
    for tick in range(max_ticks):
        hw.hardware_tick(tick, ready_at_tick)
        current_flag = hw.status_flag   # প্রতি ইটারেশনে সত্যিকারের রিড
        if current_flag == 1:
            log.append((tick, "READY (re-read)"))
            return tick, log
        log.append((tick, "not ready (re-read)"))
    return None, log


READY_AT_TICK = 7

hw_buggy = HardwareRegister()
detected_tick_buggy, log_buggy = poll_without_volatile(hw_buggy, READY_AT_TICK)

hw_ok = HardwareRegister()
detected_tick_ok, log_ok = poll_with_volatile(hw_ok, READY_AT_TICK)

print(f"হার্ডওয়্যার আসলে রেডি হয়েছে tick={READY_AT_TICK}-এ\n")

print(f"volatile ছাড়া (বাগযুক্ত) পোলিং -- শনাক্ত হওয়া tick: {detected_tick_buggy}")
for t, msg in log_buggy:
    print(f"  tick {t}: {msg}")

print(f"\nvolatile সহ (সঠিক) পোলিং -- শনাক্ত হওয়া tick: {detected_tick_ok}")
for t, msg in log_ok:
    print(f"  tick {t}: {msg}")

২ · ডিবাউন্স উপেক্ষা করা (cross-ref মডিউল ৪/L15)

মডিউল ৪-এ দেখা হয়েছিল একটি মেকানিক্যাল সুইচ প্রেস করলে সংস্পর্শ (contact) কয়েক মিলিসেকেন্ডের জন্য বাউন্স করে — একটিমাত্র প্রেস একাধিক দ্রুত 0/1 ট্রানজিশন হিসেবে রেজিস্টার হতে পারে। ডিবাউন্স ফিল্টার ছাড়া কোড লেখা একটি খুবই সাধারণ ভুল — ফলাফল একটি বাটন প্রেসে একাধিকবার কাউন্ট বাড়া, একটি রিলে একাধিকবার টগল হওয়া, বা একটি মেনু একাধিক আইটেম এগিয়ে যাওয়া। এই ভুলটি প্রোটোটাইপে প্রায়ই ধরা পড়ে না কারণ ব্রেডবোর্ডের তারের সাথে হাত দিয়ে একটি বাটন চাপলে বাউন্স সবসময় স্পষ্টভাবে সমস্যা তৈরি নাও করতে পারে, কিন্তু প্রোডাকশন-মানের সুইচেও এটি ঘটে এবং টেস্ট না করলে ধরা পড়ে না।

৩ · ইন্টারাপ্ট লেটেন্সি হিসাবে না নেওয়া (cross-ref মডিউল ৭/L27)

মডিউল ৭-এ দেখা হয়েছিল একটি ইন্টারাপ্ট ঘটার মুহূর্ত আর ISR সত্যিই চালু হওয়ার মুহূর্তের মধ্যে একটি বাস্তব, অ-শূন্য বিলম্ব থাকে (ইন্টারাপ্ট লেটেন্সি) — বর্তমান ইনস্ট্রাকশন শেষ করা, কনটেক্সট সেভ করা, উচ্চ-প্রায়োরিটি ইন্টারাপ্ট দ্বারা প্রি-এম্পশন ইত্যাদির কারণে। টাইমিং-ক্রিটিক্যাল কোডে (যেমন একটি সেন্সরের এজ থেকে একটি নির্দিষ্ট মাইক্রোসেকেন্ডের মধ্যে প্রতিক্রিয়া জানানো দরকার) এই লেটেন্সি হিসাবে না নিলে — বিশেষ করে যখন একাধিক ইন্টারাপ্ট সোর্স প্রতিযোগিতা করছে — সিস্টেম "কাগজে-কলমে" ঠিক দেখালেও বাস্তবে ডেডলাইন মিস করতে পারে।

৪ · রেডিও ট্রান্সমিশনের ব্যাটারি ড্রেইন কম হিসাব করা (cross-ref মডিউল ৮/L34, মডিউল ১০/L42-L44)

মডিউল ৮-এ ব্যাটারি-লাইফ গণনার প্যাটার্ন এবং মডিউল ১০-এ WiFi/BLE/Zigbee/LoRaWAN/সেলুলারের কারেন্ট-ড্র তুলনা দেখা হয়েছে — একটি সাধারণ ভুল হলো শুধু "গড়" বা "স্লিপ" কারেন্ট দেখে ব্যাটারি-লাইফ অনুমান করা, রেডিও ট্রান্সমিট মুহূর্তের কারেন্ট স্পাইক উপেক্ষা করে। যেহেতু ট্রান্সমিট কারেন্ট সাধারণত স্লিপ কারেন্টের চেয়ে শত-হাজার গুণ বেশি হতে পারে (L55-এর কেস স্টাডিতেই ১২০ mA বনাম ০.০১ mA দেখা গেছে), ট্রান্সমিশনের সংখ্যা বা সময়কাল সামান্য কম-হিসাব করাও গড় কারেন্টে বড় প্রভাব ফেলে — বাস্তবে অনেক IoT ডিভাইস মাঠে নামার পর প্রত্যাশার চেয়ে অনেক কম সময় ব্যাটারিতে চলে, ঠিক এই কারণে।

৫ · ডিফল্ট/হার্ডকোডেড ক্রেডেনশিয়াল শিপ করা (cross-ref মডিউল ১২/L51)

মডিউল ১২-তে দেখা হয়েছিল IoT সিকিউরিটি কেন কঠিন — বিশাল ডিভাইস সংখ্যা, দুর্বল/ডিফল্ট ক্রেডেনশিয়াল, কম প্যাচিং, ফিজিক্যাল অ্যাক্সেসযোগ্যতা। একটি অত্যন্ত সাধারণ (ও সুপরিচিত) ভুল হলো প্রতিটি ইউনিটে একই ডিফল্ট পাসওয়ার্ড বা একই হার্ডকোডেড API কী শিপ করা — একটি ইউনিটের ক্রেডেনশিয়াল ফাঁস হলে সাথে সাথেই সব ইউনিট ঝুঁকিতে পড়ে যায় (একটি বৃহৎ আকারের বটনেট তৈরির সাধারণ পথ, যা Cybersecurity কোর্সে সাধারণভাবে আলোচিত)। সঠিক পথ — প্রতিটি ডিভাইসের জন্য প্রভিশনিং-সময়ে ইউনিক ক্রেডেনশিয়াল তৈরি করা।

৬ · প্রথম দিন থেকে OTA আপডেট মেকানিজম পরিকল্পনা না করা

একটি মাঠে বসানো IoT ফ্লিটে একটি বাগ বা সিকিউরিটি দুর্বলতা পাওয়া গেলে, প্রতিটি ইউনিটে গিয়ে ম্যানুয়ালি রিফ্ল্যাশ করা প্রায়ই বাস্তবসম্মত নয় (L55-এর সেচ কন্ট্রোলারের কথা ভাবুন)। যদি প্রথম দিন থেকে একটি নিরাপদ OTA (over-the-air) আপডেট মেকানিজম পরিকল্পনা করে না রাখা হয় — একটি স্বাক্ষর-যাচাই করা ফার্মওয়্যার ইমেজ, একটি রোলব্যাক পথ যদি নতুন ইমেজ বুট না হয় — তাহলে একটি সমালোচনামূলক বাগ ফিক্স করাই কার্যত অসম্ভব হয়ে দাঁড়ায়। এটি একটি স্থাপত্যগত সিদ্ধান্ত, পরে যোগ করা কঠিন — তাই এটিকে "পরে দেখা যাবে" হিসেবে ফেলে রাখা এই তালিকার সবচেয়ে ব্যয়বহুল ভুলগুলোর একটি।