2013-12

2013-11　FM3　RX62N　SH2A　PIC32MX

１２月†

積み目標

１）PIC32MXを使った単体BASIC(あるいはC言語)コンピューター。
２）シリアルポート接続用（ファームサイズ3kB以内）のPinguinoローダー。

１）はモチベーションの低下。（もうすでに飽きている）

２）は忙しさにかまけて未着手。（とりあえず、NVmemとSerialと割り込みとか全部のモジュールを入れて、メモリー配置も済ませて3kBに収まってるんだけど、肝心のメインルーチン書いてないんだよね。）

↑

Maker Faire Tokyo 2013 バーチャル・ツアー†

Shoebillのページ

http://cc1.cocolog-nifty.com/blog/2013/11/makerfair-tokyo.html

写真満載なんで、行った気になれる。いいね。 （ボタンないけど）

↑

２）†

「２）」って、なんだよ。というのは上を参照。

完全に自分メモ。
テストを書く手順としては、

3kBローダーを、USBブートローダーから起動して、とりあえずmain()関数の先頭で、Lチカだけやらせる。
それをパスしたら、こんどは、serialの初期化をやってからLチカ ＜★★★今ここ★★★
それをパスしたら、main()のループで１文字単位エコーバックをやらせて、teratermから動作確認。
- ついでに１文字受け取るごとにLED反転するように仕掛けておく。
それをパスしたら、Serial受信を割り込みタイプに変えて、割り込み内で１文字受け取るごとにLED反転するように仕掛けておく。
FIFOを仕込んで、最初のエコーバックを割り込みタイプに書き換える。

ここまで出来たら、

最初のハンドシェイクの処理と、データを64byte単位のバイナリーパケットでやりとりするように改造。
そのパケットをUSBブートローダーのFlash消去、書き換えモジュールに繋いで終わり。

↑

PL2303なんてオワコンだよまったく。†

携快電話についてきた電話充電ケーブル兼USB-serialはPL2303が入っている。
後生大事に、このケーブルを改造して（というかSerial側のコネクタを携帯電話からピンヘッダーに変えただけ） RS232(TTL)シリアル変換に使っていた。

今日それを使おうとして、デバイス認識していないことにふと気づく。
そうだ、ＯＳがWinXPからWin8に変わったんだった

ドライバー入れなきゃ。
- Prolificのページにあるインストーラーを入れてはみたものの、デバイス認識しない。
- それもそのはず、VID:PIDがProlificのものじゃないし。（source nextのOEM）
- なので、XPの頃は、inf弄ってVID:PID合わせてた。（XPでは署名の問題ない）

Prolificのページにあるインストーラーでは、単独のinfやsysを取り出せないので、改造できない。
仕方ない。諦めた

おもむろにVMWarePlayerを立ち上げて、WinXPを起動。XP用の改造ドライバーを入れて認識した。

あー面倒。

PL2303がオワコンというよりは、Prolificの純正ドライバーすら使えないVID:PIDを入れられたPL2303がオワコン。

↑

WinXP on Win8:なんか不思議なことになっとる。†

+---------+                                              +-----------+
| WinXP   |                                              | Windows8  |
|         +=USB=+PL2303 USB-Serial+シリアル+[PIC32MX]=USB+           |
| teraterm|                                              | teraterm  |
+---------+                                              +-----------+

一見すると、２台のマシンを使って、互いにUSB-Serialを繋ぎあって、真ん中で実シリアルケーブルのクロス接続をやっている。
互いに、teratermで打った文字が相手の端末画面に出る。

昔やった、シリアル通信のUSB変換挟みバージョンだ。

ちょっとおかしいのが、この２台のマシン、実は物理的には１台２役（WinXPはVMWarePlayer上で動いている）

ちょっと気持ち悪いことが起きている。

それは、teratermで開いている互いのCOMポートが、たまたま、両方とも、COM3: なんだ。　----変だろ？

↑

今日のSerialブートローダー開発状況†

基板はとうの昔に制作済みなんだけど。

serialの初期化をやってからLチカ --- OK.
main()のループで１文字単位エコーバック --- これがウンともスンともいわない何故？
Txだけのテストもだんまりだ。

平行動作のLチカはちゃんと動いている。
何が抜けているんだろう？

↑

原因、少し分かっちゃった。†

ヒントボード選択のミス

/*	----------------------------------------------------------------------------
	SerialPinConfigure : UART I/O pins control
	--------------------------------------------------------------------------*/

void _BOOTROM_ SerialPinConfigure(u8 port)
{
	switch (port)
	{
		case UART1:
#ifdef PIC32_PINGUINO_220
			TRISBbits.TRISB4 = OUTPUT;	// RB4 / U1TX output
			TRISAbits.TRISA4 = INPUT;	// RA4 / U1RX input
#endif			
#if defined(GENERIC32MX250F128)||defined(GENERIC32MX220F032)
			TRISBbits.TRISB2=INPUT;		// RB2 is input ( RX )
			TRISBbits.TRISB3=OUTPUT;	// RB3 is output ( TX )
#endif
			break;

PIC32_PINGUINO_220 にすべきだったのだが、意図的にGENERIC32MX220F032を選んだのが敗因。
TxD,RxDのピンがRB4,RA3になるべきところを
RB2,RB3になるようにしてしまったということ。（GENERIC32MX220F032だとこうなる）

ヤラレター

というか、ちょっと調べりゃ分かることなのに。
調べる気力もだいぶ減ってる感じ。

↑

PIC32MX: UART Serialが動かない真の原因は・・・†

Makefileにあった。

以下のようにCFLAGSの一部を定義していたとする。（あくまで仮の話）

BOARD			=	PIC32_PINGUINO_220
PROC			=	32MX220F032B
DEFINES		=	-D__PIC32MX__ -D__$(PROC)__ -D$(BOARD)

これが、ビルド最終段のリンク時のgcc呼び出し(ELF_FLAGS)でしか使われず、肝心の(CFLAGS)には含まれない(PinguinoのMakefileはそうなっている)ため、
モジュール別コンパイルされるＣソース内に、肝心の '__PIC32MX__'とか'32MX220F032B'が定義されずに、コンパイルされていた。
Pinguinoでは、Ｃソースをmain32.cに全部includeして一発芸リンクするので、ELF_FLAGSに含まれていればそれでおＫ
だけど、手で書いた（モジュール分割した）Ｃソースを分割コンパイルする場合にはCFLAGSに肝心の定義が含まれないというクソバグ

IOsetRemap()とかの関数をio.c使うのやめてmain32.c内にインラインで書くと動くようになる、ということで気づいた次第。

全くもう、ＯＲＺだぜー。

↑

またまた、今日のSerialブートローダー†

UART基板の結線や、動作チェックはUSB-シリアル変換器(SerialEmulator)を作る。のHEXで実行したところ、全く問題無いことが分かった。
LEDブリンクに合わせて、TxDに . (dot) を出力するようにしたところ、正常に動くようになった。
ただし、受信が働いていない。
受信はPinguinoのserial.cによると割り込みで行っている。
Serial1Interrupt()にLEDブリンク（反転）を仕込んでみたが、無反応なようだ。
つまり、割り込みがまったく受け付けられていないモヨリ。

なんでか。どーしてか。

（づつく）

↑

PIC32MX: UART : 割り込むようになった。†

つまらん。
まったくつまらん。

原因はこれだ。

↓
//	SerialIntConfigure(port, INT_PRIORITY_3, INT_SUBPRIORITY_3);

serial.cの中にある、この行は、 INT_PRIORITY_3, INT_SUBPRIORITY_3 未定義だったため、コメントアウトして、そのまま忘れ去られていたのだった。

コメントアウトを戻して、INT_PRIORITY_3, INT_SUBPRIORITY_3 をinterrupt.c から借用してきたら、ちゃんと受信割り込みが動作するようになった。

なんだか、２日くらい潰したような気がする。

なにをやってたかというと、

１）Pinguinoのgccだけの環境(Mchip環境を除外したもの) で最小限のシリアルスケッチを変形したような単体Makefileプロジェクトをコンパイル＆リンクできるようにした。

２）サイズを最適化して、3kB程度に収まるようにした。

３）Pinguinoの「システム側ライブラリのＣソースをmain32.cに全部インクルードして一発芸コンパイル」というのをやめて、システム側ライブラリのＣソースを取り込む形で分割コンパイル＆リンクするように改造していた。

まあ、ここの３）の過程にいろいろ問題があって、ボード（チップ）種別が狂ってピン割り当てが合わなくなったり、とか、最小システムにシュリンクする過程でコンパイルできない部分を一時的にコメントアウトしたまま忘れてたりとか、そんな感じ

繰り返すけど、

ちょっと調べりゃ分かることなのに。
調べる気力もだいぶ減ってる感じ。

まあそんなところ。

↑

AndroVM改めGenyMotionについて†

GooglePlayも使えて、起動も動作も速いVM。

今日のSerialブートローダー†

やっとバグが取れて、普通にモニターとして使えるようになった。
接続ボーレートは115200が上限だった。
230400や460800だと繋がらない。

原因はu1BRGの設定値の誤差。

        5000000
U1BRG = -------- = 21.701
         230400

（実際には -1した値をU1BRGに設定する必要があるが、ここではそれは関係ないので無視する）
除算後切り捨てされて分周比21になってしまう。すると実際のボーレートは

5MHz/21 = 238095

230400との誤差は3%なので通ってもよさそうなんだけど、たぶんPL2303側が逆方向に誤差ってるんだろうなー。

結局21.701を四捨五入して22として設定すれば良いことが分かった。
PinguinoのSerialライブラリはその辺もダメダメっぽい。

↑

RETRO PC:nascom†

Z80マシンで、Microsoft BASICが走るという奴。

なんかまるでTRS-80のプロトタイプみたいなん。
自分もZ80で、こんなん作ってたけど。
ちょっとおいしいのは、MZ-80Kとは違って、*.nasというバイナリーイメージがいっぱいころがっていることか。
エミュレータもいくつかある。

http://www.mikrocontroller.net/topic/314801

PIC32MX版エミュレータのリポジトリはこのへん

https://github.com/antibyte/NasMini.X

z80 emulator は portable z80 emulator を使っている。
NTSC Video出力は、「電子ブロック工房」さんのを使っているし、SD CardファイルシステムはCHaNさんのFAT Fsだ。

MS BASIC? (8kB)

https://github.com/antibyte/NasMini.X/blob/master/Z80/msbasic.h

GALAX (スペースインベーダーみたいなゲーム) 6kB

https://github.com/antibyte/NasMini.X/blob/master/Z80/galax.h

↑

NASCOM NOSTALGIA （茄子置き場）†

http://www.myplace.nu/nascom/nasfiles.htm

フォースとかパスカルも置いてあるじぇじぇ

↑

今日のSerialブートローダー†

Windows側のソースコードを整理して、monitorとbootloaderの２つの実行ファイルを作れるようにしたった。
ブートローダーは、まだ試していない。
ファームウェアはほぼ動いてる。
USB版(8k+3k)に比べれば、UART版(3k)はコード縮めるのに全然苦労しなかった。
実在シリアルポートの場合、ボーレート設定に悩む。
- CP2102(FR60基板流用)から直出しの場合、500kbpsというのがU1BRG分周比の誤差無しで繋がるので良いと思っていたら、
- PL2303経由の長いケーブルだと115200より速いと波形がなまるらしくて、うまく繋がらない。