Szia! Természetesen lehet. A belinkelt oldalon ha a felső zöld négyzet 1 pixelére kattintasz kiírja az értékét, már csak egy kis matek meg feltételes elágazás és kész is amit szeretnél!

Amit mondasz az azt jelentené hogy a pixel bekapcsolásához össze kell állítanom az újabb karaktert és leküldeni megjelenítéshez a RAM-ba.
Ok ha így megy akkor oké...
Idáig eljutottam, csak a gond az vele hogy a LCD-RAM-ba le kell küldeni azt a összeállított a adatokat jelző karaktert ami kijön az összemontírozott pixeloszlopokból, (ugye egy pixeloszlop lenne egy hőfokadat) egy karakter 5 oszlop, benne különböző oszlopmagasságok, legalább egy karaktert foglalnak el a RAM-ból. --> Tehát maximum 8 oszlopot tudok felhasználni karakterenként 5 hőadattal.
Ez jó mert ez már 20 adat helyett 30-at tudok megjeleníteni...
Bonyolítja a helyzetet hogy a második sorban ugye lehetnek kiesebb érteket jelző pixeloszlopok is...
A variációk száma itt már elég magas, --> itt letettem a 4 soros oszlopról!
Mennyi írást bír ki a LCD-RAM? Egyáltalán lehet a LCD-RAM-ban kicserélni a karaktert "menetközben"?
Ha igen akkor a második sorhoz ismételten > karaktergenerálás > letoltés > ...stb
Srácok bírja ez a topik ezt a felvetést vagy átvonuljak vele az LCD-s-be?
Olyasmire gondoltam a kérdésemben hogy megoldható e az hogy a pixel kigyújtható-e úgy direktben egy paranccsal...
Mert akkor pixeloszloponként lehetne az adatot megjeleníteni és a régieket eggyel arrébb tolni...
Ahogy a ZX-81-en, tudjátok
Kezdjek el kapirgálni a HD44780 adatlapjában vagy kezdjek el Grafikus LCD-vel foglalkozni?

Az lcd Ram írását már egyszer én is megkérdeztem és azt mondták, lehet akárhányszor írni menet közben is! Összecsaptam neked egy 1 karakter összeállító progit. Ez 1 karaktert összeállít neked 5 bemeneti értékből dot módba.

Kicsi nyugos a dol g, mert egyszerre csak 8 user karaktert lehet letolteni a 44780 CGRAM-ba, es ha uj karaktert akarsz akkor ezt ugye ujra meg kell csinalni. Az irast birja vegtelenszer azzal nincs gond, csak ugye 8 karakter letoltese az bizony sok idot elvesz a programtol. Talan probara lehetne valami olcso nokia 3310 kijelzovel (84x48 pixel) lehetne csinalni ilyen kijelzest. Mondjuk Flowcodera nem tudok otletet, de C-ben nem egy nagy ordongosseg. A LCD vezerlese SPI vonalon lehetseges, a driver IC a PCD8544 amit nem egy nagy varazslas vezerelni. Igaz csak 3,3 voltrol mukodik, de az ujabb PIC-eknek ez nem nagy kihivas. Az esetleges beszerzesre van otletem.

Nézem!
Az szuper, akkor öt adatonkként kell csak leküldeni a ramba eltolva hátra az eddig megjelenített értékeket.
Bepakolom egy tömb-be és ott mozgatom hátrafelé.
Szuper vagy!

Mondjuk en C-ben programozok, de egy ilyen nokia 3310-es kijelzo kezelese egy 16F684 programmemoriajabol akar 15 %-ot is elhasznal. Ja ez persze BW kijelzo. A szineseket azert inkabb valami komolyabb procival kell meghajtani ha tenyleg szep kijelzest akarsz. Otthon vettem valami 2k HUF tajekan.

8 adattal (kompromisszum-kész vagyok) megelégszek.
3310 kijelzőt épp megrendeltem E-bay-en... Majd ideér...
Tanulni jó lesz, de addig is adott a feladat számomra. Matekozni addig is kell
Utána fejest ugrok a grafikus világba...

Sziasztok
Az ADC komponens makronál az "ADC RAW SAMPLE CHANNEL" és "ADC RAW AVERAGE CHANNEL" ez mit takar és hogy kell használni?

Átlagot lehet vele számoltatni az ADC mérésekből.
Használat: Csatornát készítesz, meghatározód a mintavétel számát és időközét, bezárod a csatornát.
Kapsz egy átlagot, nem kell kézzel mintavétel ismétlést és érték összeadást, átlagolást végezni.

Köszi
Egy példa esetleg?

...valahogy így.
TESZT vált. azért kell mert csak a PIC-ben működik a szimulációban nem, ha szeretnél értéket látni szimulációkor használd a TESZT változót

Ok,igy már értem

Hello!
Két elméleti kérdésem lenne (ezekre később lesz szükségem, de egy ideje már gondolkodom rajta, de nem jövök rá)
1:
Lehet e a PICből valahogy egy véletlenszámot kicsikarni?

2:
Hogyan tudnám megvalósítani a következőt:
Egy IR ledeket villogtatok különböző frekvenciával. A PICre rákötök egy IR tranzisztor, és érzékeli. A kérdése az, hogyan tudom mérni, meghatározni az egyes frekiket? Pl van egy led ami másodpercenkét 30at, a másik 40, a harmadik 50et viilog. Nekem azt kiválasztanom mi 40et villog. Hogyan?

(persze Flowcode-ban érdekelne a dolog. De ha az elmélet megvan akkor Cben, PAS-ban már lemegy)

1: valtozo=random()
2: Megméred a 2 impulzus közötti időt és ha annyi amennyi neked kell akkor örülsz és azzal bármit lehet csinálni.

Helló!

Jeles szinten szeretnék foglalkozni a Pic-ek programozásával, ezért keresem a Flow.. hasonló szintű ( 5.x verzió ) változatát.
Tud valaki segíteni?

Üdv: rotomat

http://www.matrixmultimedia.com/product.php?Prod=flowform&Var=PIC&P...SESSID 49 font a home verzio. Mellesleg a PIC-ezeshez ingyen letoltheto a gyartotol (MCHP) a MPLAB IDE, ami tartalmaz egy ASM forditot, valamint szinten ingyenesen megkapod a XC8 C nyelvu forditot. Ezzel azert messzire el lehet jutni.

Olyan kérdésem lenne, hogy jelenleg elég sok lebegőpontos változót és számítás használok a programomban, az áttételek miatt. Igaz nincs gondom velük, és jól számol, de átnéztem a programot és Long vagy Ulong változókkal tudnám helyettesíteni, mert bele férnének ha a 4 tizedesig felszoroznám és csak a vége lenne ismét INT változó kerekítve, mint most.

Van értelme cserélni vagy hagyjam. Az adc bemenet volt mérése amúgy is csak float-ban lehetséges, de csak az maradna lebegőpontos.

Változhat tőle valami?

1: No erre nem gondoltam hogy ilyen egyszerűen megy itt is.
2: Oké, ezt értem, hogy a két impulzus közötti időt mérem, de hogy? Amikor beérkezik egy jel, akkor valamelyik TMR számlálót elteszem, és amikor megszűnik az impulzus, akkor újra megnézem. És az órajel ismeretében ki tudom számolni mennyi idő telet el. Így valahogy?
(Ennek utána kell még néznem, mert nem egészen értem a dolgot. Nem értem ezt a modulált dolgot. Valószínűleg ezért nem értem)

Még egy kérdésem lenne.

Mikor a lebegőpontos változót egésszé alakítom (float2int), akkor azt hogyan végzi el a program. kerekít a végétől (fel és le a szabályok szerint) vagy csak simán levágja a tizedesvessző után lévő részt.

Ha az előbbi eset az igaz akkor értéket vesztek, mert 8 tizedesig számol elvileg, ha az utóbbi, akkor tök mindegy, mert az egészek osztásakor lévő tizedesek is elvesznek.

Így az Ulong változót használva a km számlálóban, most kiszámoltam, hogy 320 km-t tudok úgy megtenni egy huzamba lényegi pontosság vesztés nélkül, hogy nem állítom le az órát míg túl nem csordul. (most 100km-en belül pontosan számol GPS hez képest az óra.) Ha lopok a pontosságból 1 tizedest, akkor 3200km tudok meg tenni egy huzamba. Ami szerintem nem lenne észrevehető mérési veszteség. Többet vesztek ha laposabb a gumi.

De azért érdekelne hogy is végzi az átalakításokat a program.

Timert elindítod, jel érkezésekor megnézed mennyi az értéke és ha annyi amennyi neked kell pl 188-200- ig akkor egy feltételes elágazással egy másik változót átbillentessz amivel már azt csinálsz amit akarsz és kinullázod a timert és mehet minden előről.

Kivettem a float-okat. Ami pl. 1.86578 tizedes volt az most 186578 lett és ezt szorozza 17.5 helyett 175el, és így tovább. Aztán a végén annyi szor 10 es osztást használok, hogy a számérték jól jöjjön ki. Lényegében szintén levágom a végét.

A sok számjegy kell a pontossághoz, de kijelzéshez amúgy is a flaot-ot vissza kellett INT-nek alakítani, így ugyan az maradt elvileg a végeredmény, csak nem használok float változót, és nincs float művelet, csak sima alapműveletek +-/*

Csak a Volt mérés ADC bemeneten, szintmérőnél maradt float, és ott van egy két művelet vele. A hőmérő INT el dolgozik...

Kíváncsi leszek mennyit csaltak a float számítások. KM számlálónál sokat kellett játszani a dinamikus kerékátmérővel és százalékosan kellett beállítani az eltérés számítást. 100km es pontosságra sok benzint elvitt.

Ha ez most 20-30-50km en elmászik akkor az egyértelműen a float számítás pontatlansága.
Egyébként erre számítok, mert mérőszalaggal mérve a kerék kerületet, terhelve és üresen, áttételeket számolva a váltóban és a kihajtásokban, és sok milliószor átszámolva matematika szerint nincs ekkora eltérés mint amit az óra programjába be kellett írni.

Sziasztok en is eleg kezdo vagyok a pic vilagaban szeretnem ha segitenetek egy szoba termosztat megepiteseben ,gondoltam egy 2 soros kijelzore aminek az elso sora a beallitott homerseklet lenne meg a masodik a szoba homerseklet lenne. A szenzor lm35 a pic labain kellene delta kulombseg + es _ ami ido impulzusok vagyis delta 1 celziusznal 1 masodperc 5 perc szunet, delta 2 foknal 2 masodperc 5 perc szunet, delta 3 foknal 3 masodperc 5 perc szunet,
elore koszi

TMR0 IT-vel egyszeruen megoldhato. Csinalsz egy szamlalot, amit a TMRO 1 sec lepesben leptet felfele. Ha a szamlalo erteke kisebb mint a delte T akkor a kimenet bekepcsolva, ha nagyobb akkor kikapcsolva. Amikor a sec szamlalo eleri a 300-at (5 min) akkor lenullazod, es ujra kezded.

Idaig jutottam el es nem tudom ,hogy miert frisit a kijelzo

Azért frissít a kijelződ mert rosszul kezdted és amivel folytattad az se jó. Először is az lcd start (amitől az lcd elindulna) sose tud lefutni mivel a program legvégén van ráadásul cikluson kívül. Minek kell ennyi késleltetés? Ja rájöttem ettől villog a kijelződ, az a cél hogy villogjon? Mert akkor jól csináltad.

Ez igy nagyon jo ,de most hova es foleg ,hogy lehet a delta + es - impulzus timert betenni ami 2 ledbol all .Elore is nagyon szepen koszonom.

Most tényleg azt szeretnéd ha megcsinálnánk helyetted? 2 számot kivonni egymásból nem hinném hogy bonyolult lenne, főleg hogy a nehezét már megcsináltam. Mellesleg a DeltaT 1 értéket ad minek kell 2 led?

Na, meg volt a próba. 150km benzin bánta.

Semmi extra különbség nem lett a float és a long változók használata közt a végeredményt tekintve. Vagyis annyi lett, hogy long-al pontatlanabb lett a számítás, mivel a felszorzásoknál fel kellett kerekíteni előre, hogy ne csorduljon túl.

Sebesség mérése ugyan azt a pontosságot adta, 2km/h plusz ami be is volt állítva.
A km számláló viszont nagyobb eltérést hozott, mint gondoltam.

Vissza került a float változós program.
Sebességet tekintve sem vettem észre semmit, 20MHz-en pörög az óra, de a 100ms frissítés, vagyis 10Hz-nél, elég gyors, hogy észre se vegye a float számítást.

Igen a floathoz képest, de rossz irányba. vagyis nagyobb százalékos eltérést kellett beállítani. (fiordítva gondoltam én is.)

De az áttételekből adódó nem egész szám szorzatából adódik.
Míg a floatnak, hagyom a teljes számot szorozni és csak a végén van egy kerekítés, így a pontossága nagyobb.

Az egészeknél nem elég a tizedes vesszőt arrébb tenni, de már kerekíteni kell mert két 8 jegyű számot összeszorozva már túl tud csordulni még az ulong változó is. Így hátulról előrefelé a szabályoknak megfelelően fel kell kerekíteni 4-5 jegyű számmá, és beírni. Valamit pedig le kell csípni. Így pontatlanná válik a máshoz képest.

Nyilván ez egyedi eset, hogy a float ezért pontosabb. De ezt csak tanulságnak írom, hogy ahol már kerekíteni kell az egészeket is, mert túlcsordul, ott sanszos, hogy a float pontosabb a végén lévő kerekítéssel.(persze ez függ a sebességtől is, mert lehet ha fontos lenne a nagy sebesség és nem 10hz hanem sokkal több, akkor lehet ott bukna meg a float változó használata.

Igen méterben adtam meg, ahol 5 tizedesig írtam be a kerék átmérőt.
A km/h átszámítás m/s ből 3.6
A kerék és a spirál együttes áttétele, 1.84722.
pl a dinamikus kerékátmérőt sebesség mérésnél 0.08al szorozva adja hozzá.
A km számításkor pl 25.4%-ot ad hozzáa kerékhez. Így jön ki 100kmen a pontosság. Ha 1 tizedessel lejjebb (25.3) veszem akkor GPS-hez képest 100kmen van 5km eltérés.

Ezek a fix adatok a többit számolja.

A Ulong használatánál ezeket fel kellett szorozni és kerekíteni, és számolni, hogy bejövő jelek szorzásakor ne csorduljon túl a számláló.

ja a mefgmért kerékátmérő csak 2 tizedes, annyit tudok mérni, de ott nagyon pontatlan. A számmolt átmérő és a dimanikus eltérés használatakor pontosabb a számláló, sebesség mérő.