做嵌入式軟件的一般用什么軟件寫和看代碼比較好？瀏覽的網(wǎng)頁到這個(gè)問題，感覺自己的確有見意這個(gè)可以彼此分享幫一下忙。前提是51、STM32、Nordic的電路設(shè)計(jì)算嵌入式設(shè)計(jì)。1、寫代碼個(gè)人建議MDK我第

做嵌入式軟件的一般用什么軟件寫和看代碼比較好？

瀏覽的網(wǎng)頁到這個(gè)問題，感覺自己的確有見意這個(gè)可以彼此分享幫一下忙。前提是51、STM32、Nordic的電路設(shè)計(jì)算嵌入式設(shè)計(jì)。

1、寫代碼個(gè)人建議MDK我第一時(shí)間建議使用的單片機(jī)是STC89C51單片機(jī)，剛開始接近的時(shí)候在用的匯編，當(dāng)時(shí)才發(fā)現(xiàn)改這個(gè)代碼太麻煩，不過都是水平不足以的原因。偶然間可以使用了C語言，接著用MDK編譯程序幫一下忙，然后把直接燒寫完單片機(jī)就能真的跑起來。

當(dāng)然爽呆了，不要說匯編重新編寫了，修改定時(shí)器的中斷時(shí)間連所謂的的寄存器都沒好好看過，不過程序能跑就行。因?yàn)樵谌肓碎T的時(shí)候在用MDK寫程序和編譯最方便。

現(xiàn)在工作中在用也很多的是STM32，這個(gè)基于條件ARM的MCU可以使用站了起來比C8051核的51單片機(jī)確實(shí)是奇怪一些。就簡(jiǎn)單點(diǎn)不使用一個(gè)GPIO的控制輸出，就得設(shè)置時(shí)鐘，設(shè)置里頻率，設(shè)置里為輸出，一大堆流程。

當(dāng)然了ST卻絕是一家我心的公司，人家提供給了基于MDK的SDK呀，咱們動(dòng)態(tài)創(chuàng)建初始化函數(shù)就就ok啦。然后再再比葫蘆畫瓢就能并且自己的可以設(shè)置了。但是，J-link的下載都在MDK中能夠完成了，多不舒服。

2、閱讀代碼可以選擇類型Visual Studio Code我是個(gè)菜鳥工程師，混吃等死的那種，因此在不會(huì)的時(shí)候會(huì)選擇向論壇的大佬求教。諸如建議使用Nordic的芯片時(shí)，要驅(qū)動(dòng)音頻，驅(qū)動(dòng)音頻的方案相當(dāng)多，但是基本上是設(shè)計(jì)和實(shí)現(xiàn)STM32和ESP的。

大佬給的例子程序又是設(shè)計(jì)和實(shí)現(xiàn)他們的，這里就有一個(gè)問題那是IIS總線的使用我還是有太大的區(qū)別。光是手抄早就不能不能解決問題的方法，就是需要自己根據(jù)datasheet和大佬的例子自己寫代碼了。

有一點(diǎn)大家都很不清楚，要是是幫個(gè)忙，總不能郵箱你另一個(gè)求完整的程序，自己編譯就能用吧。能給一個(gè)c文件和件早就是慷慨了，這個(gè)時(shí)候自己看看吧代碼，通過datasheet寫點(diǎn)底層驅(qū)動(dòng)程序時(shí)候就不用MDK了，一是早就在用MDK在編寫程序了，二是咱們辦公室的電腦配置也就那樣，先打開慢。

而現(xiàn)在建議使用一款界面看上去舒服，意見文件匯編語言的就行，明確的這個(gè)需要可以確定Visual Studio Code。哈哈，千萬不能覺著這個(gè)軟件沒有辦法看，人家都是有真本事的。

很多本身一定會(huì)開源代碼性質(zhì)的項(xiàng)目就可以使用的這個(gè)，前段時(shí)間不參加論壇的GD32DEmcu試用活動(dòng)，因?yàn)榇a編譯不需要按裝了PlatformIO插件，是可以編譯程序的。不過這里的程序構(gòu)建，采用的是Makefile的形式。

就我推薦這兩款了，軟件的使用見仁見智吧，結(jié)果還是得選擇很好自己你操作習(xí)慣的那款。

Memcached真的過時(shí)了嗎?Redis與Memcached的比較？

很多開發(fā)者都以為Redis不很可能比Memcached快，Memcached已經(jīng)基于組件內(nèi)存，而Redis具高持久化保存到特性，就算是是異步模式的，Redis也不可能比Memcached快。不過測(cè)試結(jié)果基本都是Redis占絕對(duì)優(yōu)勢(shì)。一直在在努力思考這個(gè)原因，目前想到的原因有這幾方面。

Libevent。和Memcached差別，Redis并沒有選擇libevent。Libevent為了取悅于通用性照成代碼龐大(目前Redis代碼還不了libevent的1/3)及犧牲了在特定的事件平臺(tái)的不少性能。Redis用libevent中兩個(gè)文件直接修改利用了自己的epolleventloop(4)。業(yè)界不少開發(fā)者也見意Redis不使用另外一個(gè)libevent高性能替代libev，可是作者應(yīng)該只要能堅(jiān)持Redis應(yīng)該是小巧并去感情依賴的思路。一個(gè)印象很深刻的細(xì)節(jié)是編譯器Redis之前并不需要不能執(zhí)行./configure。

CAS問題。CAS是Memcached中比較更方便的一種防止競(jìng)爭(zhēng)修改資源的方法。CAS利用不需要為每個(gè)cacheunlock設(shè)置一個(gè)隱藏地的castoken，cas也很value版本號(hào)，隔一段時(shí)間set會(huì)token不需要指數(shù)式，但受到CPU和內(nèi)存的加持開銷，雖說這些各種開銷很小，但到單機(jī)10Gcache以及QPS上萬之后這些開銷可能會(huì)給雙方低些給他一些極其細(xì)微性能差別(5)。