Sziasztok!
PIC18F45K22-nek a ECCP3 moduljával (és a timer2-vel) szeretnék PWM-jelet (1kHz-et) előállítani de nem jön össze a dolog. Így néz ki az ide vágó rész:

Szkóppal nézve stabil H szint van a PIC 8-as lábán, azaz az RE0-án. Mit nem állítottam be, vagy mi lehet a probléma?

A configban is jól van beállítva, hogy a CCP3-nak az RE0 legyen a kimenete?

Igen, az adatlap szerint az RE0 neki az alapbeállítása. Viszont közben rájöttem a hiba okára:

Az 5db CCP moduljából három hibás az errata szerint. Átírtam az ECCP1-re és ott azonnal megjelent a PWM jel. Marad is ott.

dsPIC33EP512GP504-et használok, melynek 512kB programmemóriája van. Ennek ellenére a dashboard-on azt írja hogy a programmemóriája 175094 szó, vagyis kb 350kB. Azaz hiányzik még legalább 160kB és mint azt a sárga csík is mutatja, igencsak szükségem lenne rá Miért írja ki rosszul? És nem csak a kijelzés rossz amúgy mert ha beleírok még néhány sort a programba akkor nem is fordítja le mert szerinte az már nem fér bele a PIC-be.

24 bites a program memória (3 byte).

Ja értem. Tehát a static const unsigned char... tömböm minden egyes bájtja gyakorlatilag három bájtot foglal. Nem lehet valahogyan megoldani hogy harmad annyit foglaljon, azaz 24 biten tényleg 24 bit legyen?

- Programterület láthatóság (PSV) hozzáférés esetén az adatmemória címtartományába leképezett lapon a 24 bites szavakból csak az alsó 16 bit látszik, tehát egyharmada nem érhető el.

- A speciális tblrd utasítással elvileg minden egyes bájt hozzáférhető.

Bővebben: Link

Világos. És hogyan lehet a programmemóriába úgy letárolni 8 bites számokat (static const unsigned char xyz[] =) hogy eszerint pakolja őket össze, azaz egy 24 bites szóba ne egy tömb értéket (char) tegyen hanem kettőt. És mellékesen kérdem, hogy a legfelső 8 bit az miért van, annak mi az értelme? Néztem az MPLAB-ban a programmemóriát és mindenhol 0x00 a felső harmada. Elég nagy pazarlásnak tűnik, nem értem...

Szerk.:
Mondjuk a legjobb persze nyilván az lenne ha egy szónak mind a három bájtját lehetne adattárolásra használni. Még egyszerűbb is lenne talán, mert a PSV csak 32kB-ot fog át és akkor azt folyamatosan kellene görgetni ahogy játssza le a hangfájlt. Akkor meg kérdés hogy C nyelven hogyan lehet olvasni az egész szót, ahogyan a tblrd utasítással. És persze hogy hogyan lehet egy szóban három bájtot letárolni.

Talan ugy gondoltak, hogy az az 512 kbyte eleg sokmindenre. A PC-kben is csak 640 volt eleinte, mert billgec szerint az eleg kell, hogy legyen.
Csak halkan jegyzem meg, hogy ha assemblyben irnad a progit, akkor valoszinuleg kisebb helyet foglalna...
Ha meg oriasi adatteruletre van szukseged, akkor tegyel bele egy SDkartyat, a legkisebb is 4Mbyteos. Es atirni is sokkal egyszerubb. De eeprom is lehet, azokbol is van mindenfele meret, mindenfele sebessegre.

Nem tudom, hogy C nyelven hogyan megy a letárolás a programmemóriában. A tblrd utasítás használatára van egy példa a C30 helpjében. Abban sajnos az EEDATA elérésére használják, de talán némi némi támpontot nyúlt ez is:

Ha tudnád int -ként tárolni char helyett, akkor már 2x annyi helyed lenne. Mármint a char-okat összefűzni int-é.
Lehet hogy az XC16-nak meg lehet valahol mondani, pl.: project properties-ben, hogy a páratlan memória címekre is fordíthat azokból a char-okból.

Többiektől is kérdezem, az xc16-gcc beállítások alatt van egy olyan mező, hogy "Fillupper value for data in flash". Ez nem lehet az?

A kisebb PIC -ek utasításai 11 bitesek (3+8) Úgy tudom a tárolás is idomul hozzá, így az egyik byte helyből elveszett adattárolásra ( ill csak 3 bit marad belőle). A nagyobb PIC-eket mondjuk még nem néztem.

Baseline: 12 bites utasítás, szavas címzés.
Midrange és Extended Midrange: 14 bites utasítás, szavas címzés.
18F: 16 bites utasítás, byte-os címzés.
24F, 30F, 33F, 24E, 33E: 24 bites utasítás, byte-os címzés. A címzés miatt az utasítások ugyan 24 bitesek, de 32 bitet foglalnak.
32M: 32 bites utasítás, byte-os címzés.

Mindhárom bájtot lehet adattárolásra használni. Assemblyben meg lehet adni hogy az adatokat folyamatosan tároljuk le, vagy a PSV-nek megfelelően. (A kiolvaszás ilyenkor persze kissé macerás, mint a FAT12 fájlrendszer esetén.)
A TBLRDH ill. TBLRDL utasításokkal külön-külön lehet elérni a 24-bites adat felső ill. alsó részét. A PSV-t használva pedig többnyire csak az alsó részt érjük el, de bizonyos (újabb) mikrovezérlőknél lehetőség van a felső rész elérésére is. (Sajnos nem egyszerre; egy időben vagy csak az alsót, vagy csak a felsőt látjuk.)
Azért mert az utasításszavak 24-bitesek. Az adatbusz viszont csak 16-bites (és bájtonként címezhető).

Nem értek a C-hez, de szerintem az csak azt adja meg, hogy a 24-bites adat felső kihasználatlan 8 bitjét milyen állandóval töltse fel.

Valóban.

Egy kis kiegészítés a sok RAM-mal megáldott PIC24-esek PSV funkciójához:
Itt a 0x8000 feletti memóriaterületet nem PSV (Programterület láthatósági) ablaknak, hanem EDS (Bővített adatterület) ablaknak hívják, és itt érhető el a belső adatmemória 30kB feletti része, a külső adatmemória (EPMP), ill. a programmemória (PSV, külön a felső és alsó szavak) 32kB-os lapokon..

A programom a memóriának csupán kb 3%-át foglalja le, a többi 96% kb 20 másodpercnyi hangfájl a PIC programmemóriájában.

SD kártya ide nem igazán jó és teljesen felesleges is mert csupán néhány másodpercnyi hangot szeretnék lejátszatni a PIC-kel ami simán belefér ebbe a PIC-be, talán még így is hogy csak harmad annyit tudok beletenni mint amennyit lehetne. De most már csak azért is furdalja a kíváncsiságomat, hogy hogyan lehetne a teljes szót kihasználni adattárolásra.

icserny!


Zsora!


Ha C-ben nem megy akkor legyen assembly! Bár ilyet még nem csináltam sosem, de a C programban is át lehet váltani assembly-re, szóval akkor legyen úgy. És assembly-ben hogyan lehet úgy telerakni a programmemóriát hogy a szavainak mindhárom bájtja azt az adatot tartalmazza amit szeretnénk?

A mellékelt képen háromféle adatelhelyezés látható:
Piros: A PSV területen helyezünk el konstansokat. A felső bájtok nem használtak. (Itt 0.)
Zöld: Inicializált változókat helyezünk el. Az adatok minden bájtot kihasználnak, viszont területfoglalás nemcsak a ROM-ban van, hanem a RAM-ban is, ugyanis a változók a RAM-ban vannak, de a kezőértékük a ROM-ból töltődik be.
Kék: Programkód ill. konstansok elhelyezése. Egyaránt tudunk a PSV-nek megfelelően, ill. minden bájtot kihasználva adatokat tárolni. (1 bájt, vagy 3-bájtos szó)

Neked - szeintem - a Code szekcióban történő bájtos adatmegadás lesz a legmegfelelőbb.
(.code / .pbyte)

Köszönöm, majd próbálkozom még.

Közben viszont egy másik problémába ütköztem:
Ugyan erről a PIC-ről van szó (dsPIC33EP512GP504), a 44-es lábát azaz az RB8 portlábat szeretném egyszerű digitális bemenetnek használni. A "PORTBbits.RB8"-al olvasva 0-át kapok és a debuggerben a Variables fülön is 0-át ír az MPLABX. Viszont a lábon a digimulti szerint állandó 3,3V van. Ezek vannak az inicializálásnál amik ide vonatkoznak:

A PIC 44-es lábán az adatlap szerint ezek vannak:

Elvileg minden perifériának le kellene lennie kapcsolva ugyebár de biztos ami biztos debuggerben megnéztem; a CVREF1O és az ASCL1 biztosan tiltva van, mert:
CVRCONbits.CVR1OE=0 (Voltage level is disconnected from then CVREF1O pin)
I2C2CONbits.I2CEN=0 (Disables the I2Cx module; all I2C™ pins are controlled by port functions)
A TCK (JTAG órajel-bemenet) és a T4CK (timer4 órajel-bemenet) funkciókat nem találtam meg hogy hol vannak tiltva vagy engedélyezve. De biztos ezek is le vannak tiltva.
Szóval miért mondta azt a PIC hogy L szint van az RB8 lábán, mikor ez nem igaz? Erratat is néztem már de nem szól ilyesfajta hibáról.

Analóg funkció tiltása a lábon?
(ANSELBbits.ANSB8 = 0)

Az a láb nem tud analóg lenni.

Azért én kipróbálnám.
Mégegyszer: ANSELBbits.ANSB8 = 0

És tényleg!
Akkor mégis tud analóg bemenet lenni a láb, csak elfelejtették ráírni a PIC lábához az adatlapba.
Köszönöm!

A CV_REF1O az analóg kimenet. Minden analóg funkcióra képes láb (nem csak az ANx lábak!) induláskor analóg módban van, ezért kell tiltani azt.

Amúgy miért akarod kódból csinálni? Nem erre való.
Az adatodat amit tárolni akarsz konvertáld át valahogy object-é (makefile-ba beleírod hogy a build során generálódjon erőforrás fájl a tárolandó adatokból).
Linker szkriptben írd át, hogy a generált object fájlokat (program) a memória első x részébe tegye (azaz védd le a flash pl utolsó y lapját) majd a flash végére (kézzel megadva a címet) a linker szkriptből fűzd oda binárisan amit akarsz. A kódban meg csak a kezdőcímet kell megadnod, de akár még az is jöhet a linker szkriptből és szimbólumként hivatkozol a kódban rá.
HITECH-C toolchain-el csináltam ilyet pár éve. XC16 alatt kicsit másképp működik a linkelés, de biztosan megoldható (alapvetően nincs is linkerfájl.. legalábbis nem generálódik egy alapértelmezett a projektbe).
XC16 alatt emulált EEPROM-nak is így foglaltam helyet, majd fűztem megfelelő helyre az alapértelmezett beállításokat. Igaz ott nem kellett erőforrás fájlt csinálni, hanem csak a generált konstans táblát kellett a megfelelő helyre tenni. Ez mplabx alatt GUI ból megtehető emlékeim szerint.

Vagy van egy ennél barbárabb megoldás:
Linkerben levéded a flash egyik területét (ismert cím,méret), az adataidból generálsz hex fájlt (megfelelő címre) majd make fájlban post build során összefűzöd a kettőt.

Ezekkel megoldható, hogy kihasználd a teljes flash területet.

Hűű..., a helyzet az hogy fogalmam sincs hogy megy ez, sosem csináltam még ilyet. Kónya-könyvben nincs erről írva, Cserny István oldalán sincs ilyesmikről információ és az XC16 user manual-jában sem olvastam erről. Én csak sima .c és .h fájlokat használok, azokat tudom mire vannak.
Először is hogyan kellene kinéznie annak a fájlnak mely az adatokat tartalmazza és amiből object fájlt kell generálni? Aztán hogyan lehet azt megadni a fordítónak hogy azt a kész object fájlt úgy ahogy van húzza bele a kész hex-be?

Sziasztok!

Egy PIC16F1459-es PIC-el próbálok a belső flash memóriába írni program futás közben.
A microchip által írt példák a Flash program memory control fül alatt működnek de csak 4MHz-ig ez a fő probléma. Se belső oszcillátorról se külsőről nem működik, ha nagyobb mint 4MHz.
Valaki tud erre megoldást esetleg + NOP utasítás kell valahova ?