×
单片机 > 单片机程序设计 > 详情

S3C6410 硬件JPEG解码无关代码影响解码问题终于得以解决

发布时间:2020-05-18 发布时间:
|

早在今年8月份的时候就将jpeg解码弄好了,但是一直以来非常的不稳定,如果修改了任意地方的代码都会造成解码可能失败,起初我以为是堆栈问题,或者后面有非法指针,但是都没得到结果,最后让我只能怀疑编译器了,而且我同样的程序使用了RVDS4.0编译后JPEG解码老是等待超时,但是可以解码头部,得到相关的JPEG信息,就是无法解码图片主体部分,我换到RVDS2.2上面竟然解码成功了,同样的程序,不同的编译器结果不一样,让我对RVDS4.0十分的失望,但是无意间我发现RVDS2.2也出现修改无关代码后JPEG无法解码了,我意识到我错怪RVDS4.0了,我开始另想办法了,当我仔细阅读S3C6410 dataset的后,终于找到一线希望了,文中说道,JPEG CODE最高时钟不能超过66MHz,我当时就修改了JPEG的时钟分频,给的是4分频,刚好是66MHz,恰在此时解码又成功了,让我高兴了不久,没过多大一会,又悲剧了,打印的信息显示解码失败,等待超时,我开始怀疑是编译的地址,我就开始打印各个缓冲区,指针,变量的地址,最终发现了一个问题,就是只有源图像地址的那个指针如果最后一位为0(16进制),解码就成功了,试了很多次,这个结论是对的,最终找出了问题所在了,源图像地址必须是16字节地址对齐的,这就能解释我之前遇到的种种不可思议的问题了。

        很高兴,只要添加一句代码就能解决这个问题了,因为32bit的CPU,编译器默认是32位对齐的。

 


  1. if(JpgAddr % 16)        //源地址一定要是16字节(128位)对齐的,否则会出现各种意想不到的问题,这个问题困扰了我5个多月。  

  2.         JpgAddr = (JpgAddr / 16 + 1) * 16;  


这样,可以在申请了源图像缓冲区后,使用一个指针,指向这个缓冲区起始位置最近的那个128位对齐的地址,即可解决这个问题。




『本文转载自网络,版权归原作者所有,如有侵权请联系删除』

热门文章 更多
STM32中断向量表的位置.重定向