AVRマイコン総合スレ Part41
■ このスレッドは過去ログ倉庫に格納されています
なんかサンプルと違うんでしょ? まったく同じもの作れって言ってるのに。 sd_write() がゼロ以下を返してくる原因が知りたいのか?
ソース付いてくるのになぜ読まないのか 最近の若いモンは… いやジジイかもしれんが
sd_write() の実体は sd_L3_write() だ
sd.h でそう define されている
返しているのはゼロで初期化している wd の値だ
それがゼロのままリターンする経路は見たらわかるな?
sd_errno にエラー値をセットしているのも見えるな? ざっと見たけどこれ
オレなら使わない
そもそも sd_open() から怪しくないか?
ポインタ返してるのにサンプルはゼロ未満しかエラーにしてない
sd_L3_open() ではエラー時にゼロを返すようにしているっぽいが
sd_errno = SD_E* して break してる箇所では「ゼロ超」返すケースありそうな? >>288
mega328pの動作環境も有るのなら、FatFsが動作するか確認してみては?
問題がハードに有るのか、ソフトにあるのか見当が付くと思いますよ。 なんか昔、FatFsにAVRのローレベルデバドラ書いて
同じような症状が出た覚えがあるんだけど
どうしたんだったかな?
FatFs付属の奴と同じ感じに書き直した様な…??
まぁ良いや… avrで力不足で、16bit 、今時では、32bit系に行こうと思ったら、どのマイコンがオススメなんでしょう。
avrstudioの環境が無償なのに、なかなかよく出来ていて、
そんな都合の良い環境のものが、存在しているのかどうか知りたいです。 >>294
その環境のまま32bitの開発するんじゃあかんのか? >>295
ホントだ。いきなり解決?開発環境はどうなるのですか? >>297
???
Atmel Studioが使いたいんじゃないの???
インストールするときに32bitAVRのチェックわざわざ外したの? >>298
そういうことですか。。。ありうがとうございます。 ちなみにだが
AVRにこだわりなければARMのCortex-Mシリーズもおすすめだから
どうせインストールしなおすならARMパッケージもいれとけよ AVRスレで堂々とCortexに誘導するとは
曲者だ!!出合え!出合え! AtmelもSAMとか出しちゃってるんだしいいじゃんもう >>300
凄いですね。ところで、avrstudioで使えるのは、元atmelの Coretex-Mだけですか? AVRは好きだけど…
これから32bit勉強したいって人にAVR32とARMでARM勧めるのは文句言わないよ俺… AVR32はメーカーでもレガシー扱いだからやめとけ >>304
は?おじいちゃんなにモグモグ言ってるの? >>283
>>284
WS2812BのLEDを制御するコントローラーです。
SDカードにビットマップファイルを入れて、mp3プレイヤーの音楽を流しながら、LEDパネルとLEDテープを同時制御させようかと。
https://i.imgur.com/XQiYjmn.jpg
ATMEGA1284Pの16MHz駆動ですが、簡単にプログラム書いてみたら20fps位は出るので、まじめに書き直せば30fps位はなんとかなるかなーと期待してます。
https://i.imgur.com/x40Yur8.jpg
写真ってどうやって撮れば綺麗に写るんですかねぇ、発色がイマイチに見えて、どうすれば良いのやら… >>310
LEDをそのまま写真にとると白っぽく映ってしまうのはあるある
スモークなどのフィルタを使うとかカメラの露出をかなり下げて撮るといいかも
赤や青の単色のLEDなら専用の濃い目の単色フィルタがかなりいいが、フルカラーは難しいかも カメラって光りを出してるものは見た目通りにいかないからね。
目にはうす〜く光ってるくらいでちょうどいい。 マニュアルレベル補正で
白いところを登録すると撮影時に結構落ち着くよ
最近までこの方法を知らなくて、室内で何撮影しても青くなるんで悩んでた 丁寧で感動した
下に映ってる水色のカッターシートがダイソーなのは
わかる >>315
それレベル補正じゃなくて ホワイトバランスじゃね? 光ってると何色でも白く写っちゃうんだよな
赤外線も・・・ pic屋だけど、avrの性能とC言語との相性の良さにひかれたのと、環境を整備してるけど、
ChaNさんのところの、FFTとFAT 途中で切れちゃった。
ChaNさんのところの、FFTとFATを試すために、開発環境を整備してるけど、そのあと、何を作ろうか、迷ってる。
今使ってるPICのリプレースといっても、PICで事足りてるところで、メリットが無いなーと。 PICのADCのVREF 2.048V使えるとか、OPAMP付とか、便利なんだけど、
avrでそういうのあるのかしら?初心者なんで、うまく探せなくて。。。 Vrefは内部1.1Vとかあるよ。デバイスによっては複数から選べるものも。
アナログアンプは積んでるの見たこと無いな。
どっち使うかは好みとしか言いようがないねえ。簡単なことならどっちでもできちゃうし。 >>323
PICの方がペリフェラルは豪華なんじゃないの
内蔵RCの精度も高いし
AVRは多少パワーがあってgcc使えるぐらいの利点しかないと思う Future Product
Tiny1627のピン数の違うパッケージ出るようです。 1626/20pin 1624/14pin
さらにFlashサイズ拡張で TinyAVR 2-Seriesになるのかな?
XmegaやTiny1627の12bitADCにはProgrammable Gain Ampが付いてるようです。
arduino UNO WiFi REV2のmega4809クロックは内蔵RCだって。 アプリを作るのも楽しいけど、システムプログラムを作るのも面白い。
私は純粋にプログラミングが好きなので、
(アプリを作っても、ほとんどの作品は完成したら押し入れに突っ込んで終わり)
AVR用の真のISPを作ったり、デバッガを作ったり、マルチタスクを作ったりして楽しんだ。
(もっともこれは私がAVRを始めた時の制作順だけど)
多分私みたいなのは変人奇人で、正しいCPU道から外れていると思う。
アセンブルで作っているので、CPUはPICよりも脳内アセンブルが可能なAVRの方が好き。 >>325
PICの2.048Vというのが、なんとなく気持ちいいんです。変換値10bitで,2倍すれば直接電圧に
なる。
vrefが中途半端な値だと、スケーリングしなければならないですから。もちろん乗算器があればそんなに
オーバーヘッドないし、電圧計作るような用途じゃない限り、あえて、変換する必要も無いですけどね。 >>330
実力は±4%精度なのに2.048Vとか0.1%オーダーの
有効数字で表記するのはどうかと思う… mega0シリーズやtiny1シリーズはパワーの割に安いのがちょっとうれしいかな。 >>332
確かに、精度出そうと、外部ADC使うとか、外部vrefを使うのであれば、
この点でのPICのメリットはなくなりますね。 昔、FA用に±15V電源の外部ADCを絶縁したりして使っていた頃、
CPU内蔵ADCが出てき時は、
高速パルスが飛び回っているCPU内にADCを同居させるのか、
CPUと同じ電源を使うのか、
と驚いた事があったけど、今は内蔵ADCは普通になってしまった。 今更ですが、
ChaNさんのFFTライブラリを移植してシミュレータで検証してみたら、
一連の処理で、
atmega32@16Mhz (一部アセンブラ) 16msec
atmega32@16Mhz (C言語のみにポーティング) 68msec
PIC18@16Mhz (C言語のみにポーティング) 200msec
PIC16@16Mhz (C言語のみにポーティング) 420msec
と、AVRの方が圧倒的です。
ただ、PIC18は、64Mhzまで動くので、そうすると、
使えなくも無い、ということになってしまうんです。
PIC16は、乗算器ないから圧倒的に不利。 PICもAVRも同じMicrochip配下なんだから仲良くしようず >>337
sin,cosテーブルと、窓用の配列を用意して、演算していくけど、
PICは、インデクスアクセスがavrに比べて弱い、特にプログラム領域に確保したテーブルアクセスは
avrの方が効率よくアクセスできる。
avrでもアセンブラが優位だったのは、複数配列のアクセスのときに、C言語では、
毎回インデクスを再計算してしまうケースがある。
アセンブラでは、固定小数点演算で、fmuls命令を使うのと、汎用レジスタで一時的な計算結果を
うまく使いまわして、オーバーヘッドを防いでるのが早い理由かな。
クロック速度でなく、ステップ実行速度が同じであれば、PICが優位なケースもあり、
適材適所感がありそうです。 結局、一つの命令にかかるマシンサイクル次第なわけで、CPUのパフォーマンスを
語る上でクロック周波数なぞ参考程度にしかならない PICとAVRのコアの違いは、グローバルレジスタ方式とワーキングレジスタ方式の
差によるものが大きいと思う。
命令16ビット固定長という制限があるのに、
32個のグローバルレジスタ方式を採用したAVR設計者の方針に、
AVRファンの私としては感謝したいw
例えば、8ビット即値命令(LDI R31,$FFなど)は32個のレジスタ指定で5ビット、
即値で8ビット使うので、残りは3ビット、つまり8種類の命令だけでコード空間を
使い果たしてしまう。
もちろんそんなCPUは有りえないので、
あーでもないこーでもないという制約だらけの状態にはなっているが、
この方式の違いが、結果的にPICに対するAVRのアドバンテージにつながっているのでは?
命令コード24ビットのAVRを出してくれれば、これらの命令上の制約も大分解消されて、
ますます使いやすくなるだろうが、残念ながら出ないと思うw
以上、Cプログラマには関係の無い話しでした。 そうだよ、制約がイヤで、まず最初に
RESETピンに大容量のCや外部リセット回路がつながっていても、
SCKピンやMOSIピン、MISOピンに何がつながっていても、
(たとえ5VやGNDと直結されていても)書き込みOK
というシリアル・ライタを作った。 てかAVRはArduino需要やろ
あれが出る前は特に日本での認知度はH8とPICやった
Microchip自体がPICの改良諦めてる状況やし >>349
その理屈だとArduinoに使われてる商品だけってことになっちゃうな。
さらに特需と言えるほど広まってるかい?君の周りの人が皆Arduino買ってるかい? >>348
今まで2回ほどライタの画像をアップしたし、
特に2回目は、このジャンパーは5V/3.3V切り替えで、
あのジャンパーはSPI/PDI切り替えで・・・などと詳しく書き、
オプションの量産書き込み用ZIP(ゼロインサートプレッシャ)ICソケットボードや
ICクリップ方式書き込みアダプタなども紹介した記憶がある。
画像探したけど見つからないし、勘弁して下さい。
昔の外部メモリ用CPUで使われていたROMエミュレータからヒントを得て作りました。
原理は簡単です。 PICもArduino対応してくれたら使うんだけどな MEGA328あたりはあるどぅい〜の需要な気はする >>352
確かに私(351)が作ってアップしたものですが、それはライタではありません。
懐かしいな、一時期、I2CやSPIに凝っていた時期があって色々作りました。
最後に作ったのはmega328を2個使ったI2C/SPI通信モニタで、
トリガ条件を逆ポーランド記法で組み合わせて色々演算できるように工夫した。
https://i.imgur.com/32qxbLz.jpg
だけど、パラレル液晶や4桁7セグLED数字表示器用のI2C/SPI/UART変換器や
I2C/SPI通信モニタなどは完成して動作確認後、押し入れの棚に入れてから
一度も使った事がありません・・・。
ここは反省した方がいいのかな?w (ついでに連投)
そうそうI2Cと言えば、現在進行中で制作しているものはtiny2313と
秋月の小型液晶AQM0802AとAitendoのJJY受信モジュールを使用した
JJY受信+電波ブースターです。
ブースター部の製作と動作確認までは順調に進んだのですが、
予想外のトラブルがいくつか重なったり(5V-3.3Vレベル変換ICが壊れていたとか)、
tiny2313をI2Cマスターで使うのは初めてだったりで、
受信した0/1/マーク信号を液晶に表示するまで時間がかかってしまいました。
(旧ATMELのtiny2313の資料のTWIの説明は分りにくいぞっ!
疑心暗鬼になってしまって、
本当に出力がオープンドレインになっているかの確認までやってしまった)w
これは完成したら押し入れにしまい込まないで、ちゃんと使い続ける予定です。
家族から、最近電波時計の時間がずれて困る、とクレームが来ているので。
自分の好き勝手にやれる、趣味のプログラミング、ハード製作はとてもとても楽しいです。
止められまっしぇ〜んw PIC16,PIC18を常用してるけど、スタックは、基本CALLでしか使えないので、
パラメータをPUSH/POPするような、C言語には向かないんだな〜としみじみ。
printf的なものを実装しようとして気づいた。
picのcoreだけでも、avrが仕込まれたらどんなに便利なんだろう。。。。 >>355
凄ぉーっ!
こんなの作れるなんて、羨ましいし畏れ入ります。
>>356
JJYブースターも自分はAmazonで買おうかと思ってたけど自作なんて、これまた凄い。 >>357
PIC18Fならスタックは普通に使えまっせ。
データスタックはPOSTDECn, PREINCnというレジスタが何のためにあるのか考えれば分かる。
コールスタックにもデータを積むこともできるけど、これは12ビット幅でちょっと使いづらい。 >>360
最近のPIC16Fでも MOVIW,MOVWIで同様のこと出来るみたいですね。 >>363
出来る出来ないで言うのならば
勿論、出来ます! >>363
ATMEGA328Pに23LC1024(1MのSRAM)なら付けたことあるよ。
https://i.imgur.com/gTxFMS1.jpg
入手も容易、接続も簡単、制御もお手軽、値段も高くない。
https://i.imgur.com/Kriy1ef.jpg
この時はグラフのフレームバッファ領域に使ったけど、実用的なスピードは出たよ。
気をつけることは、ATMEGA328Pのメインメモリそのものが増えるわけではないことと、シリアル接続なのでアクセス速度がそんなに速くないこと、使い方によってはSPIを占有しちゃうことかなぁ。
お金とプリント板の領域に余裕があるのなら、SRAMの大きいATMEGA1284Pにした方が幸せだとは思うよ。 メモリいる用途なら素直に32bitにしたほうが楽なんだよね。 >>367
なるほど、この場合
SPI->I2Cという
フレームバッファからのディスプレイへの書き出しに、連続read/writeが出来るからですね。
もし、ディスプレイも spiだったら、
spiが2本あるか、メインメモリで大きめのバッファを格納しない限り、
毎回アドレス指定で、小さなバッファ単位の書き出しになり、パフォーマンスが出せませんね。 LEDの撮影のこと、色々と教えてくれてありがとう。
試行錯誤の結果、ホムセンで安かった塩ビの板を暫定的に乗っけました。
スマホの撮影だと、ホワイトバランスとかフィルターとかあまり弄れませんでした。
とりあえず動画
https://i.imgur.com/hp5V3rl.mp4
CLASS4の古いSDカードに動画ファイルを入れて連続再生すると、特に頑張らなくても40fpsくらい動きました。
ただ、標準のsd.hの仕様なのかよくわかりませんが、遅い時がありますね。
フォルダー内のファイルが多くなってくると、後半に入れたファイルを見つけにいくだけで0.5秒もかかります…
一度、オープンしちゃえば素早く読み書きできるのですが。
>>369
おっしゃる通りです。
今回もSDカードから連続読みして、WS2812Bへだらだらと書き込んでます。 外から入った光はほとんど吸収して中からの光は出てくる
液晶みたいな真っ黒LEDを売ればいいのにといつも思う 表示を隠す1ドットの液晶は欲しいな
光らない表示のスイッチは離して実装できないし・・・ ATMEL時代からLegacy扱いだったんだから当然だろう。
AVR8とは別物だ。 そのMicrochipさんがAVRに注力しとるではないか MicrochipがPICのみにしたかったらコスト競争でAVR潰しただろ
吸収合併したってことは欲しかったんだよ、AVRが ARMだけがほしかったというのが本音だろうね・・・・
他は価格的に魅力がないからな〜〜〜〜 ARMが欲しいだけなら、わざわざAtmelからマイコン事業を買う必要もなく、ARMと契約すれば済むわけで。
(実際Microchipは特殊用途向けに、ARMマイコンを出してたこともあるし) コアだけで1チップマイコンが成り立つなら、それもあると思うが。(反語) PIC32をMIPSにしたことを後悔してるんだな。分かるよ。 実際はAtmelが他社に買収されそうになったのでMicrochipが乗り出しただけだが
Dialogとの合意後に“横やり”:
Microchip、Atmelに38億ドルで対抗買収を提案
http://eetimes.jp/ee/articles/1512/21/news056.html
Dialogとの合意は破棄の可能性も:
Atmelの買収、Microchipが優勢か
http://eetimes.jp/ee/articles/1601/18/news071.html SAM7EをPIC32CZとリネームしているようですね。 PIC32(MIPS)を改良できなかったMicrochipの不甲斐なさよ ■ このスレッドは過去ログ倉庫に格納されています