RS232

Das sehe ich komplett anders.

Zum einen deshalb, weil sie sooo gut doch nicht sind, daß sie handoptimierten Assemblercode ersetzen könnten. Es geht dabei meist nicht mal unbedingt darum, welcher Code schneller ist, sondern darum, welcher _definierte_ Zeiten verbraucht und nicht schon im nächsten verfickten Build des Compilers Code mit völlig anderem Laufzeitverhalten produziert.

Ja, deswegen schreibe ich Asm. C ist für mich nur eine Art Klartext- Verschlüsselung. In schweren Fällen lasse ich den Dreck sogar erstmal kompilieren und disassemblieren, bevor ich eine Deutung von Sinn und Zweck des grenzdebilen Machwerkes wage.

Also ich weiß nicht. Wenn ich zu den Eigenheiten der Maschine auch noch die Eigenheiten des Compilers berücksichtigen muß, um passenden Code schreiben zu können, dann hört sich das nach meinem Verständnis der Grundlagen der Informatik nach einer Erhöhung der Komplexität an und nicht nach einer Verringerung. D.h.: die Verwendung der "Hochsprache" ist dann eindeutig kontraproduktiv.

Sowas kann man gerade im µC-Bereich in reichlich C-Sources finden. Verbogen bis zur kompletten Unlesberkeit, um die Effizienz des optimalen Codes zu erreichen (natürlich nur auf einem ganz konkreten Zielsystem und mit einem ganz konkreten Compiler in einer ganz bestimmten Version).

Das ist Bullshit und läuft dem Sinn einer "Hochsprache" komplett zuwieder.

Wer das nicht begreift, ist ein Vollidiot. Ohne jedes wenn und aber.

Nö, bei einer 3-Draht Strecke musst Du das so machen, damit die HW-HS (aka Modem Control) Eingänge auf dem richtigen Pegel liegen.

CD und RI auch besser noch an DTR anbinden.

Saludos Wolfgang

Und so sprach Heiko Nocon:

Das ist, mit Verlaub, Bullshit.

Code über die Anzahl der ausgeführten Operationen ein Laufzeitverhalten beizubringen, ist ganz schlimmes Gefrickel. Nicht umsonst optimieren die ganzen C-Compiler Warteschleifen raus, wenn man die Optimierung hochsetzt.

Wenn man Code mit einer definierten Reaktion braucht, nimmt man einen Timer-IRQ. Davon haben MuCs inzwischen genügend, um das passend zu machen.

Und selbst auf einem PIC mit nur einem programmierbaren Timer für mehrere zu verwaltende Ereignisse geht das. Man muss halt mal ein bischen Nachdenken...

Welche Eigenheiten des Compilers bitte? Alle C-Compiler halten sich (auf Wunsch) an MISRA. Wenn ich das berücksichtige, und nicht irgend welche Compiler-Spezifischen Hacks mache, läuft mein Code auf jedem Compiler zum funktional gleichen Ergebnis. Zumindest wenn ich alles richtig gemacht habe.

Wenn dein Code das nicht tut, machst du eindeutig was falsch.

Und die Eigenheiten der Maschine? Wenn ich ordentlichen Code geschrieben habe, tausche ich die Treiberschicht, und mein Code funktioniert auch auf anderen Kernen.

Genau. Treffender kann man das nicht formulieren.

Roland

Wobei ich beim RI skeptisch bin. Der pulst doch eigentlich nur im Rhythmus des Telefonklingelns, oder?

Gruß Henning

uf

elche

iler

Nicht, wenn WCET eine Anforderung ist.

en

Anforderung: Maximale Prozessorauslastung 70%. Upgrade des Compilers von=

x.y.1 auf x.y.2. Gesamtsystem ben=C3=B6tigt pl=C3=B6tzlich 10% Prozessor= zeit mehr.

Nein, das m=C3=B6chte man auch nicht in Assembler schreiben, aber "funkt= ionieren" mit Echtzeitanforderungen ist anders.

Vinzent.

Und so sprach Vinzent Hoefler:

Ich gehe jetzt mal davon aus, dass du die maximale Programmlaufzeit meinst. Wo soll da jetzt das Problem sein, auch aus dem C-Code eine entsprechende Abschätzung zu machen?

Maximale Prozessorlast? Was ist das denn für eine seltsame herangehensweise? Ich kenne nur Anforderungen, welche eine

- maximale Stack-Auslastung

- maximale Reaktionszeit definieren.

Letzteres über eine theoretische "Freikapazität" im Prozessor sicher zu stellen, ist Gefrickel. Denn jeder IRQ wird dir ins Knie schießen.

Es drängt sich mir der Gedanke auf, dass auch du hier über Codelaufzeiten dein Programm versuchst zu "timen". Das kann nur in die Hose gehen.

Ich habe so einen Blödsinn mal auf einem PIC probiert, um mir einen Software-Interrupt-Handler auf dem einzigen Timer zu sparen. War ein prägendes Erlebnis:

Mehr Code, mehr Speicher und funktioniert hats trotzdem nicht mit der geforderten Präzission.

Die Zeiten, wo ein guter Programmierer besseren Code per Assembler geschrieben hat, als ein schlechter in C sind schon seit Jahren vorbei.

Roland

"God is real unless declared as integer" gilt allerdings nur bei Fortran.

Waldemar

Am 05.11.2011 09:19, schrieb Roland Ertelt:

Man kann in jeder Programmiersprache FORTRAN-Programme schreiben!

Butzo

Und so sprach Klaus Butzmann:

Das auch. :-D

Nein, ich habe nie mit FORTRAN geabeitet. Ich kenne diesen Mythos nur vom Hörensagen.

Roland

Hallo Klaus,

Klaus Butzmann schrieb:

Was ist daran Unsinn, wenn ich eine direkte Verbindung habe, die keinen Sender erfordert. Dann ist es doch nur konsequent auf die Aufforderung 'ich möchte senden' direkt mit 'dann mach' zu antworten.

Gruß Martin

Hallo Roland,

Roland Ertelt schrieb:

Wenn Deine Timingbedingungen das zulassen. Wenn Du nur ein paar Befehle Zeit hast, wird das mit Interrupts u.U. schwierig. Und erst recht, wenn dann noch nicht klar überschaubare Initialisierungen der Laufzeitumgebung angestoßen werden.

Klartext: alle außer Dir sind zu blöd?

Gruß Martin

Bei deinem PC ist RTS ein Ausgang der der Gegenstelle sagt, dass sie jetzt senden darf. CTS ist ein Eingang der dir sagt, dass die Gegenstelle dir erlaubt zu senden.

Deshalb verbindet man bei einer Nullmodemverbindung immer RTS der einen Seite mit CTS der anderen Seite.

Gerrit

Hallo Gerrit,

Gerrit Heitsch schrieb:

Wir redeten von der Verdrahtung einer Dreidrahtverbindung. Da bekommt die Gegenstelle kein RTS von mir. Und von einem PC war ohnehin keine Rede.

Ach

Gruß Martin

Theoretisch ja, aber wenn Du den Input in der Luft hängen lässt, pulst er u.U. auch mit völlig undefinierten Verhältnissen. Und je nachdem, wie die UART Register/Treiber etc. initialsisiert/verändert werden... geht das in die Hose. Manche UARTs können sogar ModemSignalChange IRs auslösen und dann ggf. (je nach Geschick des Programmierers) das OS im Nirwana oder BSOD sterben lassen.

Je seltener dieser Zustand auftritt, umso spannender!

BTDT, ganz besonders die Microschrott UART Programmmmurkser sind/waren da sehr kreativ :(

Wie schon mal berichtet, habe ich seinerzeit einen komplett eigene UART Treiber geschrieben, der vollständig IR gesteuert funzte. Samt eigenem Realtime Ticker mit 1ms Auflösung mit tabellengesteuerter Timer Verwaltung für termin- sowie fristbedingte Aufrufe von beliebigen Vektoren... und habe das DOS und Windoof (=

Roland Ertelt schrieb:

So ziemlich jeder Compiler hat einige Spracherweiterungen, die sind auch nötig, für Sachen, die der ISO-Standard nicht definiert, z. B. Interrupt-Routinen.

Diese Erweiterungen bringt man aber recht einfach mit einer Compilerspezifischen Header-Datei unter einen Hut. Z. B. könnte man darin den Datentyp bool im Fall eines Keil C51 per typedef auf bit umbiegen. Hardware abstrahiert man möglichst per Treiber. Wenn das gut macht, kann man den Code sogar nativ auf einem PC ausführen und kann dort komplexere Algorithmen testen, deren Ergebnisse in Graphiken auswerten, Debugger verwenden etc.

Markus

Und in Forth geht das am Einfachsten :)

Saludos Wolfgang

Am 05.11.2011 15:12, schrieb Martin Schoenbeck:

Ja völlig korrekt, und genauso konsequent ist es bei verschwinden von CTS TXD sofort abzubrechen da der Sender ja sowieso aus ist. Die beiden Signale sind halt lokal für den Sender gedacht wurden aber oft für das Handshake zwischen Sender und Gegenstelle benutzt. Kann funktionieren, muss aber nicht.

Butzo

Am 05.11.2011 15:21, schrieb Martin Schoenbeck:

Ja, wie beim Autofahren: Alle anderen können überhaupt nicht fahren :-)

Butzo

Und so sprach Markus Schaub:

Macht das hier jemand etwa anders?

Roland