next topic »

[Reply #15 on:]

@Stefan:

messprobleme werden minimiert, weil der kleine at nur auf daten wartet und sonst nichts zu tun hat.
programmierfehler werden ohne interrupts viel einfachen eingrenzbar.

und wenn er nach 0,1 sek fertig ist, kann er in ruhe die daten zum arduino senden, weil andere aufgaben hat er nicht

Versteh ich nicht ganz: Während er 100 msec lang rechnet und dann in Ruhe Daten zum Arduino sendet, müssen die Pulse doch per Interrupt verarbeitet werden, oder ?

Ob der kleine "ATirgendwas" in Ruhe Daten zum Arduino sendet, oder, wenn er sonst nichts mehr zu tun hat, ein Display aktualisiert, ist doch kein wesentlicher Unterschied ?

Interruptgesteuertes Pulse erfassen ist in jedem Fall erforderlich, ansonsten kann alles "in Ruhe" gemacht werden. Ob die Anzeige "ruckelt", hat TelosNox noch nicht gestört. Welche anderen Echtzeit-Anforderungen siehst du ?

[Reply #16 on:]

"Daten senden" ist in der Regel langwierig. Das bischen Zählen und rumrechnen kann man locker in den Interrupts erledigen. Ja, Interrupts sind einen Tick schwieriger zu programmieren. Aber Systeme mit 2 unabhängigen Prozessoren die aus welchen Gründen nicht mehr miteinander reden wollen sind auch nicht wirklich leichter in den Griff zu bekommen.

Ich würde für sowas auf keinen Fall einen zweiten Prozessor spendieren. Da lohnt es sich mehr sich richtig in Interrupts einzuarbeiten. So schwierig ist das ja nun auch nicht.

[Reply #17 on:]

hi,

Versteh ich nicht ganz: Während er 100 msec lang rechnet und dann in Ruhe Daten zum Arduino sendet, müssen die Pulse doch per Interrupt verarbeitet werden, oder ?

ich meinte eigentlich, daß er das abwechselnd macht, also:
daten sammeln
berechnen
senden
damit wäre er ja beim pulse sammeln ungestört

"Daten senden" ist in der Regel langwierig

das habe ich nicht bedacht. ich hab meine arduinos noch nicht miteinander "reden" lassen. habe ich mir wohl einfacher vorgestellt.

gruß stefan

[Reply #18 on:]

Sauberer IO ist fast immer schwieriger als der ganze Rest. Und zwar nicht nur beim Arduino sondern ganz allgemein. Und verteilte Programme sind immer schwieriger als normale. Ob die Verteilung durch Threads, Interrupts oder durch verschiedene CPUs erfolgt ist eigentlich egal. Nur kommt im Fall von getrennten CPUs das IO Problem dazu. Deshalb lieber Interrupts. Wie gesagt, dass ist nicht Arduino spezifisch sondern so gut wie immer so.

[Reply #19 on:]

Ich hab jetzt den neuen Code ausprobiert und immer noch das gleiche Ergebnis (bei 100km/h Tacho habe ich ca. 84km/h auf dem Arduino).
Ich weiß, dass der Tacho bei 100km/h ca. 7km/h vor geht (laut Navi). Demnach MUSS der errechnete Wert zu wenig sein.

Ich könnte mir vorstellen, dass der Radumfang vielleicht etwas zu klein ist. Ich habe 195cm eingestellt (gemessen), manch andere haben 198cm. Das wären aber auch nur 1,5% Differenz, das würde sich gar nicht auswirken (1km/h mehr).

Ich wollte das aber lediglich berichten. Aktuell belasse ich es einfach dabei, da ich keine Lust habe immer wieder die Verkleidung auf zu machen, damit ich neu programmieren kann.

[Reply #20 on:]

Wieso Verkleidung aufmachen? Leg doch einen Programmieranschluss nach außen.

[Reply #21 on:]

heute bekommt wirklich schon alles einen USB-anschluß...

[Reply #22 on:]

Wieso Verkleidung aufmachen? Leg doch einen Programmieranschluss nach außen.

Ich hab ein Gehäuse, in das der Arduino gerade so reinpasst. Da geht kein Stecker mehr in den USB Port.
Wenn ich ein größeres Gehäuse nehme, dann passt es nachher eventuell nicht mehr rein.

Eine Lösung wäre ein USB Kabel direkt dran zu löten. Aber das will ich nicht machen, dann kann ich den Arduino nicht im Bedarf einfach wieder austauschen (bisher ist alles über ein selbstgebautes Shield gelöst).

Davon abgesehen wüsste ich ja sowieso nicht, was ich noch ausprobieren sollte.

[Reply #23 on:]

hi,

Davon abgesehen wüsste ich ja sowieso nicht, was ich noch ausprobieren sollte.

was mir dazu einfällt: montiere einen camcorder so, daß er den tacho aufnimmt, und beschleunige auf einer geraden strecke mal rauf. gleichzeitig protokolliere die pulse, die der µC erhält (die reinen pulse, nichts berechnen lassen). mit zb. media player classic (gratis) kannst Du zu jeder position des filmes springen. mach dir in excel eine wertetabelle sek : km/h : pulse. laß Dir beides zusammen in einer grafik anzeigen. so eine optische hilfe kann einen weiterbringen, um zusammenhänge zu verstehen.

ich weiß, etwas aufwendig, aber wenn man nicht weiter weiß...

gruß stefan

[Reply #24 on:]

Kamera wäre vorhanden und auf entsprechende Software hätte ich auch Zugriff.

Allerdings wäre es wieder zu viel Aufwand dafür, dass ich die Geschwindigkeit lediglich anzeige und keinen genauen Wert brauche. Die Geschwindigkeit dient mir ja lediglich um:
1. zu erkennen, ob das Tachosignal funktioniert
2. die Geschwindigkeitsprogression des Kettenölers zu berücksichtigen (höhere Geschwindigkeit = mehr abgeschleudertes Öl = früher nachölen)

Dafür reichen mir ungenaue Werte und im Zweifel wird halt mal 10m zu spät geölt, weil die errechnete Geschwindigkeit langsamer war. Bei einem Raster von 100m für die Einstellung sind diese 10m dann auch egal.
Ihr wisst, was ich meine. Die ganze Ölerei ist ja sowieso alles nur pi mal Daumen.

Was mich antreibt ist rein nur der Ehrgeiz herauszufinden, ob ich in meinem Code scheiße gebaut hab (ich bin Softwarentwickler, da sollte ich fähig sein einen funktionierenden Code zu basteln), oder ob das Tachosignal doof ist oder sonst irgendwas in der Art.

Ich war auch schon am überlegen, ob ich mir nicht testweise als Debug mal die Ticks pro Sekunde anzeigen lasse. Das würde zumindest zeigen, ob die Ticks linear mit dem Tacho laufen oder ob vielleicht da bereits ein Fehler ist. Dann kann man darauf schließen, dass die Berechnung stimmt bzw. falsch ist.

Was es mir halt so richtig schwer macht ist die Ableserei. Das Display hängt direkt am Lenker. Ich muss also immer vom Tacho wegschauen. So super 100% konstant Gas geben kann kaum jemand. Also schwankt es immer ein wenig. Den Wert am Display für genau 50km/h Tacho abzulesen ist also nicht gerade einfach.

[Reply #25 on:]

hi,

genau das meinte ich ja mit camcorder. dann brauchst Du garnicht hinzusehen. und wie gleichmäßig gas Du gibst ist auch egal (ein weiterer nebeneffekt ist die dankbarkeit des typen, den Du nicht überfahren hast). Du hast dann immer zwei parallele vergleichswerte. ich wußte nicht, daß ohnehin beide displays nahe aneinander sind. machts ja noch leichter.

Ich war auch schon am überlegen, ob ich mir nicht testweise als Debug mal die Ticks pro Sekunde anzeigen lasse.

genau, das und den tachowert auf einem bild.

gruß stefan