【飛凌RZ/G2L開發(fā)板試用體驗】飛凌RZ/G2L的開發(fā)板試用測評報告三 -- 實時視頻編碼推流設計與實現(xiàn)
本文來源電子發(fā)燒友社區(qū)，作者：ALSET， 帖子地址：https://bbs.elecfans.com/jishu_2304469_1_1.html
直播編碼網(wǎng)咯推流開發(fā)測試
大信(QQ:8125036)
在前面的試用測試基礎上，逐漸熟悉了RZ/G2L開發(fā)板的SDK，在研究過它的音視頻硬件與軟件包后，在想進一步利用該開發(fā)板做音視頻的深度的應用開發(fā)。前面已經(jīng)實現(xiàn)了在開飯上采集視頻，采集視頻是視頻開發(fā)的基礎，基本熟悉了板子支持V4L2軟件工具，其實V4l2還能做很多其它的功能。同樣還有很多其它的音視頻軟件也有很強大的功能，比如ffmpeg ，GStream，VLC等開源的軟件庫等。 在本次試用中嘗試將這些軟件移植到該平臺上，以便發(fā)揮該平臺硬件的優(yōu)勢性能。這里就結(jié)合該開發(fā)板的音視頻功能進一步進行音視頻高級功能進行開發(fā)與測試。
圖1
一、實時視頻編碼推流整體設計為了完成在RZ/G2L板上的實時視頻采集編碼與網(wǎng)絡發(fā)送，需要整體的做設計，設計確定好整體測試的通信協(xié)議，以及配合測試的方式。
實時視頻網(wǎng)絡推流，是指的是把采集階段封包好的內(nèi)容傳輸?shù)椒掌鞯倪^程。主流的推送協(xié)議和優(yōu)缺點有：
RTMP是Realtime Messaging Protocol（實時消息傳輸協(xié)議）的縮寫，是Adobe公司為Flash/AIR平臺和服務器之間音、視頻及數(shù)據(jù)傳輸開發(fā)的實時消息傳送協(xié)議。RTMP協(xié)議基于TCP，包括RTMP基本協(xié)議及RTMPT/RTMPS/RTMPE等多種變種。
RTMP協(xié)議中，視頻必須是H264編碼，音頻必須是AAC或MP3編碼，且多以flv格式封包。RTMP是目前最主流的流媒體傳輸協(xié)議，對CDN支持良好，實現(xiàn)難度較低，是大多數(shù)的直播平臺的選擇。
不過RTMP有著一個最大的不足——不支持瀏覽器，且Adobe已不再更新。因此直播服務要支持瀏覽器的話，需要另外的推送協(xié)議支持。
Http Live Streaming是由Apple公司定義的基于HTTP的流媒體實時傳輸協(xié)議。它的原理是將整個流分為多個小的文件來下載，每次只下載若干個。服務器端會將最新的直播數(shù)據(jù)生成新的小文件，客戶端只要不停的按順序播放從服務器獲取到的文件，就實現(xiàn)了直播。基本上，HLS是以點播的技術實現(xiàn)了直播的體驗。因為每個小文件的時長很短，客戶端可以很快地切換碼率，以適應不同帶寬條件下的播放。
分段推送的技術特點，決定了HLS的延遲一般會高于普通的流媒體直播協(xié)議。
傳輸內(nèi)容包括兩部分：一是M3U8描述文件，二是TS媒體文件。TS媒體文件中的視頻必須是H264編碼，音頻必須是AAC或MP3編碼。
由于數(shù)據(jù)通過HTTP協(xié)議傳輸，所以完全不用考慮防火墻或者代理的問題，而且分段文件的時長很短。
WebRTC（Web Real-Time Communication），即“源自網(wǎng)頁即時通信”。WebRTC是一個支持瀏覽器進行實時語音、視頻對話的開源協(xié)議。WebRTC的支持者甚多，Google、Mozilla、Opera推動其成為W3C推薦標準。
WebRTC支持目前的主流瀏覽器，并且基于SRTP和UDP，即便在網(wǎng)絡信號一般的情況下也具備較好的穩(wěn)定性。
此外，WebRTC可以實現(xiàn)點對點通信，通信雙方延時低，此外，WebRTC可以實現(xiàn)點對點通信，通信雙方延時低，是實現(xiàn)“連麥”功能比較好的選擇。
UDP方式推流，有些直播應用會使用 UDP 做為底層協(xié)議開發(fā)自己的私有協(xié)議，因為 UDP 在弱網(wǎng)環(huán)境下的優(yōu)勢通過一些定制化的調(diào)優(yōu)可以達到比較好的弱網(wǎng)優(yōu)化效果，但同樣因為是私有協(xié)議也勢必與其它系統(tǒng)互聯(lián)互通有一定問題。
它的優(yōu)點是，協(xié)議簡單能夠進行定制化優(yōu)化，能夠在網(wǎng)內(nèi)進行視頻流組播，為后續(xù)視頻濾鏡，特效開發(fā)形成網(wǎng)絡分布式的工作環(huán)境，又開發(fā)方便，視頻傳輸延時低。能夠較快的實現(xiàn)那一套視頻實時系統(tǒng)。缺點就是只能在局域網(wǎng)傳輸，無法把視頻流發(fā)布到互聯(lián)網(wǎng)上。
但此次主要目的為了測試開發(fā)板的編碼與網(wǎng)絡實時傳輸?shù)男阅埽虼吮敬畏桨高x擇了UDP的技術方案。
本次實驗的運行結(jié)構(gòu)模式如下圖：
圖2
整體分為視頻推流端，即在開發(fā)板完成視頻采集，編碼和UDP發(fā)送視頻流數(shù)據(jù)。在視頻流發(fā)送端軟件設計如下，主要設計為多線程方式，分為三個線程，分別完成視頻采集工作，視頻編碼工作，網(wǎng)絡通訊工作，三個線程通過內(nèi)存隊列塊進行數(shù)據(jù)的轉(zhuǎn)移和存儲。這些模塊總體運行的設計時序如下圖：
圖3
接收端，即在Ubuntu上實現(xiàn)UDP數(shù)據(jù)包接收，解碼還原成視頻幀并顯示到窗口上的過程。視頻接收方設計為兩個工作線程，一個數(shù)據(jù)隊列，其中一個線程完成數(shù)據(jù)的接受，因為采用UDP的協(xié)議，這里接收方設計為先啟動，開發(fā)監(jiān)聽端口等待UDP數(shù)據(jù)包，接收到數(shù)據(jù)包后，解包，把數(shù)據(jù)包再放入接收隊列中。另外一個線程完成從隊列里獲取解包后的H264數(shù)據(jù)，進行解碼，生成圖像幀內(nèi)容，然后形成內(nèi)存圖片，然后刷新到UI主線程界面中去，接收端模塊設計工作調(diào)用和時序如下圖所示：
圖4
有了整體的設計后，就可以開始開發(fā)板上運行的發(fā)送端以及Ubuntu上的接收播放端軟件。二、V4l2視頻開發(fā)介紹
在前一篇視頻采集的開發(fā)里已經(jīng)用到了V4L2視頻框架，V4L2(Video for Linux2)， 是一個專門為 linux 設備設計的視頻采集和視頻設備管理框架，是Linux下關于視頻采集相關設備的驅(qū)動框架，為驅(qū)動和應用程序提供了一套統(tǒng)一的接口規(guī)范。它使應用與硬件設備接口無關，音視頻應用不必關心底層硬件的差異與實現(xiàn)。在不同硬件平臺上，V4L2有自己的適配和支持。在RZ/G2L板上是實現(xiàn)了該視頻框架，這里先使用V4L2進行一些測試與開發(fā)。
圖5
lVideo capture device ：從攝像頭等設備上獲取視頻數(shù)據(jù)。video capture是V4L2的基本應用。設備名稱為/dev/video,主設備號81，子設備號0~63lVideo output device ：將視頻數(shù)據(jù)編碼為模擬信號輸出。與video capture設備名相同。
lVideo overlay device ：將同步鎖相視頻數(shù)據(jù)（如TV）轉(zhuǎn)換為VGA信號，或者將抓取的視頻數(shù)據(jù)直接存放到視頻卡的顯存中。
lVideo output overlay device ：也被稱為OSD(On-Screen Display)
三、V4l2基本操作流程
lVBI device ：提供對VBI（VerticalBlanking Interval）數(shù)據(jù)的控制，發(fā)送VBI數(shù)據(jù)或抓取VBI數(shù)據(jù)。設備名/dev/vbi0~vbi31,主設備號81,子設備號224~255
lRadio device ：FM/AM發(fā)送和接收設備。設備名/dev/radio0~radio63,主設備號81，子設備號64~127
v4l2設備的基本操作流程如下
1、打開設備，例如 fd =open("/dev/video0",0)
2、查詢設備能力. 如:
structcapability cap;
ioctl(fd,VIDIOC_QUERYCAP,&cap)
3、設置優(yōu)先級(可選)
4、配置設備. 包括：
視頻輸入源的視頻標準，VIDIOC_*_STD
視頻數(shù)據(jù)的格式 , VIDIOC_*_FMT
視頻輸入端口, VIDIOC_*_INPUT
視頻輸出端口，VIDIOC_*_OUTPUT
5、啟動設備開始I/O操作。
V4L2支持一下三種I/O方式：
Read/Write：通過調(diào)用設備節(jié)點文件的Read/Write函數(shù)，與設備交互數(shù)據(jù)。打開設備后，默認使用的是此方法。
StreamI/O：流操作，只傳遞數(shù)據(jù)緩沖區(qū)指針，不拷貝數(shù)據(jù)。使用此方法，需要調(diào)用VIDIOC_REQBUFS ioctl來通知設備。流操作I/O有兩種方式memory map和user buffer。（具體區(qū)別后面章節(jié)介紹）
overlay：也可以理解為memory tomemory 傳輸。將數(shù)據(jù)從內(nèi)存拷貝到顯存中。overlay設備獨有的。
對于Capture device可以以如下方式啟動設備：
調(diào)用VIDIOC_REQBUFS ioctl來分配緩沖區(qū)隊列；
調(diào)用VIDIOC_STREAMON ioctl通知設備開始stream IO
調(diào)用VIDIOC_QBUF ioctl從設備獲取一幀視頻數(shù)據(jù)；
使用完數(shù)據(jù)后，調(diào)用VIDIOC_DQBUF將緩沖區(qū)還給設備，以便設備填充下一幀數(shù)據(jù)。
6、釋放資源并關閉設備。
圖6
在Ubuntu下開發(fā)代碼如下，主要完成了視頻流接收，解包，解碼最后送到 QT窗口上不斷刷新顯示，就完成了UDP實時視頻流的接收與播放。四、X264視頻編解碼庫編譯
在實時視頻傳輸中，需要對視頻進行壓縮，減少數(shù)據(jù)流的size,才能在網(wǎng)絡中傳輸。因此我們需要使用視頻編碼，在編碼時，我們可以選擇系統(tǒng)已經(jīng)自帶的編碼庫，編碼庫是開發(fā)板隨板提供的編碼SDK，隨板的編碼庫，支持了板載硬編碼方式，方便直接調(diào)用。
而在使用中，我們有時需要自己優(yōu)化或者改造編碼，那么使用軟編碼也是一種方案，這里我們也準備了軟編碼庫的編譯，并且在播放端也需要對視頻進行解碼，那么也需要視頻解碼。，
首先通過互聯(lián)網(wǎng)獲取 x264 代碼庫，如下：
git clonehttps://github.com/mirror/x264
圖7
在PC上開始進行配置編譯./configure --enable-static --enable-shared --disable-asm
圖8
然后進行編譯
make
圖9
圖10
同時我們也可以在交叉編譯環(huán)境下，嘗試編譯開發(fā)板上運行的x264庫，編譯配置經(jīng)過嘗試，以及修改相關config腳本后，執(zhí)行配置命令如下：
首先切換環(huán)境為交叉編譯環(huán)境，執(zhí)行source 命令：
source/home/lutherluo/workspace/G2LD/OKG2L-linux-sdk10/environment-setup-aarch64-smarc-rzg2l-toolchain
然后修改configure，讓其支持板上的poky-linux系統(tǒng)，然后使用如下參數(shù)，進行makefile 文件的配置生成
./configure --enable-shared --host=aarch64-linux--cross-prefix=aarch64-poky-linux---sysroot=/opt/poky/3.1.5/sysroots/aarch64-poky-linux
最后開始編譯
make
圖11
圖12
最終編譯成功過，可以檢查一下編譯出的x264庫，是ARM64 的動態(tài)連接庫。五、實時視頻編碼推流代碼實現(xiàn)
有了上面的支持庫的準備工作，就可以著手編寫主機端的播放器軟件以及開發(fā)板上的采集編碼推流軟件。
主機上采用QT開發(fā)包，開發(fā)一個簡單的桌面應用，使用QTDesigner快速的創(chuàng)建一個窗口，窗體中放置一個wiget控件做為視頻幀顯示區(qū)，下部中間放置幾個按鈕，連接好信號，槽后，按上面設計的時序圖完成，各個線程代碼和隊列的實現(xiàn)代碼，其界面設計和代碼設計如下圖：
圖13
圖14
代碼開發(fā)運行顯示如下圖，即等待H264的UDP數(shù)據(jù)中。
圖15
- V4L2_Video::V4L2_Video(QObject *parent) : QObject(parent)
- {
- m_is_start = false;
- pthread_mutex_init(&m_encode_queue_lock, nullptr);
- pthread_mutex_init(&m_send_queue_lock, nullptr);
- }
- int V4L2_Video::init()
- {
- struct v4l2_capability cap;
- struct v4l2_format fmt;
- struct v4l2_streamparm stream_parm;
- struct v4l2_requestbuffers req;
- struct v4l2_buffer buf;
- unsigned int buffer_n;
- pthread_t thread_id;
- int ret;
- fd = open(VIDEO_FILE, O_RDWR);
- if(fd == -1)
- {
- printf("Error opening V4L2 interfacen");
- return -1;
- }
- // 查詢設備屬性
- ioctl(fd, VIDIOC_QUERYCAP, &cap);
- printf("Driver Name:%snCard Name:%snBus info:%snDriver Version:%u.%u.%un",cap.driver,cap.card,cap.bus_info,(cap.version>>16)&0XFF, (cap.version>>8)&0XFF,cap.version&0XFF);
- //顯示所有支持幀格式
- struct v4l2_fmtdesc fmtdesc;
- fmtdesc.index=0;
- fmtdesc.type=V4L2_BUF_TYPE_VIDEO_CAPTURE;
- printf("Support format:n");
- while(ioctl(fd,VIDIOC_ENUM_FMT,&fmtdesc)!=-1)
- {
- printf("t%d.%sn",fmtdesc.index+1,fmtdesc.description);
- fmtdesc.index++;
- }
- // 設置幀格式
- fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; // 傳輸流類型
- fmt.fmt.pix.width = IMAGEWIDTH; // 寬度
- fmt.fmt.pix.height = IMAGEHEIGHT; // 高度
- fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; // 采樣類型
- // fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_MJPEG;
- fmt.fmt.pix.field = V4L2_FIELD_INTERLACED; // 采樣區(qū)域
- ret = ioctl(fd, VIDIOC_S_FMT, &fmt);
- if(ret < 0)
- {
- printf("Unable to set formatn");
- goto label_exit;
- }
- // 設置幀速率，設置采集幀率
- stream_parm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- stream_parm.parm.capture.timeperframe.denominator = VIDEO_FPS;
- stream_parm.parm.capture.timeperframe.numerator = 1;
- ret = ioctl(fd, VIDIOC_S_PARM, &stream_parm);
- if(ret < 0)
- {
- printf("Unable to set frame raten");
- goto label_exit;
- }
- // 申請幀緩沖
- req.count = ENCODE_QUEUE_FRAME_NUM;
- req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- req.memory = V4L2_MEMORY_MMAP;
- ret = ioctl(fd, VIDIOC_REQBUFS, &req);
- if(ret < 0)
- {
- printf("request for buffers errorn");
- goto label_exit;
- }
- // 內(nèi)存映射
- video_buffer = static_cast(malloc(req.count * sizeof(VideoBuffer)));
- for(buffer_n = 0; buffer_n < ENCODE_QUEUE_FRAME_NUM; buffer_n++)
- {
- // memset(&buf, 0, sizeof(buf));
- buf.index = buffer_n;
- buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- buf.memory = V4L2_MEMORY_MMAP;
- ret = ioctl (fd, VIDIOC_QUERYBUF, &buf);
- if (ret < 0)
- {
- printf("query buffer errorn");
- goto label_exit;
- }
- video_buffer[buffer_n].start = static_cast(mmap(nullptr, buf.length, PROT_READ|PROT_WRITE, MAP_SHARED, fd, buf.m.offset));
- video_buffer[buffer_n].length = buf.length;
- if(video_buffer[buffer_n].start == MAP_FAILED)
- {
- ret = -1;
- printf("buffer map errorn");
- goto label_exit;
- }
- // 放入緩存隊列
- ret = ioctl(fd, VIDIOC_QBUF, &buf);
- if (ret < 0)
- {
- printf("put in frame errorn");
- goto label_exit;
- }
- }
- // 創(chuàng)建幀獲取線程
- pthread_create(&thread_id, nullptr, frame_process_thread, this);
- // 創(chuàng)建編碼線程
- pthread_create(&thread_id, nullptr, yuyv422_to_H264_thread, this);
- // 創(chuàng)建編碼線程
- pthread_create(&thread_id, nullptr, h264_udp_broadcast_thread, this);
- return 0;
- label_exit:
- close(fd);
- return ret;
- }
開發(fā)板端程序開發(fā)使用V4l2框架，按上面總體設計，完成各個工作線程的代碼實現(xiàn)，隊列代碼的實現(xiàn)，這里很多代碼除了窗口部分和主機代碼基本一致，因此可以支持copy過來復用，大大減少開發(fā)開發(fā)時間。
圖16
圖17
圖18
六、實時視頻編碼推流測試使用前面獲得的攝像頭的設備參數(shù)以及能夠采集的視頻規(guī)格參數(shù)，輸入到采集編碼端的程序中，就可以運行視頻采集編碼推流測試程序了，這里測試時，主機地址為192.168.50.212開發(fā)板配置在同一路由器下，使用有線網(wǎng)絡地址為192.168.50.232。網(wǎng)絡配置好后，通過互ping檢查兩機通訊正常，網(wǎng)絡穩(wěn)定且時延較低時，開始進行啟動測試。
圖19
首先啟動主機端的程序，即在Ubuntu下啟動播放器程序，然后在啟動Gl2開發(fā)板上的推流測試程序，操作結(jié)果如下圖：
圖20
圖21
在幾秒后在主機端即可成功看到了開發(fā)板上推送過來的直播流，視頻流很流暢，畫面完成，無馬賽克等問題。不過視頻畫質(zhì)有點低，應該是編寫開發(fā)板端編碼代碼時，有關編碼碼率參數(shù)設置的較低有關，這個在后面可以按需進行優(yōu)化。隨文放了兩段視頻，一段是是手機拍攝直播編碼推送的攝像頭與開發(fā)板的連接，主機端的播放程序以及接收到直播后的直播畫面。另外一段拍攝了一下對比直播時延的畫面，可以測試直播時延。
七、推流傳輸時延測評
最后使用開發(fā)的測試程序，測試一下整體直播實時視頻的時延，測試方式是，將一個手機計時器打開放到PC電腦顯示的Ubuntu播放器旁邊，再將攝像頭對準手機和PC電腦屏幕，使手機實時時間和在播放器里播放畫面上的時間做對比就可以看出直播的時延。
試驗測試圖圖下，實測視頻見文末拍攝的視頻畫面。
最后多次測試，系統(tǒng)整體時延在 300ms ，左右，這里需要解釋下，時延與攝像頭設備，采集，編碼，傳輸，解碼，播放各個環(huán)節(jié)都有關，這里的測試的時延并不是開發(fā)板硬件的時延，而是這個整體測試的時延，在通過對各個環(huán)節(jié)的優(yōu)化和壓縮處理流程，可以大幅減少時延，筆者在某款開發(fā)板上進過優(yōu)化軟件實現(xiàn)，實現(xiàn)到<50ms的網(wǎng)絡視頻時延效果。
在實時采集編碼時，開發(fā)板的系統(tǒng)資源使用情況如下圖：
圖22
可見板上資源消耗非常小，是因為芯片采用的硬編碼的方式，所以能夠較少的使用CPU的資源。從本次測試的效果看，開發(fā)板系統(tǒng)采集編碼效率較高，能夠支持芯片實時的硬編碼和網(wǎng)絡發(fā)送。這為后面產(chǎn)品開發(fā)提供很好的基礎，在較長時間（>60分鐘）的視頻編碼推送測試中，視頻編碼推送程序和系統(tǒng)運行非常穩(wěn)定，沒有出現(xiàn)異常中斷等現(xiàn)象，并且在持續(xù)視頻采集中系統(tǒng)穩(wěn)定運行，這也可以看出該開發(fā)板在視頻處理時的穩(wěn)定性。
-----------------------------------干貨分割線-----------------------------
附件：
開發(fā)板上編譯好的可形成測試軟件包，感興趣的可以在開發(fā)板上測試一下，播放器可以用 VLC ，windows 或者 Ubuntu下均可以。
【項目源代碼+開發(fā)板體驗視頻，詳見作者原文帖子內(nèi)容】
聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉(zhuǎn)載。文章觀點僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用，如有內(nèi)容侵權或者其他違規(guī)問題，請聯(lián)系本站處理。
舉報投訴
-
飛凌
+關注
關注
0文章
134瀏覽量
16383 -
開發(fā)板試用
+關注
關注
3文章
301瀏覽量
2318
發(fā)布評論請先 登錄
相關推薦
熱點推薦
有獎試用！！RA-Eco-RA4M2-100PIN-V1.0開發(fā)板試用活動報名
RA-Eco-RA4M2-100PIN-V1.0開發(fā)板試用活動
具有3D圖形和視頻編解碼器的通用 MPU RZ/G2L 數(shù)據(jù)手冊
RZ/G2L 微處理器配備 Cortex-A55?（1.2GHz）CPU、16 位 DDR3L/DDR4 接口、使用 Arm? Mali-G31 的 3D 圖形引擎以及
【ELF 2學習板試用】ELF 2開發(fā)板開箱測評
簡介
很高興收到飛凌嵌入式提供的ELF 2開發(fā)板，ELF 2學習板基于瑞芯微RK3588旗艦處理
發(fā)表于 01-15 09:43
瑞薩電子RZ MPU家族精品RZ/N2L產(chǎn)品介紹
瑞薩生態(tài)合作伙伴RT-Thread推出了一款高性能、多功能以太網(wǎng)MPU開發(fā)板EtherKit，搭載瑞薩電子RZ/N2L，并攜手瑞薩電子舉辦了產(chǎn)品發(fā)布會和產(chǎn)品研討。瑞薩電子在本次活動中介紹了瑞薩明星
飛凌嵌入式受邀亮相瑞薩2024工業(yè)技術研討會
飛凌嵌入式作為瑞薩電子的生態(tài)合作伙伴，給2024瑞薩電子MCU/MPU工業(yè)技術研討會的現(xiàn)場觀眾帶去了基于RZ/G2L高性能多核異構(gòu)處理器設計開發(fā)
瑞薩RZ/G2L微處理器的SD卡GPIO控制功能介紹
RZ/G2L微處理器配備Cortex-A55(1.2 GHz) CPU、16位DDR3L/DDR4接口、帶Arm Mali-G31的3D圖形加速引擎以及
【飛凌嵌入式OK3588J-C開發(fā)板體驗】OK3588J-C開發(fā)板開箱評測
很高興收到飛凌嵌入式提供的OK3588J-C開發(fā)板，這是瑞芯微最新的8K旗艦8核SOC，非常適合用來做機器視覺，AI，語音識別，圖像處理。
下面來看看OK3588J-C開發(fā)板的開箱圖，
發(fā)表于 12-04 15:23
RZ/G2L高速虛擬串口方案 基于瑞薩RZ/G2L SMARC開發(fā)板的虛擬(Virtual UART)實現(xiàn)方案
RZ/G2L具有豐富的外設，比如千兆以太網(wǎng)，CANFD以及豐富的UART接口，可以滿足工業(yè)數(shù)據(jù)收集處理相關的應用。本文主要介紹基于瑞薩RZ/G2L SMARC
發(fā)表于 11-20 14:41
?887次閱讀
有獎試用！！RA-Eco-RA4E2-64PIN-V1.0開發(fā)板試用活動開始報名
有獎試用！！RA-Eco-RA4E2-64PIN-V1.0開發(fā)板試用活動開始報名
【飛凌嵌入式OK3576-C開發(fā)板體驗】開箱報告
簡介
很榮幸參與到本次由飛凌嵌入式和電子發(fā)燒友提供的OK3576-C開發(fā)板的試用機會。
飛凌嵌入
發(fā)表于 08-22 02:13
飛凌全志T527開發(fā)板buildroot系統(tǒng)下擴大rootfs分區(qū)
一、實驗環(huán)境介紹
硬件：飛凌T527開發(fā)板（2G+16G）
軟件：全志Tina sdk
二、查看當前存儲分布
登入開發(fā)板，執(zhí)行 fdisk
發(fā)表于 07-18 14:45
RZ/G2L雙千兆網(wǎng)口使用場景 BASIC模式 SWITCH模式 ROUTER模式
RZ/G2L支持兩個通道的千兆以太網(wǎng)口，有必要給大家介紹一下這兩個千兆網(wǎng)口可實現(xiàn)的三種應用場景，方便大家有針對性地給客戶的應用場景做推廣。
工商網(wǎng)監(jiān)
評論