'nabend Allerseits, nach langer Zeit versuche ich mich nun bei den AVRs statt mit asm erst einmal mit BASCOM, was auch vergleichsweise zu sehr vielen Erfolgen führt. Mein erstes sinnvolles Projekt soll eine Verbrauchsanzeige für mein Motorrad sein. Die Grundidee ist auch schon fertig und ein erstes kleines Testprogramm mit simulierten Daten lief erfolgreich. Im Grunde möchte ich zwei Sensordaten auswerten, beides in Form von einem Rechtecksignal. Zum einen von einem Durchflussmesser, der den Fluss von Tank zum Vergaser misst und zum anderen einen Sensor, der die Drehfrequenz des Hinterrades erfasst. Nun lese ich aber nur von der Möglichkeit Impulse mit dem Timer0 und dem Pin T0 zu zählen, für eine erfolgreiche Messung bräuchte ich allerdings zwei Zähler. Dabei stoße ich etwas an meine derzeitigen Grenzen und ich finde eigenständig keine Lösung. Ich hatte schon an eine Lösung mit einem zweiten AVR gedacht, welcher dann die Sensordaten via TWI zur verfügung stellt, aber das ist für mich keine saubere Lösung... Gibt es keine Möglichkeit Impulse mit einem x-beliebigen Eingang zu zählen? Beste Grüße
Steven T. schrieb: > Gibt es keine Möglichkeit Impulse mit einem x-beliebigen Eingang zu > zählen? Das kommt drauf an, mit welcher Frequenz die Pulse kommen. Für die meisten AVRs dürfte das bei "handlichen" Frequenzen kein Problem sein. Keine Ahnung, ob das auch in Bascom geht.
Mit welchem Anschluss Du die Impulse misst ist völlig egal. Ohne Zeitbezug aber gilt hier: Wer misst misst Mist. Bis zu einer gewissen Geschwindigkeit/Wiederholrate kannst Du in einer Endlosschleife jeden Eingang zyklisch abfragen, um festzustellen was Sache ist. Tut sich hier (bei der jeweiligen Abfrage) aber was, brauchst Du eine zeitliche Referenz. Es ist eine oft übersehene Tatsache, dass ein Timer als Basis für verschiedene Zeitraster verwandt werden kann...
Alle AVRs mit Pin-Change-Interrupt bieten die Möglichkeit, Pegeländerungen an fast allen Port-Pins zu erfassen. Ansonsten gibt es immer 2 Eingänge: Int0 UND Int1. Die Pulszahl muss ja nicht in einem Zähler landen, sie kann auch in Registern gesammelt werden. Bis zu etlichen kHz geht das per INT0/INT1/PCHG-Interrupt. Ein bisschen Drumherum mit einer Zeitreferenz (TimerX) usw. musst du natürlich im Programm bereitstellen.
Danke, das hilft mir schon einmal beachtlich weiter. Allerdings stellt sich mir die Frage, ob die Messung dann noch zuverlässig ist, wenn z.B. der Eingang INT0 ständig den Programmablauf unterbrechen lässt, immerhin könnte das auch mal gut 40 mal die Sekunde passieren oder beeinflusst das die Zählung vom Timer0 nicht?
40 Impulse pro Sekunde sollten kein Problem sein. Ein supereinfacher Ansatz: Im Hintergrund läuft ein Timer als pseudo Echtzeituhr indem er z.B. einen Zähler alle paar µs inkrementiert. Der Zählerstand sollte möglichst nicht "überlaufen". Also sollten 64 Bit Breite ausreichen. Das Inkrementieren einer einzelnen Zahl braucht nur wenige Taktzyklen. Bei jeder Ansteigenden Flanke holst Du Dir den aktuellen Zählerstand und ziehst den Vorgänger ab. Je nach Zeitraster hast Du auf diese Weise eine Zeitbasis.
Amateur schrieb: > Also sollten 64 Bit Breite ausreichen. Ich fürchte, du überschätzt die Dauer einer 1/40 Sekunde. Selbst wenn du deinen Zähler mit 20MHz taktest, d.h. alle 50ns um eins weiterzählen läßt, ist das maßlos übertrieben ;-)
Sollen 40 Impulse (max.) aufgelöst werden, so ist eine Zeitbasis nötig, die wesentlich kürzere Abstände unterscheiden kann. Kommt jetzt noch hinzu, das über Stunden hinweg gemessen werden soll, eine Tankfüllung lang oder so, so kann ein nach oben "offener" Bereich nicht schaden. Bei einer "richtigen" Messung kann es sogar nötig werden einen Kalender zu implementieren. Mein Beispiel war allerdings mehr an einen Anfänger gerichtet.
Amateur schrieb: > Sollen 40 Impulse (max.) aufgelöst werden, so ist eine Zeitbasis > nötig, die wesentlich kürzere Abstände unterscheiden kann. Es ist die Rede von bis zu 40 Impulsen PRO SEKUNDE > Kommt jetzt noch hinzu, das über Stunden hinweg gemessen werden soll, > eine Tankfüllung lang oder so, so kann ein nach oben "offener" Bereich > nicht schaden. > Bei einer "richtigen" Messung kann es sogar nötig werden einen Kalender > zu implementieren. Es geht hier nicht darum festzustellen wie viel Milliliter Sprit im Laufe eines Jahres durch die Spritleitung diffundieren!
:
Bearbeitet durch User
Genau, Impulse pro Sekunde. Es soll lediglich den momentanen Verbrauch anzeigen, die Daten sollen also nicht gespeichert werden sondern für den Aktualisierungszeitraum immer wieder neu berechnet werden. Ich plane auch noch Erweiterungen, wie z.B. die Anzeige des durchschnittlichen Verbrauches oder den Restinhalt des Tankes (ggf. auch Restkilometer), aber erst einmal möchte ich erfolgreich diese Aufgabe lösen.
Der Unterschied von 40 zu 39 Impulsen beträgt 0,00064s Für eine sinnvolle Unterscheidung dieser Abstände ist nach meiner unmaßgeblichen Meinung eine Zeitbasis von wenigstens 0,0001s vonnöten. Nach Adam Ries und Eva Zwerg etwa 10.000 KHz. Ein 32-Bit Zähler bekommt also schon nach etwas über 4 Tagen Ohrensausen. Soll er Unterschied von 40 zu 39,9 Impulsen (>1 %) herausgearbeitet werden, so währen bereits 100.000 KHz nicht schlecht. Ein 32-Bit Zähler macht jetzt schon nach weniger als einem halben Tag schlapp.
Warum nach mehreren Tagen? So lang soll er nicht hochzählen, mag sein, dass ich da noch nicht den Durchblick habe, aber er muss doch nicht konsequent hochzählen, es sollte doch völlig ausreichend sein, wenn er für den Zeitraum der Aktualisierung zählt. Zwei Sensordaten werden erfasst, werden miteinander verrechnet und ausgegeben, nach x-Sekunden wird die aktuelle Messung berechnet und ausgegeben und so weiter und sofort, von Tagen spricht niemand. Eine so genaue Messung ist auch vorerst nicht von Nöten. Eine Unterscheidung zwischen ganzen Zahlen reicht mir da in der ersten Version.
:
Bearbeitet durch User
Mein Ansatz s.o. ging erstens davon aus, dass die Zeit aus der Differenz
eines Zählers gewonnen wird und zweitens diese Zeit an verschiedenen
Stellen (Drehzahlimpulse UND Durchflussimpulse) zur Verfügung steht.
Eine Messung KÖNNTE jetzt folgendermaßen aussehen:
Wohl gemerkt im Hintergrund wird eine Variable zyklisch inkrementiert.
EndlosBegin
? Neue Flanke Geschwindigkeit
Ja Hole Hintergrundzähler
Akt. Abstand = Vorheriger Zählerstand - akt. Z.
Merke akt. Zählerstand als Vorherigen Z. (Achtung != Verbrauch)
ZEIT STEHT FEST
...
? Neue Flanke Verbrauch
Ja Hole Hintergrundzähler
Akt. Abstand = Vorheriger Zählerstand - akt. Z.
Merke akt. Zählerstand als Vorherigen Z. (Achtung !=
Geschwindigkeit)
ZEIT STEHT FEST
...
? Neue Werte
Ja Hole Hintergrundzähler
Akt. Abstand = Vorheriger Zählerstand - akt. Z.
? Zeit zum aktualisieren (z.B. alle 0,5 Sek)
Ja Merke akt. Zählerstand (!= Verbr. und Geschw.)
Anzeige neuer Werte
...
>>Was sonst noch anliegt<<
EndlosEnde
Diese Sequenz kann so lange abgearbeitet werden, wie der
Hintergrundzähler nicht ausflippt.
Diese Sequenz benötigt nur einen Timer.
Amateur schrieb: > Diese Sequenz kann so lange abgearbeitet werden, wie der > Hintergrundzähler nicht ausflippt. Unter der Voraussetzung, daß sichergestellt ist, daß zwei aufeinanderfolgende Impulse niemals weiter auseinander liegen als der volle Zählumfang des Zählers, geht das sogar unendlich lange gut. Wenn man es richtig macht, nämlich mit "unsigned" Variablen.
hier mal ein Beispiel Impulszähler in C, müsste in Bascom aber genauso laufen:
1 | void PCINT3_Init(void){ // Initialisierung PCINT_Port D |
2 | PCICR |= (1 << PCIE3);//PCIntControlRegister |
3 | sei(); |
4 | }
|
5 | |
6 | void PCINT30_start(void){//d6 |
7 | isr_imp=0; |
8 | PCMSK3 |= (1 << PCINT30); |
9 | }
|
10 | |
11 | //Q1
|
12 | void PCINT29_stop(void){//d5 ok |
13 | //current can not exceed 10mA, 330 pulses/liter,
|
14 | //Messung Zeit für Durchfluss 1000l/h => 92 imps/sec
|
15 | PCMSK3 &= ~(1 << PCINT29); |
16 | q2_l_hou=(uint32_t)isr_imp*500/92; |
17 | //tsx01("l/h",isr_imp);
|
18 | tsx01("l/h",q2_l_hou); |
19 | //lgw(17,1,"Imp29/Q2 : ");li(isr_imp);lw(" ");
|
20 | //li(q1_l_hou);lw("l/h");
|
21 | }
|
22 | |
23 | |
24 | main.. |
25 | if(sec==38){PCINT29_start();}//d5-q2 |
26 | if(sec==39){PCINT29_stop();} |
Nebenbei mal die Frage... Da ich noch vor hatte eine einfache Uhr miteinzubinden, da das doch noch recht simpel mit einer RTC zu lösen ist, frage ich mich ob es Sinn macht, die RTC für die Zählung mitzubenutzen.
Schon mal verstanden wie ne mechanische Uhr seit Jahrhunderten funktionier? Wozu da wohl Zahnräder drin sind?
Interessant zu wissen wäre auch, welcher Prozessor verwendet werden soll. Ebenso, wie wird die Raddrehung erfasst. (wie viele Impulse/n) Vorschlag: 1 Timer dient als Zeitnormal (1 sek, 2 sek,...what ever) Interrupt INT0 (zB Benzin) erhöht die Variable Benzin Interrupt INT1 (zB Rad) erhöht die Variable Rad nach Ablauf der Zeit (Timer) können die Variablen Benzin und Rad ausgelesen und bearbeitet werden. Anschließend werden die Variablen auf Null gesetzt, und alles von vorn.
Prozessor steht offen, ich experimentiere hier mit einem Atmega8, angesichts der Funktionen die ich nach und nach dazupacken will wäre vermutlich ein größerer noch sinnvoll (wie z.B. Öl- und Wassertemperatur, Tankinhalt erfassen etc) Da ich in der Endschaltung das ganze als SMD Bauweise realisieren möchte, habe ich eigentlich sehr viel Spielraum. Das Erfassen der Geschwindigkeit ist noch nicht ganz durchdacht, da ich lediglich ein mechanisches Tacho habe und sonst nirgens ein Signal dafür zur Verfügung steht muss ich mir da was bauen. Was genau weiß ich noch nicht... Die derzeitige Idee wäre ein Reflexsensor an dem Magneten des Tachos zu montieren und dort Striche aufzubringen. Ich kann also noch nicht genau sagen, wie viele Impulse/n es sein werden. Deine Idee gefällt mir sehr gut, sie wirkt übersichtlich und für mich als Anfänger erstmal gut umsetzbar...
Dann wird es wohl in Richtung Atmega16 oder Atmega32 gehen. Die haben 3 INTx und viele ADC's . Damit kannst du dich dann richtig austoben. Ich habe mit diesen Prozessoren in SMD leider keine Erfahrung. Aber noch zwingt dich ja keiner einen bestimmten zu nehmen. Eine Frage noch, du willst die gemessenen Werte doch bestimmt anzeigen? womit und wie ?
Aber ich dachte mir schon, dass der kleine Atmega8 nicht reichen wird. Solange ich bei BASCOM bleiben werde, muss ich ja auch ohnehin den deutlich höheren Platzbedarf des Flashs mit einbeziehen. Ich habe hier für die ersten Tests ein einfaches 16x2 HD44780 kompatibles LCD. Später würde ich das ganze dann gern mit einem OLED Display mit SSD1306 umsetzen, da es von der Größe und vom Preis her ideal ist. Ob ich dann allerdings noch mit BASCOM experimentiere... Das weiß ich nicht. Hier wäre C# ja nun wieder deutlich geeigneter, da es für das SSD1306 wohl schon eine Menge libs für C# gibt, das bleibt hier also vorerst außen vor...
:
Bearbeitet durch User
Oh Gott, welch ein Unsinn hier verzapft wird. Nimm doch besser einen aktuellen Intel Westmehre, die Power wird schon reichen.... unglaublich, echt ..........
Statt nur rumzumeckern und dumm zu schwatzen könnte man auch konstruktive Kritik äußern, aber warum die wohl ausbleibt (könnte ja helfen)... So hilft man niemandem weiter, außer der eigenen Inkompetenz.
:
Bearbeitet durch User
Ok, ich bin dumm, Du bist schlau.. Na dann liefere mal ab. Ihr habt einfach den Fokus verloren. Euer Problem ist trivial, ebenso die Lösung. Tschüss
Der Unterschied zwischen dumm sein und dem abgeben von dummen Kommentaren ist ziemlich groß... Man kann sich selbst und anderen natürlich auch das Leben erschweren, das macht eine freundliche und soziale Welt aus. Aber das soll hier nicht Thema sein..
Fang doch erst mal damit an eine LED blinken zu lassen. Auch wenn mir der Ton nicht wirklich gefällt: Die Aufgabe IST trivial. Wenn die Anzahl der Pins reicht, dann ist der Mega8 mehr als ausreichend. Auch in BASCOM. Wie gesagt, mit dem Ton bin ich nicht einverstanden. Aber so unrecht hat er nicht. Die einfachste Funktionalität nicht hinkriegen aber von einem graphischen Display träumen. Kopfschüttel.
:
Bearbeitet durch User
Noch mal zum Thema Geschwindigkeit. Wenn du sowieso an einem Magneten (im/am Tacho) hantieren willst, wären Hallsensoren auch eine Möglich- keit, die Drehzahl zu erfassen. Je nach Anzahl der Polpaare des Magneten mehrere Hallsensoren gleichmäßig verteilen, das es mehrere Impulse pro Umdrehung ergibt. Ist ja nur 'ne Idee.
Detlef Kahrmann schrieb: > Je nach Anzahl der Polpaare des > Magneten mehrere Hallsensoren gleichmäßig verteilen, das es mehrere > Impulse pro Umdrehung ergibt. Und welchen Vorteil soll man daraus für die Verbrauchsmessung ziehen? Messung der Änderung des Verbrauchs innerhalb einer Radumdrehung? Zumindest auf einer Anzeige wird dem keiner folgen können.
@ Mike In welchem Zusammenhang Durchflußmenge und Hinterrraddrehzahl stehen, lasse ich mal aussen vor. Steven T. schrieb: Das Erfassen der Geschwindigkeit ist noch nicht ganz durchdacht, da ich lediglich ein mechanisches Tacho habe und sonst nirgens ein Signal dafür zur Verfügung steht muss ich mir da was bauen. Was genau weiß ich noch nicht... Ich wollte nur eine Möglichkeit (von warscheinlich vielen) aufzeigen. Was, und warum gemessen werden soll, kann nur Steven erklären.
Detlef Kahrmann schrieb: > @ Mike > In welchem Zusammenhang Durchflußmenge und Hinterrraddrehzahl stehen, > lasse ich mal aussen vor. Dann kannst du vielleich näher erläutern, welche nennenswerten Vorteile es für diese Anwendung bietet, wenn man mehr als einmal pro Radumdrehung eine Information über die gefahrenen Strecke erhält.
@ Mike Mein Vorschlag bezog sich nur auf die Möglichkeit, die Drehzahl der Tachowelle magnetisch zu erfassen. Wie das Übersetzungsverhältnis zwischen Hinterrad und Tachowelle ist, weiss ich nicht. Deshalb der Hinweis auf die Möglichkeit, eine Umdrehung der Tachowelle aufzusplitten. Muss aber nicht so sein. Dazu sollte Steven mehr sagen können.
Einiges passiert... Nun gut. Zum Thema, dass ich erst einmal eine LED blinken können lassen soll, finde ich etwas weit hergeholt. Das sind alles Dinge, die so einfach sind, dass es das erste ist, was an probiert und direkt klappt. Auch die Verbrauchsanzeige habe ich so erst einmal hinbekommen, das ganze lief aber mit einem Festwert ( die Impulse/s des Durchflussmessers hatte ich als festen Wert gespeichert ) und mittels eines Funktionsgenerators (eigentlich nur ein NE555 als astabile Kippstufe und variablen Widerständen) das Geschwindigkeitssignal generiert. Damit habe ich dann versucht möglichst realistische Impulsfrequenzen zu erzeugen und dadurch den Verbrauch auf dem Display anzeigen zu lassen. Das ganze klappte wunderbar und war rechnerisch gesehen auch recht passend. Im Tutorial war für das Zählen nur T0 erklärt, mit dem Kommentar, dass sich andere Eingänge bei schnellen Zählungen nicht eignen, mehr wurde leider nicht erklärt, darum stellte ich diese Frage. Den Kommentar mit dem graphischem Display finde ich auch etwas lächerlich, da ich nicht gesagt habe, dies so direkt umsetzen zu wollen, es war die rede von "irgendwann, wenn ich es kann", also wo liegt das Problem? Nun zurück zum Thema: Radumdrehung für den Vebrauch -> ich möchte den Verbrauch natürlich als liter auf 100km angezeigt bekommen, damit brauche ich also logischerweise die Raddrehzahl um zu erfassen, welche Entfernung ich zurücklege und wie viel ich in dieser Zeit verbraucht habe. Die Idee mit den Hallsensoren finde ich recht gut, wobei ich denke, dass einer dort reichen würde. Hier sollte einer allein auch kein Problem sein, da sich der Magnet recht schnell drehen muss, auch bei kleinen Geschwindigkeiten. Der Vorteil liegt wohl auch klar darin, dass ich hier keine Striche o.Ä. auf dem Magneten aufbringen muss. Korrigiert mich, wenn ich falsch liege, aber nur einmal pro Radumdrehung einen Impuls zu bekommen stelle ich mir zu träge in unteren Geschwindigkeiten vor, mein Rad hat einen Abrollumfang von 1,8m.
Hi, Du wirst das sowieso über mehrere Sekunden mitteln müssen und in PKW wird unter 40km/h oder so auch nichts angezeigt weil es keinen Sinn macht. Die Gesamtmenge an Sprit kannst Du ja trotzdem weiter aufsummieren. Lass einfach einen Timer klappern und zähle in dessen Int eine weitere Variable hoch. Dann pollst Du einfach die Impulse und mittelst das gleitend über Sekunden. Wenn da nicht jeder Impuls auf die µS genau ist, ist das vollkommen egal denn es interessieren eigentlich nur die Impulse pro Sekunde. Das ist wirklich ziemlich banal und in Bascom überhaupt kein Problem. Wenn Du das in SMD machen willst, sind die Mega allerdings nicht sehr bastlerfreundlich, da kommt nicht jeder mit 0,8mm Pitch klar. Ein Attiny861 im SO-20 sollte aber locker reichen. Mit weniger SRam macht mit Bascom keinen Spaß (Stack und Frame und so). Gruß, Norbert
Das mit der Geschwindigkeit stimmt so nicht, dass die Schwelle bei 40km/h liegen soll habe ich so nicht erlebt, i.d.r. wird schon was angezeigt, wenn man mit 7km/h im Standgas fährt, nur beim stehen lässt sich halt kein Verbrauch ermitteln. Aber das ist hier ja nicht relevant. Es klingt wirklich alles einfacher, als ich es mir vorgestellt habe. Ich denke ich werde mich die Tage damit dann mal beschäftigen und schauen, dass ich dort etwas hinbekomme. Auch die Idee mit dem Hallsensor bringt mich bedeutend weiter, ich denke damit ist das Problem eigentlich hiermit erledigt. Ich wollte deshalb einen größeren nehmen, da ich das ganze offen halten will für Erweiterungen, da denke ich macht es sich gut, direkt einen etwas größeren zu nehmen. Mit dem Löten von SMD Bauteilen habe ich überhaupt kein Problem, sonst hätte ich auch den falschen Beruf ergriffen :-D Danke dir für die konstruktive und durchinformierte Hilfe. Und auch allen anderen beteiligten, die nicht gerade gegen das Thema gearbeitet haben. Beste Grüße und ein schönen restlichen Pfingstmontag
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.