テンプレ よの中にはいろんなOSがあるんだから質問するなら自分の環境くらいかけよ
PyDOS - DOS like OS for Raspberry Pi Pico RP2040
@YouTube
なんか美しくないからこういう実例は外部のwikiにでもまとめてリンクを貼ったらいいんじゃないだろうか
初めて自分で1スレ目を立てたからウッキウキなんだよ
URL羅列しても誰も開かねーってのに
>>3-32
日本語のサマリーとしてはいいかもだけど、わざわざ貼らなくとも普通見てるからそこ。
でもukは利用人口がメチャ多いから情報も多岐でいいよね >>12
だね。3以降はテンプレじゃねーものね。
公式すら見てない人も、日本語の動画真似以外は理解不能の興味無しもいるから >>33
事例というかラズパイ財団が出してるニュースレターのpico関係一覧のカレントまでってだけだね >>34
URL開いて理解できないの?どこがわかんなかった?
まあ頑張って切磋琢磨しろや 無自覚荒らしの厄介な奴がスレ主気取りになっちまったもんだなあ
こいつあちこちで煽り散らかしてるからなあ
マジで消えてほしい
フォトカプラのPC817のコレクタを3.3Vにつないで
エミッタをそのままGPIOピンに入れて
内蔵のプルダウンで入力したら壊れる?
どこにも壊れる要因がない。
動作するとは限らないけど。
電源投入からプルダウンの設定までは宙に浮くとか
内蔵の抵抗値がやたらと小さいとか
くらいじゃないの
ところでピンから出せる電流とその合計ってどこに書いてあるの?
>>55
電子科卒業なのにもっと沢山LEDをつなげる方法を人に聞くんか LEDネタが出たのであれだけど、Adafruit_NeoPixelのソース見たら
earlephilhower版のArduino用でPicoのPIOに対応してるんだな
と思ったら公式のMbedベースのArduinoでもPIOに対応してるっぽいね
MbedベースのArduinoでもPIO使えるのか
公式のMbedベースのArduino coreでもPIO使えるね
実際にpico-sdk用のPIOのプログラムが公式のMbedベースのArduinoからも使えた
PIOがRP2040の強みだから真っ先に対応させたくなったんだなきっと
>>58
高専の電子工学科卒業ってこの程度かよ
なんにも理解せずに説明してる感じがするね
読み上げ文章も電子工作も人任せな気がする
さすがにイラっとくる動画 YouTubeなんて自称詳しい奴の素人騙しがデフォルトだろ
今のご時世サーチエンジン最適化とアフィリエイトが絡むから昔よりタチが悪い
>>74
LEDで何をしたいか、によるのでは。
普通の室内の明るさのもとで視認できることが条件なら、高めの輝度のものなら0.5mAも流せば十分見えるわけだし。 >>73
50mA取れない電源なんてヤバいじゃん。 >>76
ソーラーとか極小バッテリーなら不足するかもだわ
3.3V、<18mAのセンサーつないで動かせなかったことある
pico本体は動いてたけど I2CでMCP23017とかPCA9685モジュールでも付けるか?
>>74
どんなLED使うかによるがそいつの電流の70%流すのと100%流すので人間の目で視認区別するのはよほど頑張らないとわからんかもよ
あとは外付け回路をどう組むかとか フォトカプラのLEDなんかは7〜10mA
くらいはしっかり流さないとね。
>>82
条件次第では。
CTRのばらつき、CTRの経時劣化でマージンを考える。
応答速度を速くするなら出力負荷抵抗は小さくなるのでLEDに流す電流も大きくなる。
高温にさらされる環境であったり、寿命を優先するならLEDに流す電流は大きくしない。 ダイナミック点灯・・・
というか「Arduino LED 電流」とかでググると10〜20mA流す的な解説をしている
お前何十年前に書かれた記事かよ?みたいなのがいっぱい出てくるんだよなぁ
っていうか沢山付けたいけど電流が足りないから
ダイナミック点灯これ良いじゃんって覚えていくのが
電子工作の楽しみそのものだと思うんだが
そういう技術を吸収しようという発想が無いのか?
池沼か?
>>85
>電流が足りないからダイナミック点灯
ちょっと意味わからないですね。 言いたいことはわかるけど抵抗値を増やせばええだけって結論になるわな
>>84
LEDの定格輝度の条件がその電流になっているのを
「その電流で使う必要がある」と思ってしまっている人がたくさんいそう。 >>85
ダイナミック点灯にすると、たとえば4桁をスキャンするとして、
LEDの電流-輝度がリニアな領域で使い、かつ、桁間の休止時間を小さく抑えられたとして、
スタティック点灯のときと同じ明るさにしようとするなら、
LEDには4倍の電流が必要になるよ。結局、理想状態でもトータルの電流値は変わらない。
実際には、電流が大きくなると、直線性は失われる傾向にあるので、同じ明るさにするなら、
より多い電流が必要になる。
でも、明るさが1/4になってもおそらく、まあ見える。
それはスタティック点灯でも同じなので、ドライブ可能な電流が足りない場合に、
明るさを落としても良いなら、スタティックのままでも抵抗を大きくして電流を下げればいい。
ちがうのでは?積極的にダイナミック点灯を選ぶのは、制御側の必要ピン数や配線量を
少なくしたいときとか、ダイナミック点灯とやらをやってみたいときじゃないの? Arduino育ちの人の多くはダイナミック点灯方式とか未知の技術なんじゃないかな
「Arduino LED たくさん」とかでググってみてもポート直かシフトレジスタばかりで
ダイナミック点灯なんてほとんど出てこないし
実用的な任意の構成によるダイナミック点灯を実現しようと思ったらタイマと割り込みと
GPIO回りの理解がほぼ必須というのもありそう
>>88
Arduino系の解説サイトだとデータシートのForward Currentを流す電流値として
解説しているところが少なからずあるように見えるね LEDなんて3.3vに560Ωでいいじゃんって思う
最近のLEDは更に高い抵抗値でないと眩しそうだが
>LEDなんて3.3vに560Ωでいいじゃんって思う
そうやって、定番を持とうとするのはなんでなんだい、って思う。
用途次第で変えればいいのに。
>>90
ダイナミック点灯にしていいことなんて何もないからな。
強いて言うならポート数や抵抗が削減出来ること。
あと、デューティ比変えて明るさを変えられるくらいか。
なかなかいいじゃないか。 メーカー製の評価ボードを見るとLEDの電流制限抵抗は0.5〜1kΩくらいが
多いように見える。もちろん色によって増減したりはするが10mAなんて
流しているのはほぼなさそう
当たり前だがその程度でも十分な輝度で発光している
抵抗でLED制御するなよ
電流制御の素子があるんだからそれ使え
あとは外付けのLEDドライブ回路チップに任せりゃいいだろ
流す電流なんて使いみちによりけりだろ
照明用だと1個で100mAとかもあるし
てかGPIOは制御用と割り切ってLEDには別電源通すのが一番
でなきゃド派手な演出はできない
制御だけならLED何千個だろうがPin1本で済むんだから
>>96
それはちゃぶ台返し論法だから論外
そんなの言い出したらお前作ってるのただのリレー動作なんだろ
それなら全部リレーで作れやって言われるのと同じやで >>99
ちゃぶ台返し?
何言ってるんだ?
チップのデーターシート見て
LEDの仕様みて
電流制御の選択するだけだろ?
そこでやれ抵抗がとかいうアホが湧いてるのが変なだけだ! 何ならあれだ、100円ショップで手に入る人感センサー付きの多頭LED搭載してる基板にpicoのGPIOから司令出して繋げばエエだけだろ?
まあ、今はたくさんつけるならシリアルなLEDで2ピン使うだけで数はどんどん増やせるし、フルカラーだし。
便利になりましたとさ。
というか>>68の「Arduino nanoを使ってLEDを点滅させる方法について解説します」(アフィ有)なんかも
不正確だな。あの説明では詳しくない人が見たら20mA流すのが普通だと認識する人が出て当然だろう
あと足の長い方がアノードだと解説しているが希に逆の部品もあったりするしデータシートで確認すべきだ
ググると電流制限抵抗1つで並列に接続された複数のLEDを点灯させる例が出てくるけどVfのばらつきが未考慮
定格上限ギリギリで計算されていた場合定格オーバーになる素子が出かねない
各列に電流制限抵抗を挿入するか、全部直列にして定電流駆動するのが定石か >>100
いやいや。
これって3.3Vのポートで点灯するのが起点の話だよね。
ポートでないとしても、1個1円するかしないかの抵抗で済むところなら、
電流制御の素子を積極的に使う理由って乏しいのでは?
抵抗と違ってメーカーの選択肢も狭いし、供給の点でも抵抗の方がずっと有利。
電圧の変動の激しい電源で直接点灯するようなケースぐらいでは。
ほぼ一定の電圧の環境下で、抵抗ではなく電流制御の素子を使うのってどんな有利さが
あるのかな?
たとえば、3.3Vがかかるところで、VF1.7V@3mAのLEDを、3mAで点灯したい場合に
抵抗よりいい具体的な電流制御の素子のメーカーと型式を教えて。 >>103
@YouTube
これかな。学校のクラスで先生がみんなに同じように教えていても理解する生徒、表面的にしか覚えない、そもそも
全然わからない生徒など、いろいろいるのは誰もが経験している通り。
YouTuberの説明に限らず、たいていのことについて「〜と認識する人が出て当然だろう」はいえるね。 >>96
Pico の GPIO に CRD 付ければいいんだな。w >>104
IOが3.3VでVf=1.7VだとCRDにかかる電圧は1.4V。
余裕見て1.0Vに抑えると使えるCRDはSEMITECHだとE-301(0.3mA)しかない。
まあ、E-501(0.5mA)でいいとしよう。Vk=1.1Vだけど。
となると、3.0mA流すためには6本パラレルだね。
まあ、数百円だしいいだろ。ちょっと場所取るけどね。
オームの法則の計算が出来ないソフト屋さんなら仕方ないさ。 >>108
おいおい、データシートすら見てないのかよ?
ただのPWMコントロールでカレント制御もないじゃないか。
"10. Application design-in information" の回路図見てみろよ。抵抗入ってるじゃん。
ギザギザの抵抗しか知らなかった? IOが3.3VでVf=1.7VだとCRDにかかる電圧は1.6Vじゃないのかな。
それは置いておいて、電圧が変動することを考えなくてもいいケースでCRDを使っている人はときどきいるね。
別レスだけど、抵抗で済むところに、セカンドソースがいろいろあるわけでもなく、安くもないICを使うって、
それはちょっとないな。
抵抗の計算を厳密にやろうとして挫折する人がいるんかな?
「別レスだけど、抵抗で済むところに、セカンドソースが〜」はマクニカの記事の話ね。
>>111
ちょっと話が違うけど、
・アナログ可変定電流でLEDを点灯するのと、
・抵抗による電流制限+PWMとで、
後者の方が断然発熱が少ない、って思ってる人がいるよな。 >>113
すまん、引き算は苦手なんだ。
マクニカは扱ってるICを売るためなんだろう。大手なのに初心者にも優しい感じだよね。 CRDのデータシートを見れば判るが電圧の低い領域で定電流特性は得られない
>>105
不正確な説明で誤解を招いているのを正当化するつもりか 仕事やと状態表示程度でそんな物は使わんし、勿論ポート直結もせんな。
なんの影響力も持てない匿名掲示板の名無し風情が喚いたところで何があるというのか
>不正確な説明で誤解を招いているのを正当化するつもりか
彼が「このLEDは20mAで駆動しなければならない」といっているならともかく、最初にLEDに流れる電流と電圧のグラフの説明をしているし、
計算のレッスンで「流したい電流、今回は20mAです」といっている。
もし、これを「不正確な説明で誤解を招いている」というのなら、5chの書き込みの大半は説明が足りない曖昧なもので誤解を招くということになるぞ。
>>121
動くかもしれないけれど動作安定しない可能性あり
また最初は正常でも経年劣化で動作不良発生するかもよ
発振したような動作不良が起こる可能性もある
余り低い値は止めた方が良い >>121
動く可能性はあるんやが、そういうの使う時はキチンと定格守るわな。
元々は人の眼が誤魔化せたらエエだけの LED 点灯の話やからなぁ。 フォトトランジスタなら負荷次第だがFETだからなー
>>121
>最低5mAって書いてあるけど
データシートを見た感じだと
(最低必要な電流にばらつきがあるわけだけどその)最大が3mAって書いてあるように見える。
MOS FETのフォトカプラは、フォトダイオードの出力でゲートをチャージしてONにするので、
ある程度以上のLEDの明るさなら、ON時間が早くなる遅くなるに影響が出てくる。
でも、ゲートの放電回路やそのリークとかもあるので、デバイスによって最低駆動電流はいろいろ。
より小さい電流でONにしたいならこっちかな?
https://akizukidenshi.com/catalog/g/gI-16057/
トランジスタ出力のものに比べると、動作はすごく遅いので、置き換えは用途を考えて。 >>120
複数名の初心者にあの動画を見せて現物を作らせてみ?
十中八九動画の内容に反しないにもかかわらず過電流になる例が出るから
抵抗による電流制限が適当ではない例だから当然だが
あと一般的に影響力が大きい人ほど確かな情報発信が求められると思うけど
それも否定するのかな。5chのレスとチャンネル登録者数20万が同じ? 今日は昼まで暇だから何となく手持ちのLEDチェックしてみた
最近のは5mAでも十分な明るさだな
窓から外光入ってるのに2m先の壁に高輝度LEDの赤がクッキリ見える
これ以上はイチケンスレかイチケンの動画のコメント欄でやってくれ
電圧をかければ相応の電流が流れるし、電流が流れているという事は相応の電圧が掛かっている
>>134
ダイオードを定電流でドライブすると抵抗のように振る舞うよ! 電流と電圧が分かれば、そのときの抵抗値を計算できるよ。
>>135
>実際の回路設計では、VFばらつき、抵抗・電源電圧の誤差、温度変化などの考慮が必要です。
これをガン無視している解説が多くてヤバイ 個人の趣味の電子工作だと
もうただのLチカの時代は終わって今はNeoPixel系のRGB LEDなんじゃないの?
あれも、多数のNeoPixelを駆動するとなると
電源をマイコンの電源端子から取るのは論外だし
>>139
吐き出しで使うとは何事だ!
I/Oは吸い込みで使いたまえ。 >>141
Neopixel って、タイミング取るの意外と面倒くさいよね。
1/0 で 1bit の時間幅が変わるからUSARTとか使えないし。 ポートでLEDを点灯するのに「抵抗を使うのがおかしい」みたいな論調の人は
もう自論を撤回したのかな?
↓これには明快な答えがなかったね。
>たとえば、3.3Vがかかるところで、VF1.7V@3mAのLEDを、3mAで点灯したい場合に
>抵抗よりいい具体的な電流制御の素子のメーカーと型式を教えて。
>>146
声低くなったよね
あと音程リズムおかしくなってるから今の歌聞けない >>143
一度ライブラリ作って仕舞えば使い回し効くからどうってことはないけどね >>149
Adafruit_NeoPixelというお手本があるしな >>151
コレクタからベースのリーク電流を考えるとベース・エミッタ間に抵抗入れるのもあり
おまじない程度かもしれんけどシビアなケースでは色々安全策が必要 どうやらぼくはアスペの毛があるのかもしれないと最近自覚しつつあるのだが、
ベース・エミッタとを抵抗で結び、並列に抵抗を挿すと言われれば違和感はないのだけれど
ベース・エミッタ間に抵抗入れる と表現されると
斬鉄剣で トランジスタを一刀両断して 生じた空隙に抵抗を挿して繋げる様なイメージを持ってしまうのであったグギギ(^p^;)
>>156
「挿入する」なら斬鉄剣だけども
装置全体でみると「入れる」でもおかしくはないぞ データシート見てみたけどRP2040のSPIは連続送信できない・・・のか?
STM32やRXは連続送信できるのでシリアルLEDが要求するようなパルス列も生成可能なはず
>>135
フォトカプラの比重が異常に大きいんだがなんなのこれ >>159
0ばかり送るときのパルス列
1ばかり送るときのパルス列
それぞれは造れるけど
0と1が混在してるのを送信するのは難しいというか無理なんじゃね >>164
すでにいたか。最小パルス幅を400nsにすれば3ビット(0b100 or 0b110)でいけそう
そこにも書いてあるけどタイマの波形生成機能でもいけるはずだけど
ARM系の場合DMAの動作タイミングが判りにくい事が多いから難易度は上がりそう
STM32もマニュアルにDMAの動作タイミングが書いてないし >>156
米国の大学のテキストなんかでもinsert
resistorはあるし、Xilinxのフォーラムでも
Should I insert resistor between FPGA user io and io of other devices
なんてあるけど、「insertじゃねえ!」なんて騒ぐ下品なのはいないか。 いや、それはもろにInsert xx Between ** and ++ で適性な案件やろ(^p^;)
>>165
RP2040はPIOあるのになぜわざわざSPI? 相手側がSPIの機械なんだから
SPIで話しかけるのが礼儀だろ
衣食足りて礼節を知る
意訳:おなか減っていたらPIOでもおk
>>169
NeoPixelをPicoでSPIで実際にやってみると、難しいぞ
全く光らないことはないけど、おかしな表示になったりする
普通にGPIO操作でもやってみたが、GPIO操作では普通にうまくいった。
PicoでArduino以外でやる場合ならGPIO操作ではなくて、
Adafruit_NeoPixelのPIOの部分をそのまま持ってくるのが一番楽だろうね
GPIO操作の場合、Picoのようなある程度高クロックのマイコンなら簡単
Cortex-M0にはSysTickタイマーがあって
Picoの場合は何もしなくてもシステムクロックでカウントダウンしてる
これを使えばあとはAdafruit_NeoPixelのライブラリの中の
#elif defined(__arm__)の部分を少し書き換えるだけ
クロックが低いものだとアセンブラレベルのプログラミングになるね GPIO叩くにしても第一選択肢はDMACだなぁ
よほど暇じゃない限りCPU使うメリットは薄い
>>172
DMA使うためにもPIO使った方がいいんじゃないの? Adafruit_NeoPixelのライブラリでは
Pico用のコードはPIOを使って書かれてる
ESP32用のコードはRMT(赤外線リモコンの信号を制御するための機能)を使って書かれてる
TwitterにNeoPixel光らすためだけに
メインのマイコンとI2CでPICつないでPICでNeoPixelの制御してる人もいるね
そういうのもありかもね
Picoの場合、SPIでわざわざやらなくてもPIOで簡単にできるからね
PicoはSPIのピンを自由に変更できないし
2つしかない貴重なSPIをわざわざ使うこともない
そのマイコンの特長的な機能を使ったほうが簡単なのに標準的な機能に拘る人がいるのはなんなん
移植性とかを考えてんの?
ラップしたらいいだけじゃん
>>176
ARM PrimeCellのSPIはポンコツ
MSB Firstしか出来ないし送信ビット数も4-16までだし >>172
Adafruit_NeoPixelのコード見ると、#if defined()の機種依存コードのオンパレード
それを共通のインターフェースで使えるようにしてるよね micro:bit の NeoPixel ライブラリも優秀
>>180
SPIの規格でMSBファーストになってるだろ? バスパワーのUSBハブ(例:U2H-SN4NBF2BU)にpicoを3枚ぶら下げていた時、
外部リセット(RUN端子)でのリセットとかUSBシリアルにデバイス記述子の失敗が出てがうまくいかないことがあった
2枚まではそのUSBハブを抜差したら直っていたが3枚以上になるとそれでは直らなかった
別のセルフパワーのUSBハブ(USB-HUB220WH)に刺したらUSB関連のエラーやリセット失敗は出なくなった
試しにそのUSBハブの電源アダプタを抜いてPCに繋いでみたらUSBの電源が足りないというwindowsのエラーが出た
USBハブのチップの相性が悪いのか電源が足りてないのかわからんが相性の悪いハブはありそう
USB-HUB220WHのUSBハブのベンダーはNEC、U2H-SN4NBF2BUのベンダーはGenesys Logicだった
チップのせいか確かめるためになんか適当なセルフパワーのハブ買って試してみたい
一度にそんなにぶら下げてどうするの?
Picoは外部電源でも動作するんだからUSBでそんなにぶら下げる必要ある?
picoprobeで一枚、それから繋げるので一枚、確認用で一枚
PCとの通信用にusb-cdcも使うからどうしてもそんな感じになるのよ
picoprobe中にusb-cdc使うと死亡する
>>187
Picoは安いからいろいろ使いたくなるのはわかるな
>>188
そのためにわざわざ公式の接続方法では
TargetのPicoのUART0を繋げるようになってるんだろう
Debug中はUSB使うなってことだろうね
Arduino公式のPico用Arduino CoreでもSerial1に出力すればUART0に出力される probe使用時にusb-cdcを使って落ちるってどういう場面だろう
なんか通常使用時に起きる可能性のあることなら潰しておきたいから教えてほしい
えっ?ターゲットをブレークしたらターゲットのUSBが止まるって話?
ブレークしたら割り込みが処理できなくなるから当たり前じゃね?
USB使うプログラムはデバッグ不可能っておかしいだろ
上のUSBハブの話の余談だけど非NECチップのハブに繋いでSDK使って作ってる時にハードウェアuartを使おうとしたらハングしてたことがあった
その時にはuart_init(uart1, 9600)と記述してあっただけでハングしてた
念のためprobeに繋いでない別のpicoを同じUSBハブに繋いで同じプログラム書き込んでみても同じようにハングしてた
今使ってるNECチップのUSBハブに繋いてる時にはuartとtinyusbのcdcの同時使用でもハングしたりはしていない
同じ時にUSB繋がずVBUS電源供給でそのプログラムを書いたpicoがどういう動きをするかは試してない
もしusb側がハブとの相性が悪くて足を引っ張ってたとしたらUSBを繋がなければ動いていたかもしれない
>>192
USBに限らず通信関係のコードは止められない事が多いのでブレークせずにデバッグするのが定石
デバッガのモニタ機能やモニタ用コードの埋め込むなどしてデバッグする
USBの場合ホストのドライバも絡んでくるしデバイス側を止めるとホストまでおかしくなる可能性すらある VSYSに5V入れてる状態で
USB繋いだら壊れる?
USBワンセグチューナーでワンセグ受信機にしてる人全く居ないのだけど
あの手のチューナーはARM Linux用ドライバが無くて動かないの?
ここはLinuxをインストールできるrpiのスレではないぞ
STM32はUSBホストの作例あるけどpicoはそういうの無いの?
みつけた
pico-examples\usb\host\host_hid
電池で動く省電力なものを作りたいんだけどpicoの省電力性能は他と遜色ないですか?
>>203
ピコは恐ろしく省電力で動くチップだけど
使いようじゃないの? 省電力と言ってもソフト面とハード面両方あるからなぁ
pico+MicroPythonとかでは適切に省電力に配慮した設計が
されているSTM32やRX等と比べたら相当悪いかも
ネイティブでの実行効率も良いとは言いがたいし
今のスタンダードは
void loop() {
〜
}
とかだからな。イベントドリブンなコードを書けない人がいても驚かない
俺もパイソン
低レベル言語で書くほどの応答性必要なもの全く作ってない
何だったら人間が目視してスイッチ要りきりする程度の反応速度でも良い物ばかり
analogReadを高速化!みたいな人も少なからずいたりする
別件で引っかかってきて検索してみたら出てくるわ出てくるわ・・・
頑張るところはそこじゃねーだろw
どうせマイコン界の流行なんか移り変わるし
picoに特化したもの覚えてもねー
趣味ならPIOとか試したくならん?
業務でRP2040選定したならなおさら活かしたくなる!
このFETって逆向いてない?
>>216
VBUS(USB)が無くなるとか、外部(V)より電圧が下がった時に、外部から供給される。 VBUSと外部Vの両方が接続された時、寄生ダイオードを介して外部V側に電流が流れるのを嫌ったんじゃないかな?
待遇関係の論理を経ずに、ダイレクトで素直な表現が促される
おれも小物はMicroPythonかCircuitPythonなボードで作るようになった。
でもたまに苦しみながらもCで書くのが楽しい時がある。
趣味だから楽しい方を使ってるわ。
C++に慣れてしまったから今更Cはキツイわ
8051系でCコンパイラしかなくてちょっといじるのでもすごい時間掛かった
>>226
ヘタレなので...
他所様が作成のライブラリは使える。
自分では使いこなせない。せいぜい構造体 構造体ならCにもあるだろ。
ライブラリだって言語関係ないじゃん。
C++じゃなきゃダメな理由にはならん。
おなじこと表現するのにCとC++で生産性ぜんぜんちがう
Cだとケアしないといけことが多くなる
同等のことは書けなくはないけど品質担保するのも大変
学習量の差はあるけどC++つかわないのはもったいない
>>229
それって
CよりPythonの方がプログラムスッキリしていて見通しよく良いと言う話に通じるじゃん
案件という条件づけしないと良し悪しは判断つかないぜ
そしておれはPythonで十分
稼げて簡単がサイツヨ スレチだし機能に差がありすぎて書き切れんけど
たとえばコンテナひとつとっても同等の品質で実装するのはほぼ無理だし
Cでマトモに可変長なデータ構造扱うと本質的でないコードが散らかってつらい
基本C互換だから欲しい機能だけ使えばいいし
>>214
ArduinoからもMicroPythonからもPIOは使えるよ
Adafruit_NeoPixelのPico用の部分はPIO使って書かれてるし
MicroPythonでは公式のpico_python_sdk.pdfに使い方載ってる thonnyでmain.pyファィルから同じフォルダの別ファイルの読み込みってimportじゃあかんの?
thonnyはしらんけどその時のsys.path確認してみ
マイコンで可変長変数ってOut of memory出ない実装なのか、出たらあきらめるのか・・・
I/Oポートアクセスに数μsかかるのはなんとかならんかな。
GUI組もうとしたらネイティブコードで頑張るしかない
>>245
シリアルでLCDパネルなりOLEDパネルなり繋げば良かろう ウィンドウシステムみたいなGUIって四角を延々と書くだけ
処理が重いわけけでもないし頑張る必要も何もないけどな
ワンチップマイコンでGUIはフレームバッファの確保が厳しい
1ラインずつレンダリングするならバッファ容量は緩和されるけど
レンダラーの実装が大変
micropythonとPimoroniのpico displayでGUIアプリ作ってるけど結構速いよ
アニメーションも出来てる
>>249
320x240で16bitカラーだと150KBくらいになるからそうだろうけど
SSD1306のOLEDのような128x64で1色ならフレームバッファ容量はたったの1KBだよ?
ちなみに素のMicroPythonでもframebufモジュール使えば
ネイティブの速度で線を描いたり矩形を描いたり文字を出力したりは可能 あと、320x240の16bitカラーの液晶でも全画面分のフレームバッファを確保しないで
画面の一部分の分だけフレームバッファを確保して画面の一部分だけ出力することも可能
例えば上から3分の2だけ描画するとかね
GUIがどういうのを想定してるのかわからんけど重ね合わせのあるウインドウシステムっぽいのだとフレームバッファが無いと非常に重い
タイルとか見た目だけで実際は重ね合わせのないものならラインバッファでもなんとかなるか
MicroPythonはframebufというフレームバッファを扱うモジュールがあるから
線や矩形は高速描画できる
円を描く命令はないので円は無理
テキストはフォントサイズを変えられないが一応text出力命令がある
bitmapの描画命令もある(透明色も指定可能)
ただ、その分RAMが必要
SSD1306のような低解像度のOLEDならフレームバッファは1KBなので全く問題ないが
ILI9341になると全画面分のフレームバッファは150KB必要で
MicroPythonだとメモリが足りなくなって確保できないね
MicroPythonでグラフィックスで複雑なことするなら
PimoroniのLCD買うのがいいかもね
というかそういう用途はMicroPythonよりもArduinoの方がいいかもしれない
ArduinoならTFT_eSPIを使えばいろんなLCDに対応してるかも
TFT_eSPIを使うならearlephilhowerのArduinoを使った方がいい
earlephilhowerのArduinoならPIOやDMAなんかにも対応してる
ArduinoならTFT_eSPIにはスプライトの機能があります。
AdafruitGFXならGFXCanvas16を使うことでフレームバッファと同じことが実現できます。
>>258
自分でpico_sdk用のグラフィックスライブラリ作ったけど、結構大変だよ
かなりのコード量になった LCDのプログラミングに慣れないと、LCDの初期化ですら苦労するだろうね
はっきり言って、初期化処理が一番大変かも
初期化がしっかりできれば、あとは簡単
ただ、いろんなグラフィックス命令をサポートするのは正直面倒だし
コード量も増える
Adafruit_GFXは最悪、点さえ打てればすべてのグラフィックス機能を使えるようになってる
効率とか考えなければC++が使えるマイコンに全機能を移植可能
実際に私はNUCLEO-F767ZI用にAdafruit_GFXを丸ごとそっくり移植して使ってたりする。
文字表示する場合はArduinoのPrintクラスと同等の機能を自分で実装しないといけないけどね