PIC専用のスレ Part 59 エラッタの話題も歓迎
＿＿＿＿＿＿
／Microchip .／|
／ ( ﾟ∀ﾟ) ／ | アセンブラのアの字もわからない
|~￣￣￣￣￣| ／. 超初心者からHEXが読めてしまう
|/Ｚ./Ｚ./Ｚ./Ｚ_|／ || 鬼ﾌﾟﾛﾌｪｯｼｮﾅﾙの為のｽｯﾄﾞﾚ（#ﾟДﾟ）だ!ﾓﾞﾙｧ
||. ||. ||. ||
.
大人気のPICマイコンのスレ
なんといっても情報が豊富だし、開発環境も多いし、パッケージも豊富
使いやすくて、しかも安い。やっぱりPICだよね
例の如く基本リンクね
http://www.microchip.com/ マイクロチップ本社(Microchip Technology Inc. )
http://www.microchip.co.jp/ マイクロチップ テクノロジー ジャパン 株式会社
http://www.microchip.com/maps/microcontroller.aspx Microchip Advanced Part Selector (Maps)
またーりやっておくんなまし
種類が多くてワカランって人は上記パーツセレクタで、機能から最適製品を絞り込もう！
教えて君はとりあえずGoogle( (p)http://www.google.co.jp/ ) くらい使おう
テンプレ内の秋月小売価格も在庫が捌ければ、次の仕入れからは昨今の為替相場変動にならって
適宜価格改定されてます。ここの表記価格とは違うかもしれないのでそのつもりで
回答者する人の注意
. 最初に回答したい気持ちは分かるけど、質問者の内容を、落ち着いてよく読もう。
質問者する人の注意
. あなたの周囲しか通じない変な省略語は使わずに、なるべく詳しく説明してね
前スレ：
Part 58 https://rio2016.5ch.net/test/read.cgi/denki/1526808360/
Part 57 http://rio2016.5ch.net/test/read.cgi/denki/1517669525/ I2C_InitializeはMCCのちょっと手を加えて使うけど、他は自作してる。
SSP1ADD を取得したいがために使ってるというべきか。
というか、最近のI2Cはレジスタからがらっと変わってて自分のライブラリが使えなくなって
MCCを改造してもどきで使ってる。
pic18f27q43とか。
いやむしろ、そんなICを使わない方向で行ってる。 物を揃えるのは敷居が高いです
なので、webエミュレータとかないですか？
LEDチカチカさせる程度のプログラムが試せる程度でもいいので >webエミュレータ
それでいいなら(ライターも必要な)PICにこだわることもないのでは。 外部回路のアナログシミュレーションが不要なら標準のシミュレータで十分では？ 乾電池1個でPICを動かすみたいなネタどこだったけ？
最近変態的な回路成分が足りてない >>235
電池１個 1.2V or 1.5Vの電圧で動くように
OFFの時にコンデンサ充電してONにしたときに電池＋コンデンサの電圧で起動して
以降は昇圧回路を制御して(MCUで)電圧を維持する的なやつ？ >>235
電池１個 1.2V or 1.5Vの電圧で動くように
OFFの時にコンデンサ充電してONにしたときに電池＋コンデンサの電圧で起動して
以降は昇圧回路を制御して(MCUで)電圧を維持する的なやつ？ そうそう今検索したら普通に出てきたわ
ttp://gomisai.blog75.fc2.com/blog-entry-495.html
（もっと具体的な検討がどこかにあったような気もするが）
10年前から電圧の特性は大して変わってないけど
あえてLFを別に出さなくなった程度には進歩しているのかな >>238
トランジスタ技術の2021年4月号でAVR特集やってて
その特集で電池1個でマイコンを動かす回路を紹介してた
この件と関係ないが、そのAVR特集の中で明らかな間違を５か所以上見つけた・・・ 読んで見たら2つの記事でネタ被りしてるじゃん
コンデンサの切り替えにDPDTのスイッチ使っているけど
これも地味に高いんよね 最近のデバイスの発振停止電圧ってどんなもんなんだろうね
調べればいいんだけど
内蔵チャージポンプの使用有無とか場合分けが面倒そう 全部は調べられないのでデータシートから推察するに
Vporは1.6Vで
2017年の
PIC16LF153XX(1.8V - 3.6V)のVporrが0.8V
PIC16F153XX (2.3V - 5.5V)のVporrが1.5V
2020年の
PIC16F152XX(1.8V - 5.5V)のVporrが1.1V
2021年の
PIC16F180XX(1.8V - 5.5V)のVporrが1.0V
なので発振停止電圧は以前のLFとFの間くらいといったところか PIC16F15213 @ Fosc=2MHzで実験したところ
約1.6Vで動作開始、約1.2Vで発振停止、動作停止した
（電圧に限って言えば10年前と大差ない）
ADC使用時は約1.3Vで動作停止
内臓チャージポンプの有無による差はなかった（精度は未評価） という訳で起動さえすれば昇圧なしの電池1本1.5V動作は不可能ではない
ただしショットキーダイオードの0.2V分ドロップした
1.3Vだと動かない可能性があるので工夫か諦めが必要
ダイオードの代わりにpMOSをロードスイッチにするとドロップは避けられるが
寄生ダイオードでの逆流が起こるのでちゃんと電圧を監視しないといけないし
どうせスイッチの制御をするなら昇圧チョッパを実装した方が素直かな 1.5Vで動作させて負荷はどうするのかという点については
LEDくらいならチャージポンプ直接駆動でいけるはず
赤色なら余裕 A/Dが止まるのは変換が終わらなくて待機ループで止まるの？
それともプロセッサ自体が止まるの？ MPLAB X IDE Ver6.1.5 ですが、
アプリの動作がとても重いです。調べて見たら目盛8GBのうち、
2.2GBをMPLABが使っています。これはしょうがないと思いますが、
PAKを見ると、AVRとかがいっぱい入っています。AVRとかdsPICとかのPAKをuninstallすると
MPLABの動作が速くならないでしょうか? なんで人に聞く？
自分でやればすべて解決すること
私は、メモリをたくさん積んで解決している。
問題ないからやらない。 PCのハードウェアにもあんまり詳しくなさそうなので
付け加えておきますが、PCは環境が人によって大きく違うので
他人がどうだったから自分もこうだと必ずしも言えないことのほうが
多いのです。だからこそよけいに自分で確かめる必要がある。
あと、メモリを足したら解決するかは、それはそれで問題で、
PICにせっかくアセンブラで勉強できる環境があるんだから
x86(PC)もアセンブラレベルまである程度理解できるようになるといいと思います。
どういう実装になってそうな気がするから、ここがボトルネックだと。
勉強になるし、購入するPCの選択にも困らないと思いますよ。 いやいや、いくらなんでもそれはふっかけすぎ。
相手に少しでも非があるなら、何を言っても良いってわけじゃないです。 たしかにそうかも。
でも、環境依存だから調べないとわからないのは確かだと思う。
勉強はしたほうがいい。
言い過ぎではあるけど。 勉強はしたほうが楽しい、に訂正いたします。
やらされ勉強じゃ楽しくないわね。 言い過ぎも何も、間違ってるじゃん。
Cだから、アセンブラだからという問題ではないと思う。
MPLAB Xの操作性が遅いと言ってるんだから。
あと、メモリを取り替えできないノートPCもたくさんあるんだから、
自分で試せというのも間違い。 速くてメモリ512GBくらい積めるPCにすればいいだけ 何をやってるの？
使わないPACをアンインストールしたらどうなる？と質問してるからやってみれば？と言う話だろ？ お金もかからず、たいして時間もかからず、やってみればわかることは、誰かに質問してないでやってみる。
という姿勢は電子工作をする上で必要なことだと思います。 システムドライブにHDD使っていて、もっさり感な場合はSSDに代えるとか？
MPLABは最近使ってないけどVisual Studioとandroid studioでアプリ開発してるが、IDEが起動する時間はコーヒーが飲めるくらいあったが、SSDにしたら数秒で驚きだよ。きびきびして良いよ。 それはそうとプラグインとしてPICkit3のサポート復活したのかな PICのCコンパイラで教えてください。
__delay_ms(100); とかのdelay関数を使用するのに、
FCLK=...とか#include"libpic...h"を組み込むと覚えましたが、
MCCで構成したときに、FCLKとlibpicを書かなくても良いものもあれば
可必要があるものもあります。
この見分け方はありますでしょうか? 実際に__delay_ms(を置いて
エラーが出るかどうかで判断という方法もあるでしょうけど、もう少し規則性が
あるのかなと思いました。
MCCの追加機能の中にDelay がある場合と無い場合もあって、
こちらもよくわかりません。 いや、まずPICのCコンパイラってどれのことかちゃんと書かないと
で、一般論として、そのファイルで直接APIを呼び出すなら
当該のヘッダファイルをincludeすべき
理由はあなたの書いてあるとおり、他のところでincludeされるか判別できないから
今はincludeしていても将来実装が変わってincludeしなくなるかも知れない すみません、コンパイラはXC16とXC8です。
>そのファイルで直接APIを呼び出すなら当該のヘッダファイルをincludeすべき
ありがとうございます。
今までは、そのまま使える物は何も書かずに、使えない物は使える様になるまで
#includeを追記していました。
知識が浅いのですが、
#include "...h"は、どこでも何回も書いても問題ないのでしょうか。
MCCを使用するとmainの先頭に#include "mcc_generated/system.h"みたいな物が付きます。
そしてさらにMCCで他の機能を追加してジェネレートしたとき、
そのままではコンパイルエラーとなり、
その#include "gccgenerated/system.h"の下に
#include "stdlib.h"とか(追加した機能に寄って異なる)書かなければなりません。
MCCが作成したんだから、それも一緒に追記してくれればいいのに、と思ってしまいます。
この場合も、そこに追記しなければならないのか、書かなくていいのかの
判別をするコツなどはありますでしょうか? >>268です。
連投で申し訳ありません。
PIC18F27Q83で質問があります。以下はデータシートの発振器のページの抜粋です。
https://imgur.com/3fq3vFn.jpg
https://imgur.com/KTwgjHC.jpg
1ページ目の表に出てくる略語の意味が分からないです。
・RSTOSC = Reset OSC 起動時にこのモードで発振するようです。
・NOSC = New OSC 動作中に、ソフトで切り替える時の指定値のようです。
・NDIV = New Divider 同上、分周比のようです。
・FEXTOSC = ? Fって何?
・COSC = ? Cって何?
・CDIV = ? Cって何?
また、以下の違いがわかりません。
1ページ目の下段と2ページ目の上段に書かれた文章です。
1) ECL: External Clock Low Power mode
2) ECM: External Clock Medium Power mode
3) ECH: External Clock High Power mode
4) LP: 32 kHz Low-Gain Crystal mode
5) XT: Medium-Gain Crystal or Ceramic Resonator mode
6) HS: High-Gain Crystal or Ceramic Resonator mode
LP, XT, HSは今までのPICにあったのですが、ECL,ECM,ECHは初めてで戸惑っています。
Low、Medium、Highgって、何のパワーのことを言っているのでしょうか?
どなたかご存じの方がいたら教えてください。
宜しくお願いします。 自己レスです。
COSC, CDIVのCの意味が分かりました。Current(現在値)のようです。
現在発振器がどのモードで動いているかを。
失礼しました。 > ・FEXTOSC = ? Fって何?
普通に考えたらFrequencyでないの
> Low、Medium、Highgって、何のパワーのことを言っているのでしょうか?
外部クロックのパワーは変わるはずないんだから普通に考えたらPICの消費電力のことじゃないの
何か難しく考えすぎというか、名前なんて区別が付けばいいだけのものだから ありがとうございます。
言葉の意味が分かるとMicrochipの糸がわかると思うんです。
>普通に考えたらPICの消費電力のことじゃないの
最初そう思ったんですがlowがあれば事足りるのに3つもあるのがわからないのです。
データシートにそのへんの説明が書かれていないのです。 PICの具体的な質問してくるのって工業高校や大学の課題なの？
会社員でもいいけど周りに聞けないの？ >>272
>最初そう思ったんですがlowがあれば事足りるのに3つもあるのがわからないのです。
>データシートにそのへんの説明が書かれていないのです。
こんなふうに、なぜそういう仕様なのかわからないことを納得するまで聞こうとする人がいるけど
わりと多くの人は
「なぜそういう仕様になっているのか分からないが、そういうものだろう。さあ次の課題にGo!」
として受け入れているんじゃないですかね。
このスレじゃないかもしれないが、前にもMicrochipのA/DコンバータのSPI仕様で、
なぜこういう仕様になっているのかわからない、と書いてた人がいたけど、あれも同じです。
その人はSPI仕様についてこうあるべきじゃないですか、みたいな提案までしてたけど、ここで
提案したって、A/Dコンバータの仕様が変わるわけじゃありませんし。
2つに分かれていれば十分というのも感覚的な主観にすぎないし、自分の主観に合わないから納得できない、
というのは、学習を阻害する原因になります。学習するときに自分の強い主観は、あまりない方がいいです。
探求心は大事ですが、そのときその場で性急に解決しようとせず、疑問は持ち続けるようにすればいいと思います。
>>273
1人で学習する人はいくらでもいると思います。 PICのデータシートの読み方分かってないんでは？
本当にFEXTOSCの定義読んだ？
Register Definitionsを見るんだよ？ >>275
>本当にFEXTOSCの定義読んだ？
>Register Definitionsを見るんだよ？
はい検索して定義は読みましたがFEXTOSCのFについての記述はみつかりませんでした。
わかったのは、外部OSC信号に異常が検出されたときに別の発振器に切り替えて
動作を続けられるようなのですがその関係のようです。
予想するとFはFailのFかなと思いました。
2度に渡って教えてくれてどうもありがとうございました。 ＞CONFIG1
＞FEXTOSC[2:0] External Oscillator Mode Selection
FはEXTOSCと区別するために付けただけじゃないの？
FuseとかFlagとか そもそも周波数Foscは設定しないFOSCは受け入れられたのか あと、FEXTOSCの定義を見ろって話はFの意味じゃなくて
> lowがあれば事足りるのに3つもあるのがわからない
って寝言の方かと >>277
ブロック図Fig12-1は何度も見ていますがEXTOSCはありますがFEXTOSCは見つかりません >>278
>FはEXTOSCと区別するために付けただけじゃないの？
>FuseとかFlagとか
そうだと思いますが、Fは他にもたくさん意味がありますし。 >>279
>そもそも周波数Foscは設定しないFOSCは受け入れられたのか
FrequencyのFだと思います。
>> lowがあれば事足りるのに3つもあるのがわからない
>って寝言の方かと
LowPowerの発振器があれば、他は要らないと思いますけど。
消費電力が周波数毎に変わるから、という理由なら
HF,MF,LFではないかと思います。 >lowがあれば事足りるのに3つもあるのがわからない
むむむ。これはECH、ECM、ECLの話ですね?
ECxの設定は、発振子を使わずに外部クロック源からクロックを供給するときの設定のはずです。
ここからは完全に想像です。
PIC18F27Q83のデータシートを見ると、発振器/発振子から内部ロジックへの配線が、内部発振回路の入力側から引かれています。(古いPICでも)
この通りならば、内部ロジックへの配線で最初に通るバッファは入力としては小さい振幅を扱う、適切なゲインを持ったアンプになっているはずです。
もし、ゆっくりしたスロープのクロックソースに、高パワー(≒高ゲイン)のアンプだと、閾値付近で異常なHLを発生する恐れがあります。
逆に、速いスロープ、高い周波数のクロックソースに、低パワー(≒低ゲイン)のアンプだと、周波数についていきません。
無駄に高いゲインにすると消費電力がもったいない、ということもあるかもしれないですが、上のようなことも考えられると思います。 >>286
ありがとうございます。
>ここからは完全に想像です。
考えていただいてありがたいです。
>内部ロジックへの配線で最初に通るバッファは入力としては小さい振幅を扱う、
>適切なゲインを持ったアンプになっているはずです。
それは想像に難くないと思います。
が、NOTゲートに帰還抵抗を施したアナログ的なアンプということはないでしょうか。
であるなら、小振幅から大振幅まで扱えそうな気がします。
>逆に、速いスロープ、高い周波数のクロックソースに、
>低パワー(≒低ゲイン)のアンプだと、周波数についていきません。
これはその通りだと思います。電流流さないと高い周波数まで動かないですよね。
ありがとうございます。
>>286のお話しを考えてみて、考えが浮かびました(同じく想像ですが)
本来、ECHを1つで小振幅〜大振幅まで賄えますが、とにかく消費電力を落とす方針であれば、
ECM, ECL を作って、少しでも無駄な電気を使わない、ということかもしれないです。
実は気がついたのですが、18F27Q...では、
system clockとperipheral clockを、個別に源振と4倍PLLと選択できるようです。
つまり、32MHz system clockと、8MHz→peropheral clock のようにでき、
これも省電力のためなのかと思いました。(もちろん反対はできません)
UARTを9600で設定したのに2400でしか出ないので、調べて分かりました。
さらにそのブロック図だと、内部発振のときにperipheralにclockが行かないという
面白いことも見つけました。
どうもありがとうございます。 >>286
>無駄に高いゲインにすると消費電力がもったいない
すみません、
すでに指摘されていましたね。失礼しました。 >が、NOTゲートに帰還抵抗を施したアナログ的なアンプということはないでしょうか。
>であるなら、小振幅から大振幅まで扱えそうな気がします。
この場合、そのNOTゲートを構成するFETのドレイン―ソース間の
・ON抵抗値が大きいと、出力の立ち上がり立ち下がりが緩やかになり、周波数応答が遅くなる
・ON抵抗値が小さいと、出力の立ち上がり立ち下がりが急峻になり、周波数応答が速くなる
となるかと思います。
速ければいいというわけではないのは、>>286で推測を書きました。
>さらにそのブロック図だと、内部発振のときにperipheralにclockが行かないという
ペリフェラルにクロックが行かないと動作しないので、さすがにそういうことはないのでは。
それと、PICの場合はペリフェラルによって、個別にクロックソースを選べる(選べないものも)ようになっているので
クロックのブロック図だけでは、どのペリフェラルでどのクロックが使われるのかわかりません。
PIC18F27Q83のデータシートDS40002265Bを見ています。
Figure 12-1. Clock Source Block Diagram
を見ると、「To Peripherals」となっている矢印が、図の上の方に1個、下の方に4個あります。
このほかに、FOSCから得るものもあります。
ペリフェラルによりますが、それらのどれかが使われるのではないですか。 中の人でないと分からんことを想像で議論しても不毛だし
分かったところでデータシートに明記されていることには従うしかない >>288
>「To Peripherals」となっている矢印が、図の上の方に1個、下の方に4個あります。
ありがとうございます。私の見落としですね。 そこまで気になるならいろいろ実験してみればいいのに
中の人じゃないと内部回路までは知りようがないんだから
外からわかる範囲で観測するしかなかろう >想像で議論しても不毛だし
そういう考え方、寂しいな。 やるのはいいけど他所でやってよ
上の長文レスから得られるもの何かある？ ディスレクシアという障害もあるので仕方がありません。
近年ではフォントで読みやすさが改善できる、ということも言われています。
ブラウザのデフォルトフォントを、自分が読みやすいものに変えるといいかもしれませんね。 MCCでUARTの受信割込を設定しましたが、
最初の2文字くらい受信するとPICが固まってしまいます。
MCCの作成したソースでも、
受信割込フラグを自分でクリアしなければならないのでしょうか? >>299
プログラマー向けとされているフォントの場合は、0ODＯや1Il|は区別しやすくなっているのはあるね。
ディスレクシア向けとは方向が違うけれど、用途に合わせてフォントは変えていいと思う。 >>242
どうせ昇圧するならSPDTでいけるんじゃね？
片側のスイッチをダイオードに置き換えるというか
非同期のチャージポンプを単純に手動にしたイメージ
Vf分ドロップするが2Vは確保できる
待機電力は知らね unsigned char c → 0〜255
signed char c → -128〜+127
char c の場合は、0x7fより大きい文字コードが記憶できますか?
文字に負の数は無いのでunsigned char で使ってきましたが、
strcpyとかを使いたいときは、charで宣言しなさいとあるのがよくわからないです
この辺を説明してある本(webページではなく)がありましたら教えていただけないでしょうか。
char に3種類あるならintでも3種類あるのかも知りたいです。 char, unsigned char, signed charは全部違う形
charが符号付きか無しかは環境や設定依存
intはsigned int, unsigned intの2種類だけ
intとsigned intは同じ型 XC8はcharは符号無し
XC16, XC32は符号付きが標準
設定で変更可能
符号無しは0〜255
符号付きは-128〜127 文字と数値は本来別物
符号付きとか気にする時点で既に危険な領域に足を踏み入れている
8bitの数値にはint8_tやuint8_tを使って
charは文字用（数値じゃない）と考えるのがイマドキの基本では シリアル通信のバッファは8ビットで考えたい。
文字列関数はcharで扱いたい。
そんなジレンマを抱えているのでは。
パソコンアプリの場合だと、通信そのものは8ビット単位なのに、
文字列の内部表現は基本が16ビットということもあるけれど、
マイコンだと通信単位も文字列も8ビットであることが多いと思う。 だから文字を数値（整数）と思わなければ
そんなジレンマ存在しないよね、と
シリアル通信のバッファは8ビットで考えたい。
数学関数はfloatで扱いたい。
そこに何のジレンマもないように ありがとうございます。
strcpyとかの文字列関数を記述したら、warningだかerrorになってしまい、
それて゜質問しました。
char, unsigtned char, signed charが全部別物とは、参りました。
自分自身の取り決めみたいですね。
LCD表示器とか、2ch目のprintfのようなところで、XC8でstring関数が使いたいだけなのですが、
unsigned char count = 0;
signed char temp = -20;
char moji[11] = "PIC18F1234" と、このように決めてやっさて行きたいと思います。
printf( #1, "Hello" );
printf( #2, "GoodBy" ); のように、出力先が決められるコンパイラだといいのですか。 ジレンマを抱えてはいけない、という結論に導かねばならないってことはないしね。
charをfloatで譬えるのはかまわないが、たとえはたとえでしかない。
ANK文字だけを扱う環境下なら、実質的に「通信で使うバッファ内のデータ列」≒「文字列」ということもあるだろう。
必要に応じてキャストするだけでもいいのでは。 いや、キャストするななんて言ってないし
floatだってキャストするだろ？
文字列の場合だけ「キャストする『だけ』」みたいな
特別視をする必要がないと言っている
間違った解釈をしているから訂正したのであって
主義主張の正しさについて議論する気はない たとえば、シリアル通信で送られてきた文字データ列を、内部の文字列を前提としたポインタにキャストして成立するのって、
ANK文字をはじめとして、シリアル通信で扱う文字と、内部の文字の文字コードが同じであるという特殊な場合に限られています。
そのばあいだけに使えるので、部分集合なケースであると思います。
floatのバッファのポインタに、整数として意味を持つ整数配列のポインタをキャストするのはしたことがありません。 floatの例は整数からの変換じゃないのでは？
floatが整数でないようにcharも整数ではないと思え
ってのが>>310の話なので。 string系の関数を使うという文脈なのでバッファのポインタの話だと認識していました。
その上で「floatだってキャストするだろ？」とあるように「する」と書かれているので、そうなのか、と思った次第です。
floatのキャストの話はポインタの話からは外れています、ということでしたらそれでいいです。
短文メッセージのやりとりなので、文脈の解釈が明示的に行われないことはやむをえません。
値の話になりますが、文字取得の関数では、戻り値は文字ですが、int型の場合があります。
その場合は、int型変数で受けて、あとからchar型変数に代入することになります。
わりかし機械に近い部分のプログラムができるC言語だし、整数と文字は意識して行き来するのではないかと思います。 センサの時系列データとかfloatだってC++でいうところのreinterpret_cast使うよ
そして使える条件があるのもANK文字と何ら変わらない
自分がやったことないからといって想像で書かれてないことを捏造するのは良くない 変数とポインタのキャストは違う、後者は記憶領域を無理矢理指定するからな。
あとキャストしてもどうにもならないのがビッグとリトルのエンディアンだな。 charは数値じゃないの？
PICのXC8で、
x = 'A' + 1とかよくやるんだけど。
これは文字を数値とみなしているとは言わないのか？
なんかWindowsのC#ですら同じ演算をしたことある・・・
int data = str[i] - 'A' + 10みたいな
やり方間違ってるのか？ 究極的には合理的に期待通りの動作をするのなら、間違いではないのでは。 >>322
バイナリ数値から文字数値(?)に変換するときの使いますよね。
Aから上は困るんですけど。 正しいかはコードの意図が分からないと評価できないが
少なくともC#ではcharは整数型と区別されたので
コードはともかく理解としては間違いだと思う C#の世界だと、エンコーディングの概念が入ってきて、それをライブラリに任せるのが前提じゃないですかね。
マイコンで同じ考え方を適用するかどうかは条件次第。
前提となる条件を細かに設定せずに一律に間違いというのはおかしいし、もちろんいかなる場合でも
間違っていないというのもおかしいと思います。
ポータビリティの話を出す人もいますが、ポータビリティも絶対的に高い優先度の正義でもありませんし。 NULLは整数の0か？ってのと同種の問いかと
やっとCにもnullptrが導入されるんだね char変数一つで一つの文字を管理できるとは限ってないし、そういう場合は範囲判定とか足したり引いたりシフトしたりのような
演算の対象になると思います。 >>322
"0123456789ABCDEF"[n]
とかやったりする
要するにテーブル
8bit PICだと普通にやった方がいい 
