【米粒から】PIC専用のｽﾚPart17【32ビットまで】

>>946
CCS-Cは・・・

・数式の変形最適化や処理のフロー最適化は得意だが、生成コードの局所最適化が苦手
・全般的に最適化がPICCより下手なので、生成するコードはPICCより大きい
・生成コードにバグがあることが多いので、仕事で使うのには不向き

ってとこ。
とは言いつつ、PICCが高いのでCCS-Cを仕事で使ってるが。バグに苦しみながら。

>951　セミナーで中国のトレーナーの人が　ICD2LEｶﾞｱﾚﾊﾞPICKit2ﾋﾂﾖｳﾏｾｰﾝ　っていうから売り飛ばしたのに

PIC16F876とPIC16F886でPICを初めたいと思いRCDライタ ver2.3を作ったのですが、
本家では「黄色のN/A(=RCDライタでは書き込めない)」で(10)(11)(12)の注釈付きですが
　http://feng3.cool.ne.jp/rcd/
ハーフマットの販売のページでは「書き込める」となっています。
　http://halfmat.ocnk.net/product/52

これは、ハーフマットで改良品が売られているのでしょうか？
それとも物は同じで「プログラムだけなら書き込める(EEPROMはNG)」ということでしょうか？

そこの掲示板に質問したほうが的確な回答がもらえそう。

秋月で買ったgwsサーボを、pic16f88で動かそうとしてるんだけど、

最初、試しにpwm命令で7.8kHzをサーボの信号線にかけたりしてたからか、
その後、タイマ割り込み使ってパルス周期２０ｍｓ(50Hz)パルス幅０．８〜２．３msで動かそうとしても動かない（サーボに５ｖかけると最初だけ少し動く）
サーボって信号線に高い周波数かけたりするとやっぱり壊れるものなの？

>>953
まぁ、どんな機器も「推奨動作条件」と「実力」は別だからな。
「ICD2LEｶﾞｱﾚﾊﾞPICKit2ﾋﾂﾖｳﾏｾｰﾝ」も当然、推奨動作条件の範囲内が前提だっただろう。
それを超えた領域で動作しなくても、それは仕方がない。

>>930,932
古いの読んでました・・・ まさか間違っているとは。
ちゃんと最新版チェックしないとだめですね・・・

一応今は、シミュレートできればいいと思って、SPBRGを0にしましたが、
値を増やしてみても、ロジアナのU1TXビットに変化がありませんねぇ・・・
そもそも、起動時から、ずっと0のまんまになってます。


とりあえず実際に回路組んでみて、データが送られてきているかどうかをチェックするしかないですかね?
一応MPLABのv7.6とv8.0両方で試してみたのですが、駄目みたいです。

>>954
本家の表を、もう30分ぐらい見つめると、真意が浮かび上がって見えてくると思う。

>>942
DTMとかそっち方面はよく知らないんで、勘違いしてるかもしれないけど・・・

そのステップデータに似たものがおそらく「内部データ」と呼んだ形。
なんかのツールなりスクリプトなりで変換はできそうだけど、そんな
高度な音楽をやるわけじゃないので、ソースファイル内で収めておきたい。
そんなところです。
文字列いじれないなら、単音ずつ変換させるとします。

mml<->ステップの相互変換ツールも作ってたから、
１小節192でデータ作ってみたら?
MMLからステップデータの変換はwindowsコンソールに任せてさ。
MMLよりステップデータの方が、現代コンピュータとの親和性は良いぞ。
音符は最悪だけど(w

>>958
俺もいろいろ試してみた。
SIM Uart1ウィンドウには送信データ（文字）が表示されるから、プログラムが
動作してることは間違いないんだが、確かにU1TXでもRB2でも信号は表示されないね。

forum.Microchipでも、同様の質問に「シミュレーションはレジスタレベルで、ピンの
挙動はシミュレートされない」みたいな回答があった。
http://forum.microchip.com/fb.aspx?m=206224

楽譜系のソフトやってたことあるけど、音符単独で見たら
音程どころか、長さすら決定できないのよねん。

http://www.nabble.com/Debian-templates-for-dsPIC-build-toolchain-3.01-td12265748.html
sdccってあるけど、pic30系統のgccがある。
dspic30,33,pic24をサポートしてるようだ。(未確認）
しかしlinux(debian)ときたもんだ。
そのうちcygwinでビルドしたようなのがでてきてもおかしくない。

まぁmicrochip謹製のgccだけど
includeファイルとかはないらしいのでwindowsから持ってくるという離れ業。

ubuntuだね正確には

964=965ですorz

>>964-967

>>962
確かPWMのシミュしたときは普通に波形で出た気がする

>>969
訂正：
>forum.Microchipでも、同様の質問に「シミュレーションはレジスタレベルで、ピンの
>挙動はシミュレートされない」みたいな回答があった。
↓
forum.Microchipでも、同様の質問に「『USARTの』シミュレーションはレジスタレベルで、ピンの
挙動はシミュレートされない」みたいな回答があった。

>>970
訂正：
>forum.Microchipでも、同様の質問に「『USARTの』シミュレーションはレジスタレベルで、ピンの
>挙動はシミュレートされない」みたいな回答があった。
↓
forum.Microchipでも、同様の質問に「『UARTの』シミュレーションはレジスタレベルで、ピンの
挙動はシミュレートされない」みたいな回答があった。


何度もスマソ・・・OTL

PIC24F活用ガイドブックって本買ったんだけど
Eagleで描いたパターンがCD-ROMに入ってると思ったら
全部pdfだたーよ。Eagleだったら手持ちの部品に合わせて
書き換えようと思ったのに。

いますぐトレースしてうｐするんだ

いますぐコスチューム着用してドビュッするんだ。

ここ数年はブレッドボードで試作ﾊｱﾊｱ→完動ﾄﾞﾋﾟｭｯ→満足してやめる
みたいな自慰行為で完結してる

>９７５　半田付けすると熱で壊しちゃうもんな

熱で黒こげを転々と作ることを、「パンダ付け」というらしい

温調コテくらい買え

>>962
シミュレーションできないんですかー・・・
受信の方をSettingから適当な値送れるようなコト書いてあったので、
動いてくれることを期待してたのですが・・・

有り難うございます!
ハッキリできないとわかって、逆に安心しました。

ショートや逆接はあるけど熱で壊したことは無いなあ
どれくらいコテ当てると壊れんだ？

PICでC++って使えないの？

テスター棒の先でパチッとな…

ライターであぶられながらハンダ接続されて死んだ555は悲惨だった……。

>>981
gpp等でC++ソースをCにトランスレートすれば使えるんでない？
それか、16bit/32bit PICのコンパイラはgccだから、そのままC++ソースが食えるかも。
（ダメならC++コンパイル可能なバージョンのgccにコード生成部を移植・・・）

次スレ立てました。
センス悪いスレタイで申し訳ない。
http://science6.2ch.net/test/read.cgi/denki/1202041038/

>>983
誰でも見られるところへうｐして。


ところでまだMMLがらみをグズグズやってるんだが、MPASMのリスティング
ファイルを見て愕然とした。
dt 60/10,(55+5)/10,((55/10)*10+5)/10,55/10+1/2　の結果が
3406　3405　3405　3405　ってどういうことよ。
後半２つは四捨五入のつもりだけど、できてない。でもまぁ、計算ごとに
切り捨ててると見れば分からんでもない。けど、２番目は変だろ。

スクリプトでも書くか・・・　(´・ω・｀)

>>986
55+5=5A
5A/10=5

radixかー

しかし切り捨てはされるようだ。
四捨五入はもちろん、音長の計算は怖くてできんな。

>>988
まぁ、切捨てと分かってるんだから10で割る前に5を足しとけばいいんだけど・・・
MPASMであんまり変な計算をさせるのも気が進まないよね。

> 変な計算
小学校で習う四則演算なんだけど・・・

>>990
まぁ、10進数からして変な体系だとおもうけどなぁ。
難易度にかかわらず得手不得手はあると思うよ？

四則演算が不得手ならPICなんてやめちまえ

MMLって解像度96か192がデフォじゃない?

MML2ASMみたいな奴作って、データ作成はWindowsでやらせたら?

MPASMのradixデフォはhexで 演算は4ﾊﾞｲﾄ長整数な。
小数は扱えんから +(1/2)なんてのも無意味だぞ。

秋月で、16F887の取扱が始まった。

埋め

埋め

埋め

次スレはここ↓

【得意分野は】PIC専用のｽﾚPart18【書き込み器ｗ】
http://science6.2ch.net/test/read.cgi/denki/1202041038/

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。