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

feat: check pin G13 for host boot complete#32

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

Draft
eigen-value wants to merge5 commits intomain
base:main
Choose a base branch
Loading
from30-bridge-must-check-linux-is-ready-before-begin

Conversation

@eigen-value
Copy link
Collaborator

No description provided.

@eigen-valueeigen-value linked an issueNov 6, 2025 that may beclosed by this pull request
@sebromero
Copy link
Contributor

sebromero commentedNov 7, 2025
edited
Loading

Maybe we should consider extracting this frombegin() into its own function e.g.ready(). That way the bridge could be started usingbegin() and the time during which Linux boots could be used to prepare other peripherals etc. instead of wasting it and then when that is done, the sketch can wait for Linux usingready().@facchinm

@eigen-value
Copy link
CollaboratorAuthor

@sebromero I understand your point, but I have mixed feelings about it.
That way we can't always make sure Bridge is used before the other side is ready (eg somebody could try and use Monitor to println during peripherals setup).
Besides we complicate the UX adding yet another call before exiting setup.

sebromero reacted with eyes emoji

@sebromero
Copy link
Contributor

@eigen-value What if we do the following:begin() can stay blocking as it currently is waiting for Linux to boot, but we extract that check into its own non-blocking function e.g.ready(). The user has the option of preparing as much peripherals, buffering sensor data etc. as they can while Linux is being booted and just check periodically if Linux is ready and then start the bridge usingbegin(). That way the boot up time optionally be used for something useful without compromising the UX. As soon asbegin() is called the user HAS to (busy)-wait for the boot-up to finish. In other words, advanced users have the option of calling thebegin() function only when they know for sure the system has booted.

@per1234per1234 added the enhancementNew feature or request labelNov 8, 2025
@eigen-value
Copy link
CollaboratorAuthor

Hi@sebromero,@pennam
It makes sense so check the latest commit please.
It works with the bricks, but must be tested in the "Startup mode->Immediate" scenario

Before marking the PR as ready I need to check If G13 is raised from a specific RC onward and if a timeout is needed for backwards compat

sebromero reacted with rocket emoji

Copy link
Contributor

@sebromerosebromero left a comment

Choose a reason for hiding this comment

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

Correct me if I'm wrong but I thinkready also needs to callinit, otherwisempu_boot_pin won't be configured correctly ifready is being called standalone. The mutex wouldn't necessarily be required byready, so maybe the pin needs its own init function?

@github-actions
Copy link

Memory usage change @1b14cf9

Boardflash%RAM for global variables%
arduino:zephyr:unoq🔺 +184 - +248+0.01 - +0.01🔺 +16 - +160.0 - 0.0
Click for full report table
Boardexamples/client
flash
%examples/client
RAM for global variables
%examples/clientSSL
flash
%examples/clientSSL
RAM for global variables
%examples/hci
flash
%examples/hci
RAM for global variables
%examples/monitor
flash
%examples/monitor
RAM for global variables
%examples/server
flash
%examples/server
RAM for global variables
%examples/simple_bridge
flash
%examples/simple_bridge
RAM for global variables
%examples/test
flash
%examples/test
RAM for global variables
%
arduino:zephyr:unoq2360.01160.02360.01160.02440.01160.02480.01160.02360.01160.01840.01160.02440.01160.0
Click for full report CSV
Board,examples/client<br>flash,%,examples/client<br>RAM for global variables,%,examples/clientSSL<br>flash,%,examples/clientSSL<br>RAM for global variables,%,examples/hci<br>flash,%,examples/hci<br>RAM for global variables,%,examples/monitor<br>flash,%,examples/monitor<br>RAM for global variables,%,examples/server<br>flash,%,examples/server<br>RAM for global variables,%,examples/simple_bridge<br>flash,%,examples/simple_bridge<br>RAM for global variables,%,examples/test<br>flash,%,examples/test<br>RAM for global variables,%arduino:zephyr:unoq,236,0.01,16,0.0,236,0.01,16,0.0,244,0.01,16,0.0,248,0.01,16,0.0,236,0.01,16,0.0,184,0.01,16,0.0,244,0.01,16,0.0

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@sebromerosebromerosebromero requested changes

@facchinmfacchinmAwaiting requested review from facchinm

@pennampennamAwaiting requested review from pennam

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

enhancementNew feature or request

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Bridge must check Linux is ready before begin

4 participants

@eigen-value@sebromero@per1234

[8]ページ先頭

©2009-2025 Movatter.jp