Sziasztok!
XC16. Nagyobb méretű adathalmazokat szeretnék használni, de ezt kapom:

Beállítottam a "Code model=Large", "Allow arrays larger than 32k" - bepipálva, de nem akarja az igazat.
Az adathalmaz deklarálásakor a "__psv__ const __attribute__((space(psv)))" módosítókat adom meg.

Mit kell még ezeken kívül beállítani, hogy megegye?

Én is bele futottam nem rég, nem emlékszem miért és mire jutottam, de megnézve a kódot ez lett nálam a vége:
const byte __attribute__((space(prog))) ....
Elég sokat böngésztem az XC16 user's Guide-t, de csak erre jutottam. Ha lesz jobb megoldás, engem is érdekelne.

Egyelőre nem sikerült megfelelően működő verziót találni...

Nekem már az is fura, hogy ha létrehozok egy tömböt:
char array0[70000] __attribute__((space(prog)))={[0 ... 69999] = 55};
Annak függvényében, hogy adok e neki kezdőértéket, vagy sem, más szekcióba teszi a fordító!
Ha nincs feltöltve, a .prog szekcióba kerül(ahogy az várható is lenne), ha fel van töltve, akkor valami fantázianév jön létre, és abba teszi.
Első esetben minden további tömböt ugyanabba a szekcióba tesz, míg második esetén, mindegyiknek generál egy külön szekciót.
Nem értem....

Sziasztok,
Egy kis segítségre lenne szükségem. Eddig 18F-es PIC-eket programoztam mpasm-ban.
Szeretnék használni PIC24F-eseket szintén asm-ben. Jelen esetben az XC16-os asm-et használom (csak asm, nincs C kód benne).
Hátha van valakinek XC16-os asm-ben tapasztalata.

Két helyen akadtam el:
1. hogy lehet kifejezéseket definiálni, amit a kódban fel lehet használni?
Az mpasm-ban pl. lehetett ilyet:
#DEFINE LED1 PORTB,0
#DEFINE Flag1 valtozo,3

A kódban meg felhasználni:
BSF LED1
BCF Flag1

Ezt hogy lehet XC16 asm-ben megoldani?

2. hogyan lehet egy változót egy adott memória helyre allokálni?
Az mpasm-ban ez így működött:
CBLOCK 0x093
valtozo
ENDC

Ezt hogy lehet XC16 asm-ben beállítani?

Át kell térni relokálható kódra. MpLab PIC24 Assembler users guide

Az általad linkelt doksit a C compiler-es doksi, de használom ennek az asm-es verzióját és abban rákeresve a 'relocat' szóra meglett a megoldás. Pedig mennyit kerestem, de nem találtam. Köszi a segítséget' Az 1. pontra nincs ötleted?

Mellényúltam. MpLab PIC24 Assembler users guide
Az 1. pontra a leírás 6.7 bekezdése ad megoldást.

Nem vagyok biztos abban, hogy a vesszőt tartalmazó szöveggel nem lesz probléma.

Ezt már próbáltam. Sajnos a vesszőt tartalmazó szöveget nem tudja értelmezni, ahogy te is megjegyezted. Azért köszönöm!

Szia!
Már régen írtam asm-ben 16 bites mikróvezérlőre még a régi MPLAB-bal. Abban úgy oldottam meg az 1. definiálást, hogy külön definiáltam a portot a címével és külön a bitet a számával, és a programban az utasításnál mind a kettőt meghivatkoztam, valahogy így:
.equ LED1_port, 0x1234 ; a 0x1234 a port címe
.equ LED1_bit, 0x03 ; a porton belül a bit helye
programban:
BSET LED1_port,#LED1_bit

Köszönöm a segítségedet. Jelenleg én is így használom, csak jó lett volna úgy használni, mint a 8bit-es mpasm-ban. Próbáltam macro-val is kiváltani, de az sem az igazi. Mindegy, majd megszokom.

Sziasztok!

Ma elkezdtem foglalkozni egy PIC32MX470F512H típusú kontrollerel. A maximális sebessége 120 Mhz és van rajta USB. Viszont bárhogy nézem a dolgot, nem tudom egyszerre megoldani az USB számára szükséges frekvenciát és kimaxolni a 120 MHz-et. Jól látom, hogy a kettő együtt nem megy ? A belső 8 MHz-es FRC csak az USB vonal aktivitásának detektálására jó, ebből viszont nem tudok órajelet osztatni az USB számára (amit nem értek, csak kéne egy kettes osztás és meglenne a 4 MHz), illetve csak 96 MHz belső órajelet tudok vele elérni. Ha példáúl egy 5 MHz-es külső kvarcot használok, akkor megy a 120 MHz, de ebből semmilyen varázslat folytán nem fog 4 MHz előjönni az USB számára.

Esetleg 48 MHz-es kvarcot akasztok a kontrollere, ekkor az USB órajele mehet direktben, viszont itt már nem használható a PLL, tehát a rendszer órajele is ez lesz.

Én látok valamit rosszúl, vagy a kettő együtt nem megy ? Esetleg használni a belső oszcillátort a 120 MHz elérésére és az USB kommunikáció detektálására és ilyen esetben átváltani egy külső, pl 4 Mhz-es kvarcra, amiből pedig már származtatható az USB órajele. Ha ez a helyzet, tudja valaki ennek mi az oka ? Elég esetlen megoldásnak tartom, hogy az USB kommunikáció fennállása alatt ennyire vissza keljen skálázni a kontrollert...

UI.: Az elírás, hogy az FRC-ből nem tudok 120 MHz-et csinálni.


Köszönöm!

Szia,

Alaposan átnézve a clock diagram-ot (Bővebben: Link) én azt látom, hogy be lehet állítani két külön frekvenciára, 48MHz-re az USB-nek és akár 120MHz-re a SYSCLK-nak. Ehhez mindössze egy 20MHz-es kvarc-ra lesz csak szükséged primary oscillator-ként valamit a következő beállításokra:
- USB: Posc-t (20MHz) leosztod 5-el hogy az USB-PLL bemenetén 4MHz legyen (UPLLIDIV = 0x4) így az USB-nek meglesz a 48MHz a Full Speed-hez.
- SYSCLK: Posc-t leosztod 4-el, hogy a System-PLL bemenetén 5MHz legyen (FPLLIDIV = 0x3) majd felszorzod 24-el (PLLMULT = 0x7) és a kimeneti osztót 1-re állítod (PLLODIV = 0x0), hogy megmaradjon a 120MHz.

Az FRC-t azért nem lehet még leosztani kettővel mert tudtommal 8MHz kell az USB-nek ha Low Speed (vagy esetleg low-power) módban van (idle) pl. mikor nem küld adatot de fenntartja a kapcsolatot a host-al.

Remélem tudtam segíteni, ha még nem oldódott meg időközben

Szia!

Köszönöm szépen, e felett a kombináció felett elsiklottam. Így tényleg jónak néz ki a dolog

Köszönöm mégegyszer!

Sziasztok!

Tudnátok ajánlani egy jó step-by-step leírást, ami egy bootloader felépítését és egy sima projektel való összekombinálását szépen leírná ?

A microchip application guidját elolvastam, ott átnéztem a kódot, hogy hogyan oldja meg. Viszont amikor a saját megoldásomat szeretném használni (én írnám meg, így megtanulja az ember hogyan működik), akkor az alábbi fordító hibát kapom:


A bootloader main-jét a boot memóriaterületre helyezem el a direktívával, a felhasználói kódot pedig hagyom neki elhelyezni.

Egy PIC32MX470F512H ról van szó. Utánaolvasgattam, hogy ilyenkor mi lehet a hiba (kombinálásnál a fordító hibának észleli hogy a két hex ugyanoda dolgozna, még ha a valóságban nem is), de nem teljesen látom át az itt alkalmazandó megoldást.

Ha bárkinek van bármi leírása vagy tippe, hogy miként kéne itt elindulni, azt nagyon megköszönném

MPLab-X-et használsz?
Ott ez úgy működött, hogy külön projektben megírod a bootloadert, utána a .hex állományát hozzárendeled a main kódhoz. Ezt a main projekten belül egy "loadables" könyvtárban való elhelyezéssel kellett megoldani.
Már nem tudom honnan vettem, de elég fullos MC app note-ok vannak BootLoader témakörben.

Én 8 bites MCU-val csináltam, de nem a kódon belül kellett megadni az abszolut pozíciót, hanem a linker beállítások között. project / properties / global options / linker
Azért ütközik a kódod, mert nem így csináltad.

Szia!

Igen MpLab X. Közben találtam egy leírást, ami egész jól végigvezetett. Tényleg a linkerrel kellett játszani. Ezt a fórumbeszélgetést követtem. Ebből nekem az alábbi beállítások születtek meg (PIC32MX470F512H):
Bootloader linker fő beállításai:


Felhasználói kód fő beállításai:


Tehát lényegében a bootloader kódját úgy helyeztem el, hogy a linkernek a programmemóriának megadtam a bootmemória területét. A felhasználói szoftvernél pedig mindent eltoltam.
Így most szépen lefordul és egyenlőre egyszerűsítve (a bootloader csak elugrik a felhasználói szoftverre) a szimulátorban azt csinálja amit szeretnék. Illetve tényleg két projektet hoztam létre. Az egyik a felhasználó szoftver, a másik a bootloader. A felhasználói szoftvernél pedig loadable-ként behúzom a bootloader projektjét.

Kicsit kacifántos, de most működik Viszont meg kell tanulnom a linker rejtelmeit, hogy átlássam az egésszet ...

UI.: Mint kiderült 1.3 fordító felett ehhez a megoldáshoz szükséges a felhasználói szoftver linkerjének egy plusz részt beszúrni:

Ha már szimulátor..., nem tudja valaki, miért van az, hogy mostanában a szimulátorban csak akkor látszanak jól a változók értéke, ha legalább modul szinten definiált a változó, lokális, függvény belüli deklaráció esetén teljesen agyament dolgokat ad vissza a szimulátor! Kipróbáltam több MpLabX verziót is(más gépen is), de a jelenség maradt...

Mire gondolsz? Függvényen belül definiáltam a pb_clk változót. Mutatja a típust és az értéket is.

Igen, erre! Nekem is mutatja..., csak éppen köze nincs ahhoz ami a valóságban ott lenne!
Ha kiteszem a változót modul szintűre, akkor jól mutatja a benne lévő értéket...

A szimbólum betöltés jó? Az .elf és a .map fájl lehet esetleg hibás (nem tudom pontosan itt melyik mire van használva), így nem ott keresi a változót ahol kéne.

Szívesen, örülök, hogy segíthettem.

Srácok, PIC18F452-enél van mód a programmemóriát úgy használni mint egy flash memóriát?
16Kbyte programmemóriából kb. 1kb-ot használok a többi parlagon hever és kellene egy kb. 10Kbyte méretű puffer, amelyet fel kellene töltenem programból. Tudom, hogy ez egy program memória, de hátha van valami okosság, amellyel hozzá lehetne férni és használni a területet.
Köszi előre is.

Általánosságában mondom, hogy a PIC18 család tudja írni a saját flash tartalmát programból.
Ennek korlátja jellemzően, hogy 256 byte-os blokkokban történik a törlés és 64 byte-os blokkokban az írás. Az olvasás történhet bájtonként is.
Microchip honlapján minden dokumentumot megtalálsz.
Bootloader-ekben az összes kód ott van.

Az írás és törlés nem gond, úgy is majd akkora méretet állítanék be, hogy 256-al osztható legyen. Nincs esetleg valakinek egy kitökölt és megírt példa verziója? MPLAB-ban dolgozom és C18-al.. Előre is köszi.

Nem feltétlenül 256/64Byte-os csomagokban kell kezelni egy 18F-es PIC-et sem! Ezek konkrét értékei az adott konkrét PIC adatlapjából derülnek ki, ennek áttanulmányozását nem nagyon úszod meg! Ha pedig átrágtad magad a megfelelő részen, már nem okozhat gondot annak megírása sem...

Igen tudom, ezen részén, mármint az adatlapon túl vagyok, nyilván ha van valakinek kész programja, amely működik azt könnyebben tudom felhasználni mint PL. program.

Amúgy ennek a 18F452-nek a program memória olvasása byte-onként történik, írása 8byte-onként, törlése pedig 64byte-onként.

Valami ősrégi programomban találtam, ez már C-ben íródott, 18F6520-asra:

Nagyin hasonlít az eprom írásra, sőt egy két helyen pont ugyan olyan..
Köszi, utána nézek, össze nézem az adatlappal és próbálok össze dobni egy kódot a példa alapján.

Szerintem ez egy az egyben kompatibilis a te PIC-eddel...

Még itt annyit, hogy mivel adod meg a címet, hogy honnét töröljön-olvasson vagy hova írjon?Talán itt ezzel? Azért kérdezem mert ez konkrétan az eprom címe, ami alapból elérhető és 256 byte a mérete.