Fórum témák

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
Lapozás: OK   1306 / 1318
(#) sdrlab hozzászólása Ápr 21, 2020 /
 
Sziasztok!
XC16. Nagyobb méretű adathalmazokat szeretnék használni, de ezt kapom:
Idézet:
„Link Error: PSV or AUXPSV section '.const' exceeds 32K bytes (actual size = 42922).
Link Error: Could not allocate program memory”

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?
A hozzászólás módosítva: Ápr 21, 2020
(#) AZoli válasza sdrlab hozzászólására (») Ápr 22, 2020 /
 
É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.
(#) sdrlab válasza AZoli hozzászólására (») Ápr 22, 2020 /
 
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....
(#) helektro hozzászólása Ápr 23, 2020 /
 
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?
A hozzászólás módosítva: Ápr 23, 2020
(#) Hp41C válasza helektro hozzászólására (») Ápr 23, 2020 /
 
Át kell térni relokálható kódra. MpLab PIC24 Assembler users guide
(#) helektro válasza Hp41C hozzászólására (») Ápr 23, 2020 /
 
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?
(#) Hp41C válasza helektro hozzászólására (») Ápr 23, 2020 /
 
Mellényúltam. MpLab PIC24 Assembler users guide
Az 1. pontra a leírás 6.7 bekezdése ad megoldást.
  1. .set  LED1, PORTB,0

Nem vagyok biztos abban, hogy a vesszőt tartalmazó szöveggel nem lesz probléma.
(#) helektro válasza Hp41C hozzászólására (») Ápr 23, 2020 /
 
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!
(#) Peter65 válasza helektro hozzászólására (») Ápr 24, 2020 / 1
 
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
(#) helektro válasza Peter65 hozzászólására (») Ápr 24, 2020 /
 
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.
(#) silent15 hozzászólása Máj 10, 2020 /
 
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!
A hozzászólás módosítva: Máj 10, 2020
(#) matheattila válasza silent15 hozzászólására (») Máj 12, 2020 /
 
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
(#) silent15 válasza matheattila hozzászólására (») Máj 12, 2020 /
 
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!
(#) silent15 hozzászólása Máj 21, 2020 /
 
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:
Idézet:
„(944) data conflict at address 1FC01400h between ...hex and ...hex”


A bootloader main-jét a boot memóriaterületre helyezem el a
  1. __attribute__((address(0x9FC00000), space(prog)))
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
(#) superuser válasza silent15 hozzászólására (») Máj 21, 2020 /
 
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.
(#) silent15 válasza superuser hozzászólására (») Máj 21, 2020 /
 
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:
  1. _RESET_ADDR                    = 0xBFC00000;
  2. _BEV_EXCPT_ADDR                = 0xBFC00380;
  3. _DBG_EXCPT_ADDR                = 0xBFC00480;
  4. _DBG_CODE_ADDR                 = 0xBFC02000;
  5. _DBG_CODE_SIZE                 = 0xFF0;
  6. _GEN_EXCPT_ADDR                = _ebase_address + 0x180;
  7.  
  8.   kseg0_program_mem     (rx)  : ORIGIN = 0x9FC02000, LENGTH = 0x80000
  9.   kseg0_boot_mem              : ORIGIN = 0x9FC00490, LENGTH = 0x0
  10.   exception_mem               : ORIGIN = 0x9FC01000, LENGTH = 0x1000
  11.   kseg1_boot_mem              : ORIGIN = 0xBFC00000, LENGTH = 0x480
  12.   debug_exec_mem              : ORIGIN = 0xBFC02000, LENGTH = 0xFF0
  13.   config3                     : ORIGIN = 0xBFC02FF0, LENGTH = 0x4
  14.   config2                     : ORIGIN = 0xBFC02FF4, LENGTH = 0x4
  15.   config1                     : ORIGIN = 0xBFC02FF8, LENGTH = 0x4
  16.   config0                     : ORIGIN = 0xBFC02FFC, LENGTH = 0x4
  17.   kseg1_data_mem       (w!x)  : ORIGIN = 0xA0000000, LENGTH = 0x20000
  18.   sfrs                        : ORIGIN = 0xBF800000, LENGTH = 0x100000
  19.   configsfrs                  : ORIGIN = 0xBFC02FF0, LENGTH = 0x10


Felhasználói kód fő beállításai:
  1. _RESET_ADDR                    = (_ebase_address + 0x1000);
  2. _BEV_EXCPT_ADDR                = ((_ebase_address + 0x1000) + 0x380);
  3. _DBG_EXCPT_ADDR                = ((_ebase_address + 0x1000) + 0x480);
  4. _DBG_CODE_ADDR                 = 0xBFC02000;
  5. _DBG_CODE_SIZE                 = 0xFF0;
  6. _GEN_EXCPT_ADDR                = _ebase_address + 0x180;
  7.  
  8.   kseg0_program_mem     (rx)  : ORIGIN = (0x9D000000 + 0x2000), LENGTH = (0x80000 - 0x2000)
  9.   kseg0_boot_mem              : ORIGIN = 0x9FC00490, LENGTH = 0x0
  10.   exception_mem               : ORIGIN = 0x9FC01000, LENGTH = 0x1000
  11.   kseg1_boot_mem              : ORIGIN = (0x9D000000 + 0x1000), LENGTH = 0x490
  12.   debug_exec_mem              : ORIGIN = 0xBFC02000, LENGTH = 0xFF0
  13.   config3                     : ORIGIN = 0xBFC02FF0, LENGTH = 0x4
  14.   config2                     : ORIGIN = 0xBFC02FF4, LENGTH = 0x4
  15.   config1                     : ORIGIN = 0xBFC02FF8, LENGTH = 0x4
  16.   config0                     : ORIGIN = 0xBFC02FFC, LENGTH = 0x4
  17.   kseg1_data_mem       (w!x)  : ORIGIN = 0xA0000000, LENGTH = 0x20000
  18.   sfrs                        : ORIGIN = 0xBF800000, LENGTH = 0x100000
  19.   configsfrs                  : ORIGIN = 0xBFC02FF0, LENGTH = 0x10


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:
  1. SECTIONS
  2. {
  3.   /DISCARD/ : { *(._debug_exception) }
  4. }
A hozzászólás módosítva: Máj 21, 2020
(#) sdrlab hozzászólása Máj 21, 2020 /
 
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...
(#) silent15 válasza sdrlab hozzászólására (») Máj 21, 2020 /
 
Mire gondolsz? Függvényen belül definiáltam a pb_clk változót. Mutatja a típust és az értéket is.

Capture.PNG
    
(#) sdrlab válasza silent15 hozzászólására (») Máj 21, 2020 /
 
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...
(#) silent15 válasza sdrlab hozzászólására (») Máj 22, 2020 /
 
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.
(#) superuser válasza silent15 hozzászólására (») Máj 22, 2020 /
 
Szívesen, örülök, hogy segíthettem.
(#) don_peter hozzászólása Jún 18, 2020 /
 
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.
(#) superuser válasza don_peter hozzászólására (») Jún 18, 2020 /
 
Á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.
(#) don_peter válasza superuser hozzászólására (») Jún 19, 2020 /
 
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.
(#) sdrlab válasza don_peter hozzászólására (») Jún 19, 2020 /
 
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...
(#) don_peter válasza sdrlab hozzászólására (») Jún 19, 2020 /
 
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.
(#) sdrlab válasza don_peter hozzászólására (») Jún 19, 2020 / 1
 
Valami ősrégi programomban találtam, ez már C-ben íródott, 18F6520-asra:
  1. //----------------- Blokk törlés ----------------------------------
  2.                 EECON1bits.EEPGD=1;
  3.                 EECON1bits.CFGS=0;
  4.                 EECON1bits.WREN=1;
  5.                 EECON1bits.FREE=1;
  6.                 INTCONbits.GIE=0;
  7.                 EECON2=0x55;
  8.                 EECON2=0xAA;
  9.                 EECON1bits.WR=1;
  10.                 Nop();
  11.                 EECON1bits.WREN=0;
  12.                 for(K=0;K<64;K=K+8)    
  13.                 {
  14.                         //----------------- Blokk írás ----------------------------------
  15.                         for(i=0;i<8;i++)
  16.                         {
  17.                                 TABLAT=Data[K+i];
  18.                                 _asm TBLWTPOSTINC _endasm;
  19.                         }
  20.                         _asm TBLRDPOSTDEC _endasm;
  21.                         EECON1bits.EEPGD=1;
  22.                         EECON1bits.CFGS=0;
  23.                         EECON1bits.WREN=1;
  24.                         EECON2=0x55;
  25.                         EECON2=0xAA;
  26.                         EECON1bits.WR=1;
  27.                         Nop();
  28.                         EECON1bits.WREN=0;
  29.                         _asm TBLRDPOSTINC _endasm;
  30.                 }
(#) don_peter válasza sdrlab hozzászólására (») Jún 19, 2020 /
 
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.
(#) sdrlab válasza don_peter hozzászólására (») Jún 19, 2020 /
 
Szerintem ez egy az egyben kompatibilis a te PIC-eddel...
(#) don_peter válasza sdrlab hozzászólására (») Jún 19, 2020 /
 
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?
  1. EECON2=0x55;
  2.                 EECON2=0xAA;
Azért kérdezem mert ez konkrétan az eprom címe, ami alapból elérhető és 256 byte a mérete.
Következő: »»   1306 / 1318
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem