Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Idézet: „miközben alul 8MHz-re hivatkoztál” Meg a négyszeres PLL-re is...  8x4 = 32 Idézet: „Ha az USB-s dolog ennyire macerás” Találsz kész demóalkalmazásokat is, nem kell megijedni! Bővebben: Link
Tudod mostanban én vagyok az ügyeletes gonosz, ennek ellenére nem bántásból mondom, ez messze nem kezdő feladat. Igaz én is belecsaptam a lecsóba annó, de akkor volt már Z80 assembler előéletem és egy csomó periféria, amit egy Enterprise-ra illesztettem.
Érdekelne, neked ilyen irányú előképzedséged van-e? Idézet: „Tudod mostanban én vagyok az ügyeletes gonosz” Nyugi mar, en is mostanaban csak leb..ni szoktam az ide tevedo kezdoket  De legalabb MolnarG azzal kezdte, hogy mar megvette a Konya fele konyvet, amire azt mondtam, hogy wow! Valaki olvasni is hajlando Lehet meg is szeretne taulni
Én csináltam már pic18f4455-re PIC-PC kapcsolatot USBvel. Ehhez a típushoz van gyári demó, azt könnyű módosítani, szóval nem vészes.
Egy apró kérdés:
PWM jelet szeretnék generálni, majd a kapott jelet ki szeretném simíttani, mert ez egy analóg vezérlőjel lenne, amit egy berendezés AD átalakítója dolgoz fel. Ki tudom átlagolni a PWM jelet egy kondival?
Azzal nem, de ha teszel egy ellenállást is, hogy RC szűrőt alkossanak, akkor már igen.
Szia!
A gyári demo problémája, hogy programozott az USB kezelése, nem eseményvezérelt. Az USB kezelése elviszi a pic teljesítményének jelentős részét. Ha a mérés, kiértékelés is teljesítményigényes, akkor együtt már nem fognak jól működni... A galvanikus elválasztás az USB-n nehezen, drágán valósítható meg... Egy DDS generátort építettem, ahol a jel előállítása 100%-ra lekötötte a pic teljesítményét. Az USB kezelése egy másik pic feladata lett. A kettő között optocsatolt 150kBaud-os soros vonali kapcsolat működik. Az USB programot a PicKit2 firmware módosításával valósítottam meg. Ez a másik pic olcsóbb lehet, mint az ftdi áramkör. Szia
Nincs különösebb előképzettségem, mint már írtam, korábban máshogy viszonyultam ezekhez a dolgokhoz. Szerencsémre van egy két haverom akikekkel minden nap találkozom és ők is tudnak segíteni e téren, ők jóval képzettebbek nálam...
Nehéz optimistának lenni ilyen esetben, de ha nagyon kitartó vagy, egy év múlva menni fog, de sokat kell tanulni, ez bizonyos!
Rá is találtam köszi
:Bővebben: Link
Valaki meg tudja mondani melyik függvény konvertál float-ból stringet c30-ban? Visszafelé volt atof, de ezt az irány nem találom sehol. Talán csak az sprintf tud ilyet, de ezek a printf mind olyan nagy kódot generálnak. Más függvény nincs?
Úgy néz ki, nincs beépített ftoa(). Link
C30 -ból ítélve nem kispályás mikrovezérlőre készül a project. Tényleg nem fér bele ? (Nálam 16F -be írt komolyabb cucc mellett is elfért) Hasznos az a printf egyébként is. Más kimenetre nem használnád, csak 1x kellene konvertálni az egész kódban ?
Az ftoa egy megvalósítása itt található, de használhatod a sprintf() függvényt is.
Nekem kicsi az a range, de köszönöm mind a kettőtöknek a linket, használtam az sprintf-et kínomban.
Nem nagy a projekt, csak egy cnc fúróvezérlő lesz, most írom azt a részt ami átadja a számokat a pic-nek, és lehet hogy nem lépek ki az unsigned int-ből, bár jegyzem meg itoa-t sem láttam, de azt könyebb átalakítani, mert csak helyiértékekkel felszorozni a számértéket, és összeadni őket.
CNC-hez nem volna bölcsebb float helyett fixpontos aritmetikát használni?
Igazából a pc fog mindent számolni, és csak relatív mennyiségeket ad át a picnek, ami meg lépteti a motorokat, és itt már intek fognak menni, mennyi full és mennyi mikrolépés az x tengelyen, mennyi full és mennyi mikrolépés az y tengelyen. Csak teszt miatt gondoltam elosztok két számot, és az eredméynt visszaküldöm (mert ugye itt kell karakterekből számokká alakítani és vissza)
Es a PC nem tudja binarisan, elore meghatarozott modon elkuldeni az adatokat? Vagy ez valami szabvany protokoll amihez illesztesz tehat mindenkeppen ASCII-ban kuldozget es ezen valtoztatni sem tudsz?
Erre nem felelne meg a bejövő adatok összegének legkisebb helyiértékű byte-ja is például és ez kisebb macerával járna ( ezt visszaküldve vagy a PIC által vizsgálva !). <-- hibaellenőrzésnek gondoltam !
Steve>
Nem szabvány. Tök saját. Gondoltam arra is, hogy áküldök két byteot, az elég lenne a mikrolépésekre, mert 65535 mikrolépés ha egy lépés 0.01mm az 65centi, annál meg nem lesz nagyobb, csak akkor meg a picnek kéne kiszámolni hogy az hány full stepp és hány mikrostepp, ráadásul ebben az esetben csak a kód újraégetésével lehetne átrakni egy más áttételű motorra, míg a vb-ben egy felületen be lehetne állítani hogy mennyi egy lépés.
Persze el lehetne küldeni 2 byteban a full steppet és két byteban a mikrosteppet, és ez még mindíg csak 4byte szemben azzal ha karakteresen küldöm, de hát humánok vagyunk, amíg nincs kész addig visszaküldi a sorosra hogy mit kapott a progitól, és azt mégiscsak jobban tudom olvasni hogy x24353,210*y3456,110 mint azt hogy 5F2100D20D80006e. Minek nincs itoa sem innentől kezdve mindegy egyébként hogy sprintf-el mit csinálok belőle, csak az itoa-t sokkal egyszerűbben meg lehet írni, lehet hogy azt meg is írom. Egyenlőre képlékeny, mert még most alakul, meg most gondolkodom hogyan is kéne jól megoldani. Most éppen a 3.3V-os táp nyákját tervezem egyben 74hct-s ic-kkel, mert eddig a 3.3V-ot egy 3A-es változtatható ic-vel csináltam ami pazarlás, csak épp az volt itthon. Kéne még egy bika táp is, egyenlőre egy 5A-esem van 12 mellett, de az lehet kevés lesz a 2 motornak, szóval van még mit csinálni.
Nem nagyon hibázik de most hogy mondod tényleg lehetne egy crc-t is csinálni, na még egy feladat.
Szia
Most töltöttem le egy kis rutint, ami ugyan nem az itos, hanem 24 bites bináris - BCD konverter. Ez már majdnem az, amit te keresel, az eredmény regiszterekben 2 db decimális számjegy van, amit egyeséve át lehet alakítani ASCII kóddá. Tovább alakítható hosszabb számokra is. Szia
Köszönöm szépen de én c-ben gondolkodom és egy long átalakító most kapásból így néz ki valahogy:
hossz=strlen(bejott); longszam=0; For(i=0;i dec=i*10; longszam=longszam+(48-(int)bejott[hossz-i]*dec); } oszt ágyesz bugyesz. >
Lehet, hogy csak nekem újdonság, de találtam egy ilyet, hogy:
PICmicro 18C MCU Family Reference Manual Ahogy az lenni szokott, van hozzá Errata is.
Ezt én se láttam még.
Viszont nem értem, hogy a Figure 3-3: rajzot miért erőltelik, mikor lehetetlenné teszi az ICSP programozást a dióda miatt.  Kis módosítással még működhetne is, de így nem... Idézet: „Viszont nem értem, hogy a Figure 3-3: rajzot miért erőltelik, mikor lehetetlenné teszi az ICSP programozást a dióda miatt. Kis módosítással még működhetne is, de így nem...” Hat irja, hogy miert gondoljak igy: Idézet: „The diode, D, helps discharge the capacitor quickly when VDD powers down.” Nyilvan masok voltak a szandekaik -- amugy meg LVP-ben miert ne lehetne ICSP-t hasznalni ezzel a kapcsolassal?
Egyik szándékukkal agyonütik a másikat.
Az LVP megjegyzésed jogos, de van itt valaki aki LVP-ben programoz?
Szia!
Ez a dokumentum még 2000-ben készült az egyszer programozható 18C szériához...(Csak jelzés szinten szerepel benne a 18Fxxx) Az a dióda nem olyan kritikus, ha belegondolsz a MCLR jelre és a +5V-ra más integrált áramkörök is csatlakozhatnak. Azoknak a belső védődiódái ezzel a diódával párhuzamosan kapcsolódnak. A 3-1 ábrán inkább R1 értékével van probláma. A rosszabb esetek az "External BOR"-nál jönnek a 3-13, 3-14 ábrákon. Az a szegény Q1 inverz aktív munkapontba megy ha MCLR +Vpp -re kerül a programozáskor. Szia |
Bejelentkezés
Hirdetés |
