A 12. - 15. sort vidd el a 3. utánra.

Sajnos ugyanaz a helyzet. A programmemória foglaltsága is leesik 45-ről 38 %-ra, ha int a visszatérési érték. A program is hibásan fut. Mondjuk pont ott fut hibásan, amihez ennek a függvénynek köze sincs. Nem értem.

Az a verzió még két int -et sem tud rendesen össze szorozni. Mármint a szimulátor, PIC-ben nyilván rendben megy (disassembly alapján helyes kódot csinál a fordító) ,bár még nem próbáltam.
Azóta föltettem az X -et, ott jó a szimulátor, tetszik is, de szörnyen lassú.. pedig nem rossz gépen fut.

eeprom_xxxxxx funkciókat és makrókat felejtsd el !!!!
A plib-ben meg vannak írva jól !

Darabolt fel !
OW...funkciók előtt egy függvény.
Az OW_read... megint egy és végül az ellenőrzés.
Egyébként is így kínálja magát!
Ha többször hívsz ugyanolyan változó készlettel függvényeket, akkor a változókat célszerű kitenni near-nak.
Gyorsabb és hatékonyabb lesz...gondolkozz úgy mintha az ASM-ben irnád a kódot, csak C utasításokkal.
C ide oda, próbálj úgy gondolkozni, hogy segíts a buta fordítónak. Egyébként is ami logikailag felosztható azt oszd fel. Nem jók a hosszú függvények....ez mikrokontroller!

Valahogy így....persze helyesen !

Egészen addig, amíg nem szaladunk bele abba, amibe én nemrég, hogy beszólt a fordító, hogy szerinte túl fog csordulni a stack

Ez jó gondolat, de ahhoz először asm-ot kellene megtanulni utána a C-t, mert fordítva nem megy, illetve sokkal nehezebb, szerintem...

Én értem, csak azt magyarázza meg valaki, hogy mi történhet, amikor átírom a visszatérési értéket és nem fordítja bele, vagy hibásan. Már próbáltam nézni a disassembly kódot, de sajnos hexa kódokkal már nehezen értem meg. Esetleg van valami kiegészítő kód, ahol meg lehet nézni mindkét esetben a fordítás tartalmát (nem a hex-re gondoltam, pl.:*.lib, *.as, vagy valami) és ott összehasonlítani?

A C18-nak van assembler listája, másnak nem tudom, de biztosan van hozzá help...

Nem úgy értem, hanem van assembly kód, amit az én c forráskódomból fordít, csak ott a változók helyett hexa címeket ír. Ez a bibi.

Van a map fájl, abban tudod megnézni, hogy melyik változót melyik címre tette.

Van az MPLAB-ban a View/Program Memory és ott a Symbolic ablak. Ott élnek a nevek is. Igazából biztosan meg van az oka, hogy a disassemly listing-ben miért nem, bár én nem értem...

A C18 disassembly listájában vegyesen szerepelnek a C sorok (kommnetezve) és a elfordított assembly utasítások. Hogy mennyire rövid vagy terjengős kódot fordít a fordító így is le lehet mérni. Az is látható, ha nem az elvárásainknak megfelelő a kód (künyvtári függvények, közös erőforrások kezelése stb).
A képen a példa: Egy unsigned int változó léptetése balra egy bittel. Miért kell rá ciklus szervezni?

Igen, ez félelmetes! Próbáltad optimalizálva?

Ezt teljes optimalizálás mellett is cilkus.

Igen, így már én is jártam. Jól megszívatott anno, emiatt lassult le nagyon a progi.
Nálam a megoldás az lett, hogy osztás (szorzás) operátort használtam, az adta a leggyorsabb és legrövidebb kódot.

Nem értem én ezt a C -t:
- a UARTStatus.TxData.Val <<= 1 (6 utasítás) akkor lenne a legrövidebb, ha nem tenné ciklusba (ekkor csak 3 lenne),
- a UARTStatus.TxData.Val *=2; ugyan úgy ciklust fordít,
- a UARTStatus.TxData.Val += UARTStatus.TxData.Val; egy kicsit rövidebb, csak 4 utasítás. Itt az a problémám, hogy az előző sorban szépen kiszámolja UARTStatus.TxData.bytes.LB értékét a WREG -re és eltárolja. Mégis betölti újra a WREG -be, biztos, ami biztos alapon.
Más:
Egy 24 bites összeadás vagy kivonás miért akkor a legrövidebb, ha _asm és _endasm között megírom? Akkor minek a C ?

Az utolsó kérdésedre az lehet a válasz, hogy valamit valamiért.
Egyébként lehet, hogy bizonyos helyzetekben az általunk legrövidebbnek vélt megoldás egyszerűen nem működik, hibát okoz(egyes PIC-eknél(errata?), vagy bizonyos szekvenciák találkozásánál). A felmerült hibák miatt inkább általánosan hosszabb megoldást választottak a helyett, hogy valami módon ellenőriznék, hogy a két(vagy több) megoldás közül melyik felel meg a jelenlegi helyzetnek. Egyébként nem tudom!

Most kicsit jobban visszagondolva lehet, hogy nálam dsPIC volt, és annak van osztó (vagy szorzó) utasítása. És ezt tudta a compiler is
Neked nincs ilyen osztó/szorzó perifériád, és hozzá ASM utasításod?
Esetleg, a játék kedvéért, ismételd meg pl. 8-cal az előző kísérletedet, hátha ott már "elgondolkodik" a fordító...

Jó kérdés
Nem véletlen, hogy folyton azt hallani, hogy a sebességkritikus részeket ASM-ben kell írni.

A jó öreg 18F2550 szorozni épen tud, de az eredmény a PRODHRODL -be kerül, onnan elmozgatni sem egyszerű. Osztásra nincs hardver támogatás.

Hiába való dolog a vak ember szemét felcicomázni.....
Kb. 2000 éves perzsa mondás.
Ezért nem szabad nagyobb projekt-ben PIC-et használni !
Vagy lehet az is, hogy a gyártó is tisztában van a PIC18 fordító hibáival és direkt szivat...hogy végül is vegyünk nagyobb procit, abban talán jó a fordító...vagy mégem ?
Nem tudom a Mikroelektronika vagy a CCS mit művel...nincs tapasztalatom.

Egy ARM-os ingyenes fordító nem csinál ilyeneket.

Nem csak mi bénázunk :
Nagyon nagy GÁZ !!!
Szó szerint !
Én is TOYOTA-val járok.

Minden rendszerben lehetnek hibák, legfeljebb nem ugyanott jön elő és nem ugyanaz a hatás. Lekopogom, de nekem még nem okozott megoldhatatlan problémát egy PIC sem...

Amikről itt írtam, azok nem vezetnek hibához, csak teljes optimalizálás mellett nem kellene ilyen megoldásokat bent hagyni a kódban...

Mondjuk én nem tudtam összefüggést találni az általad rajzolt vonal és kt6263 ezen hozzászólása között. Ha arra írta(jó lenne a válasz gombbal válaszolni, hogy ilyenkor ne kelljen találgatni), akkor nagyon eltévedt, mert kíváncsi lennék az ARM-es C fordító mit művel hasonló helyzetekben...

Azt értettem mire válaszoltál, a "vonallal" a korábban tárgyalt C fordító bénaságaira gondoltam és arra, hogy ahhoz nem kapcsolódik a reagálása... Ha nem érted, nem baj, már én se!

Tisztelt hozzáértő fórumtagok!

Most kezdtem el tanulgatni a C18-t és egy acs5040 típusú hall szenzort szeretnék lekérdezni.
Mivel eddig asm-ben programoztam, így számomra kézenfekvő lenne, hogy a C programban asm modulokkal oldanám meg a perifériák kezelését, (szerintem sokkal érthetőbb) és az eredményt dolgoznám fel C-vel.
Tudom, hogy inline asm-nek hívják a dolgot, de valahogy nem tudom elkészíteni.
A C18 Compiler User's Guide ezen részét is megnéztem (43-45.oldal).
A WikiTech Terminálon ráakadtam Watt mester ugyan ezen problémájára, de ez sem hozott megoldást.
Tehát a függvényem úgy nézne ki, hogy nincs bemenő, de van egy 16 bites kimenő paraméterem. Az asm kód felhasználna 1-2 (időzítés, + ciklus számláló) belső változót és eredményül visszaadná az acs5040 mérési eredményét.

Hogy lehet ezt szépen és jól megcsinálni?

(A kód még nincs kész...)
A második asm értékadásnál a fordító. Error [1253] constant operand expected hibát ad.





Üdv

Hali!
kiindulásként írnék egy egyszerű C függvényt, aminek van visszatérési értéke, a fordítótól kérnék asm listát, majd ezt jól megcsócsálnám mi mit csinál...

Az ACCESS szimbólumot nem ismeri a beépített _asm. Kérdés még az, hogy a as5040_csn szimbólum hogyan van definiálva.

A PICCOLO projektből ezt az oldalt ajánlom tanulmányozásra (különösen a Szubrutionok-tól a Veremkeret-ig).

Fontos tudnivaló benne "A paraméterátadás szabályai függvényhívásnál" c. szakasz is, mely szerint a 16 bites visszatérési értéket a PRODH, PRODL regiszterekben adjuk át.

Urak!

Tudja valaki, hogyan lehet Hitech c-ben (pic16f886)a fel nem használt programmemória tartalmát feltölteni?
Pl: wdtreset-tel?
Egyáltalán érdemes?