C befehle für anfänger

C-Befehle allgemein findet man auch in C-Büchern.
Sonst kann ich mich Ansgar anschliessen. In den Datenblättern zu
neueren Controllern sind in der Regel auch Code-Beispiele genannt.

Bei C hast du nur eine Handvoll Befehle. Ist nicht so wie bei Basic.
Statt Befehle verwendest du Funktionen. Du kannst Funktionen selbst
erstellen, aber auch fertige Funktionen aus Headerdateien nutzen.
z.B."#include <string.h>" für String-Bearbeitungs Funktionen(was du
bei der UART-Geschichte neulich sicher schon bemerkt hat)(wenn du der
selbe Stefan bist^^). Du arbeitest dann eh Hauptsächlich mit eigenen
Funktionen, die du in Abhängigkeit von irgendwelchen Bedingungen
ausführst. Ist zu Beginn ein wenig Gewöhnungsbedürftig am Ende aber
wesentlich logischer aufgebaut.

Es geht wohl eher um die AVR-spezifischen Makros.
Der Rest (bis auf die ISRs) ist ja Standard-C.
Die Interruptbehandlung und die ISR-Deklaration ist ja von Compiler zu
Compiler verschieden.

hallo
ich wollt fragen wie ich eine funktion erstellen kann in c um eine 
schleife zu erzeugen??

ich meien wenn ich ein rechenprogrammerstell und die rechnung fertig ist 
das das programm direckt wieder von vorne beginnt und ich eine neue 
rechnung beginnen kann


bitte bitte hilfe

Flolli

DANKE :D

Kannst Du Basic?

>Bei C hast du nur eine Handvoll Befehle. Ist nicht so wie bei Basic.
>Statt Befehle verwendest du Funktionen. Du kannst Funktionen selbst
>erstellen, aber auch fertige Funktionen aus Headerdateien nutzen.
>z.B."#include <string.h>" für String-Bearbeitungs Funktionen(was du
>bei der UART-Geschichte neulich sicher schon bemerkt hat)(wenn du der
>selbe Stefan bist^^). Du arbeitest dann eh Hauptsächlich mit eigenen
>Funktionen, die du in Abhängigkeit von irgendwelchen Bedingungen
>ausführst. Ist zu Beginn ein wenig Gewöhnungsbedürftig am Ende aber
>wesentlich logischer aufgebaut.

lautes Lach

>Ist zu Beginn ein wenig Gewöhnungsbedürftig am Ende aber
>wesentlich logischer aufgebaut.

lautes doppel Lach

Die Funktionen und Subs von Basic sind von hunderten Progs.
optimiert wurden. Wenn Du der Meinung bist es besser zu können,
dann mach so weiter!

Carsten

PS versuch Dich doch mal an der len Funktion um eine Stringlänge
zu ermitteln!

1

int my_strlen(char* str) {

2

  char *start = str;

3

  while (*str++);

4

  return str - start - 1;

5

}

Macht die Schleife sogar noch schneller.

Carsten:
>Die Funktionen und Subs von Basic sind von hunderten Progs.
>optimiert wurden. Wenn Du der Meinung bist es besser zu können,
>dann mach so weiter!

Guck dir erst mal die von C an... die werden sogar von vielen Leuten 
unabhängig voneinander optimiert und geprüft. Basic hat seine 
Berechtigung, aber deine Argumente ziehen nicht... offenbar haste selbst 
noch nicht den Unterschied zu C begriffen.

nicht das es mal auf unicode umgestellt werden soll.

int my_strlen(char* str) {
  char *start = str;
  while ( *str+=sizeof(char) );
  return str - start - 1;
}

sorry vergesst den letzen beitrag, so könnte es aber sicherer sein.


int my_strlen(char* str) {
  char *start = str;
  while (*str++);
  return (str - start - 1) / sizeof( char );
}

... dann tragt alles zusammen und macht ein richtig
    gutes Basic ...


Carsten :)

@ Peter

hab ich zu spät gelesen:

>int my_strlen(char* str) {
>  char *start = str;
>  while ( *str+=sizeof(char) );
>  return str - start - 1;

was ist denn wenn " " in der Mitte sitzt?

Findest Du das opt. gelöst?

Auch ganz gut zur Schnelleinführung und zum Nachschlagen;
http://openbook.galileocomputing.de/c_von_a_bis_z/

>Zudem ist C auch schöner anzusehen und man hat weniger Probleme ein
>Programm zu portieren wenn man mal auf eine andere Architektur umsteigt
>(PIC, ARM, PPC...)

na genau von AVR zu Quatcore 8086!

Peter wrote:
> int my_strlen(char* str) {
>   char *start = str;
>   while (*str++);
>   return (str - start - 1) / sizeof( char );
> }
Bringt uns nicht weiter, da char auch bei Unicode immer noch ein Byte 
lang ist. Außerden würde ich persönlich kein Unicode im Code benutzen, 
sondern lieber Breitzeichen, das hängt mit der Thematik zusammen:
Für Breitzeichen:

1

int my_strlen(wchar_t* str) {

2

  wchar_t *start = str;

3

  while (*str++);

4

  return (str - start) - 1;

5

}

Klappt 100%. Und für ASCII tuts das mit char stat wchar_t auch 100%. 
Problem bei Unicode ist, dass man in der Schleife für jedes Zeichen 
prüfen müsste, obs denn nun Multibyte ist (und dann natürlich die 
folgenden Bytes überspringen) oder halt nicht. Mit Breitzeichen umgeht 
man das elegant.

Carsten:
>>int my_strlen(char* str) {
>>  char *start = str;
>>  while ( *str+=sizeof(char) );
>>  return str - start - 1;
Erstmal: Der Code ist falsch. Ganz einfach deshalb, weil in der Schleife 
"1" (sizeof(char)) zu *str addiert wird und dann das Ergebnis davon 
überprüft wird. Siehe oben; Unicode löst man eleganter.

>was ist denn wenn " " in der Mitte sitzt?
Dann ist das total egal. C-Strings hören mit nem Nullbyte auf.

Findest Du das opt. gelöst?
Der Code da war falsch, ansonsten löst dein BASIC das auch nicht anders.

(t->d) sorry

Aber C++ ist auch auf einem ARM nicht zu Hause!
Oder geht jetzt schon Objektprog. auf einem ARM?

:) Carsten

www.cppreference.com

Aber Achtung - Seite auf Englisch :)
und nochmal Achtung - Es handelt sich um C++, welches bekanntlich nicht 
unterstützt wird von uC.

Grüße

Reuben

Gegenfrage

>Warum sollte C++ nicht auf dem ARM gehen? IMHO stellt das kein Problem
>dar.

Warum sollte Basic nicht gehen?

Carsten wrote:
> Gegenfrage
>
>>Warum sollte C++ nicht auf dem ARM gehen? IMHO stellt das kein Problem
>>dar.
>
> Warum sollte Basic nicht gehen?

Hast du schonmal ein Betriebssystem, also so ein richtiges wie MacOS, 
Linux oder Windows in Basic programmiert gesehen? Frag dich mal warum. 
BASIC geht auf nem ARM, logo, musst halt nur nen Compiler dafür finden.

>also so ein richtiges wie MacOS

Glaubenskrieg? :)

>Hast du schonmal ein Betriebssystem, also so ein richtiges wie MacOS,
>Linux oder Windows in Basic programmiert gesehen?

bist Du da sicher, dass alle diese OS, als C als Quelle vorliegen?

lautes Lach, Lach, Lach, Lach, Lach

>in Basic programmiert gesehen

Nein

"ich prog. immer erst die Henne damit Sie ein Ei legt."

Gegenfrage:

hast Du ein OS gesehen was in C geschrieben wurde?

>hast Du ein OS gesehen was in C geschrieben wurde?

Manche sind der Meinung, Unix sei kein OS (oder war es Windows)?

> hast Du ein OS gesehen was in C geschrieben wurde?

Linux, BSD und damit auch MacOS? Keine Ahnung in was Win geschrieben 
wurde, ist mir aber auch sehr egal :D

Setz doch selber einfach Bascom ein wenns dir gefällt, ich persönlich 
würds mir selber schon allein wegen der grauenhaften Syntax von Basic 
ganz sicher nicht antun aber denke das ist jedem selber überlassen...

Und zum flollis Frage: Mit ner while oder ner for-Schleife, aber mach am 
besten mal ein C-Tutorial durch damit du die Grundlagen kannst. goto 
verwendet eigentlich kein C-Programmierer der noch halbwegs bei Verstand 
ist würde ich sagen, ist in der Sprache auch irgendwie etwas fehl am 
Platz weshalb es normal vermieden wird.

>Und zum flollis Frage: Mit ner while oder ner for-Schleife,

.. Du bist ein "GROßER" Anhänger des Basic Dialektes

  For  Vari = anfang To ende Step -.5
    `das tut weh, wenn man in C sowas nicht formulieren kann (autsch)
    Exit For
  Next  Vari

  jetzt komm  mir bitte nicht mit, den unlogischen "==" in C

und Step -.5 ?

for(double i = anfang; i>ende; i-=.5)
   break;

^^

Zufrieden?

Nein

wo ist denn das Ende der Scheife?

sag jetzt nicht das, es ein nichts sagendes ";" ist!

Ich liebe Basic.

Carsten wrote:
> Nein
>
> wo ist denn das Ende der Scheife?
>
> sag jetzt nicht das, es ein nichts sagendes ";" ist!
>
> Ich liebe Basic.

C ist eindeutig definiert:

1

for (Start; Laufbedingung; Schritt) Anweisung

"Anweisung" kann "Blabla();" sein, oder ein ganzer Block "{...}". 
Einduetig definiert, wie gesagt.

Im Übrigen habe ich dein Getrolle mal gemeldet.

.. genau das meine ich

    "abartig"

  Schleifen-Ende ist ein "}"

}
 }
  }
}

               }
                                    []
}

@  Sven Pauli

wenn eine Meinung nicht passt, wird er gemeldet.

hochachtungsvoll
der Blockwart

Nö, gemeldet wird, wenn jemand sinnlose Beiträge bringt, die außer 
Provokation keinen Zweck erfüllen. Wegen mir kannst du dein Basic mit 
ins Grab nehmen. Aber dann nerv nicht andere mit irgendwelchem 
Halbwissen deinerseits.

>Aber dann nerv nicht andere mit irgendwelchem
>Aber dann nerv nicht andere mit irgendwelchem
>Halbwissen deinerseits deinerseits

Wenn Du 30 Jahre nachweisen könntest!

rechne mal ein 1/4 vom Halbwissen * 3/8
da muß der Taschenrechner ran.

Motzer!

Carsten, beschäftige dich zumindest mal mit den simpelsten C-Grundlagen. 
Es kommt nämlich sehr lächerlich rüber, wenn jemand an was anderem 
rummosert von dem er keine Ahnung hat. Vor allem hat Basic in dem Thread 
hier nichts zu suchen.
Wenn du dich mal mit mehr als Basic beschäftigen würdest wirst du 
schnell rausfinden, dass C wesentlich mehr kann aber evtl. für Anfänger 
nicht so schnell verständlich ist wie Basic, allerdings viel praktischer 
ist wenn mans mal kann, da es sowas wie ne einheitliche Syntax hat und 
keine unnützen Grenzen setzt.
Da hilfts auch nichts wenn du == für "unlogisch" erklärst, mag für dich 
so erscheinen aber ist in Wirklichkeit wesentlich logischer und hat 
einige Vorteile. Wüsstest du aber wenn du nen bisschen Ahnung von den 
Sachen hättest über die du dich hier beschwerst.
Also sei so nett und hör auf den Thread hier zuzumüllen...

P. S.: Warum zum Himmel sollte ich ein Anhänger von Basic sein? Fehlt 
nur noch, dass ich von dir zum begeisterten Windows-Nutzer ernannt werde 
oder so... Oo

Ich hab Carsten mal ne Seite gewidmet:
http://www.mikrocontroller.net/articles/Benutzer:Haku/F%C3%BCr:Carsten

Ansonsten empfehle ich für den Einstieg in AVR-C:
- Schmitt - Mikrocomputertechnik mit Controllern der Atmel 
AVR-RISC-Familie (Oldenbourg)

Ihr werdet doch nicht schon aufhören wollen?
Auf Jungs, weitermachen...

Von Elektor habe ich noch ein Buch "Von Basic nach C umsteigen"
von 1991. Mit 5 1/4 Diskette.

Sven Pauli wrote:

> Klappt 100%. Und für ASCII tuts das mit char stat wchar_t auch 100%.
> Problem bei Unicode ist, dass man in der Schleife für jedes Zeichen
> prüfen müsste, obs denn nun Multibyte ist (und dann natürlich die
> folgenden Bytes überspringen) oder halt nicht. Mit Breitzeichen umgeht
> man das elegant.

Was soll denn ein "Breitzeichen" sein? Wenn du damit UTF-16 machen 
willst: Pech gehabt, da musst du die surrogate pairs beruecksichtigen.

Peter Stegemann wrote:
> Sven Pauli wrote:
>
>> Klappt 100%. Und für ASCII tuts das mit char stat wchar_t auch 100%.
>> Problem bei Unicode ist, dass man in der Schleife für jedes Zeichen
>> prüfen müsste, obs denn nun Multibyte ist (und dann natürlich die
>> folgenden Bytes überspringen) oder halt nicht. Mit Breitzeichen umgeht
>> man das elegant.
>
> Was soll denn ein "Breitzeichen" sein? Wenn du damit UTF-16 machen
> willst: Pech gehabt, da musst du die surrogate pairs beruecksichtigen.

Schwachsinn is das. UTF8 wird byteweise eingelesen, wobei ein Byte halt 
nicht zwangsläufig einem Zeichen entspricht, es könnte nämlich ne 
Multibyte-Sequenz sein. Logischerweise ist das technisch Blödsinn, im 
Programm wirklich direkt UTF8, sprich Multibyte zu verarbeiten, weils 
die Leistung drastisch runterdrückt, wegen der ganzen Tests, die für 
jedes nochso einsamen "str++" nötig sind.

Breitzeichen ist das, was der C-Standard vor zehn Jahren festgelegt hat: 
wchar_t, ein 32bit breiter Integer. Beim Einlesen von Textdaten werden 
diese automatisch in Breitzeichen konvertiert. Ein Breitzeichen (sprich: 
ein wchar_t) nimmt in jedem Fall genau ein Zeichen auf, ob das 
ursprünglich aus UTF8, UTF16 oder ASCII stammt, ist wurscht. Nach der 
Verarbeitung kann der wchar_t-String dann wieder in ein gewünschtes 
Format zurückgewandelt werden (und wird dadurch sicherlich wieder 
kleiner, da viele Zeichen wieder durch ein Byte dargestellt werden).

http://www.gnu.org/software/libc/manual/html_node/Extended-Char-Intro.html

Die C-Bibliothek bietet dazu natürlich sämtliche String- und 
Zeichenfunktionen einmal für ASCII (strlen...) und einmal für 
Breitzeichen an (wcslen). Beim Lesen und Schreiben gilt gleiches 
(fgets... und fwgets..., bei letzterem werden mögliche Umschaltungen 
beim Multibyte-Kram automatisch berücksichtigt).

Vieleicht solltest du mal deinen eigenen Link lesen, statt dich mit 
schraegen Uebersetzungen ("Breitzeichen") zu beschaeftigen:

"Some Unix systems define wchar_t as a 16-bit type and thereby follow 
Unicode very strictly. This definition is perfectly fine with the 
standard, but it also means that to represent all characters from 
Unicode and ISO 10646 one has to use UTF-16 surrogate characters, which 
is in fact a multi-wide-character encoding. But resorting to 
multi-wide-character encoding contradicts the purpose of the wchar_t 
type."

Kurz: Neuer Standard, neues Chaos, keine echte Loesung...

ich hab mir mal die mühe gemacht und n projekt
sowohl in bascom als auch in c geschrieben.
gut, c ist nicht meine "muttersprache" aber ich wollt
halt mal sehn von wegen ausführungsgeschwindigkeit
größe der hex usw.

unterm strich herausgekommen ist folgendes,
die ausführungsgeschwindigkeit war annähernd gleich,
tendentiell bascom etwas langsamer, aber für die anwendung
reichte es noch gut aus.
Codegröße war auch ähnlich (printf hat da aber auch viel
dazu beigetragen) sonst währ c vermutlich etwas kleiner
gewesen.

nur mit der c-syntax bin ich nicht so recht warm geworden.
mitunter wirds bei c schon etwas kryptisch mit den >> << usw.

funktioniert haben beide sprachen und auch die compiler
und ob man nun

if a=b then

else

endif

oder
if (a=b){

} else {

}

schreibt schenkt sich meiner meinung nach nix.
wenn einer nicht strukturiert programmiert wirds in
beiden sprachen müll und wenn einer sein handwerk versteht
kann er in beiden sprachen viel realisieren.

also vertragt euch gefälligst

huch ... jetzt hab ich noch nen fehler in der syntax :o)

if (a==b){

} else {

}

so sollts nun gehn

Peter Stegemann wrote:
> Vieleicht solltest du mal deinen eigenen Link lesen, statt dich mit
> schraegen Uebersetzungen ("Breitzeichen") zu beschaeftigen:

Den Link habe ich gelesen, nicht zum ersten Mal. "Breitzeichen" ist die 
gängige Übersetzung (gefunden in "O'Reilly - Programmieren in C"). Und 
wchar_t zu benutzen ist das Mittel der Wahl um UTF&Co mit Standard-C zu 
erschlagen. Der Standard besagt:
>It only requires that this type is capable of storing all elements
>of the basic character set.
Damit ist die Sache eindeutig. Ob und warum das jetzt irgendein Unix 
anders sieht, ist mir jetzt grad wurscht.

Dass einige Unixe das wchar_t noch mit 16 Bit definieren, liegt dadran, 
dass es noch garnich so lange mehr als 65 Tausend Zeichen in Unicode 
gibt. Die QT-Bibliothek hat übrigens bis vor garnicht langer Zeit ihre 
Zeichen auch 16bit-breit behandelt und erst auf 32bit umgestellt, als 
wirklich mehr als 65 Tausend Zeichen in Unicode kodiert waren.

Sollte ich aus irgendwelchen Gründen mal so furchtbar portabel schreiben 
wollen, kann ich mir immer noch eine freie UTF-Bibliothek suchen, die 
32bit-breite Breitzeichen macht, um damit genauso zu verfahren, wie der 
C-Standard es mit den eigenen wchar_t's vorgesehen hat.

Falls dir das immer noch nicht hilft, ich hab mich persönlich hieran 
gehalten:
http://www.cl.cam.ac.uk/~mgk25/unicode.html

if (a==b)
{
  Falltüröffnen();
}
else
{
  Mikrocontroller_net_löschen();
}

so sollts nun gehn

Das dürfte Dich interessieren:

Eine Webseite, die anfangs mit absoluten Einsteigerniveau und einem für 
den Mikrocontrollereinstieg geschrumpften C-Kurs beginnt und dabei 
konsequent mit kostenloser Software arbeitet, ist:

http://www.mikrocontrollerspielwiese.de

Hier gibts für alle Experimente und Projekte den C-Code und
die Eagle-Dateien gleich zum Runterladen und den wohl am einfachsten 
Programmieradapter zum nachbauen.