Hallo Ich habe mal eine Frage, und zwar habe ich verschiedene Unterprogramme die die Ausgänge eines AT90S2313 (arbeite mit ATMEL-Assembler), verschieden Blinken lassen, nun will ich diese Blink"sequenzen" gleichzeitig ablaufen lassen, kann ich Unteprogramme auch gleichzeitig ablaufen lassen oder muss ich diese beiden Programme dann zusammen schreiben? Danke schonmal Gruß Patrick
Gleichzeitig laufen lassen geht nur bei sogenannten Multitasksystemen. Aber auch da laufen sie nur scheinbar gleichzeitig. Denn ein Prozessor kann zur gleichen Zeit auch nur einen Befehl ausführen.
Du kannst mit einem Timer eine "virtuelle Multitaskingumgebung" erstellen, die zwischen Tasks hin-und-herschaltet, aber ich bezweifle, dass dafür ein AT90S2313 ausreicht. Das wäre dann auch etwas aufwendiger. Des weiteren bezweifle ich, dass das Sinn macht. Wenn man die Möglichkeit hat, das ganze einfach zu erledigen, dann sollte man sie auch nutzen. Du kannst natürlich (sofern es dir nur ums Blinken geht) jede Routine in eine ISR eines Timers (Timer0/1) hängen und die dann entsprechend deiner Blinkgeschwindigkeiten konfigurieren. Damit könntest du dann zwei Arten von Blinken erzeugen und gleichzeitig eine Hauptschleife laufen lassen.
Gleichzeitig ist ohnehin nicht möglich, da der Controller nur eine Sache zu einer Zeit machen kann und das hübsch hintereinander. Kannst Du Dein Problem konkretisieren? Vielleicht kann Dir auch ein Interrupt helfen, der ein anderes Unterprogramm sequenziell unterbricht und abgearbeitet wird... Die Frage ist, sieht der Anwender das, wenn der Prozi schnell mal hier hin hüpft, die und die LED anmacht, dann wieder dort hin hüpft und andere LEDs ausmacht und wieder andere anmacht? Da die Controller sehr schnell sind, muß man doch nur die Ausgabe der Blinkerei dem menschlichen Auge anpassen; was der Contoller die anderen 99,8% der Rechenzeit macht, ist doch relativ. Poste mal Dein Programm.
Ich sage einfach mal was ih vor habe, ich möchte über den uart und den PC die Ausgänge über den PC schalten (ein/aus). Das funktioniert auch, also Uart klappt (ist ja auch nicht so schwer). Da lasse ich dann einfach Interprogramme aufrufen, die dann die Ausgänge einfach schalten. So nun sollen die Ausgänge aber auch einfach blinken, wenn sie geschaltet werden, und zwar jeder Ausgang mit unterschiedlicher "Sequenz". Momentan habe ich das alles über Bytezähler gemacht (Code habe ich nicht da, der liegt zuhause)... Nur wenn ich nach jedem schalten eines Ausganges den Zähler mit unterschiedlichen Zeiten aufrufe bekomme ich demnach auch einen Code, der "kilometerweit" ist. Wenn ich dazu auch noch für jede einzelne Sequenz ein Unterprogramm mache, dann sprengt das irgendwann den Ramen des AT90S2313. Ich weiß das ich das auch über Timer und so machen könnte, lieder sind um Beispiele zu finden die Threads zu genau auf ein Thema gelegt... Ich hoffe ihr könnt mit helfen... Gruß Patrick
Du könntest die Blinksequenzen in eine Tabelle im Flash legen, also byteweise Ziffern eintragen, die mittels Pointer abgefragt werden, je größer die Ziffer, desto länger bleibt die LED an. Mit diesen Ziffern fütterst Du 8 Softwaretimer, die quasi jeweils ein PWM bilden, welches auf den jeweiligen Ausgang geschaltet wird. Für jede benötigte Blinksequenz legst Du eine Tabelle an (aber nicht zu viele, sonst ist der Flash voll, vielleicht so 16). Jetzt überträgst du per UART z.B. 1 Byte, wobei das obere Nibble des Bytes die Nummer des zu schaltenden Ausgangs enthält und das untere Nibble die Nummer der Tabelle im Flash mit der Blinksequenz, die der eben gewählte Ausgang erzeugen soll. Klingt vielleicht ein wenig kompliziert, aber so kann jeder Ausgang ´was völlig anderes machen, und Du brauchst nur ein (gut abgestimmtes) Programm mit ein paar Sub-Routinen. Die Ausgangsausgabe kann dann ein Hardware-Timer übernehmen, damit alles immer schön synchron wird. Über diesen kann man dann auch die Ausgabefrequenz regeln.
Kannst auch 2 Controller nehmen, an beide die gleiche Taktquelle anschliessen, sie noch syncronisieren und in Assembler parallel programmieren. Otto
"kann ich Unteprogramme auch gleichzeitig ablaufen lassen" Klar, macht doch jeder so. Du must bloß die Programme so schreiben, daß sie nicht hängenbleiben. Du hast z.B. einen Timerinterrupt, der jede 1ms einen Wert hochzählt. Und jedes Unterprogramm liest nun diesen Zeitstempel ob nun genügend Zeit vergangen ist und macht dann eine Aktion. Ist die Zeit noch nicht rum, kehrt es zum Main zurück und das ruft nun das nächste auf usw. immer in einer Endlosschleife. Man bleibt also nur solange in dem Unterprogramm, wie es braucht, um etwas zu machen (z.B. eine LED anschalten). Dadurch scheinen sie alle gleichzeitig abzulaufen. Die höhere Schule ist natürlich ein Scheduler, dem man einfach ein Unterprogramm übergibt und eine Zeit, zu der er es ausführen soll. Allerdings ist sowas schon recht komplex, so daß man es nur in einer Hochsprache (C) machen sollte (siehe Codesammlung). Peter
Wozu braucht man bei "ATMEL-Assembler" (siehe ersten Beitrag) eigentlich "AVRCO"?? ...
> AVRCO kann solchen code glaube ich erstellen
Solchen Code kann jeder erstellen, denn das ist nicht schwieriger als
bei anderem Code.
Stimmt fast, ein Multitasking System selber zu entwicklen kostet Zeit, aber unter AVRco (E-LAB) ist es dabei und total simple zu programieren und man muss nicht das Rad wieder neu erfinden. Allerdings ist AVRco Pascal. In AVRco kann man natürlich auch Teile in Assembler programmieren. Ich persönlich programmiere alle meine AVRs mit AVRco. Es gibt da eine freie Version, die kann max. 4Kb und eine spezielle Version für den Mega8 die ist recht günstig. Die Standard Version ist aber recht teuer für einen Privatmann.
Hallo Willi, aus diesem Grund wollte ich eigendlich auch mit AVRco anfangen zu programmieren. Ausserdem habe früher viel und ausschlieslich mit Turbo-Pascal programmiert. Aber da ich bestimmt irgendwann mal vom Mega8 auf größere AVRs umsteige, war mir AVRco dann für den Hausgebrauch doch zu teuer. Schade eigendlich. Gruß Dirk
Ja, ging mir ähnlich. Ich war sogar soweit mir einen eigenen Compiler zu schreiben (wäre dann jedoch JAVA geworden). Jetzt bin ich doch noch stolzer Besitzer eine AVRco Std Version geworden. Und ich muss sagen, ich bin voll begeistert. Es macht richtig Spass damit zu arbeiten.
kann der auch schon multitasking? welche prozessoren werden da unterstützt? (die neuen tiny45 85 auch?) was hast du bezahlt? welche mudule waren im preis inenthalten (LCD 7segment etc)
Hi, ALLE Versionen des AVRco sind MultiTasking Compiler. Tiny 45 und 85 werden seit 16.05.2005 unterstützt. Ansonsten an die 50 Controller. Für die "Module" = Treiber gibt es alleine über 100 Demos. Also zuviel alles hier aufzuzählen. Unterstützte Prozessoren erlennst Du an den .dsc Files. Für die Demos gibt es ein eigenes Unterverzeichnis. Installier Dir einfach mal die Demo - ist kein Problem. Ggf. wirfst Du den mitgelieferten UnInstaller an, der das Teil auch sauber wieder entfernt. hth Gunter
okay danke. also kann die demo version das auch? und auch diesen ganzen lcds und so? da werd ich mir mal gleich das demo ziehen müssen, grins
Die Demo ist zwar auf 4KB beschränkt, aber zum Testen reicht das alle mal. Ich glaub nur mit dem Filesystem und den TCP/IP Treibern wird wohl nix in der Demo werden, da die alleine schon >4KB sind.
ja gut, darauf kommt es mir nicht so an. muss mich erstmal reinfinden in die neue umgebung, aber ich denke schon vom ersten eindruck, dass das n geiles teil ist. BTW: eigentlich passt das hier gar nicht in den thread.
überfliege (wenigstens) auch mal das Tutorial (AVRco-Tutor.pdf im DOCs Directory). Eine weitere gute Quelle ist die Suchfunktion im E-Lab Forum!
Macht's euch doch nicht so schwer ! Das Ding ist in einem AT90S2313 ohne Probleme in ein paar Zeilen Assembler realisiert. Einfach etwas drüber brüten, dann wird das schon. Da muss man doch nicht gleich Multitasking auffahren. Eine wohlstrukturierte Hauptschleife oder per Timer, der dort die PWMs regelt; Alles kein Thema.
und wenns wirklich echtes Multitasking werden soll dann muss man auf mehrere AVRs ausweichen. So habe ich das bei meinem nächsten Projekt vor, weil ich 4 evtl. 8 unabhängige 16 Bit Timer brauche. Der Haupt AVR übermittelt da die Daten an die einzelnen µC's und diese können dann das ganze wirklich unabhängig und gleichzeitig ausführen ohne das man sich dann gedanken machen muss wegen den Interrupt Prioritäten usw.
Ja Thomas, ist ja gut gemeint, aber doch nicht, um ein paar "lumpige" LEDs blinzeln zu lassen... Da langweilt sich ja sogar ein einziger 2313.
Hallo, wenn man einen timer mit dem doppelten der höchsten blinkfrequenz konfiguriert, kann man hilfsvarieblen hochzählen lassen und dann die leds bei bestimmten werten setzen/zurücksetzen, (kenne kein asm aber sinngemäß): if hochzählbyte.bit0=1 then toggle led1 if hochzählbyte.bit1=1 then toggle led2 damit blinkt die zweite led Glaub ich halb so schnell wie die erste
> if hochzählbyte.bit0=1 then toggle led1 > if hochzählbyte.bit1=1 then toggle led2 > damit blinkt die zweite led Glaub ich halb so schnell wie die erste Glaube ich nicht, denn in vier Takten sind sowohl Bit0 als auch Bit1 zweimal auf 1. Wenn wir aber in diese Sprache noch ein endif einfügen: if hochzählbyte.bit0=1 then toggle led1 if hochzählbyte.bit1=1 then toggle led2 endif endif Dann paßt es mit der doppelten Blinkfrequenz
00000000 00000001 00000010 00000011 mmhh hastrecht... war wohl ned richtig überlegt. ja mit bit0&bit1 klappt es...
Hallo, ja für blinkende Leds ist das wirklich overkill. Wollte nur die Möglichkeit aufzeigen.
>und wenns wirklich echtes Multitasking werden soll dann muss man auf >mehrere AVRs ausweichen. Das wäre dann allerdings auch kein Multitasking, sondern schon "Multicontrollering", weil man mit Multitasking ja eigentlich das Ausführen mehrerer Tasks auf einem Prozessor (oder Controller) bezeichnet. >So habe ich das bei meinem nächsten Projekt >vor, weil ich 4 evtl. 8 unabhängige 16 Bit Timer brauche. Hoppla, für welche Anwendung braucht man denn soviele Timer? >Der Haupt AVR >übermittelt da die Daten an die einzelnen µC's und diese können dann >das ganze wirklich unabhängig und gleichzeitig ausführen ohne das man >sich dann gedanken machen muss wegen den Interrupt Prioritäten usw. Stimmt, aber dafür mußt Du Dir dann Gedanken über die Inter-Controller-Kommunikation machen.
Angehängte Dateien:
-
Impulsverlauf.JPG
16 KB
Hallo, für eine vollsequentielles Einspritzung/Zündsystem(Einzelzündspulen) wäre es wesentlich einfacher wenn ich einfach die Daten z.b. Einspritzbeginn+Einspritzdauer bzw. Schließwinkel+ZZP an einen µC schicke und dieser dann nur diese eine Aufgabe hat. Anstatt mich drum zu kümmern einen Timer für mehrere Ereignisse zu nutzen. Und da nehme ich lieber mehr Hardware in Kauf und muss mich weniger mit der mehrfachen Nutzung eines Timers rumquälen wo es dann doch bestimmt etwas schwieriger wird und man evtl. mit der Überschneidungen von 2 Ereignissen in Konflikt gerät. Multitasking heißt für mich mehrer Task gleichzeitig auszuführen ob man das jetzt mit einem µC macht der mehrere Recheneinheiten hat oder durch mehrere µC ist zweitrangig.
Hallo, danke für Deine Antwort. >für eine vollsequentielles Einspritzung/Zündsystem(Einzelzündspulen) >wäre es wesentlich einfacher wenn ich einfach die Daten z.b. >Einspritzbeginn+Einspritzdauer bzw. Schließwinkel+ZZP an einen µC >schicke und dieser dann nur diese eine Aufgabe hat. Das ist die große Frage, ob das einfacher ist. Selbstverstänlich ist es grundsätzlich relativ einfach, Daten von einem µC an einen anderen zu schicken. Jedoch kannst Du z. B. nicht ausschließen, daß es dabei zu Übertragungsfehlern kommt (Wahrscheinlichkeit klein, aber > 0). Diese mußt Du erkennen und korrekt handeln, damit die angesteuerte Hardware (Motor) keinen Schaden nimmt. Fürs Erkennen gibts Prüfsummen, aber wie stehts mit dem korrekten Handling? Angenommen, einer der Empfänger-µCs hat festgestellt, daß er invalide Daten bekommen hat. Was soll er dann tun? Sein Problem an den Hauptcontroller rückmelden? Klar, kein Problem, der sendet das Datenpaket einfach nochmal. Aber vielleicht doch ein Problem, denn die Prozedur kostet Zeit, und die ist in einem vollsequentiellen Einspritzung/Zündsystem knapp. Das ist nämlich stets die zentrale Frage: Wieviel Zeit steht zur Verfügung? Konkret in Deinem Fall: Wie lange dauert ein "schwarzer Balken" in Deinem Diagramm? Kannst Du mir das sagen? Wenn der nämlich so lange dauert, daß der µC währenddessen noch eine gewisse Zahl von Berechnungen durchführen kann, dann besteht für Deinen Multi-µC-Ansatz eigentlich keine Notwendigkeit. >Anstatt mich drum >zu kümmern einen Timer für mehrere Ereignisse zu nutzen. Und da >nehme ich lieber mehr Hardware in Kauf Mehr Hardware und mehr Software, weil Du den Aufwand für die Inter-µC-Kommunikation gewaltig unterschätzt (jeder, der damit noch nie zu tun gehabt hatte, tut das, und glaub mir jeder, der schon mal versucht hat, "es 'einfach' mit mehreren Controllern zu machen", wird danach bei jedem neuen Projekt lieber fünfmal überlegen, ob es nicht doch auch mit einem Controller geht.). >und muss mich weniger mit der >mehrfachen Nutzung eines Timers rumquälen wo es dann doch bestimmt >etwas schwieriger wird und man evtl. mit der Überschneidungen von 2 >Ereignissen in Konflikt gerät. Die Alternative, ein verteiltes System zu bauen, und es so zu programmieren, daß es hinterher auch funktioniert (Stichwort Debugging), hat sich bisher stets als noch viel qualvoller herausgestellt. >Multitasking heißt für mich... OK, über ne Definitionsfrage wollen wir uns nicht streiten.
Hallo, die Komunikation funktioniert da ich das gleiche System (Latch) für die Adressleitungen eines EEPROMs anwende. Aber wir verändern gerade das Thema des Beitrages. Schreib mir doch mal kurz ne Mail. Dann kann ich dir meine Vorstellung etwas näherbringen.
Anbei mal die Version mit Scheduler aufm ATTiny2313. Es werden 16 unabhängige Tasks gleichzeitig ausgeführt (je 8* LED an/aus). Der Scheduler wird in 1ms Schritten aufgerufen (max 65s Verzögerungszeit). Jede Task zum Anschalten einer LED stellt sich selbst wieder hinein und noch eine Task zum Abschalten der LED. Im Main.c sind die Tasks definiert und deren zeitliche Abfolge. Den Scheduler selber muß man nicht verstehen, er funktioniert ja. In der Codesammlung steht auch noch was dazu. Peter
Zum Thema Vernetzung von µCs, ich habs auch hinter mir, der Software-Aufwand wird total unterschätzt. Es lohnt sich nur, wenn wirklich ein µC nicht mehr ausreicht. D.h. in meinem Falle wurde es deshalb notwendig, weil mehrere gegeneinander floatende Einheiten kontrolliert werden mußten (auf bis zu 5000V liegend). Es wird auch der CAN-Bus verwendet, damit wenigstens schon einen Großteil des Protokolls die Hardware macht. Peter
Hallo, eine serielle Übertragung scheidet wegen der Geschwindigkeit aus. Ich lege die Daten an einen Port an gebe ein Signal an das Latch und die Sache ist gegessen, evtl. noch ein extra Signal wann sich der andere AVR die Daten vom Latch abholen soll. Das Protokoll ist also sehr einfach und erfordert keinen großen Programmieraufwand.
Hallo, zäumen wir das Pferd einfach von hinten auf. Die Aufgabe besteht aus drei Teilen: Frage 1: Wie kann man mit einem µC das durch Dein Diagramm spezifizierte Muster der vier Signale (vier Bits) softwaremäßig erzeugen, wenn man die Geschwindigkeit erstmal außer acht läßt (also: vier LEDs an einem Controller sollen langsam im Sekundentakt so vor sich hin blinken, wie es das Diagramm vorgibt)? Frage 2: Welcher Algorithmus erledigt diese Aufgabe besonders schnell? Frage 3: Welche Geschwindigkeit kann man mit diesem Algorithmus maximal erreichen, wenn er auf einem mit x MHz getakteten Controller läuft? Wenn die abschließende Antwort auf Frage 3 lautet "die Chose kann so schnell sein, wie's gefordert ist", dann weißt Du, daß ein Controller ausreicht. Hättest Du Antworten auf 1, 2, und 3?
zu 1. und 2. Ich müsste dem Timer Compare Match Register(Interrupt) nach dem ersten Ereigniss die Werte für das nächste Ereigniss übergeben so das dieser das ganze ausführt. meine max. Impulslänge wäre übrigens 7,5mSek und bei 8 Ereignissen wirds dann warscheinlich sehr knapp werden, deswegen wollte ich gleich auf weitere µC outsourcen, weil ich dann fur diesen einen Impuls die beiden Compare Register korrekt beschreiben kann und das nächste mal wieder aktualisieren.
Bemerkung zum Tempo: Wie schnell soll der Motor drehen? (3000 Umdrehungen/Minute entspricht 50 Hz...) Bei (unrealistischen) 15000 Umdrehungen/Minute wären das schlappe 250 Hz, also 4000 Takte bei 1MHz Prozessortakt. ...
133,333 Hz = 8000 U/Min die Geschwindigkeit des Prozessors wird nicht das Problem sein nur meine geringen Programmierkenntnisse und evtl. 8 Ereignisse die den Timer beanspruchen.
Hallo, >zu 1. und 2. Ich müsste dem Timer Compare Match Register(Interrupt) >nach dem ersten Ereigniss die Werte für das nächste Ereigniss >übergeben so das dieser das ganze ausführt. so was hab ich schon vermutet. Funktionieren würde das theoretisch, aber im Grunde ist es eine schlechte, weil viel zu umständliche Methode. Dies drückt sich auch in der Tatsache aus, daß Frage 3 hier schwer zu beantworten ist. Wenn Du Dir die Sache mal richtig überlegst, wirst Du darauf kommen, daß sich das Muster auf viel einfachere Art erzeugen läßt. Alles, was Du brauchst, ist a) ein Ereignis, das mit einer genügend hohen Frequenz fortlaufend periodisch ausgelöst wird, und b) eine Zählvariable, die von 0 bis zu irgendeinem Maximalwert zählt und dann wieder bei 0 anfängt. Diese Zählvariable scannt Dein Diagramm sozusagen auf der Zeitachse durch. Teil a) ist mit einem Timer erledigt, der im CTC-Mode (clear-on-compare-match) betrieben wird. Das a)-Ereignis ist einfach der On-Compare-Match-Interrupt. Teil b) ist mit "inc c" erledigt, wobei c die Zählvariable ist. Sie zählt 0, 1, 2... 254, 255, 0, 1, 2 ... und so weiter, solange der Controller läuft. Der Signalerzeugungsalgorithmus sieht so aus: --------------------------------------------- TimerCompareMatchInterrupt: IF (c=00) Bitmuster := b1001 IF (c=00+5) Bitmuster := b0001 IF (c=64) Bitmuster := b0011 IF (c=64+5) Bitmuster := b0010 IF (c=128) Bitmuster := b0110 IF (c=128+5) Bitmuster := b0100 IF (c=192) Bitmuster := b1100 IF (c=192+5) Bitmuster := b1000 Inc(c) ; springt bei "255 -> 256" automatisch auf Null out PORTX, Bitmuster ; Bitmuster auf gewünschten Port schicken reti ; Interrupthandler verlassen --------------------------------------------- Das ist alles! Funktionsweise klar? Die Geschwindigkeit, mit der das Muster ausgegeben wird, wird vom Compare-Wert des Timers bestimmt, und läßt sich somit sehr leicht einstellen und verändern, und zwar nicht nur zur Entwurfszeit, sondern auch während das Programm läuft! Damit wäre Frage 1 und 2 beantwortet. Jetzt zu Frage 3. Der µC muß genug Zeit haben, die Befehlssequenz im Interrupthandler abzuarbeiten (sonst würden Interrupts "verlorengehen"). Wie lange er dazu braucht, hängt ab von 1. der Anzahl der Maschinenzyklen dieser Sequenz und 2. der System-Taktfrequenz. Die Anzahl der Maschinenzyklen können wir abschätzen: so 100 dürften es sein. Ein mit 8 MHz getakteter µC benötigt für 100 Zyklen 100/(8E6 Hz) = 12.5 µs. Bis ein schwarzer Balken fertig produziert ist, wird die Routine 64 mal aufgerufen. Das dauert bei Maximalspeed 64 * 12.5 µs = 0.8 ms. >meine max. Impulslänge wäre übrigens 7,5mSek Et voila! Bei 8 MHz Systemtakt kannst Du Impulslängen bis herunter auf 0.8 ms erzeugen, aber 7.5 ms lange reichen Dir vollkommen aus. Abschließende Antwort auf Frage 3 also: Wenn Dein Motor auf Hochtouren ist, wird Dein Controller nur zu ca. 10 % ausgelastet sein. >und bei 8 Ereignissen wirds dann warscheinlich sehr knapp werden, Nein. Die Erweiterung auf 8 Ereignisse ist überhaupt kein Problem, weder code- noch geschwindigkeitsmäßig. Rechne bitte selbst nach, daß bei 16 MHz Takfrequenz selbst 100 Ereignisse (noch) kein Problem wären. >deswegen wollte ich gleich auf weitere µC outsourcen, Willst Du das jetzt immer noch?
danke für deine ausführliche Beschreibung aber hier kommt wieder was ins Spiel was ich erstmal garnicht beschrieben habe, es könnte nämlich sein das sich Punkt 2+3 mal überschneiden, weil die Länge des Impulses ja nicht immer gleich ist zudem kann auch der Beginn zeitlich vor/zurück-verschoben werden so das es dann nochmals Probleme geben könnte. Also ich befürchte wirklich das hier Interrupts verloren gehen könnten, wenn z.b. gerade eine Interruptroutine ausgeführt wird. Zusätzlich muss ich noch einige 16bit / 12bit Berechnungen durchführen um den korrekten Zeitpunkt zu ermitteln da ich eine sehr genaue Auflösung bewerkstelligen will und zuguter letzt wäre eine Auflösung von nur 64 viel zu gering hier müsste ich wirklich mind. 255 haben. Ich werde da mal mit einem Impuls anfangen und das richtig ausarbeiten, danach sehe ich mal weiter. Mit den Timer bin ich eh noch nicht soweit außer einer PWM-Ausgabe habe ich da noch nichts gemacht.
Verstehe ich das jetzt richtig? Die Impulsdauer ist konstant (xyz µs) und nicht von der Drehzahl abhängig? Oder beträgt die Impulsdauer einen bestimmten Prozentsatz einer (zweier) Umdrehung(en)? ...
nein, die Impulsdauer ist nicht konstant und der Impulsbeginn auch nicht dieser muss(bei meinem System) auch variabel sein. Deshalb wollte ich das ganze auf einzelne µC auslagern da diese dann nur diesen einen Impuls regeln müssen , klar ist das ne Verschwenung an Rechenpower aber für mich wäre das am einfachsten zu programmieren ohne viel debuggen zu müssen. Weil die Pgrogramme für die Pulsgeneration ziemlich einfach gestrickt wären. Oben habe ich auch einen Fehler geschrieben die Berechnungen würde alles der Haupt-µC machen und nur die Daten übertragen so das die anderen µC wissen wann sie was machen sollen. Diese würden dann nur auf einen OT-Interrupt warten, dann entsprechend einen von 4 90° Impulsen(also entweder den 1, 2, 3 o. 4ten 90 Impuls) abwarten und dann ihr Ereigniss ausführen. Ich nehme jetzt mal nen Tiny um eine gleichmäßige Impulsfolge auszugeben und dann werde ich mit nem Mega mal eine Messung mit dem 16bit Timer durchführen und versuchen ein Ereigniss richtig zu timen.
Du sprichst in Rätseln... Um über ein Programm nachzudenken, benötigt man zuerst die umzusetzenden Algorithmen. Um diese Algorithmen zu erstellen (oder finden), benötigt man Informationen über alle Größen, die berücksichtigt werden müssen. Diese nennst du aber nicht. Hilfreich wäre eine Zusammenfassung aller zu berücksichtigenden Größen, im einfachsten Fall wie bei einer Mathe-Aufgabe in der Schule, nämlich mit den Listen "Gegeben" und "Gesucht". Ansonsten wird das nur ein Eiertanz... ...
Hallo, >nein, die Impulsdauer ist nicht konstant und der Impulsbeginn auch >nicht >dieser muss(bei meinem System) auch variabel sein. Deshalb wollte ich >das ganze auf einzelne µC auslagern da diese dann nur diesen einen >Impuls regeln müssen mir gehts grad umgekehrt: ich sehe nicht den geringsten Grund, warum das nicht ein einzelner Controller mühelos und streßfrei erledigen sollte. Schließlich stellt es für einen Controller nicht das geringste Problem dar, vier Impulse zu managen. Auch nicht bei Deinen Geschwindigkeitsanforderungen (habs ja vorgerechnet). Ich frage mich allerdings, ob Du das Potential des von mir vorgestellten Ansatzes ("state machine") erkannt hast. , klar ist das ne Verschwenung an Rechenpower aber >für mich wäre das am einfachsten zu programmieren ohne viel debuggen zu >müssen. Weil die Pgrogramme für die Pulsgeneration ziemlich einfach >gestrickt wären. Wenn die auf ein-und-demselben Controller laufen, sind die immer noch so einfach.
Ich danke erstmal allen dir "mein" Thema :-) aufgegriffen haben um mir zu helfen. Ich werde das Forum mal durchsuchen und schauen was mir "in euren Leitsätzen" weiterhilft, da es teilweise wirklich etwas schwer ist, was geschrieben wurde, oder sagen wir es so, ich beherrsche noch längst nicht alles (bzw das meiste). Gruß Patrick
ich wollte eigentlich diesen Tread nicht für was ganz anderes nutzen, es ging ja ursprünglich um was ganz anderes. Aber ich liefere mal eine kurze Beschreibung. 8 analoge Eingangssignale Drosselklappenwinkel, Saugrohrdruck, Batteriespannung, Motortemp....(unwichtig) Einige digitale Signale die schon aufgearbeitet(Schmitt-Trigger...) an den µC kommen z.b. Impulse für Triggerung Zünd-OT und 90° Kurbelwinkel, Lamda(Sprungsonde) Aus diesen Daten wird sich das nötige z.b. für die Einspritzung(Impulsdauer+Einspritzbeginn), Zündung(ZZP und Schließwinkel) und weitere Sollwerte wie Ladedruck... aus den Kennfelder eines externen EEPROMs geholt(funktioniert schon). Diese Daten sollten dann an einzelne µC ausgegeben werden die nur diesen einen Zweck haben z.b. den Ladedruck mittels PWM zu regeln oder die Impulse für die Einspritzung und die Zündung zu liefern. Hier könnte ich Tiny nehmen die die erforderliche Hardware haben z.b. ADC zur Rückmeldung des Ladedrucks, oder welche mit 16 Bit Timer für die Genauigkeit der Einspritz/Zündimpulse. @Bolle: Ich verstehe deine Erklärung so das inc c in einer Zählschleife läuft und immer wenn was übereinstimmt wird der Interrupt für ein Ereigniss ausgelöst und bei der nächsten c Übereinstimmung wieder beendet. Ich muss aber noch ein ein paar Berechnungen durchführen und dann geht das mit der Zählschleife nicht mehr bzw. zählt sie dann noch langsamer oder ungleichmäßiger weil im Polling. Im Prinzip möchte ich einfach das der Timer den Wert einer Umdrehung misst, den Wert speichert sich auf Null setzt und wieder hoch bzw. rückwärts zählt. Von dem ermittelten Wert kann ich meine Ereignisse abziehen/hinzurechen und an die beiden OCM-Register übergeben die bei der If bedingung dann das ganze selbstständig ein / ausschalten. Vielleicht habe ich deine Eklärung aber auch falsch verstanden.
Hallo, >@Bolle: Ich verstehe deine Erklärung so das inc c in einer Zählschleife >läuft und immer wenn was übereinstimmt wird der Interrupt für ein >Ereigniss ausgelöst und bei der nächsten c Übereinstimmung wieder >beendet. Ich muss aber noch ein ein paar Berechnungen durchführen und >dann geht das mit der Zählschleife nicht mehr bzw. zählt sie dann noch >langsamer oder ungleichmäßiger weil im Polling. >Vielleicht habe ich deine Eklärung aber auch falsch verstanden. Ich fürchte, Du hast sie völlig mißverstanden. Aber das macht nichts. Ich glaube, Du bist einfach noch nicht soweit. Am besten wird wohl wirklich sein, wenn Du einfach das machst, wovon Dich wahrscheinlich ohnehin niemand abbringen könnte: Versuche, Dein Projekt nach Deinen Ideen zu realisieren. Soviel vorweg (und ich weiß, was ich sage): Du wirst es mit Deinem jetzigen Kenntnisstand nicht hinkriegen! Aber ein Scheitern kann auch was Gutes sein, wenn man anschließend überlegt, was man falsch gemacht hat (die wirklichen Gründe suchen!), und wie man es anders besser machen könnte. Sammle Erfahrungen und lerne. Später wirst Du Dich vielleicht an meine Erklärungen erinnern, und dann wirst Du sie auch verstehen. PS: Falls es sich so angehört hat: Nein, ich bin keineswegs böse oder verärgert. Ich sagte nur, was ich denke. Also nicht persönlich nehmen, bitte.
100% Ack... Ich bin auch nicht verärgert, ich mach' mich auch nicht drüber lustig... (wirklich nicht...) Frohes Schaffen... ...
ich bin niemanden böse, werde mir deine Idee noch ein paar mal durchlesen vielleicht verstehe ichs irgendwann.
Noch eine Frage an Thomas: in einem Beitrag weiter oben schriebst Du, daß Du die digitalen Signale schon aufgearbeitet hast; mittels Schmitt-Trigger. Hältst Du das für klug? Die Impulse könnten, bedingt durch die Hysterese, in ihrem Auftreten verzögert bzw. insgesamt auch verlängert werden. Das heißt, die Flanken verschieben sich durch das Schwellwert-Verhalten zeitlich nach hinten. Die bessere Variante wäre ein definierter Pull-Up und Signale, die nach Masse schalten (oder Pull-Down und nach Vcc), eventuell über Spannungsteiler und Schutzdioden, falls nötig. Damit wären die Schaltschwellen immer an der selben Stelle. Je nach Programmierung kann man dann besonders schnell reagieren oder noch zusätzlich entprellen.
die sind noch nicht aufgearbeitet das war die Systembeschriebung. Ich hatte es als Schmitt Trigger bezeichnet es handelt sich aber um diesen Baustein http://www.national.com/ds/LM/LM1815.pdf dazu wird im Prinzip das Kurbelwellenrad etwas vorgestellt um diesen verspäteten Impuls wieder auszugleichen. Scheint beim Induktivgeber nötig zu sein weil bei einer langsamen Drehgeschwindigkeit die Spannung sehr schwach und schlecht zu detektieren ist. Das Hallgeber-System liefert hingegen fast ein Rechtecksignal. So eins steht mit am Zündverteiler aber auch zur Verfügung wobei ich der Kompatibilität halber auf das normale Bosch 60-2 Kurbelwellenrad http://people.freenet.de/Thomasoly/Impulsrad.JPG setzen will so das man es an solchen Autos verwenden kann. Weiterhin meinte ich noch dieses Ding http://www.national.com/ds/LM/LM9044.pdf was ja im Prinzip nur ein Verstärker ist um das schwache Signal der Lamdasonde etwas belastbarer zu machen und in der Spannung etwas erhöht, anscheinend wird es sonst nicht zu verarbeiten sein. Diese beiden Teile bekomme ich erst die Tage.
Ah ja, na okay - ich denke, Du wirst das schon machen. Probieren geht über studieren.
habe heute 2 Mails von National-Semi bekommen die werden mir keine Muster schicken, warscheinlich weil ich keine Firma bin und die Firmendaten evt. anhand der Adresse abgeglichen werden.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.