|
Anzeige
|
Thread-Programmierung?
Gast
#529140
Hallo, weiß zufällig jemand ob man Mikrocontroller der ATmega-Reihe mit Threads programmieren kann? also so das zwei sachen wirklich parallel zu einander laufen. und wenn ja, wie würde ein solche Programm aussehen? wäre cool wenn es da einen Beispiel Code oder so gäbe... MFG TT Was ist denn "wirklich Parallel"? Mit einem Kern dürfte das wohl unmöglich sein. Vielleicht reicht Dir aber auch sowas: http://www.sics.se/~adam/pt/
Gast
#529149
> wirklich parallel Nein. Wirklich parallel geht nur mit parallelen Prozessoren, oder mit SMT wie in Power5,Pentium4. Pseudo-Parallel, d.h. preemtive multitasking, das geht jedoch. Stichwort: RTOS. Beispielcode findet sich beim jeweiligen RTOS (z.B. http://barello.net/avrx/).
Gast
#529185
danke erst mal, das es natürlich nicht 100% parallel läuft ist klar, das kann logischer weise nur mit zwei prozessor gehen. die seiten oben sehen viel versprechend aus, aber gibts das zufällig auch in C? Assembler ist nicht wirklich meine stärker....
Gast
#529188
AvrX ist zwar in Assembler geschrieben, der API jedoch ist für GCC/WinAVR gedacht. Ada Dunkels Protothreads ebenso. Also wie kommst du auf Assembler? TT wrote: > danke erst mal, > > das es natürlich nicht 100% parallel läuft ist klar, das kann logischer > weise nur mit zwei prozessor gehen. > die seiten oben sehen viel versprechend aus, aber gibts das zufällig > auch in C? Assembler ist nicht wirklich meine stärker.... Zäumen wir das Pferd doch mal von der anderen Seite auf: Wie lautet deine Problemstellung, bei der du denkst dass du parallele Verarbeitung benötigst. Viele Problemstellungen kann man mit einem Pseudomultitasking durch den Einsatz einer Haupt-while Schleife und Job-Flags in den Griff kriegen. Grundprinzip: Alle Arbeitseinheiten sollten so kurz wie möglich und so schnell wie möglich ablaufen. Dafür sieht der µC ständig nach, ob es irgendwo etwas zu tun gibt, führt diesen kurzen Job aus und ist danach gleich wieder auf der Suche nach Arbeit.
Gast
#529692
Die Problemstellung ist folgende: der Inhalt eines Datenfeldes wirde über ein selbst entwickeltes LED-Display ausgegeben, zeitgleich soll ein zweites Datenfeld mit neuen Daten beladen werden. Ist die Beladung des zweiten Feldes fertig, sollen die Felder wechseln, sprich Feld zwei wird angezeigt, und Feld eins beladen. Problem ist dass die anzeige immer aktiv sein soll, sprich die Unterbrechungen müssen sehr klein sein so dass sie dem menschlichen Auge nicht auffallen und die Daten für das zubeladende Feld kommen nicht regelmässig, bzw der zeitliche Abstand zwischen den einzelnen Bytes variert. Des wegen dachte ich es ist vielleicht so was wie in Java möglich, dass man sagt ein Thread kümmert sich um die Anzeige, ein Anderer um die Beladung des Feldes. Und wie ich auf Assembler kommen? jetzt nach dem ich mir die Seiten noch mal angeschaut habe ( konnte gestern leider nur super kurz einen Blick drauf werfen) frag ich mich das auch... keine Ahnung was ich mir da gedacht hab oder was sich da bei mir eingeprägt hat, weil C und Assembler sehen sich ja eigentlich nicht mal ansatzweise von der Form her ähnlich....
Gast
#529708
@TT >der Inhalt eines Datenfeldes wirde über ein selbst entwickeltes >LED-Display ausgegeben, zeitgleich soll ein zweites Datenfeld mit neuen >Des wegen dachte ich es ist vielleicht so was wie in Java möglich, dass >man sagt ein Thread kümmert sich um die Anzeige, ein Anderer um die >Beladung des Feldes. ;-) Und dafür brauchst du Threads? Das macht jeder uC spielend mit einfacher Interruptsteuerung. Da muss nix "wirklich parallel" laufen, von zwei Prozessoren ganz zu schweigen. Nimm nen AVR+ WinAVR (C Compiler) und fertig. MfG Falk P.S. Warum glaubt jeder, der mal 3 Zeilen Java verbrochen hat, was von Programmierung zu verstehen? ;-) > sehr klein sein so dass sie dem menschlichen Auge > nicht auffallen ;-) Für einen Controller beginnt der Stress erst dann wenn man in einer oder zwei Mikrosekunden regelmäßig was erledigt haben muss. Was du schreibst, hat gut und gern 50 Millisekunden Zeit, da kann sich der Controller dazwischen getrost noch schlafen legen und seinen Betriebsstrom sparen. > Problem ist dass die anzeige immer aktiv sein soll, sprich die > Unterbrechungen müssen sehr klein sein so dass sie dem menschlichen > Auge nicht auffallen Wie ist die Anzeige aufgebaut? Ich geh mal davon aus, dass da ein Multiplex gemacht wird. Welche Timing Grenzen hast du? Wie aufändig ist ein Update der Anzeige? > und die Daten für das zubeladende Feld kommen nicht > regelmässig, bzw der zeitliche Abstand zwischen den einzelnen Bytes > variert. Auch hier: nenn mal ein paar Zahlen. Wie gross sind die zeitlichen Abstände: von - bis? Alles in allem klingt das nach einer 08/15 Anwendung, bei der der Anzeigenupdate in einem Interrupt gemacht wird, in der Hauptschleife kümmert sich der µC um die Datenannahme und in der restlichen Zeit löst er teuflisch schwierige quadratische Gleichungen, damit ihm nicht fad wird.
Gast
#529733
mmmh stimmt mit interrupts müsste des problemlos gehen... warum hab ich selbst daran noch nicht gedacht? @Falk, nur weil ich mal ein bissle was mit Java gemacht hab denke ich net das ich programmieren kann, aber ich denke mal man muss ja sein ganzes Wissen was man in einer Programmiersprache hat nicht über Board werfen, nur weil man jetzt noch was mit einer Anderen macht, den ein paar Sachen sind ja meisten/ manchmal/ vielleicht/ womöglich ähnlich. TT wrote: > Die Problemstellung ist folgende: > der Inhalt eines Datenfeldes wirde über ein selbst entwickeltes > LED-Display ausgegeben Ich vermute mal, das Display arbeitet im Multiplexbetrieb, d.h. die Zeilen und Spalten müssen mit einer bestimmten Wiederholfrequenz (>100Hz) ausgegeben werden. Sowas muß man im Timerinterrupt machen. Anders kriegst Du nämlich kein konstantes Zeitraster hin und die Pixel würden dann unterschiedlich hell leuchten. Und das Main muß dann nur noch die neuen Daten im SRAM ablegen und ein Flag setzen, damit der Timerinterrupt die Seite umschalten kann. Peter Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
