Re: AW: [linuxsh-dev] printf

[<su...@it...>]

At 16:52 00/08/23 -0700, Bryan Rittmeyer wrote:
>
>Maybe I'm crazy, but I think there is a problem in sh-sci.h:
>
>#define SCBRR_VALUE(bps) ((PCLK+16*bps)/(32*bps)-1)
>
>Looks like most of the active people on this list (all of which know
>more than I do) had their hands in sh-sci.h at some point, but
>nonetheless I suspect this is more correct:
>
>#define SCBRR_VALUE(bps) ((PCLK)/(32*bps)-1)
>
>I am not sure where that +16*bps term came from, but I have not used it
>for my calculations and it seems to just introduce a slight error (When
>PCLK is something like 50000000, 16*bps introduces about a 2% addition
>at 57600) At lower clock frequencies and high baud rates, this factor
>becomes more important... but if I recall correctly it is NOT listed in
>the SH4 data sheet. So what's going on with SCBRR_VALUE?
>

I think +16*bps means 'round to nearest value'.
usually on integer division, result is rounded toward 0.
adding half of divider before division, changes this behavior.
So I think sh-sci.h is correct.

>Hitachi SH4 datasheet h14th003d5.pdf (the Hardware Manual) lists this on
>page 534:
>
>N = [PCLK / (64 * 2^((2*n)-1) * bps)]-1
>
>n=0 for our case, so that is clearly N = [PCLK / (32 * bps)] - 1
>
>Assuming he was using 38400 with a 25 MHz clock (my assumptions, since
>he mentioned t=19 fixed the problems) my correction generates the proper
>result, whereas the define in sourceforge CVS's sh-sci.h does not (it
>generates 20) It's slight, and RS-232C is pretty tolerant (+-2% is
>guaranteed safe, but usually up to 5-10% still works), but I believe
>sh-sci.h is incorrect.
>

in my environment, both generates correct value 19 in this case.

Regards,

----
Sugioka Toshinobu