Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Handle unaligned address in EspClass::flashWrite u8 overload#8605

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
mcspr merged 12 commits intoesp8266:masterfrommcspr:unaligned-everything
Jul 3, 2022

Conversation

@mcspr
Copy link
Collaborator

@mcsprmcspr commentedJun 16, 2022
edited
Loading

another approach at fixing#8372
resolves#8588@fabianoriccardi

instead of changing the branch, just break the flow on a lower level when actually writing things
both unaligned src and dest are placed into buffer. this copies behaviour of RTOS functions that I mentioned in the issue

example sketch seems to work. I just hope I did not break something else while fixing spiffs
(...and geez, how much unaligned writes it does. no wonder it's slow...)

@fabianoriccardi
Copy link

I guessed that this issue could be solved with a good refactor of the wholespi_flash_write_ methods. Sure I will vote for your pull request, my intention was proposing apunctual fix, modifying as little as possible, that the overall refactor is the way to go!

if (!flashReplaceBlock(address + offset, data + offset, sizeLeft)) {
returnfalse;
while (size >0) {
auto len =std::min(size,sizeof(buf));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Maybe have a double check on what is returned bysizeof(buf) here?
I always find it tricky to see for myself whether thesizeof is returning the size of the array or the size of a pointer.
In this instance, it should beFLASH_PAGE_SIZE

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

No point guessing when IDE / language server in any editor will display this b/c it's a compile time value :)
But I suppose this could bestd::size(buf); instead

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Well my "code review IDE" (also called "brain") is lacking this feature. ;) It is only highlighting code which looks like code I have spent numerous hours on to fix in the past where I missed such a mistake.
Apart from that you still need to hover your mouse on those parts of the code in an IDE that does show you what it will do and that was my suggestion, to actually do that ;)

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Which is why I mentioned the IDE as a tool to help with guesses, since we don't have this issue here. Review with a real test case might've helped too, would you mind re-checking with some ESPeasy builds if it's possible?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I did just now test ESPEasy with the code changes of this PR.
It does seem to work fine.

d-a-v and mcspr reacted with thumbs up emoji
Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

puya supports looks fine as well?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

puya supports looks fine as well?

I don't have any Puya device here at hand, so have not tested it.
If you like, I can have another look at the code?

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Please do.

@mcspr
Copy link
CollaboratorAuthor

mcspr commentedJun 27, 2022
edited
Loading

re. does it work with u8 data, we do have these test cases for various offsets
https://github.com/esp8266/Arduino/blob/master/tests/device/test_spi_flash/test_spi_flash.ino

PR adds an additional case, which fails with the current master

Copy link
Collaborator

@d-a-vd-a-v left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

device test started & passed

@fabianoriccardi
Copy link

I've tested the new commits and they solve#8372. Hoping they will be integrated soon in the main line.

mcspr reacted with thumbs up emoji

@mcsprmcspr linked an issueJul 3, 2022 that may beclosed by this pull request
6 tasks
@mcsprmcspr merged commit65d3043 intoesp8266:masterJul 3, 2022
@mcsprmcspr deleted the unaligned-everything branchJuly 3, 2022 19:47
@mcsprmcspr added this to the3.1 milestoneJul 3, 2022
hasenradball pushed a commit to hasenradball/Arduino that referenced this pull requestNov 18, 2024
esp8266#8605)Separate page handling logic and the actual writing. Make sure we place both unaligned src and dest into a buffer.Fixes edge-case introduced for SPIFFS that exclusively works through unaligned flash write function.This copies the behaviour of official RTOS port, but does not change the original spi_flash_write.
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@d-a-vd-a-vd-a-v approved these changes

+1 more reviewer

@TD-erTD-erTD-er left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

SPIFFS println weird behavior with long strings

4 participants

@mcspr@fabianoriccardi@TD-er@d-a-v

[8]ページ先頭

©2009-2025 Movatter.jp