stm32移植ecos #18，ADC驱动和应用编程（下）

上节说道，在ADC应用中，我遇到了一个问题：只要我在eCos图形配置工具中打开了ADC的任何一个通道，则不能生成正常的bin格式映像文件（但可生成正常的srec格式映像文件），如果不打开ADC任何一个通道，则可以输出正常的bin格式文件。

这个问题很纠结，最后，哥用暴力解决了！

第1招：E-mail求助

从问题现象看，似乎eCos配置上出了问题。目前尚不太懂eCos的CDL语言，所以无法从配置上看哪里出了问题。为此，我写了个E-mail给ecos-discuss（eCos邮件列表中的一个讨论组），但从邮件讨论列表看，我发的E-mail，人家没有收到。看来后面我得研究下如何通过邮件列表向eCos维护人员求助问题。

第2招：更换交叉编译器

偶然间，在看eCos的邮件列表的时候，发现有关ARM交叉编译器的说明：对于像cortex-M3处理器的，推荐使用新版本的ARM交叉编译器。

新的交叉编译器（eCos arm-eabi GNU tools – test release 4.6.3-20120623）：http://ecos.sourceware.org/ml/ecos-discuss/2012-06/msg00047.html

注：后续文章中，如果没有特殊说明，使用的皆是这个新版本的交叉编译器。

需注意，使用这个版本交叉编译器编译出来的映像文件，其入口地址不再是之前的0x68008019，而是变为了0x68008011。

不过，另人郁闷的是，还是照样不能生成正常的bin格式映像文件。

第3招：暴力解决

在eCos图形配置工具中，不使能ADC的任何通道（但打开ADC1），然后在adc1.inl源文件末尾，强行添加ADC1 channel14和ADC1 channel16，如下代码：

// Added start by reille 2013.04.24 
#define CYGDAT_DEVS_ADC_CORTEXM_STM32_ADC1_CHANNEL14_NAME "/dev/adc014" 
#define CYGDAT_DEVS_ADC_CORTEXM_STM32_ADC1_CHANNEL14_BUFSIZE    128 
STM32_ADC_CHANNEL(1, 14)

#define CYGDAT_DEVS_ADC_CORTEXM_STM32_ADC1_CHANNEL16_NAME "/dev/adc016" 
#define CYGDAT_DEVS_ADC_CORTEXM_STM32_ADC1_CHANNEL16_BUFSIZE    128 
STM32_ADC_CHANNEL(1, 16) 
// Added end by reille 2013.04.24

重新编译生成eCos库文件，再链接编译出应用程序，这时可生成正常的bin格式映像文件了，当然还有srec格式映像文件。

总结

对于这个问题，虽然用暴力的方法解决了，但原因尚未可知。我的推测应该是eCos图形工具配置时导致的，当然后续我也会跟进这个问题，不排除使用E-mail向ecos-discuss求助这个问题，毕竟用图形工具进行配置才是正道，而且最重要的是：用起来非常方便，不需要修改源代码！

如果你也遇到了类似问题，或者有什么解决思路，可以在这里留言给我，不甚感激！