Armadilloフォーラム

アドオンモジュールについて

shiba

2017年8月4日 19時55分

お世話になっております。

Armadillo-IoT-G3にて自作のアドオンモジュールを使いたいですが,どのように設定すれば宜しいでしょうか?

ATDE6にて
linux-3.14-x1-at14/arch/arm/mach-imx/armadillo_iotg_addon/armadillo_iotg_std_addon.c
を添付のように書き換えてコンパイルし、イメージを作成すればいいのでしょうか?
使いたいのは
CON1の40,41ピンのUART1_TXDとUART1_RXDです。

宜しくお願い致します。

ファイル ファイルの説明
armadillo_iotg_std_addon.c
コメント

溝渕です。

> Armadillo-IoT-G3にて自作のアドオンモジュールを使いたいですが,どのように設定すれば宜しいでしょうか?

ダイナミックに自作のアドオンモジュールを検出せずに、スタティックにピン
設定を行うのみであれば、DTSを編集することで行うことができます。

"arch/arm/boot/dts/armadillo_iotg_g3.dts"に直接UART1のノードを追加してみてください。

溝渕様
いつもお世話になっております。
ご回答有り難うございます。

>
> "arch/arm/boot/dts/armadillo_iotg_g3.dts"に直接UART1のノードを追加してみてください。
>

こちらなのですが、ノードの追加方法は
____________________________________________________________________________________________________________________
("arch/arm/boot/dts/armadillo_iotg_g3.dts"より抜粋)

&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hog_1>;

imx7d-sdb {
pinctrl_hog_1: hoggrp-1 {
fsl,pins = <
/* USDHC1 */
MX7D_PAD_GPIO1_IO08__SD1_VSELECT 0x59 /* VSELECT */

/* PDS6-J */
MX7D_PAD_ECSPI1_MOSI__GPIO4_IO17 0x00 /* GPIO_3G_IGT_3.3 */
MX7D_PAD_ECSPI1_MISO__GPIO4_IO18 0x00 /* GPIO_3G_EMERG_OFF_3.3 */

/* USB3503 */
MX7D_PAD_EPDC_DATA13__GPIO2_IO13 0x00 /* GPIO_USB_HUB_RESET_N */
MX7D_PAD_EPDC_DATA14__GPIO2_IO14 0x04 /* GPIO_USB_HUB_INT_N */
MX7D_PAD_EPDC_DATA15__GPIO2_IO15 0x00 /* GPIO_USB_HUB_CON */

/* PDS6-J */
MX7D_PAD_LCD_DATA16__GPIO3_IO21 0x00 /* GPIO_3G_VUSB_IN */

/* MCU */
MX7D_PAD_GPIO1_IO13__GPIO1_IO13 0x40000000 /* MCU_INTB */
>;
};
____________________________________________________________________________________________________________________

/* MCU */
MX7D_PAD_GPIO1_IO13__GPIO1_IO13 0x40000000 /* MCU_INTB */

の下に例として

/*MYad-on*/
MX7D_PAD_ECSPI2_MOSI__UART7_DCE_TX 0x00 /* INTF1_40 */
MX7D_PAD_ECSPI2_SCLK__UART7_DCE_RX 0x70 /* INTF1_41 */

と追記し、makeにてイメージファイルを作成すればよろしいでしょうか?

またDTSを編集する方法で自作アドオンモジュールを使用する場合、TTYデバイスファイルの指定は
従来のアドオンモジュールと同じになるのでしょうか?
例)CON1→/dev/ttymxc0
  CON2→/dev/ttymxc1

以上、よろしくお願いいたします。

溝渕です。

追加が必要なのは、UART1のノード(と、40/41ピンのピン設定)なので、添付の
ようにすると良いと思います。
※ 動作確認していないので注意してください

> またDTSを編集する方法で自作アドオンモジュールを使用する場合、TTYデバイスファイルの指定は
> 従来のアドオンモジュールと同じになるのでしょうか?
> 例)CON1→/dev/ttymxc0
>   CON2→/dev/ttymxc1

同じになります。

デバイスノードのインデックスは、uart coreのインデックスから1を引いた値になります。

uart1の場合は、1-1=0なので、ttymxc0になります。

ファイル ファイルの説明
linux-3.14-x1-at15_add_uart1.patch

溝渕様
いつもお世話になっております。
>
> 追加が必要なのは、UART1のノード(と、40/41ピンのピン設定)なので、添付の
> ようにすると良いと思います。
> ※ 動作確認していないので注意してください

回答が遅れてしまいました。試してみたところ、動作しませんでした。
おそらく他のノードとピン設定が必要と考察しています。

つきまして追加でご教示願います。
linux-3.14-x1-at15_add_uart1.patchにてUART1のノード
(おそらく+&uart1 {からの部分だと認識していますが)は何か参照できるものはあるのでしょうか?
今後もしUART2,3等ほかのノードを追加しなければならないとなった際の書き方を知りたく、お尋ねした所存です。

また今回40/41ピンのピン設定は他のアドオンモジュールで使用されているものを参照にしてしまったのですが、
(40/41ピンのピン設定はaddon_atmark_techno_rs485_x1_intf1.dtsより抜粋しました)
実際今回のlinux-3.14-x1-at15_add_uart1.patchでは書き方が少し違うように見えました。
こちらも何か参照できるのでしょうか?
(マルチプレクス表とも名前の表記等が微妙に違うため)

よろしくお願いいたします。

溝渕です。

> linux-3.14-x1-at15_add_uart1.patchにてUART1のノード
> (おそらく+&uart1 {からの部分だと認識していますが)は何か参照できるものはあるのでしょうか?

ご推測の通り、UART1のノードへの設定は、"&uart1"からの部分です。

DTSでは、"&"が付くと参照になります。uart1の実体は、以下のDTSで定義されています。

arch/arm/boot/dts/imx7d.dtsi

> また今回40/41ピンのピン設定は他のアドオンモジュールで使用されているものを参照にしてしまったのですが、
> (40/41ピンのピン設定はaddon_atmark_techno_rs485_x1_intf1.dtsより抜粋しました)

ご利用中の製品は、"Armadillo-IoT-G3"で合っていますか?

"addon_atmark_techno_rs485_x1_intf1.dts"は、Armadillo-X1用のファイルです。

> 実際今回のlinux-3.14-x1-at15_add_uart1.patchでは書き方が少し違うように見えました。

"arch/arm/boot/dts/"以下にあるのは、通常のDTSです。

"arch/arm/mach-imx/armadillo_iotg_addon/"以下にあるのは、DT Overlay用のDTSです。

そのため、構文が異なります。

> こちらも何か参照できるのでしょうか?
> (マルチプレクス表とも名前の表記等が微妙に違うため)

ピン設定用マクロについては、以下のヘッダで定義されています。

arch/arm/boot/dts/imx7d-pinfunc.h

溝渕様
いつもお世話になっております。

>
> DTSでは、"&"が付くと参照になります。uart1の実体は、以下のDTSで定義されています。
>
> arch/arm/boot/dts/imx7d.dtsi
>
imx7d.dtsiを拝見し、おそらくuart1: serial@30860000 {以降が実態部分になるのでは
と予測はいたしましたが、linux-3.14-x1-at15_add_uart1.patchのように
+&uart1 {以降の書き方はどのように記載したらよろしいのでしょうか?
(すみませんこのあたりの書き方のルールや構文等がいまいちつかめていない所存です)

>
> ご利用中の製品は、"Armadillo-IoT-G3"で合っていますか?
>
> "addon_atmark_techno_rs485_x1_intf1.dts"は、Armadillo-X1用のファイルです。

失礼いたしました。
addon_atmark_techno_rs485_iotg_g3_intf1.dtsでした。
______________________________________
MX7D_PAD_UART1_TX_DATA__UART1_DCE_TX 0x00 /* INTF1_40 */
MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX 0x70 /* INTF1_41 */
______________________________________
上記の他に使いたいピンがあった場合他のG3用モジュールを参照し、
抜粋して利用すればよろしいでしょうか?

> ピン設定用マクロについては、以下のヘッダで定義されています。
>
> arch/arm/boot/dts/imx7d-pinfunc.h
>

ヘッダの定義場所有り難うございます。
早速拝見致しました。見方として、

(linux-3.14-x1-at15_add_uart1.patchより抜粋)
MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX 0x70 /* INTF1_41 */

(arch/arm/boot/dts/imx7d-pinfunc.hより抜粋)
#define MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX 0x0128 0x0398 0x06F4 0x0 0x0

#define以降のMX7D~~の後の0x0128~~と.patchの0x70はどう違うのでしょうか?

よろしくお願いいたします。

溝渕です。

> imx7d.dtsiを拝見し、おそらくuart1: serial@30860000 {以降が実態部分になるのでは
> と予測はいたしましたが、linux-3.14-x1-at15_add_uart1.patchのように
> +&uart1 {以降の書き方はどのように記載したらよろしいのでしょうか?

やりたいことを教えてもらえると、アドバイスしやすいです。

> (すみませんこのあたりの書き方のルールや構文等がいまいちつかめていない所存です)

以下より取得可能な資料は参考になりますか?
http://www.devicetree.org/specifications/

> ______________________________________
> MX7D_PAD_UART1_TX_DATA__UART1_DCE_TX 0x00 /* INTF1_40 */
> MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX 0x70 /* INTF1_41 */
> ______________________________________
> 上記の他に使いたいピンがあった場合他のG3用モジュールを参照し、
> 抜粋して利用すればよろしいでしょうか?

すでにアドオンで利用しているビンについては、ご推測の通りです。

それ以外のピンを利用したい場合は、以下より取得可能なマルチプレクス表を
参照して確認してください。

https://armadillo.atmark-techno.com/armadillo-iot-g3/downloads

> (linux-3.14-x1-at15_add_uart1.patchより抜粋)
> MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX 0x70 /* INTF1_41 */
>
> (arch/arm/boot/dts/imx7d-pinfunc.hより抜粋)
> #define MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX 0x0128 0x0398 0x06F4 0x0 0x0
>
> #define以降のMX7D~~の後の0x0128~~と.patchの0x70はどう違うのでしょうか?

"0x0128~~"はIOMUXC coreのレジスタオフセット等のを示しています。定義
に誤りが無い限りは変更すべきではありません。

"0x70"はpull up/downなどのパッド設定を示しています。

以下のページが参考になるかと思います。
https://users.atmark-techno.com/blog/53/2629

溝渕様
いつもお世話になっております。

> やりたいことを教えてもらえると、アドバイスしやすいです。

うまく伝わらず申し訳ありません。。
やりたいこととして製作したモジュールのピン割り振り表とマルチプレクス表を添付致します。
マルチプレクス表の赤枠でくくっている部分が製作したアドオンモジュールに対応する部分で
使用する機能は青枠でくくられている部分になります。
前回教えて頂いた40、41ピン(UART1_TX_DATA,UART1_RX_DATA)の他にGPIO、UART2、I2C2等を
利用したいと考えています。

>
> 以下より取得可能な資料は参考になりますか?
> http://www.devicetree.org/specifications/
>

確認してみます。有り難うございます!

> "0x0128~~"はIOMUXC coreのレジスタオフセット等のを示しています。定義
> に誤りが無い限りは変更すべきではありません。
>
> "0x70"はpull up/downなどのパッド設定を示しています。
>
> 以下のページが参考になるかと思います。
> https://users.atmark-techno.com/blog/53/2629
>

(以下抜粋)
MX7D_PADで始まる定数の後に指定される「0x4000007f」は、PAD_CTLの設定とsionの設定になります

上記に関しては参考URLを元に調べてみます。有り難うございます!
よろしくお願いいたします。

ファイル ファイルの説明
armadillo-iot-g3_マルチプレクス表、ピン割振表.zip

溝渕です。

> やりたいこととして製作したモジュールのピン割り振り表とマルチプレクス表を添付致します。
> マルチプレクス表の赤枠でくくっている部分が製作したアドオンモジュールに対応する部分で
> 使用する機能は青枠でくくられている部分になります。
> 前回教えて頂いた40、41ピン(UART1_TX_DATA,UART1_RX_DATA)の他にGPIO、UART2、I2C2等を
> 利用したいと考えています。

uart1については、以前添付した"linux-3.14-x1-at15_add_uart1.patch"で、
/dev/ttymxc0が生成できることが確認できました。

やったことは、次の通りです。
1. Linuxカーネルへのパッチ(linux-3.14-x1-at15_add_uart1.patch)の適用
2. Linuxカーネルのビルド(DTBの生成)
3. Armadillo-IoT G3のeMMCの第1パーティションに配置してあるDTBを書き換え

溝渕様
いつもお世話になっております。
>
> uart1については、以前添付した"linux-3.14-x1-at15_add_uart1.patch"で、
> /dev/ttymxc0が生成できることが確認できました。
>
> やったことは、次の通りです。
> 1. Linuxカーネルへのパッチ(linux-3.14-x1-at15_add_uart1.patch)の適用
> 2. Linuxカーネルのビルド(DTBの生成)
> 3. Armadillo-IoT G3のeMMCの第1パーティションに配置してあるDTBを書き換え
>

こちらでもDTB書き換え後、TTYデバイスファイルのttymxc0が生成が確認できました。
マルチプレクス表にてI2C1_SCL, I2C1_SDA, I2C2_SCL, I2C2_SDAをdtsに追加したい場合
> 以下のページが参考になるかと思います。
> https://users.atmark-techno.com/blog/53/2629
>
こちらのマルチプレクス設定例にてピン設定の書き方はつかめたのですが、
例えばI2C4の場合156~304行目に
&i2c4 {
(省略)
&iomuxc {

とあり、ここがI2C4のノードになると思うのですが、
I2C1,I2C2を使いたい場合は追記するのでしょうか?
また追記する場合ノードの書き方をご教示願います。

宜しくお願い致します。

溝渕です。

> I2C1,I2C2を使いたい場合は追記するのでしょうか?

その通りです。

> また追記する場合ノードの書き方をご教示願います。

i2c1の場合はおおむね次のようになると思います。最低限[]で囲ってある値を
設定した方が無難です。すでに存在するi2c4のノードを参考に追加してみてく
ださい。

&i2c1 {
clock-frequency = <[I2Cクロック]>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";

[I2Cスレーブノード]@[I2Cスレーブアドレス] {
compatible = "[I2Cスレーブドライバのcompatibleプロパティ名]";
reg = <[I2Cスレーブアドレス]>;
};
};

上記で参照している"pinctrl_i2c1"も適宜追加する必要があります。

溝渕様
いつもお世話になっております。
>
> i2c1の場合はおおむね次のようになると思います。最低限[]で囲ってある値を
> 設定した方が無難です。すでに存在するi2c4のノードを参考に追加してみてく
> ださい。
>
> &i2c1 {
> clock-frequency = <[I2Cクロック]>;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_i2c1>;
> status = "okay";
>
> [I2Cスレーブノード]@[I2Cスレーブアドレス] {
> compatible = "[I2Cスレーブドライバのcompatibleプロパティ名]";
> reg = <[I2Cスレーブアドレス]>;
> };
> };
>
> 上記で参照している"pinctrl_i2c1"も適宜追加する必要があります。
>

かしこまりました。参考にしながら追加してみます。

あとすみませんやりたい事として簡易ながら回路図を添付致します。
使う場所が7,8,11,12, 9,10,40,41ピンで、UART1,2とGPIOを使用します。
linux-3.14-x1-at15_add_uart1.patchにてUART1,2はこちらを参照にし、dtsへの書き込みを行っていきたいと
思います。
おそらく9ピン、10ピンの設定は
MX7D_PAD_UART3_RX_DATA__GPIO4_IO4 0x00 /* INTF1_9 */
MX7D_PAD_UART3_TX_DATA__GPIO4_IO5 0x00 /* INTF1_10 */
になるのかと予想しています。

GPIOもarmadillo_iotg_g3.dtsにピン、ノードの追加は必要でしょうか?

宜しくお願い致します。

ファイル ファイルの説明
自社アドオンモジュール簡易回路図.pdf

溝渕です。

> おそらく9ピン、10ピンの設定は
> MX7D_PAD_UART3_RX_DATA__GPIO4_IO4 0x00 /* INTF1_9 */
> MX7D_PAD_UART3_TX_DATA__GPIO4_IO5 0x00 /* INTF1_10 */
> になるのかと予想しています。

上記で良いと思います。Armadillo-IoT G3から見ると出力ピンなので、PAD設
定が"0x00"とpull up/downはdisableで問題無いと思います。

> GPIOもarmadillo_iotg_g3.dtsにピン、ノードの追加は必要でしょうか?

GPIOとしてノードの追加は不要です。

ただし、RS-485のTx/Rx enable信号をuartドライバから制御させる場合は、
uartノードにプロパティとして指定する必要があります。

ユーザーランドから制御する場合は不要です。

溝渕様
いつもお世話になっております。

> ただし、RS-485のTx/Rx enable信号をuartドライバから制御させる場合は、
> uartノードにプロパティとして指定する必要があります。
>
> ユーザーランドから制御する場合は不要です。
>

uartノードにプロパティの指定方法をご教示お願いできますでしょうか?

またユーザランドから行う場合はHIGHかLOWを指定して書込み
をすれば良いと認識しておりますが正しいでしょうか?

宜しくお願い致します。

溝渕です。

> uartノードにプロパティの指定方法をご教示お願いできますでしょうか?

製品は異なりますが、Armadillo-IoT G3LのDTSが参考になると思います。

arch/arm/boot/dts/armadillo_x1l.dts:
&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart2_1>;
assigned-clocks = <&clks IMX7D_UART2_ROOT_SRC>, <&clks IMX7D_UART2_ROOT_DIV>;
assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
assigned-clock-rates = <0>, <80000000>;
rs485-rts-active-high;
rs485-enabled-at-boot-time;
fsl,rs485-tx-gate-type = "gpio";
fsl,rs485-tx-gate-gpio = <&gpio3 2 GPIO_ACTIVE_HIGH>;
fsl,rs485-rx-gate-type = "gpio";
fsl,rs485-rx-gate-gpio = <&gpio3 4 GPIO_ACTIVE_HIGH>;
fsl,rs485-rx-gate-active-low;
fsl,rs485-duplex-type = "gpio";
fsl,rs485-duplex-gpio = <&gpio3 5 GPIO_ACTIVE_HIGH>;
fsl,rs485-duplex-active-low;
status = "okay";
};

> またユーザランドから行う場合はHIGHかLOWを指定して書込み
> をすれば良いと認識しておりますが正しいでしょうか?

上記ご認識で合っています。

溝渕様
いつもお世話になっております。

>
> 製品は異なりますが、Armadillo-IoT G3LのDTSが参考になると思います。

これまでのパッチも含めてdtsに記載したものを添付致します。
496行目にGPIOのピン設定を追記し、572行目にUART3のノード、プロパティを追記いたしましたが
こちらで正しいでしょうか。。。?

宜しくお願い致します。

ファイル ファイルの説明
armadillo_iotg_g3.dts

溝渕です。

> 496行目にGPIOのピン設定を追記し、572行目にUART3のノード、プロパティを追記いたしましたが
> こちらで正しいでしょうか。。。?

ビルドできない、期待した動作をしない等の問題はありますか?

質問を質問で返してすみません。

溝渕様
いつもお世話になっております。
回答が遅くなってしまい申し訳ありません。

>
> ビルドできない、期待した動作をしない等の問題はありますか?
>
armadillo_iotg_g3.dtsを追記し、下記コマンドにてdtbファイルとuImageファイルを作成し、
[ATDE6]make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
[ATDE6]make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x80008000 uImage
作成した物をSDカードを用いてArmadilloにコピー。そして

Armadilloにそれぞれ所定のファイルをコピー
[Armadillo]mount -t vfat /dev/mmcblk2p1 /mnt
[Armadillo]cp uImage /mnt/uImage
[Armadillo]cp armadillo_iotg_g3.dtb /mnt/armadillo_iotg_g3.dtb
[Armadillo]umount /mnt

コピーを終えたらrebootをかけて接続テストをしましたが、データは取れませんでした。
[Armadillo] ls /dev/ttymxc0
/dev/ttymxc0
ttymxc0デバイスは生成できるている事が確認できました

以上、よろしくお願いいたします。

溝渕です。

> コピーを終えたらrebootをかけて接続テストをしましたが、データは取れませんでした。

データ受信ができない要因はいくつか考えられます。以下について確認してみてください。
- RX485 Driver/ReceiverのRXイネーブルピンの制御が正常に実行できていない
- UARTのボーレートが対向機器と一致していない
- 対向機器がデータを送信していない

いずれも、オシロスコープ等を利用して確認することができます。

溝渕様
いつもお世話になっております。

> データ受信ができない要因はいくつか考えられます。以下について確認してみてください。
> - RX485 Driver/ReceiverのRXイネーブルピンの制御が正常に実行できていない
下記にて
&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart3>;
assigned-clocks = <&clks IMX7D_UART3_ROOT_SRC>, <&clks IMX7D_UART3_ROOT_DIV>;
assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
assigned-clock-rates = <0>, <80000000>;
rs485-rts-active-high;
rs485-enabled-at-boot-time;
fsl,rs485-tx-gate-type = "gpio";
fsl,rs485-tx-gate-gpio = <&GPIO4_IO4 GPIO_ACTIVE_HIGH>;
fsl,rs485-rx-gate-type = "gpio";
fsl,rs485-rx-gate-gpio = <&GPIO4_IO5 GPIO_ACTIVE_HIGH>;
fsl,rs485-rx-gate-active-low;
status = "okay";
送信側のイネーブルをHIGHにしているはずなのですが、LOWで出てきていました。

> - UARTのボーレートが対向機器と一致していない

Armadilloと計測機器のボーレートを19200bpsで固定してありました。

> - 対向機器がデータを送信していない

Armadilloアドオンモジュール(OP-AGA-RS01-00)にて計測機器のデータを取得は可能でした。

以上、宜しくお願い致します。

溝渕です。

> 送信側のイネーブルをHIGHにしているはずなのですが、LOWで出てきていました。

受信側のイネーブルのことでしょうか。

受信側のイネーブル信号がactive-high(受信許可時にHIGHにする)であれば、
以下のプロパティは削除する必要があります。

> fsl,rs485-rx-gate-active-low;

溝渕様
いつもお世話になっております。

> 受信側のイネーブル信号がactive-high(受信許可時にHIGHにする)であれば、
> 以下のプロパティは削除する必要があります。
>
> > fsl,rs485-rx-gate-active-low;
>

送信側のイネーブルがLOWでした。
受信側のイネーブルはLOWで受信有効の設定にしていた為、
変更前:
fsl,rs485-rx-gate-gpio = <&GPIO4_IO5 GPIO_ACTIVE_HIGH>;
変更後:
fsl,rs485-rx-gate-gpio = <&GPIO4_IO5 GPIO_ACTIVE_LOW>;

に変更いたしました。
以上、よろしくお願いいたします。

溝渕です。

> 送信側のイネーブルがLOWでした。

問題点は「送信できないこと」でしょうか。

それとも半二重で接続しており、送信イネーブルが有効のために受信できない
ということでしょうか。

以下で紹介されているように、問題点を明確にしていただけると、より適切な
アドバイスが短期間でできるかと思います。

[技術系メーリングリストで質問するときのパターン・ランゲージ]
http://www.hyuki.com/writing/techask.html#level

> 受信側のイネーブルはLOWで受信有効の設定にしていた為、
> 変更前:
> fsl,rs485-rx-gate-gpio = <&GPIO4_IO5 GPIO_ACTIVE_HIGH>;
> 変更後:
> fsl,rs485-rx-gate-gpio = <&GPIO4_IO5 GPIO_ACTIVE_LOW>;

同様の修正を、"fsl,rs485-tx-gate-gpio"に対して行うとどうなるでしょうか。

溝渕様
いつもお世話になっております。

何点か実験し、問題点をまとめてみました。

現状、送信イネーブル信号がソフトの制御でhighに出来ず、送信が出来ませんでした。
その為、ハードの設定で強制的にhighにし、送信はできましたが、受信が出来ませんでした。

問題点の切り分けとして
①イネーブル信号の制御
②受信できない原因の考察
と考えます。

①イネーブル信号の制御が出来ていない
■試してみた点
・送信側にhighにする記述を追記→Txイネーブルがhighになりませんでした。
fsl,rs485-tx-gate-type = "gpio";
fsl,rs485-tx-gate-gpio = <&GPIO4_IO4 GPIO_ACTIVE_HIGH>;
+ fsl,rs485-tx-gate-active-high;
fsl,rs485-rx-gate-type = "gpio";

・同様の修正を、"fsl,rs485-tx-gate-gpio"に対して行うとどうなるでしょうか→Txイネーブル信号がhighになりませんでした。
fsl,rs485-tx-gate-type = "gpio";
- fsl,rs485-tx-gate-gpio = <&GPIO4_IO4 GPIO_ACTIVE_HIGH>;
+ fsl,rs485-tx-gate-gpio = <&GPIO4_IO4 GPIO_ACTIVE_LOW>;
fsl,rs485-rx-gate-type = "gpio";

・送信側、受信側のGPIOを入れ替える→Txイネーブル信号がhighになりませんでした。
fsl,rs485-tx-gate-type = "gpio";
- fsl,rs485-tx-gate-gpio = <&GPIO4_IO4 GPIO_ACTIVE_HIGH>;
+ fsl,rs485-tx-gate-gpio = <&GPIO4_IO5 GPIO_ACTIVE_HIGH>;
fsl,rs485-rx-gate-type = "gpio";
- fsl,rs485-rx-gate-gpio = <&GPIO4_IO5 GPIO_ACTIVE_HIGH>;
+ fsl,rs485-rx-gate-gpio = <&GPIO4_IO4 GPIO_ACTIVE_HIGH>;

・送信側、受信側のGPIOを入れ替えた状態で、送信側にhighにする記述を追記→Txイネーブル信号がhighになりませんでした。
fsl,rs485-tx-gate-type = "gpio";
fsl,rs485-tx-gate-gpio = <&GPIO4_IO5 GPIO_ACTIVE_HIGH>;
+ fsl,rs485-tx-gate-active-high;
fsl,rs485-rx-gate-type = "gpio";
fsl,rs485-rx-gate-gpio = <&GPIO4_IO4 GPIO_ACTIVE_HIGH>;

以前Armadillo-Iot-g3Lのソースコードを頂いた内容からG3用に編集してみたのですが、
どこか記述が違うのでしょうか?

②受信できない原因
オシロスコープにて絶縁シリアルアドオンモジュール(OP-AGA-RS01-00)にてデータを取得したものの波形と
開発中のアドオンモジュール(BTCDJ001)にて取得した波形を添付いたします。
絶縁シリアルアドオンモジュールでは水位計からのデータは取得できています。
開発中のものをみると受信データ(水位計送信データ)をイネーブルHIGHの状態で受信している為、
受信データ(水位計送信データ)はきているが、正しく取得出来ていないと思われます。

送信後、HIGH状態をいったん戻し、受信するためにはどうしたら良いのでしょうか?

よろしくお願いいたします。

ファイル ファイルの説明
Armadillo-Iot-G3_RS485通信波形.pdf

溝渕です。

> 現状、送信イネーブル信号がソフトの制御でhighに出来ず、送信が出来ませんでした。
> その為、ハードの設定で強制的にhighにし、送信はできましたが、受信が出来ませんでした。

送信イネーブル信号がソフト制御できていないようです。まずは、DTBを変更
せずにGPIOの動作確認をするのが良いと思います。

以下のマニュアルを参照してGPIOを制御し、オシロスコープで波形を確認して
みてください。GPIO4_IO4のgpio番号は100((4-1)*32+4)です。

https://manual.atmark-techno.com/armadillo-iot-g3/armadillo-iotg-g3_pro…

もしGPIOが正常に動作するにも関わらず、RS485通信を行うことができない場
合は、Armadillo-IoT G3とRS485 Driver/Receiverの接続に問題がある可能性
があります。

> ①イネーブル信号の制御が出来ていない
> ■試してみた点
> ・送信側にhighにする記述を追記→Txイネーブルがhighになりませんでした。
> fsl,rs485-tx-gate-type = "gpio";
> fsl,rs485-tx-gate-gpio = <&GPIO4_IO4 GPIO_ACTIVE_HIGH>;
> + fsl,rs485-tx-gate-active-high;

"fsl,rs485-tx-gate-active-high"というプロパティは存在しません。Txイネー
ブルを論理反転したい場合は、"rs485-rts-active-high"を追加するか、以下
のマニュアルを参照してLinuxカーネル起動オプションの"RTS_ON_SEND"と
"RTS_AFTER_SEND"をそれぞれ反転させてください。

https://manual.atmark-techno.com/armadillo-iot-g3/armadillo-iotg-g3_pro…

> ②受信できない原因
> オシロスコープにて絶縁シリアルアドオンモジュール(OP-AGA-RS01-00)にてデータを取得したものの波形と
> 開発中のアドオンモジュール(BTCDJ001)にて取得した波形を添付いたします。
> 絶縁シリアルアドオンモジュールでは水位計からのデータは取得できています。
> 開発中のものをみると受信データ(水位計送信データ)をイネーブルHIGHの状態で受信している為、
> 受信データ(水位計送信データ)はきているが、正しく取得出来ていないと思われます。

波形を見ると送信波形がHIGH側に引き付けられているので、送信/受信信号が衝突していると思われます。

> 送信後、HIGH状態をいったん戻し、受信するためにはどうしたら良いのでしょうか?

uart driverに適切にTxイネーブルの制御方法を伝えることで、送信時にのTx
イネーブルを有効化するようになります。