OT - Electronics / Computer question

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.

Re: OT - Electronics / Computer question
On Wednesday, March 25, 2020 at 12:04:56 PM UTC-7, mpm wrote:
Quoted text here. Click to load it

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?


Re: OT - Electronics / Computer question
:
  
Quoted text here. Click to load it
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.




Re: OT - Electronics / Computer question

Quoted text here. Click to load it

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.





Re: OT - Electronics / Computer question
On 2020-03-25 15:04, mpm wrote:
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: OT - Electronics / Computer question
wrote:

Quoted text here. Click to load it

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  

We've slightly trimmed the long signature. Click to see the full one.
Re: OT - Electronics / Computer question
On Wednesday, March 25, 2020 at 3:42:44 PM UTC-4, John Larkin wrote:
Quoted text here. Click to load it
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

Re: OT - Electronics / Computer question
On 25/03/2020 21:51, mpm wrote:
Quoted text here. Click to load it
Headphone jack - listen for the sign-on melody?

piglet


Re: OT - Electronics / Computer question
wrote:

Quoted text here. Click to load it

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

--  

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement  

We've slightly trimmed the long signature. Click to see the full one.
Re: OT - Electronics / Computer question
Quoted text here. Click to load it

Externally USB and HDMI/DisplayPort, Ethernet, and maybe analog audio,
internally SATA, M.2 and other PCIe variants, (often) Serial
port header, and SMB if you know where to solder.

--  
  Jasen.

Re: OT - Electronics / Computer question
On Wednesday, March 25, 2020 at 3:04:56 PM UTC-4, mpm wrote:
Quoted text here. Click to load it

How exactly do you define "finished booting"?  

--  

  Rick C.

  - Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: OT - Electronics / Computer question
On Wednesday, March 25, 2020 at 8:01:54 PM UTC-4, Rick C wrote:
Quoted text here. Click to load it

THAT is an excellent question.


Re: OT - Electronics / Computer question
On Wednesday, March 25, 2020 at 6:38:06 PM UTC-7, mpm wrote:
Quoted text here. Click to load it

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.

Re: OT - Electronics / Computer question
On Wednesday, March 25, 2020 at 10:12:10 PM UTC-4, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

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.

Re: OT - Electronics / Computer question
On Wednesday, March 25, 2020 at 7:43:22 PM UTC-7, mpm wrote:
Quoted text here. Click to load it


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.

Re: OT - Electronics / Computer question
On Wednesday, March 25, 2020 at 9:38:06 PM UTC-4, mpm wrote:
Quoted text here. Click to load it

Just put a command in the autoexec.bat file.  

--  

  Rick C.

  + Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: OT - Electronics / Computer question
snipped-for-privacy@googlegroups.com:

Quoted text here. Click to load it

  To blink an LED for ten seconds

Re: OT - Electronics / Computer question
On 26/3/20 6:04 am, mpm wrote:
Quoted text here. Click to load it

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

Re: OT - Electronics / Computer question
mpm wrote:
Quoted text here. Click to load it

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




Re: OT - Electronics / Computer question
On Thursday, March 26, 2020 at 6:46:05 PM UTC-4, Tom Del Rosso wrote:
Quoted text here. Click to load it

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.

Site Timeline