MOTO+4 Applocations のブログ

HowTo 備忘 アイデア 活動などを書いてます

Galaxy Tab s 10.5 Wifi版をAndroid13相当にSetupする1

投稿日:

リピートユーザさんからご相談があり実施した記録です。Galaxy Tab s 10.5 Wifi版は、2014製、Android6止まりですが、Samsungの高級タブレットシリーズ “S”初代、有機EL、解像度 2560×1600、1.9 GHz4コア、ブロンズメタリックで高級感あり、中古価格も安い。中々Goodな端末です。

OSインストール

SM-T800のカスタム調査を進めると、LinageOS17 (Android10相当) が見つかりますが、この手の掲示板XDAをみるとなんと LinageOS20 (Android13相当) が見つかりました。 10年前の端末が Android13 にできるなんてブルジョアです。

OSインストール手順は、boot loader と リカバリ が別々になっているくらいで、SC-03G と概ね同じです。以下インストール必要物です。

書換用WindowsアプリOdin3ver. 3.14.4
root化イメージCF_AutoRoot_Port_T800_BeansTown106.tar.md5
boot loaderT800XXU1CPK2.tar.md5
カスタムリカバリtwrp-3.7.0_9-0-chagallwifi.img.tar3.4.0-0,-3.6.2_9でもOK。
OSイメージlineage-20.0-20230426-UNOFFICIAL-chagallwifi.zip
制限事項指紋認証は使えない。

以下簡易説明です。細かい部分はSC-03G をみてください。

(1) root化

Volum Down + Home を押しながら電源ボタンONし、odinモード で起動。ボタン配置は以下のように逆になっているので、Volum Down と Volum Up を間違えないよう。

PCで、odinを起動、指定ファイルを読込み、書込みます。

一度起動して root化 を確認。

(2) Boot Loader 書換え

Volum Down + Home を押しながら電源ボタンONし、odinモード で起動。odinで指定ファイルを読込み、書込みます。これを実施しないとOSが起動しません。

(3) カスタム リカバリ 書込み

Volum Down + Home を押しながら電源ボタンONし、odinモード で起動。odinで指定ファイルを読込み、書込みます。

(4) OS 書込み

Volum Up + Home を押しながら電源ボタンONし、リカバリモード で起動。

Android File Host に置いてあった LinageOS17 の最新2024/08/17版を書いてみると失敗です。

LinageOS17 の最新2023/02/18版はOK。

ちょっと釈然としないのでもう少し探索すると LinageOS 20 版(Android13相当) がありました。Githubはこちら、 XDAのスレッドはこちら。びっくりです。書込みは問題なし。

OS起動

LinageOS 20 版で、起動は問題ないです。動作速度も遜色なし。IMEIがデフォルト非表示になっているなど、より新しいOSの利点ですね。

Samsungで気になる指紋認証と、GPSの確認は以下のとおり。

Googe appインストール

LinageOS では Goolgeサービス( 設定アプリのGoogleアカウント)、Google Play は入っていません。カスタムOS用のそれが MindTheGapps です。Android 13用を、カスタムリカバリ:TWRP からインストールしてみると失敗しました。

以上、OS自体はセットアップできましたが、Google Play は使えない状態です。まあ無償アプリで、apk が公開されているものなら使えるので、これで支障はないです。しかしあからさまにインストールできないのは妙です。次の記事で調査と対策をしていきます。

Xperia E1 Dual D2105 をAndroid 6または7.1.2相当にUpdateしてみる2

投稿日:

前記事では各種OSのインストールとウイークポイント調べ、Walkmanアプリの各バージョンの動作を確認しました。今回は本端末の最大の特徴である Walkman Button について調べました。

考察

AndroidのOS構造は全く理解していませんが、 Walkman Button を誰がどのように検出しているかを知る必要があります。考えられるケースとしては、

  1. OSにWalkman Button ドライバ部があり、それが提供するAPIアプリが使用している。正攻法ですが端末メーカ独自のボタンを組込める基本構造なのかギモンです。Samisung Tab Active3 はボタンが7つくらいあるものもあり、どうなってるんでしょう?
  2. Walkman Button にデバイス( /dev/なんとか )が割当てられていて、APIアプリがそれにアクセスし検出している。同じLinux系のラズパイのI/Oポートはこの方式です。
  3. Walkman Button の操作をラッパーする常駐アプリがある。先刻の確認ではLinageOSではカメラボタンに割当てられていました。Android OSは独自のボタンを許容していない可能性もあります。そうすると、この方式しかないということになります。

純正OSコードを見てみる

一枚SIM版のD2005のOSコードは公開されていたので見てみました。(今回端末D2105用はなぜか無い) Eclipceにインポートして、BUTTON や GPIO(入出力ポート) というキーワードで検索すると、ボタン割当てぽいところがあり。しかしWalkmanというものは無し、

つづいてWalkmanというキーワードで検索すると、

以上のことから、考察1 の No.3 の方式の可能性が高そうです。アプリを一生懸命確認しても無意味そうです。

ボタンラッパーアプリ

プレインストールアプリの中のどれかがラッパーアプリか動かして調べるにしても、50コ近くあり、And6 や And7.1.2 で起動しないかもしれません。自分で作る? 既にこの世にあるのでは? Button Mapper というアプリがありました。OSの音楽再生イベントがあり、それとリンクさせるんですね。当アプリで、Walkman Buttonを認識させるとOS上はカメラボタンになっていました。なるほど。

これで問題点は解消、素晴らしいアプリです。少し寂しいですが、音楽再生アプリは、Walkmanアプリ でなくてなんてせもいいってことになります。

残るのは、wma再生、ラジオ、カメラ ですね。

社会保険の賞与不支給申請を行う

投稿日:

売上タイミングでなかなか12月に賞与が出せません。賞与が遅れる場合も賞与支給申請を出せと社会保険事務局から追及されます。その賞与不支給申請手続きの覚え書きです。

e-gov アプリでの手続き名は以下のとおりです。

以下入力例です。

もうひとつの支払い届も提出します。

記入例は以下のとおりです。

追加情報

申請は受理されるものの以下のような指摘がありました。

この 事業者整理記号 は最もよくわからないところです。2桁の都道府県コード、2桁の市町村コード、カタカナの3桁の事業所記号、5桁の事業所番号の組合せが、帳票によってコロコロかわるような印象です。4桁の数値というと社会保険の支払い通知書の事業所コードというものもあります。それかな??? 何分、記入欄にどの項目がどれか記載されていない、入力桁数の厳格なチェックがされていないので、要注意です。

RH850F1KHで自動生成コードをベースでCANドライバーを作る3

投稿日:

前記事では北斗電子さんHSBRH850F1KH176向けにRH850自動コード生成し、RH850/U2A 用のCANドライバサンプルコードをRH850F1KH用に移植し、CAN送信をテストまでできました。今回は受信をテストします。その覚書きです。テスト環境は前記事と同じです。一先ず送信までできていれば、ハード的には送受信OKのはずです。

受信ルール数の設定

受信ルール は旧来のCAN Message Box の CAN ID Mask を包括したものといえます。受信ルール 数は以下のようになっています。

適用受信ルール数
CAN UNIT 一つあたり256
CAN Cahnel 毎任意、0～256

受信ルール のCh毎割当ては r_rh850_can_cfg.c にて以下のように設定します。Channel の group が 2つに分かれ 、リトルエンディアンなので定義の一番下が Ch. 0 になります。分かっていてもついつい上から Ch .0 と思い書いてしまいがち、なかなか気付ずトラップです。Ch毎割当数==0では受信無反応となってしまいます。

can_rx_rule_num_t	g_can_rx_rule_num[ USED_UNIT_NUM ]  = {
// ========================== U n i t 0 設 定 ==========================
	{
		{		// group0 (ココ注意Trap:一番下がch0)
		 	0,	// Ch3
		 	0,	// Ch2
		 	16,	// Ch1
		 	16,	// Ch0
		},
		{		// group1 (ココ注意Trap:一番下がch4)
		 	0,	// Ch7
		 	0,	// Ch6
		 	0,	// Ch5
		 	0,	// Ch4
		},
	},
};

受信ルールの定義

CAN ID 一つづつに受信ルール を割当てれば、 F1KH の176pinなら 256の CAN ID+データ を受信できそうですが、後述する 受信Buffer の制約を受けます。 むろんCAN ID MASK値を絞って一つの受信ルール で複数のCAN IDでを受信してもOKですが、CANデータは素早くRAMに退避する必要があります。

取り急ぎテストでは以下のように、受信ルール が 1つにつき、CAN ID 一つで行うとします。

CAN Ch.CAN ID受信ルール
00x1000
00x1011
10x20016

受信ルール の定義コードは以下の通りです。受信ルール の4つのSFR: ID、MASK、ポインタ0、ポインタ1 詳細はF1KHマニュアルを見ます。MASK値の ID種、Frame種、Node種は 基本1を立てます。32bit 16進数表記では間違い易いため、 弊方では設定マクロを追加しています。

const uint32_t g_rxrule_table[ USED_UNIT_NUM ][ CAN_RX_RULE_NUM ][ 4 ] = {
// ========================== U n i t 0 設 定 ==========================
	{
		// ------------------------ C h 0 設 定 ---------------------------
		{ // [0]
			CAN_RX_RULE_ID(0/*標準ID*/, 0/*DataFrame*/, 0/*他Node*/, 0x100/*ID*/),
			CAN_RX_RULE_MASK(1/*ID種*/, 1/*Frame種*/, 1/*Node種*/, 0x7FF/*ID*/),
			CAN_RX_RULE_PTR0(0x0000/*label*/, 1/*buf使用*/, 0/*buf番号*/, 8/*dlc*/),
			CAN_RX_RULE_PTR1(0x000000/*送受信FIFO*/, 0x00/*受信FIFO*/),
		},
		{ // [0]
			CAN_RX_RULE_ID(0/*標準ID*/, 0/*DataFrame*/, 0/*他Node*/, 0x102/*ID*/),
			CAN_RX_RULE_MASK(1/*ID種*/, 1/*Frame種*/, 1/*Node種*/, 0x7FF/*ID*/),
			CAN_RX_RULE_PTR0(0x0000/*label*/, 1/*buf使用*/, 1/*buf番号*/, 8/*dlc*/),
			CAN_RX_RULE_PTR1(0x000000/*送受信FIFO*/, 0x00/*受信FIFO*/),
		},
・・・ 中略 (定義の欠番はNG) ・・・ 
		// ------------------------ C h 1 設 定 ---------------------------
		{ // [16]
			CAN_RX_RULE_ID(0/*標準ID*/, 0/*DataFrame*/, 0/*他Node*/, 0x200/*ID*/),
			CAN_RX_RULE_MASK(1/*ID種*/, 1/*Frame種*/, 1/*Node種*/, 0x7FF/*ID*/),
			CAN_RX_RULE_PTR0(0x0000/*label*/, 1/*buf使用*/, 16/*buf番号*/, 8/*dlc*/),
			CAN_RX_RULE_PTR1(0x000000/*送受信FIFO*/, 0x00/*受信FIFO*/),
		},
・・・ 中略 (定義の欠番はNG)・・・

受信Buffer番号の定義

RH850では受信内容の取得方法が2つあるようです。今回はその中でシンプルな 受信Buffer による受信でテストします。 受信Buffer 数は以下のとおりです。

適用受信Buffer数
CAN UNIT 一つあたり128
CAN Cahnel 毎任意、0～128

CAN ID に一つづつ受信Buffer を割当てれば、 F1KH の176pinなら 128コの CAN ID+データ を同時期に受信でき、最新のそれぞれのCANデータ内容をSFRに保持でき、最も効率的といえます。むろん受信Buffer を複数のCAN IDで使いまわしてもOKですが、CANデータは素早くRAMに退避する必要があります。

受信Buffer は 送信と異なり CAN Channel の割当てはなく、一つの CAN UNIT 内で自由です。 受信ルール が 1つにつき、受信Buffer を一つ割当てます。上記のコード例では以下のように割当てています。

CAN ID受信ルール受信Buffer
0x10000
0x10111
0x2001616

受信ルールの設定

設定は、API: R_CAN_Init() の中で行われます。CAN通信中には行うべきものではないようです。注意点は各数は以下のようななっています。

適用数
受信ルール255
受信ルールSFRセット16

これは受信ルール のページ番号を 0～15 に切替えながらSFR を使い回す仕組みになっています。弊方では「U2Aとの違い?」と勘違いしてしまいました。 受信ルール の現在設定値もSFR値をウオッチしても分からないんです。 受信ルール は一つづつテストしていくしかなさそうです。

CAN Frame受信

受信Buffer による受信では受信完了割込みは発生しません。 API: R_CAN_ReadRxBuffer() でポーリングチェックします。ただCANドライバのOriginal仕様では 、ポーリング周期内に複数CAN Frame受信するケースには対応していません。弊方ではここは改造しました。その呼出し部は以下のような感じです。

	  uint32_t		last_tm = 0;
	  uint32_t		now_tm = 0;
	  uint8_t 		CAN_RxBufIdx[ CAN_RX_MAX_1MSEC ];	// 受信Buffer Index
    can_frame_t 	CAN_RxBuffer[ CAN_RX_MAX_1MSEC ];	// 受信Frame内容
	
    while ( 1U ) {
    	/// 初期化待ち ///
    	if ( complateInit == FALSE ) {
 ・・・ 中略 ・・・    	
    		}
    	}
    	/// 初期化済み ///
    	else {
    		now_tm = R_Config_TAUB_Get1msTimer();

    		if ( now_tm - last_tm > 0 ) {	// 1ms経過した
    			// 全CHからの受信CHECK
    			retCan = R_CAN_ReadRxBuffer(
   					0                 /*unit*/,
						CAN_RX_MAX_1MSEC,	/* 同時受信Frame max数 */
						CAN_RxBufIdx,		  /* 受信あったBuffer番号*/
						CAN_RxBuffer 		  /* Frame内容*/ );
    		}

テストは BUSMATER から疑似CAN Frame を送信し、e2Studio + E1 でStudioで内部をウオッチして確認します。Ch.0 、Ch.1ともに。

これで RH850F1KH で、自動コード生成とサンプコードを用いて最短(?)で動作検証およびプラットフォーム作成ができました。延べ3week程度でしょうか?

手順とそのポイントは以上ですが、RH850F1KH を直ぐに動かしたい、工数がない、自身がない会社さん等はご相談を受付けています。ある程度の有償でもよろしければこちらまでご一報ください。

RH850F1KHで自動生成コードをベースでCANドライバーを作る2

投稿日:

前記事では北斗電子さんHSBRH850F1KH176をターゲットにRH850自動コード生成をベースとし、RH850/U2A 用のCANドライバサンプルコードを、RH850F1KH用に基本部分を移植しました。次にCAN送信をテストしていきます。今回は企画元がFD未対応なので、CAN2.0のみの使用です。

テスト環境

CAN受信側のハードは、PEAK CAN-USB FDバージョン を用います。代理店さんから購入予定でしたが、ebayで新品放出品があり入手しました。正規ルート以外はコピー品も多いようなので要注意です。ドイツから直接購入は出来ないようです。過去職場でCAN2.0版を導入しましたが、筐体が黒になり安っぽさが消えたように見えます。Kavaer PCeボートも保有していますが、今回、新しく試しています。

配線はpin1とpin4を逆にしないよう注意です。HSBRH850F1KH176 のCANコネクタはpin番号がシルクに書いないようです。JST製なのでpin番がハウジングに書いてあったと思いましたが見当たらず。付属のケーブルは線が細くはんだ付して直ぐ切れそうリスキーです。太い線で作り直した方がよさげです。CANも絶縁になっていないので回路検討としてはCANトランシーバから先は別で組んだ方が良いかも。

CAN受信側のソフトはオープンソースのBUSMATER を用います。CAN DBを定義でき、CANシグナルに分けてサンプリングとログができます。CANLayzer の CAN DB のコンバートも可。しかし数年間、UPDATEがありません。のでCAN-FDには未対応です。過去職場でも紹介し導入し、割と評判が良かったですが、世間的には知名度が低いのでしょうか? (リリース当時ETASさんもアピールしていましたが) にしてもKavaer CAN King ( 全然Kingじゃない )は使い物にならないと思うのですが…

Baudrateの設定

マニュアル 「表 24.125 通信速度の設定例」の表内の「（数値）」が、CANクロックの分周ですが、そのまま設定するとBUSエラーになります。通信速度の計算式をみると、そこから -1 が必要です。CANクロック:fCANが40MHz、1Mbpsの場合、r_rh850_can_cfg.c の設定は以下のようになります。Tq数( 1bitの分解能、通信相手によっては調整要す )は取急ぎ粗目に 8 としています。

const can_ch_cfg_t  g_can_ch_cfg[ USED_UNIT_NUM ][ MAX_CH_NUM_U0 ] = {
// ========================== U n i t 0 設 定 ==========================
{
	// ------------------------ C h 0 設 定 ---------------------------
    {
    ・・・中略・・・
     /* ---- Normal Baudrate ----
       パラメータ( 分周比, SEG1 Bit-Timing, SEG2 Bit-Timing, Jump幅)
  	 */
    	CAN_CFG_N_BAUDRATE(
			// 1Mbps 分周比 = 40Mhz ÷ ( 1MHz × Tq数:8 ) = 5 より-1
   			4U, CAN_NTSEG1_5TQ, CAN_NTSEG2_2TQ, CAN_NSJW_1TQ
		),
    	/* ---- Data Baudrate ---- */
    	CAN_CFG_D_BAUDRATE(
			// 1Mbps 分周比 = 40Mhz ÷ ( 1MHz × Tq数:8 ) = 5 より-1
			// 取急ぎCAN2.0では Normal Baudrate と同じでよい模様。
   			4U, CAN_NTSEG1_5TQ, CAN_NTSEG2_2TQ, CAN_NSJW_1TQ
		),

設定値まとめを以下に示します。なお一般的に乗用車両は500kbps、働く車やレクレーションVehicleは250kbpsですが、レースや車両評価で使う場合は1Mbpsが多いようです。

項目値
通信速度1Mbps
fCAN クロック40Mz
クロック分周5
Tq数8
SEG1 Bit Timing5
SEG2 Bit Timing2
Bitズ レジャンプ幅1

CANクロック::fCANは、設定にもよりますが下図の部分でよいようです。

CAN Frame送信

RH850では送信は3つの方法があります。その中で送信Buffer が一番シンプルな手段です。使用する APIは R_CAN_TransmitByTxBuf (orgは略しすぎなので改名してます) です。送信Buffer 数は以下のようになっています。

項目数
1 Channelあたり送信Buffer数32
1 Unitあたり送信Buffer SFR数255

CAN Channel と 送信Buffer の割当てがイマイチ分かりにくいです。単純に 「 Channel番号 × 36 + CH毎に使うBuffer番号」 でいいようです。OrignalのAPIは 送信Buffer 番号は絶対値なので、ch毎の相対にした方が使いやすいでしよう。以下コードを追加しました。

#define CAN_CH_TO_TX_BUF( ch, num )			( ch * MAX_TX_BUF_OF_CH	+ num )
・・・中略・・・
	// 送信Buffer番号を算出
	txbuf_idx = CAN_CH_TO_TX_BUF( ch_idx, txbuf_idx )

以下呼出しコード例です。基板確認のため、Ch 0、Ch 1両方試します。

	Can_RtnType ret;
	can_frame_t	frame;

	frame.ID	= 0x700;
	frame.DLC	= 8;
	frame.IDE	= 0;	  // 標準frame
	frame.TMFDF = 0;	// CAN2.0
	frame.RTR	= 0;
	frame.DB[ 0 ]	= 0x30;
	frame.DB[ 1 ]	= 0x31;
	frame.DB[ 2 ]	= 0x32;
	frame.DB[ 3 ]	= 0x33;
	frame.DB[ 4 ]	= 0x34;
	frame.DB[ 5 ]	= 0x35;
	frame.DB[ 6 ]	= 0x36;
	frame.DB[ 7 ]	= 0x37;

	ret =  R_CAN_TransmitByTxBuf(	0,	// i : CAN Unit
								  0, 	    // i : CAN Ch番号
									0, 	    // i : 送信Bfffer番号
									&frame	// i : CAN Frame
	);
	
  frame.ID	= 0x701;
	frame.DLC	= 8;
	frame.IDE	= 0;	// 標準frame
	frame.TMFDF = 0;	// CAN2.0
	frame.RTR	= 0;
	frame.DB[ 0 ]	= 0x40;
	frame.DB[ 1 ]	= 0x41;
	frame.DB[ 2 ]	= 0x42;
	frame.DB[ 3 ]	= 0x43;
	frame.DB[ 4 ]	= 0x44;
	frame.DB[ 5 ]	= 0x45;
	frame.DB[ 6 ]	= 0x46;
	frame.DB[ 7 ]	= 0x47;

	ret =  R_CAN_TransmitByTxBuf(	0,	// i : CAN Unit
								 	1, 	    // i : CAN Ch番号
									0, 	    // i : 送信Bfffer番号
									&frame	// i : CAN Frame
	);

BUSMASTERでの受信結果は以下のとおりです。送信できない場合、あまり不確定要素はないため、配線ミスかBaudrate間違いの可能性が高いです。

なお送信前に、送信中かエラー中かの判定もないので追加したほうがいいでしょう。API: R_CAN_CheckTxBufResult でも代用できるかもしれません。

	{
		volatile uint32_t sts;

		sts = RCFDCnCFDCmSTS( ch_idx );
		if ( ( sts & CAN_COM_STS_BIT_ON ) == 0) {   // Ch通信可=不可
			return CAN_RTN_TX_ERROR ;
		}

		if ( ( sts & CAN_BUSOFF_STS_BIT_ON ) != 0) {  // Ch BUS-OFF
			return CAN_RTN_TX_ERROR ;
		}

		if ( ( sts & CAN_TRM_STS_BIT_ON ) != 0) {  	// Ch送信STATUS=送信中
			return CAN_RTN_TX_ERROR ;
		}
	}

送信割込み検出

送信完了割込みは、エラー割込みや送信前のSFRチェックを行えば特に不要です。割込が多発すると、組込みでは貴重な処理能力を食います。今のところは余裕があるため検出しておきました。弊方での実装例は以下のとおりです。実装先は自動コード生成された r_smc_intprg. c です。

/* CAN0 TRANSMIT INTERRUPT */
#if defined (__CCRH__)
#pragma interrupt IntCAN0Tx(enable=false, channel=26, fpu=true, callt=false)
#elif defined (__ghs__)
#pragma ghs interrupt
#elif defined (__ICCRH850__)
#pragma type_attribute=__interrupt
#else
#error Unknown Compiler
#endif
void IntCAN0Tx(void)
{
/* Start user code for IntCAN0Tx. Do not edit comment generated here */
	R_CAN_DispatchEevent( 0 /*unit*/, 0 /* ch.*/, CAN_EVENT_SEND_COMPLATE );
/* End user code. Do not edit comment generated here */
}

弊方では上記の R_CAN_DispatchEevent の中で、登録ずみcallbackを呼んでいます。例がなくとも想像がつくでしょう。r_rh850_can_cfg.c の設定も少し変更します。以下の 0xFFFFU の部分、送信Buffer の32個に対して1bitづつ有効無効を指定します。取急ぎ全部有効にしておきます。

const can_ch_cfg_t  g_can_ch_cfg[ USED_UNIT_NUM ][ MAX_CH_NUM_U0 ] = {
// ========================== U n i t 0 設 定 ==========================
{
	// ------------------------ C h 0 設 定 ---------------------------
    {
 ・・・中略・・・   
        /* ---- Tx/Rx FIFO buffer ---- */
        0x00000000UL,
     	  0x00000000UL,
        0x00000000UL,
        /* ---- Tx queue ---- */
        0x00000000UL,
        /* ---- 送信Buffer割込許可 RCFDCnCFDTMIECm ---- */
        0xFFFFU		// LSBより 1bit 1Buffer で割当て
    }

割込みが発生しない、割込みが発生後、RESETする場合は、割込み設定が正しくできていない可能性が高いです。前記事をよく確認します。

以上で送信まで試せました。受信編へ続きます。

おまけ: デバッグで助かったe2Studioの機能

SFRは多すぎてウオッチするのに時間がかかります。CS+ にもあるかもしりませんが、e2Studioでとても役に立った機能を記録しておきます。

① 選択されたレジスターを使うと、確認したいSFR値だけをまとめておける。

② 上記①の抽出のため、SFR一覧の目視検索に時間がかがる。SFRiodefine.hの定義名なので、マニュアル記載名が検索キーにならないところ、アドレスでも検索できる。