Üdv!

csak annyi kéne hogy egy terminálról beadott számot szeretnék betenni egy regiszterbe majd visszaküldeni. A gond hogy a szám kétjegyű kéne hogy legyen


PL. ha elküldöm a 67 - et csak a 6-os kerül bele az EREDMENY - be
Az is gond hogy stringként küldöm. Azt szeretném elérni hogy a szám amit küldök számként kerüljön bele a regiszterbe. igy 255 - ig tudnék számot küldeni. Viszont ha decimalisként küldöma számot hülye karakterek jönnek vissza

Már megint egy kicsit jobbkézzel vakarod a bal fület. Így egyszerűbb és áttekinthetőbb:



Elmondom ez mit csinál:
-amíg nincs adat, addig egy végtelen ciklusban várakozik (ami amúgy nemigazán jó megoldás, mert megakasztja a program futásást, de mondjuk teszteléshez jó)
-ha jött adat, akkor azt beolvassa a W-be
-a W tartalmát átmásolja az EREDMENY nevű változóba
-meghívja a KULD alprogramot (hogy ez mit csinál, nem tudjuk)
-nullázza a VETT_KARR változót . Hogy ez mire jó, nemtudom.

Namost a fentiekben sehol sem szerepel az, hogy hol kerül be az adat a TXREG regiszterbe. Csak feltételezem, hogy a KULD rutin feladata lenne ez. A másik, hogy amikor vesz egy karaktert, akkor vajon hová megy a program? Ez szintén nem látható a kódból. Így pedig lehet, hogy bejön a 7 is, csak épp nincs ami lekezelje, és ott várakozik az RCREG regiszterben.

----------------------

Amikor terminalról küldesz egy számot, akkor valójában az ASCII kódját küldöd le. A kontroller ezt teszi be az RCREG regiszterébe. Ha neked a szám értéke kell, akkor a kapott adatból vonj ki 0x30-t. Tehát ha azt akarod, hogy a terminálról leküldött 193 számot a kontrollered egy regiszterében 193 értékként tárolja, akkor az első számjegy vételekor ki kell vonni belőle 0x30-t, majd megszorozni százzal (vagy annyiszor hozzáadni százat, amennyi a vett szám értéke). A következő számjegy vételekor ugyanezt kell tenni, csak 10-el kell szorozni (vagy annyiszor hozzáadni tizet, ahány a szám értéke). Majd végül hozzá kell adni a harmadik számj értékét.

Nem csináltam még ilyet, de a User Guide szerint én így deklarálnám a mutatót:



Van olyan is, hogy

de az 24 bites!

Lásd: C18 User Guide: ram/rom Qualifiers!

Üdv!

nem akar menni!
hülye karaktereket küld vissza. hiába vonok ki 0x30 - at

a CALL KULD csak annyit csinál hogy elküldi a W tartalmát

ráadásul amikor a VETEL3 cimke beli CALL KULD visszatér újra is indul a kontroller

Én nem azt írtam, hogy ha vissza akarod küldeni, ahhoz vonj ki belőle 0x30-t, hanem ha a pic valamelyik regiszterében számként akarod látni, akkor vonj ki belőle 0x30-t. Ha a terminál programban akarsz 6-ot látni, akkor a 6 ASCII kódját kell visszaküldened, ami 0x36.

Miért kell alprogramot hívna a küldéshez? Jelen esetben a küldés csak egy MOVWF TXREG utasításból állna, ami biztosan jó lenne. Így csak reménykedhetünk, hogy MOVWF TXREG és egy RETURN utasításból áll a KULD alprogram.

Amikor a terminálprogram leküldte a beírt adatot, akkor utána küld még egy sorvégjelet is. Ez 0x0D és 0x0A-t jelent egymás után. Akár ez is okozhatja a fura karakterek megjelenését.

De amíg nem látjuk az egész programot, addig semmi sem biztos.

Azt, hogy a kontroller újraindul, lebegő reset vagy lvp láb is okozhatja.

Bocsanat, nem kotozkodeskeppen, csak, hogy tanuljanak a fiatalok: Ezt valojaban ugy "szoktak" csinalni, hogy a valtozot amibe a szamjegyeket gyujtjuk szoktak 10-el szorozni es utana az erteket hozza adni ciklusban.

Hogy miert jo ez? Mert csak egyetlen szorzas van, a 10-el torteno, amit viszonylag egyszeru megvalositani: x=(y*8)+(y*2), azaz shifteles, ertek eltarolasa temp-be, majd shifteles ketszer, es a temppel ossze kell adni es kesz is.

Miert jo meg? Mert ciklusban csinaljuk a szamjegyeket es mindegy hany digitet veszunk le, a vegeredmeny mindig helyes lesz.

Nos a KULD rutin így néz ki:


Az egész program elég hosszú nem tudom belinkelni. Ez a rész tulajdonképpen magától dolgozik. Amikor meghívódik ez a rutin akkor semmi mást nem kell csinálnia mint várni egy számot amit aztán elrak az EREDMENY változóba. Én egy stringet küldök, mondjuk 6. Azt szeretném ha ez tárolódna az EREDMENY_T tárolóba de d'6' ként vagy b'00000110' - ként. Ugyanígy a másik szám is mondjuk 8 az EREDMENY_E tárolóba. Ha ez kész reményeim szerint 10*EREDMYENY_T + EREDMENY_E kiad nekem egy 68 -at ami d'68' ként jelenik meg az EREDMENY -ben. Ugyanis ezzel később dolgozni akar a program (csökkenteni az értékét stb..). Az hogy viszaküldi nek m hogy 68 csak ellenőrzés célból kell hogy lássam a PIC vette az adást és jó szám került az EREDMENYBE.

Namost jelenleg ez a rész nem megy. Azt nemigazán tudom hogy a 0x30 levonása után a jó érték kerül e bele a tárolókba de visza biztosan hülyeség jön vissza.Álltalában két egyforma betü. + újraindul a kontroller. próbáltam átállítani a küldendő karakter tipusát dec - re de még rosszabb. Kicsit módosítottam az utolsó részt de igy sem jó:

Tudni be tudod, esetleg nem akarod. ( a linkelés nem beszúrást jelent!)
Ide csatolni is lehet a Tallózás... gombbal, kis(1Mbájt alatt szerencsés) fájlokat.
A terminalon leírtam már, hogy mit kell tenned, de nekem nagyon nem tetszik ez a csiki-csuki, úgy hogy én kiszállok.

A mogyoróm ki van ezekkel az egyszerűsített PIC nyelvekkel. Mint, azt már említettem, megpróbáltam a MikroBasic-et, és a MikroC-t is, de amit Ők a gyári leírásban adnak meg, az nem nagyon akar működni, vagy inkább nagyon NEM... Szomorú...
Mindenki tanulja meg szépen az adott PIC "belsejét" és szépen programozz ASM-ben. Legalább tudod, mikor-mit művel a PIC-ed

Csak csendesen mondom, hogy az ADDWF az hozzáadást jelent. A kivonást SUBWF-nek hívják.

Szimulatorral teszteld le az algoritmust ember! Erre valo, mar emlitettem azt hiszem

A PICDEM HPC Explorer kártyávalkapcsolatban írtam tegnap: soros porton kapcsolódva minden jól működik, csak nem írja ki a hőmérsékletet.

Először időzítési problémára, a TC74 "túlhajtására" gyanakodtam, mivel ebben a mintaprogramban is emlegetnek ilyesmit. De sem az adatátvitel lassítása, sem a kiolvasások ritkítása nem javított a helyzeten.

Viszont megfigyeltem, hogy a PICkit2-ről táplálva nagy valószínűséggel működik a hőmérő kiolvasása, adapterről beindítva annál ritkábban. Ez felveti a gyanúját, hogy feléledési problémárólvan szó. A TC74 sajnos kívülről nem resetelhető (pedig a nem használt 1-es lábon kivezethették volna!), így minden a beépített power on reset áramkörére van bízva.

Ha a programban a TC74 inicializáslása előtt és után egy-egy 50 ms késleltetést iktatok be, akkor a tápcsatlakozó ki-be húzásával is jó eséllyel beindul a hőmérés. Az adapter trafóját ki-bekapcsolva viszont esélytelen a beindulás, sőt, a soros port is behülyül tőle (a Hiperterminált is le tudja fagyasztani).

Tanulság: úgy nem szabad rendszerbe építeni a TC74 hőmérőt, ahogy az gyárilag a HPC Explorer kártyán van. Resetelés céljából le kell(ene) tudni választani a tápfeszről egy tranzisztoros vagy FET-es kapcsolóval. Mert hiába lehet a reset gombbal elegánsan resetelni a mikrovezérlőt, az nincs hatással az alkalmanként rosszul felébredő (bal lábbal felkelő? ) TC74-re...[quote]

Probaltad mar a "_PWRT_OFF_2L" configot lecserelni "_PWRT_ON_2L" -re?

Lehet nem pont ide illik, de aki PIC-ezik, az próbálkozott már LCD-vel is úgy gondolom.
Mit jelentenek az alábbi kifejezések az LCD-re nézve, funkciót tekintve? Beviteli mód setupjánál találkoztam ezekkel:
1.) decrement/increment mode
2.) entire shift on/off

Nem próbáltam megváltoztatni, mert eleve _PWRT_ON_2L szerepelt a "gyári" config.asm-ban.

Hali!
Most kezdenék pic-ekkel foglalkozni, és usb-s égetőt szeretnék.
Ha ezt itt megépíteném (az elsőt) az szerintetek jó lenne?
Még sosem volt égetőm, ezért kérdezem.
Üdv.

Az ICD2 már egy kifutóban levő égető. Persze ettől még jó, csak ha már veszünk vagy építünk, akkor inkább valami modernebbet. És mivel ICD3 (még) nincs utánépíthető, ezért marad a Pickit 2 mint utánépíthető (van is itt az oldalon cikk és téma is róla), vagy jó áron megvehető égető.

Köszi, szerintem a pickit2 eléggé macerás az smd alkatrészekkel, de inkább a wpb->pk2 fordító tart vissza.
Le sincs írva mire jó, és hogyan csináljam.
szerintetek venni, vagy csinálni érdemesebb?

Vagy esetleg érdemesebb lenne venni egy usb-sorosport átalakítót és egy egyszerű sorosportos égetőt készíteni elsőnek?

Na, ezt szerintem senki nem fogja ajánlani...

Olvasd el rendesen, mert valamit nem értettél meg.
Nézd neg szilva PK2 klónját is, az nem SMD, viszont csak az 5V-os PIC-eket tudja égetni.
http://szilva.info

Hú!
Ez fantasztikus!
Szerinted nehéz lenne nekem a Te pikit2-d átrajzolni úgy hogy furatszerelt legyen?
Csak mert szeretném hogy ha már csinálok egyet akkor a lehető legtöbb pic-hez jó legyen.

egyébként szilváé sem rossz, de ha már lúd...

Sziasztok!
Ez a kérdés már felmerült a topicban régebben, de egyértelmű választ nem kapott. Legalább is én nem találtam. Most én is belebotlottam és felteszem újra, hátha azóta lett a kérdésre magyarázat.

Megépítettem a NULLÁTÓL A ROBOTIG cikkből a JDM PIC programozót. IC-Prog 1.05-el próbálkozom egy USB-s sorosport átalakítóval, sajnos nem sok sikerrel.
Ha az IC-prog-ban Direct I/O-ra állítom az Interface-t, akkor totál semmi élet, gyakorlatilag 0 V mindenhol. Ha viszont az Interfacet Windows API-ra állítom akkor meg vannak a feszültségek, a programozás led is világít -ebből arra következtetek, hogy az áramkör jó-, de egy örökkévalóságig tartana mire lefutna a programozás, de legalább 2-3 óra.

A cikkben azt írják, hogy fel van készítve ez az áramkör az USB-s soros portra.

Előre is köszönöm a segítséget és a türelmet.

Vagy esetleg egy egyszerű fet-es + 3.3v-os tápos kapcsolással megoldható a dolog?
Mármint gate:=programozó kimenete drain-ra megy a3.3v
source-ra meg a pic lábai?
Köszönöm az eddigi válaszokat

No igen. Az az áramkör elektromosan lehet (inkább úgy mondom, hogy biztos, ha azt írják róla), hogy fel van készítve az USB/soros átalakítók szintjeihez.

Viszont amit Te is tapasztaltál, hogy ezeknek az átalakítóknak az API-n keresztül történő vonalszintállításai valami embertelen lassan mennek le, az sajnos igaz. Emiatt a programozás bitanglassú lesz, ha egyáltalán azt a lassúságot a céláramkör elviseli. Valószínűleg egyébként emiatt nem történik programozásbeli probléma, csak a kivárhatatlan lassúság miatt lesz gyakorlatilag használhatatlan a dolog.

Ha a PICkit2-m publikálási helyén belenézel a fórumba, akkor láthatsz egy olyan, jelenleg még csak elméleti szinten létező illesztőfokozatot a PK2 és a céláramkör közé, aminek segítségével 2.5V illetve 3.3V tápfeszültségű PIC-ek is kezelhetők lesznek.

Amint lesz rá módom, ki fogom próbálni a gyakorlatban is, de szerintem túl sok bizonytalanság nem lehet ebben az áramkörben, én azt gondolom, mennie kell.

Szóval akkor lenne jó, ha a Direct I/O módban működne az áramkör rendesen igaz? De ez most normális müködés vagy nem? Szerintem nem. Szerintem aki azt a cikket írta nem hiszem, hogy így gondolta?!

Egy USB/serial átalakító nem fog direkt IO módban működni, mert nem lehet IO utasításokkal elérni úgy, mint ahogy a hagyományos soros portokat. Az API megfelelő meghívása egy USB-s kommunikáció révén állítja a soros porti biteket egyenként, ettől van a lassúság. Ezzel sajnos nem tudsz mit kezdeni, ezért (is) nem valók ilyenfajta használatra az USB/soros átalakítók.