Is there a way to tell when a NUC computer has finished booting? I need to externally control some hardware power-up's (by 3rd parties so I don't have much control.) The NUC has to be up and running before I can power-up some things it will be controlling.
I could make a timer doo-dad, but there may be unforeseen issues with that approach.
Ideally, something I could run (Linux or Windows), or better yet, some sort of HARDWARE indication that the boot is complete.
Probably something simple I'm missing?? Logic state switch is better than intercepting USB or LAN packets or some crap like that.
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510
http://electrooptical.net
http://hobbs-eo.com
Maybe put a little program, or even a little command line, to set a pin on an RS232 or printer port or USB device at boot time. There a folder in Windows where you can put stuff to kick off at boot time.
What sorts of ports does the NUC have?
--
John Larkin Highland Technology, Inc
picosecond timing precision measurement
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
On Wednesday, March 25, 2020 at 3:14:06 PM UTC-4, snipped-for-privacy@gmail.com wrote :
dware that won't be activated until booting is done?
It's a complicated box-build with (in my opinion) too many fingers in the m ix. It's not clear that (other than hardware) we have much control over what so ftware ultimately goes on the NUC when it is all said and done. Software mo stly done by third-parties, and not necessarily at build-time.
Also (new wrinkle I just thought of), there are a few countries we ship to where the NUC is sent "wiped" (or maybe just running Ubuntu or something fo r basic operation) due to ITAR regulations about exporting certain technolo gies. (That's a quagmire all its own...)
I'm hoping for something hardware-wise on the NUC, and if not, then the sim plest thing possible to know it has finished booting.
4 usb (1) usb c (1) hdmi (1) headphone (audio out only, not sure if it has a mic-in?) WiFi Intel 9260 m2-ssd HD sata plug (not being used) pin header on the NUC itself
There are two separate issues here (or, looked at another way, one issue with "policy" and "mechanism" components that are largely separate).
Policy: how do you _define_ "finished booting", and how do you know that this has occurred? That's very much a question of what software (OS, distribution, apps) you are running.
It's also somewhat subjective and variable. If you've got a whole bunch of system services applications which need to start up at boot time, then for every one of them you need to decide what part of each is is "at boot time" and what part is "running normally, after boot is completed." If your product allows the user to install third-party applications, and some of _those_ have to start up before you can decide that "boot has finished", you have a problem you may never be able to solve.
Now, as one example of how this can be done reasonably-cleanly... you might take a look at the large-and-controversial "systemd" startup-and-service manager for Linux. For systemd, each service or startup program comes with a "unit file" which describes its behavior, and its prerequisites (what things have to start up before this, what things depend on this and have to be started later, and how the service signals that its startup process is complete). Systemd is responsible for managing all of these dependencies, and starting up everything in an order which doesn't violate any of them. Eventually the system reaches its desired state (e.g. multi-user operation).
In this sort of system, part of the "mechanism" you would use would be to write a one-shot service that's supposed to be started only after all of the other dependencies have been satisfied. This service would send the external signal.
If your NUC is running Windows, I'd look for a similar sort of service management capability.
As to what the external signal is... the physical part of the "mechanism"... that depends on your available hardware. If your system has a traditional serial port, you could run a program which opens the serial port (thus asserting DTR)... this might be a one-shot signal, or you might leave the program running-and-idling with the serial port open so that it continued to assert DTR.
If you have no serial port, then add a good USB-to-serial adapter (FTDI comes to mind) and do the same trick as above.
A lot of embedded motherboards have some un-dedicated GPIO lines that you can access via drivers of various sorts. I don't know if NUC boards do, but it wouldn't surprise me.
Another question is why would you care if the system is not done booting? The operator can't do anything until it's done booting anyway. We need more info on how your hardware is interacting with the NUC board.
The short answer is that there is no operator! The longer answer is that some of the 3rd party pieces in this build (to include software) start to run into problems if the NUC is not ready to assume control when needed.
Disclaimer: I didn't design this build. Let's leave it at that.
Sounds like you need a handshake for an external logic item; are there hooks in Windows (when booting to a 'main' user, I trust) to run a user program after each successful startup? If there's no operator, there's not gonna be a password prompt.
You'll also need to handshake on shutdown command (assuming you're not gonna just yank the plug out of the wall). Maybe OR with the 'power-is-stable' output that makes the ON/OFF LED work.
Lots of ways to do this, but it's harder if you aren't in control of the NUC's configuration.
You could require that the NUC expose a WiFi hotspot at or near the end of the boot cycle, and use an ESP8266 that connects to it to activate a relay that enables the other gear.
It's a complex box. There are something like (30) different things that po wer-up. The problem is a particular module has a nasty tendency to glitch (with "improper power-up/down") but could (allegedly) be completely elimina ted if we can guarantee the NUC is fully booted before all the shit happens in the box. (My use of the technical term "shit" is more an outward expre ssion of the fact that this abortion of a build ended up in my lap without a lot of notice.)
I am just about ready to punt it to one of the software teams (with a perso nal note: "Good luck!"), or cobble-up a small microprocessor-controlled set of timed solid-state switches, and tell the rest of the team to live with it.
That said, we did discuss the idea of using an LMC567 tone decoder and the speaker-out from the NUC. It's kudgey as all hell, but might work a little better (i.e., less wasted time) than the timer approach. IDK.
power-up. The problem is a particular module has a nasty tendency to glitc h (with "improper power-up/down") but could (allegedly) be completely elimi nated if we can guarantee the NUC is fully booted before all the shit happe ns in the box. (My use of the technical term "shit" is more an outward exp ression of the fact that this abortion of a build ended up in my lap withou t a lot of notice.)
sonal note: "Good luck!"), or cobble-up a small microprocessor-controlled s et of timed solid-state switches, and tell the rest of the team to live wit h it.
e speaker-out from the NUC. It's kudgey as all hell, but might work a litt le better (i.e., less wasted time) than the timer approach. IDK.
how do you know that what ever software is controlling your DoThat is runni ng just because the NUC has booted?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.