osal: add liteos_m osal#301
Conversation
- support liteos_m Signed-off-by: Hongpeng Huo <[email protected]>
WalkthroughThis pull request introduces a new OS abstraction layer for USB operations in a LiteOS environment. The file Changes
Sequence Diagram(s)sequenceDiagram
participant USB as USB Module
participant OSAL as USB OSAL (LiteOS)
participant Kernel as LiteOS Kernel
USB->>OSAL: usb_osal_thread_create(name, stack_size, prio, entry, args)
OSAL->>Kernel: LOS_TaskCreate(task_params)
Kernel-->>OSAL: Task created or error
OSAL-->>USB: Return thread handle or handle error
sequenceDiagram
participant USB as USB Module
participant OSAL as USB OSAL (LiteOS)
participant Kernel as LiteOS Kernel
USB->>OSAL: usb_osal_timer_start(timer)
OSAL->>Kernel: Start software timer
Kernel-->>OSAL: Timer started status
OSAL-->>USB: Acknowledge timer start
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
osal/usb_osal_liteos_m.c (2)
38-39: Refactor repeatedwhile (1)error handling for maintainability.
Each time an error occurs, the code logs the error and goes into an infinite loop, which may make debugging or error recovery difficult. Consider centralizing the error handling or returning an error code to allow upper layers a chance to handle the failure gracefully instead of hanging the system.Also applies to: 48-49, 66-67, 81-82, 96-97, 137-138, 152-153, 185-186, 200-201, 259-260, 281-282, 296-297, 310-311
42-42: Ensure null termination when copying thread name.
strncpy(t->name, name, sizeof(t->name))may not null-terminate ifnameexceedst->name. Consider a safer pattern:- strncpy(t->name, name, sizeof(t->name)); + strncpy(t->name, name, sizeof(t->name) - 1); + t->name[sizeof(t->name) - 1] = '\0';
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
osal/usb_osal_liteos_m.c(1 hunks)
🔇 Additional comments (3)
osal/usb_osal_liteos_m.c (3)
123-126: Clarify the purpose of this emptyusb_osal_sem_resetfunction.
The function has no implementation. If a reset mechanism is needed, implement the logic here. Otherwise, you can safely remove it to prevent confusion.
210-213: Good approach for interrupt context.
Using non-blocking calls (LOS_NO_WAIT) whenOS_INT_ACTIVEis set prevents deadlocks or waits in interrupt context. This is a well-considered design choice.
31-33:Details
❓ Verification inconclusive
Confirm pointer size alignment for
.uwArg = (UINT32)args.
Casting a pointer toUINT32may cause truncation or undefined behavior if running on a 64-bit architecture. If LiteOS is strictly 32-bit, this should be fine; otherwise, consider using a 64-bit argument field or an appropriate pointer-to-integer cast mechanism.We can scan for all references to
.uwArgto ensure usage aligns with a 32-bit environment:
🏁 Script executed:
#!/bin/bash fd -e c -e h | xargs rg '\.uwArg'Length of output: 91
Action Required: Verify 32-bit Environment for Pointer Cast Alignment
The search confirms that the only reference to
.uwArgis inosal/usb_osal_liteos_m.cwhere the pointer is cast toUINT32. This suggests the current design assumes a 32-bit address space. However, to prevent potential truncation issues on a 64-bit system, please double-check that LiteOS is strictly 32-bit. If there’s any chance the code might run in a 64-bit environment, consider revising the cast mechanism or expanding the argument field accordingly.
2 participants
Summary by CodeRabbit