大昔、MS-DOS上でCで書いたプログラムを走らせていて遭遇するエラーは大体次の2つだった。
Null Pointer Assignment
Division by Zero (Divided by Zeroだったかも知れない)

 

今はもっぱらLinux上で書いているのだが、何か問題があると
segmentation fault(せぐめんてーしょんふぉると、セグメンテーション違反)
と宣って終わることが多い。というか、ほとんど全部。

 

何かのライブラリを使っていると、比較的丁寧なエラーメッセージを吐いてくれて助かることがある。

このあいだ遭遇したのは double free というものだった。開放したポインタを再度開放していたのですね。

 

PC上のプログラミングであればデバッグはそれ程難しいものではないが、マイコン相手となるとそうもいかない。

ソフトウェアレベルではリストファイルとマップファイルに書かれていることが手がかりの全て、ということも多い。

 

ハードウェアのバグというのもある。まあ、ブレッドボードで遊ぶレベルであれば、この手のバグは設計図に隠れているのがほとんどである。

 

組み込み用途のマイコンは汎用I/Oポートの一部にLEDドライブ能力を持たせているものがある。

これが7,8本あれば外部にエンコーダを用意しなくても7segLEDを繋いで数字や英字を表示することができる。

 

ということで、過去にH8/300Hを使って時計を作ったことがあるのですが、実用性は今ひとつだったのですね。

 

理由は簡単。電気を使いすぎるから。

 

きょうび、紐付のガジェットなんて流行りませんのでバッテリー駆動することになりますが、まあ、エネループでは推して知るべしです。電池交換の都度、時刻合わせしなくてはなりませんので余計使い続ける気が萎えます。

 

消費電力の殆どはLED点灯に費やされるので点灯時間を短くすればよいのですが、デューティ比を小さくすれば暗くなって視認性が下がります。この手の節電策は、周辺光量をみて自動で輝度調整するのが精々です。

 

7segというくらいなのでドライバは最大7ビット分の情報を出力できます。これは数量であれば0から127に相当します。しかし、7segLEDの場合、表示する数字、英字合わせて40文字足らずです。半分にも満たないではありませんか。もっと効率よく使用すべきと思います。

 

次に表示器は4桁用意することがほとんどだと思いますが、ダイナミック駆動する場合、点灯しているのは1桁だけです。1桁しか点灯しないのに4桁用意する、というのは、やはり相当無駄な気がします。

 

これらを踏まえて、以下に実用的な時計を7segLED1桁で実現するためのアイデアを列挙します。

 

  1. バーサライターの要領でLEDを左右にスイングする。
  2. フーコーの振子を用意して、振子の錘としてLEDを用いる。
  3. 日時計を用意し、LEDは影を作る光源として指時針の周りを周回する。
  4. ソーラードライブの腕時計を用意して、光源としてLEDを用いる。
  5. 明滅によりモールス符号を構成する。
  6. 上記のバリエーションで、7つのセグメント各々に時間2桁、分2桁、秒2桁を割当てて同期して明滅させることで、時刻の読み取りにかかる時間を短縮する。
  7. 生活習慣を見直し、規則正しい生活を送ることで必要とする時刻の数を調整する。例えば、6時起床、12時昼食、15時お茶、19時夕食、23時就寝とすれば、必要な表示は6、0(正午)、3(15時即ち午後3時)、7(19時即ち午後7時)、1(23時即ち午後11時)で済む。

 

うーむ、なかなか思い浮かびませんね。こういうのは大体10個前後は出す、というのが相場なんですが。

 

各々について詳しく検討したいと思います。

 

1 利点 視認性が良い。動作している様子は面白いかも知れない。
 問題点 LEDのスイング機構が必要。稼働時の騒音。

 

2 利点 低消費電力(たぶん、無電源で動作可能)
 問題点 設置場所が嵩張る。低緯度地域では振動面の動きが鈍いため時刻の読み取りが困難。

 

3 利点 見た目の面白さ。電源喪失時は屋外に持ち出すことで継続使用可能。
 問題点 設置場所の標準時に同期してLEDを動かす駆動機構の大きさと精度。明るいところでは影が生じにくいこと。

 

4 利点 腕時計の文字盤を流用した視認性の良さ。
 問題点 エネルギー効率。LEDの点灯でどの程度の電力を生じうるのか。

 

5 利点 明滅により実際の点灯時間はごく短い為、低消費電力
 問題点 明滅途中からの読み取りが難しいかも知れない(慣れれば大丈夫か?)

 

6 利点 7segであることを最大限に活用している
 問題点 読み取りには相当の訓練を要するものと想像(慣れれば大丈夫か?)

 

7 利点 健康的な生活
 問題点 あとどのくらいで次の時刻に遷移するか把握しにくいので別途工夫が必要(輝度調整、点滅など)

 

 

どうでしょうか。比較的容易に実現できそうなのは1と3、次点で5、といったところでしょうか。
3の駆動機構ですが、アナログ式の壁時計を水平に設置して、短針の上にLEDを取り付けて、真ん中に指時針を立てれば簡単かも知れませんね。

 

まあ、本命は7なんですが。時間に追われて常に時計を見ていなくてはならない生活というのも御免被りたいですので。

 

 

青空文庫に「紙幣鶴」(斎藤茂吉)というのがアップされた。読んでも何が面白い(印象深い)のかさっぱりだったのでwikipediaを見てみたら、オーストリア・クローネというのはそれ以前のオーストリア・ハンガリー・クローネとは別物で1年しか発行されなかったらしい。本作の初出は1925年とされており、この年は発行されなくなった翌年である。
「一隅の卓によったひとりの娘」が戦後のハイパーインフレに苦しむオーストリアの事情を理解していた、というのがこの話の肝、なのかなあ。であれば冒頭の「この娘の素性などをいろいろ穿鑿せぬほうが賢いとおもう」が落ちるのだけど。

 

底本読め、ってことですか。そうですか。(青空文庫は解説を省略している)

 

 

 

近所の廃品回収業者が予告ビラを配ってきたので不要となったPCを処分することにした。

 

内容はThinkPad2台とEPSONノート1台。EPSONノートはつい先日まで音出しPCとして頑張っていたのだけれど、室内LANへのログインに失敗することが多くなったので思い切って廃棄することにした。

 

一方、未練がましく残したのはWindowsCE機である日立ペルソナHPW-600JC。久しぶりに通電して、動かなければ廃棄しようと思ったのだけれど普通に動作してくれたので。
カレンダーの初期値が1999年なので今から19年前のハードということになる。アプリケーションは一通り揃っているが20年近い歳月の流れは残酷で、いくつかは実用にならない。

ネットワーク関係ではブラウザ(IE3相当)が深刻で表示がしょぼいのは諦めるとしても近年のセキュリティ向上のおかげで認証を突破できなくなってしまった。Yahoo!Japanはエラー、Googleは白紙回答、唯一msnだけは繋がったけれど1画面表示したところでフリーズしてしまった。
なおLANはPCカード(16ビットのみ)のNIC(NE2000互換)が使える。これも最初見当たらなくて部屋中を探さなくてはならなかった。16ビットのNICなんて今や貴重品かも知れない。
ブラウザがダメなのでファイル交換はFTPということになるが、WinCE用のFTPクライアントは思いの外少ない。シェアウェアとフリーを一つづつ見つけたので当然フリーの方を試したのだが動かなかった。何か足りないらしいのだが、それが何なのかが分からない。
最後の手段はLAN内にsambaサーバを立ち上げてWindowsファイル共有を行うことだけれど、動いているハードは全てLinuxであり日頃sshfs等でお気楽お手軽に済ませているので、今更sambaはいまいち気が進まない。

LANカードを探している最中に4GBのCFを見つけたので、ファイル交換は当面これで凌ぐことになりそうである。

 

この他はFAX送受信、ワープロ、表計算、お絵かき、メール、スケジューラ、データベース、ボイスレコーダ、と盛りだくさんだけれど、これといって使うものがない。どれも良く出来ているので勿体無いとは思うのだけれど。
そんな中、ボイスレコーダを弄っていてこれが記録だけでなく再生にも対応しているのに気づいた。当たり前といえば当たり前だが。扱えるフォーマットはpcmのみなので今まで見向きもしてこなかったのだが、うまく使えばミュージックプレイヤーとして使えるのではなかろうか?と思って試してみることにした。
最もハイファイにしても22k,ステレオ,16ビットというショボさで、ハイレゾに慣れた耳で聴くには流石にちょっとどうかと思ったのだが、実際に聞いて確かめるのが一番確実はある。
PC上でffmpegを使って手持ちのflacを変換してみると、数分のトラックであれば概ね20〜30MBに収まるようだ。aacやmp3に比べれば大きいがflacに比べれば大差無い(音質は大差あるが)。
ペルソナにヘッドフォンを繋いで実際に聞いてみるとそんなに悪くない印象である。例えて言うならノイズの少ないカセットテープのような感じである。高音が大きく損なわれいるものの反対に中低域はしっかりしているのでジャンルによっては聴きやすいとも言える。


最後に。やはりプログラムが掛けないと面白くないので、nscriptというCライクなスクリプト言語をダウンロードした。これはソケットが使えたはずである。昔インストールして弄っていた時は、ソケットなんてどうやって使うのだろうと思っていた。既存のネットワークアプリが全滅に近いので、これが正真正銘最後の切り札になるかも知れない。

 

ネット徘徊で見つけたネタから。

 

2017年の集計によれば、TI、アナデバの順。でも、TIの売上99億米ドル・シェア18%に対し、アナデバのそれは43億1千万米ドル・8%と半分にも満たない。

 

まあ、TIの中身はかつてのBBとナショセミが含まれるので当然といえば当然か。

 

 

3位のSkyworksと4位のInfineonは馴染みのない会社なのでちょっと調べたら、前者は無線モデム周りに強みがあって急成長しているとか。後者はドイツ系だけどアメリカの会社を買収してパワー半導体で寡占を目指しているようだ。なる程、馴染みが無いわけですな。

 

以下、5位から順に ST,NXP,Maxim, オンセミ,マイクロチップと続きようやく10位にルネサスが出てくる。これでもインターシルを買収しているのだが。ルネサス独自のアナログICって何かあったかしらん。

 

我らが(?)新日本無線はどの辺なんでしょうね。まあ、会社は大きくなれば良いというものでも無いし、ニッチで細く長く生き残るのもアリでしょう。エンドユーザーの一人としては、秋葉原の店先で買えなくなるのが一番困るので。

 

 

ネットで「はんだこての持ち方」について検索するとヒーター部分を持った画像がヒットするらしい。

 

「何事も経験ですな」(違

 

当該画像をアップしたアホンダラは傷害罪で告発されるべき、と思う。

 

個人的には卓球のラケットと同じで良いと思っている。即ち、ペングリップとシェークハンド。概ねペングリップで間に合うが、シャーシを立てて配線する場合はシェークハンドのほうが良いこともある。

 

シェークハンドの変形(?)で、手首を返した状態(小指がコテ先側、親指が電源コード側)で握る方法もある。この握り方のまま肘をつくとコテ先がほぼ 力点= 支点=作用点 になって熱を伝えやすい、と言われる。しかし、そこまでしなくてはならないなら、コテ先の形状やヒーターのワット数を見なおしたほうが良いだろう。

 

(3/1加筆訂正)

 

USAでは与野党対立の余波で政府機能の一部がストップしたらしい。

 

地元に送信所があるので日頃からAFNを聞いているのだけれど、こんな時は真っ先にサービスが停止するようだ。フィラーとしてクラッシックを何曲か同じ順序で繰り返し流しているだけである。

 

サービス停止といいつつ停波しないのは、緊急時には必要不可欠だから、ということなんだろう。

 

米Microsoftが「ExcelにPython載せたほうがいい?」というアンケートを実施している、とか。要望が多いらしい。

 

まあ、Pythonの普及具合からみれば判らんこともないけど。

 

俺がExcelのVBAでアプリケーション書いたのは2011年が最後なので、今はどうなっているか分からないけれど、VBAで書けなくてPythonなら書ける(書きやすい)というものは無いと思う。
旧バージョンとの互換性やコードのメンテナンスとか、その辺の手間暇を考えると、然程生産性向上に寄与するとは思えない。

 

等というのはデスクトップで使う場合の話である。Pythonはやたらとライブラリ(モジュール)が揃っているから、IoTやらFAやら金融やら何やらからデータ引っ張ってきてExcelで捌く、という案件なら使用言語が統一できて好都合かも知れない。

 

コアなパイソニスタ()はExcelにPython搭載となれば「我が世の春!」とか喜ぶんだろうね。そんなに表計算ソフトでPython使いたかったらGnumericでも使ってろと小一時間。

 

選択肢を増やすのは良いが、併せて安定性低下や価格上昇など始まったら本末転倒である。MSが注力すべきはVBAの「高速化とバグ出し」だと思う。

 

何かを制作(製作)する場合、仕上がりをどうするのか、というのが問題になります。

 

それが写真であれ、ラジオであれ、プログラムであれ、他所から頼まれたもの(有償・無償を問わず)であれば相手方とのやりとりの中で必然的に仕様が決まってくるので、後はそれを目指して(或いはそれに従って)進めていくだけです。

 

しかし、完全自由制作(製作)の場合、この「仕上がりの縛りが無いが故の迷走」というのがしばしば生じるのですね。

 

例えば、総数20枚超に及ぶ超大作な組写真(但し内容があるとは限らない)とか、気がついたら2万行を超えていたPC向けのアプリケーションプログラム(但し実用的であるかは不問)とか、電源が肥大化して不経済極まりないラジオ(但し、)であるとか。

 

一応、最初に「何を作るのか」というのは決めるしそれに向けて大雑把な仕様も組むのですが、細かいところがあやふやなままなので、最終出力がおかしくなってしまう訳です。

 

それでも個人的には、写真であればプリントサイズ、カラーかモノクロか、製作期間及び経済的な事情から「大四切〜四切、7〜8枚程度」という縛りはあります。

プログラムの場合は、ターゲットの実装メモリに左右されるので一概に決まりません。PC使っていてネットも使って良い、とかなると事実上無制限(但し制作者側の気力・体力の続く範囲内で)となってしまいます。

ラジオなんかのハードウェアだと、自分の技術レベルと経済的な事情のみが制約事項となります。

 

で、どうなるかというと、HDD内には作りかけ出来損ないのプログラムが死屍累々、ジャンク箱は試作段階で失敗したプロジェクトの残骸でいっぱい、とかなるわけです。

 

写真だけは意外とまともだったりします。が、こちらは作るだけなら手軽(展示したり評を乞うたりするほうが大変)なので、やっぱり「増殖の一途」ではあります。

 

 

 

さて、ここしばらくラジオ(及び電気ものハードウェア)をやっていますが、上記のような混乱を回避するべく、フォーマットを決めつつあります。

 

フォーマット2017(仮)

  • 電源 DC3.6V 〜 4.8V Eneloop
  • シャーシ YM-130 (W130xH30xD90)

 

筐体をケースではなくシャーシ、としたところがミソで、外装のケース部分で体積を稼いだり、ライザーを使って実装密度を稼ぐなどの工夫の余地を残しています。

 

電源電圧はアナログ回路の場合はもう少し欲しいところですが、デジタルとの親和性や統一性を優先して決めました。低圧で動作するデバイスや回路を工夫しないとなりません。

 

どうでしょうか。最近の製作は概ねこれに沿っているので無理が生じる可能性は少ないと思います。それでも、僅か2項目を縛っただけで途端に敷居が高くなったような気がしますし、その分苦労のしがいがありそうな気もします。

 

 

 

そういえば子供の頃、雑誌「初歩のラジオ」に「カセットケースシリーズ」という連載ものがありました。これは、カセットケースの中に収まる(収める)電子工作の製作記事で、ロジックICを使ったゲーム、ワイヤレスマイク、デジタルテスタ等など、バラエティに富んだ内容でした。また同じく雑誌「子供の科学」には「かまぼこ板の上に平ラグ板を載せたものの上に、文字通りありとあらゆる回路(但し使うトランジスタは数石程度)を構成」した製作記事の連載があり、読者を圧倒していました。考えてみればこれらはみんなフォーマットだった訳です。そうしなければ限られた紙面の上でまとまった記事にはならなかったでしょう。最近は安くて高機能な部品が手軽に使えるようになったせいか、こういう凝った記事は見かけなくなったような気がします。

 

帯域は広いほうが良い。AMラジオ程度の音は合わない。車の中で聴くには厚かましい。ステレオで再生されるとうそ臭い。

 

モノラルスピーカーで少し音量を絞って聴くのが丁度いい。

 


Search

Calendar

S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
<< June 2018 >>

Archive

Mobile

qrcode

Selected Entry

Link

Profile

Search

Other

Powered

無料ブログ作成サービス JUGEM