Problems with printk() function
gedare at rtems.org
Mon Dec 19 21:48:23 UTC 2011
On Mon, Dec 19, 2011 at 4:24 AM, Hoover, Victor P CTR NAVAIR, AIR
184.108.40.206 <victor.hoover.ctr at navy.mil> wrote:
>> -----Original Message-----
>> From: rtems-users-bounces at rtems.org [mailto:rtems-users-
>> bounces at rtems.org] On Behalf Of Sebastian Huber
>> Sent: Monday, December 19, 2011 3:59
>> To: rtems-users at rtems.org
>> Subject: Re: Problems with printk() function
>> On 12/19/2011 09:25 AM, Hoover, Victor P CTR NAVAIR, AIR 220.127.116.11 wrote:
>> > I'm having a couple of problems with the printk() function.
>> > a) The optional precision value doesn't seem to be supported for
>> > hexadecimal values (types x and X). Then again, I haven't
>> played with
>> > it enough yet to see if precision is supported at all...
>> printk() is used normally for debug output and/or contexts which allow
>> printf() (e.g. interrupt context, exception handler). It doesn't
>> support all
>> formats available via printf().
> I understand its purpose and it obviously isn't supporting the precision
> value in this case. I questioned this because all of the existing debug
> code in the network.c module I'm debugging uses %2.2x for displays. I
> would think that if the precision field wasn't supported then the original
> code wouldn't be trying to use it.
> I couldn't find anything specific to this searching through the mailing
> list and the bugzilla data base. However I do recall seeing a posting
> somewhere saying that printk() should support all sprint() capabilities.
> The question really becomes, is it supposed to support precision values.
>> > b) If the format string does not end with a newline character, no
>> output is
>> > displayed.
>> This is probably a problem with the program which displays the output.
> I'm not clear on what program you're referring to here. I'm working with
> the MVME162 BSP. Originally it did not have low level support for printk()
> in the BSP; I added it. The function that gets called to handle the output
> accepts and displays a single character at a time. The problem would have
> to be at a higher level than the BSP code to exhibit this behavior.
If you are connecting over a serial line with something like telnet,
it may not be flushing the output buffer until a new line is sent or
received (depending whether the issue is host or client side). Just a
>> Sebastian Huber, embedded brains GmbH
>> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>> Phone : +49 89 18 90 80 79-6
>> Fax : +49 89 18 90 80 79-9
>> E-Mail : sebastian.huber at embedded-brains.de
>> PGP : Public key available on request.
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> rtems-users mailing list
>> rtems-users at rtems.org
> rtems-users mailing list
> rtems-users at rtems.org
More information about the users