hal_serial_nor interacts with external peripherals, and validates responses and the such. In these circumstances, it should return with an error and allow the application code to remediate it (instead of solely relying upon asserts as is currently done in the flash device driver).
Solely relying upon asserts is fine for internal peripherals (though in Hi-Rel applications even that is not acceptable in most scenarios).
serial_nor complex driver should return status
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: serial_nor complex driver should return status
Hi,
Which functions are you referring to? flashXXX() functions defined in the interface all return error codes.
Giovanni
Which functions are you referring to? flashXXX() functions defined in the interface all return error codes.
Giovanni
Re: serial_nor complex driver should return status
None of the hal_serial_nor exported functions return a status:
https://github.com/ChibiOS/ChibiOS/blob ... rial_nor.h
Here's an example:
snorStart() calls snor_device_init() which does a transaction with wspiReceive(). It then evaluates the response using an assert:
The assert is fine, but it should also return, and errors should be propagated to the application code. Currently, neither snorStart() or snor_device_init() return anything.
https://github.com/ChibiOS/ChibiOS/blob ... rial_nor.h
Here's an example:
snorStart() calls snor_device_init() which does a transaction with wspiReceive(). It then evaluates the response using an assert:
Code: Select all
osalDbgAssert(n25q_find_id(n25q_manufacturer_ids,
sizeof n25q_manufacturer_ids,
devp->device_id[0]),
"invalid manufacturer id");
The assert is fine, but it should also return, and errors should be propagated to the application code. Currently, neither snorStart() or snor_device_init() return anything.
Return to “Small Change Requests”
Who is online
Users browsing this forum: No registered users and 35 guests