I have a serial daughter board that I need to detect on boot up of my
target device and was hoping to conditionally launch the serial-port
driver based on the daughter board’s presence. I can detect the board
fine, but I can’t seem to find a conditional command that I can use in
the “.script” portion of the build file - it seems that a command for
branching is not included in the “built-in” commands (reopen, display,
etc…).
I thought I would be clever and write a program that sets and exports an
environment variable (based on detection of the serial board) but it
seems that environment variable expansion (i.e. putting $myenvvar into
the “.script”) does not work either.
Is there some way I can put conditionally executed statements in the
“.script” portion of a build file to influence what gets started during
boot-up?
Thanks in advance!
-george
Why not just have a process that detects for the serial daughter board, and
spawns the driver if present?
-Adam
George Broz <gbroz@earthlink.net> wrote in message
news:3E3EA01C.2E264E5E@earthlink.net…
I have a serial daughter board that I need to detect on boot up of my
target device and was hoping to conditionally launch the serial-port
driver based on the daughter board’s presence. I can detect the board
fine, but I can’t seem to find a conditional command that I can use in
the “.script” portion of the build file - it seems that a command for
branching is not included in the “built-in” commands (reopen, display,
etc…).
I thought I would be clever and write a program that sets and exports an
environment variable (based on detection of the serial board) but it
seems that environment variable expansion (i.e. putting $myenvvar into
the “.script”) does not work either.
Is there some way I can put conditionally executed statements in the
“.script” portion of a build file to influence what gets started during
boot-up?
Thanks in advance!
-george
Mike Lee <mikel@berkeleyprocess.com> wrote:
The presence of the daughter board determines where I send debug information
(either /dev/null or /dev/ser1) during boot-up. So I need to “reopen” to
redirect standard in/out/err after I launch (or don’t launch) the driver.
(Aside from linking the console port using ln -sP).
I don’t know how to do the “reopen” programmatically (from within the
process that I would spawn the driver), so I was hoping to use a conditional
or just do something like “reopen $mydevice” from within .script but that
doesn’t work.
Is there a way I can do the redirection from within a C-program (to redirect
subsequent messages in the bootscript)?
Perhaps your programs can use the process manager filesystem to
leave droppings for themselves? I’m thinking something like
a procmgr symlink from /dev/my_standard_output which would then
be redirected to /dev/null or /dev/ser1…
It’s ln -sP from the command line; don’t have the docs handy here
for the C API function…
Cheers,
-RK
thanks,
-george
“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:b1mblp$90e$> 1@nntp.qnx.com> …
Why not just have a process that detects for the serial daughter board,
and
spawns the driver if present?
-Adam
George Broz <> gbroz@earthlink.net> > wrote in message
news:> 3E3EA01C.2E264E5E@earthlink.net> …
I have a serial daughter board that I need to detect on boot up of my
target device and was hoping to conditionally launch the serial-port
driver based on the daughter board’s presence. I can detect the board
fine, but I can’t seem to find a conditional command that I can use in
the “.script” portion of the build file - it seems that a command for
branching is not included in the “built-in” commands (reopen, display,
etc…).
I thought I would be clever and write a program that sets and exports an
environment variable (based on detection of the serial board) but it
seems that environment variable expansion (i.e. putting $myenvvar into
the “.script”) does not work either.
Is there some way I can put conditionally executed statements in the
“.script” portion of a build file to influence what gets started during
boot-up?
Thanks in advance!
-george
\
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Robert Krten <nospam84@parse.com> wrote:
Mike Lee <> mikel@berkeleyprocess.com> > wrote:
The presence of the daughter board determines where I send debug information
(either /dev/null or /dev/ser1) during boot-up. So I need to “reopen” to
redirect standard in/out/err after I launch (or don’t launch) the driver.
(Aside from linking the console port using ln -sP).
I don’t know how to do the “reopen” programmatically (from within the
process that I would spawn the driver), so I was hoping to use a conditional
or just do something like “reopen $mydevice” from within .script but that
doesn’t work.
Is there a way I can do the redirection from within a C-program (to redirect
subsequent messages in the bootscript)?
Perhaps your programs can use the process manager filesystem to
leave droppings for themselves? I’m thinking something like
a procmgr symlink from /dev/my_standard_output which would then
be redirected to /dev/null or /dev/ser1…
It’s ln -sP from the command line; don’t have the docs handy here
for the C API function…
Or, write a process that detects the daughter board and returns true
or false. Then your sysinit (or whichever) script can simply test for
true or false and do all the necessary stuff, including a reopen.
–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net
The presence of the daughter board determines where I send debug information
(either /dev/null or /dev/ser1) during boot-up. So I need to “reopen” to
redirect standard in/out/err after I launch (or don’t launch) the driver.
(Aside from linking the console port using ln -sP).
I don’t know how to do the “reopen” programmatically (from within the
process that I would spawn the driver), so I was hoping to use a conditional
or just do something like “reopen $mydevice” from within .script but that
doesn’t work.
Is there a way I can do the redirection from within a C-program (to redirect
subsequent messages in the bootscript)?
thanks,
-george
“Adam Mallory” <amallory@qnx.com> wrote in message
news:b1mblp$90e$1@nntp.qnx.com…
Why not just have a process that detects for the serial daughter board,
and
spawns the driver if present?
-Adam
George Broz <> gbroz@earthlink.net> > wrote in message
news:> 3E3EA01C.2E264E5E@earthlink.net> …
I have a serial daughter board that I need to detect on boot up of my
target device and was hoping to conditionally launch the serial-port
driver based on the daughter board’s presence. I can detect the board
fine, but I can’t seem to find a conditional command that I can use in
the “.script” portion of the build file - it seems that a command for
branching is not included in the “built-in” commands (reopen, display,
etc…).
I thought I would be clever and write a program that sets and exports an
environment variable (based on detection of the serial board) but it
seems that environment variable expansion (i.e. putting $myenvvar into
the “.script”) does not work either.
Is there some way I can put conditionally executed statements in the
“.script” portion of a build file to influence what gets started during
boot-up?
Thanks in advance!
-george
Thanks. I can write the process that returns true or false. But the problem
is that within the “.script” portion of the build file, there doesn’t seem
to be any branching-type commands supported. It seems the boot script runs
under a limited esh shell, and the documentation implies that commands like
“if-then-else” (or any equivalent branching construct) are not available.
(At least that’s the impression I get confirmed by the results of my
trials).
Do you know what command I can use to test for true/false in the “.script”
portion of the build file?
Thanks!
-george
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:b1mgr9$mv6$2@inn.qnx.com…
Robert Krten <> nospam84@parse.com> > wrote:
Mike Lee <> mikel@berkeleyprocess.com> > wrote:
The presence of the daughter board determines where I send debug
information
(either /dev/null or /dev/ser1) during boot-up. So I need to “reopen”
to
redirect standard in/out/err after I launch (or don’t launch) the
driver.
(Aside from linking the console port using ln -sP).
I don’t know how to do the “reopen” programmatically (from within the
process that I would spawn the driver), so I was hoping to use a
conditional
or just do something like “reopen $mydevice” from within .script but
that
doesn’t work.
Is there a way I can do the redirection from within a C-program (to
redirect
subsequent messages in the bootscript)?
Perhaps your programs can use the process manager filesystem to
leave droppings for themselves? I’m thinking something like
a procmgr symlink from /dev/my_standard_output which would then
be redirected to /dev/null or /dev/ser1…
It’s ln -sP from the command line; don’t have the docs handy here
for the C API function…
Or, write a process that detects the daughter board and returns true
or false. Then your sysinit (or whichever) script can simply test for
true or false and do all the necessary stuff, including a reopen.
–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net
Mike Lee <mikel@berkeleyprocess.com> wrote:
Thanks. I can write the process that returns true or false. But the problem
is that within the “.script” portion of the build file, there doesn’t seem
to be any branching-type commands supported. It seems the boot script runs
under a limited esh shell, and the documentation implies that commands like
“if-then-else” (or any equivalent branching construct) are not available.
(At least that’s the impression I get confirmed by the results of my
trials).
Do you know what command I can use to test for true/false in the “.script”
portion of the build file?
Sorry. I missed the fact that you wanted to do this in the boot startup
script.
–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net
I will definitely try this in absence of being able to find a
branch-construct (command) that can be used in the bootscript.
thanks!
-george
“Robert Krten” <nospam84@parse.com> wrote in message
news:b1mg74$laf$1@inn.qnx.com…
Mike Lee <> mikel@berkeleyprocess.com> > wrote:
The presence of the daughter board determines where I send debug
information
(either /dev/null or /dev/ser1) during boot-up. So I need to “reopen” to
redirect standard in/out/err after I launch (or don’t launch) the
driver.
(Aside from linking the console port using ln -sP).
I don’t know how to do the “reopen” programmatically (from within the
process that I would spawn the driver), so I was hoping to use a
conditional
or just do something like “reopen $mydevice” from within .script but
that
doesn’t work.
Is there a way I can do the redirection from within a C-program (to
redirect
subsequent messages in the bootscript)?
Perhaps your programs can use the process manager filesystem to
leave droppings for themselves? I’m thinking something like
a procmgr symlink from /dev/my_standard_output which would then
be redirected to /dev/null or /dev/ser1…
It’s ln -sP from the command line; don’t have the docs handy here
for the C API function…
Cheers,
-RK
thanks,
-george
“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:b1mblp$90e$> 1@nntp.qnx.com> …
Why not just have a process that detects for the serial daughter board,
and
spawns the driver if present?
-Adam
George Broz <> gbroz@earthlink.net> > wrote in message
news:> 3E3EA01C.2E264E5E@earthlink.net> …
I have a serial daughter board that I need to detect on boot up of my
target device and was hoping to conditionally launch the serial-port
driver based on the daughter board’s presence. I can detect the board
fine, but I can’t seem to find a conditional command that I can use i
n
the “.script” portion of the build file - it seems that a command for
branching is not included in the “built-in” commands (reopen,
display,
etc…).
I thought I would be clever and write a program that sets and exports
an
environment variable (based on detection of the serial board) but it
seems that environment variable expansion (i.e. putting $myenvvar
into
the “.script”) does not work either.
Is there some way I can put conditionally executed statements in the
“.script” portion of a build file to influence what gets started
during
boot-up?
Thanks in advance!
-george
\
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.
George Broz <gbroz@earthlink.net> wrote:
Is there some way I can put conditionally executed statements in the
“.script” portion of a build file to influence what gets started during
boot-up?
There is no branch or conditional construct in the (very limitted)
script language available to you in the [+script] portion of the
boot image. (Note: it need not be called .script, it is the [+script]
attribute that is important.)
Since you need to do the equivalent of a reopen, you will probably
have to use the creation of a PROC level symlink (“ln -P”) and reopen
that link, which will point to the right place.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Nothing prevents you from doing something like this:
[+script] .script={
…
sh /proc/boot/boot-rc
}
boot-rc={
normal shell syntax here
}
That’s what we do.
– igor
Mike Lee wrote:
Thanks. I can write the process that returns true or false. But the problem
is that within the “.script” portion of the build file, there doesn’t seem
to be any branching-type commands supported. It seems the boot script runs
under a limited esh shell, and the documentation implies that commands like
“if-then-else” (or any equivalent branching construct) are not available.
(At least that’s the impression I get confirmed by the results of my
trials).
Do you know what command I can use to test for true/false in the “.script”
portion of the build file?
Thanks!
-george
“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:b1mgr9$mv6$> 2@inn.qnx.com> …
Robert Krten <> nospam84@parse.com> > wrote:
Mike Lee <> mikel@berkeleyprocess.com> > wrote:
The presence of the daughter board determines where I send debug
information
(either /dev/null or /dev/ser1) during boot-up. So I need to “reopen”
to
redirect standard in/out/err after I launch (or don’t launch) the
driver.
(Aside from linking the console port using ln -sP).
I don’t know how to do the “reopen” programmatically (from within the
process that I would spawn the driver), so I was hoping to use a
conditional
or just do something like “reopen $mydevice” from within .script but
that
doesn’t work.
Is there a way I can do the redirection from within a C-program (to
redirect
subsequent messages in the bootscript)?
Perhaps your programs can use the process manager filesystem to
leave droppings for themselves? I’m thinking something like
a procmgr symlink from /dev/my_standard_output which would then
be redirected to /dev/null or /dev/ser1…
It’s ln -sP from the command line; don’t have the docs handy here
for the C API function…
Or, write a process that detects the daughter board and returns true
or false. Then your sysinit (or whichever) script can simply test for
true or false and do all the necessary stuff, including a reopen.
–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net