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á:


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.

Szia!
Az összeadás,kivonás,szorzáshoz ez sztem jó lesz:

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

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.

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

Ha gcc az alap, vannak beépített függvények osztás kivételével.
Bővebben: Link

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.

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

getIPSR

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.

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

É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?

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 )

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 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.

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ő...

Igen. Azt írják, hogy csak akkor használd, ha az interrupt controller Single Vector módra van konfigurálva.

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:


Így ebből arra számítok, hogy uxInterruptNesting == 0-val nem interrupt-ban van a program.

Köszönöm a választ!

Egy kérdést csak egy helyre, hirdetést az Apróhirdetés rovatba teszünk fel!

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.

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....

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.

Ezzel a műveleti erősítővel működik.
Köszi

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...

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

Mottó: Írjunk minél nagyobb számot.
4 kszó (4k*32 bit) == 32 kbyte (4*(4*8) bits) == 128 kbit

1byte = 8bit
4 kword = 4096 * 32 bit = 128kbit = 16 kbyte

Az adatlap szerint 32 kilobájt, azaz 32768 bájt.

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

"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.

Értem, csak akkor a Data RAM Size Register 0x00020000-os értéke mit jelent, mert az meg 131072 ami 128k-nak felel meg?

Szerintem a kezelhető címtartomány, de a fizikai memória méret a pictől függ.