BSP_I2C

[Shaun345]

Removed most of the content from the original version of the BSP_I2C. Trying to move it over to the simple HAL commands in the documentation.

Planning on utilizing a queue with structs containing the metadata, device address, and data length for each transmit call that cannot be immediately serviced. Created two prototypes but have not started the interrupt routine.

I need to check if the data buffer passed into the HAL receive command automatically gets inserted with the data or if our interrupt handler must do this. Considering using the memory address interrupt-based send/receives if this functionality is also desired.

[IshDeshpa]

Also; change the target branch to main since this will get merged directly there

[Shaun345]

Also; change the target branch to main since this will get merged directly there

I'll modify this branch to branch off the main branch instead before switching this PR to merge with main.

[Lakshay983]

can you check to see if the queue is full (for adding) or empty (for popping) before you do any queue accesses.

[Shaun345]

can you check to see if the queue is full (for adding) or empty (for popping) before you do any queue accesses.

An empty queue should already be accounted for. What is the desired behavior for a full queue? Should I just return a Error status instead of a "okay" or "busy" status? Just want to make sure it lines up with the behaviors of the other BSPs.

[IshDeshpa]

Yeah full queue we just drop the message and return error. @Lakshay983 I'm pretty sure the xQueueSend returns an error if the queue access fails, so we can just check the return condition (see https://www.freertos.org/Documentation/02-Kernel/04-API-references/06-Queues/04-xQueueSendFromISR)