Tessék itt a forrás : Bővebben: Link

Mintha ebben a rev-be nem akkora számot töltenének, mint ami nem fér bele, ugye?

Ezen gondolkodtam én is próbálgattam más típusú változókkal is de nem nagyon akart összejönni. változók értéke Igazából nincs tippem már mit próbáljak ki

Ezen nem "gondolkodni és próbálkozni" kell, hanem pár alapvető dolgot megtanulni. Kezd mindjárt a változók típusával. Aztán mielőtt változtatsz egy kódon, meg kellene érteni a működését. Azután ott a szimulátor, azonnal kiderül, ha hibás típust használsz és le lehet mérni a kód futási idejét is, hogy két megszakítás között le tud-e futni.

Nem világos, hogy mi "csordul túl" nálad. Elfogy a RAM, kevés lesz a programmemória, vagy a fordításnál közli a Mikroc, hogy overflow van?

Bár igazából mindegy. A Mikroc fordítójának jellegzetes logikája van. Ha kicsi a program, akkor akár egy bájtba is betöltheted két float hányadosát, mert fel tudja használni azt a 20 segédregiszterét, amikben dolgozgat. Ez kicsit megtévesztő, de rendes dolog tőlük, hogy beleírták. Az eredeti, pár soros programban nincs is baj. Ha nő a program, akkor ezeket inkább stack és egyéb gondok tárolására használják, úgyhogy azt a változót kell rendesen deklarálni, amibe az eredmény megy, mert azt fogja használni a fordító a résszámításokhoz is. (Egy 4 bájtos osztáshoz jó sok számolgatás kell assembly-ben.)

Tehát a "rev" legyen long, de inkább float, az a biztos. Persze csak akkor, ha van elég RAM. Ha nincs, akkor kénytelen leszel szétbontani a számítást olyan részösszegekre, amik beférnek 2-4 bájtba. Az is gond, hogy minél nagyobb számjegyekkel végzel aritmetikai műveleteket, úgy pakolja be a kódba a különböző, egyre nagyobb terjedelmű, számító rutinokat. Azok szintén használnak segédregisztereket, így gyorsabban fogy a RAM, mint a fagyi a gyerekzsúron.

Úgy kell felépíteni a programot, hogy optimális legyen a RAM allokáció. (Ezért is jobb assmebly-ben is venni pár leckét.) A PIC nem számítógép, be lehet ugyan írni, hogy anégyzetszerbénégyzetpergyökkettő, a fordító meg is kísérli a feldolgozását, de elfoglalja az összes helyet. Ha meg már egyszerűen nincs hova bepréselnie 4 egymást követő bájtot, jön a hibaüzenet.

Másolom a hibaüzenetet a szimulátorból : PC=0B0BA4 Stack owerflow is device forcing reset.
Szabad ramom 90% szabad rom 85% fordítás után ennek csak elégnek kell lennie.. de akkor megpróbálom azokkal a változókkal amiket említettél.

Na, akkor már tudjuk mi a hiba. A Stack overflow azt jelenti, hogy túl sok egymásba ágyazott programhívás van a kódban. Valószínűleg a nagy osztást számoló rutin belépése tette be a kaput.
Át kell dolgozni a programot. Sok az elágazás. Utána talán menni a fog a számítás az eredeti módon, de azért a rev legyen legalább u long.

Értem, igen tuti hogy ez a nagy számítás okozza a hibát mert amint csökkentem az értékét akkor működik. Rendben megpróbálom úgy.

Megoldottam, fogtam addig módosítgattam a kódot amíg a frekvenciát pontosan meg nem kaptam, egy plusz függvénnyel pedig felszoroztam a pillanatnyi frekvenciát 60-al így megkaptam a percenkénti fordulatszám eredményét így már jó.

Sziasztok!
Táblázatkezelési problémám van. A klasszikus call... addwf PCL,f RETLW.. -vel kb 200 bájtot sikerült kiolvasnom, majd a program elejére ugrott. Lapváltás még nem volt, de a PCL már FF-re váltott. Ezt még valahogy értem. Aztán megpróbáltam a következőt:
sin: movlw d'0'
movwf index
movlw HIGH (TABLE_START)
movwf PCLATH
movf index,w
addlw TABLE_START
skpnc
incf PCLATH,f
movwf PCL
nop

TABLE_START
retlw ...
Ez viszont az első retlw után a program elejére ugrik, W-be még betölti az adott értéket.
(ezt az internetről bányásztam)

Olvastad?

Régebben olvastam és most átfutottam, de nem látom a hibát. Segítenél kinyitni a szemem?
Megpróbáltam a "GetTabData" szerint még egyszer, de ugyanaz az eredmény.

Köszönöm... újra végig mentem rajta most már jó. (Remélem nem felejtem el megint.) Az a CALL... nagyon kellett bele.

Idáig még nem használtam semmilyen kommunikációs portot (nem is értem hogy úszhattam meg eddig), de most mindenképp SPI-n kellene vezérelnem egy A/D-t és egy D/A-t. Épp a nyákot tervezem az áramkörhöz és kérdezném hogy ugye jól kötöttem össze őket a PIC-kel?
(A kapcsolási rajz még nincs kész, ezért a többi részt ne tessék nézni.)

Az MCP4922 adatlapja azt írja, hogy az adatbeírás a #CS bemenet lehúzásával kezdődik. Utána 16 bitet kell beléptetni (bitek sorrende és szerepe az 5-1. ábrán) és, amiből az első 4 bit konfigurációs bit, a további 12 pedig adatbit. Ezt követően a #CS jel magasba húzásakor íródik be a megfeleő regiszterbe az adat. A kettős bufferelés miatt azonban az adatregiszterbe írt számmal arányos jel nem kerül ki közvetlenül a kimenetre, ebbe még az #LDAC és az #SHDN bemenetek állapota is beleszól.

A hardveres Shutdown mellőzhető, az #SHDN lábat magas szintre kell húzni.
Az #LDAC bemenet arra való, hogy az A és a B DAC kimenetét szinkronizáltan lehessen frissíteni (az #LDAC bemenet lehúzásakor íródnak be az előzetesen beállított adatregiszterek a két DAC-ba). Ha erre nincs szükség, akkor #LDAC egyszerűen földre köthető (alacsony szint kell neki), s ekkor megszűnik a kettős bufferelés.

A #CS bekötése nyilván nem mellőzhető. Több eszköz is ráköthető az SPI buszra, s az egyedi #CS vezetékek választják ki, hogy melyik reagáljon éppen (lásd: 6-1. ábra).

Megjegyzés: a fentiekben a # jel a felülhúzást jelöli (alacsony szintnél aktív jel).

Mi anno a negált jelszinteket "/" karakterrel jelöltük, mert az még az írógépen is megvolt...

Köszönöm a válaszokat, akkor így jó lesz?

Ebből én nem látok semmit. Ti igen?

Nyilván látnak mert az előző rajz is ekkora volt. Nyisd meg új lapon és akkor valamivel nagyobb lesz!

Valahol meg '!' jelet használnak erre. (mármint az alacsony aktív jel jelölésére)

Valamivel jobb, de én így se látom a feliratokat, csak a vezetékek számát tudom megszámolni és szerintem a legutóbbi válasz is így született, nem azért mert a rajz olvasható. Ilyen nagy probléma feltenni egy normális képet, vagy pdf-et?

Dehogy probléma. A rajzom nagyobb felbontású, csak a HE lekicsinyíti sajnos. Viszont a pdf jó ötlet, íme:

A fájl nevére kattintva, nagyobb lesz, tádá...!

Így már tökéletes! A bekötés szerintem is jó.

Micsoda műhelytitkok! De azért úgy is határeset, a pdf szépen nagyítható.

Szia! Mire gondolsz? A 'CS' vonalakra? Mert az SPI-re nem kellenek. A 'CS'-kre lehetne, de oda sem mindig indokolt, attól függ milyen problémát okoz a bekapcsolás időtartama a perifária és a PIC között. Általában nincs gond, de van mikor jó, ha a lebegő engedélyező láb fel van húzva, annak ellenére, hogy a lebegés általában H szint.

Nem kevered az I2C-vel? Az SPI meghajtott kimenettel rendelkezik, ezért lehet csak egy eszköz engedélyezve a vonalon.

Az összes ki-bemenetre szerintem is felesleges, de ha több eszköz van az SPI buszon, akkor a CS lábakra én mindenképpen tennék olyan irányú húzást, amivel az inaktív állapotba húzódik. Azért, hogy ne történhessen meg a kontroller indulása alatt, hogy két eszköz is aktív CS szintet érzékel, és a kimeneteik szembekapcsolódnak.

Egyetértek, hasonlót próbáltam javasolni én is.

Sziasztok! Olyan, lehetőleg 2 irányú kommunikációs kapcsolatra lenne szükségem PIC-ek közé (2-nél több mcu) ahol a tápfeszültség 2 vezetékére van rámodulálva az Rx és Tx. Tudnátok valamit javasolni? RS485-tel valahogy megoldható lenne?