Hoppla das ging ja schnell !
Also wenn ich das richtig verstanden habe müsste ich das dann so machen:
1
...
2
while(1)
3
{
4
cli();
5
rise1=rise;
6
fall1=fall;
7
pulse1=pulse;// pulse duration
8
sei();
9
OCR1B=pulse1;
10
uart_puts(utoa(rise1,s,10));//************
11
uart_puts("\t");//***********
12
uart_puts(utoa(fall1,s,10));//************
13
uart_puts("\t");//***********
14
uart_puts(utoa(pulse1,s,10));//************
15
uart_puts("\n\r");//***********
16
_delay_ms(20);//***********
17
18
}
19
...
oder ?
sorry aber hab erst vor kurzem mit dem Programmieren angefangen
Ich bekomme dann aber immernoch falsche Werte, ist das vielleicht wenn
genau dann ein Flankenwechsel zwischen cli(); und sei(); auftritt?
Auch wenn ich OCR1B= pulse; direkt in der ISR setzte stimmt der Impuls
auf dem Oszi nicht immer ??
Peter wrote:
> Na super. Dann lerne doch erstmal Programmieren, bevor du versuchst, zu> rechnen!>> Die Überschrift lautete wohl treffender:> Bin ich noch blöder als ich aussehe?!
Da bin ich gerade dabei, ich kann aber nicht alles auf Anhieb und suche
deshalb Hilfe im Forum. Auf solch blöde Kommentare von Leuten wie dir
kann ich dabei gerne verzichten. Du konntest wahrscheinlich alles gleich
auf Anhieb ...
na.. er ist halt der SUPER PETER ;-) (legte sein Rosarotes Cape um die
Schultern und flog davon .. plopp).
Aber mach dir nix draus es gibt halt immer wieder so überaus schlaue
Menschen, die von sich meinen alles überall und immer besser gemacht zu
haben oder die gleich als Superhacker(es gibbet nur einen!) auf die Welt
gekommen sind fg
in diesen Sinne .. die Macht ist bei dir Luke!!
Gruß euer Superhacker
> Die Überschrift lautete wohl treffender:> Bin ich noch blöder als ich aussehe?!
Na du Superprogrammierer. Wo liegt denn das Problem in
diesem Programm? Ich halte mich nicht für einen schlechten
Programmierer und ich bin weis Gott kein Anfänger. Aber
ich sehe das Problem auch nicht.
Also Super-Peter. Erhelle uns.
@Lukas
Mach dir nichts draus.
Dein Problem ist knifflig. Irgendetwas übersehen wir
(oder der Compiler). Ich hab schon versucht mal mit einem
Taschenrechner ein bischen mit den Zahlen zu spielen um
rauszukriegen, was hier tatsächlich gerechnet wird. Aber
irgendwie komme ich auf keinen grünen Zweig.
Das hab ich auch schon versucht ;-), aber selbst wenn ich direkt in der
ISR den OCR1B setzte und die RS232 deaktiviere funktioniert es nicht :-(
aber trotzdem Vielen Dank für Eure Vorschläge
Hmmm, Da muss Deep Thought seine Finger im Spiel haben... Ist Dir
aufgefallen, dass alle falschen Zahlenwerte mit 42 anfangen? ;-)
Ich habe mir das ganze jetzt auch mal genauer angesehen, aber kein
System bei den falschen Werten gefunden (eben bis auf die o.g.
Tatsache). An der Auswertung an sich scheint nichts verkehrt zu sein.
@Läubi:
Genau das macht er ja jetzt. Da dürfte es keine Kollisionen mehr geben.
Lukas Keller wrote:
> Also wenn ich das richtig verstanden habe müsste ich das dann so machen:>
1
>...
2
>while(1)
3
>{
4
>cli();
5
>rise1=rise;
6
>fall1=fall;
7
>pulse1=pulse;// pulse duration
8
>sei();
9
>OCR1B=pulse1;
10
>uart_puts(utoa(rise1,s,10));//************
11
>uart_puts("\t");//***********
12
>uart_puts(utoa(fall1,s,10));//************
13
>uart_puts("\t");//***********
14
>uart_puts(utoa(pulse1,s,10));//************
15
>uart_puts("\n\r");//***********
16
>_delay_ms(20);//***********
17
>
18
>}
19
>...
20
>
> oder ?
Sieht gut aus.
> Ich bekomme dann aber immernoch falsche Werte,
Sind die falschen Werte immer noch im Bereich von ~43000
oder hat sich dieser Wertebereich in Richtung 64000 verschoben?
Ja sorry. Ich hab zuwenig geschalfen.
Komm auch nicht drauf einzige idee wäre --> Überlauf
War da nicht mal was das manche COmpiler andere Datenwortlängen haben
als die Orginal "PC-Typen"???
(Welchen Wertbereich hat unsigned short?)
Ich hab da eine Theorie.
Wenn ich deine ISR mal etwas einrücke, kommt folgendes
heraus.
1
ISR(SIG_INTERRUPT0)
2
{
3
if(PIND&(1<<PD2))// rising edge
4
rise=TCNT1;
5
elseif(!(PIND&(1<<PD2)))// falling edge
6
fall=TCNT1;
7
8
pulse=fall-rise;
9
}
Das Problem ist jetzt, dass du pulse auch dann neu berechnest
wenn du einen neuen rise Wert hast. In dem Fall macht aber
eine pulse Berechnung keinen Sinn, denn du Berechnest hier
die Zeit von der letzten fallenden Flanke zur jetzigen
steigenden Flanke.
In den meisten Fällen ist diese unnötige Berechnung belanglos,
nur ab und zu erwischt du in main() die Berechnung in einem
Zustand, in dem genau dieser Zustand herrscht: Du hast nicht
die Zeit von der steigenden bis zur fallenden Flanke berechnet
sondern von der fallenden Flanke bis zur steigenden Flanke.
Vorschlag:
Probier mal:
Hi
hat wohl eher nichts mit rechnen zu tun kontrolliere doch mal zeile 14
13353 39797 1529
das ist wohl auch nicht ganz richtig. solch fehler kommen mindestens 4
mal vor
Gruß elko
Habe nur einen ISPMKII, und mit dem Softwaredebugging bin ich auch nicht
weiter gekommen, aber wenn ich es so mache dann geht es :-) fragt mich
nicht warum aber es geht !!
1
ISR(SIG_INTERRUPT0)
2
{
3
if(PIND&(1<<PD2))// rising edge
4
rise=TCNT1;
5
elseif(!(PIND&(1<<PD2)))// falling edge
6
{
7
fall=TCNT1;
8
pulse=fall-rise;
9
OCR1B=pulse;
10
}
11
}
Danke nochmal für eure Bemühungen
@Karl heinz Buchegger:
Danke genau das war das Problem
Kleines Gedankenexperiment.
Darf man bei unsigned int einfach so Subtrahieren ohne auf die Grösse
der operanden zu achten?
Der Identifier "unsigned" bedeutet doch "ohne Vorzeichen"
Beispiel:
Unsigned int a,b,c;
a = 30000;
b = 32000;
c = a - b
Nach Adam Riese:
30000 - 32000 = -2000
Aber da "unsigned" VAriablen nicht negativ werden können, was steht dann
wohl in Variable c?
In deinem Code steht:
/*
.
.
.
volatile unsigned short int rise;
volatile unsigned short int fall;
volatile unsigned short int pulse;
.
.
.
pulse = fall-rise;
*/
> Aber da "unsigned" VAriablen nicht negativ werden können, was steht dann> wohl in Variable c?
Da steht die Zweierkomplement-Darstellung von "-2000", also 0xF830 oder
63536...
Lukas Keller wrote:
> aber wenn ich es so mache dann geht es :-) fragt mich> nicht warum aber es geht !!
Also doch.
Du hast eine Race Condition.
Das eigentliche Problem ist, dass du unsynschronisiert
aus der main Schleife auf die Variablen zugreifst
(das erklärt auch die Anomalie, die elok entdeckt hat)
Deine main() Schleife kümmert sich nicht darum, ob eine
vollständige Messung (also Detektierung der rising edge,
Detektierung der falling edge und Berechnung der Pulsdauer)
erfolgt ist.
Angenommen du hast eine vollständige Messung
Die rising edge war 13059
die falling edge war 15089
dann wird eine neue rising edge festgestellt.
Neuer Wert 14234
Aber noch bevor die falling Edge kommt, greift sich das
Hauptprogramm die Werte ab und erhält:
rising edge 14234
falling edge 15089
Du hast also 2 Messwerte aus völlig unterschiedlichen Messungen.
Du musst dir ein Flag in der ISR setzten, dass der main() Schleife
signalisiert, dass die Messung vollständig ist.
Lukas Keller wrote:
> Habe nur einen ISPMKII, und mit dem Softwaredebugging bin ich auch nicht> weiter gekommen, aber wenn ich es so mache dann geht es :-) fragt mich> nicht warum aber es geht !!
Hat Karl Heinz doch erklärt.
Und das 2.Testen des Pins ist unnütz.
Wenn er nicht 1 war, muß er 0 sein. Binärsignale können nur 2 Zustände
haben.
Schau Dir mal mein oberes Posting an.
Peter
>ja das hab ich gelesen, allerdings erst nach meinem posting,>danke für den tipp mit der unnützen Abfrage, is ja eigenlich klar ;-)
Eigentlich war der Fehler von Anfang an klar. Uneigentlich auch. Wie
schrieb der Typ weiter oben? Wer nichr Programmieren kann, sollte nicht
auch noch versuchen, Probleme zu lösen. Bei deiner Überheblichkeit wirst
du es nicht weit bringen. Wir habe dir diesmal weitergeholfen, aber
gelernt hast du nichts.
Karl wrote:
>>ja das hab ich gelesen, allerdings erst nach meinem posting,>>danke für den tipp mit der unnützen Abfrage, is ja eigenlich klar ;-)>> Eigentlich war der Fehler von Anfang an klar.
Warum hast du dann nicht gleich mit dem Finger darauf gezeigt?
Ich kann mich nicht erinnern, ein Posting von dir gesehen zu haben.
> schrieb der Typ weiter oben? Wer nichr Programmieren kann, sollte nicht> auch noch versuchen, Probleme zu lösen.
Von dem Typen hab ich zwar einige blöde Sprüche in Erinnerung
aber seltsamerweise ist mir keine einzige C-Problemlösung von
ihm im Gedächtnis geblieben.
Es ist hinterher immer leicht, gescheit zu sein.
Du kennst die urban legend von Kolumbus und dem Ei?
> Bei deiner Überheblichkeit wirst> du es nicht weit bringen.
Ich seh in seinen Antworten keineswegs Überheblichkeit.
Wenn man das erste mal auf race conditions trifft, dann können
die einem den Schlaf rauben. Und dafür, dass er noch nicht
lange µC programmiert, ist sein Programm wirklich nicht schlecht
geschrieben. Zumindest wurde hier schon jede Menge schlechteres
Material präsentiert.
> Wir habe dir diesmal weitergeholfen, aber> gelernt hast du nichts.
Das kannst du natürlich beurteilen. Und bevor du fragst:
Nein, ich kann es auch nicht beurteilen. Aber zumindest hab
ich versucht ihm zu erklären, wo das Problem liegt und wenn
er die Erklärung nur halbwegs verstanden hat, dann hat er schon
eine Menge dabei gelernt.
Das sollte auch keineswegs überheblich gemeint sein. Ich bin froh hier
im Forum so tolle und schnelle Hilfe gefunden zu haben.
@ Karl heinz Buchegger:
Ja Danke deine Erklärungen haben mir sehr weitergeholfen, war super
verständlich geschrieben.
Gastarbeiter wrote:
> void loop_hammer(void);
Das Semikolon solltest Du da besser entfernen...
> printf("Persönlichkeiten werden nicht");> printf("durch schöne Reden geformt");> printf("sondern durch Arbeit und eigene Leistung")
Und hier jeweils eins hinter die Zeilen - ich würde auch noch ein \n ans
String-Ende setzen, sonst wird die Ausgabe recht unleserlich.
ich tip mal auf einen überlauf.
volatile unsigned short int x;
würd ich nicht so schreiben. besser wäre uint16_t x;
versuchs mal mit nem 32bit breiten wort. bin jetzt zu müd um das genau
durchzurechnen müsste aber glaub schon ein 32bit wort sein.
gruss sven
Thread beobachten
Seitenaufteilung abschalten