「PIC AVR 工作室」サイトの日記的なブログです。
サイトに挙げなかった他愛ないことを日記的に書き残してます。
PIC AVR 工作室 ブログ



Firefoxのメジャーアップデートが、いつも嵌って
いやなので、先延ばしにしてるんだけど、まぁ、
2台のうち、使用頻度の低い方の1台だけ先にアップ
デートしておこうかなと。

Ubuntuで弄ってみた感じでは、メジャーアップデート
って言うほど変わった感じも無かったし。



というわけで、Windows7の片方だけ29にアップデート
してみた。

…再起動後に、変わった部分を説明するチュートリアル
が出てきた。
まぁ、実感としては、あまり大きく変わった感はない
なぁ。右上の三本線が変わっただけって感じもする。

ファイルメニューを表示させておいて、そっちから操作
することが多いから、三本線とその周辺はあっても
無くてもあまりオイラには気にならない程度の変更って
気もしてきた。


もうちょっとだけ弄ってみてから、いつも使ってる
マシンも更新するかどうか、考えよう。

まぁ、
https://support.mozilla.org/ja/kb/how-to-make-new-firefox-look-like-old-firefox
プラグインで古いUIっぽくするのもあるし、いざと
なれば、そっちも試してみよう。



3Dプリンタで3Dプリンタを作る…的なムービーが
あった。へぇ。RepRapかな。



http://jp.autoblog.com/2014/05/13/your-next-car-could-feature-softwheels-video/
このホイール、賢いな。

車椅子とかだと、これは他の手段では代替しにくい
技術になるかもしれない。自転車とかもヨサゲ。

ただ、クルマとなると、ちょっと状況は変わってくる
だろうな。
バネ下重量がでかくなっちゃって、運動性能に影響が
でたり、ショックは構造上横方向の力に弱いから、
倒して曲がる2輪と違って、4輪では横Gに耐えられない
可能性もある。

それにしても、もう当たり前の選択肢しかないと
思っていたところにも、まだ改善の余地って残って
いるものだなぁ。必要は発明のなんとやらだな。




引き続き、Arduinoのオシロ。ちょっとだけアタマの中の
モヤモヤを整理する。

プローブからの信号を、一旦オペアンプで受け取って、
DCオフセット(+2.5Vする)とか、出力レンジを切り替え
するとか、その辺をナニするオペアンプに、ナニを使えば
いいのか?


微小電圧入力の時には、250倍とか増幅する必要があるので、
オペアンプのオフセットが小さくないといけないんだけど、
一方で、一番最初の入力段の部分では、矩形波が入ってくる
可能性も普通に存在してるので、反転入力/非反転入力の
電圧範囲が大きく開いちゃっても問題ないオペアンプじゃ
ないとまずい仕様。

前者は、せめて1mV以下に抑えておきたい。調整回路を
組み込むとしても、この程度じゃないと、色々と
やばそう。


で、その条件で探すと、反転/非反転の電圧差が1V
くらいまでのオペアンプしか見つからない。しかも
SRが1V/us程度と、結構遅め。

矩形波みたいな急峻な入力が入ってくると、フィード
バックが間に合わなくて、定格におさまらず、異常発振
とか起こしちゃう可能性。
だからといって、ダイオードとかで保護回路組んじゃう
と、入力容量がでかくなり過ぎて、CRフィルタ(LPF)
になっちゃうとか、やばし。



色々考えたんだけど、一番最初の入力段は、反転/非反転
がフルスイングの範囲でokってヤツにしておいて、大増幅
をかける段に低オフセットのを置いて、残った2回路は
それぞれ動作に制約が無いほうに適当に配置しておけば
いいのかな?と。

そんな方向で、一度テストしてみようかな。
想定している4回路のうち、2回路が低オフセット、残りの
2回路は入力の反転/非反転の電圧差に制約が無いやつ。
それなら、最低限のオフセット調整回路で充分動くはず
だろうと。


それでうまく動かなかったら、やっぱり両電源にして、
電圧範囲も±10Vくらいにしておいて、オペアンプの
選択肢を増やした方がいいのかな。

それなら、GND電位もデジタル側とアナログ側で
2.5Vもオフセットさせなくても済むし。

オペアンプ用の両電源、5Vから簡単に作れるICって、
何使うのがいいのかな?NJM2360使うか、それとも
MAX232かな。




コメント ( 0 )




なんとなく気になっていたので、ちょこっとだけ
昨日の続き。オシロモードの表示方法を弄って
みる。


xorで線を連続して引いてみると、始点と終点の部分
が連続するところで二重に重なる部分ができて、点
が消えちゃうはずだから、さらにそこをxorで点を
打てばいいのかな?と思ったら、なんか汚い線に
なっちゃう。

じゃぁってんで、xorの点を打たないとどうなるかな、
と試してみたら、



まぁ、そこそこの感じになったので、とりあえず
こんな感じにしておこう。困ったらあとでまた。



あと、FFTで出力される値のレンジが、想像以上に
ちっちゃいんだけどって気になってたので、FFT
の計算まわりを見直してみる。

http://brown.ap.teacup.com/nekosan0/2241.html
この間読んだロジックからみると、65536段階で入力
して、出力は256段階だったはず。


そういえば、ADCからの入力レンジは0~1023。
FFTの入力レンジは0~65535。64倍の開きがある。

20×log10(64) ≒ 36dbと出る。

なるほど。40db近く出力が下がっちゃうわけだ。
判明。


計算式をちょいっと直して、動かしてみる。



でた。ほぼフルレンジで出てくる。よし。



まぁFFTの方は、入力値、出力値のレンジと、Vrms、
dbVあたりの換算をきっちりと実装しないと、この
表示も全然不正確なんだけど、とりあえずフルレンジ
で波形が表示されるようになったので、単位はともかく、
処理自体は大丈夫っぽい。


あとは、UI回りも含めて、測定レンジの切り替え、
サンプル周期の切り替えまわりの、ソフトとハード
の仕様をどんなかんじにまとめていくかだな。


あと、ふと思いついたんだけど、メモリに余裕が
あれば、ハードコピー機能(ビットマップイメージ
をシリアルで転送)とか、数値データ送信機能
とかも付けたいな。残メモリ次第だな。


メモリがいっぱい余ったら、FFTを64点から128点に
変えたいんだけどな。




ChaNさんのサイトを久々に見に行く。
http://elm-chan.org/docs/avr/avrisp_j.html#lpcon
おぉ。このISP端子の案、面白い。コンスルー
っていうのがあるんだな。

ピンヘッダの厚みもじゃまだから…っていうのが
あるんだけど、ISPの端子って、順番がグチャグチャ
だから、プリント基板で配線作ろうとすると、
1層では綺麗に配線できないんだよな。

そっちも解決されるといいんだけどな。



http://hackaday.com/2014/05/12/a-quadcopter-from-scratch/
Arduino制御のクアッドコプター。ほう。

で、文章を読んでみると、PIDライブラリと。
http://playground.arduino.cc/Code/PIDLibrary

へぇ。playgroundにPIDライブラリなんてあった
のか。
まぁ、あっても不思議じゃないよな。今度じっくり
弄ってみたい。



http://jp.techcrunch.com/2014/05/10/20140509printtopeer-networks-your-3d-printer-so-you-can-build-your-own-bot-farm/
プリンタをネットワークでシェアって、うん、まぁ、
面白いかも。
地下室に、巨大なプリンタがプリントジョブ待ちって、
なんか、いつかどこかでみたような景色だよな。
大昔のお話らしい。




Firefoxが、29にアップデートしろって出てくるん
だけど、まだやりたくないんだよな。モロモロ
宗教上の理由から。
UIが変わるのいやだし、ブラウザで人柱になるの
やだし。

Ubuntu入れてあるノートの方は、アップデートを
適用したら勝手に29が入っちゃって、まぁ、そもそも
UbuntuのUnity自体がまるっきり違うUIだし、Ubuntu
のFirefoxはあまり使ってないから、そんなには
困らないんだけど、Windowsはなぁ…


そもそも、windowsアプリの標準形をむしして、
なんでブラウザばかり変なUIに変わっていって
しまうんだろうな。
クルマでいえば、乗る度にハンドルの場所探したり、
ブレーキの場所探したり、速度表示の単位を調べ
直したり、みたいなのって、どうなのよ?


https://support.mozilla.org/ja/kb/how-to-make-new-firefox-look-like-old-firefox
firefox29のUIを、古いスタイルに戻すプラグイン
っていうのがあるんだけど、これ使っても、すっかり
元通りってわけにはならないはずだからなぁ。



昔、Netscapeの4.73に慣れきってたころに、新しい
スタイルに乗り換えないといけなくなって、ようやく
今のFirefoxではどこで何の操作すればいいか、
アタマで考えなくても使える程度になってきたのに
なぁ。

パッと見のスキンじゃなくて、メニューの深部までの
使い勝手なんだよな。そっちを弄られると、いざ
なにかしようと思って弄ると、メニューの階層を
辿っても辿りなおしても、使いたいメニュー画面が
見つからなかったり…。

Windows7でデバイスマネージャが開きにくいのとかも
同様だな。



コメント ( 0 )




この間の、SPI通信を高速化する関数、
http://brown.ap.teacup.com/nekosan0/2248.html

SSD1306 OLED用の実験プログラムからこの関数を
抜き出して、5110液晶のプログラムにも適用して
みた。


当たり前だけど、表示が一気に高速化できた。

line描画もサックサクに速くなったので、シメシメ
と調子にのって、もうちょっと弄ってみる。
なんとなくオシロっぽい動きをさせてみる。



既に、タイマ割り込み処理も、FFTライブラリも、
高速ADC(単なるアナログ入力じゃなく、高速化した
ADC入力処理)も、メモリ使用量調査のために組込ん
であるので、これを連動させて、サンプリングした
データを画面にプロットしたり、FFT表示させてみる。

と言っても、単位とかはいい加減なまま、とりあえず
画面に収まる範囲にレンジを調整して、それなりに
波形が出てくることを見てみたいな、と。


まず、オシロの入力波形表示イメージ。

こんなんだったり、


こんなんだったり。



単位とかは、固定文言決め打ちなので、現状ではまだ
全くのウソ。単位とかはあとでUIを詰めるときにまた。

サンプリングした値をドットで表示しているだけなので、
振幅が大きくなると、こんな風に点々になっちゃって、
イマイチ分りにくいかなぁ。線で繋ぎたいところ。


次、FFT画面。



こっちは、xorのline表示で繋いでみた。

グラフ領域が横64ドットなのに対し、64点FFTの
実数化(スカラー化)データは32点なので、
1つ飛びだから、うまいこと簡単に表示できた。


オシロの波形表示も線で繋ぐとすると、横64ドット
のところ、64点を線で繋いで描画する必要がある
から、ちょっと厄介かもしれないな。

画面全体を再表示しなくても済むように、わざわざ
xor表示出来るようにしてあるので、オシロ波形
だけpset条件のlineで描くのは、処理負荷的に困る
のだ。



ちなみに、入力波形は、アナログ入力端子を
オープンにしたときに拾ってるノイズ波形
なので、特に意味のあるデータでは無し。

なんとなく、FFTの表示、40dbほど小さく出ちゃう
感じだなぁ。っていうか、半分の長さで表示され
ちゃってる感じ。
例えば、この写真のDC成分は、ほぼフルスケール
(一番上まで)表示されるであろう入力データなの
に、そこまで届いてないんだよな。


FFTの窓関数によるエンベロープの広がりも、
そんなに小さくするほどの影響はないはずだし、
どこか計算式が勘違いしてるんだろうな。

まぁ、以前考えておいた計算式を組み込んでいる
訳じゃないから、あれを組み込んだらそれなりに
動くんじゃないかなぁと。


なんにしても、それっぽく動いているのを眺めると、
なんかちょっとタノシイ。
ちゃんと動くようになったら、専用基板が欲しく
なるよなぁ。




http://p.twipple.jp/rJeTv
話題になってる漫画。

不思議なことに、オイラもこの漫画読むと、なぜか
鼻血が出ちゃうんだよね。不思議不思議。
200回くらい確認してるから、間違えないと思う。

昔はまぁ面白かったんだけど、オイラはオカルトや
迷信には興味がないから、もう永遠に読むことは無い
だろうな。

綿密な取材に基づいて云々って話らしいけど、
取材のノートには、
 「鼻血かくにん!よかった。」
とでもメモってあるのかな。不謹慎だよな。
せめて「この話はフィクションです」って書いておけば
よかったんじゃないのかな。

オイラは元々鼻の内部が弱いからだけど、普通の人
だったら、低線量の被爆したくらいじゃぁ、そんな
症状が出るって、科学的には考えられないけどな。

むしろ、鼻血出るほどの被爆してたら、もっと他の
症状がいっぱい出てるはず。

その程度の線量で云々いうなら、大理石の生産地域
とかでは、もっとたくさんの人が色んな症状に悩ま
されてないとおかしいはずなんだけどな。

まぁ、もう忘れよう。




https://twitter.com/GOLBY_TRINITY/status/464712212607553536
エレベーター。



https://twitter.com/matsumoto0007/status/465510217954779136
またしても武蔵野線。
伊東四朗、小松政夫もびっくりだな。


http://www.aitendo.com/product/7458
そこそこのお値段だけど、aitendoのタッチセンサー
基板。なかなか使い勝手良さそう。



http://cherio199.blog120.fc2.com/blog-entry-8365.html
テルマエ・ロマエの原作!



コメント ( 0 )




久々に、ちょっとデパートに。

探してたブツは見つからず、ちょっとがっかりしつつ
ビックカメラに。オモチャ売り場に久々に行ってみる。

ヤマトのプラモコーナーが相変わらずあるので、ここで
色々眺めてみると、
http://bandai-hobby.net/site/character_yamato2199.html#mecha01

メカコレのサイズのヤマトとゆきかぜが、300円で。

えぇ?昔100円だったじゃん!とか思いつつ、ショー
ウィンドウも眺めてみると、製作例がかざってあった。
観察してみると、ものすごい精緻!!

これは300円ってレベルじゃなくね?もうちょっとしてても
不思議じゃないかもしれん。パルスレーザーとかも細かい。
主砲もものすごくスタイリッシュで精緻。かっちょいい。
オイラの記憶にあるメカコレとは全然違う。
へぇ。

できれば、ガミラス艦の色んなクラスとか、2199でも
ちらっと出てきた白色彗星帝国の艦隊も、この精緻さで
メカコレシリーズとして出してくれたらうれしいところ。

やっぱ、パート2もやって、アンドロメダも作って
欲しいよな。



http://www.huffingtonpost.jp/2014/05/09/rainbow-on-skytree_n_5293683.html?utm_hp_ref=japan
雷様。スカイツリーに。4Kテレビのカメラって、
こういうの撮るときには確かに便利かもしれない。
まぁ、あまり欲しいとは思わないけど。



http://headlines.yahoo.co.jp/hl?a=20140509-00000311-sph-soci
ドラえもん、全米デビュー…って、
http://twitpic.com/8nwa50
こんな感じになるの?



http://nekowan800.blog101.fc2.com/blog-entry-7315.html
おじいちゃん…。
掃除機は動かんねぇ。



コメント ( 0 )




相変わらず、Arduinoでオシロの続きをちょっと。

LCDやOLEDの、SPI通信速度で、表示速度がちょっと
遅いのが気になっているので、最終的に速度アップを
するとしたら、どの程度まで高速化できるのかを
チェックしておくことに。


SPIといっても、LCDもOLEDも4ピンシリアルってやつ
なので、内蔵SPIモジュール使ってるわけじゃなく、
内部ではdigitalWrite()で処理してるので、これが
遅さの元凶だろうと。

んで、直接レジスタを叩いて、信号をオン/オフする
ロジックに。変えるのは、SPI通信用の関数だけ
なので、局所的な修正で済んだ。



で、実行してみた結果を整理してみると、ざっくり、
処理速度が一桁速くなった。

たとえば、



こんな風に、斜めの線で扇形を描いていく処理を
4方向繰り返す処理。修正前は45秒ほど掛かっていた
のが、修正後は約4秒。

10倍くらい速い。この写真の扇表示なら1秒以内。


実際は、描画処理だけじゃなく、線を描く関数内で、
線の傾きの計算とかモロモロしているはずなので、
それを含めると、SPI通信処理周りは、もっと速く
なっているはず。


その他、psetで全画面表示とかも、桁違いに速く
なってる。シメシメ。


やっぱり、digitalWriteの遅さが原因だったんだな。


修正前後の、SPI周りの関数を抜粋。

<<<修正前>>>

void LcdWrite(byte dc, byte data)
{
  digitalWrite(PIN_SC1, LOW);
  digitalWrite(PIN_DC, dc);
  
  shiftOut(PIN_SDIN, PIN_SCLK, MSBFIRST, data);
  digitalWrite(PIN_SC1, HIGH);
}


<<<修正後>>>

void LcdWrite(byte dc, byte data)
{
  PORTD &= ~(1<< PIN_SC1);  // chip select = LOW
  if (dc != LCD_D) {
    PORTD &= ~(1<< PIN_DC);  // data/command LOW(command)
  } else {
    PORTD |= 1<< PIN_DC;  // data/command HIGH(data)
  }
  for (int i = 0; i<8; i++) {
    PORTD &= ~(1<< PIN_SCLK);  // serial clock down
    if ((data & 0x80) == 0x80) {  // pick up MSB
      PORTD |= 1<< PIN_SDIN;  // serial data(HIGH)
    } else {
      PORTD &= ~(1<< PIN_SDIN);  // serial data(LOW)
    }
    PORTD |= 1<< PIN_SCLK;  // serial clock up
    data <<= 1;  // MSB first
  }
  PORTD |= 1<< PIN_SC1;  // chip select HIGH
}


I/Oピン周りの定義は共通で、こんな感じ。
#define PIN_SC1 7 // chip select
#define PIN_SDIN 4 // serial data
#define PIN_SCLK 3 // serial clock
#define PIN_RES 6 // reset
#define PIN_DC 5 // data/command

引き数のdcはデータ/コマンドの選択、dataは
送信するデータ1バイト分。


どちらも、ピン番号はdefineマクロの値を変える
だけで簡単に入れ替えられるんだけど、修正後の
方は、PORTD内だけでしかピンを自由に選択でき
ない。
まぁ、D2~D7の6本から自由に5本を選べるだけ
でも充分かなと。



とりあえず、グラフィック周りの速度は、いざと
なれば充分速い速度に切り替えられるので、必要
になったら…だな。

懸念点は一つ減った。



http://bylines.news.yahoo.co.jp/yamamotoichiro/20140507-00035106/
FreeBSDにも穴か。へぇ。PS4だけじゃなく、
Mac OSのMachも、元を辿ればBSD系だった
ような。



http://www.huistenbosch.co.jp/event/game/
152万平米のゲーセン?



コメント ( 0 )



« 前ページ 次ページ »