Re: AW: [linuxsh-dev] printf

[Bryan R. <br...@ix...>]

"Studencki (external) Pawel" wrote:

> ========================================================
> Greg, I've put put some printks to debug function sci_set_baud and
> SCSMR = 0
> t = 26
> 
> I'm not sure, are these settings correct for my platform. According to
> hardware manual, I have to know "operating frequency for periphelar devices"
> to set SCBRR correct. Is this value showed at booting of kernel?

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?

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.

Comments?

Regards,

Bryan Rittmeyer
mailto:br...@ix...