Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Én Eddig MX-et akkor használtam amikor elkezdtem 32 bitezni mert abból volt DIP-es aztán azóta csak MZ-ket használok azon kívül hogy nem megy rá kvarc más nem nagyon akasztott ki benne.
Jó az ADC-t ha pontos mérésre akarjuk használni lehet felejtős, bár mostani projektben PT100-is kifejezetten pontosan mér és feszültséget is sima 1%-os osztóval is pontosan mérek vele, bár nincs rá igény. Az MZ nem feltétlen a nagy periféria készlete miatt szoktam használni hanem egy kicsit a kényelem miatt, sokáig míg assembly-ztem és assembly-c átmenetbe voltam nagy optimalizálás őrült voltam, de elmúlt Amit a harmony-ból használtam Timer, SYS_TMR service-ek, ADC_HS, UART, I2C, USB, RESET, SYS_DMA (nagyjából ezek) És elkezdeni nem volt egyszerű bár a c++ segített rajta, mert ahogyan érzékeltem a library elég erősen objektum orientáltságra hajtottak (persze valós hiba kezelés nélkül). Van egy két hely ahol ki jön hogy más más ember csinálta a libary-t szerint az I2C és UART API része jobban eltér mint ahogyan kellene. Viszont ami nagy előny volt az egészben hogy semmivel nem kellet nagyon szenvedjek (persze eltekintve míg fel nem fogtam, hogy hogyan épülnek fel a library-k) és az összes library non-blocking-ra konfigolható tehát könnyen fűzhető hozzájuk más (és RTOS-hoz is jó). Azt vettem észre, hogy egész jól használhatóak c++-al együtt is (bár a harmony még nem erre van kitalálva - kicsit szenvedős ezen a téren) Lezárásként az eddig itt hallottakból egy fél-egy éves használat után pozitív csalódást hozott. Valamint amit egyre fontosabbnak tartok az elnevezési konzekvencia - itt kifejezetten jól sikerült
Az MZ-ket nem nagyon néztem, mert nem kellett az a sebesség, na meg kell a periféria, bár főleg kommunikációs. Most is olyanon töröm a fejem amihez minimum 1 IIC, 2 SPI és 2 UART kell, (teszthez 3 UART). Illetve a v1 már kész van, de dolgozom a v2-n. Meg úgy gondoltam az MX-ek jobban kiforrtak már, de úgy nézem amit egyszer kiadnak az úgy marad. A minap böngésztem ehhez a projekthet az MX-eket és nem nagyon találtam olyat amiben megvolt az összes szükéges periféria és ne lett volna hibás valamelyik. Némelyik megkerülhető, de vannak nagyon durvák is.
Az MX-eket azért nem fejlesztik tovább, mert ha el tudják adni a havi díjas (!) MZ fordítót, az sokkal többet hoz a konyhára. Még nem eldöntött játék, tényleg nyerik-e azt a meccset, vagy csak átkergetik a teljes közösségüket másik gyártóhoz. Egyenlőre úgy tűnik, nem a tapasztaltabbik irányban haladnak a lejtőn.
Sziasztok!
20 ms-onként szeretnék 1->500 us-ig változtatható kitöltési tényezőjű jelet előállítani. Ehhez beállítottam a TMR1 megszakítást 20 ms-ra a TMR2-őt pedig 1 us-ra. TMR1-ből indítom TMR2 megszakítást 20 ms-onként. A rendszer órajelem 32 MHz. Ilyen módon a kimeneten mért jelet nem sikerült 4,5 us alá vinnem. (Ekkor a megszakításban csak egy kimenet állítás van, meg az interrupt flag törlése.) Így megpróbáltam egy olyan variációt is, hogy a 20 ms-os megszakításba tettem egy szoftveres késleltetést (tudom, hogy nem szép dolog), így 270 ns-ig képes voltam lecsökkenteni a kimeneti jel magas szintjének idejét. (A felhasznált PIC 16F18857 típusú) Ezt a feladatot továbbra is időzítőkkel szeretném megoldani, van valami ötletetek esetleg? A válaszokat előre is köszönöm! A hozzászólás módosítva: Nov 1, 2018
1 us megszakítás helyett nem lehetne valami haladottabb módon előállítani az impulzust, pl. az adatlap 29.5.5 SOFTWARE START ONE-SHOT MODE alfejezete szerint?
Ez annyit csinál, hogy minden túlcsordulás után törli az engedélyező bitjét nem? Tehát mindig engedélyeznem kell a 20 ms-os megszakításban. Egy láb magas szintbe állítását viszont így is a TMR2 megszakításban kellene elvégeznem nem?
"Tehát mindig engedélyeznem kell a 20 ms-os megszakításban."
Nekem úgy tűnt, hogy igen. Idézet: Pont azt szeretném elérni, hogy erre ne legyen szükség.„Egy láb magas szintbe állítását viszont így is a TMR2 megszakításban kellene elvégeznem nem?” De ennek részleteit az adatlapból kell kisilabizálni. Futólag olvasva ott volt olyasmi, hogy PWM-mel kell kombinálni, hogy kiadja az impulzust. De nem merültem el a részletekben, mert nem használok ilyen mikrovezérlőt (és a jövőben sem szeretnék).
Rendben köszönöm! Most egyébként az NCO-t és a TMR2-t hoztam össze CLC modul segítségével (S-R tárolóként használva). Egész jó úton haladok így is, de próbálkozok még a one-shot móddal is.
Sziasztok!
Adott a PIC32MM0256GPM028 32bites pic. Sajnos a fordító nem engedi beincludolni a plib.h-t mert hiányol valami megszakítást. Szeretnék pár bájt adatot letárolni a flash-be, hogy kikapcsoláskor ne veszítse el, hogy következő bekapcsolásnál visszatölthessem. A dee_emulation_pic32-t hívtam segítségül, de ez is a plib.h-t akarja beölteni. Megnéztem milyen függvényeket használ, NVMUnlock,NVMWriteRow,NVMWriteWord,NVMErasePage,NVMProgram. Ezeket megkerestem neten, beletettem. A program lefordul, de nem működik. Nem tárolja el az adatokat, és kiolvasni sem tudja.
Ezeket az egyszerű függvényeket írtam. Sajnos írásnál is 6-os hibakóddal tér vissza. A DataEEWrite függvény leírásában a hatos hibakód : Value 6 for page corrupt status. Erről a sorról van szó:
Itt is az e-> 6, tehát a DataEERead is 6-os hibakóddal tér vissza. Itt ez Value 6 for page corrupt status.-t mond. Van valakinek valami tippje mi lehet ez? Elküldöm mellékletbe a saját dee_emulation fájlomat. Nagyon hálás lennék, ha valaki tudna segíteni, más nagyon sok órám ráment erre az egészre. A hozzászólás módosítva: Nov 15, 2018
Moderátor által szerkesztve
A DataEEInit -et lefuttatod a függvények futtatása előtt?
Nem, az kimaradt De most pótoltam, és a hiba pontosan ugyanaz sajnos.
Az init 7-es hibakóddal tér vissza: Value 7 for write error.
Gyors átfutásból azt látom, hogy a NVMWriteWord-ot nem lesz jó ehhez a PIC-hez.
Idézet: „The memory can be programmed by rows or by two 32-bit words, called double-words.” Az NVMDATA0/1 nem egy 32 bites upper lower half hanem 64 bites regiszterpár. Ez biztos, hogy az egészet fel fogja borítani, de csak így használható ezen a PIC-en.
Megoldottad a problémámat! Nagyon köszönöm!
Sikerült megcsinálni, gondoltam megosztom veletek. A választott PIC végül a PIC18F4620 lett. Egy ideig félre raktam a dolgot, de kb 1 hete megint előszedtem.
8. pontként írhattam volna még ezt is: PIC16: MOVFW SET_FREQ_2 PIC18: MOVF SET_FREQ_2,W mivel nem így csináltam ezért sok minden nem is működött Azt egyébként nem is írtam, hogy először PIC18-on nem is sikerült az EEPROM-ba menteni. Amikor kézi hangolás után el akartam menteni az adott csatornát, a szükséges 7 byte-ból mindig csak az elsőt mentette le. Nem is tudtam mire vélni a dolgot. Úgy sikerült megcsinálni, hogy az írási műveletek között várok pár száz msec-et. Kép A hozzászólás módosítva: Nov 21, 2018
Hali! Nekem ez működik 4620-on mplabc18\v3.38\
Köszi, hogy megmutattad! Az enyém pedig így néz ki:
A hozzászólás módosítva: Nov 21, 2018
Olvasáshoz nem kell tiltani a megszakítást.
PIC18F2620 -on jól működik:
A hozzászólás módosítva: Nov 21, 2018
Mert ezt kihagytad: while(EECON1bits.WR); ehelyett várakozol időtlen ideig
pic adatlap: At the completion of the write cycle, the WR bit is cleared in hardware and the EEPROM Interrupt Flag bit, EEIF, is set. The user may either enable this interrupt, or poll this bit. EEIF must be cleared by software. érdekes hogy a mintapéldában sincs benne csak szövegesen felette... A hozzászólás módosítva: Nov 21, 2018
Hali!
Szerintem se, de valami bajom biztos volt vele, ha beleraktam rég volt
Köszi a tippet, működik várakozás nélkül! Látszik, hogy nem vagyok egy nagy programozó
Nem akarok semmit mondani.
XC32 v1.44 "xc32installdir\pic32mx\include\lega-c\machine\types.h"
Ugyanez "pic32mx\include\Cpp\c\stdint.h" alatt is.
még egy helyen hiba volt ezen a 3 helyen találtam hibát "C:\Program Files (x86)\Microchip\xc32\v1.44\pic32mx\include\lega-c\machine\types.h" "C:\Program Files (x86)\Microchip\xc32\v1.44\pic32mx\include\Cpp\c\stdint.h" "C:\Program Files (x86)\Microchip\xc32\v1.44\pic32mx\include\Cpp\c\machine\types.h"
Sziasztok!
Szerintetek bennem van a hiba? PIC320256GPM064-et próbálok sleep módban hajtani (OSCCONbits.SLPEN=1, PWRCONbits.VREGS = 0) doksi-ban a DC61-es paraméternél +25 °C max 30µA-t írnak én az OSC1-es external-os dolgot leszámítva mindent ugyanúgy csináltam de nálam 560µA mutat a multi és mindez ha nem LPRC-ről megy hanem FRC 8MHz akkor nagyobb mint 1 mA miközben a sleep mode-os reference-ben Idézet: „ The oscillator behavior in Sleep mode is as follows: • If the CPU clock source is POSC, the oscillator is turned OFF in Sleep mode • If the CPU clock source is FRC, the oscillator is turned OFF in Sleep mode • If the CPU clock source is SOSC, the oscillator will be turned OFF if the SOSCEN bit is not set” Értem én hogy a megadott 30µA csak design kalkuláció, de azért a design és a valóság között csak nem 20 szoros torzítás van. Lehet inkább egy EFM32 választok ha már úgy is energy micro néven fut... A hozzászólás módosítva: Feb 17, 2019
A legegyszerűbb tipikus hibák egyike ilyen jellegű: nincs valahol egy felhúzó ellenállás egy kimeneten, mely alacsony szinten van? )
Bakker...
Egy Curiosity-t használok épp nem is értem miért nem jutott eszembe hogy van rajta egy csomó felhúzás és azokat szépen a PIC-el drainelem... Így megszűnt az oscillator-al kapcsolatos hiba most FRC 8MHz-en ugyanannyit mérek mint LPRC-vel. Viszont ez az ugyanannyi még mindig 100µA. Érdekesség ha nem nyúlok a TRIS-ekhez és minden bemenet akkor ~260µA-es áramot mérek (lassan áll be az érték) ha a kimenetekre állíthatóak kimenet és '0'-ra vannak állítva akkor 98-100µA-t mérek. (Bár ez várható emlékeim szerint a digitális cuccok nem szeretnek "lebegni") Szerinted/Szerintetek mit lehetne még tenni? Vagy elégedjek meg ezzel mint közép út?
Ha az adatlap 35uA-t közöl, akkor annyit tud is a uC. Neked kell felderíteni, hogy merre folyik még áram. Hogy elég-e a 100uA, azt csak te tudhatod.
Idézet: Ha az errata nem mond ettől eltérőt, akkor lehet, hogy tényleg 35uA, de mikrocsip esetén ebben sem kell biztosnak lenni, sajnos. „Ha az adatlap 35uA-t közöl, akkor annyit tud is a uC.”
Hali!
A stab kocka áramát is beleméred? Meg van a panelon még más aktív cucc is... |
Bejelentkezés
Hirdetés |