简介本资源是一个基于嵌入式Linux平台的智慧农业信息采集与控制系统完整实现面向计算机、自动化、电子信息等专业的在校学生、教师及嵌入式初学者解决农业环境参数远程监控与自动调控的实际问题。系统采用C语言开发依托MySQL数据库存储温湿度、电机/开关状态等历史数据并支持阈值设定、越限判断与反向控制指令下发可在QEMU模拟的Ubuntu 16.04环境中运行适合作为课程设计、毕设原型或嵌入式物联网综合实训项目。压缩包共10个文件35KB含4个核心C源码client/server/endpoint、3个Makefile分模块编译、1个头文件、1个README说明文档和1份LICENSE协议结构清晰、模块解耦便于理解通信逻辑、数据库交互与控制流程。已有118人学习下载所有代码均经实测运行通过附带详细注释与部署提示支持远程教学答疑可直接运行或在其基础上扩展传感器类型与控制策略。 搞嵌入式项目这几年我接过不少“软硬结合”的活儿但真正让我把数据库、Linux、传感器串在一起的还是这套智慧农业信息采集控制系统。项目本身不复杂——用C语言写主控程序跑在嵌入式Linux板子上定期读温湿度、光照、土壤水分这些传感器数据写入MySQL再根据阈值去控制继电器、水泵、风机。但就是这么一套系统从选型到落地中间踩的坑、做的取舍远比“能跑就行”这四个字多得多。如果你正准备做类似的嵌入式Linux项目或者正在纠结“嵌入式的数据到底该存哪”这篇文章应该能给你省下几周的弯路。先说清楚本篇文章围绕的核心就是这个项目标题本身基于MySQL的嵌入式Linux智慧农业信息采集控制系统。我会从需求拆解、技术选型、环境搭建、数据库设计、C语言代码结构、问题排查到交付文档把整个系统的关键细节完整过一遍。即使你现在还没有板子也能先把架构和代码逻辑吃透后面上硬件时照着做就行。1. 先盘清需求这套智慧农业系统到底要解决什么问题1.1 从一栋大棚的真实作业场景说起与其先讲技术不如先讲场景。我去过一个实际运行中的温室大棚里面种的是叶菜棚里湿度常年很高夏天温度能飙到40度以上。人工管理最大的问题是“反应慢”——等发现棚内温度过高的时候叶片已经萎蔫了。所以智慧农业的核心需求不是做一个酷炫的仪表盘而是解决一个问题环境参数能不能被机器自动读取、自动记录、自动判断、自动控制。这套系统的数据链路是这样的温湿度传感器比如DHT11或SHT30挂在GPIO或I2C总线上光照传感器和土壤湿度传感器接在ADC口主控板用一个跑嵌入式Linux的ARM板每隔几秒采集一次数据然后把数据写入MySQL。控制端根据预先配置的阈值决定是否打开风机、水泵或卷帘。整套系统听起来简单但涉及采集、存储、控制、远程查看四个环节每一个环节都有不少细节。1.2 系统边界和核心功能清单在做项目之前一定要先把边界划清楚。这决定了后面代码怎么写、文档怎么组织。我最终定义的功能清单是这样的环境监测定时采集空气温湿度、光照强度、土壤湿度支持多路传感器扩展。数据存储所有采集数据写入MySQL便于历史查询、趋势分析和报表导出。自动控制根据阈值规则自动控制继电器风机、水泵、补光灯、卷帘电机。手动控制通过命令行或上层管理界面手动下发设备控制指令。远程访问MySQL开放给局域网内的Web服务或手机App实现远程查看和控制。系统自检掉线自动重连、传感器异常检测、进程看门狗、日志记录。这套边界的好处是每个模块之间是解耦的。采集程序只管采集数据库只负责存储控制逻辑独立成模块。这样即使某个传感器换了型号或者后面要加一个摄像头核心的框架都不需要推翻。1.3 底层架构传感器、主控、数据库、上层应用如何协作这张架构图虽然不画图但关系要讲清楚。底层是传感器和执行器中间是嵌入式主控板再往上走是MySQL数据库最上层是Web应用或手机App。感知层各类传感器负责把物理量转成电信号也就是“感知”。主控层嵌入式Linux板上的C程序负责数据采集、处理、控制指令下发。存储层MySQL负责把历史数据持久化同时保留设备状态和控制记录。应用层Web后端或App通过SQL查询数据库把数据展示成图表或者下发控制指令。从数据流来看传感器数据是单向流入数据库的控制流则是从上层应用或本地逻辑下发到主控再由主控驱动继电器。这两个方向要分开考虑因为数据库只负责“记录”控制指令可能来自本地自动逻辑也可能来自远程手动操作两者之间需要一个统一的接口。2. 技术选型复盘嵌入式LinuxCMySQL这个组合的取舍2.1 为什么在嵌入式侧选择Linux而不是裸机或RTOS我做这个项目之前有过用STM32裸机做环境监测的经历。裸机方案的优势是成本低、启动快、实时性强但有个致命的短板网络协议栈和文件系统生态太弱。如果要在裸机上跑HTTP服务、连接MySQL、处理多路传感器和定时任务工作量会非常大而且后期扩展几乎寸步难行。嵌入式Linux的优势在于它是一个完整操作系统。线程、文件、网络、进程管理这些底层能力都是现成的C程序可以直接调用POSIX接口跑起来就像一个精简版服务器。数据库客户端库、网络库、GPIO库都能在Linux上找到成熟的实现。对智慧农业这种需要长期运行、多任务并发的场景Linux的稳定性也更有保障。2.2 C语言在这个项目里的不可替代性有人说“都2025年了嵌入式为什么还写C”说实话C语言在这个场景下不仅不过时反而是最合理的选项。第一系统的底层要操作GPIO、I2C、ADC等硬件资源这些在C语言里可以直接通过内存映射或系统调用访问效率极高。第二目标板上通常跑的是裁剪过的Linux系统内存和CPU资源有限Python或Java这类运行时开销大的语言并不是首选。第三C程序的运行行为是高度确定的一个线程多久醒来、一次数据库查询花多久都更容易预估这对控制类系统很重要。当然C语言的坑也多指针、内存管理、字符串处理都得自己小心。但它的回报也是实实在在的——一个编译好的程序可以直接在板子上跑几个月不用重启这就是工业化产品需要的特质。2.3 MySQL登场与SQLite和文件存储的对比它解决了什么嵌入式项目最常见的存储方案其实是SQLite因为它零配置、轻量级、单文件。我自己早期也用SQLite做过采集系统但后来发现三个问题并发写入能力有限。SQLite在写入时会对数据库文件加锁如果采集线程和控制线程同时访问容易出现“database is locked”。远程访问不方便。SQLite是文件型数据库虽然可以把它放在NFS或Samba共享目录里但性能和安全性都不理想。数据分析能力弱。当数据量上来之后按时间范围聚合查询、多表联查SQLite虽然能做但在并发环境下的表现远不如MySQL。MySQL的定位是真正的网络数据库服务。它独立运行一个服务进程支持多客户端并发连接数据表设计、索引优化、权限控制都很成熟。在智慧农业场景里大棚现场如果有多套嵌入式设备每套设备都能作为MySQL客户端把数据写入同一个中心服务器这个优势是SQLite根本做不到的。需要强调的是MySQL在嵌入式设备上并不一定要装在板子里——后面我会讲两种部署形态这是很多人第一次接触时都会搞混的地方。3. 环境准备和交叉编译让MySQL跑在目标板或连上远端服务器3.1 两种部署形态板载MySQL与远程MySQL在嵌入式Linux里用MySQL有两种典型做法一种是远程数据库模式。开发板作为纯客户端编译时只编译MySQL的client库libmysqlclient连接一个局域网或云端的MySQL服务器。这种模式的好处是板子的资源消耗小数据集中管理多套设备可以共用一台数据库服务器。我实际推荐这个方案因为智慧农业往往是多棚、多采集点数据汇聚到中心服务器才便于分析。另一种是板载数据库模式。把MySQL服务端完整编译进目标板系统板子自采自存适合脱网运行、小规模单点部署。缺点是板子存储有限MySQL服务内存占用不小一般只存储近期的数据还要做定期清理或数据导出。两种模式在C代码层面几乎没有差别因为客户端库的API是一样的。区别主要在环境部署和交叉编译参数。下面我以远程数据库模式为主来展开因为这是最稳妥、最通用的方案。3.2 交叉编译MySQL客户端库的关键步骤交叉编译是第一个大坎。目标板是ARM架构开发机是x86_64直接用主机上的mysql.h和libmysqlclient.so肯定不行必须用交叉编译工具链编译一份能在ARM上运行的客户端库。要在开发机上准备好交叉编译工具链以ARM Cortex-A7为例通常安装的路径是/opt/arm-2014.05/或者arm-linux-gnueabihf-前缀的工具链。我用的是arm-linux-gnueabihf-gcc具体步骤大致如下# 下载MySQL源码或直接获取libmysqlclient源码包这里以常见的社区版源码为例 tar -xzf mysql-5.7.44.tar.gz cd mysql-5.7.44 # 设置交叉编译环境变量 export CCarm-linux-gnueabihf-gcc export CXXarm-linux-gnueabihf-g export CFLAGS-I/opt/arm-libs/include export LDFLAGS-L/opt/arm-libs/lib # 配置编译只编译客户端库 cmake . \ -DCMAKE_SYSTEM_NAMELinux \ -DWITHOUT_SERVERON \ -DWITH_SSLno \ -DCMAKE_INSTALL_PREFIX/opt/arm-mysql-client make make install这里有个很现实的坑MySQL 5.7之后用的是cmake而不是传统的configure。很多第一次接触的人会按老教程写./configure结果直接报错。另外交叉编译时即使不需要SSL也要把相关的依赖库处理好像我上面用-WITHOUT_SERVER只编译客户端能减少很多麻烦。编译完成后把/opt/arm-mysql-client下的include目录和lib目录拷贝到开发板或者放到交叉编译的sysroot里备查。3.3 目标板运行时环境权限、时区、网络库编译好了只算走了一半。开发板上的运行时环境至少还要准备这几项网络联通。开发板如果通过网线连接路由器要确认能ping通MySQL服务器的IP。很多人程序连不上数据库第一步就忘了查网络。我在调试时通常先执行ping 192.168.1.100再执行mysql -h192.168.1.100 -uuser -p先用命令行客户端测通了再跑源码。千万不要跳过这一步。时区同步。嵌入式板子默认时区可能不是UTC8。在采集数据写入MySQL时如果用NOW()函数获取时间插入的时间跟真实时间可能差8个小时对于农业记录来说这个偏差没法接受。解决办法是在开发板启动脚本里设置TZAsia/Shanghai或者在C代码里不用NOW()而用本地时间函数手动构造时间字符串。系统库依赖。交叉编译的libmysqlclient.so可能依赖libncurses.so、libpthread.so等目标板上如果缺失程序启动时会报“error while loading shared libraries”。可以用arm-linux-gnueabihf-readelf -d libmysqlclient.so查看依赖然后到开发板根文件系统里补齐。4. 数据库设计与C语言API用法4.1 数据表设计实时表、历史表、设备控制表MySQL表的设计直接影响系统后续的数据查询和维护。我的建议是分三张核心表传感器实时数据表、传感器历史数据表、设备控制记录表。实时数据表只保存最新一条数据每次采集更新覆盖CREATE TABLE sensor_latest ( node_id INT PRIMARY KEY, temp FLOAT, humidity FLOAT, light INT, soil_humidity FLOAT, update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );历史数据表则按时间追加用于后期图表分析CREATE TABLE sensor_history ( id INT AUTO_INCREMENT PRIMARY KEY, node_id INT, temp FLOAT, humidity FLOAT, light INT, soil_humidity FLOAT, record_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_node_time (node_id, record_time) );设备控制表记录每一次设备的开关动作CREATE TABLE device_log ( id INT AUTO_INCREMENT PRIMARY KEY, device_id VARCHAR(32), action TINYINT, source VARCHAR(16), create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP );这里有几个值得注意的点node_id字段很重要如果以后多个节点接入就能区分数据来源。历史数据表必须给(node_id, record_time)建联合索引否则数据量大后按时间范围查询会非常慢。定期清理历史数据没必要无限存。可以写一个事件调度每天删除30天前的记录或者存到另外的归档表。4.2 C语言连接数据库的基础APIC语言连接MySQL的核心API基本固定记住这几步就够了#include mysql/mysql.h MYSQL *conn; MYSQL_RES *res; MYSQL_ROW row; conn mysql_init(NULL); if (conn NULL) { fprintf(stderr, mysql_init failed\n); return -1; } if (mysql_real_connect(conn, 192.168.1.100, agri, password, smart_agri, 3306, NULL, 0) NULL) { fprintf(stderr, mysql_real_connect error: %s\n, mysql_error(conn)); mysql_close(conn); return -1; } // 执行查询 if (mysql_query(conn, SELECT temp, humidity FROM sensor_latest WHERE node_id1)) { fprintf(stderr, query error: %s\n, mysql_error(conn)); mysql_close(conn); return -1; } res mysql_store_result(conn); while ((row mysql_fetch_row(res))) { printf(temp%s, humidity%s\n, row[0], row[1]); } mysql_free_result(res); mysql_close(conn);编译时用gcc -o test test.c -lmysqlclient -I/usr/include/mysql前提是开发机上已经装了libmysqlclient-dev。在实际项目里我不会在主程序的每个文件里都写这些连接代码而是封装一个db.c模块提供db_connect()、db_insert_sensor()、db_control_device()这类函数调用方只关心业务逻辑。4.3 预处理语句与批量写入避免性能瓶颈嵌入式设备采集数据的频率如果是一秒一次直接每次INSERT一条MySQL能扛住但会频繁产生日志和事务提交对Flash存储也不友好。更好的做法是批量插入。用预处理语句的版本如下MYSQL_STMT *stmt; MYSQL_BIND bind[4]; const char *sql INSERT INTO sensor_history(node_id,temp,humidity,light) VALUES(?,?,?,?); stmt mysql_stmt_init(conn); mysql_stmt_prepare(stmt, sql, strlen(sql)); float temp 25.5; float humidity 60.2; int light 300; int node_id 1; memset(bind, 0, sizeof(bind)); bind[0].buffer_type MYSQL_TYPE_LONG; bind[0].buffer node_id; bind[1].buffer_type MYSQL_TYPE_FLOAT; bind[1].buffer temp; bind[2].buffer_type MYSQL_TYPE_FLOAT; bind[2].buffer humidity; bind[3].buffer_type MYSQL_TYPE_LONG; bind[3].buffer light; mysql_stmt_bind_param(stmt, bind); mysql_stmt_execute(stmt); mysql_stmt_close(stmt);使用预处理语句有两个明显好处一是SQL解析和执行计划可以复用执行效率高二是参数绑定方式天然避免了SQL注入和字符串拼接错误。如果连续采集多条可以把多个INSERT放到一个事务里然后一次性提交速度会快很多。mysql_autocommit(conn, 0); for (int i 0; i 10; i) { mysql_stmt_execute(stmt); } mysql_commit(conn); mysql_autocommit(conn, 1);4.4 中文乱码和时区问题怎么处理采集的数据本身是数字中文主要出现在设备名称、日志内容里。如果你希望在数据库里查询时不会看到一堆乱码有三处要统一服务端默认字符集、建表时的字符集、客户端连接字符集。C代码里连接成功后立即执行一次SET NAMES utf8mb4这样当前连接的字符集就固定为utf8mb4。建表时指定DEFAULT CHARSETutf8mb4MySQL服务端的my.cnf里也配置character-set-serverutf8mb4三层统一之后一般不会再乱码。5. 主控程序的实战拆解采集、控制、存储如何协同5.1 总体线程模型采集线程、数据库线程、控制线程如果整个主程序只在一个while循环里完成后台工作耦合度会很高传感器采集慢数据库写入慢控制逻辑就会卡住。所以我采用多线程模型让不同任务跑在不同的线程里采集线程负责定时读取传感器数据周期可以是2秒或5秒。存储线程通过一个环形缓冲区接收采集线程的数据批量写入MySQL。控制线程定时读取最新传感器值和阈值配置下发控制指令。主线程负责初始化全局资源、创建线程、等待退出信号。初始化阶段的一个重点是采集线程和控制线程之间需要共享传感器最新值。这里要加互斥锁避免读取到半个数据。实际代码中可以用pthread_mutex_t保护一个结构体。线程和数据库连接的关系也要理顺每个线程如果是独立使用数据库连接要单独mysql_init并mysql_real_connect不要多个线程共享同一个MYSQL句柄否则会出现未知错误。这是很多新手容易踩的陷阱。5.2 传感器采集与软件滤波传感器采集不只是调库读数值那么简单。我在做DHT11的时候发现读到的温湿度有时会突然跳到异常值。原因是DHT11的时序对延时非常敏感一旦系统调度延迟或中断打断读到的数据就会错乱。解决办法是两层过滤硬件层面给传感器供电加一个100nF去耦电容软件层面做连续多次采集和滤波。可以用中值滤波连续采5次去掉最大值和最小值取中间3个的平均值。int read_dht11_filtered(float *temp, float *humidity) { float temps[5], hums[5]; int valid_count 0; for (int i 0; i 5; i) { if (read_dht11_once(temps[i], hums[i]) 0) { valid_count; } usleep(200000); // 200ms间隔 } if (valid_count 3) return -1; // 排序加平均 ... return 0; }这种做法的目的很直接宁可少采几次也不能把错误数据写进数据库。错误数据一旦入库后面做趋势分析时就会产生错误的报警或者控制动作影响远比采集慢几秒严重。5.3 控制闭环阈值判断和继电器动作控制的逻辑相对简单但思路要清晰。系统从数据库的config表读取上下限阈值然后与最新传感器值比较如果温度大于上限比如35度则打开风机继电器。如果土壤湿度小于下限则打开水泵继电器同时记录一条设备日志。如果光照不足则打开补光灯。实现时注意两点一是执行器动作之后要有一个“保持时间”防止频繁启停。比如水泵开启后至少运行30秒否则传感器数据回流波动会导致继电器反复吸合继电器寿命很快就耗尽了。二是控制指令下发的GPIO操作要放到单独的函数里便于以后改成UART控制或Modbus控制。void control_relay(int relay_id, int on_off) { char gpio_path[64]; snprintf(gpio_path, sizeof(gpio_path), /sys/class/gpio/gpio%d/value, relay_id); int fd open(gpio_path, O_WRONLY); if (fd 0) return; write(fd, on_off ? 1 : 0, 1); close(fd); log_device_action(relay_id, on_off); }控制线程还要处理一个特殊情况如果数据库连不上阈值配置读不到那么自动控制逻辑应该进入“安全模式”也就是按一个默认的保守策略运行或者直接报警等待人工介入。5.4 稳定运行掉线重连、看门狗、守护进程嵌入式设备放在大棚里跑稳定性是第一位的。MySQL连接断掉是家常便饭网络抖动、服务重启、数据库重启都会造成连接失效。程序需要做自动重连每次执行SQL前检查连接状态如果发现连接不可用重试mysql_real_connect重试间隔指数递增最多到60秒。进程守护上我采用了两种方式。一是用systemd的WatchdogSec或cron定时检查进程是否存活二是程序自己实现内部看门狗采集线程每次循环都会更新一个时间戳控制线程如果发现该时间戳超过合理时间没有更新就认为采集线程卡死执行重启动作或报警。另外程序运行时的日志要写到syslog或文件里。日志至少包含时间、级别、模块、事件描述。不要只printf到终端因为一旦进程被systemd接管终端的输出未必能看到。用syslog的话日志收集更规范。6. 排错实录开发中遇到的那些坑6.1 数据库连不上从网络层到授权层的排查链路这是出现频率最高的问题。排查思路按以下链路走能省去很多痛苦网络层开发板ping服务器。如果ping不通先查网段、网线、路由器。服务层在服务器上执行netstat -lntp | grep 3306确认mysqld在监听。权限层登录MySQL执行SELECT user, host FROM mysql.user;确认用户允许的开发板IP登录。最常见的错误是root用户只允许localhost登录开发板当然连不上。连接参数C程序里确认主机名、端口、用户名、密码、数据库名都正确。有一个情况容易被忽略MySQL配置了skip-networking这样所有TCP连接都会被拒绝而本机命令行还能连接导致“为什么我本机能连程序连不了”的假象。6.2 编译和链接错误怎么逐条看懂编译报错大致分三类找不到头文件、找不到库文件、链接选项顺序错误。mysql.h: No such file or directory开发机上没安装libmysqlclient-dev或者头文件路径不在默认搜索路径。编译时用-I/usr/include/mysql指定。undefined reference to mysql_init说明链接时没有-lmysqlclient。注意链接库的选项要放在源文件之后比如gcc main.c -lmysqlclient如果写反了仍可能报错。cannot find -lmysqlclient说明库路径不在默认搜索路径用-L参数指定或者更新ldconfig缓存。如果交叉编译还要检查编译器和库架构是否匹配。用readelf -h libmysqlclient.so查看Machine属性确认为ARM而不是Intel。6.3 写入慢怎么定位和优化我在早期版本做了一个压测采集线程每秒采集一次直接单条插入跑了半天历史数据表有20万条数据之后写入开始变慢数据库CPU占用也高。排查后发现原因有两个每条INSERT都自动提交导致频繁的fsync。历史表没有按时间分区或索引过多插入时维护索引的开销大。优化手段我已经在前面提过用预处理语句批量事务每10条数据一次提交。优化后写入耗时降到原来的十分之一左右数据库CPU占用也明显下降。6.4 设备端断电和进程崩溃后的数据安全大棚现场难免有断电。断电时内存里的采集数据还没写入数据库这部分数据会丢但这是可以接受的因为采集本来就是周期性的。更怕的是MySQL写入了一半表损坏。所以历史数据表使用InnoDB引擎不要用MyISAM它的事务机制能保证断电恢复的一致性。数据表字段尽可能用FLOAT或DECIMAL避免存储过程中的四舍五入问题。进程崩溃的问题我遇到过两种一是控制线程里对设备控制函数处理不当导致段错误二是数据库连接失效后没有判空继续使用空指针。解决办法是统一做malloc/结果集的空指针检查同时用信号处理函数捕获SIGSEGV并写崩溃日志。7. 交付物、文档结构和后续扩展想法7.1 源码目录是怎么组织的项目交付时源码目录不能是一堆文件平铺。我参考常见开源项目的习惯最终组织如下smart_agri/ ├── src/ │ ├── main.c │ ├── sensor.c │ ├── sensor.h │ ├── db.c │ ├── db.h │ ├── control.c │ ├── control.h │ ├── log.c │ └── log.h ├── include/ │ └── common.h ├── sql/ │ └── init_db.sql ├── config/ │ └── agri.ini ├── Makefile ├── README.md └── docs/ ├── 需求文档.md ├── 设计文档.md └── 部署手册.md每个.c文件尽量控制在一到两个功能模块内比如sensor.c只负责传感器读取db.c只负责数据库操作control.c负责控制逻辑和阈值判断。头文件里只放对外接口和必要的宏定义别把实现细节暴露出去。Makefile里分别有编译目标、安装目标、清理目标交叉编译时用arm-linux-gnueabihf-gcc替换gcc。7.2 文档该怎么写才算是合格的项目交付很多人在项目完成后程序写得不错但文档质量一塌糊涂。对于智慧农业这种软硬结合的项目一份合格的文档应该至少包含四个部分项目概述讲清楚系统解决了什么实际问题运行环境是什么。系统架构设计模块划分、数据流图、线程模型最好画一张简易架构图并用文字解释清楚。部署说明从烧录系统、拷贝交叉编译产物、配置文件修改、启动服务到验证功能逐步描述。测试报告记录功能测试、长时间稳定性测试、异常恢复测试的结果体现项目的成熟度。文档不需要花哨但一定要能指导一个从来没接触过这套系统的人按着文档把整套系统搭起来。如果文档中漏掉一个“关闭防火墙”的步骤其他人复现时就会卡住。7.3 后续还能怎么扩展距离“智慧农业”完全体还有不少扩展空间。比如在采集数据的基础上接入MQTT协议把数据推送到云平台或者加入图像识别分析病虫害。数据库层可以做读写分离历史数据量大后引入时序数据库做冷热分离。控制层可以加入模糊控制算法根据气象数据预判温湿度变化而不是简单的阈值开关。不过这些扩展都建立在稳定扎实的基础框架之上。先跑通采集、存储、控制这条主线再去追求“智能化”才是最稳妥的路径。最后说点个人的体会。嵌入式Linux项目跟纯应用开发不一样它会同时考验你对硬件、操作系统、网络、数据库的理解。这套系统虽然名字长但本质就是把几个成熟技术组合起来解决一个具体的农业问题。如果你也正在做类似项目不用急着烧钱买服务器先拿一块开发板、一台旧电脑装好MySQL把C程序跑起来让数据真正流动起来系统就有价值了。本文还有配套的精品资源点击获取