jag håller på och gör en liten applikation i en PIC och skriver koden i C. jag har kopplat en syrgas-sensor till en AD omvandlare som en PIC läser av för att pressentera ett gas-halten.
Just nu har jag fastnat lite på hur jag ska kalibrera min syrgasmätare och göra hyffsat effektiv kod.
AD värdet kan variera mellan ca 40-120 och ska då kalibreras mot talet 2090 (20.9% syrgas).
Om jag skulle vilja kalibrera min mätare så borde jag räkna ut en konstant C * AD värdet = 2090.
ex låt säga att jag läser av värdet 120 på ADn som ska kalibreras.
2090/120 = 17,41666.. vilket kommer bli talet 17 om man räknar med intergers.
Om jag sedan vill använda min uträknade konstant 17 på AD värdet kommer jag få gashalten
17*120 = 2040 (20.4% syrgas)
jag har en rest på 50 (2090-2040) som jag inte riktigt vet vad jag ska göra med.
Skippar jag resten så kommer felet bli ännu större om jag når en syrgashalt på 80%.
80% syrgas ger ett AD värde på ca 459
459*17 = 7803 (78% syrgas)
någron som vet hur jag ska kunna räkna för att få ett mer exakt svar?
Mvh/
Danield
Matteproblem i C
Re: Matteproblem i C
Räkna i 1/10-dels enheter eller 1/100-dels enheter, det gör "alla andra".
2090/120 = 17,41666 blir alltså:
209000/120 = 1741 om du räknar i 1/100-delar.
2090/120 = 17,41666 blir alltså:
209000/120 = 1741 om du räknar i 1/100-delar.
Re: Matteproblem i C
> 2090/120 = 17,41666.. vilket kommer bli talet 17 om man räknar med intergers.
Det är bara att flytta kommat så får du vilken upplösning du vill.
En PIC vt i alla fall inte var ett "komma" är...
För övrigt gör du ju redan exakt samma sak på ett annat ställe :
> ...mot talet 2090 (20.9% syrgas).
Det är bara att flytta kommat så får du vilken upplösning du vill.
En PIC vt i alla fall inte var ett "komma" är...
För övrigt gör du ju redan exakt samma sak på ett annat ställe :
> ...mot talet 2090 (20.9% syrgas).
Re: Matteproblem i C
hej igen! tack för svaren!
Jag krånglade nog till det för mycket i början istället för att lösa det som Ice-cap vilket är en ganska snabb och effektiv metod. Jag kunde inte låta bli att "nörda till det lite" och testa min metod mot IceCaps.
jag hade 2 metoder, 1: IceCaps där jag multiplicerar med talet 256 för att få högre upplösning. 2: En egen-snickrad metod jag kom på när jag stod i duchen som kompenserar med resten som blir kvar vid kalibreringen..
Dels testade jag hur pass exakt svaret blev och dels på hur lång-tid det tar att räkna ut resultatet.
Jag kommer nog skippa min egen funktion eftersom den e svår att förstå och tillför nog ingen direkt större exakthet som har betydelse. Men tyckte endå att det var ett intressant test ifall någon annan är intresserad.
Sammanfattningen av mitt lilla test är:
Det är inte säker att man får högre upplösning bara för att man "flyttar kommat".
Min metod tog dubbelt så lång tid att exevera jämfört mot den andra men verkar bli något mer exakt.
här är koden med kommentarer och resultat:
Jag krånglade nog till det för mycket i början istället för att lösa det som Ice-cap vilket är en ganska snabb och effektiv metod. Jag kunde inte låta bli att "nörda till det lite" och testa min metod mot IceCaps.
jag hade 2 metoder, 1: IceCaps där jag multiplicerar med talet 256 för att få högre upplösning. 2: En egen-snickrad metod jag kom på när jag stod i duchen som kompenserar med resten som blir kvar vid kalibreringen..
Dels testade jag hur pass exakt svaret blev och dels på hur lång-tid det tar att räkna ut resultatet.
Jag kommer nog skippa min egen funktion eftersom den e svår att förstå och tillför nog ingen direkt större exakthet som har betydelse. Men tyckte endå att det var ett intressant test ifall någon annan är intresserad.
Sammanfattningen av mitt lilla test är:
Det är inte säker att man får högre upplösning bara för att man "flyttar kommat".
Min metod tog dubbelt så lång tid att exevera jämfört mot den andra men verkar bli något mer exakt.
här är koden med kommentarer och resultat:
Kod: Markera allt
void testDivide(uint16 AD_value)
{
uint8 Coef = 17; // 2090/120
uint16 AdCalib = 120; // value during calibration of sensor
uint16 Rest = 50; // result of 2090-17*120
uint16 Result;
Result = AD_value*Coef; //52
Result += (AD_value*Rest)/AdCalib; //320
// totalt 372 cykler
}
void testDivex256(uint16 AD_value)
{
uint16 Coef = 4458; // ((2090<<8)/120)
uint16 Result;
uint32 tempRes;
tempRes = ((uint32)AD_value)*((uint32)Coef); //101 cycles
Result = tempRes>>8; //82 cycles
// totalt 183 cykler
}
void main(void)
{
// 10.45% syrgas
// (60 * 2090)/120 = 1045.0
// förväntat resultat 1045
testDivex256( 60 ); // 1044
testDivide( 60 ); // 1045
// 80% syrgas
// (459 * 2090)/120 = 7994.25
// förväntat resultat 7994
testDivex256( 459 ); // 7993
testDivide( 459 ); // 7994
// 140% O2 (100% på 4m djup)
// (804 * 2090)/120 = 14003
// förväntat resultat 14003
testDivex256( 804 ); //14000
testDivide( 804 ); //14003
}
Re: Matteproblem i C
Men likaväl skalar du ner resultatet varför det kan kvitta!
Ditt RESULTAT från dessa rutiner ska ju vara i högre upplösning, du har alltså i mina ögon sumpat hela grejen och du gör det precis här:
Result = tempRes>>8;
Hela idéen är att all räkning utförs med en faktor högre värden och bara i utläsningen placeras komma rätt.
Och ett snabbt sätt att läsa tempRes utan att shifta höger:
Resultat = *(uint16)((&tempRes)+1);
Lär knappast ta ett 80-tal cyklar.
Ditt RESULTAT från dessa rutiner ska ju vara i högre upplösning, du har alltså i mina ögon sumpat hela grejen och du gör det precis här:
Result = tempRes>>8;
Hela idéen är att all räkning utförs med en faktor högre värden och bara i utläsningen placeras komma rätt.
Och ett snabbt sätt att läsa tempRes utan att shifta höger:
Resultat = *(uint16)((&tempRes)+1);
Lär knappast ta ett 80-tal cyklar.
Re: Matteproblem i C
Jag sumpar inte alls hela grejjen. eftersom jag inte behöver 32 bitars upplösning på ett tal som sträcker sig från 0 - 20000 så är det ganska onödigt att behålla det formatet. Skulle resultatt bli "mer exakt" om jag inte skiftade?? jag försår nog inte vad du menar. som jag ser det får jag med "fler siffror" men exaktheten i dessa är fortfarande dålig.
jag tycker oxå att det är väldigt märklgit att det tar 80 cykler att flytta utälsningen ett steg åt ena hållet. Det är C18 studentversion som pysslar med konstigheter, går absolut att lösa på annat sätt.
jag tycker oxå att det är väldigt märklgit att det tar 80 cykler att flytta utälsningen ett steg åt ena hållet. Det är C18 studentversion som pysslar med konstigheter, går absolut att lösa på annat sätt.
Re: Matteproblem i C
Det är en 32-bitars variabel som ska flyttas 8 platser, den kommer alltså att flytta 4 bytes en bit åt gången vilket självklart tar en del tid.
Och kompilern gör bara som den har fått veta, den knaser sig alltså inte men programmören gör det...
Och kompilern gör bara som den har fått veta, den knaser sig alltså inte men programmören gör det...
Re: Matteproblem i C
Vilket innebär assemblerDet är C18 studentversion som pysslar med konstigheter, går absolut att lösa på annat sätt.
Då har du full kontroll 
Re: Matteproblem i C
Nu vet jag inte hela sammanhanget kring projektet, men om 8-bit AD-omvandlaren bara rör sig mellan 40 - 120 (decimalt räknat) på AD-omvandlaren för syresensorns 0-100% område så är din upplösning 1.25% per steg (om det rör sig linjärt) - jag skulle titta över anpassningskretsarna till A/D-omvandlaren så att man nyttjar nästan hela A/D-omvandlarens området (typ 240 av 256 steg? [1]) då du i allafall skulle få 0.4% steg och med 10-bit omvandlare skulle få runt 0.1% per steg.
Är sensorn dessutom olinjär med syrgashalten så måste du dessutom se till att du har nödig upplösning (säg 1 %) i området där spänningen rör sig minst i jämförelse med skalan av ökad stimuli.
Att anpassa analoga delen så att det får A/D-omvandlaren att arbeta med nästan sin fulla skala för mätsensorns tänkta arbetsområde är _minst_ lika viktigt att få till i ett sådant projekt som matematiska övningarna i PIC-en efteråt. Man kan aldrig förbättra dålig indata med ens med expertskriven mjukvara - men det är väldigt enkelt att förstöra bra indata med dåligt skriven mjukvara. Så se till att ha bra indata så att du med din nuvarande programeringskunskap har utrymme att 'förstöra' i allafall lite och ändå har tillräckligt bra upplösning kvar
---
Om detta är en skolarbete som skall lämnas in senare så skulle jag i allafall som lärare ge nedslag på att du bara mäter 80 steg i A/D-omvandlaren på området 0-100% när det tekniskt sett gå att få mycket bättre upplösning - har du 1%-stegningskrav i displayen i uppgiften så kommer du inte att lyckas med nuvarande lösning oavsett hur bra program du skriver - då grundupplösningen till A/D-omvandlaren i nuläget är för litet.
jag säger det här nu så att du blir medveten om detta och kan göra något åt det innan allt byggs fast mjuk och hårdvarumässigt och det blir jättestort jobb att göra om och göra rätt och inte får det som kalldusch från den som sedan bedömer arbetet.
se detta som konstruktiv kritik!.
lycka till!
[1]
vid enkelspänningsmatning är det knepigt att hantera spänning väldigt nära 0-volt på AD-omvandlarens ingång även med rail-to-Rail OP-ampar som anpassningskretsar och därför så kanske man måste offra första 5- 10 stegen i skalan närmast 0 Volt. dvs efter anpassning så kanske syresensorns område går mellan 10 och 250 i AD-omvandlarvärde (8-bit AD) för området 0-100% syre och man får 0.42% per steg i upplösning om sensorn arbetar linjärt)
Är sensorn dessutom olinjär med syrgashalten så måste du dessutom se till att du har nödig upplösning (säg 1 %) i området där spänningen rör sig minst i jämförelse med skalan av ökad stimuli.
Att anpassa analoga delen så att det får A/D-omvandlaren att arbeta med nästan sin fulla skala för mätsensorns tänkta arbetsområde är _minst_ lika viktigt att få till i ett sådant projekt som matematiska övningarna i PIC-en efteråt. Man kan aldrig förbättra dålig indata med ens med expertskriven mjukvara - men det är väldigt enkelt att förstöra bra indata med dåligt skriven mjukvara. Så se till att ha bra indata så att du med din nuvarande programeringskunskap har utrymme att 'förstöra' i allafall lite och ändå har tillräckligt bra upplösning kvar
---
Om detta är en skolarbete som skall lämnas in senare så skulle jag i allafall som lärare ge nedslag på att du bara mäter 80 steg i A/D-omvandlaren på området 0-100% när det tekniskt sett gå att få mycket bättre upplösning - har du 1%-stegningskrav i displayen i uppgiften så kommer du inte att lyckas med nuvarande lösning oavsett hur bra program du skriver - då grundupplösningen till A/D-omvandlaren i nuläget är för litet.
jag säger det här nu så att du blir medveten om detta och kan göra något åt det innan allt byggs fast mjuk och hårdvarumässigt och det blir jättestort jobb att göra om och göra rätt och inte får det som kalldusch från den som sedan bedömer arbetet.
se detta som konstruktiv kritik!.
lycka till!
[1]
vid enkelspänningsmatning är det knepigt att hantera spänning väldigt nära 0-volt på AD-omvandlarens ingång även med rail-to-Rail OP-ampar som anpassningskretsar och därför så kanske man måste offra första 5- 10 stegen i skalan närmast 0 Volt. dvs efter anpassning så kanske syresensorns område går mellan 10 och 250 i AD-omvandlarvärde (8-bit AD) för området 0-100% syre och man får 0.42% per steg i upplösning om sensorn arbetar linjärt)
Re: Matteproblem i C
Hej!
Det var en väldigt bra förklaring och jag har faktiskt funderat på detta.
jag har nog varit lite otydlig. värdet 40-120 är själva AD värdet när man kalibrerar mot 20.9% syrgas , vilket motsvarar en spänning från sensorn på ca 5-15mV. AD omvandlaren har en förstärkning på 8 vilket ger ett resultat på 5*8 = 40 och 15*8 = 120. i "värsta fall" så har jag en upplösning på 20.9/40= 0.52%/steg. Sensorn är linjär sånär som på 1%. Jag använder 12-bit upplösning med spännings-referensen 2.048V vilket ger svaret i mv vid en förstärkning på 1 vilket är väldigt behändigt. (12 bitar ger 4096 men eftersom jag inte använder det negativa området så blir det 2048 steg kvar på den possitiva sidan).
Jag har bara tillgån till 0-3.3V på kortet och körde tidiare med en OP-förstärkare, rail-to-rail. Men eftersom den började blir linjär först vid 10mv så var det väldigt osäkert att kalibrera denna i det olinjära området och då få stora följdfel. Lösningen jag använde mig av ett tag var att linjärisera signalen från op-förstärkaren i formen A*AD_värde^2 + B*AD_värde + C = linjäriserat värde. Problemet med denna lösningen är att man måste kalibrera alla op-förstärkare var för sig och dessutom kommer olinjäritetn ändras lite med temperaturen.
Jag hittade en delta-sigma AD omvandlare från microchip (mcp3424) som har upp till 8ggr intern förstärkning och klarar av insignaler i området Vss-0.3V och Vdd+0.3V. Den är aningen långsam men det får jag ta.. Jag har testat AD-omvandlaren i det låga intervallet och jämfört med en multimeter och den verkar ge väldigt bra värden.
I den slutliga applikationen så kommer man egentligen bara ha en nogrannhet på -+1% vilket är het OK. det finns såpass många andra faktorer som spelar in så att det egentligen inte spelar så stor roll.
Detta är ett helt privat projekt jag håller på med men eftersom jag ska använda det själv så är det jättekul att få funderingar och kommentarer kring detta.
Det var en väldigt bra förklaring och jag har faktiskt funderat på detta.
jag har nog varit lite otydlig. värdet 40-120 är själva AD värdet när man kalibrerar mot 20.9% syrgas , vilket motsvarar en spänning från sensorn på ca 5-15mV. AD omvandlaren har en förstärkning på 8 vilket ger ett resultat på 5*8 = 40 och 15*8 = 120. i "värsta fall" så har jag en upplösning på 20.9/40= 0.52%/steg. Sensorn är linjär sånär som på 1%. Jag använder 12-bit upplösning med spännings-referensen 2.048V vilket ger svaret i mv vid en förstärkning på 1 vilket är väldigt behändigt. (12 bitar ger 4096 men eftersom jag inte använder det negativa området så blir det 2048 steg kvar på den possitiva sidan).
Jag har bara tillgån till 0-3.3V på kortet och körde tidiare med en OP-förstärkare, rail-to-rail. Men eftersom den började blir linjär först vid 10mv så var det väldigt osäkert att kalibrera denna i det olinjära området och då få stora följdfel. Lösningen jag använde mig av ett tag var att linjärisera signalen från op-förstärkaren i formen A*AD_värde^2 + B*AD_värde + C = linjäriserat värde. Problemet med denna lösningen är att man måste kalibrera alla op-förstärkare var för sig och dessutom kommer olinjäritetn ändras lite med temperaturen.
Jag hittade en delta-sigma AD omvandlare från microchip (mcp3424) som har upp till 8ggr intern förstärkning och klarar av insignaler i området Vss-0.3V och Vdd+0.3V. Den är aningen långsam men det får jag ta.. Jag har testat AD-omvandlaren i det låga intervallet och jämfört med en multimeter och den verkar ge väldigt bra värden.
I den slutliga applikationen så kommer man egentligen bara ha en nogrannhet på -+1% vilket är het OK. det finns såpass många andra faktorer som spelar in så att det egentligen inte spelar så stor roll.
Detta är ett helt privat projekt jag håller på med men eftersom jag ska använda det själv så är det jättekul att få funderingar och kommentarer kring detta.
Re: Matteproblem i C
Nu har jag ifs lämnat matteproblemet men tänkte endå besvara påståendet.
1. få portabel kod.
2. få bättre överbick av vad som händer.
för det första så har jag inte sagt till kompilatorn att flytta "vaje bit" 8 steg åt vänster. Det jag säger är att "alla bitar" ska flyttas 8 bitar åt vänster.
Ditt eget exempel "Resultat = *(uint16)((&tempRes)+1);" visar ganska tydligt att du inte ritkigt själv vet vad du håller på med.
I just detta fallet med denna kompilatorn blir det rätt. Antag att du vill köra samma kod för t.ex en 16 bitars processor eller kanske kompilera koden i ett projekt som kör C++, då är det väldigt stor risk att det blir fel.
Om variabeln "tempres" t.ex finns på adress 0x100 så vill man läsa ut ett 16 bitars värde från adress 0x101. Men kör du på en 16 bitars arkitektur så finns risken att man läser ut värdet från adress 0x102 eftersom du inte specat att det är en 8-bitars adress du vill stega med 1.
I C++ exemplet så finns risken att du läser ut 16 bitars-värdet från adress 0x104 eftersom du stegar pekarern 4 byte eftersom det är en pekare till ett 32-bitars tal.
Din lösning är varken tydlig eller portabel. jag skulle säga att det är ren tur att ditt exempel faktiskt fungerar.
en lösning som jag kör med just nu är:
Det finns forfarande risk att det blir feltolkat mellan olika kompilatorer eftersom strucar och unions är lite upp till kompilatorn att tolka.
Det finns fler exempel på där C18 hittar på dumheter, t.ex om jag vill jämföra 2st tal så kan man göra deta på 2 sätt:
i C18 tar if-satsen i ex2 2-klockcykler mindre tid att exevera fastän man uppnår samma mål.
Det finns fler exempel men orkar inte redovisa alla konstigheter jag hittat.
Den enda optimeringen som inte är tillgänglig i student-versionen är "PROCEDURAL ABSTRACTION". Så som jag tolkar specen så innebär detta att C18 tittar efter återkommande sekvenser som den optimerar till 1 sekvens som den kallar på. detta ger mindre och snabbare kod men verkar inte ha något att göra med ovanstående problem.
Det jag vill komma fram till är att om man måste hålla på och skriva om koden på alla möjliga sätt för att optimera för en viss kompilator så blir koden otydlig och det kan ge konsekvenser om man vill återanvända koden i andra projekt.
Eftersom C18 inte uppfyller dessa krav ser jag det som en väldigt dålig kompilator. Hade jag tänkt skriva koden enbart för PIC så skulle jag nog gått över till assembler.
Om någon vet hur man kan "skriva om" hur C18 ska "översätta" C-koden till assembler så får ni gärna berätta för mig hur man gör.
Jag väljer språket C framför assembler för attOch kompilern gör bara som den har fått veta, den knaser sig alltså inte men programmören gör det...
1. få portabel kod.
2. få bättre överbick av vad som händer.
för det första så har jag inte sagt till kompilatorn att flytta "vaje bit" 8 steg åt vänster. Det jag säger är att "alla bitar" ska flyttas 8 bitar åt vänster.
Ditt eget exempel "Resultat = *(uint16)((&tempRes)+1);" visar ganska tydligt att du inte ritkigt själv vet vad du håller på med.
I just detta fallet med denna kompilatorn blir det rätt. Antag att du vill köra samma kod för t.ex en 16 bitars processor eller kanske kompilera koden i ett projekt som kör C++, då är det väldigt stor risk att det blir fel.
Om variabeln "tempres" t.ex finns på adress 0x100 så vill man läsa ut ett 16 bitars värde från adress 0x101. Men kör du på en 16 bitars arkitektur så finns risken att man läser ut värdet från adress 0x102 eftersom du inte specat att det är en 8-bitars adress du vill stega med 1.
I C++ exemplet så finns risken att du läser ut 16 bitars-värdet från adress 0x104 eftersom du stegar pekarern 4 byte eftersom det är en pekare till ett 32-bitars tal.
Din lösning är varken tydlig eller portabel. jag skulle säga att det är ren tur att ditt exempel faktiskt fungerar.
en lösning som jag kör med just nu är:
Kod: Markera allt
typedef union _DWORD_VAL
{
DWORD Val;
WORD w[2];
BYTE v[4];
struct
{
WORD LW;
WORD HW;
} word;
struct
{
BYTE LB;
BYTE HB;
BYTE UB;
BYTE MB;
} byte;
struct
{
WORD_VAL low;
WORD_VAL high;
}wordUnion;
} DWORD_VAL;
DWORD_VAL tempres;
Result = *(uint16*)&tempres.byte[1]
Det finns fler exempel på där C18 hittar på dumheter, t.ex om jag vill jämföra 2st tal så kan man göra deta på 2 sätt:
Kod: Markera allt
uint16 a, b;
// ex 1
if( a == b)
{
gör nått
}
// ex2
if(a^b == 0)
{
gör nått
}
Det finns fler exempel men orkar inte redovisa alla konstigheter jag hittat.
Den enda optimeringen som inte är tillgänglig i student-versionen är "PROCEDURAL ABSTRACTION". Så som jag tolkar specen så innebär detta att C18 tittar efter återkommande sekvenser som den optimerar till 1 sekvens som den kallar på. detta ger mindre och snabbare kod men verkar inte ha något att göra med ovanstående problem.
Det jag vill komma fram till är att om man måste hålla på och skriva om koden på alla möjliga sätt för att optimera för en viss kompilator så blir koden otydlig och det kan ge konsekvenser om man vill återanvända koden i andra projekt.
Eftersom C18 inte uppfyller dessa krav ser jag det som en väldigt dålig kompilator. Hade jag tänkt skriva koden enbart för PIC så skulle jag nog gått över till assembler.
Om någon vet hur man kan "skriva om" hur C18 ska "översätta" C-koden till assembler så får ni gärna berätta för mig hur man gör.
Re: Matteproblem i C
vad är det för syresensor du använder ?
hur tänker du kalibrera - med olika blandningar av syre och kvävgas från flaska?
hur tänker du kalibrera - med olika blandningar av syre och kvävgas från flaska?
Re: Matteproblem i C
dangraf: "Ditt eget exempel "Resultat = *(uint16)((&tempRes)+1);" visar ganska tydligt att du inte riktigt själv vet vad du håller på med."
Ja, det får stå för dig och din tolkning, jag har levt på att designa µC-lösningar och programmera dessa sedan 1998 och har klarat av detta ganska väl. Och ja, jag är intensivt medveten om skillnaden mellan little endian och big endian och allt det kan ställa till med.
Däremot kan jag vara lite tveksam till ditt kunnande efter vad jag ser här och därmed din bas för ett sånt uttalande.
Att "tricket" fungerar beror på att det är just en 8-bit processor, detta då vissa 16-bitars processorer kräver att 16 bit värden ska vara placerat på en jämn adress.
Jag har i övrigt, i all min okunnighet, fixat så att samma program kan kompileras till en Fujitsu 16-bit processor OCH till en Renesas M16C, samma källkod förutom de hårdvaruspecifika delar, detta betyder att jag kan uppdatera ett program och då kompilera samma källkod till 2 olika processorer, jag kan även länka ihop de resulterande hex-filer och programmera produkten med samma program, oavsett vilken processor det sitter i, den kontrollerar automatisk vilken processor och väljer rätt fil vilket gör att alla uppdateringar är med samma program och baseras på samma källkod.
Slutsumman är att serviceteknikerna uppdaterar utan att veta vilken processor som sitter i och ändå får exakt samma funktionalitet.
Men OK, jag är ju inte bra på detta så det är väl ganska normalt, alla klarar ju detta.
Ja, det får stå för dig och din tolkning, jag har levt på att designa µC-lösningar och programmera dessa sedan 1998 och har klarat av detta ganska väl. Och ja, jag är intensivt medveten om skillnaden mellan little endian och big endian och allt det kan ställa till med.
Däremot kan jag vara lite tveksam till ditt kunnande efter vad jag ser här och därmed din bas för ett sånt uttalande.
Att "tricket" fungerar beror på att det är just en 8-bit processor, detta då vissa 16-bitars processorer kräver att 16 bit värden ska vara placerat på en jämn adress.
Jag har i övrigt, i all min okunnighet, fixat så att samma program kan kompileras till en Fujitsu 16-bit processor OCH till en Renesas M16C, samma källkod förutom de hårdvaruspecifika delar, detta betyder att jag kan uppdatera ett program och då kompilera samma källkod till 2 olika processorer, jag kan även länka ihop de resulterande hex-filer och programmera produkten med samma program, oavsett vilken processor det sitter i, den kontrollerar automatisk vilken processor och väljer rätt fil vilket gör att alla uppdateringar är med samma program och baseras på samma källkod.
Slutsumman är att serviceteknikerna uppdaterar utan att veta vilken processor som sitter i och ändå får exakt samma funktionalitet.
Men OK, jag är ju inte bra på detta så det är väl ganska normalt, alla klarar ju detta.
Re: Matteproblem i C
Syrgassensorn är en "PSR-11-39-MD" som är väldigt vanlig i rebreathers som t.ex "inspiration" från AP-valves.
Jag tänkte kalibera sensorn mot vanlig luft eftersom den håller en nivå av 20.9%syrgas. Det är en vedertagen metod som används runtom i världen, man kompenserar inte för lufttryck och temperatur.
Det hade varit bättre om man kalibrerade mot 100% syrgas(närmre 99%, det går inte att få exakt 100% syrgas) för att ge bättre upplösning och linjäritet. Men för tillfället så har jag ingen bra mekanisk lösning för att släppa ut gasen och vara säker på att sensorn får 100% gas från tuben utan att den blandats med luft. Jag får komma på en bra lösning på detta problmet senare och tänkte börja med att kalibrera mot luft där jag kan vara helt säker på syrgashalt.
Jag tänkte kalibera sensorn mot vanlig luft eftersom den håller en nivå av 20.9%syrgas. Det är en vedertagen metod som används runtom i världen, man kompenserar inte för lufttryck och temperatur.
Det hade varit bättre om man kalibrerade mot 100% syrgas(närmre 99%, det går inte att få exakt 100% syrgas) för att ge bättre upplösning och linjäritet. Men för tillfället så har jag ingen bra mekanisk lösning för att släppa ut gasen och vara säker på att sensorn får 100% gas från tuben utan att den blandats med luft. Jag får komma på en bra lösning på detta problmet senare och tänkte börja med att kalibrera mot luft där jag kan vara helt säker på syrgashalt.
Re: Matteproblem i C
>>Icecap
Alla gör fel. Min mening var inte att peka ut att "du har fel". Huvudpoängen var att jag tycker att kompilatorn borde fixa en shift-operation på 8 steg på mindre än 82 cykler eftersom det är en kopilator till en 8-bitars processor.
Jag blev minst lika irriterad på dig när du sågade min shift-operation som du är på mig nu när jag visat att även din lösning kan gå fel.
Jag tänkter inte börja berätta om "hur duktig jag är" för att mäta mig med dig, du har säkert mer erfarenhet. Jag förstår inte riktigt vart du vill komma med ditt senaste inlägg. Är mitt påstående fel om att det kan bli fel om man kompilerar i en annan miljö eller för en annan kompilator?
Alla gör fel. Min mening var inte att peka ut att "du har fel". Huvudpoängen var att jag tycker att kompilatorn borde fixa en shift-operation på 8 steg på mindre än 82 cykler eftersom det är en kopilator till en 8-bitars processor.
Jag blev minst lika irriterad på dig när du sågade min shift-operation som du är på mig nu när jag visat att även din lösning kan gå fel.
Jag tänkter inte börja berätta om "hur duktig jag är" för att mäta mig med dig, du har säkert mer erfarenhet. Jag förstår inte riktigt vart du vill komma med ditt senaste inlägg. Är mitt påstående fel om att det kan bli fel om man kompilerar i en annan miljö eller för en annan kompilator?
