問題タブ [cmsis]

Atmel SAM3X8E を使用して組み込みシステム プロジェクトに取り組んでいるときに、いくつかの CMSIS ヘッダー ファイルに次のようなコードがあることに気付きました。

C++ の typedef に が含まれないのはなぜconstですか? C++ はランタイム メモリに整数の const 変数を格納しないという言及をどこかで見ました。これが真の場合、constマイクロコントローラ レジスタがメモリ マップされる方法のために削除する必要があることを意味しますが、他にそれを言っているものを見つけることができないようです。 C++ はそれを行います (私の検索は確かにかなり簡単でしたが)。C++ の経験があまりないので、C++ ではconst構造体メンバーが許可されていないのではないかと思いました。これらの typedef は主にレジスターのコレクションの構造体 typedef で使用されるためですが、そうではないようです。

私のシナリオは Arduino Due (ARM ターゲット) へのクロスコンパイルに関するものですが、これは一般的な C の弱いシンボルの問題だと思います。

ファームウェアを 3 つの部分に分けたい: 1. ハードウェア ライブラリ (CMSIS、ミドルウェア) -> libHardware.a 2. リアルタイム OS ライブラリ -> libOS.a 3. アプリケーション コード -> 上記にリンクされている Output.elf

参照されている CMSIS 実装では、次のことが宣言されています。

CMSIS 設計の考え方は、IRQ の一部を選択的に実装および処理するアプリケーション コードを持たせることです。

libHardware.a の nm レポート

私のシナリオでは、これらの IRQ ハンドラーを libOS.a に実装したいと考えています。

void SysTick_Handler(void) を実装し、nm レポート:

次に、それらをリンクします。これは基本的に次のようになります。

(OS は低レベルのハードウェア関数に依存するため、グループ化が必要です。ハードウェアは、OS によって提供される IRQ/main() 関数を呼び出す必要があります)

nm レポート:

まだまだ弱い！libOS.a で定義されているストロング シンボルを使用していると思われます。最後に、SysTick は処理されず、もちろん壊滅的な障害につながります。

一方、libHardware/startup_sam3xa.c で弱いと宣言しなければ、すべて正常に動作します。app/app.c に SysTick_Handler を実装することを選択した場合、それも強くリンクされます。

私の質問は、libHardware.a で定義された弱いハンドラーを libOS.a がどのように実装できるかということです。または、これらのファームウェア開発シナリオでのベスト プラクティスは何でしょうか?

CMSIS バージョン 3 をダウンロードしましたが、使用に問題がありました。主な問題は startup_device.s にあります。このファイルを正しく処理する方法がわかりません。適切なドキュメントが見つかりませんでした。この cmsis バージョンを使用しようとした人はいますか? どうやって進める？タイトルにあるように、NXP LPC1769 を使用しています。

ありがとう

GPDMA コントローラを使用して SSP1 チャネルにアクセスしようとしています。CMSIS ライブラリを使用すると、これは包括的になります。しかし、SSP1 の出力には何も見えません。

最初の例として、1 バイトを送信したいとします。

注釈: (A) サイズを変更しました: 0、1、20、いくつかの値 何も変更されません (B) CMSIS 実装では、常に DMAREQSEL レジスタのビットがリセットされます。を設定する必要があると思うので、この行を追加しました。しかし、結果は変わりません。

LPC_SSP1 レジスタを直接読み書きする SSP ポーリング機能を使用すると、ロジック アナライザで転送を確認できます。しかし、GPDMA を使用すると何も起こりません。アプローチの何が問題になっていますか？

そこに実用的な例はありますか？

CMSISファイルと周辺機器ドライバファイルに書かれているコードの種類。どうすればそれらを区別できますか? どんな例でもより役に立ちます。ありがとうございました。

次のように 2 つのピンを高く設定することが可能GPIO_SetBits(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)です。

オンライン stm32f10 周辺ライブラリ ( here ) は次のように述べています。

このパラメーターは GPIO_Pin_x の任意の組み合わせにすることができ、x は (0..15) にすることができます

しかし、GPIO_SetBits関数内には次のものがあります。

これは、各入力を 1 つのピンとして検査する単純なマクロを指します。

プロジェクトで、次の定義を持つヘッダー ファイルを使用していました。

は__I、別のヘッダー ファイルで次のように使用されます。

私の質問は__I、C++ ではなく C で const になるのはなぜですか? アドレスがあるので CR が指している値を変更することはできますが、の定義__Iが異なる理由は好奇心です。

これが何のために、または何からのものであるかに興味がある人のために、__I定義は IAR Embedded Workbench ARM for Cortex-M4 からのものであり、構造体は Texas Instruments LM4F120H5QR CMSIS ファイルからのものです。

今日、公式の Arch Linux リポジトリから Openocd をインストールし、JTAG アダプターULINK-MEで使用しようとしています。ULINK-ME は CMSIS-DAP デバッグ ファームウェアを使用していることがわかりました。Openocd には CMSIS-DAP ドライバーがあるため、アダプターと通信できるはずですが、以下のコマンドを書いた後、エラーが発生しました。

ULINK-ME を、マイクロコントローラー LPC3141 を統合したボードEA3141に接続しています。これは、構成ファイルをロードする LPC3131 に近いものです。

エラーが発生する理由を知っている人はいますか?

私も別の方法で起動しようとしましたが、やはりエラーが出力されます。今回はちょっと違う。

アップデート：

ULINK-ME の `sudo lsusb -v コマンドの出力は次のとおりです。

「CMSIS-DAP」という文字列がないため、CMSIS-DAP ファームウェアを持たない古い ULINK-ME (2013 年より前に購入) アダプターを使用していると思われます。Keil が私の古い ULINK-ME に CMSIS-DAP をフラッシュする何らかの方法を提供してくれることを願っています。

解決：

Keil に手紙を書いたところ、彼らは ULINK-ME のファームウェアを更新できると主張しましたが、それは事実です。彼らは次の 3 つのリンクを教えてくれました。

1. - シリアル番号を確認する

2. - ポイント 1 で Keil uVision が単独でこれを行っていない場合はアップグレードします。

3. - ULINK-ME をさらに操作

Windows マシンに MDK-ARM v5 をインストールしてから、ツールバーの非常に隠れたアイコン (魔法の杖) をクリックする必要がありました。デバッグの下で、ULINK2/ME オプションを選択すると、ファームウェアが自動的に更新されました。現在、ULINK-ME (古いモデル) に CMSIS-DAP があり、次のコマンドで確認できますsudo lsusb -v。

Wine を使ってこれをやろうとしましたが、できませんでした。少なくとも今は Windows はもう必要ありません。