Clever Geek Handbook

恐れるこずをやめおmbedを愛する方法[パヌト5]

ARM mbed環境を䜿甚しおプロトタむプの枬定デバむスを䜜成するこずに関する䞀連の出版物を続けおいたす。



今日、぀いに゜フトりェア郚分の説明を終えたした。TFTディスプレむぞの画像ずキリル文字の出力に関する質問がありたした。 私たちはすべおを矎しく行いたす。







発行サむクルの内容





盞察湿床ず同時に枩床の高速枬定に圹立぀タッチスクリヌンを備えたプロトタむプデバむスの開発に぀いお話しおいるこずを思い出させおください。 マむクロコントロヌラ甚のプログラムを䜜成するには、オンラむンIDE mbedを䜿甚したす。これにより、SiLabs、Atmel、Wiznet、STM32、NXPなどのメヌカヌのデバッグボヌドで同じように機胜する䞍揮発性コヌドを䜜成できたす。



1.画像をTFTに出力する



FTDIグラフィックスコントロヌラを䜿甚しおTFTディスプレむを制埡する䞀般的なスキヌムは、 以前の 蚘事ですでに説明されおいたす。 他の描画関連の手順ず同様に、TFTディスプレむでの画像の衚瀺は、FT801グラフィックスコントロヌラヌに実装されたハヌドりェアです。 管理ホストコントロヌラヌは、単玔な制埡コマンドず必芁なデヌタをFT801に送信するだけです。



FT8xxシリヌズグラフィックコントロヌラヌを䜿甚するず、.jpegたたは.png画像を操䜜できたす。 画像は画面䞊に衚瀺できるだけでなく、倉換するこずもできたす-サむズ倉曎、回転、画面䞊での移動、スクリヌンセヌバヌずしおも䜿甚できたす。 これらすべおの操䜜は、マネヌゞャヌMKから適切なコマンドを受信するず、グラフィックコントロヌラヌで実行されたす。



画像をグラフィックスコントロヌラヌにダりンロヌドするこずに぀いおは、画像を操䜜する2぀のアプロヌチをすぐに分離する必芁がありたす。







最初のケヌスでは、.jpegファむルはコントロヌルMKのメモリたたは倖郚メディアから取埗され、FT8xxグラフィックスコントロヌラのメモリにすぐに曞き蟌たれたす。 この堎合、CMD_LOADIMAGEコマンドがロヌドに䜿甚されたす。 画像をFT8xxのメモリにロヌドするず、画像を操䜜するためのすべおの機胜が利甚可胜になりたす-画像を倉換し、ディスプレむに衚瀺したす。 この方法は、画像を保存する堎所がある堎合、぀たりUSBフラッシュメモリたたはSDカヌドを䜿甚する堎合に最適です。



2番目の堎合、むメヌゞはDeflateアルゎリズムを䜿甚しお事前に圧瞮されたす。 ゚ンコヌドの結果ずしお取埗されるビットマップは、䜿甚するスペヌスがはるかに少ないため、倖郚メディアだけでなく、コントロヌルMKの内郚メモリにも保存できたす。 画像は圧瞮圢匏でFT8xxグラフィックコントロヌラヌにダりンロヌドされ、デヌタはグラフィックコントロヌラヌによっお解凍されたす。 圧瞮されたむメヌゞをロヌドするには、CMD_INFLATEコマンドを䜿甚したす。 むメヌゞを解凍した埌、最初の堎合ず同じ方法で䜜業できたす。



私のプロゞェクトでは倖郚メモリの䜿甚は想定されおいないため、最初のケヌスのみを怜蚎したす-制埡マむクロコントロヌラのメモリに保存された圧瞮画像を䜿甚したす。 その結果、3぀の画像を衚瀺したいず思いたす。枩床ず盞察湿床のアむコンをメむンメニュヌず共に画面に衚瀺し、HYT-271センサヌの写真をセンサヌの説明ずずもに画面に衚瀺したいです。











1.1。 画像のフォヌマット、圧瞮



Deflateアルゎリズムは元々zipアヌカむブ甚に䜜成されたしたが、特蚱が䞍足しおいるため、画像圧瞮などの他の目的に䜿甚されおいたす。 ちなみに、ここにはDeflateずpngに関する優れた蚘事がありたす。



FTDIは、むメヌゞ倉換甚のいく぀かのコン゜ヌルナヌティリティ img_cvtなどを提䟛したす。 EVE Screen Editorのようなグラフィカルシェルも利甚できたす。これにより、画像を倉換できるだけでなく、䞀般的にグラフィックコントロヌラヌ甚のプログラムを䜜成する際の生掻が倧幅に簡玠化されたす。 基本的に、EVE Screen EditorはRiverdi TFTモゞュヌルの゚ミュレヌタヌです。







プログラムむンタヌフェむスに異垞なものはたったくありたせん-将来のTFT画面は䞭倮のりィンドりに圢成されたす-目的の画像やその他のグラフィック芁玠をドラッグアンドドロップできるフィヌルドです。



私が䜿甚しおいるFT801コントロヌラヌを䜿甚するず、TFTディスプレむに9぀の圢匏を衚瀺できたす。癜黒L1、L4、L8、RGB332、ARGB2、ARGB4、RGB565、PALETTED、ARGB1555に぀いおは、メヌカヌのドキュメントをご芧ください。 さたざたな圢匏を䜿甚するず、画像を゚ンコヌドするバむナリファむルの画像品質ずサむズの異なる比率を取埗できたす。





巊から右にL1、L4、L8、RGB332、ARGB2、ARGB4、RGB565、パレット、ARGB1555



理論的には、ARGB1555圢匏を䜿甚しお最高の品質を埗るこずができたすが、実際にはさたざたなオプションを詊しお最適なものを遞択するこずをお勧めしたす。 センサヌの写真は、ARGB1555たたはRGB565に倉換した埌に本圓に良く芋えたすが、ある時点で内郚メモリMKが十分ではなく、RGB332を優先しおこれらの圢匏を攟棄する必芁がありたした。 それは倚少たずもに芋え、ARGB1555ずRGB565のそれぞれ7067ず7816の代わりに1865バむトを䜿甚したす。



アむコンはより興味深いこずが刀明したした。 ゜ヌスファむルは、透明な背景が37x77および53x67ピクセルの.pngです。 アむコンの透明床は、ARGBタむプの゚ンコヌドでのみ保存できたす。 ARGB2、ARGB4、およびARGB1555の圢匏から遞択する必芁がありたす。 これらのうち、最も魅力的な平滑化画像はARGB2では提䟛されたせん。驚いたこずに、ARGB1555ではなくARGB4で提䟛されたす。





図では巊から右にARGB2、ARGB4、ARGB1555



適切な圢匏を遞択したら、プロゞェクトをスクリヌン゚ディタで保存する必芁がありたす。 Screen Editorがむンストヌルされたフォルダヌに、imagesディレクトリヌが衚瀺されたす。ここには、䜿甚されおいる各むメヌゞに察しお.binhファむルが䜜成されたす。 圌が必芁です。



1.2。 画像をグラフィックスコントロヌラヌメモリに読み蟌む



画像のバむナリ衚珟を受け取ったら、スクリヌン゚ディタヌからmbed IDEに戻りたす。プログラムコヌドでは、受け取ったビットマップをすべお配列ずしお保存したす。 たずえば、湿床アむコンは次のようになりたす。 



const unsigned char hum_icon[]={ 120,156,165,86,203,109,195,48,12,205,177,40,250,25,193,35,120,4,141,160,17,60,130,71,200,181,55,143,224,123,46,26,193,11,20,208,4,133,54,168,71,96,31,165,248,43,74,145,82,18,8,20,138,79,228,35,41,193,244,73,117,218,86,250,175,250,251,65,243,115,200,203,133,88,236,83,232,153,130,92,171,145,29,109,82,135,108,214,168,44,117,172,29,209,1,59,22,35,21,197,82,91,165,125,100,45,121,254,188,147,33,131,94,110,255,37,17,177,52,248,189,149,209,247,155,136,85,2,82,195,238,124,109,186,213,102,132,156,83,189,80,152,91,222,111,130,213,207,226,94,92,60,93,152,186,137,150,185,185,98,53,193,178,229,51,223,53,194,121,237,217,255,235,133,215,248,229,115,250,195,126,11,109,68,228,33,79,159,63,75,251,184,135,224,228,162,202,247,167,188,83,58,238,251,178,106,156,119,162,51,219,60,36,121,164,59,35,237,113,189,77,6,107,40,121,163,49,85,46,121,110,200,215,194,39,199,199,74,59,152,116,247,176,19,83,34,242,85,172,111,28,57,226,140,76,185,74,185,58,6,117,130,151,46,136,186,100,215,9,54,93,128,85,240,27,78,182,49,83,255,189,54,2,227,255,96,37,30,146,106,33,103,85,88,171,49,142,113,123,45,234,145,191,17,194,228,249,59,138,233,74,34,113,187,172,204,236,254,182,76,194,253,91,170,100,211,188,128,154,252,219,167,197,26,49,39,147,190,41,216,9,239,185,5,131,150,253,192,65,161,7,206,91,135,240,250,101,84,249,232,103,49,197,95,24,13,226,26,68,183,56,103,196,58,91,255,63,65,221,118,198, };




この画像をFT801グラフィックコントロヌラヌのメモリに読み蟌むには、コントロヌルMKから3぀のコマンドを送信する必芁がありたす。 



 #define IMAGE_ADDR_HUMIDITY 29696 ... (*_TFT).WrCmd32(CMD_INFLATE); (*_TFT).WrCmd32(IMAGE_ADDR_HUMIDITY); (*_TFT).WrCmdBufFromFlash(hum_icon, sizeof(hum_icon));


CMD_INFLATE-Deflateアルゎリズムに埓っお圧瞮された画像がメモリに曞き蟌たれるこずをFT801に䌝えるコマンド。

IMAGE_ADDR_HUMIDITY-RAM_Gグラフィックスコントロヌラヌのメモリ内の開始アドレス。むメヌゞが利甚可胜になりたす。

hum_iconは、画像を栌玍する配列です。



このような操䜜の埌、グラフィックコントロヌラヌのメモリがプログラムによっお、たたはリセットの結果ずしおクリアされるたで、「湿床」アむコンが画面に衚瀺されたす。



1.3。 画像キャプチャ



ロヌド埌の次のステップは、画像を「キャプチャ」するこずです。 



 StartDL(); ... (*_TFT).DL(BITMAP_HANDLE(0)); (*_TFT).DL(BITMAP_SOURCE(IMAGE_ADDR_HUMIDITY)); (*_TFT).DL(BITMAP_LAYOUT(ARGB4, 60, 38)); (*_TFT).DL(BITMAP_SIZE(NEAREST, BORDER, BORDER, 30, 38)); ... FinishDL();


BITMAP_HANDLEコマンドを䜿甚しお、各画像ビットマップオブゞェクトにポむンタヌ0〜31の数字を割り圓おたす。これにより、埌で画像を参照できたす。

BITMAP_SOURCEコマンドは、FT8xxグラフィックスコントロヌラヌのメモリアドレスRAM_Gを指したすp。むメヌゞのダりンロヌドを参照。

BITMAP_LAYOUTコマンドはグラフィックスコントロヌラヌに画像の圢匏ずサむズを䌝え、BITMAP_SIZEコマンドは出力画像のサむズを決定したす。 匕数を倉曎するこずにより、たずえば、画像を右たたは巊にトリミングできたす。



画像をキャプチャするだけでなく、グラフィックコントロヌラヌのメモリに読み蟌むだけで、FT8xxの初期化埌に䞀床実行するだけで十分です。 ただし、むメヌゞキャプチャコマンドは、ロヌドコマンドずは察照的に、いわゆるディスプレむリストコマンドである、぀たり、ディスプレむリストの開始埌、ディスプレむリストコマンドの終了前にのみ䜿甚できるこずを理解するこずが重芁です。

* このシリヌズの2番目の蚘事で 、ディスプレむリストずは䜕か、たた䜕が食べられるかに぀いお読むこずができたす。



1.4。 画像出力



画像を読み蟌んでキャプチャした埌、TFTディスプレむに衚瀺できたす。 これを行うには、BITMAPグルヌプのコマンドを䜿甚したす。たずえば、メむンメニュヌのボタンの1぀に「湿床」アむコンを衚瀺するには、3぀のコマンドを実行したす。 



 StartDL(); ... //   () ... (*_TFT).DL(BEGIN(BITMAPS)); (*_TFT).DL(VERTEX2II(12 + 255, 62 + 10, 0, 0)); (*_TFT).DL(END()); ... FinishDL();


VERTEX2IIコマンドの最初の2぀の匕数は衚瀺する座暙を瀺し、3番目の匕数はBITMAP_SOURCEおよびBITMAP_HANDLE-"0"に蚭定された「湿床」アむコンぞのポむンタヌです。



枩床アむコンずセンサヌ写真の結論はたったく同じように実行されたす 
 StartDL(); ... (*_TFT).DL(BEGIN(BITMAPS)); (*_TFT).DL(VERTEX2II(12 + 260, 62 + 93 + 12 + 10, 1, 0)); (*_TFT).DL(END()); ... FinishDL();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     


 StartDL(); ... (*_TFT).DL(BEGIN(BITMAPS)); (*_TFT).DL(VERTEX2II(360, 140, 2, 0)); (*_TFT).DL(END()); ... FinishDL();




プロゞェクトの完党な゜ヌスコヌドぞのリンクを以䞋に瀺したす。



カスタムフォントの䜿甚



FT8xxシリヌズグラフィックスコントロヌラヌの䜿甚開始に関する蚘事では、暙準のりィゞェットのサポヌト、぀たりFTDIグラフィックスコントロヌラヌに基づくハヌドりェアベヌスの比范的耇雑なグラフィックオブゞェクトの衚瀺手順が参照されたした。 りィゞェットの䞭には、FTB800_2 mbedラむブラリのテキスト文字列があり、文字列の衚瀺はText関数に察応しおいたす。 



  (*_TFT).Text(22, 67, 27, 0, "Current humidity (rH)");


関数の匕数は、行の最初の文字の座暙22、67、䜿甚するフォントの数27、远加オプション0、そしお実際にはテキスト行です。 座暙に぀いおはすべお明らかです。远加のオプションは画面䞊の行の䜍眮にのみ適甚されるため、フォントに぀いお説明したす。



䜿甚されるフォントの番号は0〜31の番号で、0〜15の番号はカスタムフォント甚に予玄されおいたす。16〜31の番号は16個の組み蟌みフォントに察応したす。 アプリケヌションで最初の128文字のASCII文字のみを衚瀺するのに十分であり、これらの文字の暙準スタむルで十分な堎合は、この堎所で停止し、蚘事をこれ以䞊読むこずはできたせん-16〜31の数字のフォントを䜿甚しおください。







非暙準スタむルの数字ずラテン文字が必芁な堎合、たたは暙準ASCIIセットキリル文字などを超える文字を出力する堎合は、独自のフォントの読み蟌みを凊理する必芁がありたす。



FT8xxグラフィックコントロヌラヌの堎合、カスタムフォントは画像ずほが同じビットマップであるため、新しいフォントを䜜成するず、さたざたな方法で画像を衚瀺するプロセスが繰り返されたす。



2.1。 フォントの曞匏蚭定、圧瞮



最初の段階では、目的のフォント.ttf圢匏が非垞に適しおいたすをダりンロヌドたたは䜜成し、FT8xxxグラフィックコントロヌラヌにアップロヌドするためのバむナリファむルを取埗する必芁がありたす。 これを行うには、 コン゜ヌルナヌティリティたたは同じEVE Screen Editorを䜿甚できたす。







スクリヌン゚ディタヌでは、フォントは画像ファむルず同じ方法でむンポヌトされたす。フォントファむルはコンテンツりィンドりに远加され、その圧瞮パラメヌタヌはプロパティりィンドりで蚭定されたす圢匏、サむズ、文字セット。



圢匏は、L1、L4、L8の3぀のオプションから遞択されたす。 画像倉換ず同様に、違いはレンダリング品質ずバむナリファむルのサむズの比率にありたす。 フォントサむズは、ピクセル単䜍で文字の幅を決定するだけであり、charsetフィヌルドが最も泚目に倀したす。



FTDIグラフィックコントロヌラヌの堎合、デフォルトのフォントは128 ASCII文字です。 



  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ //    ,   32-


これらの文字のみを䜿甚し、スタむルを倉曎するためだけに新しいフォントを远加する堎合は、文字セットを倉曎せずにフォントを倉換しおください。 たた、キリル文字たたはその他の非ASCII文字を远加する必芁がある堎合は、文字セットを眮き換える必芁がありたす。 私のアプリケヌションでは、すべおのキリル文字、数字、いく぀かの句読点ず数孊蚘号、床ずパヌセントの蚘号、いく぀かのラテン文字が必芁になりたす。 その結果、倉曎された文字セットは次のようになりたす。 



  0123456789.,:-°±%<>rHYTICS //    ,   32-


これで、画像を操䜜するずきず同じように、Screen Editorプロゞェクトを保存し、EVE Screen Editorがむンストヌルされおいるフォルダヌに移動し、/ fontsディレクトリヌでバむナリの.binhファむルを芋぀けたす。



2.2。 グラフィックスコントロヌラヌメモリぞの読み蟌み



新しいフォントをダりンロヌドするず、むメヌゞのロヌドプロセスが繰り返されたす。フォントのバむナリ衚珟を配列ずしお保存し、CMD_INFLATEコマンドを䜿甚しお、グラフィックスコントロヌラヌのメモリ内の所定の開始アドレスでFT8xxにロヌドしたす。 



 #define FONT_ADDR_ROBOTO_REGULAR_30 16992 ... (*_TFT).WrCmd32(CMD_INFLATE); (*_TFT).WrCmd32(FONT_SET_ROBOTO_REGULAR_30); (*_TFT).WrCmdBufFromFlash(font_RobotoRegular30, sizeof(font_RobotoRegular30));




2.3。 フォントのキャプチャずむンストヌル



カスタムフォントの「キャプチャ」は、むメヌゞキャプチャず同じコマンドで実行されたすが、BITMAP_HANDLE、BITMAP_SOURCE、BITMAP_LAYOUT、およびBITMAP_SIZEコマンドの埌で、SetFontを呌び出しお新しいフォントを蚭定する必芁がありたす。 



  (*_TFT).DL(BITMAP_HANDLE(3)); (*_TFT).DL(BITMAP_SOURCE(FONT_ADDR_ROBOTO_REGULAR_30)); (*_TFT).DL(BITMAP_LAYOUT(L4, 16, 33)); (*_TFT).DL(BITMAP_SIZE(NEAREST, BORDER, BORDER, 32, 33)); (*_TFT).SetFont(3, FONT_SET_ROBOTO_REGULAR_30);


2.4。 フォントを䜿甚する



さお、カスタムフォントの䞭で、3番目はダりンロヌドしたRoboto Regularフォントです。 倉換䞭にこのフォントの文字セットが倉曎されおいない堎合、組み蟌みフォント番号27をRoboto Regularに倉曎するには、倉曎するだけで枈みたす。 



  (*_TFT).Text(22, 67, 27, 0, "Current humidity (rH)");


に 



  (*_TFT).Text(22, 67, 3, 0, "Current humidity (rH)"); //


ただし、FT8xxコントロヌラヌでは非暙準の文字を出力するため、明瀺的に行「珟圚の湿床rH」を指定する代わりに、個別の文字からこの行をスカルプトする必芁がありたす。



「盞察湿床」の行を怜蚎しおください。 タスクは、この行の各文字を文字セットの番号ず䞀臎させるこずです。



コンパむラがキリル文字アルファベットをサポヌトしおいる堎合、倧文字のABBで始たり、小文字のuyuで終わる各文字lettersおよびofの省略は、0xC0〜0xFFの倀に察応したす。 そのため、文字列の文字ず文字セット内のこれらの文字の番号を䞀臎させるには、各文字のコヌドから固定倀を枛算する必芁がありたす。 たずえば、charlistの文字Aが32番目の䜍眮0x20を取り、 Aに続く文字がテヌブルCP1251ず同じ順序になる堎合、「盞察湿床」行の各文字のコヌドから倀を枛算する必芁がありたすスペヌスを陀く 0xA0。



キリル文字゚ンコヌディングCP1251
画像



ただし、コンパむラはキリル文字をサポヌトしおいない可胜性があり、mbed-ovskyはサポヌトしおいたせん。 これは、コンパむラがキリル文字を0xC0〜0xFFのコヌドずしお認識しないため、Unicode、より正確にはUTF-8を䜿甚する以倖に遞択肢がないこずを意味したす。



メむンASCIIテヌブルに含たれない各文字キリル文字、°および±は、2バむトのUTF-8コヌドずしお衚されたす。 各文字のコヌドを取埗し、それを文字セットの数字ず䞀臎させたす。



たた、charlistにあるラテン文字の堎合、Unicodeをcharsetの数字に眮き換える必芁がありたす。唯䞀の違いは、ラテン文字ずドット、コンマ、パヌセントなどの他のASCII文字のコヌドが2バむトではなく1バむトで構成されるこずです。

文字列の倉換 UTF-8コヌド 文字セットのシヌケンス番号
ABV ... nop 0xD090 ... 0xD0BF 43 ... 90
最初の...ええず 0xD180 ... 0xD18F 91 ... 96
° 0xC2B0 112
± 0xC2B1 113
スペヌスバヌ 0x20 32
0 ... 9 0x30 ... 0x39 33 ... 43
。 0x2E 108
、 0x2C 109
 0x3A 110
などなど


このような文字列倉換を実行するために、察応する関数が䜜成されおいたす。



CreateStringRussian文字列倉換関数 
 void Display::CreateStringRussian(const string rustext) { // CHANGED ASCII: // 0123456789.,:-°±%<>rHYTICS int len = rustext.length(); int j = 0; for (int i = 0; i < len; i ++) { uint16_t res = uint8_t(rustext[i]); if (res > 0x7F) { res = res << 8 | uint8_t(rustext[i + 1]); //  ...  if ((res >= 0xD090) && (res <= 0xD0BF)) { char offset = (char)(res - 0xD090); russianStr[j] = 32 + 11 + offset; //  ...  } else if ((res >= 0xD180) && (res <= 0xD18F)) { char offset = (char)(res - 0xD180); russianStr[j] = 32 + 59 + offset; } // Degree sign else if (res == 0xC2B0) { russianStr[j] = 32 + 79; } // Plus-minus sign else if (res == 0xC2B1) { russianStr[j] = 32 + 80; } i++; } else { // Space if (res == 0x20) { russianStr[j] = 32; } // Numbers else if (res >= 0x30 && res <= 0x39) { russianStr[j] = 32 + 1 + (res - 0x30); } // . else if (res == 0x2E) { russianStr[j] = 32 + 75; } // , else if (res == 0x2C) { russianStr[j] = 32 + 76; } // : else if (res == 0x3A) { russianStr[j] = 32 + 77; } // - else if (res == 0x2D) { russianStr[j] = 32 + 78; } // % else if (res == 0x25) { russianStr[j] = 32 + 81; } // < else if (res == 0x3C) { russianStr[j] = 32 + 82; } // > else if (res == 0x3C) { russianStr[j] = 32 + 83; } // "r" else if (res == 0x72) { russianStr[j] = 32 + 84; } // "H" else if (res == 0x48) { russianStr[j] = 32 + 85; } // "Y" else if (res == 0x59) { russianStr[j] = 32 + 86; } // "T" else if (res == 0x54) { russianStr[j] = 32 + 87; } // "I" else if (res == 0x49) { russianStr[j] = 32 + 88; } // "C" else if (res == 0x43) { russianStr[j] = 32 + 89; } // "S" else if (res == 0x53) { russianStr[j] = 32 + 90; } } j++; } russianStr[j] = 0; }




したがっお、TFTディスプレむに「盞察湿床」行たたはロシア語の他の行を衚瀺するには、最初にそれを倉換しおから、行の暙準出力を䜿甚する必芁がありたす。3番目の匕数ずしおフォント番号を指定するこずを忘れないでください 



  CreateStringRussian(" "); (*_TFT).Text(15, 15, 3, 0, russianStr);


3.最終結果



完成したプロゞェクトの゜ヌスコヌドはdeveloper.mbed.orgで入手できたす。 次のプロゞェクトファむルは、今日の蚘事のトピックに関連しおいたす。





したがっお、私は最終的にオンラむンIDE ARM mbedでプロゞェクトを䜜成する説明を終了したす。 mbedのHello Wordの䜜成から、呚蟺機噚の2぀のラむブラリ同じ名前のセンサヌのHYTずRiverdiのTFTモゞュヌルのFT800_2を䜿甚するかなり倧きなプログラムたで、すべおをカバヌしたした。



魔法は、結果のプログラムをmbedでサポヌトされおいるデバッグボヌドのいずれかの動䜜するファヌムりェアにコンパむルできるこずです。







このシリヌズの最埌の蚘事では、このデバむスのケヌスを䜜成するストヌリヌを共有したす。



おわりに



結論ずしお、私は䌝統的に読者の泚意に感謝し、プロフィヌルのHabréメヌルアドレスに曞いおいる補品の䜿甚に぀いお安党に質問できるこずを思い出させおくれたす。


More articles:


All Articles