Skip to content
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

Open
wants to merge 23 commits into
base: master
Choose a base branch
from

Conversation

mathias-arm
Copy link

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 to mbed_app.json) and use other for storage_filesystem.blockdevice:

#include "SDIOBlockDevice.h"
static SDIOBlockDevice bd;

BlockDevice *get_other_blockdevice()
{
    return &bd;
}

BlockDevice *BlockDevice::get_default_instance()
{
    return &bd;
}

JojoS62 and others added 20 commits August 9, 2019 00:39
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
@mathias-arm
Copy link
Author

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 DISCO_F746NG and LPC55S69_NS.

mathias-arm added a commit to mathias-arm/mbed-os that referenced this pull request Aug 12, 2019
@0xc0170
Copy link
Collaborator

0xc0170 commented Aug 23, 2019

Sorry for the delay, I should have a look the upcoming week at this one.

Copy link
Collaborator

@0xc0170 0xc0170 left a 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);
Copy link
Collaborator

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;
Copy link
Collaborator

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

Copy link
Collaborator

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
Copy link
Collaborator

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();
Copy link
Collaborator

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?

@mathias-arm
Copy link
Author

@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.

@0xc0170
Copy link
Collaborator

0xc0170 commented Sep 17, 2019

@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);

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.

Copy link
Author

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)) {

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.

Copy link
Author

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.

Copy link
Author

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.

Copy link
Collaborator

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 */
Copy link

@VeijoPesonen VeijoPesonen Sep 18, 2019

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...)

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?

Copy link
Author

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.

Copy link
Collaborator

@0xc0170 0xc0170 left a 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 */
Copy link
Collaborator

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 */
Copy link
Collaborator

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);
Copy link
Collaborator

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);
Copy link
Collaborator

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

@AGlass0fMilk
Copy link
Member

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!

@maclobdell

@maclobdell
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants