@Wezuv:
Igen, és meg is köszöntem, mert sikerült teljesen körüljárni a kérdést, és az a fontos. A többi már csak részletkérdés, azzal biztosan elboldogulok magam is. Oké, szószátyárságban különben vita nélkül bűnös vagyok, a bocsánatotokat kérem érte Kicsit túlterheltek az ünnepek érzelmileg, és kimerültebb vagyok az átlagosnál.

@killbill:
Nem 1W, hanem 1V. Kapocsfeszültség stabilan előreszámítható kezeléséről volt szó.

Idézet:
„Jelen esetben nem merem hűtés nélkül hagyni,”

150mA * (5V-3,3V) = 0,255W az sok egy SO8 toknak? A DPak nem kapcsolható.

Próbálok ráhagyásokkal tervezni mindent. Betű szerint nem sok ugyan az sem, amit számoltál, de azok mögött a számok mögött analóg mennyiségek vannak, és nem csak azonnali elpukkanási határérték létezik, hanem áramköri használódás is. Amit jelenleg hozzáadtam ahhoz a negyed watthoz, és az so8 hűtőpad nélküli 140 k / w hőellenállásához, az egy munkagép hőkisugárzása a nyári melegben, mint környezet. Rossz esetben napsugárzás is. A cucc műanyag dobozban lesz ugyan, de az is csak át tud hevülni. Még a pic32-t is csak 24mhz-ig hajtom ki, hogy alacsonyan tudjam tartani a hőmérsékletét rossz esetben is. Már amennyire az egyáltalán lehetséges. Ha így is rossz lesz, hát így is rossz lett, de legalább nem azon szúrtam el, hogy még a sorsot is kihívtam magam ellen.

Érdemes ellátogatni a Microchip oldalára! Érdekes dolgokra bukkankat a látogató:
MpLabX IDE download: MPLAB® X IDE v3.15 letöltése a 3.20 verziót tölti le....
Sajnos a 3.15 és ez a verzió IPE sem kezeli jól a dsPIC33EP64GS502 -t (sárga a LED).
Minden kapcsolódásra az a válasz jön, hogy a kiolvasott 0x0 azonosító nem egyezik a várt 0x4E210000 -gyel. Ugyanazzal a panelkével a PICkit2 -n szépen bele tudta programozni a PE -t és ki tudja olvasni a program memóriát....

Csak én érzem úgy, hogy nagyon elkapkodja a microchip a dolgokat? Mostanában meggyűlt a bajom elég sokszor amióta az újjab termékeiket használam. Csak egy pár példa:
- PIC32MZ széria, alapvető funkciók hibásak az errata szerint is, de nem javítják ki, pedig eltelt egy-két év már, és nem jön új verzió, REV3-nál tartunk csak...
- MPLAB Harmony: a dokumenctáció hiányos, a weboldalon "coming soon" felirat réges rég óta...
- MPLAB Harmony kódban USB OTG-ben egy >= jel helyett csak a > jel volt egy if részben, sokat szívtam mire megtaláltam
- MPLAB Harmony konfigurator a TIMER-ek beállításait nem menti el rendesen, mindíg újra be kell állítanom ha módosítani szeretnék valamin
- MPLAB X IDE problémák.... nekem sokszor eldobja az ICD3-at pl. és sorolhatnám még
Mindeközben már valami nagyon új miktrokontrollert akarnak piacra dobni, vagy talán már piacon is van? PIC16-PIC18 szériával sosem voltak ilyen gondjaim MPLAB 8 alatt.

A PIC16 sem jobb, bár nem sokat használom, de az MCC-vel futottam bele olyanba, hogy a PWM nem ment mert nem a beállított értéket töltötte bele a generált kód, hanem fix 0-t. De ezen nem kell csodálkozni az után, hogy az egyik adatlapban találtam egy hibát, amit részletesen leírtam és elküldtem a microchip-nek, majd hónapokkal később jött az olvasási visszaigazolás, hogy olvasatlanul törölve lett a levél...

Szia! Én most egy 32MX-el dolgozom. Mindig mindent gyalog állítok be, így elég kevés a probléma vele. Igaz nem használok túl sok perifériát a mostani projectben csak a párhuzamos portot, soros portot, SPI-t, I2C-t. Az ICD3-at nekem nem dobálja el az X 3.10, nem lehet, hogy az újabb kiadás hibás és azt használod? Sok panasz érkezett rá itt is.

Ez pont ilyen f@s volt mar 2009-ben is. Az USB stack-ben is javitottam hibakat, a TCP/IP-ben is. Es kozben forgott a gyomrom attól, amit láttam. Rettentő nagy gány az egész. A mikrocsip mindig is ilyen volt, mar a 16Cxx sorozattol kezdve. És ha megvesznek egy céget, akkor többnyire azt is csak elrontják, lásd mikrocsip WiFi modul. Olyanok, mint a mikrofos.

Én most kerültem szembe a Harmonyval, az RMII csatornát nem tudta konfigurálni, hogy az alternatív lábakon legyen. Viszont kézzel átírva a konfig fájlt, utána egyből volt hálózat, ami viszont pozitív

De ezzel az MPLABX-el nem tudok kibékülni. Rengeteg memóriát eszik, bár ezt részben a Java hibájának tekintem. Másrészt egy Reset láb oda-vissza billentés a programozó eszközön keresztül ne tartson már 8-10 másodpercig...

Én egyenlőre át sem tértem sem az mz-re, sem a harmony-ra, és továbbra sem használom az mplab-ot sem. Maradtam az mx-nél, meg a kézzel gyártott fordító scripteknél (nálam minden egy klikkre fordul 2 másodperc alatt bibii ). Minden másban annyi a hiba, hogy azzal roncsolja csak az idegrendszerét, aki akarja - én eddig nem akartam, és remélem, mire muszáj lesz, addigra csak emberibb állapotok lesznek az mz környékén is.

Feldobtam a kérdést mc-nek még január 3.-án, hogy olvastam az mz / da család előzetes doksijait, és kíváncsi lennék rá, van-e bármilyen tervezett public release date. Azóta ülnek rajta. Valami nagyon bonyolultat kérdezhettem

Még a 60001361B.pdf -et is eltüntették... Sikeresen programozom a 32MZ1xx, 32MX2xx , 32MZ -kel PICkit2 -vel mindenféle firmware csere nélkül.

Sziasztok! Valaki használt már SQI-t SD kártyához PIC32-vel? Keresgéltem librari-t, nem találtam.

Az az sqi az sd kártyák saját protokoljának a neve ?

Csak a PIC periféria neve.

Sziasztok!
Adott egy 50% kitöltési tényezőjű, néhány kHz-es PWM jel. Ebből kellene előállítani egy ugyan ilyen, de 0°-180° közt (legalább fokonként) állítható fázistolású jelet. Van erre esetleg ötlete valakinek? Van egy gyanúm hogy a 16 bites PIC-ek timer és OC perifériáival, esetleg az input capture-rel meg lehet oldani valahogy de még nem jöttem rá a magoldásra.

Az egyik OC-t össze kellene kapcsolni valamelyik timerral. Az OC-nek "Single Compare mode"-ban kellene mennie és így a fázistolás egyszerűen az OCxR regiszter állításával változtatható. A timert pedig kapuzni kellene az alapjellel, így akkor indulna el amikor jön a H szint. Azért pedig hogy mindig nulláról induljon, be kell állítani egy megszakítást a bemenő jel lefutó élére, és ott nullázni a timert.
Ennek két hibája van; az egyik hogy a timer mivel kapuzva van ezért csak addig pörög míg a jel magas szintű. A timer kapuzásnak valahogy arretálnia kellene. A másik probléma pedig hogy az OC modul a "Single Compare mode"-ban felezi a frekvenciát. Ha "Double Compare Continuous Pulse mode"-ban menne, akkor jó lenne a frekvencia, csak így az OCxR-en felül az OCxRS-t is mindig át kell állítani, a konstans 50% kitöltési tényező megtartásához.

Ja, amúgy az alapjelet a PIC is előállíthatja, ez lehet hogy megkönnyíti esetleg a dolgot.

Csak egy ötlet, nem néztem meg az adatlapot, nem tudom megvalósítható-e:
A két PWM kimenetet két külön timer-el hajtod meg. A timer-ek ugyanazzal a frekvenciával járnak, a kitöltési tényező is azonosra legyen beállítva. Amikor a fázist akarod beállítani kiolvasod az egyik timer aktuális értékét, és a kiolvasott értéket a kívánt fázistolás értékével megnövelve beírod a másik timer-be. A 16bites timernél így a 0-val megnövelt érték lesz a 0fok, a 32768-al megnövelt érték lesz a 180fok.

Nem rossz ötlet! Nem értem miért akartam én túlbonyolítani...
Közben eszembe jutott egy még egyszerűbb, ehhez csak egy timer (és két OC) kell: a timer közös mindkét jelnél, "Single Compare" módban mennek a compare modulok , az egyiknek az OCxR-je fixen nulla, a másiknak a fázistolását pedig az ő OCxR-jével lehet állítani.

Szia!

Jutottál valamire?
Most én is ezt tervezem. Az azonos lábak egy az egyben összeköthetőek (Vcc=3.3V mindkettőnél)?
A CMD lábat úgy gondolom egy szabadon választható portra köthető. Ha jól értelmezem ezzel lehet kiválasztani, hogy Command/Response vagyis parancsot adok ki vagy választ akarok.
Felhúzó ellenállások sem kellenek?

Még nem volt időm.
A lábak összeköthetők.
Igen, külön lábra, stb.
Kellenek a felhúzók, sőt, nézz körül, mert találni nagy sebességhez mindenféle ajánlást.
pl: AN10911

Köszi!
Ebben csak ESD védelemre találtam utalást és sima mezei 10-100K-s ellenállást láttam. Vagy elkerülte a figyelmem?

Inkább én értettem félre, tényleg ESD-re gyúrtak itt.

És hogyan oldanátok meg azt, ha nem két hanem három jelre lenne szükség? A másodiknak az elsőhöz képest 0°-180°-közti, a harmadiknak a másodikhoz képest pedig szintén 0°-180°-közti fázistolást kellene tudni beállítani. Mindhárom jel kitöltési tényezője 50%.

Ha fix 50%-os kitöltés kell, használhatod a Toggle módot. Ahol 180°-nál nagyobb eltérés kell az alapállapotot kell megváltoztatni (ez lehet csak a modul megállításával és újraindításával lehetséges, ki kell próbálni).

Csupán kíváncsiság gyanánt, mi a pláne az egészben? Az spi miért nem jó?

A pláne a (jóval) nagyobb sebesség, ill. olyan dolgok amik SPI módban nem elérhetők.
(Tudom hogy nem engem kérdeztél.)

dsPIC33EP512MC502-vel próbálok PWM jelet előállítania következőképpen: A timer5-öt és az OC1-et összekapcsolom, az OC1 kimenetét pedig kiteszem egy lábra (az RP38-ra, azaz az RB6-ra). A timer5 nullától 3499-ig számol (PR5=3499) belső órajelről, mindenféle osztás nélkül. Az OC1 pedig "Double Compare Continoous Pulse" módban megy, azaz ha a TMR5 egyenlő az OC1R-rel, akkor magas szintre vált a kimenet, ha pedig a TMR5 egyenlő az OC1RS-sel, akkor pedig alacsony szintre. Az OC1R=0, az OC1RS pedig 1749. Ennek végeredménye elméletileg egy 50% kitöltési tényezőjű négyszögjel lenne, a gyakorlatban azonban stabil L szintet mérek a lábon. Mit ronthattam el?

Nem tudom hogy ennél a kontrollernél is úgy van-e, de a 24EP512... amikkel dolgoztam, ott minden OCx perifériának saját OCxTMR számlálója van, és a TMR5 -öt max ennek az OCxTMR órajelének választhatod, tehát amikor TMR5 megszakítást okoz, akkor lép OCxTMR.
Tehát azt akarom mondani, hogy nem TMR5 = OC1R és OC1RS, hanem OC1TMR = OC1R és OC1RS. Elég sokat szívtam vele.

Már nem tudtam módosítani előző hsz.-t.
Rosszul emlékeztem, nem TMRx megszakítás lépteti OCyTMR-t, hanem közös órajelet választhatsz. De az igaz, hogy nem TMRx és OCyR / OCyRS egyezés az esemény, hanem OCyTMR és OCyR / OCyRS.

Talán az első és utolsó sorok megszívlelendők.

A timer szinkronizalasnak akkor van szerepe, ha tobb OC modult akarsz egymas kozott szinkronizalni, elleknezo esetben nem szukseges hasznalni. Minden OC mudulnak sajat timere van, ahogy AZoli is irta. Az OCM regisztertol fuggoen meg tudod adni, hogy az OC1R es OC1RS mit allitson.
A te kododban az a hiba, hogy az orajelt is a timer5 adja (vagyis mikor tullepi a beallitott erteket, akkor lepteti egyel az OC timeret) es szinkronizalod is ugyanarra a timmerre (vagyis mikor tullepi a timer5 a beallitott erteket reset jelet ad az OC belso timerenek).
Csatolok egy peldat egy egyszru beallitashoz: