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
>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!
flolli wrote:
> hallo> ich wollt fragen wie ich eine funktion erstellen kann in c um eine> schleife zu erzeugen??> Flolli
3 Möglichkeiten:
1) die einfachere: nimm ein GOTO
2) die konsequentere: kauf dir das Buch "Programmieren in C" von K&R,
lies es gründlich durch und handle nach den Regeln,
die dort beschrieben sind.
3) die alternative: programmiere Basic und minmm Möglichkeit 1)
@ Carsten:
> :> lautes Lach>> Ist zu Beginn ein wenig Gewöhnungsbedürftig am Ende aber>> wesentlich logischer aufgebaut.> lautes doppel Lach
Das interessiert keinen mehr.
Der Originalpost ist 1/2 Jahr alt.
flolli wrote:
> 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
Du willst also direkt mit der Nase in die Lösung reingetunkt werden?
Dann schau mal in das Example-Verzeichnis Deiner Compilerinstallation,
jedes Main enthält dort die sogenannte Main-Loop.
Bzw. schau überhaupt mal in ein C-Grundlagenbuch oder Tutorial.
Peter
@Lothar Miller
>int my_strlen(char* str)>{> int cnt;> if(!str) return 0;> for(i=0; *str; str++, i++);> return i;>}
Das haut wohl nicht hin! (cnt, i)
Und wieso so kompliziert?
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 );
}
Carsten wrote:
> Die Funktionen und Subs von Basic sind von hunderten Progs.> optimiert wurden.
Ja, da kann C wohl nicht mithalten, die Bibliotheken werden dort nur von
über 100.000-en Profis optimiert.
> Wenn Du der Meinung bist es besser zu können,> dann mach so weiter!
Wenn ich mal den Debounce-Befehl von Bascom nehme, dann kann ich das
wesentlich effizienter mit meiner Routine machen.
Viele der in Bascom integrierten Funktionen helfen zwar die ersten
Schritte zu machen, hindern einen aber, sobald das Programm etwas
komplexer wird.
Z.B. wenn eine Funktion einen Timer belegt, kann man diesen nicht mehr
für andere Sachen benutzen.
Programmiert man den Timer dagegen selber, kann ein Timer z.B. PWM,
Input Capture, Display-Multiplex, Tastenentprellen und RTC zusammen
machen ohne Probleme.
Peter
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...)
@ 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?
>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!
Quatcore 8086! => Du meinst wohl QuadCore
Und zudem sagte ich auch ARM und PPC nur als beispiel, nix von x86 und
selbst wenn ist auch da Bascom nicht zu Hause.
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
intmy_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.
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
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.
>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?
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
Kauf dir ein C Buch oder les dir etwas dazu im Internet durch.
Das "Ende" der Schleife gibt es hier nicht. "break" wird bei jedem
Schleifendurchlauf ausgeführt (oder auch nicht. Was soll das für einen
Sinn machen?).
1
for(doublei=anfang;i>ende;i-=.5)
2
break;
Wenn du mehr als einen Befehl ausführen willst, musst du einen neuen
Block öffnen:
1
for(doublei=anfang;i>ende;i-=.5)
2
{
3
Blabla();
4
Function();
5
foo();
6
}
Basic ist hier um einiges schlimmer, meiner Meinung nach.
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.
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
Ja, C würde mich wirklich auch brennend interessieren...
So als stümperhafter Basic-Programmierer ;)
Ne wirklich, grosse Familie, 8h Arbeit und Techniker-Abendschule, wo
soll ich die Zeit hernehmen auchnoch C zu lernen.
So bastel ich eben mit Bascom herum bis es geht (früher Pascal und
qBasic programmiert als Hobby)
Aber wenn mir jemand ein wirklich gutes C-Tut anbieten kann, welches
mich nicht gleich 4h kostet bis ich die ersten 5 Zeilen verstanden habe,
wäre ich auch zufrieden :)
Anselm
p.S.:Optimaler Weise ein direkter Vergleich der auch noch gut
kommentiert ist
Basic-Programm -> Umsetzung in C
Mit vergleichen und "learning by doing" gehts wohl am einfachsten
Anselm 68 wrote:
> p.S.:Optimaler Weise ein direkter Vergleich der auch noch gut> kommentiert ist> Basic-Programm -> Umsetzung in C> Mit vergleichen und "learning by doing" gehts wohl am einfachsten
Eine andere Programmiersprache ist nicht nur eine andere Syntax.
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
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
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.