driver new building

最新推荐文章于 2019-03-06 10:51:15 发布
原创 最新推荐文章于 2019-03-06 10:51:15 发布 · 244 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#books #build

本文探讨了结构构建、内存管理及保护等主题。讨论了预抢占计数、区域保护等概念，并提到了符号使用情况的研究。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

__refdata  //?

arrays init //try again

kfifo usage study

preempt count

area protection

 

structure build

arch build thinking // any books on it ?

 print_symbol usage ?

 

 

Debezium报错处理系列之五十九：The driver could not establish a secure connection to SQL Server by using Secure
zhengzaifeidelushang的博客
04-12 2579
Debezium报错处理系列之五十九：The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer SSL encryption
Building Conversational Agents with Python and Tensorflow
AI天才研究院
08-03 1582
AI已经成为我们的生活中不可或缺的一部分。它可以让我们做任何事情，把我电脑变成你的计算器，帮助我们找到工作，为我们节省时间、金钱或者更多，还可以通过自然语言进行沟通。我们用聊天机器人、自动助手、Siri、Alexa等各种不同形式的应用来与计算机互动。它们都能够理解和交流人类语言，并通过音频、视频、文本进行通信。近年来，越来越多的公司和个人已经开始致力于研发基于AI的聊天机器人系统，比如谷歌的DialogFlow和微软的Bot Framework。
【Linux Device Driver】(3edtion).pdf
09-20
2. Building and Running Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Setting Up Your Test System 15 The Hello World Module 16 Kernel Modules Versus ...
mozilla firfox geckodriver v0.23.0 火狐 webdriver
11-20
The SHA1 used in --version when building geckodriver from a git repository is now limited to 12 characters, as it is when building from an hg checkout. This ensures reproducible builds.
USB Driver
u014742281的专栏
03-06 1932
USB Driver基于linux的usb驱动及libusb的常用接口usb的硬件设计usb协议Linux usb驱动libusb的使用 基于linux的usb驱动及libusb的常用接口 基于linux的usb驱动分析和host端基于libusb的接口实现usb的读写. usb的硬件设计 USB的硬件设计简单介绍 usb协议 USB的概念和协议等. 问1. 既然还没有"驱动程序"，为何能知道
ioctl compat_ioctl unlock_ioctl
07-08 6368
<br />区别：<br />ioctl 和 unlock_ioctl <br />ioctl 不会lock_kernel()<br /> <br />compat_ioctl被使用在用户空间为32位模式，而内核运行在64位模式时。这时候，需要将64位转成32位。<br /> <br />引用<br />http://blog.chinaunix.net/u1/38994/showart_2248151.html<br />对几个ioctl执行顺序的分析<br /> <br />关于ioctl,unlock
ramfs 和 ramdisk 的区别
04-13 2122
　　Ramdisk, ramfs, tmpfs.　　① 第一种就是传统意义上的，可以格式化，然后加载。　　这在Linux内核2.0/2.2就已经支持，其不足之处是大小固定，之后不能改变。　　为了能够使用Ramdisk，我们在编译内核时须将block device中的Ramdisk支持选上，它下面还有两个选项，一个是设定Ramdisk的大小，默认是4096k;另一个是initrd的支持。　　如果对R
内联汇编
08-20 1496
#include int main() { int a = 10, b; __asm__("movl %1, %%eax\n\t" "movl %%eax, %0\n\t" :"=r"(b) /* output */ :"r"(
find_next_zero_bit and DECLARE_BITMAP
07-18 1443
find_next_zero_bit：int find_next_zero_bit(const unsigned long *addr, int size, int offset)查询*addr中，从第offset位开始，第一个不为0的位的位数(最低位从0开始)，注: offset最小值为0，最大值为sizeof(unsigned long)*8 - 1//why * 8??sample:例如查找位图bitmap(共32位)的第5位开始第一个不为0的位的位数(查询结果为5)--5   4   3   2  
匿名页面
10-05 1184
匿名页面一般指的是user thread中的stack and heap, which means no file back up. 比页面缓存要活跃一些 mem shrink的时候会用到这些 thrashing 颠簸 为了节省页表空间提出反向页表的
如何在根文件系统中使用modprobe
03-18 1182
这几天在做4020的快速启动，本来想将网络模块化这样，能够将内核大概缩小0.5M（这个还是zImage），这样无论在uboot阶段搬运，还是在 zImage段的解压缩，还是在最后的启动都可以大大减少linux的启动时间，然而这中间有个很重要的问题是怎样在nfs中实现modprobe的命令，我在原来的busybox1.10.4中敲入modprobe命令出现如下错误： /quick_start # m
preempt_disable() and cond_resched()
08-09 1115
首先确认一点,  如果使用了preempt_disable(), 是不允许调用cond_resched的, 如果调用, schedule()应该会打印出错信息. 这个很好理解, cond_resched()的目的是提高系统实时性, 主动放弃cpu供优先级更高的任务使用, 如果调
patch
03-14 701
[root@amd src]# patch -p0 patching file linux-2.6.11/drivers/net/Kconfigpatching file linux-2.6.11/drivers/net/Makefilepatching file linux-2.6.11/drivers/net/ppp_generic.cpatching file linux-2.6.11/dr
fedora 12开机自动登入
03-19 696
这个方法一定行使用root登录，编辑/etc/gdm/custom.conf ,加入如下内容：[daemon]TimedLoginEnable=trueTimedLogin=yourusernameTimedLoginDelay=0其中yourusername是你想自动登录的用户名。重启即可。
关于Linux的makefile的自动生成，以及.configure及编译选项
06-21 658
参考文档：http://www.ibm.com/developerworks/cn/linux/l-makefile/主要解释makefile生成工具的工作流程http://blog.ednchina.com/fafen/1596316/Message.aspx基于上面文档的进一步分析及required file `config.h.in' not found解决方法http://blog.chinaunix.net/u2/84449/showart_2087602.htmlrequired file `.
Latency
10-11 629
什么叫实时操作系统 Not fast just preditable study lock, and write the table study the ip related knowledge ▪A system is real timewhen
uImage zImage
04-12 564
make Image uImage与zImage的区别）2010-03-18 17:20内核编译（make）之后会生成两个文件，一个Image，一个zImage，其中Image为内核映像文件，而zImage为内核的一种映像压缩文件，Image大约为4M，而zImage不到2M。    那么uImage又是什么的？它是uboot专用的映像文件，它是在zImag
booooook
10-11 544
Embbed Multi-Core Understanding the Linux Kernel    Understanding Linux Virtual Memory    Professional Linux Kernel Architecture  Linux
Pro linux embedded system(TBD)
10-11 509
how to reduce rootfs size how to speed up boot time arm-linux-size bloat-o-meter
====================[ 构建 | XXS.elf | Debug ]==================================== /Users/mac/Applications/CLion.app/Contents/bin/cmake/mac/aarch64/bin/cmake --build /Users/mac/Desktop/NewFolder/XXS_副本/cmake-build-debug --target XXS.elf -- -j 6 [ 14%] Building C object CMakeFiles/XXS.elf.dir/Core/Src/syscalls.c.obj [ 14%] Building C object CMakeFiles/XXS.elf.dir/Core/Src/main.c.obj [ 14%] Building C object CMakeFiles/XXS.elf.dir/Core/Src/LCD1602.c.obj [ 19%] Building C object CMakeFiles/XXS.elf.dir/Core/Src/stm32f1xx_hal_msp.c.obj [ 23%] Building C object CMakeFiles/XXS.elf.dir/Core/Src/gpio.c.obj [ 28%] Building C object CMakeFiles/XXS.elf.dir/Core/Src/stm32f1xx_it.c.obj [ 33%] Building C object CMakeFiles/XXS.elf.dir/Core/Src/sysmem.c.obj [ 38%] Building ASM object CMakeFiles/XXS.elf.dir/Core/Startup/startup_stm32f103vetx.s.obj [ 47%] Building C object CMakeFiles/XXS.elf.dir/Core/Src/system_stm32f1xx.c.obj [ 47%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal.c.obj [ 52%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_cortex.c.obj [ 57%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_dma.c.obj [ 61%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_exti.c.obj [ 66%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_flash.c.obj [ 71%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_flash_ex.c.obj [ 76%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_gpio.c.obj [ 80%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_gpio_ex.c.obj [ 85%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_pwr.c.obj [ 90%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_rcc.c.obj [ 95%] Building C object CMakeFiles/XXS.elf.dir/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal_rcc_ex.c.obj [100%] Linking C executable XXS.elf /Applications/ArmGNUToolchain/14.2.rel1/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/14.2.1/../../../../arm-none-eabi/bin/ld: CMakeFiles/XXS.elf.dir/Core/Src/main.c.obj: in function `main': /Users/mac/Desktop/NewFolder/XXS_副本/Core/Src/main.c:94:(.text.main+0x1c): undefined reference to `LCD_Clear' /Applications/ArmGNUToolchain/14.2.rel1/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/14.2.1/../../../../arm-none-eabi/bin/ld: /Users/mac/Desktop/NewFolder/XXS_副本/Core/Src/main.c:99:(.text.main+0x2e): undefined reference to `LCD_WriteString' /Applications/ArmGNUToolchain/14.2.rel1/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/14.2.1/../../../../arm-none-eabi/bin/ld: /Users/mac/Desktop/NewFolder/XXS_副本/Core/Src/main.c:102:(.text.main+0x42): undefined reference to `LCD_WriteString' Memory region Used Size Region Size %age Used RAM: 1992 B 64 KB 3.04% FLASH: 4508 B 512 KB 0.86% collect2: error: ld returned 1 exit status make[3]: *** [XXS.elf] Error 1 make[2]: *** [CMakeFiles/XXS.elf.dir/all] Error 2 make[1]: *** [CMakeFiles/XXS.elf.dir/rule] Error 2 make: *** [XXS.elf] Error 2
最新发布
03-25
<think>嗯，用户发了一个构建错误的问题，需要我来分析。首先，看看错误信息。链接阶段出现了未定义的引用，比如`LCD_Clear`和`LCD_WriteString`。这说明编译器在链接的时候找不到这些函数的实现。 用户用的是STM32的项目，CMake来构建。从构建日志看，CMakeFiles里有编译LCD1602.c.obj，说明这个文件应该被包含在项目中。那问题可能出在函数的声明和定义不一致，或者源文件没有被正确编译。 首先，检查函数声明是否正确。在头文件里，比如LCD1602.h，有没有正确声明这些函数？比如`void LCD_Clear(void);`或者类似的，并且有没有包含在main.c里？如果头文件没有正确声明，或者被条件编译指令错误地排除了，就会导致链接器找不到定义。 其次，检查函数定义是否存在。查看LCD1602.c文件，确认是否有`LCD_Clear`和`LCD_WriteString`的实现。可能拼写错误，比如大小写不一致，或者函数名有误。例如，函数定义是`LCD_Clear()`，但声明的时候写成了`LCD_clear()`，这样就会导致链接错误。 另外，编译过程中LCD1602.c是否被正确编译？构建日志显示[14%]的时候在编译这个文件，所以应该没问题。但需要确认生成的.o文件是否被链接进去。有时候CMake的配置问题，比如漏掉了源文件，或者目标没有正确链接库，也可能导致这个问题。检查CMakeLists.txt，确保LCD1602.c被添加到add_executable或add_library的源文件列表中。 还有，函数有没有被static修饰？如果函数在LCD1602.c里被声明为static，那么它们只在那个文件内可见，其他文件无法链接到，这时候就会出现未定义的错误。需要确认函数定义没有static关键字。 还有一个可能性是链接顺序的问题，但这种情况在CMake中比较少见，因为CMake会自动处理依赖关系。不过可以尝试在CMakeLists.txt中调整源文件的顺序，把LCD1602.c放在前面，或者在target_link_libraries中添加相应的库，如果有的话。 另外，用户的错误信息里提到了内存使用情况，RAM和FLASH的使用率都不高，说明代码量不大，所以问题可能不在内存溢出，而在于符号解析失败。所以重点还是函数实现是否被正确找到。 总结可能的解决步骤：首先检查头文件中的函数声明是否正确，是否有拼写错误；然后检查源文件中的实现是否存在且正确；确认CMakeLists.txt是否正确包含了所有需要的源文件；最后检查是否有static修饰符或其他编译选项导致符号不可见。</think>这个错误是典型的链接器错误，表示在编译的最后阶段（链接阶段）找不到某些函数的实现。以下是逐步分析及解决方案： --- ### **步骤1：理解错误类型** 错误信息示例： ```bash undefined reference to `LCD_Clear' undefined reference to `LCD_WriteString' ``` 这表明： - 函数`LCD_Clear()`和`LCD_WriteString()`在代码中被调用（声明存在）， - 但链接器（`ld`）在编译后的对象文件（`.obj`）或库文件中找不到它们的实现。 --- ### **步骤2：检查函数声明与实现** #### 可能原因1：**头文件未正确声明** - 在`main.c`中调用`LCD_Clear()`和`LCD_WriteString()`时，需确保： 1. 包含对应的头文件（如`LCD1602.h`）, 2. 头文件中正确定义了这两个函数： ```c // LCD1602.h void LCD_Clear(void); void LCD_WriteString(const char* str); ``` #### 可能原因2：**实现文件未编译** - 检查`LCD1602.c`是否被正确添加到CMake项目中： ```cmake # CMakeLists.txt add_executable(XXS.elf Core/Src/main.c Core/Src/LCD1602.c # 确认这一行存在 # 其他源文件... ) ``` #### 可能原因3：**函数实现错误** - 检查`LCD1602.c`中是否存在这两个函数的实现： ```c // LCD1602.c void LCD_Clear(void) { // 具体实现代码 } void LCD_WriteString(const char* str) { // 具体实现代码 } ``` - 注意函数名、参数类型是否与声明**完全一致**（包括大小写）。 --- ### **步骤3：检查编译日志** 从你的编译日志中： ```bash [ 14%] Building C object CMakeFiles/XXS.elf.dir/Core/Src/LCD1602.c.obj ``` 说明`LCD1602.c`已被编译，因此问题更可能出在**函数实现与声明的匹配性**或**作用域问题**。 --- ### **步骤4：验证符号表** 使用`nm`工具检查`LCD1602.c.obj`中是否包含目标符号： ```bash arm-none-eabi-nm LCD1602.c.obj | grep LCD_Clear ``` - 若输出类似`T LCD_Clear`，表示符号存在； - 若无输出，说明实现未被正确编译或函数名不匹配。 --- ### **步骤5：常见陷阱排查** 1. **C++名称修饰问题**： - 如果`.c`文件被误编译为C++代码，函数名会被修饰（如`LCD_Clear`变成`_Z10LCD_Clearv`）。 - 确保在CMake中明确指定为C语言： ```cmake set_source_files_properties(Core/Src/LCD1602.c PROPERTIES LANGUAGE C) ``` 2. **静态函数限制**： - 如果函数被声明为`static`（如`static void LCD_Clear()`），它们仅在当前文件内可见。 - 移除`static`关键字以允许外部调用。 --- ### **步骤6：修复建议** 1. **验证头文件包含**： ```c // main.c #include "LCD1602.h" // 确认包含头文件 ``` 2. **检查函数签名一致性**： - 确保`LCD1602.h`中的声明与`LCD1602.c`中的实现**完全一致**（包括参数类型、返回类型）。 3. **重新生成构建系统**： 清理并重新生成CMake构建： ```bash rm -rf cmake-build-debug/ mkdir cmake-build-debug && cd cmake-build-debug cmake .. make ``` --- ### **最终结论** 错误根源是**链接器找不到`LCD_Clear`和`LCD_WriteString`的实现**。通过检查函数声明、实现一致性及构建配置，可以解决此问题。如果问题仍未解决，请提供`LCD1602.h`和`LCD1602.c`的代码片段以便进一步分析。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值