Köszönöm a segítséget, de az eddigi próbálkozások sikertelenek voltak, elfogyott a türelmem.
Nem tudom megérteni, ha valaki közzé tesz egy projektet, akkor azt miért nem mindenki által használható formában és nem csak pr.-ozo matematikus prof.-ok számára ismeretes konvertálási eljárások után hasznosíthatóak.
Nem gondolom, hogy kb. 3Pr. nyelvet kellene megtanulnom, mert egy sz.-os thermostátot szeretnék megépíteni és nem hex-ben van a pr.-ja.
Ha mégis valakit érdekel, a köz javára konvertálhatná a pr.-ot, hogy aki tudja hasznosítsa.
Köszi: kepitu

Ne csüggedj annyira... A tapasztalatain szerint (tisztelet a kivételnek) a feltöltött programok sok esetben nem működnek. Egyesek a másolások megelőzése érdekében, mások feledékenységből (pl. a konfig biteket mindig kézzel állítja be), sokak tudatlanságból (ki se próbálta) tesznek fel programokat. Azért igen sok tesztelési munka kell, hogy egy program minden beállítás mellett leforduljon és működjön. Hozzá kell szokni, hogy nem teljesen megbízhatók, és mindegyiket meg kell vizgálni... Aki a hibát ki tudja javítani, az örülhet a programnak. Ez még mindig sokkal kevesebb minka, mint megírni...

Szia!

A 30 s időzítéshez 120000000 utasítást kell végrehajtani. A VARJ_2 címtől egy 8 us ciklus található. Ezt már csak 15000000 szor kell végrehajtani. Ez nem oldható meg a két külső ciklussal, kell egy harmadik is.

Állítsd be az MpLab Sim -et debuggernek, a Settings menüpontban add meg a 4 MHz órajelet. Fordítsd újra a programot, jelenítsd meg a StopWatch ablakot. Állíts be töréspontot a várakozás elejére és a végére. Futtasd a programot a várakozás elején levő töréspontig, töröld a stoppert, futtasd tovább a kilépésnél levő töréspontig. A stopperről leolvashatod az eltelt időt.

Én úgy értelmezem kérdést, hogy FOSC = 4 MHz. Akkor csak 30_000_000 ciklust kell leszámolni.

Link: PIC Delay calculator

Hali!

SPI busz kérdés. Ezúttal nem a hagyományos felhasználásra gondoltam.

Keskeny logikai impulzusokat kellene generálnom. Körülbelül 80..100 ezer impulzust egymáshoz képest kötött időzítésben. Az impulzus sorozat kezdetének a szinkronizálása nem egy lényeges valami, de ha egyszer elindult a sorozat, akkor az impulzusoknak egymáshoz képest már kötött idő határokon belül kell maradniuk - kvarc pontosság legalább.

Azon filoztam, hogy ha az spi-t fel tudom erre használni, nem kellene cpld-t raknom a pic mellé.

A programozással még elboldogulok, a kérdésem a hardver sajátosságaira vonatkozik. Kerestem kimondottan olyan irányelvet leírva, hogy az spi kommunikációban nagyon hosszú üzenetben is a byte-ok bit bit után szoros illesztésben garantáltan bármiféle szünet / gap nélkül követik egymást. Ilyet egyenlőre nem találtam, pedig már a motorola SPI Block Guide V03.06 -t is átnyálaztam (annál is kompetensebb doksit pedig nem ismerek).

Csinált már esetleg valaki ilyesmit a gyakorlatban, vagy létezik valahol arra vonatkozó info, hogy ilyen elgondolás megbízhatóan működni tud?

Én kipróbálnám a helyedben szimulátorban. Érzésem szerint ha még az előző adatsor kiküldése előtt betöltöd a következőt, akkor azok egymáshoz képest nem fognak kölönböző késésekkel indulni, mindig ugyanakkora lesz két adat között az eltelő idő.

Sziasztok!
A/D átalakítást szeretnék megoldani PIC-kel, van egy 16f628a-m, sajnos nem tanultam assembly programozást, csak C-t, az alapdolgok, már nagyon jól mennek(időzítők, megszakítások kezelése), viszont már kellene pár komolyabb dolog, így a kérdésem az lenne, hogy megoldható-e C nyelvvel A/D átalakítós program írása, és esetleg PWM moduláció írása. És lenne egy buta kérdésem is "Az MCLR lábat, 10kohm-mal fel kell húzni a Vdd tápfeszültségre." Ezt miért kell megcsinálni?
Egyébként esetleg VHDL fordító van PIC-hez? Segítségeteket előre is köszönöm!

Anno egy ds33-ason kipróbáltam, és szünet mentesen mentek az sck impulzusok egymás után. De 8-10 féle picre most nem tudom megnézni, és ha azokon is mind azt látnám, az akkor sem ugyan az, mint irányelv szintjén győződni meg róla, hogy márpedig az most nem alkalmi jelenség, hanem előreszámítható. Én átlag szeretem precízen tudni, hogy mit is csinálok. Sok hibám van, ez az egyik.

A kérdést igazából úgy is le lehet fordítani, hogy létezhet SPI-vel hosszabb adat kommunikáció _1_ vezetékesen? Ugyanis ha kezdeti signál alapján az órajel üteme felmérhető (mondjuk egy páros 0x55 0xAA-val kezdjük mindig az adat csomagot, amit ez után követ 4*1 byte csomag hosszúság röptében), és a szinkron a teljes adás alatt azonos marad, akkor ezt bármilyen hosszú adatcsomagnál meg lehet csinálni, és akkor az én kérdésemre is megvan a válasz.

Köszönöm, a 4 -gyel osztás kimaradt... Bocsánat. A hozzászólás többi része jó.

A/D: Használj 16F819 vagy 16F88 típust.
PWM: A fenti kettőben és a 16F628 -ban is van Timer2 és CCPM
MCLR: Ezen a lábon nincs belső védődióda a Vdd felé, mivel a Vpp feszültséget is el kell viselje. A láb nincs sehova sem kötve a zajok miatt beléphet a kontroller a programozási módba.

A vhdl hardver leíró nyelv. Cpld / fpga-khoz van kitalálva, ahol kvázi logikai kapuk és flopok ki és bemeneteinek kötögetéseit valósítod meg egy elektronikusan felépített mátrixban (a makro cellák is azokból vannak).

A pic annyival másabb, hogy itt a perifériák már mind ki vannak képezve, és ki van képezve a központi egység is, ami a perifériákat összefogja. Van utasítás készlete, és az utasításokat sor folytonosan hajtja végre. Nem egyszerre futnak, mint pld a vhdl logikai feltételei.

Szóval a kettőt ne keverd össze. Csak azért, mert a pic-en belüli perifériák is mind egyszerre futnak, és a pic is így kvázi multi taszkosnak nevezhető, attól ez még processzor + perifériák, és nem programozott logikai blokk. Ez elektronikailag kőbe van vésve, ezen programozással nem tudsz változtatni. Vhdl fordító pic-hez nincs, és nem is lehet a szemantikai különbség miatt.

C-ben teljes értékű programok fejleszthetőek rá, kezelhetőek megszakítások stb, bár a C fordító legjobb optimalizáltsága mellett is ha megnézed a fordító lista kimenetét asm-ben, hát bizony összességében átlag 4-5x lassabb lehet a C-ben megírt program futása, mint ha assemblyben írtad volna meg. Ha a sebesség nem kritikus, akkor a karbantarthatóság, az átláthatóság, és a kód hordozhatóság nevében ilyen áldozat meghozható. Ezt döntsd el te.

Végső soron nem muszáj egy ősrégi picet nyüstölni. Ha amúgy is vhdl-hez vagy szokva, gondolom nem tétel neked smd nyákon 100 lábas tokokat kezelni. Vannak 32 bites pic-ec 80 mhz órajellel, és ha az árukat megnézed, már nem olyan nagyon veszélyesek (jó persze, nem 3-400 forintok, de azért 2-3khuf még nem a világ vége, mint ahogy egy fpga-ban sem). Azoknál akad bőven feláldozható teljesítmény.

Az nMCLR lábat azért szokás magasba cibbantani, mert mint a neve is mutatja, egy alacsony aktív reset láb (master clear), és ha alacsonyban hagyod, resetbe fagyasztod a pic-et. Ha pedig lifegve hagyod, random resetekkel kell számolnod.

Idézet:
„Az eredeti hex nem használható, mivel ...”

De, használható. Talán előnyösebb lett volna azt írni, hogy ha az SMD változatot a céláramkörben ICSP-n keresztül akarod felprogramozni akkor, figyelj az 1K-os bázisellenállásokra. Bár, hozzáteszem, nálam semmi gondot nem okozott fejlesztés közben.

Idézet:
„Az idétlen lábkiosztás miatt sok gond lehet vele.”

Nincs vele gond. Az "idétlen" lábkiosztás, az egyszerűbb nyákterv miatt lett választva, nem amiatt, hogy valaki majd ICSP csatit tervezzen rá. Amúgy, igazad van, csak a teljesen laikus utánépítőknek megtévesztő ez a kiemelt "nem használható" szöveg.

Szia!

Nem akartam megsérteni senkit...
A végén azt javasoltam, hogy úgy építse meg, ahogy Te tervezted, akkor nem lesz problémája. Az a biztos.
Végig egy SMD verzióról beszéltünk. A kiemelés, lehet túl erős volt, főleg, ha valaki csak azt a hozzászólást olvasta. A letiltott MCLR nem jó megoldás a belső oszcillátoros konfigurációkban, a MCLR lábat nem is használja az áramkör. A topik fejlécében azt ajánljuk, hogy mindenképen legyen rajta 10k felhúzás a Vdd -re, akkor lehet aktív is.

Az SMD verzió felhozza az említett probémákat. Az első programozásnál nincs még gond, de az újraprogramozásnál előjöhetnek. Ha marad kihasználatlan láb és a funkciókat át lehet tenni más lábakra, akkor célszerű az ICSPDAT/PGD és ICSPCLK/PGC lábakat kihasználatlanul hagyni. Ha mégis fel kell használni őket, legyenek bemenetek.

Egy másik topikban küzd valaki 16F818 -cal, belső oszcillátor, letiltott MCLR, a PGC és PGD láb kimenet. Már két darabot nem lát a programozó...

Javitsuk ki, ha lehet, a "Az eredeti hex nem használható..." részt "Az eredeti hex nem használható SMD verzióhoz..." -ra.

Ez teljesen jogos. Én csak a fogalmazáson lovagoltam. Nagyon köszönöm a többiek nevében is a sok segítséget Tőled. Részemről semmi probléma (és sértődés)! Sőt, örülök neki, ha segítesz jobbá tenni a dolgokat! Köszi mégegyszer!

4-5x különbség csak akkor van, ha valakinek halvány lila gőze sincs arról, hogy mit is csinál, de az ilyen vélhetően asm-ben is gány kódot írna. Kicsit elemezgetve az asm listát és megismerve, hogy a fordító mit mire fordít, lehet olyan C kódot írni, ami szinte ugyanarra fordul, mint amit "kézzel" írna az ember. Szerintem 70-80%-os sebességet kis odafigyeléssel C-ben is el lehet érni.

Szia!

Egy C24-C30 fordító assembly listájából:








Ehhez hasonló részből rengeteg van a kódban.

Biztosan nem írnánk le egymás után kétszer - négyszer, ha kézzel kell begépelni.

Meg ez is egy csemege:


Valahogy így nézett ki:


Ez már a C filozófiájából jön: a függvénynek egy kimenőértéke van. Az osztás után a hányados is és a maradék is megvan a W0 ill W1 -ben, de a program még egyszer oszt. Minek? A 5968 cím után a W0 és a W1 menthető lenne.

Nyilván többféle módon lehet C fordítót is gyúrni, és én pld az ingyenes C30-at nézegettem anno (MC oldalről ingyen letölthető). Abban nulla optimalizálás van.

Viszont hogy emberi értelemhez képest 70-80% hatásfokot érjen el egy C fordító, azt akkor is soknak találom. Már csak azért is, mert asm-ben nagyon másképpen kell gondolkodni, mint C-ben. C-ben absztrakt rutinokat látsz, meg feltétel blokkokat, míg asm-ben sorfolytonos végrehajtás és "goto"-k vannak.

A változókat sem kell mindig ugyan abba a memória rekeszbe raknod a folyamat egészének a szintjén, mert te magad pontosan tudod, hogy éppen akkor hol lesz. Rakás utasítást meg lehet spórólni, ami C-ben hasonló szagúra fogalmazva olyan irgalmatlan rondán nézne ki, hogy ihaj - és még csak nem is lehetséges olyasmikre utasítanod a fordítót, mert nincs olyan nyelvi elem. Ha lenne is, senki sem fogja olyanra szerkeszteni a szöveget, és már ezen kibukik a történet. C-ben a szépen megszerkesztett szöveg néz ki jól, és nem az, ami a processzor szintjén gépi kódban hatékony.

Optimalizálásból is annyit tud egy C fordító, hogy részleteket optimalizálni, nem folyamatot egészben. Nincsen felső szintű logikája olyat megtenni. Nem tud "sanity check"-et végezni. Nem emberi elmével gondolkodik.

A C-t az átláthatósága, és a hordozhatósága miatt szeretik. Az említett hatékonyságot szerintem soha el nem fogja érni.

Köszönöm a kimerítő választ, így rengeteg dolog tisztázódott, amiben nem voltam biztos. Most már csak valami anyagot kell találnom C nyelven az A/D átalakító megvalósításához. Még egyszer Köszönöm!

Más:

Anno kerestem pic32-es modulokat ethernet csatlakozással szerelve (felpakolva a phy, a trafós csati, és a minimális környezeti elemek, kvarc ilyesmik), és kaptam is pár linket, de így utólag már nem találom őket itt a fórumban, és google pajtással sem tudok szót érteni.

Valami tipikus dugasz próba panelbe pakolható dupla tüskesoros modul kellene, ahol a fel nem használt pic lábak közül van a tüskékre kivezetve lehetőleg jó sok. Pictail nem szimpi. Amatőr kísérletezéshez nekem valahogy nem áll kézre.

Aki tud ilyet, segítsen ki plz. Az ára igazából mindegy. Nem tömegesen lesz rá szükségem, csak 1-1 darabra.

Igazán semmiség.

Hanem hogy az A/D átalakítás és PWM output jellemzően van-e akkora falat, hogy arra libek létezzenek, ezt nem tudom.

Ami Microchip Libet találni lehet (jó minőségben ellenőrzött kód részletek forrásai), azt innét indulva megtalálod:

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nod...547784

És persze ne felejtsd el, hogy a pic áramkör. Azok a program példák is mind úgy épülnek fel, hogy vannak külön pic családok jellemzői, és a headerekben a define-okat be kell állítgatni éppen arra az adott pic-re és áramköri környezetre. Végső soron nem leszel sokkal előbbre egy ilyen egyszerűbb alkalmazásnál, mintha simán fognád az adott pic adatlapját, kiollóznád az abban a perifériára kiadott kódrészleteket, és azokat te magad gyúrnád egybe.

Oshon környezetben dolgozok.
Mplabal még csak most ismerkedek.
Tehát simán Assembler be kellene.
Kiszámolást azt tudom hogyan kell, de valahogy sosem egyezett meg a valósággal.

Dehogy nulla! -O1 szintű optimalizálás van benne. Az a
sort nálam már ugyanúgy optimalizálta, mint az -Os vagy -O3 szintű.

Itt mire gondolsz pontosan, milyen szoftverrel?
És sajnos a programod lényegét sem értem...
Ki tudnád bővebben fejteni?

Ha az optimalizálás nélküli kódot telerakja a fent idézett értelmetlén utasításokkal, akkor könnyű sikeres optimalizálót írni. Garantált a siker, ha csak a felesleget távolítja el.

Sziasztok, még mindig kezdő vagyok a témában, de szeretnék gy apró kérdést feltenni.

Egy komplett kijelzőpanelt bontottam szét amin egy 128x64 pixel grafikus LCD panel található T6963C vezérlővel a kijelzőhöz komplett illesztés, meghajtás, vezérlés, és egy 8 bites periféria IC egy 82C55AM-2 ami A B C portot kreál egy portból és tartalmaz egy puffert is. Ennek az IC -nek az egyik portján lógott az LCD. a többin gombok és egy csipogó.

A kérdésem erre az IC re vonatkozik.
Az periféria IC PIC -hez használható későbbiekben, legalább is tanulási jelleggel mert ahogy látom nem lehet olyan vészes adatokat küldeni/fogadni ezen keresztül. Ha nem érdemes, akkor süllyesztő.

Köszönöm a segítséget.

A képek...

Van neki saját topikja is, ahol talán okosat is tudnak mondani.

De érdemes keresgélni a vezérlő típusszámára hivatkozva. Erről beszélnek például itt,
vagy itt is.

Szia Icserny.

Félreérthetően fogalmaztam: Nem az LCD --ről hanem a Periféria IC -vel kapcsoltban (82C55AM-2) szerettem volna tájékoztatást kapni, hogy érdemes e vele foglalkozni, tanulgatni rajta, vagy nem.

Szia!
Ránéztem az adatlapjára, ha gondolod tartsd meg, ha nincs kedved foglalkozni vele, akkor ne tedd. Általában nem szokás mikrokontrollerhez ilyesmit illeszteni, mert túl sok portlábat elvisz. Ha nem kell túl nagy sebesség, akkor inkább I2C vagy SPI porttal rendelkező portbővítőket célszerű alkalmazni. Ettől függetlenül még nem feltétlenül kell kidobni, kísérletezgetni azért lehet vele.