www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Unterprogramme gleichzeitig?


Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christoph Wagner (christoph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst auch 2 Controller nehmen, an beide die gleiche Taktquelle
anschliessen, sie noch syncronisieren und in Assembler parallel
programmieren.
Otto

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRCO kann solchen code glaube ich erstellen

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wozu braucht man bei "ATMEL-Assembler" (siehe ersten Beitrag)
eigentlich "AVRCO"??

...

Autor: Bolle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> AVRCO kann solchen code glaube ich erstellen

Solchen Code kann jeder erstellen, denn das ist nicht schwieriger als
bei anderem Code.

Autor: Willie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Millenniumpilot (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Willie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Gunter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Willie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gunter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
überfliege (wenigstens) auch mal das Tutorial
(AVRco-Tutor.pdf im DOCs Directory).
Eine weitere gute Quelle ist die Suchfunktion im E-Lab Forum!

Autor: Willie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ansonsten bei Fragen fragen

Autor: Christoph Wagner (christoph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Bob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
00000000
00000001
00000010
00000011

mmhh hastrecht... war wohl ned richtig überlegt.
ja mit bit0&bit1 klappt es...

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ja für blinkende Leds ist das wirklich overkill. Wollte nur die
Möglichkeit aufzeigen.

Autor: Bolle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Thomas O. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bolle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: peter dannegger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bolle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bolle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

...

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

...

Autor: Bolle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bolle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
100% Ack...
Ich bin auch nicht verärgert, ich mach' mich auch nicht drüber
lustig... (wirklich nicht...)

Frohes Schaffen...

...

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich bin niemanden böse, werde mir deine Idee noch ein paar mal
durchlesen vielleicht verstehe ichs irgendwann.

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah ja, na okay - ich denke, Du wirst das schon machen. Probieren geht
über studieren.

Autor: Thomas O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.