Improve hardware I/O error handling, timeouts, and logging

[PriyanshuRaut]

Motivation

• Prevent indefinite blocking in read by adding bounded waits and per-call timeouts to avoid deadlocks.
• Replace print usage with structured logging and return values so higher layers (API/runtime) can report failures to users.
• Surface explicit error conditions to callers by introducing specific exception types for connection, read, write, and timeout failures.

Description

• Added HardwareError plus HardwareConnectionError, HardwareWriteError, HardwareReadError, and HardwareTimeoutError exception classes.
• Updated Arduino.write to accept an optional timeout, set a per-call write timeout, return a structured result ({"ok": True, "bytes_written": ..., "message": ...}), and raise HardwareWriteError on failure.
• Updated Arduino.read to accept timeout and poll_interval, use a bounded poll loop that returns {"ok": True, "data": ...} or raises HardwareTimeoutError/HardwareReadError on failure.
• Replaced print calls with self.logger calls and made led_on, led_off, motor_start, motor_stop, and close return or propagate structured results/errors.

Testing

• No automated tests were run against the modified code.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: fcfccb6ee2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Enforce per-call timeout on readline

When in_waiting > 0, the code calls self.conn.readline() without adjusting the serial port’s own read timeout, so readline() can still block until the port-level timeout or a newline is received. In scenarios where timeout/read_timeout is shorter than the serial port’s configured timeout (or when a partial line arrives without a newline), the method can exceed the requested max_wait and won’t raise HardwareTimeoutError on time, defeating the per-call timeout guarantee. Consider temporarily setting self.conn.timeout (or using a non-blocking read) to ensure the loop’s max_wait is the actual upper bound.

Useful? React with 👍 / 👎.