Fórum témák

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
Lapozás: OK   1301 / 1318
(#) cross51 hozzászólása Márc 9, 2019 /
 
Sziasztok!

Szeretnék aritmetikai ellenőrzést írni összeadás, kivonás, szorzás osztásra (túlcsordulás/alulcsordulás).
Ezeket matekoltam ki rá:
  1. bool checked_add(int8_t a, int8_t b)
  2. {
  3.         if (((a > 0) && (b > (SCHAR_MAX - a))) ||
  4.                 (a < 0) && (b < (SCHAR_MIN - a)))
  5.         {
  6.                 return true;
  7.         }
  8.        
  9.         return false;
  10. }
  11.  
  12. bool checked_mul(int8_t a, int8_t b)
  13. {
  14.         if (a != 0 && b != 0)
  15.         {
  16.                 int8_t result = a * b;
  17.                 if (a != result / b)
  18.                 {
  19.                         return true;
  20.                 }
  21.         }
  22.  
  23.         return false;
  24. }
  25.  
  26. bool checked_sub(int8_t a, int8_t b)
  27. {
  28.         if (((a >= 0) && (b < (a - SCHAR_MAX))) ||
  29.                 ((a < 0) && (b > (a - SCHAR_MIN))))
  30.         {
  31.                 return true;
  32.         }
  33.  
  34.         return false;
  35. }
  36.  
  37. bool checked_div(int8_t a, int8_t b)
  38. {
  39.         if (a != 0 && b != 0)
  40.         {
  41.                 int8_t result = a / b;
  42.                 if (a != result * b)
  43.                 {
  44.                         return true;
  45.                 }
  46.         }
  47.  
  48.         return false;
  49. }


Az érték típusok nem lényeges mivel generikusan lesz megírva és operator túlterheléshez lesz berakva (c++) csak az egyszerűség kedvéért most a legkisebb típussal és egyszerű függvényekkel teszteltem.
Erre írtam egy teszt kódot ami végig pörget 0-255 x,y változóra értéket (persze 127-től felfelé negatív) és logikailag helyesnek tűnnek a vizsgáló függvények.
(úgy ellenőriztem, hogy int8-on is elvégeztem a műveletet és int32-is és ha ezek az eredmények nem egyenlőek megnéztem a függvényt is és ha false-t ad vissza akkor baj van, de ilyen nem történt)

A kérdés esetleg ezeket meg lehet írni optimálisabban(leginkább a szorzás osztást)?

Assembly-ig nem szeretnék le menni mivel ez egy olyan könyvtár része lesz ami elvileg bármely 32 bites mikrokontrollerhez használható valamint nem szeretnék egy operatort 50-60 sorosra írni mivel elég sok van belőle.

Ezt többnyire csak debugg-ban tervezem használni valamint "testesebb" microcontrollerekhez de azért mégse legyen tizen x szer lassabb mint a beépített operatorok.
(#) Tasznka válasza cross51 hozzászólására (») Márc 10, 2019 /
 
Szia!
Az összeadás,kivonás,szorzáshoz ez sztem jó lesz:
  1. bool osszeadas (char a,char b)
  2. {
  3. if (( (int)(a+b) > -129) && ((int)(a+b) < 128))
  4. return true;
  5. return false;
  6. }

Osztásnál picit érdekesebb,mert ott figyelni kell,hogy az osztó nem 0-e,és ott ugyebár nincs csordulás,max a maradékot lehetne nézni.Bár lehet,hogy valamit elnéztem
(#) cross51 válasza Tasznka hozzászólására (») Márc 10, 2019 /
 
Az osztásnál lehet túlbuzgó voltam és többnyire elég 0-val osztásra ellenőrizni, de ha -128 elosztom -1-el akkor az túlcsordul.
(#) Tasznka válasza cross51 hozzászólására (») Márc 10, 2019 /
 
Upsz tényleg.De amit írtam,annál jól számolja,csak be kell tenni a 0-a feltételvizsgálatot.Ha nem rakod be, akkor a matherr-t nullázd ki,mert resetel a pic
A hozzászólás módosítva: Márc 10, 2019
(#) rolandgw válasza cross51 hozzászólására (») Márc 11, 2019 /
 
Ha gcc az alap, vannak beépített függvények osztás kivételével.
Bővebben: Link
(#) cross51 válasza rolandgw hozzászólására (») Márc 12, 2019 /
 
Ez hasznos, köszi a tippet.
Sajna az XC32 egy szót sem ejt róla valamint az ARM-os mcu-khoz elég sok fordító van így megint maradna az #if def-elés amit szeretnék elkerülni.
(#) cross51 hozzászólása Márc 21, 2019 /
 
Sziasztok!

Hogyan oldható meg ez PIC32-őn hogy a software el tudja dönteni, hogy most interruptban van-e vagy csak a fő program fut.

Én itt próbáltam a CP0-nak (status) a IPL-jét nézni, de az írható olvasható tehát, ha akar bárki belepiszkál aztán (cause) RIPL bitjeit, de ez meg marad azon az értéken ami az utolsó interrupt volt.

Néztem az INTSTAT SRIPL bitjeit ami elvileg single vectored-ben kell használni, de MVEC=1-el is ment ez addig működött jól amíg én nem piszkáltam bele a status ipl-jébe.

Erre van valami korrekt mód?

Egyébként FreeRTOS fölé szeretnék húzni egy (c++) API-t egyaránt PIC32-őn és ARM-on futtatható módon (sok értelme nincs de egyik RTOS api-se "tetszik").
Az ötlet mbos-ből jön ahol mondjuk
  1. ...
  2. static int inHandlerMode (void)
  3. {
  4.   return __get_IPSR() != 0;
  5. }
  6. ...
  7. uint32_t osKernelSysTick(void)
  8. {
  9.   if (inHandlerMode()) {
  10.     return xTaskGetTickCountFromISR();
  11.   }
  12.   else {
  13.     return xTaskGetTickCount();
  14.   }
  15. }

getIPSR
(#) Wezuv válasza cross51 hozzászólására (») Márc 22, 2019 /
 
Ez nem kizáró ellentét? Ha megszakításban van a PIC, akkor nem fut a "sima program", fel se merül, hogy tudja-e, hogy megszakítás folyik. Ha meg a megszakítás rutin folyik, akkor tudja, mert övé az erőforrás.
(#) cross51 válasza Wezuv hozzászólására (») Márc 22, 2019 /
 
Persze fejlesztési időben én is tudom, hogy az egy interrupt és "speciális" függvény és oda az ISR függvényeket kell hívni.

Én sokkal inkább azt szeretném, hogy a software runtime el tudja dönteni, hogy interruptban van vagy nem hardware állapotok alapján.
Persze használhatnék egy sima flag-et is, de az egyszer felejtem el beírni valahova és adott esetben olyan hibát okoz amit nehéz lehet felderíteni.

Ez szerintem ki vehető az előző példából is nem kell tudni, hogy a taskTickCount-ját másképp kell "kezelni" normál kódban vagy interruptban.
És amikor már nem az a cél, hogy bytekokat spórolj a memóriából sőt adott függvényeket leszámítva (amiről tudod, hogy gyorsnak kell lennie) a sebesség sem érdekel akkor elkezd kicsit "softwaresedni" az ember agya is és elkezd el tűnni a hardware az ember szeme elől.

De némi infót még találtam erről amit akarok csinálni a status EXL bitjét kéne nézni ha ezt a gyári/RTOS-hoz írt wrapper nem piszkálná (ez egyben jelezi azt, hogy a rendszer exception szinten van és tiltja a további megszakításokat is ezért írja 0-ra a wrapper).

Az INTSTAT SRIPL bitjeit megnéztem hardware-es debuggal (lehet a soft debugban elírtam valamit) és ott működtek megfelelően mindig tudtam az status ipl bitjeitől függetlenül hogy interruptban van-e vagy nem mert ha iterruptban volt akkor az SRIPL beállt az adott interrupt prioritására (éa a 0 prioritás meg a kikapcsold int-et jelenti) csak egy apróság, hogy a doksiban
Idézet:
„This value should only be used when the interrupt controller is configured for Single Vector mode”

És nem igazán értem, hogy miért rossz nekem ha használom mert amúgy ugyanúgy viselkedik single és vectored módban is.
Vagy csak vectored módban felesleges használni-ra gondolnak?
(#) Wezuv válasza cross51 hozzászólására (») Márc 22, 2019 /
 
A feladatot már értem, de segíteni nem tudok mert ilyesmit még nem akartam 32-essel megoldani. Ellenben bitosan van valami, ami ezt jelzi... (mert ha nincs, akkor más se akarta így megoldani ezt a problémát )
A hozzászólás módosítva: Márc 22, 2019
(#) Kovidivi válasza cross51 hozzászólására (») Márc 22, 2019 /
 
Mint kezdő kérdezem, a PIC tud egyszerre interrup-ban is, meg a főprogramban is lenni? AVR-nél egyszerre, egy időben csak az egyik lehetséges (mármint amelyik típusokat ismerem...) Köszi.
A hozzászólás módosítva: Márc 22, 2019
(#) Hp41C válasza Kovidivi hozzászólására (») Márc 22, 2019 /
 
A dsPIC33CH családot kivéve nem lehet.
A dsPIC33CH egy kétmagos kontroller, mindkét kontroller futhat az alap programban és futhat a saját megszakítás kiszolgálójában. Az általad említett eset úgy állhat be, hogy az egyik mag a saját alap programját, a másik mag a saját kiszolgálóját futtatja.
(#) icserny válasza Kovidivi hozzászólására (») Márc 22, 2019 /
 
Amíg egy CPU-ja van egy mikrovezérlőnek, addig vagy megszakításban van, vagy a főprogramban (értsd: nem megszakításban). A vagy itt kizáró értelemben értendő...
(#) killbill válasza cross51 hozzászólására (») Márc 22, 2019 /
 
Idézet:
„„This value should only be used when the interrupt controller is configured for Single Vector mode”
Vagy csak vectored módban felesleges használni-ra gondolnak?”
Igen. Azt írják, hogy csak akkor használd, ha az interrupt controller Single Vector módra van konfigurálva.
(#) cross51 válasza cross51 hozzászólására (») Márc 22, 2019 /
 
Lehet hagyom inkább ezt a core status-ból okosságot.
Belenéztem a FreeRTOS portjába a microchip-nél van uxInterruptNesting változó amit contextSave és Restore-ban piszkál. Az vPortIncrementTick-nél néztem, hogy contextSave előtt uxInterruptNesting 0-volt utána 1 (gondolom a nesting miatt a lényeg hogy > 0)
És a protmacro.h-ban találtam egy ilyet:
  1. extern volatile UBaseType_t uxInterruptNesting;
  2. #define portASSERT_IF_IN_ISR() configASSERT( uxInterruptNesting == 0 )


Így ebből arra számítok, hogy uxInterruptNesting == 0-val nem interrupt-ban van a program.
(#) Kovidivi válasza Hp41C hozzászólására (») Márc 22, 2019 /
 
Köszönöm a választ!
(#) Moderátor hozzászólása TheZ95 hozzászólására (») Ápr 25, 2019
 
Egy kérdést csak egy helyre, hirdetést az Apróhirdetés rovatba teszünk fel!
A hozzászólás módosítva: Ápr 25, 2019
(#) kszabi hozzászólása Júl 4, 2019 /
 
Sziasztok!
Egy dspic33 RA4-5 bemenetére konfiguráltam a QEI modult.
Erre egy tl074 műveleti erősítő kimenete van kötve komparátorként, 3K ellenállással gnd-n, 5V és GND táppal.

A gong az hogy a kimeneti alacsony szint kb 1.2V-on van, így nem indul el a számlálás.
Van erre valami megoldás hogy lehetne megfelelő jelszintre hozni?
Új nyákot csinálni nincs idő, deszka panelen kell megoldanom.
Köszi Szabolcs.
A hozzászólás módosítva: Júl 4, 2019
(#) pipi válasza kszabi hozzászólására (») Júl 4, 2019 /
 
Rail to rail műverősítő kéne szerintem, pl mcp6002? Hqvideoban szokott lenni.
Arra is figyelj, hogy milyen kell, pl rail-to-rail input and output vagy csak az egyik oldal....
(#) Peter65 válasza kszabi hozzászólására (») Júl 4, 2019 /
 
A TL074-es valóban nem 5V-os üzemre ideális. A kommersz műveleti erősítők közül az LM324-gyel esetleg megpróbálhatod.
(#) kszabi válasza pipi hozzászólására (») Júl 8, 2019 /
 
Ezzel a műveleti erősítővel működik.
Köszi
(#) pipi válasza kszabi hozzászólására (») Júl 8, 2019 /
 
Gondolom megtaláltad az mcp-ből is a megfelelőt, amit ajánlottam mcp6002-t, abban 2 műverősítő van, de van 6004-es is...
(#) cs_gabor hozzászólása Júl 12, 2019 /
 
Sziasztok, egy "soros-párhuzamos" átalakítót szeretnék készíteni, így esett a választásom a PIC32MX340F512H típusra. A kiválasztás szempontja a DMA és a minél nagyobb SRAM valamint a viszonylag olcsó ár (tme.hu kb. 1500Ft) volt...
Amiért írok, sajnos a SRAM méret nem egyértelmű, az összehasonlító oldal szerint 128kB, a mikrochip oldalán az MCU System Features 32kB míg a Paramétereknél 128kB a méret, a datasheet szerint viszont megint csak 32kB-ot ad. Szeretném megkérdezni vajon melyik a helyes adat illetve honnan tudhatnám ezt meg pontosan?
Köszönöm
A hozzászólás módosítva: Júl 12, 2019
(#) Hp41C válasza cs_gabor hozzászólására (») Júl 12, 2019 /
 
Mottó: Írjunk minél nagyobb számot.
4 kszó (4k*32 bit) == 32 kbyte (4*(4*8) bits) == 128 kbit
(#) cua válasza Hp41C hozzászólására (») Júl 12, 2019 /
 
1byte = 8bit
4 kword = 4096 * 32 bit = 128kbit = 16 kbyte
(#) icserny válasza cs_gabor hozzászólására (») Júl 12, 2019 /
 
Az adatlap szerint 32 kilobájt, azaz 32768 bájt.
(#) cs_gabor hozzászólása Júl 12, 2019 /
 
Köszönöm a válaszokat. Így kicsit érthetetlen miért írják, hogy 128kbájt két helyen is. Közben nézegettem a Section 3. Memory Organization dokumentációt, melyben a 3.9 oldalon a BMXDRMSZ Data RAM Size Register leírásában szerepel a 0x00020000 méret ami viszont valóban 128kbájt.
Nem lehet, hogy a 32k valójában 4 bájtos (32 bites busz) és így jön ki a 128k? Tudom, kicsit félreérthető, hiszen egy bájt normális értelmezésben a busz szélességtől függetlenül 8 bit, de lehet itt másként értelmezték ezt. Csak próbálom értelmezni az olvasottakat
(#) icserny válasza cs_gabor hozzászólására (») Júl 12, 2019 /
 
"kicsit érthetetlen miért írják, hogy 128kbájt két helyen is."
Copy - Paste effektus. Egy másik PIC adatait szerkesztették át, ez valahogy bennfelejtődött...

"Nem lehet, hogy a 32k valójában 4 bájtos"
Nem lehet.
(#) cs_gabor hozzászólása Júl 12, 2019 /
 
Értem, csak akkor a Data RAM Size Register 0x00020000-os értéke mit jelent, mert az meg 131072 ami 128k-nak felel meg?
(#) pipi válasza cs_gabor hozzászólására (») Júl 12, 2019 /
 
Szerintem a kezelhető címtartomány, de a fizikai memória méret a pictől függ.
Következő: »»   1301 / 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