Sida 2 av 4

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 16:32:17
av newbadboy
Icecap skrev: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.
Helt ärligt känns det bättre att kompilatorn är bra och min kod är skit :-). Jag lär mig efterhand medans kompilatorn har jag betalt för.

Fö är det MikroC jag använder.

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 16:35:39
av Icecap
Bra inställning! Kompilern är nog rimlig (inte super) men din del av kodandet kan förbättras - som för alla oss andra. Alltså blir dina program bättre och bättre utan att det kostar annat än tid.

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 16:41:49
av lillahuset
Icecap: Du har helt rätt att det är skitprogrammering. Men, en bra kompilator brukar genomskåda skitprogrammering och åstadkomma bättre. På gott och ont.

bearing: Jag tycker man ska undvika C i PIC12xxxx och liknande. Men det är ju "resandes ensak".

sodjan: Skarpögt. :tumupp:

Jan Almqvist: :D

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 16:45:30
av newbadboy
sodjan skrev:> 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.
Currenlimit kan ha tre värden beroende hur många ggr jag tryckt på en knapp. Den är dekl som float men kommer ändra till int. I verkligheten är det ca 900mv 1560mv och 2700 mv. Så dessa är fasta värden och inget jag räknar.

Jag kanske missförstår men shuntvalue är ett inläst adc värde mellan 0-3V så jag ser inte hur du får det till att det skulle vara 0. 1.2.3. Just nu är shuntvalue dekl som float men det funkar ju inte utan kommer bli en int med lämplig multiplikation.

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 16:56:39
av sodjan
> Misstänkte att det var ngt sådant men blev ändå rätt ställd att det var så illa...

Är det "illa" att kompilatorn försöker göra det du ber om!? :-)

> Men, en bra kompilator brukar genomskåda skitprogrammering och åstadkomma bättre.

Exakt hur skulle det göras bättre av kompilatorn? Genom att *inte*
länka in floating-point stödet då man uttryckligen ber om det i koden?
Lösningen är så klart att se över sina algoritmer så att man inte ber
om något i onödan.

>Currenlimit [...] Den är dekl som float men kommer ändra till int.

Ja där har du ju ett direkt fel också. :-) Du ska i princip aldrig använda
något som har med floating-point att göra på dessa processorer.

> Jag kanske missförstår men shuntvalue är ett inläst adc värde mellan 0-3V så jag ser inte hur du får det till att det skulle vara 0. 1.2.3.

ADC värdet kan vara som minst 0 och som störst 1023.
(0*3.3)/1024 = 0
(1023*3.3)/1024 = 3 (efter avrundning neråt).

Alltså 0, 1, 2 eller 3) beroende på värdet från ADCn.

Nu så vet vi ju inte matningsspänning, ADCs ref spänning o.s.v, men du kanske
aldrig får värdet 3 heller och max inspänning är 3V och matningen 5V.

> I verkligheten är det ca 900mv 1560mv och 2700 mv. Så dessa är fasta värden och inget jag räknar.

OK, då kan du i förväg räkna ut vilka ADC värden som detta motsvarar och
sedan lägga dessa värden direkt i koden och jämföra det direkt med ADC
värdet utan några beräkningar alls.

Vad det ser ut som är att du försöker skriva koden så att den använder värden
som är skalade till "verkligheten", d.v.s värden som är uttryckta i mV. Helt
onödigt så klart, processorn har inte en susning om vad mV är i alla fall... :-)

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 16:57:48
av sodjan
Eller för att uttrycka det lite enklare...

Lägg ner lite mer arbete själv i förväg, så gör du jobbet
för processorn oerhört mycket enklare... :-)

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 17:04:46
av newbadboy
Matning och adcref är 3.3v.

Inga float. Upfattat efter denna övningen ser jag verkligen "faran"med dem.

Ska sitta imorron och försöka göra det snyggt. Har iaf fattat problemet.

Kan nog dyka upp ngn fråga till. Tack så länge.

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 17:16:33
av lillahuset
sodjan: Jag skrev "på gott och ont". Kompilatorn "vet" att värdet ska tilldelas en heltalsvariabel och kan alltså göra optimeringen. Men kompilatorer beter sig väldigt olika och din grundinställning är helt rätt. Det är bara det att jag har sett en hel del oväntat "trolleri". MicroC kanske också kan "trolla" om man ställer upp optimeringen. :)

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 17:19:32
av bearing
Ett sätt att göra koden "snygg" är att definiera en "enhet" i form av en konstant.
Eftersom att programmet har variabler med namnet shunt gissar jag att det handlar om ström-mätning.
Då kan man göra typ såhär:

Kod: Markera allt

#define MAX_CURRENT 3300
#define MAX_ADC 1024
#define mA (1UL * MAX_ADC / MAX_CURRENT)
#define CURRENT_LIMIT_LOW  (1000 * mA)
#define CURRENT_LIMIT_HIGH (2000 * mA)

...

CurrentLimit = CURRENT_LIMIT_LOW;
Nu har jag skrivit med heltal, men på många kompilatorer kan man ha decimaltal i dom här konstanterna, ty förkompilatorn räknar i flyttal och sedan trunkerar till heltal ifall konstanten skrivs till en integer. Dock inte alla kompilatorer / förkompilatorer, har jag märkt.
Men ifall din förkompilator hanterar flyttal och trunkerar, kan du skriva konstanterna i t.ex. ampere med decimaler, om du önskar.

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 17:23:33
av Jan Almqvist
Ska man vara petig är det inte konstanter utan makron...

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 17:28:45
av bearing
Är det?
Trodde att det bara var ett makro om det tog argument.
Typ

Kod: Markera allt

#define milliamps(i) (i * 1024 / 200)

...

current_limit = milliamps(20);

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 17:37:47
av Klas-Kenny
newbadboy skrev: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.
Men, du läser ju inte om ingången, variabeln ändras ju aldrig. Så det är exakt samma jämförelse två gånger. :)

Okej, så Reset är alltså ett makro? Rekommenderar att du skriver det med versaler då, som man brukar göra med makron och konstanter för att inte blanda ihop dem med vanliga variabler.

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 17:40:54
av Jan Almqvist
bearing skrev:Är det?
Trodde att det bara var ett makro om det tog argument.
Typ

Kod: Markera allt

#define milliamps(i) (i * 1024 / 200)

...

current_limit = milliamps(20);
https://en.wikipedia.org/wiki/C_preprocessor

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 17:47:26
av bearing
OK, men jag föredrar nog att fortsätta säga "konstant" eller "define" snarare än "objektlikt makro". Samt säga "makro" för "funktionslikt makro".

Men det kanske är fel, så jag får väl ändra mig om det uppstår missförstånd.

Tycker ändå det känns som att svenskan har en lite annan betydelse av orden här. Men det kanske bara är min egen känsla.

Re: Lite klarhet i varför ROM slukas i PIC

Postat: 16 december 2015, 18:48:15
av newbadboy
Klas-Kenny skrev:
newbadboy skrev: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.
Men, du läser ju inte om ingången, variabeln ändras ju aldrig. Så det är exakt samma jämförelse två gånger. :)

Okej, så Reset är alltså ett makro? Rekommenderar att du skriver det med versaler då, som man brukar göra med makron och konstanter för att inte blanda ihop dem med vanliga variabler.
Dra på trissor nu kopplar jag. I mitt huvud läste jag två ggr men missade tydligen att skriva det i koden . Hehe nu fattar jag varför du ifrågasatte det. Bra det hade jag nog missat och varit lite svårt att testa.