OT - Electronics / Computer question

[mpm]

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.

 

On Wednesday, March 25, 2020 at 12:04:56 PM UTC-7, mpm wrote:

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.

I don't get it. Aren't you running a custom control program for your hardware that won't be activated until booting is done?

 

[Phil Hobbs]

On 2020-03-25 15:04, mpm wrote:

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.

Guess you can't just use a printer port pin.

You could use something like a Bus Pirate.

Cheers

Phil Hobbs

--
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

 

[John Larkin]

On Wed, 25 Mar 2020 12:04:47 -0700 (PDT), mpm <mpmillard@aol.com>
wrote:

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.

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

 

[mpm]

On Wednesday, March 25, 2020 at 3:14:06 PM UTC-4, edward...@gmail.com wrote:

> I don't get it. Aren't you running a custom control program for your hardware that won't be activated until booting is done?

It's a complicated box-build with (in my opinion) too many fingers in the mix.
It's not clear that (other than hardware) we have much control over what software ultimately goes on the NUC when it is all said and done. Software mostly 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 for basic operation) due to ITAR regulations about exporting certain technologies. (That's a quagmire all its own...)

I'm hoping for something hardware-wise on the NUC, and if not, then the simplest thing possible to know it has finished booting.

 

[Dave Platt]

In article <cdc90e25-d962-447d-80eb-47e8105a7935@googlegroups.com>,
mpm <mpmillard@aol.com> wrote:

I'm hoping for something hardware-wise on the NUC, and if not, then the simplest thing possible to know it
has finished booting.

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.

 

[John Larkin]

On Wed, 25 Mar 2020 14:51:10 -0700 (PDT), mpm <mpmillard@aol.com>
wrote:

On Wednesday, March 25, 2020 at 3:42:44 PM UTC-4, John Larkin wrote:
What sorts of ports does the NUC have?

Near as I can tell...

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 <-- this might be the ticket?!
LED for HD operation

Supposedly the NUC part#: blknuci7bnbe

A USB-RS232 dongle could give you an output on RTS or something.

--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

 

[piglet]

On 25/03/2020 21:51, mpm wrote:

On Wednesday, March 25, 2020 at 3:42:44 PM UTC-4, John Larkin wrote:
What sorts of ports does the NUC have?

Near as I can tell...

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 <-- this might be the ticket?!
LED for HD operation

Supposedly the NUC part#: blknuci7bnbe

Headphone jack - listen for the sign-on melody?

piglet

 

[mpm]

On Wednesday, March 25, 2020 at 3:42:44 PM UTC-4, John Larkin wrote:

What sorts of ports does the NUC have?

Near as I can tell...

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 <-- this might be the ticket?!
LED for HD operation

Supposedly the NUC part#: blknuci7bnbe

 

[Rick C]

On Wednesday, March 25, 2020 at 3:04:56 PM UTC-4, mpm wrote:

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.

How exactly do you define "finished booting"?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[mpm]

On Wednesday, March 25, 2020 at 8:01:54 PM UTC-4, Rick C wrote:
> How exactly do you define "finished booting"?

THAT is an excellent question.

 

[mpm]

On Wednesday, March 25, 2020 at 10:12:10 PM UTC-4, edward...@gmail.com wrote:

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.

 

On Wednesday, March 25, 2020 at 6:38:06 PM UTC-7, mpm wrote:

On Wednesday, March 25, 2020 at 8:01:54 PM UTC-4, Rick C wrote:
How exactly do you define "finished booting"?

THAT is an excellent question.

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.

 

[whit3rd]

On Wednesday, March 25, 2020 at 7:43:22 PM UTC-7, mpm wrote:

On Wednesday, March 25, 2020 at 10:12:10 PM UTC-4, edward...@gmail.com wrote:

Another question is why would you care if the system is not done booting?

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.

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.

 

[Rick C]

On Wednesday, March 25, 2020 at 9:38:06 PM UTC-4, mpm wrote:

On Wednesday, March 25, 2020 at 8:01:54 PM UTC-4, Rick C wrote:
How exactly do you define "finished booting"?

THAT is an excellent question.

Just put a command in the autoexec.bat file.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

Rick C <gnuarm.deletethisbit@gmail.com> wrote in news:46a3ef6d-bda3-
4608-a769-216832e950b4@googlegroups.com:

On Wednesday, March 25, 2020 at 9:38:06 PM UTC-4, mpm wrote:
On Wednesday, March 25, 2020 at 8:01:54 PM UTC-4, Rick C wrote:
How exactly do you define "finished booting"?

THAT is an excellent question.

Just put a command in the autoexec.bat file.

To blink an LED for ten seconds

 

[Clifford Heath]

On 26/3/20 6:04 am, mpm wrote:

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.

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.

CH

 

[Tom Del Rosso]

mpm wrote:

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.

But *how* would you power up those devices anyway? Doesn't the
controller have to boot before it *could* power them up?

 

[Lasse Langwadt Christense]

fredag den 27. marts 2020 kl. 02.25.03 UTC+1 skrev mpm:

On Thursday, March 26, 2020 at 6:46:05 PM UTC-4, Tom Del Rosso wrote:
mpm wrote:
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.

But *how* would you power up those devices anyway? Doesn't the
controller have to boot before it *could* power them up?

It's a complex box. There are something like (30) different things that power-up. The problem is a particular module has a nasty tendency to glitch (with "improper power-up/down") but could (allegedly) be completely eliminated 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 expression 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 personal 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.

how do you know that what ever software is controlling your DoThat is running just because the NUC has booted?

 

[mpm]

On Thursday, March 26, 2020 at 6:46:05 PM UTC-4, Tom Del Rosso wrote:

mpm wrote:
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.

But *how* would you power up those devices anyway? Doesn't the
controller have to boot before it *could* power them up?

It's a complex box. There are something like (30) different things that power-up. The problem is a particular module has a nasty tendency to glitch (with "improper power-up/down") but could (allegedly) be completely eliminated 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 expression 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 personal 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.