Mert nincs is ott. Ott az van, hogy a Carry-t beforgatja a 7. bit helyére, a 0. bitet meg átteszi a Carry-be. Az már a te dolgot, hogy mi legyen a Carry-ben a forgatás előtt.

Azért mert akkor még nem ismertem potyo beírását, azóta tudom.

Korábban csak simán az RRCF-et alkalmaztam és azt figyeltem meg, amit leírtam. Arra nem gondoltam, hogy a 7. helyen egy korábban bennmaradt Carry jelenik meg. Azt hittem, hogy ez a jobbratolás körbe-körbe mozgatja a biteket. (Az RRCF utasítás leírásánál nem emlékszemelőzetes Carry törlésre)

Mostmár világos.


Üdv
Ray

Az nem a 0. biten lévő 1-es, hanem a bent felejtett Carry!

Miért nem nézed meg hogyan működik az utasítás?

A potyo által mutatott példában az első sor a Carry törlése! Ezt miért hagytad figyelmen kívül?

potyo!
Igazad van, az általad írt utasításokkal sokkal rövidebb és egyszerűbb az egész. Az ADDWFC marha jó, nem kell nyüglődni a túcsordulással.

Kösz.

Az osztás is így egyszerűbb. Nekem a jobbra tolásnál (RRCF) a 0. biten lévő egyes megjelent a 7. helyen.
pl.
0010001 jobbra tolva az RRCF-el 1001000-at adott.

Ugyanazt az utasítást használva most meg nem. (Ki érte ezt?)


Üdv
Ray

Ezt megismétled az összes méréshez.

Adatlap 24.2 fejezet




Gondolom itt osztást akartál írni. Egy kicsit nyakatekert a módszered, az osztást mindig a felső bájt felől kell kezdeni.
És ezt ismétled többször, ha kell.

Tegnap este piszkálta az oldalamat ez az egész és egy kis időt fordítottam rá. Nem is olyan borzasztó. Valami olyasmit csináltam, amit pajti írt.

Az alábbi eljárásról van szó, jól gondolom?

1. Az összeadás az egyszerübb.
A két bájt neve: FREKI_L (alsó) és FREKI_H (felső).
Egyzserűen összeadom a FREKI_H-t a következő mérés FREKI_H-jával és ugyanezt csinálom a FREKI_L-el is. Ha a FREI_L-ek összeadása során túlcsordulás van, azt jelzi a STATUS-ba a C flag. Ilyenkor soron kívül növelem a FREKI_H-t eggyel. A FREKI_H mindig 10 körül szokott lennei, úgy hogy ez nem fog túlcsordúlni.

Mi a különbség az ADDWF és az ADDWFC között, mindkettőnél magasra álla a C, ha túlcsordulás van. Szmámomra mindkettő egyformán használható.



2. A kivonás macerásabb.
Jobbra tolom először a FREKI_L-t (RRCF), ekkor a 7. bit biztosan 0 lesz.
Aztán jobbra tolom a FREKI_H-t, ha a C magasra áll, akkor a FREKI_L 7. bitjét 1-re állítom. Ezután tekinthető úgy, hogy a számot elosztottam kettővel. Ezt megismételve az eredmény az eredeti szám negyed része lesz. (a tizedes számokat figyelmen kívül hagyva)

Üdv
Ray

Átlagolni, résztagonként is lehet. Tört részek miatt, esetleg nagyobb a hiba, de nem kell kettő hatványának lenni az átlag számának.

(a+b+c)/3 vagy ((a+b)/2+c)/2

üdv! proli007

Annyival egyszerűbb 18F-nél, hogy az ADDWFC utasítás figyelembe veszi az előző összeadás folyamán generált Carry flaget, így nem kell külön ellenőrizni, csak összeadni az alsó bájtokat ADDWF-el, az összes többit (jelen esetben csak a felsőt) ADDWFC-vel.

Hasonló megoldás létezik a kivonásra is SUBWFB és a SUBFWB utasítások képében, nem kell komplemenst képezni.

Így hirtelen nem néztem meg, de ugye van carry flag azon a PIC-en ?

Összeadás. Alsó byte-hoz alsó byte hozzáadás, hozzáadás után ha carry bebillent, felsőbb byte növelése eggyel, ha carry ismét bebillent, következő felsőbb byte incrementálása is, és így tovább. Ha legalsó byte-ot hozzáadtad, veszed a következő byte helyiértéket, és a megfelelő helyiértéken hozzáadod, aztán ugyanúgy végigpörgeted az átvitelt. Arra vigyázz, hogy ha adott picen kimondott increment is van, nem biztos, hogy kezeli a carry-t, ellenőrizd az utasítás készletét. Ott lesz a táblázatban a kezelt flag bitek felsorolása. Konstans hozzáadása célszerűbb.

Kivonás. A kettes komplemens az a dolog, ami rémálom szokott lenni. A kivonandó értéknek a komplemensét kell képezni, és legalsó byte-tól kezdődően ugyanúgy byte-onként végigmenni alacsonytól magas felé, és átvitelt is mindig végigpörgetni. Átvitel akkor van, ha hozzáadás közben az eredmény legfelső bitjén 0 -> 1 változás történt, ekkor ki kell vonni egyet az eggyel felsőbb byte-ból, szintén figyelni, és végigpörgetni az átvitelt végig. A kivonást legalsó helyiértékekkel kezded, és végighaladsz legmagasabb helyiértékig byteonként. Az a legfelső bit néha nem jó példa (pld 0x40-ból kivonni 0xff-et 0x41 lesz az eredmény - igazából hozzáadni 0x01-et), de a carry flag támogatás átlag működni szokott, vagy van kimondott kivonó utasítás is, és nem kell magadnak kettes komplemenssel hancurozni, szóval gond vele nincsen sok.

Ha valahol ostobaságot írtam, ugassatok le érte.

Pont ettől akartam megmenekülni. Nincs mese, bele kell ásnom magam ebbe. A dolgot bonyolítja, hogy alsó/felső bájttal is gyötrődni kell (agyilag).

Már az összeadásra is külön oda kell figyelni. Mikor érinti az eredmény a felső bájtot, mikor nem...stb. A két bájtos számból való kivonás még csupa homály előttem, de sebaj, ünnepek után - kellő lelkierőt és ismeretet gyűjtve - rászánom magam.

A mérések száma lehet a kettő hatványa, kb. négy mérés már elégnek tűnik, a nyolc meg már soknak.

Üdv
Ray

Igen-igen, ezt el is felejtettem mondani! Kösz, potyo!

Ajánlom figyelmedbe az ADDWFC utasítást, megkönnyíti az átvitel kezelését. Célszerű ha n kettő egész számú hatványa, akkor osztás helyett jobbraléptetést lehet használni.

Nincs ilyen rutinom, de gondolom azt Te is tudod, hogy az átlagolás összeadás és osztás műveletekkel elvégezhető.
Tehát össze kell adni n-adatot és el kell osztani n-el. Ennyi.

Nem tudna valaki egy olyan rutint v. macrot küldeni, amivel 4 v 5 szám átlagát lehetne könnyen-gyorsan meghatározni.

Egy mérés kiértékeléséhez kellene, mert a mérési eredmények eléggé szórnak és arra gondoltan, hogy az átlagot veszem mérési eredménynek. Még az is szóba jöhet, hogy a legalacsonyabb és a legmagasabb értéket lehagyom, és ezután veszem az átlagot.

A dolgot bonyolítja, hogy kétbájtos (alsó- és fölső bájt) számokról van szó.

Nincs kedvem sokáig görcsölni ezzel, azért kéne egy jó kis rutin.

Különben PIC18F4320-asban működne mindez.

Üdv
Ray

Megtaláltam az MPLAB Súgójában. Help Topics MPASM Assembler Index fülön megkeresed az EEPROM_Data_Byte bejegyzést, és ott írja.

Köszi!

Máskor volt erről szó itt a topikban, lehet, hogy innen van a 0x2100. 18F-nél a 0xF00000 címre kell tenni. De én sem tudom, hol lehet utánanézni.

Sziasztok!

16F877 -nél ORG 0x2100 cím után tudtam asm. -ben az eeprom területre adatokat elhelyezni, de már nem tudom honnan vettem a 2100- at. Nem tudja valaki hogy hol lehet ennek utánnanézni a 18F sorozatra vonatkozóan? Nem találom az adatlapokban..

Van egy eprom topic, abban van szó a Willemről.
http://forum.terminal.hu/viewtopic.php?t=26585

Nekem van Willem, szerintem a 4.1-est érdemes építeni, de ahogy Potyo is említette, az univerzális programozók szokszor nem annnyira profik az adott területen, mint egy kimondottan arra a célra szánt égető. Bár az 5 tűske (ICSP) a Willemen is ott van, sőt a táp és égetőfesz is elég sokféle értékre állítható, de azok a fránya szoftverek... Szóval a vas tudná, de az sw nem. Ezt neked kell tudni, hogy milyen típusokat szeretnél programozni, végülis sok típust ismer, de vannak hiányosságok. Ha végigolvastad a topicot, akkor tudod, milyen égetőket szoktunk ajánlani...

Willem előnye, hogy kezel több soros eepromot is, ami TV szerelőknek jól jön, de az se problémamentes. Egyébként nekem van olyan soros eeprom programmerem, ami 4700 féle soros eepromot ismer. Dobj meg mailel, ha érdekel.

Párhuzamos eprom TV-ben nincs, az inkább BIOS égetéshez kell.

Nem emlékszem, hogy a topikban valaki említette volna, hogy willem égetőt használna. Persze ettől még lehet jó, de az univerzális égetők általában nem szoktak annyira univerzálisak lenni. Ha pl. azt akarod, hogy az összes pic-et ismerje, akkor csak Microchip gyári égetőben gondolkozhatsz. Ez pedig nem fogja tudni kezelni a nem Microchip gyártmányú memóriákat. Persze lehet, hogy fizikailag ugyanaz az áramkör képes lenne kezelni, de mondjuk nincs hozzá való szoftver. Mondjuk más kérdés, ha írsz hozzá szoftvert a specifikációk alapján...

Köszöntök mindenkit!

Új vagyok itt a fórumon és a segítségeteket szeretném kérni. Látom nagyon pengék vagytok PIC témában (is). Én teljesen kezdő vagyok
ezen ezközök programozásában. Most jutottam el oda, hogy szeretném megtanulni. Ezt a topikot (és sok másikat is) már végig olvastam,
a javasolt szakirodalom többségét begyűjtöttem. A lényeg: szeretnék építeni egy égetőt, ami a PIC-eken kívül sok egyebet is tud égetni. Ez azért is hasznos, mert TV javítások kapcsán már jónéhányszor szükségem lett volna valamire amivel az epromot fel tudom programozni. Eddig mindig a kollégám égette nekem, de nincs már pofám ezzel zaklatni őt.
Szóval a willem nevű csodaáramkört szeretném megcsinálni. Ezzel nincs is gond, nem túl bonyolult cucc. Viszont lenne pár kérdésem és kérésem hozzátok.
Melyik PCB verziót építsem meg? Külföldi topikokban olvastam, hogy a újabb verzió nem feltétlenül jobb mint valamelyik előző. Számomra két szempont a lényeges:a megbízhatóság és a minél szélesebb körű kompatibilitás. Ilyesmi, hogy külső táp, csatolófelület, beállítások bonyolultsága, nem igazán számít. Írjátok le légyszi' a véleményeteket.

A winPIC800 szoftver bámelyik PCB verzióval működik? Ha jól értem a nagyobb PIC-eket csak ez a szoftver tudja égetni.

A willem szoftver 0.98-as verziója jó bármelyik PCB-hez?

Hát egyelőre ennyi. Bocs, hogy kicsit hosszúra sikerült, de szeretném a legjobb döntést hozni.

Üdv.: Laci

http://online.chipcad.hu/www/arak.aspx?group=0120


Pedig ha belenéznél egy ethernet vezérlővel szerelt pic adatlapjába, akkor látnád, hogy mi ez a szokásos interface...

Oké, bocsi a lamerkodásért, abba fejezem, csak még egy uccsó OFF kérdés erről.

Az a bizonyos "szokásos interface" kiskereskedelmi értéken kb hol mozoghat árban. Tudsz erre tippet adni ?

Ha jól tévedek egy ethernet phy vezérlő, és egy kis trafó, amit gyakran egybe is építenek némelyik RJ-45 csatolóval, plusz egy szűrőkör, amit szintén egybe szoktak vele építeni. Többet megtudnom nem sikerült róla.

A 16 bites adatbusszal rendelkezők között nincs 14 bit széles programmemóriával rendelkező példány

Azoknál, ahol a programmemória 14 bit széles, ha olvasod a területet, akkor a felső bájt két felső bitje nullát fog adni, mert fizikailag nem létezik az a két bit a szilíciumban.

De tényleg ideje lenne belenézned az adatlapokba, mert minden eddig feltett kérdésedre benne van a válasz, és nemis nehéz megtalálni.

Na ez egy kicsit probléma.

Azoknál a 14 bites típusoknál, amelyeknél írható a program memória, plusz az adatbusz is 16 bites, a felső két bit csak dísznek van ott ? Ha adatokat tárolok be, azok is csak 14 bitesek lehetnek ?

Semmi különös, a maradék 2-4 bit egyszerűen nem létezik, nincs beépítve. Olvasásuk nullát ad vissza minden esetben. Az adatlapokat ajánlom egyébként megtanulmányozni, ott a blokksémán fel van tüntetve, hogy pl. 2kx14 programmemória. Ez azt jelenti, hogy 2k utasítást helyezhetsz el benne (persze leszámítva a kétszavas utasításokat).

Program memóriára azt látom ott 64KByte.

16 bit széles opkódos piceknél az gondolom 32KWord, de 12-eseknél átlag hogy megy ? A fentmaradó 4 bitet leszemetelik későbbi kompatibilitás címén, vagy szoros illesztéssel 48KWord ?

Ja igen, a 14 bitesek-re meg végleg furán nézek ezügyben.

Nem, a Harward architektúra miatt az utasításkészlet továbbra is többféle szélességű. Bár a jelölés egy kicsit logikátlan: 18F-nél 16bit széles a programmemória, 16F-nél és egyes 12F-nél 14bit, a többi 12F-nél és 10F-nél 12bit széles. A 8, 16 és 32bit az az adatbusz szélességére utal.

Köszönöm a gyors választ. Egy következő noob kérdéssel hálálom meg.

A belinkelt katalógus lapon 8 bites architektúrás pic-ek vannak. Ismereteim picekről kicsit régiek. Akkoriban még 14 bitesek voltak. A bitszélességeket azóta kompatibilizálták, és fixen 8, 16, 32 (ez az egy még fejlődőben van gondolom) bitesek lettek utasításkészletre is ?

Vannak picek beépített 10Mbit-es ethernet interfésszel

Mondjuk azt nem tudom, mekkora feszültséggel hajtják meg az utp kábelt, de szerintem kicsivel. Ha nagy a feszültség, az nagy áramot is jelent. De a szokásos interfészt kell megépíteni trafóval, mindennel együtt, akkor nem kell a feszültséggel foglalkozni.

Szoktak PIC-kel hálózatot illeszteni ? Pld egy RJ-45-ös csatolóra gondolok itt, és UDP szabvány megvalósítására.

Eleférhet ez egy PIC-ben, vagy valami nagyobb teljesítményű cuccos fog kelleni hozzá ?

Ja igen, még annak sem néztem utána, mekkora feszültséggel hajtják meg az utp hálót. Biztos az sem kevés.

Közben mégis kigondoltam valamit. Persze csak ha nem gond, hogy a bitek nem egyszerre változnak:

Ennél csak bonyolultabb mód van(bitenként vizsgálni a kivinni kívánt tartalmat és BxF-el billegtetni. Nem túl elegáns, de jól áttekinthető. Na meg hosszabb a kód is. Hogy lassabb e nem tudom, de hogy nem egyszerre változik a port az biztos. Viszont nem függ a többi bit időközbeni változásától és mindegy melyi kbiteket kezeled.

Én a xorwf helyett iorwf-t használnék, de az is ugyanezt csinálja itt.

Igenis, moderátorúr, jók leszünk.

Akkor egy idevágó: hogy tudom a w regiszter felső négy bitjét kivinni egy port alsó négy bitjére úgy, hogy a felső négyet nem bántom? Most így csinálom, de remélem, vagy egyszerűbb mód.



Persze be is lehetne olvasni a portot, de akkor közben lehet, hogy egy interrupt megváltoztatná a felső négy bitet, és akkor rosszat írok vissza.

A nem a témába vágó kérdéseket kérem az offolós topicban folytatni!
(Eddig csak azért voltam elnéző, mert kivételes a helyzet!)
ON.

Veled már meglenne az elektronika, mint közös érdeklődési kör. Arra gondoltam, hogy a környezetemben levő lányoktól még sosem hallottam azt, hogy mit vacsorázzunk, én pedig ezt a kérdést fel szoktam tenni, szóval velük ez lehetne egy közös téma, de nem az.

potyo: ezt a vacsoradolgot nem értem. Szakács vagy, azért lenne közös érdeklődési körünk? Vagy, hogy főzök-e? (Persze, szoktam.)

A játszótéri anyukák arca szokott még érdekes lenni, amikor a gyerkőcök beszélnek a karácsonyról, és megkérdezik a lányom, mit szeretne. Első helyen most egy Barbie-vár van, de hozzá szokta tenni, hogy "és anya is biztos forraszt nekem valami szépet". (Csináltam neki pár LED-es villogó bigyót, rózsaszín, lila és hasonló LED-ekből.) Na, ilyenkor általában az anyukák lefordulnak a padról.

Sikerült jól szétoffolni a topikot, ígérem, igyekszem ezentúl a PIC-ekre koncentrálni. Csak jó, hogy megértő fülekre találtam, végre nem vagyok csodabogár.

Még ha a milegyen vacsira kérdés felmerülne, akkor legalább lenne közös érdeklődési körünk...

Amúgy meg hadd vágja ki a biztosítékot. Attól, hogy ők nem elég inteligensek hozzá, attól még te simán lehetsz.

Mondjuk én azért is járok erre a fórumra, mert itt hozzám hasonló érdeklődésű emberkék jönnek össze. Azt hiszem te is itt ragadsz mostantól.

Igen, a férjemet totál nem érdekli. Ő már úgyahogy elfogadta a dolgot, de az ismerőseim körében mindenki ki van akadva rajta. Talán azt még megemésztik, hogy elektronika, forrasztás, de a programozás az végképp kivágja a biztosítékot, főleg a pasiknál.

Üdvözlet!
Csatlakozom potyohoz, sajna a környezetemben:
Fiúneműek: Milyen telefont, milyen autót, milyen számgépet (játékra)...
Lányneműek: Műköröm, kozmi, mi legyen vacsira...

Legalább nem érezném néha magam marslakónak....

Nekem így látatlanban letszene. Viszont olyan lánnyal még nem találkoztam, akit érdekelne az elektronika, szóval esélyem sincs a gyakorlatban kipróbálni. Amúgy a férjedet gondolom egyáltalán nem érdekli az elektronika...

Köszönöm mindenkinek a segítséget, végül megcsináltam pontosan úgy, ahogy az adatlap írja, és voilá, tudok írni a kijelzőre. Persze most azt kéne, hogy összehasonlítom a kódot a régivel, hogy mit szúrtam el, de egyelőre nincs erőm hozzá, mert a végén már legszívesebben szétvertem volna az egészet. (Arról nem is beszélve, hogy a férjem egyre sűrűbben emlegeti a "hisztis tyúk" frázist, ami nálunk azt jelenti, hogy "drágám, talán egyik este velem is foglalkozhatnál, nem csak a hülye áramköreiddel". Tényleg, ti, fiúk hogy viselnétek, ha a barátnőtöket érdekelné az elektronika? Ez tényleg olyan kiakasztó dolog?)

Bocsánat, visszamenve 5-el előbbi hszbe beszerkítettem egy doksit.
Csak az nem szólt a programról....

Nem mindig értem ám mit akarsz!

Na, sikerült olyat betennem, ami nem ír a kezelésről semmit!
http://www.sparkfun.com/datasheets/LCD/HD44780.pdf
23.oldaltól...

Nekem is a megszakításos módszer szimpi, mert nem kér felesleges időt, de ez csak szervezési kérdés, a kivitel rutinjai nem sokat változnak.

Ha ismrekedik az ember a lelki életével, nekem a szájbarágós jött be, sztán
ha megvan a jó szekvencia, mindenki a neki teccccőt használja...
Ja! Az init elején vagy az oszcillátort, vagy a TMRX-t úgy állítom be, hogy a megszakítások kellő idővel köpködjék az adatot az LCD-nek.
A végén minden visszaáll, a kiíratáskor nekem a Busy figyelése jött be jobban.
Hát ezek az én szokásaim, sztán mindenki úgy, ahogy neki kényelmesebb vagy átláthatóbb.

3. Ezt megnézem már, mert lehet, hogy nem véletlen a dolog.

Hello Watt!
3: Nem is azt mondtam, hogy változóval kell, csak azt írja, mikor mennyi a min. idő, ami után küldhető a következő...
http://www.chipcad.hu/letoltes/adatlapok/ES16201REF.pdf
Egyébként a KIJINInél
MOVLW 0XXX
MOVWF OSCCON vagy TMRXCON
movlw 0xXX
movwf PortX
bsf LCDEN
btfss TxIF
bra $-2
bcf LCDEN
movlw köv.parancs
movwf PORTX
.
.
nekem egészen jól műxik
kicsit hosszabb, de jól követhető, mikor mit visz ki