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

Make SD cards available over web workflow #8699

Merged
merged 8 commits into from
Jan 25, 2024
Merged

Conversation

tannewt
Copy link
Member

@tannewt tannewt commented Dec 6, 2023

This changes storage.mount() to require that a mount point exist on the parent file system.

A bug in background tasks is also fixed where the function parameter is cleared on pending callbacks during "reset".

Disk usage is shown on the directory listing and changes based on the mounted file system. Writable is also loaded per-directory.

Fixes #8108. Fixes #8690. Fixes #8107.

@tannewt tannewt added this to the 9.0.0 milestone Dec 6, 2023
@tannewt tannewt requested a review from jepler December 6, 2023 00:28
@tannewt
Copy link
Member Author

tannewt commented Dec 6, 2023

The server side USB check isn't quite right. Will need to look at that when I have a chance next. Out of time for today.

@RetiredWizard
Copy link

RetiredWizard commented Dec 6, 2023

I ran the test code.py from #8690 and didn't see any delays/hangs in the timer printouts and was able to copy multiple files via web workflow without the webpage crashing. Thanks!!! 😁

I successfully copied a 4Mb file which did hang the code.py file while the transfer was happening but once the transfer finished everything behaved normally.

I was able to hang the code.py running on the serial terminal by doing a page refresh on the web workflow directory listing, at which point the serial terminal was completely unresponsive, however either performing a file transfer via web workfow, deleting a file or simply changing the directory that was being displayed released the serial terminal and it once again functioned normally.

The warning about having the CIRCUITPY drive mounted on the host computer didn't seem to be displayed on the web workflow page, When I tried to transfer a file with the CIRCUITPY drive mounted the web workflow file browser didn't display an error messages but the file wasn't copied.

I don't often use the web workflow "Full Code Editor" so I'm not sure this has anything to do with this PR but when I tried to launch it the following message was displayed:
Unable to connect. The device 10.0.0.218 was not found. Be sure it is plugged in and set up properly.

I mounted/unmounted a SD card multiple times and the web workflow displayed the directory contents that you would expect. I even tried mounting a second SD card on top of an already mounted SD card's mount point. That resulted in an error but didn't cause any problem with the already mounted directory.

The total used and total size of the flash was displayed on the web workflow directory listing:
Disk usage:5.8 MB out of 5.9 MB
versus the total free/available and total size on the Linux directory screen:
Free space: 93.0 KiB (Total: 5.7 MiB)
and a DF -h:
/dev/sde1 5.7M 5.6M 93K 99% /media/retiredwizard/CIRCUITPY

When I copied another 50K the web workflow disk usage indicated that the used space was equal to the total space of 5.9MB so the available space (total - used) seems accurate to a precision of 100KB.

@tannewt
Copy link
Member Author

tannewt commented Dec 6, 2023

I ran the test code.py from #8690 and didn't see any delays/hangs in the timer printouts and was able to copy multiple files via web workflow without the webpage crashing. Thanks!!! 😁

Yay! Thanks for testing!

I successfully copied a 4Mb file which did hang the code.py file while the transfer was happening but once the transfer finished everything behaved normally.

This is expected. The web workflow code waits for the whole file before returning to python code. I don't think this is an issue because we'll reload soon after anyway.

I was able to hang the code.py running on the serial terminal by doing a page refresh on the web workflow directory listing, at which point the serial terminal was completely unresponsive, however either performing a file transfer via web workfow, deleting a file or simply changing the directory that was being displayed released the serial terminal and it once again functioned normally.

Could you explain this in more detail please? I'm not sure if you mean the REPL or not.

The warning about having the CIRCUITPY drive mounted on the host computer didn't seem to be displayed on the web workflow page, When I tried to transfer a file with the CIRCUITPY drive mounted the web workflow file browser didn't display an error messages but the file wasn't copied.

I'll be tweaking this soon. No error exists for failed upload yet. I'll need to add that too.

I don't often use the web workflow "Full Code Editor" so I'm not sure this has anything to do with this PR but when I tried to launch it the following message was displayed: Unable to connect. The device 10.0.0.218 was not found. Be sure it is plugged in and set up properly.

The full code isn't updated for the new directory listing yet. The developer tools in your browser may have more info.

The total used and total size of the flash was displayed on the web workflow directory listing: Disk usage:5.8 MB out of 5.9 MB versus the total free/available and total size on the Linux directory screen: Free space: 93.0 KiB (Total: 5.7 MiB) and a DF -h: /dev/sde1 5.7M 5.6M 93K 99% /media/retiredwizard/CIRCUITPY

When I copied another 50K the web workflow disk usage indicated that the used space was equal to the total space of 5.9MB so the available space (total - used) seems accurate to a precision of 100KB.

I have it setup to do / 1000 so it matches SD card size better. It was a couple GB for my 32GB card.

@tannewt tannewt removed the request for review from jepler December 6, 2023 19:22
@tannewt tannewt marked this pull request as draft December 6, 2023 19:22
@tannewt
Copy link
Member Author

tannewt commented Dec 6, 2023

BLE workflow hasn't been updated so the CI failed. I have ideas on doing clearer per-mount locking so I'm going to run with that. I'm thinking about the S3 future where we have both web and ble workflows going concurrently.

@RetiredWizard
Copy link

RetiredWizard commented Dec 6, 2023

Could you explain this in more detail please? I'm not sure if you mean the REPL or not.

I have a tio terminal session connected to the micro controller, doesn't matter if it's in the REPL or running a python program.

I also have the web workflow file browser open in a web browser window (http://10.0.0.218/fs/#/) .

If I hit the refresh page button on the web browser the web workflow web page refreshes but the tio serial terminal hangs and will not respond to any input including Ctrl-C, Ctrl-D

Pressing the refresh button a second time on the web browser refreshes the workflow page normally and the tio serial terminal starts processing any keys that were pressed while it was hung, but after a few seconds hangs again. (While typing this in, the serial terminal screen started responding again after maybe a minute of being frozen, I hadn't seen it release by itself before but perhaps I never let it sit long enough).

If while the USB serial terminal is frozen, you peform any file activity (delete, rename, upload) or change the folder being displayed on the web workflow page, the serial terminal is released and functions normally again.

** I waited again with the terminal screen frozen and after 1-2 minutes it released again, so there does seem to be a timeout going on.

@RetiredWizard
Copy link

The full code isn't updated for the new directory listing yet. The developer tools in your browser may have more info.

I'm not sure what to look for but the developer tools console simply displayed a couple status messages:

Load different workflow               index.js:37
Initializing File Transfer Client...  index.js:37

image

@tannewt
Copy link
Member Author

tannewt commented Dec 7, 2023

The full code isn't updated for the new directory listing yet. The developer tools in your browser may have more info.

I'm not sure what to look for but the developer tools console simply displayed a couple status messages:

The network tab can be helpful because it shows the calls being done to the device and if they failed.

@RetiredWizard
Copy link

I don't see any failed calls... The 9 second delay was me entering the CircuitPython password

image

@tannewt
Copy link
Member Author

tannewt commented Dec 8, 2023

This may be how the unsupported version is handled. @makermelissa would know.

@makermelissa
Copy link
Collaborator

I can't really remember because it's been about a year, but I would have thought it would at least attempt to contact it.

This changes storage.mount() to require that a mount point exist
on the parent file system.

A bug in background tasks is also fixed where the function
parameter is cleared on pending callbacks during "reset".

Disk usage is shown on the directory listing and changes based on
the mounted file system. Writable is also loaded per-directory.

Fixes micropython#8108. Fixes micropython#8690. Fixes micropython#8107.
@tannewt tannewt marked this pull request as ready for review January 16, 2024 22:57
@tannewt tannewt requested a review from jepler January 16, 2024 22:57
@tannewt
Copy link
Member Author

tannewt commented Jan 16, 2024

I've reworked how locking is managed. IIRC I tested the web workflow side with the rework but not BLE. Marking ready for review because the code should be close.

Copy link
Member

@jepler jepler left a comment

Choose a reason for hiding this comment

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

I have some small comments & changes requested. The new functionality is exciting.

extmod/vfs_blockdev.c Show resolved Hide resolved
mp_raise_OSError(MP_EEXIST);
} else {
// Something with the same name doesn't exists.
mp_raise_RuntimeError(MP_ERROR_TEXT("Mount point missing. Create first (maybe via USB)"));
Copy link
Member

Choose a reason for hiding this comment

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

What's the consequence of making this a warning in 9 and an error in 10? Maybe something like this but less horribly verbose.

warnings_warn(&mp_type_FutureWarning, MP_ERROR_TEXT(
    "Mount point missing. "
    "This will be an error in CircuitPython 10. "
    "This prevents file from being available via web & bluetooth workflow. "
    "Create an empty directory (maybe via USB) first");

Also is it important that the placeholder be a directory, which is a requirement on Unix-style systems I have used?

Copy link
Member Author

Choose a reason for hiding this comment

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

If it is a warning, then the parent directory won't list the mount point. So navigating into the mount wouldn't work.

supervisor/shared/background_callback.c Show resolved Hide resolved
supervisor/shared/bluetooth/file_transfer.c Show resolved Hide resolved
Makes sure mount point is a directory.

Fixes micropython#8110 by making it explicit that progress is per-file.
@tannewt
Copy link
Member Author

tannewt commented Jan 18, 2024

Ok, I've made some fixes and tested over WiFi and BLE. Please look again.

@tannewt tannewt requested a review from jepler January 18, 2024 22:57
@jepler
Copy link
Member

jepler commented Jan 19, 2024

build is failing :(

@tannewt
Copy link
Member Author

tannewt commented Jan 23, 2024

Hopefully this will pass. Please push back if I'm being too aggressive with these errors. I'm not sure how else to make more space.

@tannewt
Copy link
Member Author

tannewt commented Jan 23, 2024

@jepler Please take another look. All builds fit now.

@RetiredWizard
Copy link

Perhaps #8690 should be separated from this PR so it doesn't hold it up?

@tannewt
Copy link
Member Author

tannewt commented Jan 24, 2024

Perhaps #8690 should be separated from this PR so it doesn't hold it up?

I don't want to mess with this PR anymore. I'd like to get it merged since it is ready.

@RetiredWizard
Copy link

Perhaps #8690 should be separated from this PR so it doesn't hold it up?

I don't want to mess with this PR anymore. I'd like to get it merged since it is ready.

That's what I was thinking too 😁, merge this but remove the link to #8690 or re-open it after this is merged.

Comment on lines +80 to +82
// CIRCUITPY-CHANGE: Pass the blockdev object into native readblocks so
// it has the corresponding state.
mp_uint_t (*f)(mp_obj_t self, uint8_t *, uint32_t, uint32_t) = (void *)(uintptr_t)self->readblocks[2];
Copy link
Member

Choose a reason for hiding this comment

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

This cast would be an undetected error if we had any other block device implementations (micropython has several) but we control them all it's probably OK.

Copy link
Member Author

Choose a reason for hiding this comment

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

Would you like me to add native ioctl implementations for others with native read/write? Or what?

jepler
jepler previously approved these changes Jan 25, 2024
Copy link
Member

@jepler jepler left a comment

Choose a reason for hiding this comment

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

I found one item for possible future improvement, but if it fits let's put it in and get some testing!

shared-bindings/pwmio/PWMOut.c Outdated Show resolved Hide resolved
We already consolidated the resulting message
Copy link
Member

@jepler jepler left a comment

Choose a reason for hiding this comment

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

thanks for implementing that change

@tannewt tannewt merged commit 474dae8 into adafruit:main Jan 25, 2024
465 checks passed
@tannewt tannewt deleted the ww_sd_card branch January 25, 2024 18:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants