0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
电子发烧友
开通电子发烧友VIP会员 尊享10大特权
海量资料免费下载
精品直播免费看
优质内容免费畅学
课程9折专享价
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

數(shù)據(jù)分包設(shè)計的考慮

Q4MP_gh_c472c21 ? 來源:最后一個bug ? 作者:最后一個bug ? 2022-05-12 14:54 ? 次閱讀

大家好,我是bug菌~前些天跟大家解釋了如下代碼:

		

offset=len/64+!!(len%64);

并且跟大家詳細聊了一下其中的!!操作,然而這段代碼的主要功能還是為了進行分包處理,既然是分包自然而然就會想到一種常用的分包處理方法,這也是本文的重點。

數(shù)據(jù)分包在嵌入式軟件開發(fā)中算是一種非常常見的處理,其主要原因還是硬件上的各種限制,不得已而為之,特別是在通信協(xié)議的定制過程中尤為常見。

1

傳輸限制

玩過各種通信協(xié)議的朋友都知道,像非常多的通信方式都是以數(shù)據(jù)幀的形式來進行傳遞,不同的通信方式因各方面的因素又存在一個最大傳輸字節(jié)數(shù)的限制,考慮到穩(wěn)定性、容錯性等等對單次發(fā)送的數(shù)據(jù)長度進行限制,又或者所接收的設(shè)備其內(nèi)存資源有限,不足以接收、處理過長的數(shù)據(jù)包。

zigbee這樣的物理層每幀最大只能傳輸127個字節(jié),通過每層不斷的封包到應(yīng)用層后每包才100個字節(jié)。當(dāng)上層用戶協(xié)議的數(shù)據(jù)包過大,無法一次性傳輸,就只能分包或者分組下發(fā),最終接收方組包后解析提取數(shù)據(jù)。

2

分包設(shè)計的考慮

有些朋友該說了,我就不喜歡搞大包發(fā)送,使用短包,然后通過不同的標(biāo)識進行不同數(shù)據(jù)位的定義,簡單很多。

當(dāng)然長包與短包并沒有本質(zhì)上的區(qū)別,其目的都是傳輸數(shù)據(jù),但在實踐的過程中還是會遇到居多處理上的區(qū)別:

數(shù)據(jù)的同步性方面:

比如當(dāng)通信的設(shè)備轉(zhuǎn)速超了,同時報了一個故障碼,如果采用短包上傳,很可能故障碼和轉(zhuǎn)速位于不同的數(shù)據(jù)包中,當(dāng)數(shù)據(jù)包丟包或許是亂序,就會導(dǎo)致當(dāng)接收到故障碼的時候,此時超標(biāo)的轉(zhuǎn)速值已經(jīng)丟失或者延時等,有概率不能準(zhǔn)確獲得故障時的超標(biāo)轉(zhuǎn)速。

而使用長包,只需要發(fā)送方能夠保證打包的時候同步,那么接收方就可以同步獲得相應(yīng)的數(shù)據(jù)。

通信協(xié)議設(shè)計自由度方面:

在設(shè)計協(xié)議的時候,長包會更加的自由,大多數(shù)情況都不需要考慮大數(shù)據(jù)傳輸?shù)?/span>占位問題,甚至在編碼上直接copy結(jié)構(gòu)體發(fā)送也是相當(dāng)方便的。

3

計算包數(shù)問題

既然長包的設(shè)計相對比較方便。那分包處理是少不了的?

分包還不簡單?

要發(fā)100個字節(jié)的數(shù)據(jù),每次只能發(fā)15個,那發(fā)送7包就可以了,直接編碼,代碼如下:

SendPack=SendNum/PackNum;
if(SendPack%PackNum)SendPack++;

這算是常規(guī)操作,如果覺得有點難度,還要多敲敲代碼。

一般用C語言比較久的朋友都想去簡化這種操作,畢竟實現(xiàn)一個簡單的功能需要兩行代碼,強迫癥,忍不了~

就有了本文開頭的!!處理方式,或者如下處理也是一樣的:


		

#include #definePackNum(total,single)(total/single+((total%single)?1:0)) intmain(void) { printf("packNum:%d ",PackNum(100,15)); printf("packNum:%d ",PackNum(150,15)); printf("packNum:%d ",PackNum(200,15)); printf("packNum:%d ",PackNum(5,15)); printf("hellobug~ "); return0; }

僅僅只是秀了一下C語言的幾個小技巧罷了,并沒有實質(zhì)性的改善。

很明顯,本文的重點并不是介紹如上兩種辦法,而是如下更加高效的代碼:


		

PackNum=(total+(singleNum-1))/singleNum;

對于一些以往沒有使用的朋友或許有點懵,那bug菌這是嘮叨幾句:

該表達式主要是利用了取整的特性來達到+1的目的。

直接除單包個數(shù),不能整除的情況,結(jié)果都會少1,比如10/6,應(yīng)該是2包,而由于最終除法結(jié)果只能是1。

所以通過補償(singleNum - 1)后,結(jié)果就分兩種情況:

1、原本能夠整除的數(shù),補償后無法整除,結(jié)果與之前一致;

2、原本不能夠整除的數(shù),其余數(shù)必然在【1~(singleNum- 1)】之間,所以補償以后,其余數(shù)范圍在【singleNum~(singleNum+ singleNum- 2),則其結(jié)果為整除部分+1。

與我們分包個數(shù)是一致的,相當(dāng)巧妙。

4

擴展

這種方法不僅僅只是用于通信的分組中,把思維進一步泛化。

只要是類似分組的處理都可以使用該算法

比如內(nèi)存的分區(qū),flash的設(shè)計上都是一個扇區(qū)一個扇區(qū)的分布。

現(xiàn)在想分配整數(shù)個扇形區(qū)域用于存儲某些數(shù)據(jù),每一個扇區(qū)512個字節(jié),存儲2000個字節(jié)的數(shù)據(jù),該分配幾個扇區(qū)?

我相信你已經(jīng)有答案了~

審核編輯 :李倩

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 數(shù)據(jù)
    +關(guān)注

    關(guān)注

    8

    文章

    7221

    瀏覽量

    90089
  • 數(shù)據(jù)包
    +關(guān)注

    關(guān)注

    0

    文章

    268

    瀏覽量

    24596
  • 代碼
    +關(guān)注

    關(guān)注

    30

    文章

    4856

    瀏覽量

    69435

原文標(biāo)題:談?wù)剶?shù)據(jù)分包及相關(guān)小技巧

文章出處:【微信號:gh_c472c2199c88,微信公眾號:嵌入式微處理器】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    選擇數(shù)據(jù)采集器時需要考慮的因素

    在選擇數(shù)據(jù)采集器時,需要考慮以下關(guān)鍵因素,以確保所選設(shè)備能夠滿足特定應(yīng)用需求并具有良好的性能和可靠性: 采集需求 : 數(shù)據(jù)類型和數(shù)量 :確定需要采集的數(shù)據(jù)類型(如溫度、濕度、壓力、位移
    的頭像 發(fā)表于 11-28 16:02 ?496次閱讀

    socket編程的安全性考慮

    在Socket編程中,安全性是一個至關(guān)重要的考慮因素。以下是一些關(guān)鍵的安全性考慮和措施: 1. 數(shù)據(jù)加密 使用TLS/SSL協(xié)議 :TLS/SSL(傳輸層安全性/安全套接層)是網(wǎng)絡(luò)安全中最常用的協(xié)議
    的頭像 發(fā)表于 11-01 16:46 ?419次閱讀

    BiCMOS ICs供電的考慮因素

    電子發(fā)燒友網(wǎng)站提供《BiCMOS ICs供電的考慮因素.pdf》資料免費下載
    發(fā)表于 10-23 09:34 ?0次下載
    BiCMOS ICs供電的<b class='flag-5'>考慮</b>因素

    字節(jié)跳動考慮在泰國新建數(shù)據(jù)中心

    據(jù)知情人士透露,字節(jié)跳動旗下的BytePlus正在積極考慮于明年在泰國設(shè)立一個全新的數(shù)據(jù)中心。這一舉措旨在進一步拓展公司在云計算和人工智能服務(wù)領(lǐng)域的全球布局。
    的頭像 發(fā)表于 10-22 17:05 ?408次閱讀

    高速ADC與FPGA的LVDS數(shù)據(jù)接口中避免時序誤差的設(shè)計考慮

    電子發(fā)燒友網(wǎng)站提供《高速ADC與FPGA的LVDS數(shù)據(jù)接口中避免時序誤差的設(shè)計考慮.pdf》資料免費下載
    發(fā)表于 10-15 09:50 ?6次下載
    高速ADC與FPGA的LVDS<b class='flag-5'>數(shù)據(jù)</b>接口中避免時序誤差的設(shè)計<b class='flag-5'>考慮</b>

    AM572x散熱考慮

    電子發(fā)燒友網(wǎng)站提供《AM572x散熱考慮.pdf》資料免費下載
    發(fā)表于 10-11 10:42 ?0次下載
    AM572x散熱<b class='flag-5'>考慮</b>

    高速電路PCB的EMC設(shè)計考慮

    電子發(fā)燒友網(wǎng)站提供《高速電路PCB的EMC設(shè)計考慮.pdf》資料免費下載
    發(fā)表于 09-21 11:50 ?5次下載

    音頻產(chǎn)品Buck轉(zhuǎn)換器設(shè)計考慮

    電子發(fā)燒友網(wǎng)站提供《音頻產(chǎn)品Buck轉(zhuǎn)換器設(shè)計考慮.pdf》資料免費下載
    發(fā)表于 09-09 14:34 ?0次下載
    音頻產(chǎn)品Buck轉(zhuǎn)換器設(shè)計<b class='flag-5'>考慮</b>

    DLPC910的datasheet中未看到pindelay數(shù)據(jù),DLPC910和DMD之間的LVDS總線是否要考慮pindelay的影響?

    如標(biāo)題所述,DLPC910的datasheet中未看到pindelay數(shù)據(jù),DLPC910和DMD之間的LVDS總線是否要考慮pindelay的影響
    發(fā)表于 08-16 06:18

    ESP8266 RTOS SDK中Lwip自動分包及重組的問題求解

    數(shù)據(jù)包自動分包和重組,但是實際上我修改之后仍然無效,請問是不是還有其他宏需要修改?或者lwip本身有限制?
    發(fā)表于 07-10 08:12

    esp32如何接收1M以上的數(shù)據(jù)?

    手里有1塊ESP32_WROVER 模組 ,服務(wù)器發(fā)送不定長數(shù)據(jù)可能最大會到1M-2M,我不太清楚怎么處理,目前使用recv接收1K左右的數(shù)據(jù)正常,希望有這方面的思路 ,可以使用PSRAM直接接收還是分包接收?
    發(fā)表于 06-21 14:56

    ESP32 BLE使用nimble協(xié)議棧怎樣才能發(fā)送超過20個字節(jié)的數(shù)據(jù)?

    我在使用藍牙傳送傳感器數(shù)據(jù),目前只能發(fā)送20個字節(jié)大小的數(shù)據(jù)包,請問大家是如何實現(xiàn)發(fā)送大于20字節(jié)的數(shù)據(jù)包的。我想嘗試將數(shù)據(jù)分包發(fā)送,但是
    發(fā)表于 06-17 07:18

    比亞迪出席2024年泰國曼谷工業(yè)分包展覽會

    2024年5月15日至18日,比亞迪集團采購處及泰國分公司代表出席了泰國曼谷工業(yè)分包展覽會(SUBCON Thailand 2024),彰顯了比亞迪在區(qū)域市場的深入拓展和對創(chuàng)新制造業(yè)合作的堅定承諾。
    的頭像 發(fā)表于 05-21 09:36 ?437次閱讀
    比亞迪出席2024年泰國曼谷工業(yè)<b class='flag-5'>分包</b>展覽會

    ESP32 基于ESP-IDF5.1.2 使用WIFI_AP_UDP發(fā)送數(shù)據(jù)時報錯 errno=12

    使用ESP32做無線傳輸,發(fā)送一幀圖像數(shù)據(jù),進行分包,每次發(fā)送14300字節(jié),大概率出現(xiàn)丟失最后一包,并伴隨sendto報錯信息,errno=12(Not enough space 空間不夠)
    發(fā)表于 05-07 16:34

    stm32f746g如何使用usb一次性發(fā)送一包超過1.5M的數(shù)據(jù)?

    目前我正在用disco stm32f746g的板子通過高速usb給上位機傳輸數(shù)據(jù),因為數(shù)據(jù)量比較大,所以一包數(shù)據(jù)就超過1.5M。上位機是一個很多年前寫的成熟版本,無法更改。高速usb的緩存達不到1.5M,所以如何
    發(fā)表于 03-13 08:29

    電子發(fā)燒友

    中國電子工程師最喜歡的網(wǎng)站

    • 2931785位工程師會員交流學(xué)習(xí)
    • 獲取您個性化的科技前沿技術(shù)信息
    • 參加活動獲取豐厚的禮品