LRA1はなぜBASICなのか?外部MCUなしでLoRa通信したい!
この記事について
LoRaモジュール「LRA1」は、単なる通信モジュールではありません。
外部マイコンを使わずに単体で動作できる“自立型マイコン”を目指して開発しました。
その中核にあるのが──BASICインタプリタ。
今回は、なぜ2020年代にBASICなのか?
そして、他の選択肢(mruby・MicroPython)を試した結果、どうしてBASICに戻ってきたのか。
LRA1の設計思想を少しだけ掘り下げてみます。

🎀 LoRaモジュールなのにBASICが動くって、やっぱり変わってるよね〜(いい意味で)!
きっかけは“マクロ”
最初期のLRA1は、技適試験用の簡単なコマンドだけを持つモジュールでした。
SEND、RECV、CONF──ほんの数行の制御。
ところが、使っているうちに「ちょっとした処理を自動化できたら便利だな」と思ったんです。
最初は簡易マクロを作るつもりでした。
けれど、考えていくうちに気になったことがありました。
「他社のLoRaモジュールはどうなってるの?」って
🎀 最初は“ちょっと便利にしたい”くらいの気持ちだったんだね〜!
外部MCUなしで完結するモジュールをつくりたい
さっそく、他社のモジュールを調査してみました。
市販されている多くのLoRaモジュールは、外部にマイコン(MCU)を接続しないと何もできない構成になっていました。
UARTやSPI経由でATコマンドを送るタイプがほとんどで、
モジュール単体では送信も受信も行えません。
最初にこの現実に直面したとき、正直、驚きました。
LoRaという技術そのものはとても面白いのに、
使うためには外部制御が必須。
つまり「無線通信チップ」であって、「モジュール」と呼ぶにはほど遠い存在だったんです。
それが、どうにも不便でした。
簡単な実験をしたいだけなのに、
毎回ArduinoやSTM32などを別に用意して、通信コードを書いて、結線して──という手間が発生します。
「なんでモジュール単体で動かないんだろう?」
「LoRaの面白さを試すだけでも、こんなに準備がいるのか」
そう感じた瞬間から、
「外部MCUがなくても動作するLoRaモジュールを作る」という目標ができました。
つまり、LRA1は“LoRaモジュールの自立化”を目指した設計なんです。
BASICインタプリタを内蔵する発想も、
もともとはこの「単体で完結するモジュールを作りたい」という考えから生まれました。
LoRaを“チップ”ではなく、“小さなコンピュータ”として扱う。
それが、LRA1というプロジェクトの出発点でした。
🎀 つまり、“LoRaモジュールが自分で考えて動く”ようにしたかったんだね!
BASIC をやってみた
上に書いたように、LRA1単体で外部MCUなしで動作させるために、
最初は簡易マクロ程度のものを作るつもりでした。
でも、独自にマクロの文法を考えるのはちょっと大変です。
だったら、既に世の中にあるスクリプト言語やマクロを借用しようと考えました。
そのとき、気が付きました。
「それなら、もうBASICにしてしまった方が早い。」
数年前、別のマイコン(STM8L)向けに趣味でBASICインタプリタを動かしていたのを思い出しました。
自分の勉強も兼ねて、言語処理系をスクラッチから書いてみたかったんです。
目的はそれだけだったので、動いたら満足してそのままになっていました。
自作のコードなので当然に内部構造は完全に理解していました。
そのためLRA1(SAMR35)へ移植してみたら、意外なほどあっさり動きました。
これが、現在のLRA1 BASICの始まりです。
🎀 スクラッチから言語を作るって…、やっぱりそういう人だよね!
mrubyも試してみた
ある程度BASICが動作したときに、mruby-3.1.0(uRuby) も試していました。
※ mruby は、Ruby言語を組み込み機器でも使えるように軽量化した実装で、メモリ使用量を抑えつつ、Rubyらしい文法でスクリプトが書けるのが特徴です。
BASICの他に、今風の言語にも対応させたいなあという気持ちでした。
スタートアップやドライバー部分、バイトコードの解釈付近に手を入れて、
LoRa機能は未搭載で、LEDのLチカ程度までは動作することを確認できました。
ただ、やってみてわかったのは──
“動くけど、面倒くさい” ということ。
- RubyのコードをPC上でビルドし、
.mrbファイルを作る必要がある - 開発環境の導入が必須
- バイトコード生成のたびにPC側で処理が必要
- VMが重く、メモリを圧迫(SRAM的に厳しい)
結果、LoRaスタックと共存させるのは現実的ではありませんでした。
ちなみに、Windows用のアップデートツールは .mrb にも対応しています。
とはいえ、これは 「エラーにしていないだけ」(つまり、気まぐれ対応)です。
なので、いまでもLチカ程度のmRubyは動作します。
気が向いたら、そのあたりのコードも公開するつもりです。
🎀 “一応動いたけど、現実的じゃない”ってパターンだね!
MicroPythonは…スペックで即脱落
Pythonも一応検討しました。
LRA1を広く使ってもらうには、Pythonに対応するのが一番だと思っていました。
組み込み用にPythonを動作させるには、MicroPythonになります。
※ MicroPython(マイクロパイソン) は、Pythonをマイコンなどの小型機器で動かせるように軽量化した実装で、REPL(対話実行)やファイルシステムを持ち、スクリプト感覚でハードを操作できるのが特徴です。
でも、MicroPythonが快適に動くには最低でも次のようなスペックが必要です:
| 環境 | 推奨RAM | Flash | 備考 |
|---|---|---|---|
| ESP32 | 256KB〜 | 1MB以上 | 標準ポート |
| RP2040 | 264KB | 2MB | ファイルシステム込み |
| LRA1 (SAMR35) | 24KB | 128KB | LoRaスタック含む |
※ SAMR35 = SAML21 + SX1276 の SiP(System in Package)
この時点でアウト。
REPLもファイルシステムも持てません。
実装できても、動かすことが目的化してしまいます。
実用ではなく、苦行。
マイコン向けっていっても、リッチな環境のマイコン向けで、ぜんぜんMicroじゃないんです。
だからMicroPythonは検討段階で却下しました。
🎀 名前は“Micro”だけど、LRA1には“Mega”すぎたんだね〜!
BASICは「環境と一体」だから強い
BASICの強みは、環境と一体になっていることです。
コマンドを打てば即実行、結果がすぐ返る。
これこそがLoRaのような「送って・受けて・試す」用途に最適なんです。
昔の8bitパソコンのBASIC環境を思い出してください。
| 機種 | CPU | RAM | 備考 |
|---|---|---|---|
| PC-8001 | Z80互換 4MHz | 16〜32KB | カセットでプログラム保存 |
| MSX | Z80A 3.58MHz | 8〜64KB | グラフィック命令付きBASIC |
| LRA1 (SAMR35) | Cortex-M0+ 48MHz | 24KB | LoRa + I2C + PWM + SPI対応BASIC |
クロックは当時の約10倍、メモリは同程度。
つまり、昔のBASICマシンを再現できる性能がある。
だからこそ、BASICがいちばん自然に馴染んだんです。
あの頃の「電源を入れたら即READY.」という世界観を、
LoRaモジュールの中で再現したかった。
🎀 “現代のBASICマシン”って感じがして、なんかロマンあるね!
そして、LRA1 BASICは“ほんの少し今風”
LRA1 BASICは、見た目こそBASICですが、中身はちょっとモダンにしています。
DO/LOOPによる繰り返し構文IF ... ENDIFによるブロック構造FOR ... NEXTの改良(入れ子対応)CATCHによるエラーハンドリング- C言語ライクな演算子(
++,&&,||,!=など)に対応 - 飛び先にラベルが使える
つまり、GOTOを使わなくても構造化できるBASIC。
昔の雰囲気は残しつつ、現代的に書けるようにしています。
10 A=10 20 DO 30 A-- 40 IF !A THEN 50 PRINT "Done!" 60 EXIT 70 ENDIF 80 LOOP
このくらいなら、誰でも理解できる。
でも、ちゃんと現代的な構造化もできる。
“レトロ”と“実用”の中間を狙った仕様です。
🎀 BASICって聞くとレトロなイメージだけど、LRA1のはちょっと違うんだよ〜!
LoRaの操作も、1行で完結
LRA1 BASICのコマンドは、すべて1行完結を基本にしています。
SEND "HELLO" RECV 2000 I2C 64,0,1 PWM 3,128
START/STOPやバッファ制御は内部で処理。
「どうやって送るか」より「何を送りたいか」を優先できる設計です。
これにより、ターミナルから打ち込むだけでLoRa通信ができる。
IDEもライブラリも不要。
“書いて即実行”というBASICの原点をそのままLoRaに持ち込んでいます。
🎀 たった1行で電波が飛ぶって、ちょっと魔法みたいじゃない?
限界もあるけど、それでいい
LRA1 BASICは浮動小数点がなく、処理速度も遅い。
けれど、LRA1の目的は高速演算ではなく通信。
LoRa通信は数秒〜数分単位の世界です。
速度よりも、手軽さと“試せる環境”のほうが価値がある。
「速度よりもシンプルさ」。
それがLRA1 BASICの設計思想です。
BASICなら、電波実験やプロトタイピングに最適。
コードも人に見せやすく、教育用途にも向いています。
🎀 “速さ”より“楽しさ”。それがLRA1 BASICの良さだよね!
まとめ:BASICは原点であり未来
BASICを選んだのは、懐古ではなく合理性の結果でした。
uRubyもuPythonも強力だけど、
「LoRaを即動かせる環境」という目的から見ると、
LoRaのような低速・省電力通信では、
シンプルで直接的なBASICが、いちばん自然だったんです。
昔のBASICマシンが持っていた“閉じた小宇宙”を、
いまのマイコンの中にもう一度作る。
そして、昔のBASICマシンが「コンピューターの入り口」だったように、
LRA1 BASICも「LoRa無線通信の入り口」にしたかった。
🎀 BASICが“過去の遺産”じゃなくて、“未来の入口”になるって、ちょっと素敵だね!
📪 お問い合わせなど
技術的なご相談やご質問などありましたら、
📩お問い合わせフォーム
または、
📮info@shachi-lab.com までお気軽にどうぞ。
🎀 気になることがあったら、気軽に声かけてね〜!
🔗 関連リンク
しゃちらぼの最新情報や開発の様子は、こちらでも発信しています:
- 🌐しゃちらぼ公式サイト
- 🐦 X(旧Twitter):@shachi_lab
- 📗 Qiita:@shachi-lab
- 🐙 GitHub:@shachi-lab
- 📸 Instagram:@shachi_lab
ほんとは「しゃちらぼ(Shachi-lab)」なんだけど、見つけてくれてありがとう🐬




コメント