Jelen esetben a kérdés a baudrate sebességre irányult, oda pedig nem a 12MHz-et kell figyelembe venni, a különböző beállításokhoz tartozó képletek tartalazzák a megfelelő osztásokat is.

Köszönöm, hogy segítesz, de nem tudom mire gondolsz.(Azért válaszolok lassan , mert próbálom közben elindít a kommunikációt)
FOSC=20MHz
BRGH=1
BRG16=1
SYNC=0
Ebben az esetben a képlet a következő:
FOSC/[4(n+1)]
A képlet alapján és a PIC dokumentációja alapján ugyan azt az értéket kaptam 300K átviteli sebességre, 16665.
Nem értem?! Az FOSC értékem a rossz?

Fosc=rendszeridő
Mi az ami nem érthető?

Köszönöm a segítséget! Elindult a kommunikáció!
Én folyamatosan a 20MHz-es kristály oszcillátorhoz akartam beállítani az átviteli sebességet.
Üdv.:K

Ne feledd a másik "hibát" is módosítani, amit jeleztem.

Rendben! Kijavítottam. Köszönöm! K.

Sziasztok Urak !

A következőre szeretnék valamiféle magyarázatot ,vagy megoldást kapni.

- Adott 2db PIC ,amik közös órajelen vannak (OSC1 -en,OSC2 1M -val földön.)
- Órajel 2MHz.
- PWM Kimenetet figyelem és a képen látható elcsúszás figyelhető meg.
- Mindkét picben csak annyi van ,hogy PWM kitöltés 50%

A lényeg a szinkron lenne ,de minden egyes tápelvételnél másképp (random) ,de pici csúszással jön vissza.

Köszönet !

A magyarázat nagyon egyszerű: a PWM kimenet egy számláróra épül. A számláló az órajelet számolja, majd a beállított periódus elérésekor nullázódik. A nullázódásnál lesz az egyik él a kimeneten, a másik pedig innen számolva a beállított kitöltési tényező szerint jön majd. Ahhoz, hogy szinkronban jöjjenek a jelek, az kéne, hogy a két PIC számlálói egyszerre induljanak, azaz a programoknak is hajszálpontosan egyszerre kéne elindulniuk. Ezt a PIC hardverből nem garantálja, bekapcsoláskor van egy többé-kevésbé random várakozás. A programoknak kellene induláskor összeszinkronizálniuk egymáshoz, vagy azt is lehet, hogy menet közben az egyik folyamatosan ellenőrzi, hogy hol jár a másikhoz képest, és korrigál.

Szia !
Köszönöm ,logikus magyarázat !Mit tudok tenni ,ha segítenél ebben.
Mi a szokás ,ennyire "pontos" dolgot még nem kellett csinálnom.....
Ja....
És a végkifejlet nem 2db PIC lesz ,hanem 8-10 db ,ezeknek kellene "szinte" teljesen szinkronban PWM-kedni.

Ha nekem kéne ilyet csinálni, én átgondolnám ezt az elvárást, és ha lehet, elkerülném. Ha nagyon muszáj n db azonos frekijű, szinkronizált, de eltérő kitöltési tényezőjű PWM jelet előállítani, akkor valószínűleg mást használnék erre a célra. 8-10 kimenetig lehet találni PIC-et, felette létezik pl. LED-ek meghajtására kitalált IC, amiben 16-24 PWM kimenet van, amit mikrokontroller tud vezérelni. Megkeresem, hogy hol láttam.
Vagy ha még ennél is több kimenet kell, akkor meg egy kisebb FPGA-ben secperc alatt össze lehet dobni, a szakajtó PIC árából meg ki is jön.

Nem a HT1632 -re gondolsz LED ügyileg ?

Valami Texas IC volt, meg nem mondom a típusát most.

Sziasztok!
Egy fejlesztéshez akartam valami új PIC-et használni, mert jól jött volna a 2 UART egy tokban. Ki is választottam a 18F46K22-t, de ahogy nézegettem az adatmemóriát, írta az adatlap, hogy az SFR egy része (0xF38-0xF5F) nem tartozik az Acces RAM-hoz. Ergo ha használni akarjuk, akkor be kell állítani a 15. BANK-ot, ami végülis nem nagy baj, hisz egyszer kell csak beállítani, ha az ember csak az Acces RAM-ot használja.
Le is szimuláltam MPLAB-ban, és tényleg úgy van.
Végülis nincs semmi kérdésem, érthető a dolog, csak eddig megszoktam, hogy az Acces RAM tartalmazza az összes SFR-t, és most ez kicsit meglepett.

Sajnos mosanaban egyre tobb 18F-es jon ki ilyen szervezessel. Egyszeruen mar annyi regiszter van, hogy nem tudjak mashova bezsufolni.
En ezzel egy 25K80-asnal szembesultem eloszor, PWM es AD kapcsan.

Ha a szkopoknal megszokott egy kocka az idoalap, akkor ez a csuszas abnormalisan nagy, fel milliszekundum koruli. Ezt nem magyarazza a picek eltero felebredese.
Minden konfigbit (kulonosen a WDT) ugyanolyan?
Milyen nyelven irtad meg?
Miert nem lehet egy PIC-el meghajtani? 500Hz siman menne szoftveres PWM-bol EGY db PIC-el tetszoleges szamu (akar 40) kimenettel. Es a csuszas szerintem mikroszekundum alatt lenne.

Szerintem felesleges annyi perifériát belezsúfolni egy tokba. Főleg a 28 lábúaknál.
Inkább csinálnának több fajta sub-családot, hogy legyen elég fajta variáció.
Így a bankos problémával visszajutottunk a 16F-hez, amit direkt el akartam kerülni a 18F-el.
Na nem baj, végülis választottam egy másik PIC-et (18F2620), ami ugyanazt tudja, csak nincs tele értelmetlen perifériákkal.

Szerintem meg jo. Olcso a szilikon
En szeretek par tipusra beallni, kiismerem a nyugjeiket.
Egyebkent assemblyben hivatalbol szinte mar senki nem dolgozik (engem kiveve), a magasabbszintu nyelvek meg alapbol kezelik.

... hanem helyette inkább többe kerül... ez tök jó üzlet a Microchipnek

A tokozas dragabb. Igazabol a fejlesztes meg a tokozas a draga belole. A tobbi szinte elhanyagolhato. Ja, meg a marketing es a vezetok premiuma.

Természetesen azért drágább, mert régebbi. És az a Microchip policy, hogy az újabb termékek árát picivel alacsonyabbra lőjük be, a régebbiek árát meg nem engedjük le, így az árorientált felhasználók szépen áttérnek az újabbakra.
2620 ugyanis 28-lábú, a 46K22 meg 40-lábú, tehát ha a tokozás lenne a drágító tényező (amúgy kicsit az, kb. 50-100 Ft-ot számít), akkor a 46K22 lenne a drágább, nem pedig fordítva.

Szia!
A fejlődés már csak ilyen:
- A sok periféria bezsúfolásának az oka, hogy szélessebb körben lehessen alkalmazni egy típust. Valakinek két UART, valakinek a két MSSI kell, másoknak pedig sok timer stb. Minél nagyobb darabszámot lehet elérni egy típussal, annál olcsóbb lesz. Az új technika (K sorozat), alacsonyabb csíkszélességgel, újabb gépsorral dolgozik, ugyan arra felületre több egység fér rá.
- Minél régebbi a terv és a gyártási technológia annál drágább a kontroller. A jó öreg 16F84A ( 900 Ft+áfa), avagy 18F2620 (1130 Ft+áfa) - 18F26K20 (640 Ft+áfa)...

Persze, az oké hogy sokminden van egy tokon belül, csak ez így kókány megoldás.
bbalazs_ én is assembly-ben programozom a PIC-eket, bár ismerem a C-t is, de lusta vagyok rá áttérni

Akkor az advanced midrange típusokhoz mit szólsz? 32 bank -juk ban. Legalább van egyszavas "movlb bank" utasításuk...

OK, de mit csinalsz mondjuk az USB vagy a NET alkalmazasokkal, ahol a draga egyetlen mikrocsip csak es kizarolag C-ben biztositja a forrast.
En is utalom a c-t meg nem is akarom megtanulni, de elobb-utobb valami minimalisan foglalkozni kell vele, mert egyszeruen kenyszeritenek.

Elmondtad a lenyeget: hova LOJUK be az arat.
En az eloallitasi koltsegrol beszeltem. A tobbi a marketing.

Ha úgy vesszük, a felárral azt is megfizeted, hogy az már egy jobban kiismert (néha javított) típus.

Az újat meg azért adják olcsón, mert a kedves vevő is részt vesz a fejlesztésben: sűrű anyázások közepette reportolja a gyártónak a felfedezett hibákat.

Idézet:
„En is utalom a c-t meg nem is akarom megtanulni, de elobb-utobb valami minimalisan foglalkozni kell vele, mert egyszeruen kenyszeritenek.”

Annyit tennék még hozzá, hogy meg is vetetik a méregdrága fordítót, mert a free módú optimalizáló inkább teleszórja a kódot értelmetlen utasításokkal, mint optimalizál. Ráadásul a 8, a 16 és a 32 bitesekhez megveheted külön-külön. Ha már rászoktál, akkor vedd is meg a nagyobb kontrollereket, mert nem fér be a programod a kisebbek memóriájába...

Mondjuk az USB asm-ben már húzós, én is C-ben játszottam vele, bár az se volt teljesen világos
Ami még indok a C-nél: a változó típusok, meg a műveletek. Nem kell ide-oda pakolgatni az átvitelt, deklarálsz egy integert, vagy floatot, és már mehet is a móka.

Szia !
Nem is igazán az a baj ,hogy nagy ,hanem az ,hogy random.
Végül is egy PIC-ben lesz ,majd meglátom mennyire macerás programozni ,mennyire fog elcsúszni "n" darabszámnál.WDT ki van kapcsolva.Csak halkan írom Flowcode-ban programozom.
Ahogy néztem a port kiíratások között 500nsec eltolódás van, de az "új" PICben még nem is néztem (18F67K22).
Köszi a választ !

Ha egy helyen lesznek a "kimenetek", akkor jobban jársz egy több PWM modullal ellátott PIC-el, vagy valami céláramkörrel, ahogy ezt már jelezték a többiek is. Egyéb esetben nem nagyon lehet megoldani a dolgot, főleg ha neked 500nsec is számít...