欧美极品高清xxxxhd,国产日产欧美最新,无码AV国产东京热AV无码,国产精品人与动性XXX,国产传媒亚洲综合一区二区,四库影院永久国产精品,毛片免费免费高清视频,福利所导航夜趣136

標題: STC 8H XDATA的奇怪問題 [打印本頁]

作者: 非凡科技 時間: 2025-10-30 00:12
標題: STC 8H XDATA的奇怪問題
芯片是8H8K64U,最初使用的模式是DATA，后來程序大了提示溢出，就改為XDATA，發現有幾個初始化的變量都歸零了，逐一排查，當屏蔽掉讀取eeprom對數組賦值這段代碼時，不再歸零，關鍵是這段代碼一直正常使用，被改變的變量也跟數組沒有關系，在之前的正常代碼中如果設置為XDATA模式也會出現同樣問題，這幾個變量是U8類型，數組是u16類型，如果把被改變的變量改為u16類型就好了，百思不得其解，期間也嘗試了重新建立工程，加 volatile關鍵字都沒有解決，看看大家有啥好辦法不

作者: man1234567 時間: 2025-10-30 08:16
近幾次提問都是沒頭沒腦的口述，沒有電路沒有代碼沒有單片機具體型號，主打計算機算命

作者: a399288395 時間: 2025-10-30 08:27
我也好像遇到過，定義全局變量的時候，沒有賦初值，之前一直都正常，因為都是軟件自動賦0，也是因為超出空間，換編譯模式后，個別變量初值變了，不是0了，而是隨機數。我也沒細查，就是自己在定義變量的時候手動賦初值后解決。宏定義的值不會變，就是全局變量的值個別會變，

作者: rsx9583 時間: 2025-10-30 08:44
我使用8H8K64U的時候也發現，用DATA、PDATA和XDATA會存在問題，里面有一段涉及浮點的計算函數，選擇兩種模式的時候，計算結果會不一樣……有的感覺是明顯溢出的錯誤結果，不知道是怎么原因，也懶得追蹤。

作者: 搖滾一族 時間: 2025-10-30 08:45
頭文件用的是8H嗎？重新官網下載最新的頭文件替換一下試試

作者: 非凡科技 時間: 2025-10-30 09:07

a399288395 發表于 2025-10-30 08:27
我也好像遇到過，定義全局變量的時候，沒有賦初值，之前一直都正常，因為都是軟件自動賦0，也是因為超出 ...

我習慣性的定義時就進行賦值

作者: wufa1986 時間: 2025-10-30 09:35
因為XDATA的數據是隨機的，啟動代碼沒有初始化，所以定義必須初始化

作者: 非凡科技 時間: 2025-10-30 15:22

wufa1986 發表于 2025-10-30 09:35
因為XDATA的數據是隨機的，啟動代碼沒有初始化，所以定義必須初始化

已經初始化了，在定義時就賦值了

作者: 非凡科技 時間: 2025-10-30 15:24

搖滾一族發表于 2025-10-30 08:45
頭文件用的是8H嗎？重新官網下載最新的頭文件替換一下試試

是8H頭文件，遇到好幾次了，只要用XDATA模式就出莫名其妙的問題

作者: 非凡科技 時間: 2025-10-30 18:53
最后解決是定義時指定位置，不過這也太麻煩了吧

作者: WL0123 時間: 2025-10-31 07:18

非凡科技發表于 2025-10-30 15:24
是8H頭文件，遇到好幾次了，只要用XDATA模式就出莫名其妙的問題

使用STC8H做過多個項目，從沒有遇過樓主所述情況。

作者: Highnose 時間: 2025-10-31 11:58

非凡科技發表于 2025-10-30 15:24
是8H頭文件，遇到好幾次了，只要用XDATA模式就出莫名其妙的問題

換2塊芯片再試試

作者: lmn2005 時間: 2025-11-2 11:25
初始化時賦值比較好

作者: 188610329 時間: 2025-11-2 16:09
Keil 里面關閉雙DPTR指針。那東西不是給 STC 設計的。

作者: 622323wjl 時間: 2025-11-8 23:01
從問題現象和8051架構（8H8K64U屬于STC8系列，基于增強型8051）的內存特性來看，核心矛盾很可能出在**XDATA空間的地址分配沖突**與**數據訪問對齊要求**上，結合變量類型（U8/u16）的差異可進一步分析：
關鍵原因推測
8051架構中，`DATA`（內部直接尋址RAM）和`XDATA`（外部擴展RAM）的內存管理機制截然不同：
`DATA`空間小（通常128B~256B），編譯器會嚴格緊湊分配，且8位/16位變量地址默認對齊，不易沖突；
`XDATA`空間大（8H8K64U可能支持64KB），但編譯器對XDATA的地址分配更“松散”，且**16位數據（u16）在XDATA中默認按偶地址對齊**（為提高訪問效率），而8位數據（U8）可占任意地址。
當切換到`XDATA`模式后，若u16數組的起始地址被分配在“偶地址”，而U8變量的地址恰好被分配在數組相鄰的“奇地址”，此時對u16數組的賦值操作（每次訪問2字節）可能**越界覆蓋相鄰的U8變量**——因為u16的讀寫會一次性操作偶地址+奇地址兩個字節，若U8變量正好在奇地址上，就會被數組的賦值“順帶”改寫為0（EEPROM讀取的初始數據可能包含0，或數組初始化時的填充值）。
而將U8變量改為u16后，變量會被分配到偶地址，與u16數組的地址對齊，避免了被數組讀寫越界覆蓋，因此問題消失。之前`DATA`模式下未出現問題，是因為`DATA`空間小，編譯器自動規避了這種地址重疊；而`XDATA`空間大，分配策略更寬松，才暴露了沖突。

解決辦法
1. **強制指定地址，避免重疊**
在變量和數組定義時，通過編譯器擴展語法強制指定不重疊的XDATA地址（需參考芯片手冊確認XDATA可用范圍），例如：
```c
__xdata __at(0x0000) u16 eeprom_array[100];  // 數組指定在0x0000開始（偶地址）
__xdata __at(0x00C8) uint8_t var1;          // 變量指定在數組結束后的地址（0x0000 + 100*2 = 0x00C8，偶地址后接奇地址需間隔1字節）
```
確保變量地址與數組地址（含數組總長度覆蓋的范圍）無重疊。
2. **調整數組定義，確保對齊隔離**
在u16數組后預留1字節“隔離區”，或用`__align(2)`強制數組按2字節對齊，避免U8變量被“擠”到數組的地址范圍內：
```c
__xdata __align(2) u16 eeprom_array[100];  // 強制數組起始地址為偶地址
__xdata uint8_t var1;                   // 編譯器會自動將var1分配到數組范圍外
```
3. **檢查EEPROM讀取函數的邊界**
即使數組定義正確，若讀取EEPROM時的長度計算錯誤（例如實際讀取字節數超過數組容量），也可能越界覆蓋后續變量。需確認讀取代碼中的`長度參數`是否嚴格等于`數組元素數×2`（u16數組每個元素占2字節），例如：
```c
// 錯誤示例：若數組長度100，卻讀取201字節，會越界1字節
eeprom_read(eeprom_array, 0, 201);
// 正確示例：嚴格匹配100×2=200字節
eeprom_read(eeprom_array, 0, 100*2);
```
4. **利用.map文件分析地址分配**
編譯后生成的.map文件會記錄所有XDATA變量和數組的地址及占用范圍，通過搜索變量名和數組名，查看是否存在地址重疊（例如數組的結束地址 ≥ 變量的起始地址），直接定位沖突位置。
總結
本質是XDATA模式下8位變量與16位數組的地址分配沖突，因16位數據的“偶地址對齊”特性導致對數組的操作意外覆蓋了相鄰的8位變量。通過強制地址隔離、檢查讀寫邊界或利用.map文件排查重疊，可徹底解決問題。

歡迎光臨 (http://m.raoushi.com/bbs/)