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... És persze az a legbosszantóbb az egészben, hogy ha ez a hiba eltűnik, akkor szépen már működni fog az egész ketyere.
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.

Ez nem ilyen egyszerű, mert a két PIC különböző programozási specifikációval rendelkezik, tehát lehetnek eltérések a FLASH programozás részleteit illetően.

Bővebben: Link1, Link2

Az adatlapban is benne van:

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!


* 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. Kiexportáltam az MPLab-ból a memóriák tartalmát úgy, hogy először kitöröltettem az összes memóriát, aztán betöltöttem a bootloadert, aztán export, majd elindítottam a PC programról a feltöltést, (BAD_FLASH_WRITE hibával befejezte az első sor után), aztán megint kiexportáltam a memóriák tartalmát. Összehasonlíttattam a két file-t és byte-ról byte-ra megegyezett a kettő, tehát már az írás sem sikerült neki, nem csak az ellenőrző visszaolvasáskor észlelt hibát. Azt már tegnap kiteszteltem, hogy a flash_a_block metódusban a második 'return'-nál adja ki a hibát, tehát a címellenőrzésen még átmegy, az írás utáni ellenőrzésnél talál hibát, ami nem is csoda, hiszen nem ír semmit.
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?

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... Már mindent próbáltam, 2x32, 4x32, 4x16 ciklusokat, leellenőriztem az adatlap alapján az assembly részt, kiegészítettem a megszakítások letiltásával, egyébként a listához képest jónak is tűnik. Csak éppen nem működik, az első sor átvitele után Flash írási hibával jön vissza. Belenézve a program memóriába, ott pedig semmit sem csinált, egy byte-ot sem írt be sehova. Már azon gondolkodom, hogy nem-e a program címképzésével van gond és valami olyan címet számol ki, amely nincs is... Szóval kissé nagyon tanácstalan vagyok.

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

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!
Elvileg abból az adatbázisból dolgozik, amit a Chipedit.exe programmal meg lehet nézni (talán javítani is lehet?).

Hibák mindenhol lehetnek, az MPLAB eszközleíró állományaiban is találtam már elírást...