Fórum témák
» Több friss téma |
Fórum » CCS PIC Compiler
32 bites, mint a float, az lehet helyette.
Gyanítom hogy float, de ha a help azt írja hogy "not a supported data type" akkor miért erőlködsz vele?
Nem szerencsés a compiler jóindulatában bízni.
Egy netről kukázott kódban volt, de amíg nem tudtam, hogy mi akar lenni, nem tudtam helyettesíteni. Futni fut ezzel is, de szerintem túlcsordulnak a dolgok, meg nem tudom mennyire szereti a pwm modul, ha nem egész szám a kitöltési tényező...
Kitöltési tényezőnek mindenképpen egész számot fog kapni a PWM modul, mivel az egy áramkör, aminek van 10 bemeneti bitje, ami vagy 1 vagy 0. A fordító konvertálja a float tipust egészre, amikor írsz a PWM modulba. Persze ez elég gány munka, jó eséllyel az egész számítást lehetne végig egész számokkal végezni. Hol található ez a kód?
Esetleg megosztod velünk hogy mit értesz "tulcsordulnak a dolgok" alatt? Mi a jelenség amit tulcsordulásnak vélsz?
A PWM ahogy Potyo is írta 10 bites, ha 16 bites értéket adsz neki majdnem biztos hogy a felső 6 bitet fogja levágni, azaz ha 1025-öt állítasz be PWM-nek akkor az csak 1 lesz. Ostoba kontrollerek! 1025 = 1 ![]()
EZ az eredeti. Az üres funkciói persze ki vannak dobva. Amiben használom, a bemenő jel egy kb 15 és 25 közti szám, amit igyekszünk kb 20-on tartani (alapjel=20, amit kiszámol, az pedig megy pwm kitöltési tényezőnek)
Ha sorosporton kiírom gépre a bemenő jelet és a kitöltési tényezőt, jól látni hogy szabályoz, csak hajlamos negatív számot kiírni kitöltési tényezőnek...
Sziasztok Urak!
A segítségeteket szeretném kérni... A szitu a következő: Jelenleg egy USB-CAN adapteren dolgozom gőzerővel és elakadtam. Kb. fél éve hozzájutottam a Neten egy hevenyészett és - mint később kiderült - sok hibával "ellátott" leírásnak. No, mindegy, a tervezésben segítségemre volt, kész a működő, tesztelt áramkör, megírtam az eredetileg C++ -ban írt, PC oldali programot segítségül véve a sajátomat C#-ban (ne tudjátok meg, több szálú, párhuzamos programfutások, stb.) és most ott tartok, hogy az eredeti PIC bootloader beégetve, a PC szépen át is küldi a végrehajtó program HEX-ből megfelelően betöltéshez átalakított, címmel ellátott sorait és mindjárt az első sornál FLASH írási problémát jelez. Azt leteszteltem, hogy odáig minden rendben van, a programok mindkét oldalon jól működnek, a FLASH manipuációnál akad el a dolog, a hibát is (a javítások után most már) korrekt módon visszajelzi a PC-nek. Azért akadtam el, mert a FLASH rész assemly-ben van írva én pedig ahhoz láma vagyok, nem értek. Az eredeti progit PIC18F258-ra írták, én az áramkörben PIC18F2580-at használok, összehasonlítottam az adatlapokban a progi szerint fontos címeket, ezeket azonosnak találtam, de lehet, hogy tévedek. Csatolom az eredeti CCS C-ben írt bootloadert, kérlek benneteket, nézzétek át az assembly részt, meg a címeket, hogy vajon miért nem tudja írni a FLASH-t... Én már ott tartok több hét szenvedés után, (biztosan Ti is voltatok így) hogy csak nézem a listát, de már nem is látom... ![]() ![]() Előre is köszönöm a segítséget, a megmentő a következő találkozón komoly sörökre számíthat tőlem. ![]()
Ja, igen, elfeledtem leírni: a csatolt programban csak annyit írtam át, hogy kijavítottam a PIC típusát, és kikommenteztem az ICD2-re vonatkozó 3 sort, mert én PICKIT-tel dolgozom.
Az adatlapban is benne van:
Idézet: „PIC18F2580: 7.5.1 FLASH PROGRAM MEMORY WRITE SEQUENCE ... 6. Write the 32 bytes into the holding registers with auto-increment. ... 13. Repeat the question three more times.” A programodban és a PIC18F258 adatlapjának ajánlása ugyanezt a 64 bájtot 8x8 bájtra bontva írja - ez a fő különbség! Idézet: „PIC18F258: 6. Write the first 8 bytes into the holding registers... ... 14. Repeat steps 6-14 seven times to write64 bytes.” * Megjegyzés: ez a "three more times" netán sajtóhiba az adatlapban (copy-paste effect)?
Az előzőek értelmében az "assembly részben" a ciklushatárokat kellene átírni:
i = 2; while (i--) { j = 32; while (j--) { Ráadásul ez C nyelven van! ![]()
Nagyon köszönöm, hogy energiát és időt áldozol rám és segítesz. Beírtam a változtatást a programba, de sajna ugyanaz az eredmény.
![]() ![]() Csatolom a memória file-t. Az jutott az eszembe, hogy vajon nem lehetne ezt az egész metódust a CCS C WRITE_PROGRAM_MEMORY / READ_PROGRAM_MEMORY parancsával lecserélni, hiszen azt pont a PIC18-ra találták ki? (lehet, hogy tévedek, még soha nem próbáltam) Mi a véleményed? Idézet: „Az jutott az eszembe, hogy vajon nem lehetne ezt az egész metódust a CCS C WRITE_PROGRAM_MEMORY / READ_PROGRAM_MEMORY parancsával lecserélni, hiszen azt pont a PIC18-ra találták ki?” Nem tudok hozzászólni sem a CCS C-hez, sem a programmemória íráshoz. Csak "gyári" bootloadereket használok. De mégegy különbséget látok az adatlap ajánlása és az általad belinkelt program között: az alábbi szekvenciák előtt kellene egy BCF INTCON, GIE interrupt tiltás, utána meg egy BSF INTCON, GIE interrupt újraengedélyezés is.
Igen, bár a Main-ban GLOBAL interrupt letiltás van, gondolom, ezt ezért hagyták ki. Ami érdekes viszont, hogy a "még háromszori" ismétlésre való hivatkozás nem nyomdahiba, hanem egy 4-es hurok, amely az adatlapon levő assembly listában is megtalálható, ott, ahol a 258-nál a 8-as hurok "PROGRAM_LOOP" van.
Ez így elég logikátlannak tűnik. Az Erase blokk mérete ugyanis általában 64 bájt, a Write buffer mérete pedig 8/16/32/64 bájt (típusa válogatja, a pic18f2580 típusnál 32 bájt). Mivel törölni mindig legalább 64 bájtot kell, írni pedig egyszerre annyit lehet, amennyi write buffer mérete, így annyi egységet kell írni, hogy a végösszeg 64 bájt legyen. Jobb adatlapokban pl. így írják:
Bocs, közben el kellett szaladnom ügyeket intézni...
Igen, szóval nem értem a dolgot. Az adatlapok memória írási szekvencia-leírásai is egyformák, az adatbyte számok kivételével (8 helyett 32) a két adatlap-programlistát letéve egymás mellé, a ciklusszámok kivételével ugyancsak egyformák... de mégsem működik a program, sem 2x32, sem 4x32 ciklussal.
Hát, ez nem akar sikerülni...
![]() ![]()
Valami egyszerű próbaprogramban próbálnám ki a flash írását. Természetesen ellenőrizném a címet is, mert ennek így mennie kellene.
Csak egy ötlet. Nem kell a config biteknél engedélyezni az önprogramozást és/vagy az alacsony feszültségű programozást?
Bocs, a választ 'Jossz'-nak szántam.
Szerintem nem, mert az önprogramozás alapból engedélyezve van, az LVP pedig a külső programozásra vonatkozik, s lefoglalja a PGM lábat.
Ahogy icserny mondja, úgy igaz. Szerintem valamelyik cím, ill. programozási határérték (cím) van elszúrva. Most azt csinálom, hogy találtam a CCS C példái között egy általános bootloader programot (Ex_bootloader.c) ebből fogok kiindulni, először kipróbálom úgy, hogy egy hex sort beleírok a programba, mintha úgy kapta volna a buszon (ugyanis a kommunikációs részt kiteszteltem a hibás progiban és az korrekt módon működik), és ha úgy működik, akkor szépen ebbe az új programba rakosgatom át a többi kommunikációs és dekódoló metódust a hibás programból. Előbb-utóbb ki fog derülni, hogy milyen hibát is raktak bele az eredeti programba...
![]()
Nekem az jutott eszembe, hogy amikor én a soros portos bootloaderemet írtam, akkor figyelni kellett arra, hogy a az írás elindítása után van egy idő, amíg a kontroller teljesen kuka. Azaz semmiféle utasításvégrehajtás nem működik olyankor, és erre figyelni kellett a kommunikációban, mert ha túl gyorsan borítottam rá az adatokat, akkor a következő blokk eleje elveszett. Elég rég foglalkoztam vele, ezért csak halványan dereng, de lehet, hogy érdemes lenne ennek is utánanézni.
Ezt írja az adatlap is, hogy írási egységenként (8/16/32 bájt) ~2 ms-ig nincs utasításvégrehajtás.
Lenne valakinek ötlete, hogy hol lehet megtalálni a #fuses direktívák leírását? Ugyanis nagy a gyanúm, hogy a problémámban a WRT beállítások játszanak szerepet. A gondom az, hogy 4 féle WRT is van, az eredeti programban a WRT, WRTB használatos, csakhogy a 2580-as MCU-nál lehet, hogy mást kell használni. Szóval jó lenne tudni, hogy mi mit is jelent pontosan...
![]() Idézet: „hol lehet megtalálni a #fuses direktívák leírását?” Az adatlapban (konfigurációs bitek), de az MCC18 fordító is szívesen felsorolja: mcc18 --help-config -p18f2580 > pic18f2580.txt mcc18 --help-config -p18f258 > pic18f258.txt A belső írást/olvasást szerintem csak az EBTR kezdetű konfigurácós bitek befolyásolják (táblaolvasás). Én úgy tudom, hogy a kódvédelem (CPx) és az írásvédelem (WRTx) csak a PGC/PGD lábakon át végzett programozáskor hatásos.
Hali
Hat szerintem az eszkoz header file tartalmazza a fuse bitek leirasat. (ha jol ertem a kerdest). Udv Vili
Szia!
A CCS C-ben az eszköz header file-ok csak a fuse direktívák felsorolását tartalmazza, tehát, hogy az illető MCU-nál milyen direktívák használhatók. Icserny jól mondta, az Microchip C-ben az ottani eszköz definíciók szövegesen is tartalmazzák a direktívák leírását.
Hello!
Van egy dsPIC30F2010-em ezt szeretném motorvezérlésre használni, de ehhez először be kellene állítani a a pwm modult és ezzel van problémám. A reference manualban van ehhez kapcsolódó leírás: MOTOR CONTROL PWM // Sets up the motor PWM module setup_motor_pwm(1,MPWM_FREE_RUN | MPWM_SYNC_OVERRIDES, timebase); // Sets the PWM1, Unit A duty cycle value to 0x55 setup_motor_pmw_duty(1,0,0x55); //Set the motor PWM event set_motor_pmw_event(pwm,time); set_power_pwm0_duty(duty_cycle)); // Sets the duty cycle of the PWM 0,1 in //Complementary mode Több kérdésem is lenne: timebase helyére mit kell írni? a PWM-hez a Timer 2 vagy Timer 3 kell de ezt hogyan kell beletenni ebbe a példába? És kell még valamit beírni hozzá hogy ez működjön? Bocsi ha nagyon amatőr a kérdésem de nem jutottam semmire vele.
Na, végül sikerült elindítani a ketyerét
![]() Átírtam a program assembly részét, kidobtam az egészet és a CCS C write_program_memory parancsot használtam, ezzel beindult és teljesen korrekt módon megírta a flash-t. Mejegyzem lapszélre, a PIC18F2580-hoz kétféle adatlapot is találtam, az egyik 2004-es, abban még 8x8-as ciklust ír, a másik 2007-es (ezt nézted Te is), abban meg ott az a hiba, hogy 4x32-es ciklust írt. A PIC18F4680-as esetében (megnéztem, mert egyébként a CAN moduljaimban azt használom) már 1x64-es ciklust ír, ami már hihetőbb. ![]() Szóval azért van kis kavarc és persze ez mindig akkor viszi el az erdőbe, amikor legjobban kellene a jó megoldás... Az erase / write / read_program_memory parancsoknak éppen ez az előnye (most már látom), hogy függetleníti a programozót az alkalmazott MCU paramétereitől, mert a compiler lerendezi a dolgot. Persze abban csak reménykedni lehet, hogy a compiler nem hibázik ![]()
Örülök,hogy végül sikerült működésre bírni a programot!
Idézet: Elvileg abból az adatbázisból dolgozik, amit a Chipedit.exe programmal meg lehet nézni (talán javítani is lehet?).„Persze abban csak reménykedni lehet, hogy a compiler nem hibázik” Hibák mindenhol lehetnek, az MPLAB eszközleíró állományaiban is találtam már elírást... |
Bejelentkezés
Hirdetés |