Guten Morgen!
ich verwende den Keil C-Compiler für 8051.
In Assembler kann man mit SETB und CLR auf einzelne Bits zugreifen.
Gibt es in C dafür eine Entsprechung?
Ich habe folgendes versucht:
PortC|=1<<5; //Bit 5 setzen
leider übersetzt der Compiler den Befehl nicht mit SETB, sondern
über mehrere Befehle mit MOV und ORL. Dadurch ist das Programm zu
langsam.
Danke schonmal im Voraus.
"PortC|=1<<5; //Bit 5 setzen" is nun mal eine shift anweisung. und hier
zufaellig halt 1 bit shl und das kann der assembler quasi direkt
uebernehmen. abhilfe: inline assembler!
Hans wrote:
> PortC|=1<<5; //Bit 5 setzen>> leider übersetzt der Compiler den Befehl nicht mit SETB, sondern> über mehrere Befehle mit MOV und ORL. Dadurch ist das Programm zu> langsam.
Sehr komisch, im Forum wird ständig behauptet, C sei sogar schneller als
ASM?
Der fünfte Ludolf wrote:
> Wenn du auf schnelle Art und Weise Bits Toggeln willst, dann versuche> die entsprechenden Routinen mittels Assemblerbefehlen in C einzubinden.
Wozu brauch ich dann C, wenn die einfachsten Dinge zum Problem werden.
>Wozu brauch ich dann C, wenn die einfachsten Dinge zum Problem werden.
Schreib mal bitte ein richtig komplexes Programm (mit Berechnungen und
noch irgendwelch anstrengendem Zeug) in Assembler, bei dem du auch noch
die Übersicht über Jahre behälst.
>leider übersetzt der Compiler den Befehl nicht mit SETB, sondern>über mehrere Befehle mit MOV und ORL.
Manche Compiler haben noch einen Optimierungsschalter...
> ...C sei sogar schneller als ASM?
In der Fertigstellung des Programmes stimmt diese Aussage, aber nicht in
der Ausführungsgeschwindigkeit des compilierten Programmes.
Hast Du den Code als Debug compiliert?
Ich kenne zwar den Compiler nicht, den Du verwendest, weiß aber, daß für
Debug-Compiles bei gut optimierenden Compilern (z.B. Visual C++) alle
Optimierungen abgeschaltet werden, um die Zuordnung von Maschinencode
zum Quelltext zu erleichtern und damit sinnvolles symbolisches Debuggen
überhaupt erst möglich zu manchen. Der so erzeugte Maschienencode ist
äquivalent zum optimierten Code -- oder sollte es zumindest sein -- aber
deutlich weniger effizient.
Übersetze Dein Programm mal als Release und sieh Dir dann nochmal den
Maschinencode an.
Der 8051 ist BITadressierbar also warum den Umweg. Das Define sieht beim
Keil etwas anders aus. Hoffe mein Gedächtnis trügt mich nicht.
sbit _DATA = P3^5;
Rahul Der trollige wrote:
>>Wozu brauch ich dann C, wenn die einfachsten Dinge zum Problem werden.>> Schreib mal bitte ein richtig komplexes Programm (mit Berechnungen und> noch irgendwelch anstrengendem Zeug) in Assembler, bei dem du auch noch> die Übersicht über Jahre behälst.>>>leider übersetzt der Compiler den Befehl nicht mit SETB, sondern>>über mehrere Befehle mit MOV und ORL.>> Manche Compiler haben noch einen Optimierungsschalter...
1. Was soll an C-Code übersichtlich sein?
2. Aus welcher Sprache besteht C?
3. Man kann sich in Assembler , durch Macros und Subroutine das gleiche
Konstrukt wie in C zusammenbauen und das RAD nicht ständig neu
erfinden.
4. Ein C-Programmierer ohne Assembler Kenntnisse, was macht der dann im
obigen Fall? Stellt er dann seine Frage ans Forum so " Hat mal jemand
nen Treiber zum setzen oder Löschen eines Bits"
5. Wenn man in Assembler ordentlich programmiert, ist es garnicht
notwendig, bestimmte Speichergrößen für Programmcode zu überschreiten.
(Das gilt nicht für Daten)
6. C ist eine Sprache von den Anfang 70ern und hat einen Syntax, der den
heutigen Anforderungen garnicht gerecht wird. der Core eines Prozessors
hat wenigstens immer eine Anzahl von Grundbefehlen, für festegelegte
logische Funktionen. C ist mittlerweile ein Zusammenwürfelung aus lauter
unsinnigen Begriffen.
7. Portierbarkeit von C. Finde ich besonders lustig. Was ist damit
gemeint.
Nehmen wir an ich habe an eine MCU eine bestimmte Pheripherie
aneschlossen und habe in C dazu eine Library zur Ansteuerung bekommen.
Steige jetzt auf nen anderen Prozessorkern um und möchte dort die
gleiche Pheripherie anschliessen. Dort gibts aber noch keine
Bibliotheksfunktion dafür.
8. Ein Assembler ist im Verhältniss ein kleines Programm und bietet mir
immmer die Möglichkeit optimalen Code zu schreiben. Bei C bin ich auf
die Programmierer dieser Sprache angewiesen. Machen die Fehler rein, hab
ich Sie auch und tausende andere genauso.
Schaut Euch doch mal die Update Listen und Versionsänderungen von Keil,
IAR etc. an. " Da steht dann " dies und das hat in der letzten Version
leider nicht funktioniert, wurde aber behoben"
In der nächsten Revision steht das gleiche usw.
Es kommt sogar oft vor, daß neue Fehler eingebaut werden, die früher
nicht da waren.
Ist etwa 12 Jahre her, da hat ein Kollege mit C für 8051 von Keil
gearbeitet. Beim Hersteller angefragt, welche Fehler der Compiler hat.
Antwort war " Wir sagen Ihnen lieber was funktioniert"
Wenn ich in Assembler Fehler mache, bin ich wenigstens selber dafür
verantwortlich und hab die Möglichkeit es zu korrigieren.
In C heisst es dann,´" Ich schau mir den compilierten Assembler
Sourcecode an"
Toll, ne Programmiersprache, die man noch kontrollieren muß, ob Sie es
auch richtig macht. Was macht der, der keine Assemblererfahrung hat?
Man muß Dinge nicht programmiertechnisch ohne Grund unnötig aufblasen.
Der fünfte Ludolf wrote:
>> ...C sei sogar schneller als ASM?>> In der Fertigstellung des Programmes stimmt diese Aussage, aber nicht in> der Ausführungsgeschwindigkeit des compilierten Programmes.
Nicht mal das stimmt.
Wenn man fragen muß, wie setzte ich ein Bit in C.
Dann ist wohl jede Aussage über Erstellungszeit unsinnig.
Ooooooh Dirk, auf welchem Trip bist du denn ???
Ich habe 15 Jahre lang Assembler programmiert und ja, ich mache es heute
auch noch von Zeit zu Zeit.
Wenn du also schon Assembler kannst und dich dann mit C befasst dann
mußt du hinter die Kulissen schauen. Es gibt nichts was moderne C
Compiler nicht auch in Assembler übersetzten können. Allerdings braucht
es Erfahrung. Ich programmiere diverse MC Familien und glaub mir, mein
Code ist zu 70 % portierbar. Dein ASS Code ist zu 0% portierbar.
Erst lernen, dann meckern.
> Portierbarkeit von C. Finde ich besonders lustig.> Was ist damit gemeint.
Hardware: Man nehme beispielsweise einen MCP2515 oder ENC28J60. Einzig
der Code für die SPI-Hardware ist abhängig vom Microcontroller, der Rest
nicht. Ähnlich auch DS18x20, allerlei Realtime-Clocks, EEPROMs,
Dataflashes, FRAMs usw.
Software: CAN und Ethernet haben meist mehr oder minder heftige
Software-Layer oben drauf sitzen (z.B. TCP/IP).
> C ist eine Sprache von den Anfang 70ern und hat einen Syntax,> der den heutigen Anforderungen garnicht gerecht wird.
Full ack. Für Windows-GUIs, DCOM/ORB-Programmierung usw ist C ziemlicher
Mist.
Nur hat die Programmierung von Microcontrollern sehr viel Ähnlichkeit
mit den Anforderungen aus eben jener Zeit, aus der C stammt, aber
praktisch keinerlei Ähnlichkeit mit den zitierten Programmiertechniken
grosser PC-Programme.
Dirk,
mal ganz ehrlich: Was soll das?
Du könntest genauso gut versuchen den Briten von der Monarchie
abzubringen. Oder den Papst vom Evangelium zu überzeugen.
Was mir bei den ASM - "Fanatikern" immer wieder auffällt ist,
das sie wenn es darum geht C zu kritisieren, sofort Gewehr bei Fuß
stehen. Stellt aber jemand eine Frage zu einem Asm-Problem herrscht
dann aber das große Schweigen. Solche Fragen werden dann von anderen
beantwortet. Mixed mode Programmierer üblicherweise, die sich aus
Diskussionen wie diese größtenteils heraushalten.
Aufgrund deiner angeblichen großen Erfahrung müßte du doch eigentlich
einen sinnvolleren Beitrag hier im Forum leisten können als diese
ständigen Angriffe.
Wie wäre es mal mit einem TCP-Stack in Assembler für die Codesammlung?
- Michael
> Wie wäre es mal mit einem TCP-Stack in Assembler für die Codesammlung?
Also in C könnte ich einen beisteuern ;-)) läuft auf x51, AVR's und
MSP's ;-))
Hat wer einen in ASS für die genannten Typen ?? her damit !
A.K. wrote:
> Software: CAN und Ethernet haben meist mehr oder minder heftige> Software-Layer oben drauf sitzen (z.B. TCP/IP).
Hast Du dier mal den SoftwareLayer von CANopen CIA4xxx angeschaut??
Die Nutzdatenrate ist nur ein Bruchteil der Übertragenen Daten.
Für diesen unsinnigen Mist braucht man wieder höhere Übertragungsraten,
dafür wieder aufwendigere Hardware, Übertragungstechniken und Schirmung
für EMV Probleme etc.
Was passiert dann mit der Effizienz?
> Die Nutzdatenrate ist nur ein Bruchteil der Übertragenen Daten.
Wenn du hohe Übertragungsraten willst, nimm USB oder Ethernet. Dafür ist
CAN nicht gedacht.
Der Sinn von CAN ist Vereinheitlichung von Schnittstellen im
Automobilbereich, bei Übertragung von Status- und Steuerinformation. Was
auch Vereinheitlichung von Softwareschnittstellen und übergreifendes
Systemmanagement einschliesst.
Wie effizient oder ineffizient CANopen&Co sein mögen, Code der von
hunderten von Programmierern verschiedenster Firmen über viele Jahre
verbrochen wird, ist anders nicht handhabbar. Und das Zeug innerhalb
einer Firma soll auch dann noch funktionieren, wenn deren Programmierer
final unter die Räder des Endproduktes kam.
Es liegt eher daran, daß man von Anfang an Leute an Projekte ranlässt,
deren Denke andere später auslöffeln müsssen.
Viele Köche verderben nun mal den Brei.
Die höchste Ausfallrate im Automobilbereich, bezieht sich mittlerweile
auf Softwareprobleme.
Warum nicht dem Autofahrer zumuten, an der Tankstelle täglich ein
Softwareupdate zu machen und die Möglichkeit des Sourcecode Debugens auf
dem Navidisplay.
Wäre doch ne tolle Idee.
Alles immer schneller und Highleverlischer schreiben und die
Auswirkungen
den Kunden tragen lassen. Tolle Einstellungen.
Jeder ist über Windows und seine 70T Fehler glücklich.
Dann hört auf zu meckern und akzeptiert die Auswirkungen der eigenen
Taten.
> Wozu eigentlich einen Assembler, wo man doch mit dem Hex-Editor dasselbe
erreichen kann?
Uhu, bist du die Reinkarnation von "von Neumann" ? Als seine Mitarbeiter
Assembler entwickelten vertrat er die gleiche These ;-))
A.K. wrote:
>> Viele Köche verderben nun mal den Brei.>> Und wenn der einzige Koch tot ist macht die Küche Pleite?
Und wenn Kernigan und Ritchie tot sind stirbt der Buchstabe C aus.
Wie kann man so ne unqualifizierten Mist schreiben.
ich weiß nicht obs der keil hat denke aber es ist Standard.
mein CVAVR macht InlineAssembler
>>>>>>>>>>>>>>>>>>>>>
You can include assembly language anywhere in your program using the
#asm and #endasm directives.
Example:
void delay(unsigned char i) {
while (i--) {
/* Assembly language code sequence */
#asm
nop
nop
#endasm
};
}
Inline assembly may also be used.
Example:
#asm("sei") /* enable interrupts */
In order to use multiple instructions in inline assembly, the \
separator is required.
Example:
#asm("nop\nop\nop")
The registers R0, R1, R22, R23, R24, R25, R26, R27, R30 and R31 can be
freely used in assembly routines.
However when using them in an interrupt service routine the programmer
must save, respectively restore, them on entry, respectively on exit, of
this routine.
> Wie kann man so ne unqualifizierten Mist schreiben.
Der nächste Schritt bringt uns dann wohl zu Godwins Law. Schade
eigentlich, ein bischen Streitgespräch ist manchmal ganz unterhaltsam.
Winfried, ich hatte es schon erklärt, der 8051 ist BITfähig, AVR's
können das nicht.
Das Schlüsselwort heißt SBIT und das wird auch nach setbit und clearbit
übersetzt. Wo ist das Problem ? Man muß eben den Compiler und die
Architektur verstehen.
Dirk, erst deine Ignoranz bei Baud vs. Bit/s, und jetzt das hier... bist
du irgendwie auf dem Troll-Trip?
Hans, ist die Optimierung eingeschaltet? Dass ein Compiler wie Keil eine
so einfache Ersetzung nicht hinbekommt kann ich mir nicht vorstellen.
Andere Compiler (z.B. AVR-GCC) schaffen das auch ohne dass man ihnen
explizit sagt "verwende hier sbit".
Mensch Dirk!
Deine Ass-Verblendung ist ja Entsetzlich! Ich war auch mal so, hab 20 J.
Ass geschrieben, hab' genau mit deinen Argumenten rumgetönt.
Seit 5J. schreibe ich C, wenns sein muss kommt Ass-Code hinzu - und es
muss oft sein!
>Und wenn Kernigan und Ritchie tot sind stirbt der Buchstabe C aus.>Wie kann man so ne unqualifizierten Mist schreiben.
Das Betriebssystem auf dem du gerade schreibst ist auch in C
geschrieben.
An deiner Stelle würde ich deinen Rechner samt OS auf den
unqualifizierten Misthaufen schmeißen.
Der fünfte Ludolf wrote:
> Mensch Dirk!>> Deine Ass-Verblendung ist ja Entsetzlich! Ich war auch mal so, hab 20 J.> Ass geschrieben, hab' genau mit deinen Argumenten rumgetönt.
C gibts seit den 70ern. Warum hast du 20 Jahre Deínes Lebens
verschwendet?
>> Seit 5J. schreibe ich C, wenns sein muss kommt Ass-Code hinzu - und es> muss oft sein!
Hättest Du mal, andere Beiträge von mir in Threads gelesen, würdest Du
verstehen, was ich damit sagen möchte. Es geht garnicht darum C schlecht
zu machen.
Es geht lediglich darum, den Leuten die hier in dieses Interessengebiet
einsteigen zu vermitteln, sich zuerst mit den Grundlagen zu
beschäftigen.
Der IC wurde auch nicht vor dem Transistor erfunden.
> Das Betriebssystem auf dem du gerade schreibst ist auch in C> geschrieben.
Ich weiss, es geht auch garnicht anders, wie wären sonst Megabytes für
nen
Maustreiber zu erklären.
> An deiner Stelle würde ich deinen Rechner samt OS auf den> unqualifizierten Misthaufen schmeißen.
Wer würde das nicht gern.
Würde auch gern ein Auto kaufen, was absolut umweltverträglich und
sparsam
ist. Aber das interresiert niemanden. Lieber nen Kühlschrank mit TFT
Monitor und Internetsnschluß zum Abruf von Wasserkochrezepten
Ach Dirk, meinst Du wirklich, Du könntest so, wie Du das hier angefangen
hast, irgend einen davon überzeugen, daß es nützlich ist, sich mit Asm
auseinander zu setzen?
Lies doch mal was interessantes, z.B. das hier (danke Joe, für die
Idee): http://de.wikipedia.org/wiki/Von_Neumann
>Hättest Du mal, andere Beiträge von mir in Threads gelesen, würdest Du>verstehen, was ich damit sagen möchte. Es geht garnicht darum C schlecht>zu machen.
Nach dem Rumgeflame interessiert sich vermutlich niemand mehr für
irgendwelche deiner Beiträge, weil du einfach als Troll abgestempelt
wirst.
>Es geht lediglich darum, den Leuten die hier in dieses Interessengebiet>einsteigen zu vermitteln, sich zuerst mit den Grundlagen zu>beschäftigen.
Man kann sich auch von hinten in die Brust schiessen...
>Der IC wurde auch nicht vor dem Transistor erfunden.
Stimmt.
Dirk Hofmann wrote:
> wie wären sonst Megabytes für nen Maustreiber zu erklären.
Zum zweiten Mal: glaubst du ernsthaft dass da mehrere MB Programmcode
drinstecken?
> ... sich zuerst mit den Grundlagen zu beschäftigen.
Das solltest du dir selbst mal zu Herzen nehmen.
Andreas Schwarz wrote:
> Dirk Hofmann wrote:>> wie wären sonst Megabytes für nen Maustreiber zu erklären.>> Zum zweiten Mal: glaubst du ernsthaft dass da mehrere MB Programmcode> drinstecken?>>> ... sich zuerst mit den Grundlagen zu beschäftigen.>> Das solltest du dir selbst mal zu Herzen nehmen.
Gute Frage Andreas, sag mir, was glaubst Du wie viel echten Prorammcode
ein Maustreiber hat?
Ne Antwort wäre zur Abwechslung mal toll.
Der Maustreiber für die Logtech G5 Lasermaus besteht aus vier
Teilen, die zusammen 135kB groß sind. Wie viel davon in den Speicher
gemapped wird und wie viel RAM darüber hinaus benötigt wird, weiß
ich nicht.
Aber das ganze Gerede ist müßig. Dirk, falls du erreichen willst
das sich Anfänger zunächst mit den 'richtigen' Dingen befassen
sollen, so hast du dein Ziel weit verfehlt.
Vielleicht solltest du eins bedenken: Manchmal liegt es an einem selbst.
- Michael
Wenn's jetzt um Treiber und Betriebssystem geht.:
Soviel ich weis hat Herr Mike Grosoft und seine Leute viel mit Basic
gearbeitet und später mit C#.
Der Maustreiber selbst hat immer irgendetwas im Bereich von 100 bis 200
KB.
(Außer ein Koffer verbreitet die Debug-Version)
Der Rest ist Firlefanz wie Anzeigen in der Taskleiste, zusätzliche
Einstellprogramme, nette Bildchen oder ein MP3-Player wie bei Logitech.
mfg Sepp
> was glaubst Du wie viel echten Prorammcode ein Maustreiber hat?
Ich muss nicht glauben, ich kann nachschauen.
Der Treiber selbst:
/System/Library/Extensions/MicrosoftMouse.kext/Contents/MacOS/MicrosoftM
ouse: 156K
Das Konfigurationsprogramm:
/Applications/Microsoft Mouse.app/Contents/MacOS/Microsoft Mouse: 174K
Jeweils enthalten ist Code für zwei Architekturen (PPC und x86) und
Overhead durch Metadaten.
Und warum war der Download dann 5 MB groß? Wegen Bildern, Icons,
Hilfe-Dateien, Strings in 10 Sprachen:
$ du -sh /Applications/Microsoft\ Mouse.app/Contents/Resources/
8.9M
Andreas Schwarz wrote:
>> was glaubst Du wie viel echten Prorammcode ein Maustreiber hat?>> Ich muss nicht glauben, ich kann nachschauen.>> Der Treiber selbst:> /System/Library/Extensions/MicrosoftMouse.kext/Contents/MacOS/MicrosoftM ouse:> 156K>> Das Konfigurationsprogramm:> /Applications/Microsoft Mouse.app/Contents/MacOS/Microsoft Mouse: 174K>> Jeweils enthalten ist Code für zwei Architekturen (PPC und x86) und> Overhead durch Metadaten.>> Und warum war der Download dann 5 MB groß? Wegen Bildern, Icons,> Hilfe-Dateien, Strings in 10 Sprachen:>> $ du -sh /Applications/Microsoft\ Mouse.app/Contents/Resources/> 8.9M
OK Andreas,
danke für Deine Antwort.
Stelle Dir folgendes Vor!
Nimm den Grundtreiber ohne Firlefanz mit voller Funktionalität.
Wie viel Speicherbedard würdest Du zur Realisierung auf einem
stinknormalem
µC veranschlagen.
Ich hab für eine Applikation schon mal eine PS2 Tastatur über einen µC
über 2 Portleitungen realisiert.
Inkl. der Umsetzung aller SET2 codes und vieler Windowsspezifischen
Sondertasten.
Das waren 3 KBytes.
Takt und Datenleitung wurden per SoftwareSim realisiert.
Und weil bis jetzt niemand daran gedacht hat die eigentliche Frage zu
beantworten mache ich es.
Versuch's einfach mal ohne dem Shift.
Denn der Compiler macht nur dass was du ihm sagst.
Versuchs so:
PortC |= 0x10; //Bit 5 setzen
Und das Löschen von Bit5 geht so:
PortC &= 0xEF; //Bit 5 löschen
Wenn du dir dass im Kopf Ausrechnen erspahren willst, dann verwende doch
einfach den Windowstaschenrechner in wissenschaftlicher Ansicht.
Der kann Binär, Dezimal Hexadezimal und octal.
Das mit den Megabytes hätten wir also geklärt; jetzt kommst du mit ein
paar kB an die angeblich zu viel sind...
In einem PC-Maustreiber kann man eben nicht wild auf Pins und globale
Variablen zugreifen, man muss sich in das Treibermodell des
Betriebssystems einfügen, und dadurch ist schon mal deutlich mehr
Aufwand notwendig. Zudem implementieren praktisch alle aktuellen
Maustreiber haufenweise Sonderfunktionen, meiner z.B. eine Zoomtaste,
Belegung der Sondertasten mit Tastenkombinationen, einstellbare
Mausbeschleunigung, und das Ganze für ein Dutzend verschiedene Modelle.
Dass dabei ein bisschen mehr als 3 kB zusammenkommt ist doch nicht
verwunderlich und liegt ganz bestimmt nicht an C. Und wenn Microsoft den
Maustreiber in Assembler geschrieben hätte, dann hätten sie bei Apples
Umstieg von PowerPC auf x86 schön blöd aus der Wäsche geguckt (ganz
abgesehen davon dass dieser Umstieg auch nur durch die Verwendung von
Hochsprachen im Betriebssystem überhaupt möglich war).
Josef wrote:
> Und weil bis jetzt niemand daran gedacht hat die eigentliche Frage zu> beantworten mache ich es.>> Versuch's einfach mal ohne dem Shift.> Denn der Compiler macht nur dass was du ihm sagst.>> Versuchs so:> PortC |= 0x10; //Bit 5 setzen
Das Ausrechnen von Konstanten bekommt nun wirklich auch der allerletzte
Compiler hin; der Shift war auch gar nicht das Problem, sondern dass der
Compiler den Bytezugriff nicht in einen Bitzugriff umgewandelt hat
("mehrere Befehle mit MOV und ORL").
Joe wrote:
> Josef, die Frage habe ich schon 3x beantwortet, den Thread liest nur> keiner mehr, hier also noch einmal SBIT SBIT SBIT SBIT 8051 kein> AVR!!!!!
Das hat nichts mit 8051 oder AVR zu tun, Zugriffe auf IO-Ports kann auch
der AVR bitweise machen. Und die Compiler (AVR-GCC zumindest, IAR sicher
auch) kommen da auch von selbst drauf, wenn ein AND/OR mit einem Bit
gemacht wird.
@Josef: Der Shift-Ausdruck ist eine Konstante. Wenn dein Beispiel
funktioniert würde das ja bedeuten das der C51 kein constant-folding
implementiert hat. Dann müßte
1
a=3+3;
ebenfalls zur Laufzeit berechnet werden.
>Ich hab für eine Applikation schon mal eine PS2 Tastatur über einen µC>über 2 Portleitungen realisiert.>Das waren 3 KBytes.
Ja, das erklärt einiges.
Zumal ja das PS/2 Protokoll bekanntlich viel komplizierter
ist als das USB HID Protokoll und auch viel mehr leistet.
Und das hast du ganz alleine geschafft? Nicht schlecht.
Ich deinstalliere sofort den GCC.
Hans hat folgende Frage gestellt:
Guten Morgen!
ich verwende den Keil C-Compiler für 8051.
In Assembler kann man mit SETB und CLR auf einzelne Bits zugreifen.
Gibt es in C dafür eine Entsprechung?
Ich habe folgendes versucht:
PortC|=1<<5; //Bit 5 setzen
leider übersetzt der Compiler den Befehl nicht mit SETB, sondern
über mehrere Befehle mit MOV und ORL. Dadurch ist das Programm zu
langsam.
Danke schonmal im Voraus.
Also, PortC gibts beim 8051 nicht, es gibt P0, P1, P2, P3.
Demnach ist PortC z.B. P3 und der hat 8 BIT, P3_0, P3_1...
P3_5 ist bei Verwendung des Keil C Compiler:
sbit meinPin = P3^5;
und dann:
meinPin = 1; mein Pin = 0;
das wird auch übersetzt nach
setb p3.5
clr p3.5
Nu sag ich nix mehr ;-))
Also, mein Logitech-Treiber:
Logitech-Setpoint v3.10.exe hat nur 39.2MiB Größe (im Setup).
Soviele Megabytes um den kleinen kb-Treiber gewrapped :(
---
>Ein Assembler ist im Verhältniss ein kleines Programm und bietet mir
>immmer die Möglichkeit optimalen Code zu schreiben
Wenn ich in ASM uint32_t data; haben will, wie mach ich das?
data0;data1;data2;data3 - Toll, wie übersichtlich und praktisch...
Über das rumrechnen mit verschiedenen uint32_t will ich gar nicht erst
nachdenken müssen.
---
Was beim Prob. bei ASM ist:
Binn im Programm und will ne Schleife als Label...
hab ich schon loop5 benutzt? kommt 6, 7 oder 8?
Und goto's sollen ja auch nicht so beliebt sein...
---
>Wenn man fragen muß, wie setzte ich ein Bit in C.>Dann ist wohl jede Aussage über Erstellungszeit unsinnig.
Fragen wir anders: Wie übergebe ich eine Funktion mit 3
unterschiedlichen int-Typen in ASM in möglichst kurzer Zeit. Die
Übergabe sollte auch übersichtleich sein. Ich möchte Jederzeit alle 3
Typen schnell überblicken können.
Joe wrote:
> Ich habe folgendes versucht:>> PortC|=1<<5; //Bit 5 setzen>> leider übersetzt der Compiler den Befehl nicht mit SETB, sondern> über mehrere Befehle mit MOV und ORL. Dadurch ist das Programm zu> langsam.>> Danke schonmal im Voraus.>> Also, PortC gibts beim 8051 nicht, es gibt P0, P1, P2, P3.
Ja, PortC sollte nen dicken Fehler bringen.
Man muß schon die richtigen Ports benutzen:
1
P3|=1<<5;
macht auch nirgends ein MOV, sondern nur ein "ORL P3, #20h", ist daher
nur 1 Zyklus und 1 Byte mehr, als der Bitbefehl.
Für den Bitbefehl muß man beim Keil "sbit" nehmen:
>> C ist eine Sprache von den Anfang 70ern und hat einen Syntax,>> der den heutigen Anforderungen garnicht gerecht wird.>>Full ack. Für Windows-GUIs, DCOM/ORB-Programmierung usw ist C ziemlicher>Mist.
Und welche Programmiersprache ist für diese Dinge empfehlenswert?
Felix schrieb:> Und welche Programmiersprache ist für diese Dinge empfehlenswert?
Du bist hier in einem µC Forum, also kurz gesagt C und ASM.
Reden wir von PC Programmierung --> C++ , C# , Java , PIET(Joke) , .....
C++ ist nicht wirklich besser als C und Java wird eher wenig für
Windows-GUI/Desktop-Anwendugen benutzt.
> Du bist hier in einem µC Forum, also kurz gesagt C und ASM.
Ja und? Deswegen darf man sich trotzdem auf einen Beitrag beziehen, der
ein anderes Thema anspricht.
Thread beobachten
Seitenaufteilung abschalten