I don't think I made it clear that I'm always issuing commands to the telnet window and expecting the responses in the telnet window.
Some times after I boot the system if I telnet to ti and issue the command "spg motor.*log 1" it will generate output in the telnet window, as I expect it to, but on other boots "spg motor*log 1" will generate output in the serial console window, which is totally unexpected and means I need to keep an eye on the console. This is fine right now, since I'm too busy to fix it, but I can't have normal engineers start using the software. > On Mar 29, 2015, at 14:47 , Peter Dufault <dufa...@hda.com> wrote: > > >> On Mar 29, 2015, at 13:06 , Joel Sherrill <joel.sherr...@oarcorp.com> wrote: >> >> If it is a one-time thing at boot issues, then it may simply be a printk() >> during the BSP initialization or a printf() before the telnet session is >> initiated. >> >> Can you capture the string? That would help locate it. >> > By one-time I mean after the RTEMS process boots, I think output goes to > either the telnet session or the serial console. I don't mean to be > loosey-goosey here, but I don't want to state something I'm not 100% sure of. > > I have "spg" and "gpg" (set parameters with globbing, get parameters with > globbing) commands in the RTEMS shell to "set parameters with globbing" and > "get parameters with globbing", where globbing means the pattern is expanded > as a regular expression. When I do "spg" it may set multiple parameters based > on the pattern, so I can issue a command such as "spg motor.*log 1" to turn > logging on all motors. The "spg" command uses fprintf() to print the changes > it makes to multiple variables to stderr, so that I can see what parameters > were changed. > > Sometimes the changes are displayed in the telnet window, and other times the > changes are displayed in the serial console window. They are always displayed > in one or the other, and I *think* (but I won't promise) that where they are > displayed (telnet window versus serial console) persists until a reboot. > > Peter > ----------------- > Peter Dufault > HD Associates, Inc. Software and System Engineering > Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
