為何寫flash的時候要位址左移一位?

2021-07-22 08:38:23 字數 1682 閱讀 9201

**一:

#define writeflash(addr,dat) *((volatile int16u *)(addr<<1))=(int16u)dat

#define readflash(addr) (*((volatile int16u *)(addr<<1)))

/*addr為讀寫操作的半字位址,data則為要寫入的半字資料。因為arm處理器是以位元組為單位

進行資料處理的,而sst39vf160是16位資料寬度,所以,addr位址必須左移1位。*/

**二:

//擦除是否為空

int sst39vf160_checkblank(int32u addr,int32u wordsize)

return 1;

}

在網上看到這麼一段話,我琢磨不透。「s3c44b0x是按照位元組編址的,而flash rom是以16位為乙個儲存單元」是怎樣推出要「偏移一位」呢?**一的注釋和上一段一樣,也沒有給出是如何推導出來的。而且**二中的下面這行**的注釋更是讓我不解。前面的i被定義成int32u 型,怎麼通過左移一位就可以得到16的資料呢?懇請各位大俠給出較為詳細的解釋.

temp=*((volatile int16u *)(i<<1)); //位址左移一位,也就得到16位的資料了。

解答:關於那個錯位,我不知道能不能跟你說清楚。首先,sst39vf16 flash是16位的,也就是以兩個位元組(半字)為最小操作單位的。也就是說你在flash位址上給0x00000,則它給出的資料是第乙個16位的半字;在flash位址上給0x00001,它給出的是第二個16位的半字;在flash位址上給0x00002,它給出的是第三個16位的半字。。。但arm的位址是以位元組編址的,它可以以位元組單位來讀取或者寫外設。

假設我們要讀取flash的第乙個位元組,ldrb r0,[r1];將r1內容寫0x00000,這個時候arm執行的是這樣的操作:

1、送出位址0x00000

2、在d0-d15上讀取資料

3、將讀到的16位資料的低8位給r0低8位(高24位為0)

假設我們要讀取flash的第二個位元組,ldrb r0,[r1];將r1內容寫0x00001,

這個時候arm執行的是這樣的操作:

1、送出位址ox00001

2、在d0-d15上讀取資料

3、將讀到的16位資料的高8位給r0的低8位(高24位為0)

從上面的操作可以看到,如果我們一一對應的將arm和flash得位址連線,那麼我們想讀flash的第2個位元組的話,就沒有辦法讀到了。因為你位址給0x00001,flash就在資料線上給的是第3個位元組和第4個位元組的資料,並將高8位(flash的第4個位元組)給r0;如果你給的位址是0x00000的話,arm的理解就是將資料線d0-d15的低8位給r0,顯然這個16位的資料是flash的第1個位元組和第2個位元組的資料,低8位指的就是第乙個自己的資料。顯然怎麼也讀不到flash的第2個資料。

我們既要遵循arm的規則,又要讓flash給我們正確的資料。你自己想應該怎麼辦?很簡單,把arm給的位址最低位剪掉,把剩下的給flash。要讀第2個位元組,還是送0x00001,但是最後的1被剪掉了,flash得到的位址是ox00000,顯然給出的資料是第1個和第二個位元組。而arm覺得送出的位址是0x00001啊,應該把高位址給r0啊,即把第2個位元組給了r0。就是乙個「欺上瞞下」的過程。

在寫php的時候的一些經驗

今天 因為乙個驗證碼問題 搞了一下午 所以很就結合抑鬱 為什麼 會出現這個錯誤 因為 我們專案的伺服器的變更 所以專案的配置檔案也跟著一起要進行更改 所以在更改眾多配置檔案的時候 就埋下了 接下來要處理的問題的隱患 當把配置檔案都改好上傳之後 還並不知道驗證碼那邊出問題了 知道有人跟我說 出問題了 ...

寫記錄表的時候,如何產生唯一標識。

1.獲取隨機的唯一標識 有可能系統版本較低,沒有class if system uuid,可以使用2的方法 data ldf system uuidtype ref to if system uuid,ldf uuid type sysuuid c32.ldf system uuid cl uuid...

關於寫js的時候的一些問題

size medium 第一種情況 missing after argument list 這種情況產生的原因是在js中 string型別的變數在js函式傳遞的時候必需包含在雙引號中,這樣你加上雙引號就沒問題了。具體的例子是,我在生成html 的js中如下寫法的時候是會報錯的。str str 但是當...