Lite klarhet i varför ROM slukas i PIC

[newbadboy]

Har skrivit ett program till 12F675 som maxar ROM minnet när jag bara lägger till eller tar bort en enklare beräkning. Utan beräkningen har jag kvar 52% ROM

Shuntvalue skulle jag vilja deklarera som float men kompilatorn säger att minnet ROM inte räcker till. Endast som unsigned short kan jag få genom kompileringen men då har jag 0% ROM kvar

Funktionen som innehåller raden visas nedan men det finns mer kod såklart. Shuntvalue används bara i nedan funktion.

Kod: Markera allt

void CurrentMeas(){
     ShuntValue=ADC_Read(2);
     ShuntValue=(ShuntValue*3.3)/1024;    Denna raden gör att använd ROM går upp till ovan nämnda 
     if(ShuntValue>CurrentLimit){
       delay_ms(3);
       if(ShuntValue>CurrentLimit){
          while(Reset=1){
                LoadCTRL=1;
                LedOut=1;
                }
         }
       }
     }

[Klas-Kenny]

Det finns väl inget ROM i en sådan µC, så exakt vilket minne menar du egentligen? Flash, RAM eller EEPROM?

Blir heller inte riktigt klok på koden överlag. Varför gör du jämförelsen (Shuntvalue>CurrentLimit) två gånger? Kan någon av dem förändras under delay-tiden genom något interrupt eller liknande eller?
Samt while(Reset=1) blir sannolikt en oändlig loop, du vill nog ha ==, men även där, kan Reset ändras genom någon interruptrutin? Annars borde den ju aldrig förändras.

[bearing]

FLASH kallas ofta ROM, så det är väl inte konstigt.

Anledningen till att koden blir stor är att flyttal används i beräkningen.

Gör beräkningen utan flyttal, så ska du se att koden inte blir så stor.
Räkna t.ex. med 10ggr så stora tal, men heltal.

Kod: Markera allt

uint16_t ShuntValue;
ShuntValue = ADC_Read(2);
ShuntValue = (ShuntValue * 33) / 1024;

Vad som är lämpligt beror på dina krav på noggranhet i beräkningarna.

[lillahuset]

Fantastiskt, nästan hälften av 1,75kB går åt för en flyttalsberäkning. Vad är det för skitkompilator? En "riktig" kompilator skulle inse att lösningen är en multiplikation och en skift. Typ maximalt ett dussintal instruktioner i en anständig arkitektur.

Lösningen på problemet är att, eftersom kompilatorn verkar omåttligt korkad, beräkna 3,3/1024 och sedan multiplicera det med lämplig potens av två så att man får den noggrannhet man behöver. Sedan multiplicerar man med det värdet och skiftar höger rätt antal steg. Lycka till!

Edit: Såg just att bara multiplikation med unsigned short verkar ta orimligt mycket plats. Om det är enda multiplikationen i programmet och det inte är tidskritiskt kan du ersätta det med adderingar i en loop.

[Shimonu]

Vill någon förklara vad som möjligen händer i kompilatorn. Är det att stöd saknas för flyttalsberäkningar och det får helt enkelt göras i mjukvara istället? Hur stort kan programminnet vara? Säg att det är 0.5 KB eller så, då skulle det ändå kräva mer än 0.25 KB för att genomföra den beräkningen, det känns slösaktigt. Nu drog jag ändå till med ett ganska snålt programminne tycker jag också.

[Icecap]

Shimonu: I.o.m. att det används flyttal inkluderas flyttals-libbet och det fyller! Detta är anledningen till att "alla" starkt rekommenderar att man inte använder flyttal i µC utan "kraft" eller om man inte har en synnerlig tung anledning.

Det är inte en skit-kompilator, det är skit-programmering.

Det är mycket få mindre µC som har FPU inbyggd, det är helt enkelt inte värd priset då de sällan kör med flyttal - och om de kör med flyttal får man ta det att mjukvaran blir större och att "allting" går långsammare.

[sodjan]

> Vill någon förklara vad som möjligen händer i kompilatorn. Är det att stöd saknas för
> flyttalsberäkningar och det får helt enkelt göras i mjukvara istället?

Förstår inte riktigt vad du frågar om... Det är ju ganska självklart
att om processorn inte har någon flyttalsenhet i hårdvaran så
får det göras med programvara istället. Så är det ju alltid !?

Man jag kanske missförstod frågan...

[bearing]

Vill någon förklara vad som möjligen händer i kompilatorn. Är det att stöd saknas för flyttalsberäkningar och det får helt enkelt göras i mjukvara istället? Hur stort kan programminnet vara? Säg att det är 0.5 KB eller så, då skulle det ändå kräva mer än 0.25 KB för att genomföra den beräkningen, det känns slösaktigt. Nu drog jag ändå till med ett ganska snålt programminne tycker jag också.

Ja, den här processorn har definitivt inte flyttalsstöd=)
Den har inte heller någon hårdvaru-multiplikator.
Den har inte ens en separat shift-instruktion. Utan instruktionen innan "shift genom carry"-instruktionen, måste nolla carry-flaggan, ifall man vill göra en vanlig shift.

Och ja, kompilatorerna har nog inte högsta kvalitet. D.v.s man får fundera lite själv, och kan inte låta kompilatorn göra större delen av jobbet.

Jag brukar se det som att skriva assembler, fast med en lite "finare" syntax, när jag skriver C för dom här små picarna.

[sodjan]

> ShuntValue=ADC_Read(2);
> ShuntValue=(ShuntValue*3.3)/1024;

Shuntvalue kan alltså enbart ha värdena 0, 1, 2 och 3.
Om Shuntvalue är en int, vill säga. Antar det.

> if(ShuntValue>CurrentLimit)...

Hur är CurrentLimit definierad och vilket värde har den?

Hela logiken verkar underlig. Varför inte ha ett CurrentLimit som
du kan jämföra med värdet från ADCn direkt? D.v.s att du räknar
om din "limit" i förväg och jämför med det istället...

Och som redan sagts, det finns ingen som helst anledning att börja
köra flyttal här.

När det gäller kompilatorn så gör den väl bara som den är ombedd.

[Jan Almqvist]

Fantastiskt, nästan hälften av 1,75kB går åt för en flyttalsberäkning. Vad är det för skitkompilator? En "riktig" kompilator skulle inse att lösningen är en multiplikation och en skift. Typ maximalt ett dussintal instruktioner i en anständig arkitektur.

Lösningen på problemet är att, eftersom kompilatorn verkar omåttligt korkad, beräkna 3,3/1024 och sedan multiplicera det med lämplig potens av två så att man får den noggrannhet man behöver. Sedan multiplicerar man med det värdet och skiftar höger rätt antal steg. Lycka till!

Edit: Såg just att bara multiplikation med unsigned short verkar ta orimligt mycket plats. Om det är enda multiplikationen i programmet och det inte är tidskritiskt kan du ersätta det med adderingar i en loop.

Eller också multiplikation med 211 och sedan bara MOV/LOAD/STO eller motsvarande. Man löser det med ett dussintal instruktioner t.o.m. i en Didact 6802!!

[newbadboy]

Det finns väl inget ROM i en sådan µC, så exakt vilket minne menar du egentligen? Flash, RAM eller EEPROM?

Blir heller inte riktigt klok på koden överlag. Varför gör du jämförelsen (Shuntvalue>CurrentLimit) två gånger? Kan någon av dem förändras under delay-tiden genom något interrupt eller liknande eller?
Samt while(Reset=1) blir sannolikt en oändlig loop, du vill nog ha ==, men även där, kan Reset ändras genom någon interruptrutin? Annars borde den ju aldrig förändras.

Reset==1 ska det vara. Det var det sista jag skrev innan jag tog en paus missade det.

Sedan jämför jag två gånger bara för att inte känna av korta transientet

Reset är en fysisk knapp. Jag vill helt enkelt att om Shuntvalue är högre än limit så ska den fastna i while loopen tills knappen trycks in.

[newbadboy]

FLASH kallas ofta ROM, så det är väl inte konstigt.

Anledningen till att koden blir stor är att flyttal används i beräkningen.

Gör beräkningen utan flyttal, så ska du se att koden inte blir så stor.
Räkna t.ex. med 10ggr så stora tal, men heltal.

Kod: Markera allt

uint16_t ShuntValue;
ShuntValue = ADC_Read(2);
ShuntValue = (ShuntValue * 33) / 1024;

Vad som är lämpligt beror på dina krav på noggranhet i beräkningarna.

Misstänkte att det var ngt sådant men blev ändå rätt ställd att det var så illa

[bearing]

Eller också multiplikation med 211 och sedan bara MOV/LOAD/STO eller motsvarande. Man löser det med ett dussintal instruktioner t.o.m. i en Didact 6802!!

Det skulle dock innebära en 32-bit mjukvaru-multiplikation i C på den här processorn.

Bäst är nog att inte skala om variablerna i onödan, utan köra med det råa ADC-värdet. Som Sodjan föreslår.

[newbadboy]

Fantastiskt, nästan hälften av 1,75kB går åt för en flyttalsberäkning. Vad är det för skitkompilator? En "riktig" kompilator skulle inse att lösningen är en multiplikation och en skift. Typ maximalt ett dussintal instruktioner i en anständig arkitektur.

Lösningen på problemet är att, eftersom kompilatorn verkar omåttligt korkad, beräkna 3,3/1024 och sedan multiplicera det med lämplig potens av två så att man får den noggrannhet man behöver. Sedan multiplicerar man med det värdet och skiftar höger rätt antal steg. Lycka till!

Edit: Såg just att bara multiplikation med unsigned short verkar ta orimligt mycket plats. Om det är enda multiplikationen i programmet och det inte är tidskritiskt kan du ersätta det med adderingar i en loop.

Tyker också det verkar liite väl köttigt att döda allt minne pga av en skrutten beräkning.

Har inga fler beränkningar alls, bara här. Det är bara en massa logiska villkor och delays annars

[Icecap]

ShuntValue= ShuntValue/310; // Borde ge samma värde som:
ShuntValue=(ShuntValue*3.3)/1024; Denna raden gör att använd ROM går upp till ovan nämnda

Men sluka sinnessjukt mindre minne.