ik ben bezig met deze code, het betreft een touch screen uitlezing aansturing van 12 PWM kanalen en nog een hoop meer ik heb er zoveel mogelijk omschrijving van de functies bij gezet.
de software is geschreven in sourceboost.
echter ik heb 2 (3) rare probleempjes.
1. De auto calibratie welke de waarden zou op moeten slaan in de EEPROM werkt niet? calibratie werkt wel maar het opslaan in de EEPROM niet. spanning eraf en alles is weg.
2. Op de 2de uitgang van PWM zit een onverklaarbare flikker??? Iedere sec (circa). Springt groen ff vol aan voor 0,1s.
3. Dit is ook terug te zien op de led display welke aangestuurd wordt met de 74hc595. hierop is hetzelfde effect te zien maar ze zijn beiden niet gelijktijdig.
software:
www.winius.net/pwn.c {nieuw}
www.winius.net/pwm2.c {oud}
bij voorbaat dank
klein is fijn
Moderator
Jemig wat een lap.. Nu vind ik C al onleesbaar, en dit is onbegonnen werk.
Opdelen in stukken en per stuk apart testen. Als je PWM raar doet sloop je alle code weg die niets met PWM te maken heeft en probeer je het opnieuw. Doet ie nog steeds raar, dan weet je waar je moet zoeken. Doet ie niet meer raar, dan ga je de rest stukje bij stukje weer erbij zetten. Waar het fout gaat, daar moet je zoeken.
WilToyo
Maak me niet gek, ik ben al gek.
1. De auto calibratie welke de waarden zou op moeten slaan in de EEPROM werkt niet? calibratie werkt wel maar het opslaan in de EEPROM niet. spanning eraf en alles is weg.
Werkt je EEPROM routine naar behoren? EEPROM's willen nog weleens trage krengen zijn (ook die in microcontrollers). Plak daar eens wat while lussen tussen, waarin je controleerd of de bits die je wilt setten ook daadwerkelijk geset zijn.
2. Op de 2de uitgang van PWM zit een onverklaarbare flikker??? Iedere sec (circa). Springt groen ff vol aan voor 0,1s.
Ik zie daar ergens een enorm lange if-lus (PWM-program). Maak daar eens een switch-lus van, best kans dat je van het geflikker af bent. Er zitten trouwens wel meer lange if-lussen, maar dit is wel een hele lange. Je moet ook proberen if-lussen in if-lussen te vermijden, anders wordt het al snel onoverzichtelijk.
3. Dit is ook terug te zien op de led display welke aangestuurd wordt met de 74hc595. hierop is hetzelfde effect te zien maar ze zijn beiden niet gelijktijdig.
Komt waarschijnlijk door die if-lus, dat leverd vertraging op.
Hoe heb je de code geschreven? In 1 keer en toen getest. Of in delen, functie geschreven, getest, volgende functie geschreven, getest etc.?
http://pastebin.com/f66836761
Dat maakt het makkelijker te lezen 
unsigned char sRed1; //Red 1 value
unsigned char sGreen1; //Green 1 value
unsigned char sBlue1; //Blue 1 value
unsigned char sRed2; //Red 2 value
unsigned char sGreen2; //Green 2 value
unsigned char sBlue2; //Blue 2 value
unsigned char sRed3; //Red 3 value
unsigned char sGreen3; //Green 3 value
unsigned char sBlue3; //Blue 3 value
unsigned char sRed4; //Red 4 value
unsigned char sGreen4; //Green 4 value
unsigned char sBlue4; //Blue 4 value
Weet je wat een array is? 
char EEPROM_READ(char adresa) // read from EEPROM
{
eeadr = adresa;
set_bit( eecon1, RD); // start reading
return eedata;
}
Tussen set_bit en return moet een nop, anders gaat het uitlezen niet goed.
//Red Led
if (L1r>L)
{
set_bit(portd,4);
}
else
{
clear_bit(portd,4);
}
[....]
//Blue Led
if (L4b>L)
{
set_bit(portb,7);
}
else
{
clear_bit(portb,7);
}
L++;
Dat moet je toch echt anders doen, ten eerste kan dat prima met een array en een loop, ten tweede zou het mooi zijn om het resultaat van de vergelijking direct aan het bit toe te wijzen, al werkt dat alleen als least significant bit geset wordt in de waarde die de vergelijking teruggeeft.
Verder zie ik nog wat kleine slordigheidjes, zoals:
if (Dn > 0)
{
switch (Dn)
{
case 1:
Da = rcreg;
Dn = 0;
break;
case 2:
Db = rcreg;
Dn = 0;
break;
[...]
default:
Dn = 0;
break;
}
}
Bij elke vergelijking van de switch set je Dn op 0, waarom doe je dat niet gewoon na de switch?
Eigenlijk moet je hiervoor helemaal geen switch gebruiken, je kunt beter een array maken van 7 elementen en de waarde in Dn gebruiken om een element te kiezen.
Jochem
If you want to succeed, double your failure rate.
Op 20 juni 2008 01:05:33 schreef bobo1on1:
http://pastebin.com/f66836761
Dat maakt het makkelijker te lezen
Grappige site, maar als je gewoon een editor met C-syntax highlighting hebt (don't we all?) opent hij 'm daar zelf in als je de link van TS gebruikt.
@TS: Neem de opmerkingen ter harte en deel je code op in compacte blokken die je ook losstaand kunt testen. Verder zou het leuk zijn om wat functieheaders e.d. in te voegen als je anderen om hulp gaat vragen, is voor jezelf ook handig als je later op je code terugkijkt.
Nog een tip: Volgens mij wordt aangeraden om de interrupts uit te zetten tijdens het schrijven naar de eeprom. (In ieder geval bij de 628) Ik vind dit zo snel niet terug in je code.
alle code is bijna los staand getest echter nu is alles samengevoegd en doen der problemen voor.
alleen de eeprom is niet los getest.
pwm werkte prima los en ook in combinatie met een hoop andere code. echter sinds toevoeging van het schuifregister dient zich dit probleem voor.
array's ben ik relatief onbekend mee.. ik schrijf liever code die werkt dan dat ik eerst 20 uur weer moet uitzoeken en dan pas kan schrijven.
sommige delen komen ook uit andere stukken code van vorige projecten.
de PWM met if constructie werkt stand alone prima. en ook werkt het nog prima zonder knipperen als je kijkt naar de uitsturing.. echter er is 1 kanaal L1G welke hem gewoon af en toe voluit knalt voor 0,1s.. het andere kanaal L1r doet het prima.
Het lijkt mij ook in de interrupt te zitten.
niet alle software is van mijn hand, dit maakt het voor sommige delen voor mij een stuk lastiger te begrijpen.
de unsigned char sRed1 is bijvoorbeeld in de code al komen te vervallen zover ik weet.
tevens het RS232 programma zit er wel in maar wordt verder nog niet gebruikt.
Op 20 juni 2008 07:54:42 schreef Jochem_S:
[...]Grappige site, maar als je gewoon een editor met C-syntax highlighting hebt (don't we all?) opent hij 'm daar zelf in als je de link van TS gebruikt.@TS: Neem de opmerkingen ter harte en deel je code op in compacte blokken die je ook losstaand kunt testen. Verder zou het leuk zijn om wat functieheaders e.d. in te voegen als je anderen om hulp gaat vragen, is voor jezelf ook handig als je later op je code terugkijkt.
stonden er nog geen functie headers in dan? dacht dat grote delen er wel in stonden al, maar kan zijn dat her en der nog ontbreken omdat de software is samen gevoegd tot 1 groot pakket.
In ieder geval iedereen al super bedankt voor alle tips en kritiek ik ga er naar kijken 
!!!
[Bericht gewijzigd door veenie op (23%)]
Jochem
If you want to succeed, double your failure rate.
Op 20 juni 2008 11:09:13 schreef veenie:
stonden er nog geen functie headers in dan?
Waar ik keek niet, maar mede daarom heb ik het vrij snel voor gezien gehouden
dacht dat grote delen er wel in stonden al, maar kan zijn dat her en der nog ontbreken omdat de software is samen gevoegd tot 1 groot pakket.
Dat is ook het gevoel wat ik krijg als ik die code voor m'n neus krijg: '1 groot pakket' waar je eens flink in moet gaan graven.
zit het probleem hem niet Bij de eeprom in het feit dat ik void eeprom null oproep bij iedere keer opstarten???
Gatze
Congratulations on your purchase. To begin using your quantum computer, set the power switch to both off and on simultaneously
Op 20 juni 2008 11:09:13 schreef veenie:
array's ben ik relatief onbekend mee.. ik schrijf liever code die werkt dan dat ik eerst 20 uur weer moet uitzoeken en dan pas kan schrijven.
Arrays zijn simpel. En je code wordt veel leesbaarder. en dat duurt geen 20 uur. En je hebt je rest van je leven profijt van. (als c over 50 jaar nog bestaat.)
Dit
unsigned char sRed1; //Red 1 value
unsigned char sGreen1; //Green 1 value
unsigned char sBlue1; //Blue 1 value
unsigned char sRed2; //Red 2 value
unsigned char sGreen2; //Green 2 value
unsigned char sBlue2; //Blue 2 value
unsigned char sRed3; //Red 3 value
unsigned char sGreen3; //Green 3 value
unsigned char sBlue3; //Blue 3 value
unsigned char sRed4; //Red 4 value
unsigned char sGreen4; //Green 4 value
unsigned char sBlue4; //Blue 4 value
kan dit worden
unsigned char sRed[4];
unsigned char sGreen[4];
unsigned char sBlue[4];
Waarbij je bijvoorbeeld de 2 led van rood op de volgende manier een waarde geeft
sRed[2]=255;
Dit is een stuk gemakkelijker en leesbaarder. Ik raad het je echt aan om zulke dingen te leren het scheelt echt.
succes!
ok eeprom fixed!! YEAHEE alleen nog de flits in me outputs... zit in de interrupt vermoed ik..
daarna de software weer even compacter schrijven en netter.
tnx voor de support en tips!
regel: 143 - 146
void EEPROM_NULL();
char EEPROM_READ(char adresa);
void EEPROM_WRITE(char adresa,char data);
regel: xxx?
void EEPROM_NULL() // erase all EEPROM
{
eeadr=0;
while(eeadr<=63)
{
eedata=0;
EEPROM_WRITE(eeadr,eedata);
}
}
dit stukje code veroorzaakt het probleem in de interrupt maar waarom en wat is er aan te doen?
regel: 792
Transfer_Array(dbMaster);
regel: 805-808
dbPos++;
if(dbPos > 5)
dbPos = 0;
@bobo1on1:
Zou je kunnen laten zien hoe dit beter kan dan in dit geval? hoe je het precies bedoelt?
Dat moet je toch echt anders doen, ten eerste kan dat prima met een array en een loop, ten tweede zou het mooi zijn om het resultaat van de vergelijking direct aan het bit toe te wijzen, al werkt dat alleen als least significant bit geset wordt in de waarde die de vergelijking teruggeeft.
EDIT: die arrays zijn echt top! 
maakt het stuk overzichtelijker inderdaad!
hmm nog een vreemd probleem erbij.
Af en toe wordt de waarde verhoogt van xx naar 255 in het pwm zonder reden.. Dit gebeurt echter maar af en toe en geheel onregelmatig soms elke 5 min soms 1x in de 2 uur. bugje? hij blijft dan ook hoog staan.
*nieuwe code is toegevoegd.
bobo1on1 zou je nog willen laten weten hoe ik het kan verbeteren in de interrupt?