-
Notifications
You must be signed in to change notification settings - Fork 16
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
initial PR for SDIOBlockdevice implementation #1
base: master
Are you sure you want to change the base?
Conversation
add SDIOBlockdevice implementation for STM32F4
added some description
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
@ARMmbed/mbed-os-storage Can you review? |
@0xc0170 will do after 5.11 release |
@dannybenor We need a review sooner. This is blocking new Pelion DM boards by ST. Could you please help? |
blockdevice should be a component and not a feature |
#define SD_DBG 0 /*!< 1 - Enable debugging */ | ||
#define SD_CMD_TRACE 0 /*!< 1 - Enable SD command tracing */ | ||
|
||
#define SD_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.
shouldn't those be in H file?
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 debug settings are used private in the cpp source, they are not relevant for other modules. I have taken this approach from the SDBlockdevice.
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.
Those return errors should be exposed by the h file (possibly for SDBlockDevice as well)
An even better suggestion is to use the errors at mbed_error.h
https://github.com/ARMmbed/mbed-os/blob/master/platform/mbed_error.h
UNKNOWN 256 Unknown error
INVALID_ARGUMENT 257 Invalid Argument
INVALID_DATA 258 Invalid data
INVALID_FORMAT 259 Invalid format
INVALID_INDEX 260 Invalid Index
...
* @param buffer Buffer to write blocks to | ||
* @param addr Address of block to begin reading from | ||
* @param size Size to read in bytes, must be a multiple of read block size | ||
* @return 0 on success, negative error code on failure |
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.
Please try to elaborate possible error values for each API
@JojoS62 - thanks for submitting this important BlockDevice implementation. I've left several questions and remarks - thanks! |
I have prepared some modifications as requested, but I will run the tests again first. Will push the commits tomorrow. |
- removed comments - renamed short variable names
@screamerbg this requires HAL to go into mbedOS master. Please create a preq and ad HAL team |
@dannybenor - This PR was moved to external repo for the same reason. HAL changes might take time as they are not planned, but that should not stop users to use SDIO interface. HAL changes will be needed to integrate with Mbed OS, but in parallel this driver can be polished and used as external. Also other partners will have reference to add to SDIO changes which will be helpful in finalizing HAL API's. |
@deepikabhavnani Yes, you are right. I missed this point. LGTM |
while (SD_DMA_ReadPending() != SD_TRANSFER_OK) | ||
{ | ||
uint32_t tickstart = HAL_GetTick(); | ||
if ((HAL_GetTick() - tickstart) >= MBED_CONF_SD_TIMEOUT) |
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 requires a fix in order to measure Timeout correctly.
@JojoS62 - thanks for making adjustments! |
tickstart was inside checking loop removed wait_ms() calls added timeout checks for all while loops
Hi Any update ? Thx |
@dannybenor @offirko Any update on this? |
sorry for the delay, at the moment I'm very busy with my work. |
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.
LGTM
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.
@JojoS62 - Thanks for adding this
@ARMmbed/mbed-os-maintainers - Please review and merge |
we can review but merging is up to @ARMmbed/mbed-os-storage team I believe |
/** @file fsfat_test.h | ||
* | ||
* mbed Microcontroller Library | ||
* Copyright (c) 2006-2016 ARM Limited |
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 should be 2019 (new file or at least 2018-2019)
New files should contain SPDX identifier (look at platform header files).
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.
Small license fix, rest looks fine
Sounds good, not sure why I thought only maintainers have merge permissions on this repo |
@ARMmbed/mbed-os-storage Can we progress? there's new PR that depends also on this one |
Why this PR is not progressing ? |
@ARMmbed/mbed-os-storage @dannybenor Could you please answer @jeromecoutant ? |
Just curious - would this better to now have have a generic SDIOBlockDevice in the mbed-os/components/storage/blockdevice/COMPONENT_SDIO and then specific implementations under platform-specific target code at mbed-os/targets/TARGET_/.../TARGET_/ Or alternatively, if there isn't a HAL abstraction to be used by a generic block device driver, perhaps fully target-specific SDIO blockdevice implementations could live in the target code. Can we move forward with one of these approaches, or perhaps another approach? |
- ARMmbed#1 is based on [JojoS62/sdio-driver/master](JojoS62@c03489c). - ARMmbed#2 is based on [NXPmicro/sdio-driver/Add_SDIO_LPC55S69](nxp-archive@370c51a)
@MarceloSalazar @adbridge don't forget this feature :-) |
@jeromecoutant we don't deal with this repository and it doesn't form part of our mbed-os releases. @MarceloSalazar @0xc0170 do you know anything about how this repo is used/controlled ? |
It seems I missed some notifications about updates here. I will try to implement the changes soon. @irfanafa is this issue still pending? I don't have a NUCLEO_F746ZG, so I can check it only in theorie. |
It's good for the STM32F746. Thankyou
…On Thu, 13 Aug 2020, 14:03 JojoS, ***@***.***> wrote:
It seems I missed some notifications about updates here. I will try to
implement the changes soon.
@adbridge <https://github.com/adbridge> This component was not complying
the rules for an integration into Mbed-os, so it was offloaded here. It
would be nice if the master branch could be filled.
@irfanafa <https://github.com/irfanafa> is this issue still pending? I
don't have a NUCLEO_F746ZG, so I can check it only in theorie.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKVTDIBKONA5QCQAIPNJBGTSAPI75ANCNFSM4GC6LHLA>
.
|
mbed file structure has changed again
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.
Didn't test, but I assume @JojoS62 did !
Thx
in the past month, I reworked this component for the F7. I added also support for the DISCO_F769NI, which uses the 2nd SDMMC interface. I still need to clean up experimental stuff and run the filesystem tests again. |
This is the component that was not merged into mbed-os.