ARM的嵌入式Linux移植体验之设备驱动

发布者:TranquilVibes最新更新时间:2012-11-13 来源: 21IC 关键字:ARM  嵌入式  Linux移植 手机看文章 扫描二维码
随时随地手机看文章
  设备驱动程序是操作系统内核和机器硬件之间的接口,它为应用程序屏蔽硬件的细节,一般来说,Linux的设备驱动程序需要完成如下功能:

  ·设备初始化、释放;

  ·提供各类设备服务;

  ·负责内核和设备之间的数据交换;

  ·检测和处理设备工作过程中出现的错误。

  Linux下的设备驱动程序被组织为一组完成不同任务的函数的集合,通过这些函数使得Windows的设备操作犹如文件一般。在应用程序看来,硬件设备只是一个设备文件,应用程序可以象操作普通文件一样对硬件设备进行操作,如open ()、close ()、read ()、write () 等。

  Linux主要将设备分为二类:字符设备和块设备。字符设备是指设备发送和接收数据以字符的形式进行;而块设备则以整个数据缓冲区的形式进行。在对字符设备发出读/写请求时,实际的硬件I/O一般就紧接着发生了;而块设备则不然,它利用一块系统内存作缓冲区,当用户进程对设备请求能满足用户的要求,就返回请求的数据,如果不能,就调用请求函数来进行实际的I/O操作。块设备主要针对磁盘等慢速设备。

  1.内存分配

  由于Linux驱动程序在内核中运行,因此在设备驱动程序需要申请/释放内存时,不能使用用户级的malloc/free函数,而需由内核级的函数kmalloc/kfree () 来实现,kmalloc()函数的原型为:

   void kmalloc (size_t size ,int priority);

  参数size为申请分配内存的字节数,kmalloc最多只能开辟128k的内存;参数priority说明若kmalloc()不能马上分配内存时用户进程要采用的动作:

       GFP_KERNEL 表示等待,即等kmalloc()函数将一些内存安排到交换区来满足你的内存需要,GFP_ATOMIC 表示不等待,如不能立即分配到内存则返回0 值;函数的返回值指向已分配内存的起始地址,出错时,返回0。

  kmalloc ()分配的内存需用kfree()函数来释放,kfree ()被定义为:

         # define kfree (n) kfree_s( (n) ,0)

  其中kfree_s () 函数原型为:

         void kfree_s (void * ptr ,int size);

  参数ptr为kmalloc()返回的已分配内存的指针,size是要释放内存的字节数,若为0 时,由内核自动确定内存的大小。

  2.中断

  许多设备涉及到中断操作,因此,在这样的设备的驱动程序中需要对硬件产生的中断请求提供中断服务程序。与注册基本入口点一样,驱动程序也要请求内核将特定的中断请求和中断服务程序联系在一起。在Linux中,用requeST_IRq()函数来实现请求:

       int request_irq (unsigned int irq ,void( * handler) int ,unsigned lONg type ,char * name);

        参数irq为要中断请求号,参数handler为指向中断服务程序的指针,参数type 用来确定是正常中断还是快速中断(正常中断指中断服务子程序返回后,内核可以执行调度程序来确定将运行哪一个进程;而快速中断是指中断服务子程序返回后,立即执行被中断程序,正常中断type 取值为0 ,快速中断type 取值为SA_INTERRUPT),参数nAME是设备驱动程序的名称。

  4.块设备驱动

  块设备驱动程序的编写是一个浩繁的工程,其难度远超过字符设备,上千行的代码往往只能搞定一个简单的块设备,而数十行代码就可能搞定一个字符设备。因此,非得有相当的基本功才能完成此项工作。下面先给出一个实例,即mtdblock块设备的驱动。我们通过分析此实例中的代码来说明块设备驱动程序的写法(由于篇幅的关系,大量的代码被省略,只保留了必要的主干):

#include
#include
staTIc void mtd_notify_add(struct mtd_info* mtd);
static void mtd_notify_remove(struct mtd_info* mtd);
static struct mtd_notifier notifier = {
 mtd_notify_add,
 mtd_notify_remove,
 NULL
};
static devfs_handle_t devfs_dir_handle = NULL;
static devfs_handle_t devfs_rw_handle[MAX_MTD_deviceS];

static struct mtdblk_dev {
 struct mtd_info *mtd; /* Locked */
 int count;
 struct semaphore cache_sem;
 unsigned char *cache_data;
 unsigned long cache_offset;
 unsigned int cache_size;
 enum { STATE_EMPTY, STATE_CLEAN, STATE_DIRTY } cache_state;
} *mtdblks[MAX_MTD_DEVICES];

static spinlock_t mtdblks_lock;
/* this lock is used just in kernels >= 2.5.x */
static spinlock_t mtdblock_lock;

static int mtd_sizes[MAX_MTD_DEVICES];
static int mtd_blksizes[MAX_MTD_DEVICES];

static void erase_callback(struct erase_info *done)
{
 wait_queue_head_t *wait_q = (wait_queue_head_t *)done->priv;
 wake_up(wait_q);
}

static int erase_write (struct mtd_info *mtd, unsigned long pos,
int len, const char *buf)
{
 struct erase_info erase;
 DECLARE_WAITQUEUE(wait, current);
 wait_queue_head_t wait_q;
 size_t retlen;
 int ret;

 /*
 * First, let\'s erase the flash block.
 */

 init_waitqueue_head(&wait_q);
 erase.mtd = mtd;
 erase.callback = erase_callback;
 erase.addr = pos;
 erase.len = len;
 erase.priv = (u_long)&wait_q;

 set_current_state(TASK_INTERRUPTIBLE);
 add_wait_queue(&wait_q, &wait);

 ret = MTD_ERASE(mtd, &erase);
 if (ret) {
  set_current_state(TASK_RUNNING);
  remove_wait_queue(&wait_q, &wait);
  printk (KERN_WARNING "mtdblock: erase of region [0x%lx, 0x%x] " "on /"%s/" failed/n",
pos, len, mtd->name);
  return ret;
 }

 schedule(); /* Wait for erase to finish. */
 remove_wait_queue(&wait_q, &wait);

 /*
 * Next, writhe data to flash.
 */

 ret = MTD_WRITE (mtd, pos, len, &retlen, buf);
 if (ret)
  return ret;
 if (retlen != len)
  return -EIO;
 return 0;
} [page]

static int write_cached_data (struct mtdblk_dev *mtdblk)
{
 struct mtd_info *mtd = mtdblk->mtd;
 int ret;

 if (mtdblk->cache_state != STATE_DIRTY)
  return 0;

 DEBUG(MTD_DEBUG_LEVEL2, "mtdblock: writing cached data for /"%s/" "
"at 0x%lx, size 0x%x/n", mtd->name,
mtdblk->cache_offset, mtdblk->cache_size);

 ret = erase_write (mtd, mtdblk->cache_offset,
mtdblk->cache_size, mtdblk->cache_data);
 if (ret)
  return ret;

 mtdblk->cache_state = STATE_EMPTY;
 return 0;
}

static int do_cached_write (struct mtdblk_dev *mtdblk, unsigned long pos,
int len, const char *buf)
{
 …
}

static int do_cached_read (struct mtdblk_dev *mtdblk, unsigned long pos,
int len, char *buf)
{
 …
}

static int mtdblock_open(struct inode *inode, struct file *file)
{
 …
}

static release_t mtdblock_release(struct inode *inode, struct file *file)
{
 int dev;
 struct mtdblk_dev *mtdblk;
 DEBUG(MTD_DEBUG_LEVEL1, "mtdblock_release/n");

 if (inode == NULL)
  release_return(-ENODEV);

 dev = minor(inode->i_rdev);
 mtdblk = mtdblks[dev];

 down(&mtdblk->cache_sem);
 write_cached_data(mtdblk);
 up(&mtdblk->cache_sem);

 spin_lock(&mtdblks_lock);
 if (!--mtdblk->count) {
  /* It was the last usage. Free the device */
  mtdblks[dev] = NULL;
  spin_unlock(&mtdblks_lock);
  if (mtdblk->mtd->sync)
   mtdblk->mtd->sync(mtdblk->mtd);
   put_mtd_device(mtdblk->mtd);
   vfree(mtdblk->cache_data);
   kfree(mtdblk);
 } else {
  spin_unlock(&mtdblks_lock);
 }

 DEBUG(MTD_DEBUG_LEVEL1, "ok/n");
 
 BLK_DEC_USE_COUNT;
 release_return(0);
}

/*
* This is a special request_fn because it is executed in a process context
* to be able to sleep independently of the caller. The
* io_request_lock (for <2.5) or queue_lock (for >=2.5) is held upon entry
* and exit. The head of our request queue is considered active so there is
* no need to dequeue requests before we are done.
*/
static void handle_mtdblock_request(void)
{
 struct request *req;
 struct mtdblk_dev *mtdblk;
 unsigned int res;

 for (;;) {
  INIT_REQUEST;
  req = CURRENT;
  spin_unlock_irq(QUEUE_LOCK(QUEUE));
  mtdblk = mtdblks[minor(req->rq_dev)];
  res = 0;

  if (minor(req->rq_dev) >= MAX_MTD_DEVICES)
   panic("%s : minor out of bound", __FUNCTION__);

  if (!IS_REQ_CMD(req))
   goto end_req;

  if ((req->sector + req->current_nr_sectors) > (mtdblk->mtd->size >> 9))
   goto end_req;

  // Handle the request
  switch (rq_data_dir(req))
  {
   int err;

   case READ:
    down(&mtdblk->cache_sem);
    err = do_cached_read (mtdblk, req->sector << 9,
req->current_nr_sectors << 9,
req->buffer);
    up(&mtdblk->cache_sem);
    if (!err)
     res = 1;
    break;

   case WRITE:
    // Read only device
    if ( !(mtdblk->mtd->flags & MTD_WRITEABLE) )
     break;

    // Do the write
    down(&mtdblk->cache_sem);
    err = do_cached_write (mtdblk, req->sector << 9,req->current_nr_sectors << 9, req->buffer);
    up(&mtdblk->cache_sem);
    if (!err)
     res = 1;
    break;
  }

 end_req:
 spin_lock_irq(QUEUE_LOCK(QUEUE));
 end_request(res);
}
}

static volatile int leaving = 0;
static DECLARE_MUTEX_LOCKED(thread_sem);
static DECLARE_WAIT_QUEUE_HEAD(thr_wq);

int mtdblock_thread(void *dummy)
{
 …
}

#define RQFUNC_ARG request_queue_t *q

static void mtdblock_request(RQFUNC_ARG)
{
 /* Don\'t do anything, except wake the thread if necESSary */
 wake_up(&thr_wq);
}

static int mtdblock_ioctl(struct inode * inode, struct file * file,
unsigned int CMd, unsigned long arg)
{
 struct mtdblk_dev *mtdblk;
 mtdblk = mtdblks[minor(inode->i_rdev)];
 switch (cMD) {
  case BLKGETSIZE: /* Return device size */
   return put_user((mtdblk->mtd->size >> 9), (unsigned long *) arg);

  case BLKFLSBUF:
   if(!capable(CAP_SYS_ADMIN))
    return -EACCES;
   fsync_dev(inode->i_rdev);
   invalidate_buffers(inode->i_rdev);
   down(&mtdblk->cache_sem);
   write_cached_data(mtdblk);
   up(&mtdblk->cache_sem);
   if (mtdblk->mtd->sync)
    mtdblk->mtd->sync(mtdblk->mtd);
    return 0;
  default:
   return -EINVAL;
 }
} [page]

static struct block_device_operations mtd_fops =
{
 owner: THIS_MODULE,
 open: mtdblock_open,
 release: mtdblock_release,
 ioctl: mtdblock_ioctl
};

static void mtd_notify_add(struct mtd_info* mtd)
{
 …
}

static void mtd_notify_remove(struct mtd_info* mtd)
{
 if (!mtd || mtd->type == MTD_ABSENT)
  return;

 devfs_unregister(devfs_rw_handle[mtd->index]);
}

int __init init_mtdblock(void)
{
 int i;

 spin_lock_init(&mtdblks_lock);
 /* this lock is used just in kernels >= 2.5.x */
 spin_lock_init(&mtdblock_lock);

 #ifdef CONFIG_DEVFS_FS
 if (devfs_register_blkdev(MTD_BLOCK_MAJOR, DEVICE_NAME, &mtd_fops))
 {
  printk(KERN_NOTICE "Can\'t allocate major number %d for Memory Technology Devices./n",
MTD_BLOCK_MAJOR);
  return -EAGAIN;
 }

 devfs_dir_handle = devfs_mk_dir(NULL, DEVICE_NAME, NULL);
 register_mtd_user(¬ifier);
 #else
  if (register_blkdev(MAJOR_NR,DEVICE_NAME,&mtd_fops)) {
   printk(KERN_NOTICE "Can\'t allocate major number %d for Memory Technology Devices./n",
MTD_BLOCK_MAJOR);
  return -EAGAIN;
 }
 #endif

/* We fill it in at open() time. */
for (i=0; i< MAX_MTD_DEVICES; i++) {
 mtd_sizes[i] = 0;
 mtd_blksizes[i] = BLOCK_SIZE;
}
init_waitqueue_head(&thr_wq);
/* Allow the block size to default to BLOCK_SIZE. */
blksize_size[MAJOR_NR] = mtd_blksizes;
blk_size[MAJOR_NR] = mtd_sizes;

BLK_INIT_QUEUE(BLK_DEFAULT_QUEUE(MAJOR_NR), &mtdblock_request, &mtdblock_lock);

kernel_thread (mtdblock_thread, NULL, CLONE_FS|CLONE_FILES|CLONE_SIGHAND);
return 0;
}

static void __exit cleanup_mtdblock(void)
{
 leaving = 1;
 wake_up(&thr_wq);
 down(&thread_sem);
 #ifdef CONFIG_DEVFS_FS
  unregister_mtd_user(¬ifier);
  devfs_unregister(devfs_dir_handle);
  devfs_unregister_blkdev(MTD_BLOCK_MAJOR, DEVICE_NAME);
 #else
  unregister_blkdev(MAJOR_NR,DEVICE_NAME);
 #endif
 blk_cleanup_queue(BLK_DEFAULT_QUEUE(MAJOR_NR));
 blksize_size[MAJOR_NR] = NULL;
 blk_size[MAJOR_NR] = NULL;
}

module_init(init_mtdblock);
module_exit(cleanup_mtdblock);

  从上述源代码中我们发现,块设备也以与字符设备register_chrdev、unregister_ chrdev 函数类似的方法进行设备的注册与释放:

int register_blkdev(unsigned int major, const char *name, struct block_device_operations *bdops);
int unregister_blkdev(unsigned int major, const char *name);

  但是,register_chrdev使用一个向 file_operations 结构的指针,而register_blkdev 则使用 block_device_operations 结构的指针,其中定义的open、release 和 ioctl 方法和字符设备的对应方法相同,但未定义 read 或者 write 操作。这是因为,所有涉及到块设备的 I/O 通常由系统进行缓冲处理。

  块驱动程序最终必须提供完成实际块 I/O 操作的机制,在 Linux 当中,用于这些 I/O 操作的方法称为"request(请求)"。在块设备的注册过程中,需要初始化request队列,这一动作通过blk_init_queue来完成,blk_init_queue函数建立队列,并将该驱动程序的 request 函数关联到队列。在模块的清除阶段,应调用 blk_cleanup_queue 函数。

  本例中相关的代码为:

       BLK_INIT_QUEUE(BLK_DEFAULT_QUEUE(MAJOR_NR), &mtdblock_request, &mtdblock_lock);
blk_cleanup_queue(BLK_DEFAULT_QUEUE(MAJOR_NR));

  每个设备有一个默认使用的请求队列,必要时,可使用 BLK_DEFAULT_QUEUE(major) 宏得到该默认队列。这个宏在 blk_dev_struct 结构形成的全局数组(该数组名为 blk_dev)中搜索得到对应的默认队列。blk_dev 数组由内核维护,并可通过主设备号索引。blk_dev_struct 接口定义如下:

struct blk_dev_struct {
 /*
 * queue_proc has to be atomic
 */
 request_queue_t request_queue;
 queue_proc *queue;
 void *data;
};

  request_queue 成员包含了初始化之后的 I/O 请求队列,data 成员可由驱动程序使用,以便保存一些私有数据。

  request_queue定义为:

struct request_queue
{
 /*
 * the queue request freelist, one for reads and one for writes
 */
 struct request_list rq[2];

 /*
 * Together with queue_head for cacheline sharing
 */
 struct list_head queue_head;
 elevator_t elevator;

 request_fn_proc * request_fn;
 merge_request_fn * back_merge_fn;
 merge_request_fn * front_merge_fn;
 merge_requests_fn * merge_requests_fn;
 make_request_fn * make_request_fn;
 plug_device_fn * plug_device_fn;
 /*
 * The queue owner gets to use this for whatever they like.
 * ll_rw_blk doesn\'t touch it.
 */
 void * queuedata;

 /*
 * This is used to remove the plug when tq_disk runs.
 */
 struct tq_struct plug_tq;

 /*
 * Boolean that indicates whether this queue is plugged or not.
 */
 char plugged;

 /*
 * Boolean that indicates whether current_request is active or
 * not.
 */
 char head_active;

 /*
 * Is meant to protect the queue in the future instead of
 * io_request_lock
 */
 spinlock_t queue_lock;

 /*
 * Tasks wait here for free request
 */
 wait_queue_head_t wait_for_request;
};

  下图表征了blk_dev、blk_dev_struct和request_queue的关系:

  下图则表征了块设备的注册和释放过程:

  5.小结

  本章讲述了Linux设备驱动程序的入口函数及驱动程序中的内存申请、中断等,并分别以实例讲述了字符设备及块设备的驱动开发方法。

关键字:ARM  嵌入式  Linux移植 引用地址:ARM的嵌入式Linux移植体验之设备驱动

上一篇:如何处理ARM体系下浮点数Middle-Endian问题
下一篇:基于WINCE&S3C2410的多串口移植技术

推荐阅读最新更新时间:2024-03-16 13:13

一种基于ARM和智能手机的蓝牙CAN分析仪设计
  针对CAN总线通信质量、测试和验证的需要,以及传统CAN分析仪的复杂性,且必须选择PC机作为显示终端的不足,论证了一种基于ARM单片机和智能手机的CAN总线分析仪设计。该分析仪采用以ARM单片机为核心的硬件电路完成对CAN网络的实时数据收集和监控;采用蓝牙通信方式实现分析仪与智能手机的通信并以智能手机为终端完成数据分析。文章对分析仪硬件、软件和智能手机页面进行了具体设计,提出了一种新的波特率自动检测方法,最后给出了所设计的 CAN总线分析仪的实际试验结果,可实现CAN总线波特率自动检测、正常监测以及CAN总线状态分析的功能。   CAN(controller area network)控制器局域网络是一种实时性强、灵活性好
[测试测量]
一种基于<font color='red'>ARM</font>和智能手机的蓝牙CAN分析仪设计
赛普拉斯公司在中国成功举办无代码嵌入式系统设计研讨会
免费的全球系列研讨会演示如何利用PSoC Express TM 软件来快速完成设计; 免费附带演示套件 2006 年 11 月 07 日 北京讯 近日,赛普拉斯半导体公司( Cypress Semiconductor Corp. )为有兴趣学习 Cypress 的 PSoC Express 无代码、可视开发软件的设计者们举办了系列研讨会。这些免费研讨会所涉及的内容包括: Cypress PSoC ( Programmable System-on-Chip )混合信号阵列架构概述以及 PSoC Express 技术培训。    参会 者参加了一次亲自动手操作的实验室授课,
[焦点新闻]
嵌入式无线视频监控系统设计
0 引言 高性能、低功耗嵌入式CPU和高可靠性网络操作系统的面世,使得可视电话、视频会议、远程视频监控等运算数据量大的应用在嵌入式设备中实现成为可能。传统的基于同轴电缆的视频监控系统结构复杂、稳定性差、可靠性低且价格昂贵,因而出现了嵌入式网络视频服务器等远程Web视频监控系统。在本嵌入式无线视频监控系统中,使用高性能ARM9芯片作微处理器,控制video4linux实现USB摄像头视频数据采集,采集的视频数据经JPEG压缩后,在 ARM9芯片的控制下通过2.4GHz无线发送/接收模块进行视频数据传输;视频传输模块再将视频数据通过串口或网络提交给视频应用服务端,最后由视频应用服务端将接收到的压缩数据帧重组、复合成视频图像,实现无线
[单片机]
<font color='red'>嵌入式</font>无线视频监控系统设计
基于嵌入式Linux图像采集恢复和应用
1.引言       随着后PC时代的到来和嵌入式的蓬勃发展,运用嵌入式系统实现远程数据采集已成为社会需求的趋势。本文采用嵌入式系统采集图像数据实现加工零件的远程测量,代替传统的人工检测。其特点有:网络化,准确性高,节约人力和物力。   2.系统软硬件平 台       由于嵌入式设备资源有限,所以在开发嵌入式系统的软件部分需要在宿主机平台上实现,运用宿主机的资源编译目标机平台上可运行的软件。本文系统的宿主机平台:Redhat 9.0,交叉编译环境:ARM-Linux-Gcc;目标机平台:UBOOT 1.1,Linux 2.4.18 和YAFFS 根文件系统。       系统硬件平台的处理器采用 Samsung 公司的集成
[嵌入式]
基于嵌入式和ZigBee技术的智能家居系统设计
ZigBee是一种新兴的无线通信技术,它具有短距离、低功耗、低成本和低数据速率等特点。而智能家居的特点就是网络传输数据量小,对带宽要求低,但是需要的网络实时性好,延迟要短,要求接入方便,系统续航能力久、可扩展性强并且后期维护简单。这无疑使ZigBee技术成为了首选,因为ZigBee技术的主要应用领域就是工业控制、电子设备和楼宇自动化等,它的特点决定了ZigBee技术能很好地满足智能家居系统的需求。 1系统总体方案 智能家居系统网络大致可分为外部网(因特网)、内部网(ZigBee自组网)和家庭网关。其中,家庭网关是核心部分,本系统以移植在tiny6410开发板上的Boa服务器作为家庭网关,它负责家庭内部网络和外部网络的连接和协议转
[单片机]
基于<font color='red'>嵌入式</font>和ZigBee技术的智能家居系统设计
快数学Arm(17)--uC/OS-II任务管理块TCB
原指望Arm7能得到快速学习,但看了之后发现与C51的难度不是相同数量级的.如果真的想学好,还是需要研究很多东西的.我绕了个圈子,接着转向学习uC/OS-II,学一样东西无法按照书上的套路按部就班的学,那样实在太慢了.看了一项uC/OS-II的教材,发现要学好它是需要花费一些时间的,对于时间比较短缺的我来说是不是有足够的时间把它学下去,我也不知道,但只要我不被其他的更重要的事情打断,我想我是能够坚持下去的,我相信我的毅力. 在前面我们知道了uC/OS-II(后面写成ucos2,敲起来方便些)是可以实现多任务的,看了书以后发现这种多任务虽然功能要比C51强了很多,但真的需要投入很多精力才能逐渐弄清楚,而且C语言差的人,没有汇编经
[单片机]
ARM7与FPGA相结合的应用
  ARM7与FPGA相结合在工业控制和故障检测中的应用   工业控制中往往需要完成多通道故障检测及多通道命令控制(这种多任务设置非常普遍),单独的CPU芯片由于其外部控制接口数量有限而难以直接完成多路检控任务,故利用ARM芯片与FPGA相结合来扩展检控通道是一个非常好的选择。这里介绍用Atmel公司ARM7处理器(AT91FR40162)和ALTERA公司的低成本FPGA芯片(cyclone2)结合使用完成多通道检控任务的一种实现方法。    各部分功能简介   图1为此系统的结构连接框图。如图所示,ARM芯片与FPGA芯片之间通过数据总线、地址总线及读写控制线相连,而与终端PC则通过串口通信;FPGA与目标设备通过命令控
[工业控制]
采用ARM+Linux 的仪器控制系统设计
0 引 言   嵌入式系统的开发都有其特殊的应用场合与特定功能,而嵌入式Linux操作系统因其开源和广泛的处理器支持、易于移植而备受行业青睐。AT91RM9200是Atmel公司针对系统控制、通信领域推出的基于ARM920T内核的32位RISC微处理器,它具有小体积,低功耗,低成本及高性能等特点,其内部集成了SPI、串口、PIO、以太网、EBI、USB、MCI等多种接口。   在Linux系统中,应用层不可以直接操作硬件,需设计驱动程序向下屏蔽硬件特性,实现硬件与用户间的通信。系统平台为在虚拟机中安装Fedora 8,目标系统采用Linux 2.6.21.7内核,定制文件系统建立NFS根文件系统,使用双网卡方式搭建成交叉开发环
[单片机]
采用<font color='red'>ARM</font>+<font color='red'>Linux</font> 的仪器控制系统设计
小广播
添点儿料...
无论热点新闻、行业分析、技术干货……
设计资源 培训 开发板 精华推荐

最新单片机文章
何立民专栏 单片机及嵌入式宝典

北京航空航天大学教授,20余年来致力于单片机与嵌入式系统推广工作。

换一换 更多 相关热搜器件
电子工程世界版权所有 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号 Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved