-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sdio driver feature #4
base: master
Are you sure you want to change the base?
Conversation
add SDIOBlockdevice implementation for STM32F4
almost the same as for STM32F4, but in F7 SDIO device is renamed to SDMMC SDMMC1 is used for DISCO_F746NG updated readme.md for new target # Conflicts: # README.md
- removed comments - renamed short variable names
tickstart was inside checking loop removed wait_ms() calls added timeout checks for all while loops
Tested this with the block device test inside features-storage-tests-blockdevice-general_block_device
I have created also another repository, to semi-automatically integrate the sdio-driver into MbedOS. It also documents how I have used it to test mbed-bootloader and mbed-cloud-client-example / pelion-example-common with |
Sorry for the delay, I should have a look the upcoming week at this one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What benefits are there for introducing async? Does it need to be separated (another DEVICE_
) ? We had previously async separated due to introducing it to already supported drivers, this could come with it as default.
* | ||
* @note check physical present switch. Maybe not support by hardware, then function will always return true. | ||
*/ | ||
virtual bool isPresent(void); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be is_present()
virtual const char *get_type() const; | ||
|
||
private: | ||
mbed::DigitalIn _cardDetect; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_card_detect
and below also for card info member
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've noticed others as well , like SDIO_Cardinfo_t
members. We don't use camel case in most cases (only C++ class names)
}, | ||
"target_overrides": { | ||
"DISCO_F469NI": { | ||
"CMD_TIMEOUT": 30000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix alignment
return SD_BLOCK_DEVICE_ERROR_ERASEBLOCKS; | ||
#if DEVICE_SDIO_ASYNC | ||
} else { | ||
uint32_t tickstart = us_ticker_read(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this using _us_ticker - not wait_us() rather or Ticker object? Shouldn't it sleep_for
rather?
@0xc0170: I think the idea with having DEVICE_SDIO_ASYNC is that the async drivers would not have to be duplicating some of the logic and putting the wait logic in control of SDIOBlockDevice. I think @orenc17 did that part. In my #3 version, I did add the timeout value to the HAL call and left the wait in the low-level part. Your call. I will look into the other changes. |
@ARMmbed/mbed-os-storage Could you please review? |
* @arg SD_TRANSFER_OK: No data transfer is acting | ||
* @arg SD_TRANSFER_BUSY: Data transfer is acting | ||
*/ | ||
int sdio_get_card_state(void); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion the documentation tells that this would be the same as checking sdio_read_pending and sdio_write_pending in a row. Implementation seems to be something different. Would you please update this comment section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a little bit of confusion because the sdio_read_pending()
and sdio_write_pending()
are only defined if SDIO_ASYNC
is defined.
{ | ||
int sd_state = MSD_OK; | ||
|
||
if (!SD_CheckReadOnly(&g_sd)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This functionality is something different I was expecting based on the comment section.
We don't do camelCase, I suppose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The NXP driver does not have SDIO_ASYNC
defined so it does not seem to have a notion of the device being "busy". Actually it should probably return SD_TRANSFER_OK
and a SD_TRANFER_ERROR
should probably be added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding camelCase, my goal was to keep my changes to a minimum on the target-specific code. The symbols beyond the HAL seem to me much less important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not touch 3rd party drivers so if this CheckReadOnly comes from there, all good !
@@ -0,0 +1,163 @@ | |||
/** \addtogroup hal */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason for having a new API instead of providing an implementation for the already existing BlockDevice interface and extend it when necessary? Maybe do it in a similar manner as SDBlockDevice.(My bad, this is HAL API, not Mbed OS API...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or are there any plans to get this driver to Mbed OS one day?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One day there will be plans to add this to MbedOS. The original code comes from 2 different implementations. @orenc17 did some work to align them. I understand the reason of the existence of this repository as a place to work out the APIs and the generic part. Having the different implementations in the same tree will allow easier changes and testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some styling remarks, otherwise looks fine to me to land and continue progressing this
#define SDIO_DBG 0 /*!< 1 - Enable debugging */ | ||
#define SDIO_CMD_TRACE 0 /*!< 1 - Enable SD command tracing */ | ||
|
||
#define SDIO_BLOCK_DEVICE_ERROR_WOULD_BLOCK -5001 /*!< operation would block */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would make this enum rather than macros. SImilar to types like qspif_bd_error
(an example how error code look like).
#define BLOCK_SIZE_HC 512 /*!< Block size supported for SD card is 512 bytes */ | ||
|
||
// Types | ||
#define SDCARD_NONE 0 /**< No card is present */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here as above, lets make them more debug friendly. I would even do enum class as we are now C++1x
* @brief DeInitializes the SD card device. | ||
* @retval SD status | ||
*/ | ||
int sdio_deinit(void); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hal usually names this _free
* @param block_count: Number of SD blocks to write | ||
* @retval SD status | ||
*/ | ||
int sdio_write_blocks(uint8_t *data, uint32_t address, uint32_t block_count); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return types for HAL: wouldn't it be better to have a status return type, see qspi HAL for instance. qspi_status_t
to describe all return types
What's the status of the sdio blockdevice feature? I have a need for one of my custom boards. I'd be interested in helping integrate this feature to mbed-os master! |
@AGlass0fMilk @mathias-arm as part of the silicon partner governance, a design document was proposed for official SDIO ARMmbed/mbed-os#11847. There was some work initially but it seems to have stalled a bit. It would be great if you can review that document and provide your feedback and we can push it a bit closer to completion. |
Ignore #3. I replayed ARMmbed/mbed-os#10235 (without the mbed-os part that I put here).
With this PR, you can add a
sdio-driver.lib
in your project (+ a few tweaks tombed_app.json
) and useother
forstorage_filesystem.blockdevice
: