mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bit setzen in C


Autor: Hans (Gast)
Datum:

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

: Gesperrt durch Moderator
Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, ein Compiler ist selten effektiv.

Autor: let (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich dachte es mir schon: Wenn das keine Steilvorlage ist ;)

Autor: gast (Gast)
Datum:

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

Autor: Der fünfte Ludolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du auf schnelle Art und Weise Bits Toggeln willst, dann versuche 
die entsprechenden Routinen mittels Assemblerbefehlen in C einzubinden.

Autor: Dirk Hofmann (arm-dran)
Datum:

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

Autor: Dirk Hofmann (arm-dran)
Datum:

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

Autor: Rahul Der trollige (rahul)
Datum:

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

Autor: Der fünfte Ludolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ...C sei sogar schneller als ASM?

In der Fertigstellung des Programmes stimmt diese Aussage, aber nicht in 
der Ausführungsgeschwindigkeit des compilierten Programmes.

Autor: Uhu Uhuhu (uhu)
Datum:

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

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hans,

so gehts:

#define DATA            P3_5

DATA = 1;
DATA = 0;


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;

Autor: Dirk Hofmann (arm-dran)
Datum:

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

Autor: Dirk Hofmann (arm-dran)
Datum:

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

Autor: Joe (Gast)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: let (Gast)
Datum:

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

Autor: Joe (Gast)
Datum:

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

Autor: Dirk Hofmann (arm-dran)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk,

warum schreibst Du Deinen Mist hier nicht in Assembler? Hochdeutsch ist 
doch viel zu ineffizient für Deine revolutionären Einfälle.

Autor: Dirk Hofmann (arm-dran)
Datum:

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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Viele Köche verderben nun mal den Brei.

Und wenn der einzige Koch tot ist macht die Küche Pleite?

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wozu eigentlich einen Assembler, wo man doch mit dem Hex-Editor dasselbe 
erreichen kann?

Autor: Joe (Gast)
Datum:

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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann war John von Neumann wenigstens nicht so ein Weichei, wie 
Dirk...

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Na dann war John von Neumann wenigstens nicht so ein Weichei, wie Dirk...

Heute machts wieder Spaß, guter Kommentar ;-))

Autor: Dirk Hofmann (arm-dran)
Datum:

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

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

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

Autor: A.K. (Gast)
Datum:

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

Autor: Joe (Gast)
Datum:

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

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die AVR's gibts nen netten Workarround:

Beitrag "sbit macro für avr-gcc"

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas, ich habs eigentlich 2x erklärt, Hans muß es nur noch verwenden 
;-)) ließt du nicht mehr ?

Autor: Der fünfte Ludolf (Gast)
Datum:

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





Autor: Dirk Hofmann (arm-dran)
Datum:

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

Autor: Uhu Uhuhu (uhu)
Datum:

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

Autor: Rahul Der trollige (rahul)
Datum:

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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: Dirk Hofmann (arm-dran)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An ihren Taten sollt Ihr Sie messen,

.
.
.
.

und Sie taten nichts

außer ..............

siehe oben!!!!


Viele Grüße


Der Troll

Autor: Dirk Hofmann (arm-dran)
Datum:

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

Autor: Patrick Dohmen (oldbug) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt's eigentlich bald nen Button zum Sperren von Nicks?

SCNR

Autor: let (Gast)
Datum:

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

Autor: Sepp (Gast)
Datum:

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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: Dirk Hofmann (arm-dran)
Datum:

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

Autor: Josef (Gast)
Datum:

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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: Joe (Gast)
Datum:

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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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

Autor: let (Gast)
Datum:

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

Autor: Joe (Gast)
Datum:

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

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nu sag ich nix mehr ;-))
Macht ja nichts, inzwischen geht es ja auch um die Vorgabe einer 
sinnvolle Grösse für Maustreiber.... ;-)

Autor: X. H. (shadow0815)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
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:
sbit P3_5 = P3^5;

P3_5 = 1;

Peter

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter, Joe hat das nicht geschrieben, er hats erklärt ;-))

Autor: Felix (Gast)
Datum:

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

Autor: Jean Player (Gast)
Datum:

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

Autor: Felix (Gast)
Datum:

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

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.