[PIC] Räkna ut ACQT & ADCS på 18F4221

[Pajn]

Det hade jag faktiskt inte testat. Och det funkade ju...
Eftersom jag skiftar utan problem i andra ställen i koden
hade jag ingen tanke på det.

[sodjan]

Du kan ju kolla vad skillnaden i ASM kod blir. Kanske att
kompilatorn gör något "smart" när den ser en shift med 8 pos.
Som att bara swappa bytes direkt. En multiplikation med 256
måste ju alltid ske korrekt rent matematiskt.

[Batman]

Vilken kompilator använder du?
Om du använder C18 utan integer promotions kommer den att göra shift som en 8 bitars operation, dvs resultatet blir alltid noll.
256 är större än 8 bitar så då kommer multiplikationen göras i 16 bitars int preciision.

[bearing]

Ja, du måste antagligen typecasta.

Kod: Markera allt

result = (uint16_t) (ADRESH << 8 ) | ADRESL;

[sodjan]

Onödigt när det blir mycket tydligare med "ADRESH x 256".
Om man inte har en speciell anledning att köra shiften...

[Pajn]

Okej tack alla!

Ja det är C18 i MPLAB X det handlar om.
Tyvärr kan man inte se assembler resultatet utan man får gissa vad som händer.

Jag tog Bearings lösning (men uppdelad i två som tidigare) då jag föredrar shift över
multiplissering med ett "magiskt nummer". Då jag tycker det blir lättare att följa,
speciellt om man kommer tillbaka till koden efter några månader.

Visserligen sparar man 16 Byte om man gör som Bearing över att dela upp det

Kod: Markera allt

tmp =  ADRESL;
tmp |= (int) (ADRESH << 8);

men jag föredrar läsbarheten

EDIT:
Så går det när man snackar för fort.

Kod: Markera allt

tmp |= (int) (ADRESH << 8);

För tillbaka problemet med att resultatet "hoppar" runt. Så jag nöjer mig med Sodjans lösning

EDIT2:

Kod: Markera allt

(int) (ADRESH << 8)

Försöker antagligen skifta ADRESH 8 bitar till höger inne i ADRESH och sen kasta
det till en int (16 bitar). Anledningen till att det hoppar är antagligen att när
ADRESH overflowas får jag konstig data istället för 0.

Kod: Markera allt

tmp = ADRESH;
tmp = (tmp << 8);
tmp |= ADRESL;

Verkar fungera som det ska. Aja att grubbla på vad som är snyggast kan jag göra själv

[bearing]

Räknar den fel även med "min" kod?
Blir det rätt ifall du castar till "unsigned int" istället för "int" (shiftning går till på annat sätt med signed). Är tmp en int eller unsigned int?

Skulle du kunna visa disassembly för "min" kod och "din" kod?

[Pajn]

Ja den hoppar med din kod, även om det är en unsigned int eller om
man gör det på endast en rad.

tmp är en unsigned int.

Tyvärr får jag inte någon ASM från kompilatorn

[bearing]

Det var märkligt. Klarar inte kompilatorn casting?
Man kanske måste lägga castningen innanför parentesen?
result = ((unsigned int) ADRESH << 8 ) | ADRESL;

Det borde på något sätt gå att få en .lst-fil som visar koden som genererats.

[Batman]

Jo, castningen måste vara innanför, framför ADRESH, annars utförs skiftningen i 8 bitar inne i parantesen och castningen blir på resultatet.
Man kan också slå på integer promotions för kompilatorn, då görs alla operationen med int(16 bitar), men koden tenderar att bli stor efter det. Så om man kan kan lära sig att vara utan så är det bra.

[Pajn]

Självklart. ADRESH måste kastas till minst 10bitar innan den går att skifta 8bitar.
Att man inte tänkte på det

[sodjan]

> ...då jag föredrar shift över multiplissering med ett "magiskt nummer".

Om man tycker att 256 är speciellt "magisk" så vet i fanken om man håller på med rätt saker!

> Tyvärr kan man inte se assembler resultatet

Jag vet inte med säkerhet, men jag väljer tillsvidare att inte tro på det.
Jag har aldrig sett en kompilator som inte kan generera en asm/maskin listning.
Det gäller sannolikt bara på att hitta rätt "kran" att vrida på för att spara den.
Men eftersom det hela är "löst" så kanske du inte är intresserad, men eventuellt
skulle det kunna ge bra insikt i vad kompilatorn gör "under the hood", så att säga.

[dangraf]

En annan sak som skulle kunna gå fel är att du har din 16bit variabel "result" som du tilldelar ett 8bit värde (ADRESL) har man otur ändras bara de lägre 8 bitarna om kompilatorn väljer att se "result" som ett 8bitars tal.
därefter kör du "OR" på de övre 8 bitarna som möjligen inte har blivit initierade till noll. Tror inte att detta är felet men du borde köra casting på samtliga konverteringar från 8bit register som ska tilldelar 16bit variabler eller högre.

[Pajn]

@Sodjan
Jag förstår vad du menar men det är inte övertydligt att multiplissering
med 256 är jämställt med att shifta 8 bitar. Frågan varför just 256 ska
inte behöva komma upp.

Självklart borde det gå att få en ASM listning, men jag lyckas inte hitta
varken fil, inställning eller nått på Google.

Det skulle vara riktigt smidigt att få ut en listning i vissa sammanhang
så om nån vet nått får ni gärna skriva en rad

@Dangraf
Tack för tipset. Men i just det här sammanhanget tömmer jag tmp efter
att ha hämtat och visat tempen då den ska användas till andra saker
också. Men det är bra att tänka på i framtiden.

[sodjan]

> Men i just det här sammanhanget tömmer jag tmp...

Är inte tmp en vanlig variabel ?
Exakt *vad* betyder det att du "tömmer tmp" ?

> ...då den ska användas till andra saker också.

På vilket sett har det någon betydelse ?

Enda gången jag ser att det har rellevans är i interrupt-rutiner,
men då handlar det om att *återställa* värden, inte att "tömma".