Ha kapcsos zárójel van akkor is kell az " jel?
Az is lehet, ha vessző karaktert akarsz tárolni, akkor ',' kell az aposztróf is.

A cc5x adatlapban ahogy néztem vagy {} vagy " " használnak, együtt nem láttam őket, de a fordító nem írt ki hibát rá.

C forditok a C nyelvbol adodoan eleg lazan kezelik a hibakat. Nem egy olyan nyelv amit magas biztonsagi kovetelmenyekkel rendelkezo helyre alkalmazni szoktak. C++ mar sokkal rigidebb ilyen szempontbol, de az csak egy eroltetes, igazan attoro megoldast az sem nyujt. A Fortran/Pascal nyelvcsalad mar sokkal jobb minden ilyen szempontbol, de igazan nagy megbizhatosagu rendszerekbe az Ada-t javasoljak. Azt szoktak mondani, hogy amit az Ada fordito lefordit az a kod mar a valosagban is mukodo kepes. Pl Airbus-nal ha be akarsz nekik dolgozni akkor elsodleges kovetelmeny, hogy Ada-ban dolgozz. Nem veletlen, hogy Toulouse-ban az egyetemen nem veletlen olyan kemenyen oktatjak az Ada nyelvet, minthogy a kornyeken talan az egyetlen ceg ahova egy informatikus elhelyezkedhet az Airbus.

És ha azt tanácsolnátok, hogy ASCII kóddal adja meg a vesszőt?

Nem tudom, egy próbát lehet, hogy megérne, bár az ' ' közötti karaktert elvileg ASCII kódban tárolja, már ha jól értelmezem a manualt.

Igen, a MCC18-ban ez így van, de hogy abban a szutyokban hogy, azt nem tudom és nem is nagyon érzek késztetést, hogy megtudjam.

Sziasztok!

Bocsi a nagyon kezdő kérdésért: most jutottam el odáig PIC-el, hogy külső órajelet szeretnék adni a TIMER0-nak. (PIC18F4520) Látom, hogy a 6-os lábra (T0CKI) kell kapcsolni a kvarcom egyik lábát...de hová kössem a másik lábat..? :pirul: nagyon ciki..?
Illetve ez esetben a PIC járhat más órajelen, csak a TIMER0 kap a működéstől eltérő frekit. Jól gondolom?

Adatlapban benne van. (129. oldal)

Az oké, de az TIMER1. A TIMER0-t a T0CKI pin mellet várnék egy kb T0CKO nevűt is, de olyant nem látok.

Jogos a pont, viszont a Timer0-ra nem lehet kristályt kötni, csak külső ütemadót.

Így már értem! Erre magam is rájöhettem volna, most aztán tényleg szégyellhetem magam! Köszönöm a választ!

Nincs mit! Egyébként előszőr én is figyelmetlenül olvastam a kérdésed. Lényeg, hogy az adatlap 99%-ban pontos, és segít. Érdemes használni(pontosabban elengedhetetlen)!

Szia!

Ez a második megközelítésed a helyes. v=s/t
Tehát a kerékátmérőm vagyis a megtett út az állandó csak az idő változik!
A motorom típusa Simson S51 és maximum 70-el bír menni csak.
16 bites kereső algoritmus? Mire gondolsz?

Köszi!
Ezt mindenképpen kipróbálom!

Simsonra lesz csak azért 6192 mert 172cm*36-al. (3,6 a m/s és km/h közti váltószám és nem akartam tizedestörtet mert azt macerásabb lenne binárisan tárolni és számolni meg még macerásabb lenne vele, így kihoztam egészre)

Ertem, akkor elegendo mondjuk ugy 100-ig megcsinalni kilomeres felbontasban, az 16 bites szamokkal 200 byte(word) a program memoriaban... ambar lehet az utolso szamjegy eleg bizonytalannak fog mutatkozni, hosz nem hinnem, hogy pontosan ugyanazzal a sebesseggel menne a jarmu, hanem az akarmit is csinalsz mindig +-1-2-3 km/h-t ingadozni fog, ami miatt az 5km/h bontassal valoszinuleg jobban jarnal.

16 bites kereso: Van egy szamod, amit irtam, hogy amit mersz. Ezt a szamot probalod megkeresni a tablaban, aminek mindegyik eleme 16 bites. Tehat nyilvan a felso byte-ot (MSB) kell eloszor viszgalni, es ha az egyezik, akkor kell megnezni az alsot (LSB) is.

Most lusta vagyok utana szamolni hogy eri meg legjobban, de ahogy irtam valoszinuleg linearis keresessel is lehet, vegulis mindig a legutolso elemtol kell kiindulni, es onnan kell megnezni, hogy lefele vagy felfele kell-e a tablaban linearis keresessel megtalalni az aktualis erteket (elozo talalathoz kepest kisebb vagy vagyobb-e, illetve azt is kell majd nezni, hogy melyik szamhoz van kozelebb -- felfele vagy lefele kell-e kerekiteni...).

Bocs, de én az állítólagos 1,72 m-es kerékátmérő-t kritizáltam. Szerintem kerületnek hívják.

Egyébként ezen a honlapon a PIC menüpontot választva találsz szorzó és osztó eljárásokat PIC18-ra. Ha arra kell?

Jah bocs, a kerékátmérő 55cm. 1,72m a kerület.
16F874 lesz benne és egy 2*16karakteres LCD re íratom ki a henger hőfokokt a megtett kilométert és a sebességet, valamint lesz egy nullázható napi km szerűség.
Már csak az osztás hiányzott a progiból a többit megírtam az elmúlt 3hétben.

Köszi szépen!
Kipróbálom először az osztó rutinokat aztán ha túl sokáig tartanak akkor marad ez a táblázatos dolog.
Valószínűleg a hőfokmérést is majd így kell megoldanom ilyen táblázattal mert KTY81 est használok és a PIC AD átalakítóját.

Szerintem jó lesz ez osztással is. Frissíteni a kijelzőt bőven elég tizedmásodpercenként, én meghajtanám a PIC-et egy 4MHz-es kvarcról, ekkor van kb. 100000 utasításciklus kiszámolni a kijeleznivalót. Ha ebbe nem férsz be, akkor ott valami nagyobb gond van...

Szia!
Annyira nem értek a motorokhoz, de nem lesz kevés az a hőszenzor? 150 °C- ot tud mérni, ha esetleg egy helyben túráztatod a gépet, hadd pürrögjön , akkor nem lesz 150 °C- nál melegebb a henger fala? Ez amúgy léghűtéses igaz? Szerintem érdemes lehet elmerengeni a témán.

Nem melegszik fel 150foknál jobban elvileg mert az már bő túlmelegedés lenne, megszorulna a dugó.
110fokot mértem rajta múltkor melegen 10km es út után.
Igen léghűtéses.

4MHz es kvarcom van, a 32,768KHz est csak a TMR1 léptetésére használom. (annak sok lett volna a 4MHz és hamar túlcsordul)

Ha a 4MHz az MCU orajele (FOSC), akkor az 4-el mar eleve osztva van mire a Timer1-hez er, azaz 1MHz-el kell szamolni. Erre meg rapakolod a maximalis 1:8-as prescalert, es akkor maris 125kHz-ed van. Ez kb 0.5 masodpercenkent fog neked tulcsordulni. Ha ez is tul gyorsan tortenik meg meg mindig lehetne egy interrupt segitsegevel novelni a szamlalod meretet, tehat minden tulcsordulaskor 1-el novelgetsz egy byte-nyi valtozot, igy a Timer1 16 bites szamlaloja es az a kulso valtozo egyuttesen egy 24 bites szamot tesz ki.

Ezek a dolgok akkor jok ha sporolni akarsz a kristallyal. Masik modszer, hogy a PIC az belso orajelrol ketyeg, mivel neki nem kell pontos orajel, csak az idomereshez kell azt pedig a 32kHz kristaly biztositja. Ilyenkor meg azt is elerheted, hogy a PIC a meresek kozott alszik, igy aramot sporolhatsz meg. De gondolom ez megint valamo 16F877-es vagy hasonlo aminek nincs belso oraja? Ha igen en a helyedben elgondolkodnek a 887-esen, ami olcsobb, belso oraja is van es debuggolhato is... Ja es majdnem felulrol kompatibilis a 877-tel, tehat tulajdoonkepp 1:1-ben lecserelheted.

szépen halad a project, köszönöm az eddigi segítséget.

Viszont most is lenne egy kérdésem.Az LCD művletek jól működnek, viszont most 4800 bauddal fogadnék adatokat egy gps modultól. az SPBRG-t 51-re állítottam, 16Mhz-en így kijön a 4800. Asszinkron 8 bites átvitel, 0x22-t írok a TXSTA-ba, 0x90-t az RCSTA-ba. Figyelem a PIR1 regiszter PCIF bitjét, ha 1, vagyis jött adat, akkor RCREG tartalma a W-be és meghívja a kijelző karakterkiíras függvényét. a mellékelt programot lefuttatva kapok a kijelzőre egy egy karakteres || -jelet és ennyi. A gps jól adja a jelet teszteltem terminálon.(4800, 8bit, 1stop)

valakinek nincs véletlen valami ötlete?
köszönettel, denisz

Szerintem ezzel lesz a gond:



Az a gond, hogy amikor a felső és az alsó nibble-t írod ki, aközött csinálsz az RS lábon egy felfutó és egy lefutó élet (bár a kommentben azt írod, hogy RS line to 0, én meg fejből nem tudom, hogy az RS-nek hol kell állnia, de így biztosan nem jó). A bsf LCD_PORT, RS magasra állítja, viszont a movwf LCD_PORT miatt alacsonyra billen az RS láb is, mert az andlw 0x0f és a swapf templcd, w miatt az alsó négy bit nulla a w-ben a movwf LCD_PORT meghívásakor. Úgy kell megcsinálnod, hogy az alsó biteket a porton ne bántsd. Pl. lehet úgy, hogy egy MOVLW 0x0F, ANDWF LCD_PORT, W művelettel letárolod az alsó négy bit állapotát a portról, majd ezt OR-olod a templcd tartalmávalal, és úgy írod ki movwf-el a portra. Az igazán jó megoldás az árnyékregiszter használata lenne, de LCD-nél nem lesz gond anélkül sem.

szerintem ezzel nem lesz baj, mert, ha csak simán text függvényt hívom meg, akkor hibátlanul kiirja a szöveget a kijelzőre. Egy kissé sokat variáltam a programban, és elfelejtettem átírni a kommenteket.( de ezeket, most megteszem). tehát a kiírás elvileg jó...

denisz

Akkor lehet, hogy az RS láb nem szinkronizál 4 bites módban, csak az RW láb? Mindenesetre jobb nem kisérteni a sorsot, inkább írd át olyanra, ami nem bántja a többi bitet, egyel kevesebb hibalehetőség.

Tul azon amit potyo mondott a PORT-okat sohasem szabad bitmoveletekkel vagy mas RMW utasitassal igy piszkalni! Elobb MOVWF -el kiirsz valamit a portra, majd BSF-el billented a biteket. Minimum egy NOP illene a ket utasitas koze, de jobb lenne Potyo tanacsat megfogadni es arnyek regisztert alkalmazni.

az probléma lehet, hogy a PIC adatlapjában a boud rate-ek közül a 4800 ki volt húzva? Én meg annyira konfiguráltam a PIC-et, mert a modul annyin ad.