geri12!
Nem tud senki segíteni, mert nem ismeri senki ezt a nyelvet, de főleg a fejlesztő környezet ismeretlen. Ez eddig szerintem kiderült. Sajnálom!

watt!

Van egy mondás! Ahány ember, annyiféle nyelv!

Biztos vannak olyan országok, ahol a Magyar nyelvet is egy "bohóc" nyelvnek tartják.

Na a kis kitérő után a lényeg. Lehet nem voltam az elején elég érthető... Van nekem egy speciális órám ami ezek szerint evvel van megírva! (most már tudom) De ahoz hogy megértsem és megváltoztassam a progit, ismernem kell ezt a jal kódot, vagy mit. Tudom-tudom hogy asm meg minden, de a fő forrás ebben az esetben a jal. A készítő valahogy több jal kiterjesztésből kreálta az asm-et. Kívánságom szerint azokat kell megváltoztatni és azokból lehet először asm-et, majd hex-et generálni.

A segítséget köszönöm. (link)

Az Algol-nak több dialektusa, és azon belül több alfaja van. De fenti kód nem tiszta Algol az tuti.
De én óva intek mindekit az ilyen nulla támogatással rendelkező fordítótól - amit jó ideje nem is fejlesztenek - főleg akkor, ha kezdő az illető.

Ha nem megy az assembly és gyorsan eredményeket szeretne az ember, letölti az oshon szimulátorát,abban van basic fordító

Algolt még nem tanultam, valószínűleg már nem is fogok, de most kiváncsiságból összehasonlítottam egy algol forráskóddal és szerintem ez csak nagyon hasonló, de nem tiszta Algol. Tehát van benne Algol is
(ha tévednék, akkor sorry)

Sziasztok PIC-ezők:)

Újabban felfigyeltem a grafikus kijelzőkre, és annak a lehetőségeire.
Először egy nokia3310 kijelzőt szeretnék életrekelteni piccel.
Olvastam hogy az SPI kommunikációt támogatják.De sajnos az én picem hardware-esen ezt nem tudja (16f628-04/p)
Próbáltam keresni neten szoftveresen megírt SPI kommunikációt.
Amit találtam így néz ki:



E rutin mellé még az írták:

"74 utasításciklus=14.6uS @ 20MHz
Ez megfelel 540Kbit/sec nek."

Most lehet, hogy nagyon laikus kérdések jönnek, de tényleg nem értek az SPI-hez:

Szerintetek ez így működne?
Nem túl egyszerű a progi egy ilyen kommunikációhoz?
Itt nem kellenek stop/start bitek, mint az RS-232nél?
Simulatoron amúgy látszott szépen, ahogy az órajellel együtemben mennek az adatok, tehát a prgi műxik. (Oshon Simulator IDE)
Tudnátok segíteni, hogy számolták ki ezt a 540kbit/s-t, mert a nokiaához ez túl sok, ráadásul 4MHz a picem és nekem ezt vhogy újra kellene számolnom, lassítanom NOP-okkal stb.
Esetleg ha vkinek van további ötlete ezzel kapcsolatban, azt nagyon köszönöm!!!

További szép napot!!!

Norby

Hello mindenki!
Van egy ravasz kérdésem. Adott egy 18F4320, 4bites Hexa kapcsoló, ennek az állását kell időnként beolvasni, eltárolni. A kapcsoló PortA 0-3 -n van, ha a progi
MOVF PORTA, W -vel olvassa, állandóan asszem 0x05-t lát.
(TRISA bemenet, portok Digital IO, ADC tiltva)
De ha : BTFSC PORTAX
BSF BEX ,
akkor minden rendben
JA, portokon 10k felhúzó, max. 15mm vezeték a kapcsoló lábáig, a kapcs fémháza földelt...

És Te miért bonyolítod a saját életedet? Ezt a bohóc nyelvet nem ismeri senki és nem is fogja! Ebből következően senki nem fog tudni segíteni neked, csak offolás megy a ügyben.
Ha meg akarod érteni mi folyik a PIC-ben vedd elő az MPLAB-ot és az Assemlert!

Igen-igen!

Ez is egy programnyelv.

A jal code studio-val lehet készíteni...

Ez a sok nyelv! Miért kell ennyire túlbonyolítani?

Ezzel egyetértek, ilyet már nem szabad tanulni... Bár nem vicckód, ez az Algol nyelv.

Na ilyen nyelvet nem szabad tanulni.
Se pascal, se basic, se C, csak turmix.


Ez egy vicckód.

Szerintem ezzel:
http://jal.sourceforge.net/

Érdekes, ezt mivel fordítod?

Üdv mindenkinek!

Egy programot akarok beleírni egy PIC16F877-be. Ez meg is tudom csinálni, de szeretnék egy kicsit csemegézni a forráskódokban is.

Azt szeretném megkérdezni, hogy ha van 3db egyforma nevű fájlom különbőző kiterjesztésben. Az egyik ugye a HEX, amit beírok a PIC-be, a másik az asm forráskód, a harmadik pedig egy jal nevezetű valami. A legutolsóra volnék kíváncsi hogy az mit takar. Ebből a jal-ból van egy pár darab az asm-en kívül.

Így néz ki:

main.asm
main.hex.
main.jal
clock.jal
hd44780.jal
sound.jal
stb
stb

Elnézést a kezdetleges kérdésekért, de mostanában kezdtem el belemélyülni a "programmegíráson" kivüli ismeretekbe. Szeretném megérteni mi zajlik a PIC-be működés közben

Köszi a választ előre is!

Köszi a kitartó segítséget, innentől azt hiszem menni fog.

Már értem, végül is ha van idő, akkor ez is jó.

a-x ha nincs kölcsönvét, akkor az eredmény y-ba.
b-x ha nincs kölcsönvét, akkor nézzük hogy: eredmény < y ha igaz, az eredmény y-ba.
c-x ha nincs kölcsönvét, akkor nézzük hogy: eredmény < y ha igaz, az eredmény y-ba.
d-x ha nincs kölcsönvét, akkor nézzük hogy: eredmény < y ha igaz, az eredmény y-ba.

y+x= a keresett szám..
Kivéve ha a 4 kivonás mindegyike alulcsordult, mert akkor x=0 -val is végigcsináljuk a fönti műveleteket.
Tehát ha a 4 kivonás mindegyike alulcsordult, akkor x változót töröljük, (x=0) és újra elvégezzük a fönti 4 kivonást, hasonlítást, és a végén y-ban lesz a legkisebb érték.
Mert ugye a 4 alulcsordulás azt jelenti hogy mind a 4 szám kisebb mint x, és ekkor a legkisebb számra van szükségem.

Tudom felesleges a 0-kat kivonogatni, de egyelőre nekem így a legáttekinthetőbb működése..

Ezt nem értem.

Ezt én nem írtam, csak azt, hogy nem veszel figyelembe egy csomó más lehetőséget. Egy pár jelzőbit használatával nem kell semmit újracsinálni, egy körben kijön az eredmény.

Ha mindig alulcsordul azt a lehetőséget írtam. Szerinted nem jó?
Ha valamelyik kivonás alulcsordul, az a szám rögtön ki is esett, mert kisebb mint x. Kivéve ha mind kisebb, mert akkor x=0-val újracsináljuk.

Kihagyod azt a lehetőséget, ha mindig alulcsordul. Meg azt, amikor először alulcsordul, aztán meg nem.

Lássuk:
1. verzió a tiéd:
a-x ha C=1 (nincs kölcsönvét), akkor az eredmény y-ba.

b-x ha ha C=1, akkor ha eredmény < y, akkor eredmény y-ba.

c-x ha C=1, akkor ha eredmény < y, akkor eredmény y-ba.

d-x ha C=1, akkor ha eredmény < y, akkor eredmény y-ba.

2. verzió
a-x , ha C=0, akkor eredmény y-ba

b-x , ha C=0, ha eredmény > y, akkor eredmény -> y

c-x , ha C=0, ha eredmény > y, akkor eredmény -> y

d-x , ha C=0, ha eredmény > y, akkor eredmény -> y

keresett szám=x+y

3. verzió
a-x , ha C=0, akkor eredmény y-ba

b-x, ha C=1, akkor eredmény y-ba

c-x, ha C=0, akkor semmi, ha C=1, akkor ha eredmény<y, akkor eredmény->y

d-x, ha C=0, akkor semmi, ha C=1, akkor ha eredmény<y, akkor eredmény->y

ez a verzió felléphet a c-nél, vagy a d-nél is(amikor először lesz C=1!).
Valamint ez a verzió keveredhet a 2. verzióval is néhány lépésen keresztül.

keresett szám=x+y

És így?

a-x ha nincs kölcsönvét, akkor az eredmény y-ba.

b-x ha nincs kölcsönvét, akkor nézzük hogy: eredmény < y ha igaz, az eredmény y-ba.

c-x ha nincs kölcsönvét, akkor nézzük hogy: eredmény < y ha igaz, az eredmény y-ba.

d-x ha nincs kölcsönvét, akkor nézzük hogy: eredmény < y ha igaz, az eredmény y-ba.

y+x= a keresett szám..
Kivéve ha a 4 kivonás mindegyike alulcsordult, mert akkor x=0 -val is végigcsináljuk a fönti műveleteket.. ??

Jaj, most jövök rá, hogy a V=X-(65536-M) az egyenlő X+M-el!

Így tehát csak a maradék kezelésére kell ügyelni, a végén a képlet ugyanaz az egyszerű összeadás lesz!

Igen, a lényeg ennyi, de láthatod, hogy azért ettől bonyolultabb a kívánalmaid miatt!

Majdnem, de közben annyit gondolkodtam, hogy lemaradtam, ezért még a korábbi kérdésedre reagálva indítanék.


Ez egy kicsit bonyolítja kérdést.
A szám kiértékelését eddig úgy gondoltam, hogy a megtalált legkisebb maradékot hozzáadjuk X-hez. Ez akkor jó, ha mindig van egy X-nél nagyobb szám(ami X után következik ugye).
Ha nincs nagyobb szám, akkor a legkisebb áll a sorban hozzá legközelebb, aminek a valós maradéka az alulcsordultsága miatt a legnagyobb szám! Tehát kivonásnál figyelembe kell venni a Carry értékét, és ettől függően cserélni le a maradékot.

Normál esetben, amikor minden szám nagyobb mint X, a maradékot(V_érték-X) akkor cserélnénk le, ha az kisebb, mint az előző maradék.

példa: V->a megtalált legközelebbi vizsgált érték, M->maradék

Carry=1(nem volt alulcsordulás)
X=32000
V= 36000
M=V-X=4000
V=X+M

A másik eset, amikor mindegyik szám kisebb:
Carry=0(alulcsordulás volt)
X=32000
V=30000
M=V-X=63536
V=X-(65536-M) szerk: A V=X+M ugyanezt adja, lásd a kiigazítást kettővel lejjebb!

Tehát a Carry legutolsó állapota meghatározza, hogy melyik művelettel kapod vissza a keresett értéket. szerk: Akkor ez nem érdekes, mert egy a képlet, csak a maradék kezelésre kell figyelni, ez következik...

De nem csak ezt kell meghatároznia, hanem azt is, hogy mikor cseréld ki a maradékot a tároló regiszterben.
Ezért a Carry állapotát nyomon kell követni, és tőle függően elágaztatni a programot a következő szerint:

Addig, amíg kisebb a V mint az X, azaz C=0, addig a nagyobbik maradék kerül megtartásra, illetve a nagyobbikat kell letárolni és ha ez végig így marad, akkor a V=X-(65536-M) képlettel lehet a keresett értéket megkapni

Ha egyszer is a C=1 lesz(azaz V nagyobb, vagy = X), akkor az első alkalommal ki kell cserélni vizsgálat nélkül a maradékot(ehhez jelző kell, ami a C=1 állapotát figyeli, hogy első alkalommal 1-e).
Ha ezután bejön egy C=0, akkor azt figyelmen kívül kell hagyni.
Ha bejön egy C=1, de nagyobb maradékkal, azt nem kell tárolni.
Ha bejön egy C=1, de kisebb maradékkal, akkor azt el kell tárolni és a végén a V=X+M képlettel számolni.

Remélem nem gabalyodtam bele!
Ha van másnak jobb ötlete az engem is érdekelne! Egyébként szép feladat!

Tehát azt mondod hogy:

a-x ha nincs kölcsönvét, akkor az eredmény y-ba.

b-x ha nincs kölcsönvét, akkor nézzük hogy: eredmény < y ha igaz, az eredmény y-ba.

c-x ha nincs kölcsönvét, akkor nézzük hogy: eredmény < y ha igaz, az eredmény y-ba.

d-x ha nincs kölcsönvét, akkor nézzük hogy: eredmény < y ha igaz, az eredmény y-ba.

y+x= a keresett szám..

Így??
javítottam..

Akkor a legkisebb a kiválasztott, mert 16 biten 0xFFFF+1=0x0000 ő következik a sorban.
Köszi a segítséget, még emésztem amit írtál...

A PIC-ben csak a kivonás utáni Carry vizsgálat áll rendelkezésre. De ezt Te is írtad, hogy összehasonlítgatod...
Azt, hogy melyik volt hozzá a legközelebb onnan tudod, hogy a tőle nagyobb esetében keletkező maradékot letárolod, majd a következő nagyobb érték maradékából kivonod, ebből láthatod, hogy melyik volt a közelebbi érték. Elég mindig egy maradékot letárolni, az előző legközelebbhez tartozót. Csak akkor tárold le, ha az érték nagyobb mint X egyébként marad az előző legközelebbihez tartozó. Ha mind a 4-et megnézted, akkor a bent maradt maradékhoz tartozó érték lesz a keresett. (amit úgy is megkaphatsz, hogy hozzáadod az X-hez..)

De tényleg, akkor mi van, ha mind a 4 kisebb nála?

Ezt nem értem. Pont ez a kérdés hogy hogyan döntöm el? Amikor még a sorbarendezéssel is gondjaim vannak.

Szerintem magával a sorbarendezéssel megkapod az X helyét. A többi változót már nem is kell sorba rendezni, csak az X-ig.

Sorba rendezés egyik módja, hogy megkeresen a legnagyobbat, amit a vizsgált memóriaterület végére mozgatsz, majd újra ezt teszed, csak egy címmel lejjebb rakod. Ezt addig kell csinálni, míg az X-nem jött, és akkor az előző lesz a keresett érték.

De ha jobban belegondolok, a sorba rendezés több idő, mint ha mind a 4-el egyenként összehasonlítod és eldöntöd melyik volt hozzá a legközelebb.

Volna egy újabb kérdésem, remélem még nem untátok meg.

Van 4db. 16 bites változóm, kaotikus, folyton változó sorrenedben, és van még egy 16 bites változóm (ez legyen X).
A feladat hogy a 4 változó közül ki kell választanom azt, amelyik - ha növelvő sorrendbe tenném az 5 változót - akkor X-et követné a sorban.

Biztos hogy van rövidebb és szebb megoldás annál, hogy X-et inkrementálom, és összehasonlítom a négy változóval, majd ha nincs egyezés újra...

De egyelőre azt se látom, hogyan tudnám növekvő sorrendbe tenni őket.. ha egyáltalán kell.

Akkor pláne nem értem.
De a lényeg, hogy jól műkszik, ahogy kell.

Egyébként régebben is volt ilyen gond valakinél, de már nem emlékszem, hogy mi lett a megoldás. Majd megnézem én is, mert izgatja a fantáziámat...

MOVF TMR1L,w utasítás hatására sem változik TMR1H a watch ablakban. De most felprogramoztam, és a PIC -ben meg jól működik a progi, az a lényeg. Köszi a segítséget.

Most nézem hogy van egy olyan "regiszter" a watch ablakban hogy TMR1_internal, az kell nekem!

Akkor nem értem én sem. És ha még is kiolvasod az L-t, akkor sem változik?

Elvileg RD16 bittel lehetne ezt beállítani. De én pont azért nem 16bites módban használom, hogy lássam.

A TMR1H csak akkor változik, ha kiolvasod a TMR1L-t!
Nézd meg a 12-2 rajzot az adatlapban!

A TMR1 High Bájtot nem látni a szimulátorban, az nem hozzáférhető regiszter(ha jól emlékszem), közvetlenül írni és olvasni sem lehet, mint ahogy az imént írtam.

Sziasztok!

18F1320 -et szimulátorban próbálok, és TMR1L túlcsordulásakor nem nő TMR1H értéke. Én nem látok semmi ilyen lehetőséget az adatlapon... mit csinálok rosszul?

Köszi!
A 24HJ-k ráadásul 512bájtonként törölhetőek(és 64bájtonként írhatóak). Persze, ha minden igaz, mert példát a programozás adatlapjában nem adnak, csak a teljes törlésre(parancs az van rá), így konkrét forrást még nem leltem erről.
Így ha írok is egy Verify-os égető rutint, akkor sem lesz annyira hatékony, mint a 18F-eknél. Azért így is kímélni fogja a flasht, hiszen csak azt a blokkot törli+írja, ami változik. Rossz szokásom, hogy inkább égetek, mint szimulálgatok. Lehet, le kell szokjak erről a 24F-eknél! Az a tervem, hogy statisztikát vezetek az égető programmal arról, hogy melyik blokk hányszor lett égetve. Ehhez be kellene vezetnem a project lehetőségét, hogy a log-okat vissza lehessen keresni az adott céláramkörhöz. De ez egyelőre csak terv, ha nem is távoli, mert hamarosan kéne...

DMIPS = Dhrystone MIPS. Olvasnivaló: ITT meg ITT

Úgy tudom, hogy azért tértek át erre a mérőszámra, mert ezeknél a prociknál már az utasítások ciklusszáma nem egyforma.
De nagyjából jó sejted, a megadott érték egy átlagos MIPS-nek feleltethető meg, ami ez esetben 108 DMIPS.

Az írási ciklusszám az engemet is meglepett. Főleg az a meglepő, hogy ezekben már nincs is EEPROM, persze használd a FLASH memóriát arra...
De még nem futottam problémába, pedig amiket használok jóval többször lett újrapogramozva 1000-nél.
A nagy memóriás példányoknál szerintem a Verify mód még hasznosabb, mert a programozási idő elég hosszú.

Potyo!
Mi ez a 1,5 x nMHz -> DMIPS a 32MX-eknél? Próbálom megérteni, de nem megy. Valóban 72MHz esetén 108MIPS-es lenne a tok? Valamit félreértek?

szerk:
Aztán kiakadtam, hogy a 24HJ-k flash Ep ciklusa minimum 100, tipikusan 1000. Visszafejlődünk! Azt hiszem itt nagyon szükség lenne a Verify-os írási módnak! Pedig úgy terveztem, hogy nem fejlesztek, hanem használom a PICkit2-t, de egyszerűen nem tudom kikerülni a dolgokat...

Próbáld ki kólával is.

Nekem minden áramköröm így kezdi a pályafutását. Amikor össze van forrasztva, akkor forró víz, körömkefe és mosópor segítségével a forrasztás maradványait eltávolítom, majd megszárítom valami alkalmas helyen. Ezután jön csak az első próba.

Én akartam, de férjuram fellázadt, hogy na, azt már nem, hogy én ilyenkor is forrasztgassak. Valamiért ő jobban értékeli, ha ilyenkor inkább főzögetek. Azért persze egy LED-eket összevissza felkapcsolgató "csodalámpa" így is elkészült picur lányomnak.
Ja, és képzeljétek el, egy feszültség alatt lévő áramkört (egy PIC volt rajta+pár külső ellenállás) sikerült a lányomnak kólával megkínálnia. Persze lekapcsoltam gyorsan, de így is eltelt pár másodperc, amíg a kóla és az 5 V együtt volt rajta. Mivel látványosan nem szikrázott, és nem is égett szét semmi, kíváncsi voltam, hogy bírta. Megmostam csap alatt, hogy lejöjjön a cukros trutyi, aztán meghajszárítóztam, kipróbáltam, és működött!!! Jajj, úgy örültem neki.
Ja, és BUÉK mindenkinek!

****KELLEMES ÜNNEPEKET KÍVÁNOK MINDENKINEK!****

Furának biztos hogy fura de én eddig csak 16F84-el bohóckodtam ez viszont egy "kissé" nagyobb állat . és úgy gondoltam körbeszaglászom mire is lehet használni ha már megdobtak 3 db-al. eddig a legértelmesebb egy PC-szkóp amit találtam azt valószínűleg meg fogom építeni de még így is marad 2 szórakozni.

Valahogy a sok másolgatás során belebarmoltam a mérési rutinba és két félnapja nem tudom megfejteni, miért nem megy. (korábban működött)

Valaki legyen szíves ránézni, hátha friss szem egyből észerveszi a hibát.



PIC18F4320-as


Üdv
Ray

Hááát úgy terveztem igen, de a nagylány nem biztos, hogy belemegy....

Ti csináltok valamit karácsonyra?
Én most lettem kész(néhány effektet írok még rá), egy karácsonyfára tervezett 8oszlopos, oszloponként 10 égős fényjátékkal. 5 napja forrasztok(16órát naponta!) , a programot ma írtam meg rá... .
Ilyenkor mindig elhatározom, hogy többet az életben nem csinálok ilyet, de aztán mindig valahogy elfelejtem a kínt!
Majd a fán készítek róla egy divixet, ha érdekel valakit!

Fura kérdés! De nézz fel az oldalamra, van egy fényfüggöny 458-al, gyakorlatilag fut 452-n is, néhány apró változtatás kell esetleg!

Szasztok sikerült hozzájutnom pár PIC18F452-höz valakinek van valami értelmes projectje rá?

Egyre világosabb. Kicsit nehezen jöttem rá, valszeg mert hátulról kezdtem az egészet.

Üdv
Ray