Szintúgy. Szerintem elegánsabb módszer nem nagyon van.
Maskolni kell, majd shiftelni.

Sziasztok!

Épp a Topi féle cikkben leírtakat próbálom végrehajtani csak nekem van pickit2őm.Szóval csinálok egy nyákot amin rajta van a 877, meg az oszcillátor(20Mhz) a két kondi és a pickit kettő lábkiosztása szerint kivezetem a picem lábait hogy összekössem!
1 = VPP/MCLR
2 = VDD Target
3 = VSS (ground)
4 = ICSPDAT/PGD
5 = ICSPCLK/PGC
6 = Auxiliary --->csak ezt nem értem

szóval így jó lesz?Mplabból tudom majd debugolni?

Köszi

Igen, úgy jó lesz. Az AUX lábat normál esetben nem kell sehová bekötni. Azt ne felejtsd el, hogy a NYÁK-odra a PIC tápfeszültségére a VDD és VSS lábakhoz minél közelebbi csatlakozással tegyél egy 100nF körüli hidegítőt! Természetesen a debug is menni fog.

akkor is ha a kitről etetem egyelőre?Mármint a két hidegítő=kondi(bocs de "analfabéta vagyok még)

Az attól függ. Ha a fordítás pillanatában ismert az érték, akkor a fordító simán behelyettesíti a megfelelő értékeket, és ezesetben mindegy a dolog. Ha viszont menet közben kell, akkor vagy az únió, vagy a pointer+castolás adja a legoptimálisabb kódot, mégha ez nemis túl olvasható.

Itt azért emeljük ki, hogy ez csak a CCS fordítóban működik. A legtöbb fordítóban nem létezik bit tipus, a legkisebb adat, amit visszatérési értékként egy rutin tud adni, az egy bájt, vagyis az (unsigned) char tipus. Annál pedig nem mindegy, hogy ~ vagy ! jelet használunk, mert előbbi minden bitet ellentétesre fordít az operandusban, míg utóbbi azt vizsgálja, hogy nulla vagy nem nulla az operandus. Bit esetén ugyanazt adják, de egész bájt esetén már nem!

A Vss és Vdd vezetékek közé, a PIC megfelelő lábaihoz lehetőleg minél közelebb elhelyezve kell a hidegítés. A 877-nek mindkét oldalon vannak tápfeszültséglábai, mindegyiket kösd be! Az nem baj, ha a PIC mindkét oldalára kerül egy-egy hidegítő kondenzátor.

konstans? Hat beteszed ram-ba es az szetosztodik...

unsigned long szetosztva = 0x12345678;

Utana vagy pointerrel elered (mintha FSR eznel assemblyben), vagy unionnal hozod letre, es akkor egyenkent barmkor megcimezheted. Also 8 bitet meg castolassal

if ((unsigned char)szetosztva == 0x12) ....

es persze lehet ilyen csunyasagokat is muvelni:

if (*(unsigned char*)&szetosztva+1 == 0x34) ....

A jo hir, hogy makrokat lehet irogatni, pl:

#define byte(var,idx) (*(unsigned char*)&var+idx)

es utana mar egyszerubb es szeb a helyzet:

if(byte(szetosztva,1) == 0x34)

(most fordito nelkul csak ugy leirtam, ugyhogy lehet kihagytam zarojelet vagy valamit nagyon elirtam, de kb ez lenne a lenyeg)

köszi találtam itthon 100nF kondit!Akkor indul a szerelés!!

Bocsi, azt nem mondtam, hogy a 4 bájt az egy uns. char tömb négy eleme.

Tehat akkor egy ilyesmi kellene neked?

unsigned char cim[10];
*(unsigned long*)cim = 0x12345678;

A tomb az pointerkent is felfoghato - vagy ha nem ez kell akkor nem fogom most pontosan mi a kerdes. Be tudnad idezni hogy probalkoztal?

Ugyanebbe a cipőben járok én is..
Most jutottam el a Topi-féle cikk alapján a "ledvillogtatáshoz".
Azért tettem idézőjelbe,mert ugyan tudja a leckét mindkét progival,de legalább ötödrészre csökken a ledek váltási ideje a videon láthatóhoz képest...
Az okát nem tudom.
PIC877-04/p, Pickit2,és a kvarc természetesen 4Mhz.
Nem hiszem,hogy működni fog neked a 20megással,mert a progi is 4megásra van irva.

Hülyeséget irtam...
Helyesen:a ledek váltási ideje,legalább ötszöröse a videón láthatónak.
Elnézést kérek.

Akkor számoljunk egy kicsit. Ha jól gondolom, az alábbi kódrészlet van időzítésként abban a programban, amit próbálgattok (a "Nullától a robotokig" első részében lévő tesztprogi):



(A kommentek néhol nem konzisztensek a valódi értékbetöltésekkel!)

Most a nagyfokú pontosságot mellőzni fogom, mert az ugró utasítások pontos végrehajtási idejét és a változók újratöltésére vonatkozó utasításokat nagyvonalúan nem számolom. Ezzel nagyot nem fogok tévedni, mert ezek az idők jóval kisebbek a többihez képest.

Tulajdonképpen három egymásba ágyazott ciklusról van szó, a legbelsőben a ciklusmag 10db NOP utasítás. A legbelső ciklus 20-szor futtatja le ezt a ciklusmagot, az 200db NOP utasítás. A középső ciklus 255-ször futtatja a legbelsőt, azaz a 200db NOP-ot, így már 255*200db NOP-ról beszélhetünk. A legkülső ciklus a középsőt 100-szor futtatja, azaz végül 100*255*200 db NOP-ot fog végrehajtani a CPU, mielőtt eléri a szubrutin végét, a RETURN-t.

A NOP végrehajtási ideje a CPU órajelétől függ. A klasszikus, 4MHz-es órajel ütem azért kényelmes, mert egy NOP-ot a CPU 4 órajel alatt hajt végre, így a végrehajtási ideje pontosan 1us lesz. Ha az órajelet 5-szörösére, 20MHz-re növeled, akkor 200ns lesz egy NOP végrehajtási ideje.

Szóval 4MHz-ről járatva a fenti kódrészlet kb. 100*255*200=5 100 000us lesz, azaz 5.1 másodperc. 20MHz-en ennek az ötöde, azaz kb. 1 másodperc lenne ez az időzítés. Mivel minden kimenetváltás után ugyanez az időzítő rutin van meghivva, így a váltások között ilyen idők telnek el.

Ha már sikerült a progit elindítani, és az MPLAB-ból lefordítva is működésre bírni, akkor érdemes az időzítési konstansokkal eljátszadozni. Pl. kiszámolni, hogy milyen váltási időhöz mekkora konstansok kellenek, és ezt ellenőrizni a valóságban is.

Ha van 16F887-tel szerelt gyári 44-pin demo board, akkor az pl. egy jó feladat, hogy ezt a programot hogy lehet a 887-re átvinni, hogy a demo boardon fusson. Utána el lehet szórakozni a 887 belső oszcillátorával, különböző CPU órajelekkel.

Lemértem mechanikus stopperrel:egy "körülfordulásnyi idő" 60.5mp. A kvarc a névleges frekitől 100Hz-el alacsonyabb értéken rezeg,de ez akár a frekimérő hibája is lehet,vagy a mérőzsinór kapacitása is beleszólhat.

Akkor igy még nem kerek(legalábbis nekem).
Erről a progiról van szó: asm_forgo.zip

Érdekes megoldás, nekem nem jutott volna eszembe.
Én így oldottam meg:



A Tied sokkal tömörebb és egyszerűbb.

Én az "asm_elso.zip"-et szedtem le legelőször, mert az volt a cikkben az első példaprogi. Most megnéztem az "asm_forgo.zip"-et is, abban ugyanaz a DELAY rutin van.

Mi a kérdés? Nem 5mp körüli a lépések közt eltelő idő?

No, én úgy látom, hogy azért a Tied egy szempontból korrekt, a trudnai-é meg másik szempontból

Szóval azt mindenképpen szem előtt kell tartani, hogy a C fordító a több byte-os számokat hogyan ábrázolja: az LSB vagy az MSB van a kisebb címen.

A Te módszereddel biztos lehetsz benne, hogy olyan sorrendben kerül a memóriába, ahogy Te azt elképzeled. Ez akkor lehet jó, ha esetleg valami asm betétben felhasználod az értékeket, esetleg valami PIC-től független kommunikációnál (pl. az USB) kötött byte-sorrend kell. Ha nem úgy csinálod, ahogy beidézted, hanem trudnai módszerével akkor esetleg fordítótól fog függni, hogy milyen sorrendben kerülnek le a byte-ok a pufferedbe.

Ellenben az ő módszere a c-beli feldolgozásoknál lehet kényelmesebb, pont azért, mert rábízza a C-re, hogy hogy kezeli a számokat (még akár a hosszuk is változhat, lehet egy long 8 byte-os), talán rugalmasabban portolható a kód (bár erre itt most nem túl sok szükség van).

Nem. 60.5mp/8=7.56
Aztán lehet,hogy egyszer majd rájövök....

Hát, nagyságrendileg azért helyben vagyunk. A videón szerintem 1-2 tized két váltás közt az idő, azaz biztos nem ez a bazihosszú DELAY van a progiban, mert ez még 20MHz-ről is 1 másodperc felett lenne. Próbálj meg játszani a legkülső ciklus konstansával, az alábbi részletben:



Ha ezt a 100-at lecsökkented 10-re, máris kicsivel 0.7 másodperc felett lesz a váltások közti idő (mérésed alapján), ha 2-re csökkented, akkor pedig annak az ötöde, azaz 150ms körüli.

Valószinű nem jól vázoltam a helyzetet,igy azután nem is tudsz segiteni...
Amúgyis az egész problémának a kezdő pices topicban lenne a helye.
Tehát mégegyszer:nem az egyes ledek közti váltás idejével van bajom,az tényleg max egy tizedmásodperc(átugrik) hanem ez a hosszú idő úgy jött ki,hogy az első led "kigyulladásától" inditva a stoppert,egy képzeletbeli kör megtételének idejét mérve. A kör befejezésének pontja az első led ismételt "kigyulladásának "a kezdete.
Huhh...

Lehet neked kellene megoldani a kozep-kelet-azsiai problemakat Nagyon diplomatikus

Ami az LSB/MSB problemat illeti az valoban egy kenyes kerdes, legjobb lemakrozni es a makrokat felteteles forditasi direktivakkal letrehozni, tehat getMSB/setMSB ill getLSB/setLSB makrok tomkelege kellene, de ebbe lehet itt nem erdemes elmelyednunk.

Amire viszont van esely, hogy az eselest ha kicsit maskepp csinaljuk lehet a fordito jobban kepes optimalizalni - ha kepes egyaltalan. Tehat:



Persze ki kellene probalni mi az amit jobban le tud a fordito optimalizalni, de itt az lenne a lenyeg, hogy a shifteket esetleg a fordito felismeri, talan a mogotte levo eselest, igy atalakitja sima byte-os muveletekre. De meg kellene nezni ezt a valosagban is persze.

Az én példámban el tudom képzelni mi történik, azaz hogyan kerülnek kimaszkolásra a nem szükséges bájtok, és utána hogy shiftelődik bele egy 8 bites uns. char változóba. De a Te példádban ez már nehezebben megy.
Biztosan előbb belépteti a 8 bitet a változóba, és csak utána végzi el az és logikai műveletet? A legalsó sor 4bájtos éseléséről nem is beszélve...

Persze ennek kiderítésére a próba a legjobb megoldás, de most nincs a közelemben fordító, majd estefelé ráérek, mert füvet kell nyírnom, aztán a lefordított kódot is megnézem, mi lesz belőle és összehasonlítom a másikkal.

En mindjart sirva fakadok! Igaz nekem csak a student edition van meg, ami allitolag nem optimalizal, na de ennyire?!

Ez a Te valtozatod:


ez az enyem:

es ez egy nagyjabol optimalizalt valtozat, na de konyorgom, en ezt 4 utasitassal lerendezem assemblybol (18F-nel ugye, mivel MC18 csak 18F-eknel mukodik...)

ez ugye mind a 4 byte-ot mar atmozgatja, mig az elozo ketto a 4 byte-bol egy byte atmozgatasa, benne a shifteles ciklusban.

Ha meg egyszer nekem azt mondja valaki a C gyorsabb kodot general... Persze ha van olyan C forditoja valakinek amivel ennel nagysagrendekkel jobb eredmenyt lehet elerni, ne tartsa titokban!

A 4 utasitasos megjegyzesem vissza szivtam Ha nem stacken van a dolog akkor normalis kodot fordit:

Megjegyzes: az a NOP az nem NOP, mive a MOVFF ket programszot foglal le, csak a disassembly ilyen vacakul jeleniti meg.

Amugy ettol fuggetllen a shiteleses, eseleses kod ugyanugy vacakul forditodik...

Álljon meg a nászmenet! A fordító RAM-ba teszi a konstanst? Az egész kifejezés nem a fordítóban zajlik le? Én MOVLW és MOWF-el intézném el az egészet, a többit számolja ki a fordító!

Persze, hogy RAM-ba teszi, a 'const' csak egy megjegyzes a forditonak, hogy nem akarod modositani azt az erteket. 'rom' kulcsszoval beteheted ROM-ba is, de akkor meg ennel is hoszabb kodot general (tblrd-k miatt). Ha ez csak egy ertek, akkor #define -nal hozdd letre:

es akkor mindjart jobb a helyzet:

(Ez ugye mind a 4 byte!!!)

Ugyanaz fordul akkor is ha a pointeres megoldast valasztod:


Ez nyilvanvaloan azert van, mert nem RAM-ban tarolodik igy, hanem forditasi idoben kiertekelodik az osszes movelet (shift+ES) igy a fordito mar egy elore kiszamolt erteket tesz be a W-be...

Sziasztok!

Az AN1199 - 1-Wire Communication with PIC Microcontroller app note-al próbálkozok. Annyi különbséggel, h PIC18F4550-et és DS1820-at használok.
Állítgattam az oszcillátor beállításokat, mert az eredeti kódban nincs 48MHz-re késleltető rutin. Elvileg 24MHz-n megy. Viszont a DS1820 rom code-ját nem olvassa ki, csak 0-ákat, pedig azt állítja megtalálja (vagyis kap választ a reset pulse-ra).
Az 1-Wire data vonalat fehúztam 4,7kOhm-al, de 2,2kOhm-al is próbáltam. Elsőt a DS1820 adatlap írja, viszont néhány Maximos app note-ban 2,2k maxot ír.
Rá van kötve az 5V-ra is.
Kínomban már bootloader és egyéb usb-s firmware nélkül próbálom. Először önmagában működjön.
A read rom command mindkét slave eszköznél ugyanaz, ezért se értem, mi a probléma.
Mégse 24MHz-n menne a pic és rosszak az időzítések?
Előre is köszönöm mindenkinek a segítséget!

Én írtam egy programot, ami 4MHz-ről működött annakidején. Szóval a program legalább jó, csak az időzítéseket kell módosítani. Itt található:Link