Weiß jemand, ob avrgcc Semaphore unterstützt? Und falls ja - wo finde ich die? Mfg Thomas
avrgcc ist ein Compiler und kein RTOS ... Habe neulich eine Reportage gesehen: Kurz vor der Ägyptischen Küste lassen sich einige Semaphoren finden :)
"avrgcc ist ein Compiler und kein RTOS ..." Wer hat den bitte gesagt, dass man mit einem AVR kein Multithreading machen kann??? Wie synchorinisert ihr dann eure Threads wenn nicht mit Semaphore? Und Kommentare wie "vielleicht im Mittelmehr" kann man sich sparen ... Dann muss ich mir also meine atomare check+bitset Operation also selbst zusammenbauen ...
Es hat keiner behauptet, dass das nicht geht. Nur ist der Compiler halt nicht dafür verantwortlich. Du kannst entweder ein fertiges RTOS nehmen oder programmierst dir eines selber. Ich bin bisher immer gut ohne den Overhead einer Threadverwaltung ausgekommen (auf dem MC), da ich die Programme einfach auf die jeweilige Aufgabenstellung hin optimieren. Maximale Laufzeiten kann man aus den Listings entnehmen (oder vielmehr berechnen). Wenn du im Forum mal nach RTOS suchst, wirst du viele Infos finden. Sich aufzuregen, wenn auf eine nicht besonders gut gestellte Frage wie deine eine genauso schlaue Antwort kommt, finde ich nicht ok.
Um Thread synchronisieren zu können benötigt man atomare Operationen, die der COMPILER zur Verfügung stellen muss. Das hat nichts mit einem RTOS (Real-Time-Operating-System??) zu tun, da sobald man Threading hat mit Real-Time eh nichts mehr los ist. Semaphore kann man nicht nur bei Multithreading-Apps gebrauchen - stell dir vor, du hast eine normale Applikation mit einem Timer-Interrupt und beide verwenden eine bestimmte Resource eine Zeit lange z.B. ein LCD (ist wohl nicht das beste Beispiel :-) dann musst du die Resource Locken. Wenn du jetzt aber eine Abfrage drin hast wie "Ist die Resource frei" und als nächsten Schritt "Ja: dann locke sie" ist das ganze nicht Threading-Sicher, weil die zwei Schritte vom Timer unterbrochen werden können. Dazu benötigt man Semaphore - das sind Operationen, die genau die zwei Schritte atomar ausführen, also nicht unterbrochen werden können. Hmm - eigentlich müsste es sogar reichen, die Interrupts vor der Abfrage zu sperren ... Klar kann man es umständlicher machen, in dem man im Timer Flags setzt und die Flags dann in der Hauptschleife des Hauptprogramms auswertet und dann dort alles macht. "Sich aufzuregen, wenn auf eine nicht besonders gut gestellte Frage wie deine eine genauso schlaue Antwort kommt, finde ich nicht ok." Wenn man die Grundkonzepte Threading + Synchronisation kennt, ist das eine korrekt gestellte Frage - wenn man davon keine Ahnung hat, braucht man auch keine Antwort zu posten. Mfg Thomas
Was ahben Semaphoren mit Echtzeitsystemen am Hut, ausser daß Sie möglicherweise benutzt werden? Atomare Zugriffe auf Compilerebene werden AFAIK durch den Typemodifier 'volatile' garantiert, hat aber rein gar nichts mit Semaphoren zu tun. Wenn ich da wirklich so falsch liege, dann bitte ich um Korrektur!
hmm - volatile sagt imho nur, dass eine z.B. Variable von der Optimierung ausgenommen wird ... Den Rest seh ich genauso :)
Jetzt aber wirklich... Die Semaphores haben nichts mit dem C Kompiler zu tun. Wenn Du "Atomare" operationen brauchst (vermutlich DB-Programmierer) dann soll deine Software die Interrupts vorlaeufig ausschalten (sreg_copy=SREG; cli(); atomic_operation(); SREG=sreg_copy;).
+sei(); Und ja: ich wollte auf die Optimierung hinaus... Aber wie gesagt, Semaphoren haben nichts mit dem Compiler zu tun. Schau Dir gängige uC-OSe an, das ist doch alles schon vorgekaut...
OldBug: nix +sei(). Stell dir vor Du hast eine "Atomare" Routine. Diese Routine ruft einen Trieber auf den Du vor 2 Jahren geschrieben hast: void atomare_routine(void) { cli(); init_external_chip(); tue_was_atomares(); sei(); } void init_external_chip(void) { cli(); PORTB=0xff; sei(); } Siehst Du den Bug? tue_was_atomares() ist nicht mehr atomar :) Mit SREG=sreg_copy wird der I-bit nur dann wieder angemacht wenn er vor dem cli() schon da war. Schliesslich ist sei() dasgleiche wie SREG |= (1<<IBIT); Regards, Richard Cape Town
Nana, moment :-) #define ENTER_CRITICAL_SECTION sreg_copy=SREG; cli(); #define EXIT_CRITICAL_SECTION SREG=sreg_copy; void atomare_routine(void) { ENTER_CRITICAL_SECTION; init_external_chip(); tue_was_atomares(); EXIT_CRITICAL_SECTION; } void init_external_chip(void) { cli(); PORTB=0xff; sei(); } ...dabei würde genau das Gleiche passieren: tue_was_atomares(); ist nicht mehr atomar!
OldBug, ja genau, du sollst "habitually" durch SREG die interrupts sichern, besonders in den "low-level" Routinen. sei() ist nicht mehr moedisch :) Ban sei()!!!
In den Low-Level routinen verwende ich normalerweise GAR KEIN sei();, höchstens vor dem Hauptprogramm, oder wenn sie im Hauptprogramm erst Freigegeben werden sollen, dann erst da... Eine Routine init_external_chip(), wie Du sie vorgestellt hast, sollte man in der Tat nicht basteln ;)
Und Semaphoren haben im Compiler wirklich nix zu suchen, ist Sache des Betriebssystems. Es mag ja sein dass manche Compiler Bibliotheken mit den Schnittstellen zu Semaphoren mitliefern, diese sind dann aber Betriebssystem spezifisch. Aber wo kein BS ist da hat der Kaiser (Hallo Franz) sein Recht verloren <=|:-)
Stimmt ... nichtsdestoweniger kann man Semaphore nachbilden - da der AVR kein OS hat, könnte es sein, dass AVRGCC ja in irgendeiner Library Semaphore nachgebildet hat - wo wir bei der ursprünglichen Frage wieder sind :-)
Ne Anmerkung: Ich verwende immer cli(); + sei();, da ich mir die Sperre über eine komplette Unterfunktion garnicht leisten kann. Gerade bei CPUs mit nur einer Interruptpriorität müssen die Sperrzeiten ja absolut kurz sein. Ich sehe jetzt auch keinen Sinn darin, warum bereits der Aufruf einer Funktion unter Sperre erfolgen sollte. Sobald es sich außerdem um geringer wichtige Interrupts handelt, disable ich auch nur diesen einen Interrupt, dann können die eiligen Interrupts völlig unbehindert zuschlagen. In diesem Fall könnte auch die Sperre nur dieses langsamen Interrupts über mehrere Unterfunktionen hinweg tolerabel sein. Ein cli(); ist quasi immer ein Tanz auf einer heißen Herdplatte, d.h. ich versuche so schnell wie nur irgend möglich mit sei(); wieder kalten Boden unter die Füße zu bekommen. Die Frage einer durch Kaskadierung zu frühzeitigen Freigabe stellt sich also für mich garnicht erst. Peter
Die Antwort wurde schon lange gegeben: "Du kannst entweder ein fertiges RTOS nehmen oder programmierst dir eines selber."
Okay - dann hat also AVRGCC keine nachgebildeten Semaphoren wenn ich deine Antwort verstanden habe. Mehr wollte ich ja garnicht wissen :-) Wieso denn nicht gleich so?
** IDENTITÄTSDIEBSTAHL ** Auch dieser Beitrag ist nicht von mir: Autor: Rufus T. Firefly Datum: 12.04.2005 09:53 vielleicht im Mittelmehr? Wer mich kennt und/oder schon Beiträge von mir gelesen hat, wird wissen, daß ich in der Lage bin, so einen kurzen Satz korrekt zu formulieren. Auch neige ich nicht dazu, zu sinnvollen Fragen völlig schwachsinnige Antworten zu geben; das machen andere Leute, die offensichtlich sogar zu feige sind, ihr anonymes Pseudonym zu verwenden. Es wird Zeit dafür, daß sich die entsprechenden Idioten aus diesem Forum zurückziehen. Eine Anmeldepflicht wäre diesbezüglich wohl auch förderlich. @Thomas: Kannst Du uns einen C-Compiler nennen, bei dem Semaphoren zum Sprachumfang gehören? Auch mir ist die Zugehörigkeit von Semaphoren zu einem RTOS-Kern die geläufige Lesart; selbst die Reduktion von Semaphoren auf eine atomare Operation (i.d.R. ein entsprechende Maschinenbefehl) kenne ich nur als Bestandteil eines RTOS-Kerns.
Hmm - Posix-Semaphore, die es z.B. unter Linux + Unix gibt ... ich müsste aber nachschauen was man da includen muss ... Die gehören aber tatsächlich zum Betriebssystem dazu ... allerdings muss es nicht unbedingt ein RTOS sein - ich wollte nur wissen ob AVRGCC vielleicht sowas schon drin hat, weil man synchronisations-Mechanismen wie Semaphore eigentlich häufig brauchen kann ... Hätte ja sein können :-)
Nochwas: Zum Sprachumfang natürlich nicht - aber genauswenig gehört doch die STL zum Sprachumfang von C++ ...
<ot>
> Eine Anmeldepflicht wäre diesbezüglich wohl auch förderlich.
Die Möglichkeit einer Anmeldung wäre schon sehr vorteilhaft, denke ich.
Aber eine Anmeldepflicht finde ich nicht so gut; Identitätsdiebstahl ist
bereits durch freiwillige Registrierung verhindert.
Gerade Gäste posten aber gerne mal Antworten oder Fragen, ohne sich
gleich registrieren zu wollen. Bei einer Anmeldepflicht würde das Forum
einige User, nicht nur störende, verlieren, fürchte ich.
</ot>
> aber genauswenig gehört doch die STL zum Sprachumfang von C++ ...
Doch, guck mal in den C++-ISO-Standard.
Hi es gibt durchaus Sprachen bei denen Semaphoren Bestandteil der Sprache selbst sind. Eine solche ist z.B. Pearl. Matthias
@Matthias: Pearl ist aber, wenn ich mich recht erinnere, eine Sprache, die RTOS-Elemente mit sich bringt. Vor längerem (müsste noch in den 80ern gewesen sein) gab's mal in der c't eine Artikelreihe dazu. Ansonsten: http://www.irt.uni-hannover.de/pearl/pearl-gb.html @Chris: Magst Du das mit der freiwilligen Registrierung noch ein wenig elaborieren?
Hi schreib ich doch. Werner B. schreibt das Semaphoren ins Betriebssystem gehören. Das stimmt so nicht. Es gibt eben Sprachen, und Pearl ist eine davon, die diesen Mechanismus auf Sprachebene mitbringen. Die Sprache muß das also per Definition können. Also ist die Semaphore Bestandteil der Sprache und nicht des OS. Man könnte auch sagen das das OS Teil der Sprache ist. Matthias
@Matthias:
>>> Man könnte auch sagen das das OS Teil der Sprache ist.
Nein!
Gruß, Michael
> Man könnte auch sagen das das OS Teil der Sprache ist. Du sprichst indirekt den vielleicht wichtigsten Unterschied an, der C von anderen Sprachen hervorhebt. C wurde offiziell von ANSI standardisiert. Somit gibt es feststehende Regeln, ab wann sich ein Programm guten Gewissens als "ANSI-C-Compiler" bezeichnen lässt. Viele anderen Sprachen dagegen, auch etwa Java, sind nicht offiziell standardisiert. Der "Standard" ist bei solchen Sprachen meistens der Compiler/Interpreter des Herstellers; die Sprache kann sich also mit jeder neuen Compiler-Version ändern. Dass C standardisiert ist, hat einige Vorteile. Man kann zum Beispiel sicher sein, dass sich jeder sog. "well-formed" ANSI-C-Code auf jedem ANSI-C-Compiler kompilieren lässt. Ein Nachteil ist natürlich, was man in diesem Thread wieder mal besonders gesehen hat: Standard-C bietet keine betriebssystem- oder hardware-spezifischen Funktionen an. Es wäre zwar unter Umständen möglich, Threads (und damit Semaphoren) in den C-Standard zu setzen, trotzdem hat sich das Standardisierungskomitee dagegen entschieden. Der Grund war, soweit ich weiß, dass solche Funktionen einen enormen Implementierungsaufwand bedeuten würden. Wären Threads oder ähnliches in den C-Standard aufgenommen worden, würde es mit Sicherheit nicht für so viele verschiedene Architekturen ANSI-C-Compiler geben. <ot> > Magst Du das mit der freiwilligen Registrierung noch ein wenig > elaborieren? Ich dachte an sowas, was etwa auf www.c-plusplus.de recht erfolgreich praktiziert wird. Dort kann jeder posten, ob man registriert ist oder nicht. Viele Fragen werden dabei von Unregistrierten gestellt, aber auch viele Antworten. In den Nicht-OT-Foren sind Antworten von Unregistrierten seltener als in OT, aber trotzdem vorhanden. Es gibt auf dem Forum sogar "prominente" Unregistrierte, die regelmäßig im Forum unterwegs sind und hilfreiche Antworten geben, sich aber (aus welchen Gründen auch immer) nicht registrieren. Nur in einem Unter-Forum, der Spiele/Grafikprogrammierung, sind Postings von Unregistrierten nicht mehr zugelassen. Das ist schade, war aber notwendig, da dieses Forum blöde Fragen und blöde Antworten regelrecht anzieht. Wenn mehrmals pro Tag die Frage kommt, wo man Tutorials für einem Quake-like Ego-Shooter findet, besteht die Gefahr, dass ein Forum sein Niveau verliert. In allen anderen C++-Unter-Foren dürfen unregistrierte User problemlos posten. Ich denke, ohne die Möglichkeit des unregistrierten Postings würde das C++-Forum sehr viele User verlieren und die Hemmschwelle für Neueinsteiger erhöhen. Ich weiß nicht, wie viele Moderatoren und/oder Admins dieses Forum hat. Das C++-Forum besitzt jedenfalls trotz der Möglichkeit des unregistrierten Postens ein nicht niedriges Niveau, da die Moderatoren Präsenz zeigen. Dadurch wissen die meisten, dass ihre Postings, sollten sie beleidigend oder störend sein, ziemlich schnell den Weg alles Irdischen gehen. In diesem Forum wird es sehr verdeckt gehalten, wer die Möglichkeit besitzt Postings zu löschen (nur Andreas?). Aber auch hier sieht man ja, dass das Niveau ziemlich gut ist, obwohl man unregistriert posten darf. Eine Registrierung hätte natürlich auch noch andere als den Identitätsschutz: Man könnte seine Beiträge nachträglich editieren, man könnte (je nach Software) E-Mail-Benachrichtigungen bei neuen Beiträgen erhalten, man könnte E-Mails von anderen Usern empfangen, ohne seine E-Mail-Adresse zu posten. Was aber wirklich nervig sein kann, sind hunderte blinkende Features irgendeiner neuen Forensoftware. IMHO wäre z.B. in so einem Forum wie hier etwa ein Avatar völlig fehl am Platze; es sollte schließlich der Stil eines "technischen Forums" gewahrt bleiben, den es zur Zeit ohne Frage besitzt. Aber ich denke, hier besteht erstmal keine Gefahr, dass überstürzt und unüberlegt eine neue Forensoftware installiert wird. </ot>
Ah, danke für die Aufklärung. Ich hatte Dich zunächst missverstanden und angenommen, Du beschriebest ein Feature dieses Forums hier, das ich vollkommen übersehen hatte. D'accord; ein Mischbetrieb aus freiem Forum und Anmeldemöglichkeit wäre in der Tat eine sehr praktische Lösung. Auch Deine Abneigung den übliche Forenfeatures gegenüber teile ich. "Avatare" und vor allem diese beknackten Smiley-Graphiken sind an Entbehrlichkeit nur schwer zu überbieten. Lasset uns hoffen ...
doch das geht... z.b java "uhr" die mit so komischen buchstaben aufgebaut ist und dem mauszeiger folgt... das ist noch sinnfreier als avatare ;) am avatar kann man wenigstens den geisteszustand des jeweiligen besitzers ablesen... und bei den smilies hat man zum grübeln wem soo fad war das zu zeichnen.. sprich die uhr ist das sinnfreiste ;) 73
OK, Hans, dieser Java-Scheissdreck "toppt" diese bescheuerten Smileys noch. Die graphische Darstellung dieses Forums sollte ziemlich exakt genau so bleiben, wie sie ist; dafür übrigens ein Lob an Andreas!
btw, dabei handelt es sich um JavaScript (vorausgesetzt wir reden vom selben unnützen Quatsch). Ich bin kein Java-Programmierer, aber soweit ich weiß wären solche noch penibler, was die Unterscheidung Java<->JavaScript angeht. ;-) > Die graphische Darstellung dieses Forums sollte ziemlich exakt > genau so bleiben, wie sie ist; dafür übrigens ein Lob an Andreas! Jep, der Stil vermittelt einen "technischen" Eindruck und passt damit ziemlich gut zum Thema. Wobei ich mir ein kleines Feature schon gerne wünschen würde: Maximal n Postings pro Seite, der Rest des Threads liegt auf weitere Seiten verteilt. Dann würden Monsterthreads mit >300 Beiträgen den Browser nicht so stark ausbremsen.
Zurück zum Thema: auch ich kenne Semaphore nur als Betriebssystem Bestandteil und denoch stimmt gleichermaßen das Argument in Bezug auf die Fähigkeiten des Compilers. Möchte man ohne Tricks mit einem Compiler Semaphore programmieren so muß die Hardware und auch der Compiler ganz bestimmte atomare Operationen unterstützen, ohne gehts nicht. Atomare Operationen sind unabdingbar dafür.Auch eine Kombimation aus PUSHF + CLI() + Operation + RETI ist da wenig hilfreich, denn sie sind nicht atomar und funktionieren nur auf einer MCU wie dem AVR mit IRQ's ohne Prioritäten. Gruß Hagen
Hi solange das OS (bzw. die Laufzeitumgebung) einen Prozesswechsel sicher verhindern kann (z.B. durch sperren aller Interrupts) braucht der Controller keinerlei spezielle Operationen beherschen. Allerdings will man daß abschalten von INT's vermeiden. Deshalb haben viele Prozessoren eben atomare Operationen um die Funktion von Semaphoren auch ohne das abschalten der INT's zu realisieren. Matthias
> Deshalb haben viele Prozessoren eben atomare Operationen um die > Funktion von Semaphoren auch ohne das abschalten der INT's > zu realisieren. Wenn Du damit Operationen wie test-and-set oder lock-exchange meinst, dann sind die bei reinen Microcontrollern eher selten. Allenfalls als netter Nebeneffekt von to-memory Operationen bei CISC ISAs. Der Grund ist ja auch ein anderer: Interrupts abzuschalten verhindert Konflikte bei Interrupt-Routinen und parallelen Threads. Ohne weitere Massnahmen bleiben es jedoch mehrere Buszugriffe und es hilft folglich nicht bei parallelen Prozessoren oder bei I/O-Controllern mit Eigenintelligenz. Wenn also spezielle Befehle existieren, dann um das Problem auf der Ebene der Bustransfers anzugehen.
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.