Skip to content

Conversation

@eigen-value
Copy link
Collaborator

No description provided.

@eigen-value eigen-value linked an issue Nov 6, 2025 that may be closed by this pull request
@sebromero
Copy link
Contributor

sebromero commented Nov 7, 2025

Maybe we should consider extracting this from begin() into its own function e.g. ready(). That way the bridge could be started using begin() 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 using ready(). @facchinm

@eigen-value eigen-value requested a review from sebromero November 7, 2025 10:22
@eigen-value
Copy link
Collaborator Author

@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
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 using begin(). That way the boot up time optionally be used for something useful without compromising the UX. As soon as begin() is called the user HAS to (busy)-wait for the boot-up to finish. In other words, advanced users have the option of calling the begin() function only when they know for sure the system has booted.

@per1234 per1234 added the enhancement New feature or request label Nov 8, 2025
@eigen-value
Copy link
Collaborator Author

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

Copy link
Contributor

@sebromero sebromero 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 think ready also needs to call init, otherwise mpu_boot_pin won't be configured correctly if ready is being called standalone. The mutex wouldn't necessarily be required by ready, so maybe the pin needs its own init function?

@github-actions
Copy link

Memory usage change @ 1b14cf9

Board flash % RAM for global variables %
arduino:zephyr:unoq 🔺 +184 - +248 +0.01 - +0.01 🔺 +16 - +16 0.0 - 0.0
Click for full report table
Board examples/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: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
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 free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bridge must check Linux is ready before begin

4 participants