Köszönöm, megnézem!

Meg a négyszeres PLL-re is...
8x4 = 32

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?

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...

Hat irja, hogy miert gondoljak igy:



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