然后先考究硬件,看看在硬件上到底能不能满足我们的要求,主控芯片S3C2440,在UART一章说在系统时钟下,波特率最高可达115200,然后注释中说如果Pclk达到60M,可以实现921600,我就按他说的,将主频提高,顺便将pclk提高到了60M,发现921600根本实现不了,230400波特率虽然能通,但是错误率很高,根本无法用,然后我又尝试着将Pclk提高到了70M,通过这种饮鸩止渴的方式,波特率可以提高到230400并且稳定传输,但是更高的波特率则无法实现,而Pclk不能无限提高,因为我们开发板还连接了触摸屏,在Pclk70M的情况下,触摸屏经常重启,说明这个方案不可行,所以就pass掉了,下面简单说一下我怎么更改的系统时钟Fclk,Hclk,Pclk。这三个时钟的关系以及计算方法我就不赘述了,我主要参考博客http://blog.csdn.NET/dong_zhihong/article/details/8469269进行修改
1)首先找到bootloader中 INC文件夹下的Option.inc文件,打开以后,找到如下代码段,这段代码就是主频400M时对应的M,P和S值设置,需要更改主频的话更改其中相应的数值几个(后来我发现,其实这个地方不改也行,因为最终起作用的是第二步)
[ FCLK = 400000000
CLKDIV_VAL EQU5
1:4:8
M_MDIV EQU
127 127
M_PDIV EQU
2 2
[ CPU_SEL = 32440001
M_SDIV EQU
1 2440A
|
M_SDIV EQU
0 2440X
]
]
2)找到u2440mon.c,然后在main()函数中找到如下代码,修改case2中的mpll_val = (92<<12)|(1<<4)|(1)这一行(为啥修改这一行?因为在这个switch代码有个j=2),其中三个数分别代表M,P,S。这才是决定主频的关键。
switch(j) {
case 0:
//240
key = 14
mpll_val = (112<<12)|(4<<4)|(1)
break
case 1:
//320
key = 14
mpll_val = (72<<12)|(1<<4)|(1)
break
case 2:
//400
key = 14
mpll_val = (92<<12)|(1<<4)|(1)
break
case 3:
//420!!!
key = 14
mpll_val = (97<<12)|(1<<4)|(1)
break
default:
key = 14
mpll_val = (92<<12)|(1<<4)|(1)
break
}
3)然后再 2440lib.c文件中,找到 ChangeClockDivider()函数,这个函数是控制分频比的,代码如下,这两个一个控制h_div,一个控制p_div。其中case 18: hdivn=2break这一行控制H分频,具体怎么改可以参考手册。
switch(hdivn_val) {
case 11: hdivn=0break
case 12: hdivn=1break
case 13:
case 16: hdivn=3break
case 14:
case 18: hdivn=2break
}
switch(pdivn_val) {
case 11: pdivn=0break
case 12: pdivn=1break
}
只需以上三步,就可以更改系统主频以及分频比,得到自己想要的Fclk和Pclk。
然后再说说我把上一个方案否定了以后,再仔细阅读芯片手册,发现串口的时钟源可以有三种方式获得:pclk,fclk/n,exclk,而且手册上说采用外部时钟的话,可以做到更高的波特率,但是这需要更改硬件,从指定那个引脚引入一个时钟,然后还要更改驱动程序,所以放弃了,所以只剩下一个路可以走,就是采用fclk/n的方式作为串口的时钟源,因为fclk频率很高,所以时钟源提高了,就可以把波特率提上来。然后就开始看linux内核源代码,因为串口的驱动早就集成到了linux内核之中,然后我就跳进了一个大坑。
其实串口本身的驱动并不复杂,如果裸机开发的话我感觉不难(强调一下,这个串口的裸机开发我没有做过,请做过的人不要喷我),因为串口被封装到了linux系统中,并且是层层封装,最终被封装成了tty的形式,所以我就从tty的驱动看起,抽丝剥茧,从里面寻找蛛丝马迹,
首先发现了s3c2440.c这个文件,通过调试得知,初始化的时候调用了其中的s3c2440_serial_init()函数,刚开始以为在这个文件中就这个函数有用,其实后来才知道,这个文件中的s3c2440_serial_getsource()和s3c2440_serial_setsource()在驱动中多次被调用。
然后考虑到,在上位机设置波特率的时候,调用的是系统函数cfsetispeed(),后经调试得知,这个函数调用了Samsung.c这个文件中的s3c24xx_serial_set_termios()这个函数,所有与串口相关的配置都与这个函数有关,因此锁定了方向,只要从这个函数中找到与波特率以及时钟源相关的语句,更改成我想要的即可,而这个函数又调用了很多子函数,但真正与波特率及时钟源相关的函数就是如下几句
/*
* Ask the core to calculate the divisor for us.
*/
baud = uart_get_baud_rate(port, termios, old, 0, 115200*8)
if (baud == 38400 &&(port->flags &UPF_SPD_MASK) == UPF_SPD_CUST)
quot = port->custom_divisor
else
quot = s3c24xx_serial_getclk(port, &clksrc, &clk, baud)
/* check to see if we need to change clock source */
if (ourport->clksrc != clksrc || ourport->baudclk != clk) {
s3c24xx_serial_setsource(port, clksrc)
if (ourport->baudclk != NULL &&!IS_ERR(ourport->baudclk)) {
clk_disable(ourport->baudclk)
ourport->baudclk = NULL
}
clk_enable(clk)
ourport->clksrc = clksrc
ourport->baudclk = clk
}
其中,uart_get_baud_rate()函数用于计算出上位机程序到设置的波特率的值,经我调试得知,上位机波特率从2400到921600都可以被准确的计算出来;所以这个函数跳过,然后看最后那个if语句,这个语句的作用是产看目前的时钟源是否与设置的时钟源相同,如果不相同,则按照设置的时钟源进行更改,这里面还涉及linux下的关于管理时钟的一个结构体clk结构体,参照博客http://blog.chinaunix.Net/uid-26583794-id-3208153.html以及http://wenku.baidu.com/view/13b4c686b9d528ea80c77904.html我找到了linux下的mach-smdk2440.c这个文件,这个文件中定义了串口所用的clk结构体,这也是linux系统启动时对串口的初始化配置结构体都在这,但是我更改过这个地方,让他初始化配置是首选fclk作为串口的时钟源,但是我发现这并没有效果,所以继续寻找中。
这样就剩下一个函数可以考虑了,s3c24xx_serial_getclk(),进入这个函数你会发现,这个函数是对串口时钟及波特率一个全面的配置,进入这个函数中,就有个结构体tmp_clksrc,这个结构体很关键,他的内容如下:
static struct s3c24xx_uart_clksrc tmp_clksrc = {
.name = "pclk",
.min_baud
= 0,
.max_baud
= 0,
.divisor
= 1,
}
从这个名字中就可以看出,它把串口的时钟源内定成为了pclk,这也是罪魁祸首,但是当我把name更改为fclk时,整个系统就无法启动了,包括前面说的更改mach-smdk2440.c中初始化配置,也是无法启动,后来在配置串口是做了一个判断,当波特率低于200000时,才有系统源配置不变,当波特率高于200000时,不在采用tmp_clksrc这个结构体,而是采用我自己定义的一个结构体,当然就是把name改成fclk,发现虽然只是能够更改 里面部分参数的时钟源,而正在的时钟源还是pclk,说明我的更改根本么有生效,由于这个linux调用太庞杂了,我就抱着试试看的态度,也是没有办法的办法,在配置完串口时钟的代码之后,添加了如下几行代码,直接更改S3C2440的寄存器,我知道这样做是很不“道德”的,而且很容易引起系统混乱,但是我只是这么试试,没想到还真的有用。
在 samsung.c文件中添加
if (baud >= 200000)
{
printk("baud >= 200000 @-------------samsung.c\n")
__raw_writel(0x1fc5,S3C24XX_VA_UART0 + S3C2410_UCON)
__raw_writel(0x0fc5,S3C24XX_VA_UART1 + S3C2410_UCON)
__raw_writel(0x8fc5,S3C24XX_VA_UART2 + S3C2410_UCON)
__raw_writel(32,S3C24XX_VA_UART0 + S3C2410_UCON+0x24)//保证控制台的波特率还是115200用于显示
__raw_writel(3,S3C24XX_VA_UART1 + S3C2410_UCON+0x24)//921600
//__raw_writel(3,S3C24XX_VA_UART1 + S3C2410_UCON+0x24)
}
上面这段代码经我多次试验得到的,因为一开始用的系统主时钟fclk为400M,这样算出来UBRDIV1分频应该为3,但是这样的话错误率比较高,还是导致无法传输,至此我终于明白手册上为什么说pclk在60M 可以实现921600了,因为用60M时钟计算的话,分频UBRDIV1为3.069,最接近整数3,所以在这个错误率下可以实现921600的波特率传输,所以我将系统时钟fclk设置为420M,其中MDIV=97,PDIV=1,SDIV=1,而ucon0=0x1fc5,ucon1=0x0fc5,ucon2=0x8fc5,这样n=1+6=7,所以串口的时钟源为fclk/n=60M,可以得到精确的921600波特率,所以实现我刚开始的目标,其实要实现其他的波特率也可以,比如460800,计算后主时钟fclk(尽量算出的分频UBRDIV1最贴近整数),然后就可以实现了。
在这还有个小想法,提高串口波特率,还可以使用USB转串口,因为USB转串口可以实现921600,而linux中以及集成了USB转串口的驱动,只需要在调用串口的那个open函数中改为调用USB转串口的节点即可,当然,这个方案我没有试,因为我们就一个USB口,而且还被占用了,所以希望有需要的朋友可以试一下。
我之所以发表同样内容的文章是因为我的文章是一系列的,不会因为别人写过我就不写了。另外我对串口通信有着自己的观点。现在大多数的笔记本电脑都没有外置串口,这不奇怪,因为有更快更稳定的接口代替了串口。不过基于 Windows CE 的设备仍然保留着串口,而且目前看来串口的地位暂时不会动摇。目前流行的基于CE的设备很多都具有像导航、打电话等功能,而GPS、GSM/GPRS模块都是外置串口的终端设备,你想不用串口都不行。
上面我说了我有着自己的观点,我的观点就是不要把串口通信封装成类。我不明白为什么有些人总要把串口封装成类呢。把一个事物封装成类,那这个事物就一定是不易改变的,如果每次编写都要修改,那封装成类就一点意义都没有了。设想如果MFC类总要改变的话,那我们用MFC编的程序也要修改同样次数了。如果编写超级终端一类的程序倒是可以将串口封装成类,因为超级终端只管输入命令和显示输出数据,不对输出数据进行处理,那读串口的函数就可以一直使用而不必更改。但事实上串口通信大多数用来与终端设备进行通信,需要对终端设备返回的数据进行处理。而返回的数据在什么时间返回、数据量的大小不是确定的,非要封装成类难度很大。
正如CE的帮助文档所说,串口通信是最简单的通信之一。稍麻烦的是在读数据方面。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)