Fórum témák

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
 
Témaindító: G-Lex, idő: Jan 9, 2006
Lapozás: OK   1301 / 1301
(#) 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
Következő: »»   1301 / 1301
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu