Sprung aus Funktion zu Funktion ?

Philipp L. schrieb:
> praemabel();   <- Hier wird ja die Funktion "Zwischenbit" nie beendet ?

Nur, wenn die Funktion praemabel() eine Endlasschleife darstellt, wird 
sie nicht beendet. Ansonsten führt sie am Ende einen Rücksprung durch 
und landet in der nächsten Zeile nach ihrem Aufruf.

NB: Schreibt man das nicht praeambel()?
NB2: Bist du sicher, das du gleich mit einem DCC Dekoder anfangen 
willst? Mach doch erstmal was einfacheres.

Was ist eine "Praemabel"? Meintest du vielleicht "Praeambel"?
Ich würde sowas als Automat mit einer case-Struktur aufbauen, wobei du 
den case-pointer ja in deinen Unterfunktionen dann beliebig verändern 
kannst.

> NB2: Bist du sicher, das du gleich mit einem DCC Dekoder anfangen
> willst? Mach doch erstmal was einfacheres.

Jep, bin sicher :-)
Das Einlesen des ersten Bytes und dessen Adressauswertung funktioniert 
auch schon.
Muss jetzt nur noch die nächsten Bytes einlesen.

> Gebe Zwischenbit einen Rückgabewert. In der main() prüfst du den und
> rufst dementsprechend Einlesen2()

Das mit den Rückgabewerten habe ich zwar durchgelesen, aber es 
funktioniert noch nicht wirklich.
Hier mal ein Test mit einem festen Rückgabewert von 5

uint8_t Zwischenbit(void)
{
while (startcount == 0)
{
}
return 5;
}

Nach durchlaufen der Funktion müsste doch in "Zwischenbit" der Wert 5 
gespeichert sein.

Wenn ich dies aber in der Main prüfen möchte, erscheint der Fehler:
comparison between pointer and integer.

if (Zwischenbit == 5)
PORT_B1 = 1;
else
PORT_B1 = 0;

Kann ich also die Funktion Zwischenbit nicht als Wert abfragen?

Danke!!

Philipp L. schrieb:
> Kann ich also die Funktion Zwischenbit nicht als Wert abfragen?

Du solltest Dir mal Dein C-Buch zu Gemüte nehmen. Dir fehlen eklatante 
Grundlagen an sehr elementaren Stellen.

Wie wird in C eine Funktion aufgerufen? Wie sieht die Syntax dafür aus?


Ich halte es nicht für sinnvoll, Dir hier mit Detailkorrektoren 
"weiterzuhelfen", denn damit lernst Du die Dir fehlenden Grundlagen 
nicht, sondern kopierst nur munter weiter irgendwo gefundene 
Versatzstücke ohne Verständnis zusammen.

Das mag jetzt vielleicht unfreundlich und hart klingen, ist aber so.

> Du solltest Dir mal Dein C-Buch zu Gemüte nehmen.

Ist ständig neben dem Rechner und hilft mir an vielen Stellen weiter.

> if (Zwischenbit() == 5)
>     Einlesen2();

Danke!

Ich konnte auch mit Hilfe des Buches nicht herausfinden, dass ich eine 
Funktion auch innerhalb der If-Bedingung aufrufen kann.

>Dir fehlen eklatante Grundlagen an sehr elementaren Stellen.

Das ist korrekt und wird mir auch noch an anderen Stellen begegnen.
Dafür fange ich ja mit C erst an.
ich lerne aber lieber anhand von konkreten Projekten, innerhalb dessen 
ich dann verschiedene Themen erlerne.

z.B. hat es mich sehr gefreut, dass ich das Protokoll bis zum ersten 
Byte lesen kann und dies auch wunderbar funktioniert.

Natürlich habe ich nebenbei auch kleine Testprogramme, in denen ich 
bestimmte Grundlagen außerhalb des Hauptprojektes teste und dazu lerne.

> Man kann alle möglichen Dinge
> hinschreiben die den Anschein haben zu funktionieren, aber trotzdem
> falsch sind und früher oder später dann nicht mehr gehen. Wenn man nur
> mit Try&Error lernt, lernt man diese Dinge nicht.

Wie kann denn ein Anfänger sonst etwas lernen.
Ich teste Befehle anhand von kleinen Testprojekten.

Wenn es funktioniert und ich der Meinung bin es verstanden zu haben, 
dann kommt das nächste Thema dran.
Alle bis dahin verstanden Dinge werden verwendet.

Ich glaube in C würde ich es lassen, erzeugt dort wahrscheinlich mehr 
Probleme als es an Nutzen bringt.

In Assembler kannst Du jede Schweinerei machen, zu der der Controller 
fähig ist. Also wenn Du dem Controller sagst JMP von einer einer 
Funktion irgendwo hin, dann macht der das. Ob man es tatsächlich so 
machen sollte, auch mit Hinblick darauf, daß evtl. Teile des Codes in 
anderen späteren Projekten wiederverwendet werden könnten, finde ich 
aber auch fragwürdig. Also wenn keine Notwendigkeit besteht, auf einzig 
und allein diese Weise die letzten 20 Byte Flash zu bekommen die man 
noch braucht, dann würde ich es nicht machen.

Wir kommen hier mittels Text nicht weiter.
Das ist eine Grundsatzdiskussion, für die du mich kennen müsstest oder 
wir ein Gespräch führen müssten.

Es ist schön, hier immer gute Antworten zu bekommen.

Moin,

Theor schrieb:
> Wenn Du also mit Deiner Methode einigermaßen effizient lernen willst,

Theor schrieb:
> Du musst streng zwischen dem, was in dem
> Buch steht und Deinen Vermutungen darüber unterscheiden,

Theor schrieb:
> Kürzer und noch effizienter ist der Weg, ein Kapitel bzw. ein
> Unterkapitel zunächst vollständig zu erfassen und zu verstehen.
> Noch besser, der Weg, dann jeweils die Übungsaufgaben zu machen.

Und wo bleibt der Spassfaktor dabei? Ich nehm' hier mal stark an, dass 
es sich um hobbymaessiges programmierenlernen handelt und nicht darum, 
als Absolvent eines Informatikstudienganges mit Schwerpunkt 
Theaterwissenschaften/Politologie jetzt moeglichst schnell und effektiv 
Sicherheitssysteme fuer Atomraketenzuendsysteme programmieren zu 
muessen.

Ja, mir haben sich auch die Zehennaegel aufgerollt - aber hey - es ist 
noch kein Meister vom Himmel gefallen; natuerlich programmiert man 
ordentlichen Stuss am Anfang, und wenn man viel Glueck hat, wird der 
Stussanteil spaeter kleiner.

Philipp L. schrieb:
> Wie kann denn ein Anfänger sonst etwas lernen.
> Ich teste Befehle anhand von kleinen Testprojekten.
>
> Wenn es funktioniert und ich der Meinung bin es verstanden zu haben,
> dann kommt das nächste Thema dran.
> Alle bis dahin verstanden Dinge werden verwendet.

Passt. Weiter so!

Gruss
WK

Zum Ablauf des Programms - das hat nichts mit C zu tun - beschäftige 
dich mal mit Statemachines (zu Deutsch Zustandsautomaten). Damit regelt 
man das Lesen und Schreiben komplizierterer Protokolle.

Zu deiner Lern"methode": Versuch und Irrtum bringt nur sehr begrenzt 
etwas.  Besonders, wenn du dir darauf aufbauend deine Privat-Philosophie 
zu einer Programmiersprache zusammenreimst. Die Grundkonzepte lernen, 
die Details intensiv studieren funktioniert besser, als sich etwas 
zusammenzuträumen.

Das hat nichts mit C als Sprache zu tun. C ist auch nicht heimtückisch. 
C ist ziemlich simpel. Das als heimtückisch zu bezeichnen zeugt von 
einer gewissen Boshaftigkeit.

>> (Ruby,

Ruby (eine Hipster-Programmiersprache die sich auf dem absteigenden Ast 
befindet) unterstützt mehrere Programmierparadigmen. Viel Spaß die als 
Anfänger zu lernen und auszusortieren was man braucht.

>> Python

Eine der Hipster-Programmiersprachen schlechthin. Viel Spaß beim 
Abzählen von Whitespaces. Dazu eine chaotische Anzahl von Bibliotheken 
die zu 9o% sowieso nur schlecht dokumentierte Wrapper sind.

>> Java)

Verwendet im Kern immer noch eine C-Syntax. Kommt schon in der 
Standard-Edition mit einem API von über 4000 Klassen. Davon sollte man 
schon ein paar hundert kennen wenn man als Java-Programmierer durchgehen 
möchte.

Dr. Sommer schrieb:
>> Das hat nichts mit C als Sprache zu tun. C ist auch nicht heimtückisch.
>
> Dann erkläre doch mal kurz und verständlich, was die drei Bedeutungen
> des "*" sind :-)

Multiplikationsoperator:

1

a = 4 * 5;

Vier mal fünf.

Pointerdefinition/Deklaration:

1

int *p;

p ist ein Pointer auf int, also eine Variable, die auf eine andere 
Variable vom Typ int zeigt.

Hier ist p nicht initialisiert, d.h. p zeigt irgendwohin.

1

int a;

2

int *p = &p;

In diesem Beispiel wird p so initialisiert, daß es auf die Variable a 
zeigt.

Dereferenzierungsoperator:

1

int a = 4;

2

int b;

3

int *p = &a;

4

5

b = *p;

Hier wird der Pointer dereferenziert, d.h. der Wert bestimmt, auf den 
der Pointer zeigt.

Welcher Wert landet jetzt in b?


> Oder was "void (*fptr) (const volatile short*, void (*) (void), void*, int[]) 
bedeutet.

Das ist ein Funktionspointer, der auf eine Funktion mit der Signatur

1

void funktion(const volatile short*, void (*) (void), void*, int[])

verweist.

Der zweite Parameter der Funktion ist wiederum ein Funktionspointer auf 
eine Funktion mit der Signatur

1

void funktion(void)

Alle anderen Parameter der Funktion sind Pointer auf verschiedene 
Datentypen.

Die Funktion hat keinen Rückgabewert.


Anstelle des letzten Parameters könnte man genausgut int* schreiben, da 
das in diesem Kontext exakt dasselbe bedeutet.




> Oder was an if(a << 15) falsch ist.

Falsch ist es nicht, es macht nur selten das, was der Schreiber erwartet 
und das Verhalten hängt von den Umgebungsbedingungen ab.

> Oder wie man Fehlerbehandlung ohne
> Speicherlecks hinbekommt.

?


> Oder wie man Strings ohne Sicherheitslücken
> verarbeitet. ...

Indem man die richtigen Funktionen dafür verwendet, bzw. versteht, wo 
die Probleme liegen.

Moin,

Also bei so vielen Bedenkentraegern wundert's mich nicht, dass wir 
technologisch den Anschluss verloren haben.
Wenn ich C lerne, was kratzen mich denn am Anfang die droelfzehn 
Bedeutungen des "*"? Was kratzen mich wilde Funktionspointerkonstrukte? 
Das braucht kein Mensch am Anfang.
Wenn ich mir vorstelle, als ich vor ueber einem drittel Jahrhundert am 
ZX81 fast 24/7 am Werkeln war, da waere einer angekommen, der haette 
gefragt: "Oh - du programmierst den ja in BASIC - Wieviele 
Programmierparadigmen unterstuetzt das denn?" Und haette dann die Stirn 
in Sorgenfalten gelegt, ob meiner sicher unqualifizierten Antwort...
Bloss gut, dass es damals noch keine Internetforen gab und meine Eltern 
eher die Sorge hatten, dass das Kind auch mal 'nen Apfel ist und in der 
Schlule nicht noch schlechter wird.

Gruss
WK

Moin,

Dr. Sommer schrieb:
> Die meisten Leute fangen aber nicht nur an.

Da ich hier in diesem Thread schreibe, beziehe ich mich mehr auf den 
Threaderoeffner als auf "die meisten Leute".

Dr. Sommer schrieb:
> Die Logik verstehe ich nicht. Indem man nur die einfachste Technik
> verwendet und auf alles komplexere verzichtet behält man den
> technologischen Anschluss?

Ich meine es so, dass man am Anfang durchaus auch mit einfacher Technik 
und "spielerischem" Ansatz arbeiten sollte, und nicht gleich alles 
extrem verkopft angehen.

Gruss
WK

Philipp L. schrieb:
> Wenn eine Funktion durchlaufen wurde, erfolgt der Rücksprung in das
> Hauptprogramm und ruft dadurch die Funktion in der nächsten Zeile auf.

Korrekt.
Jede Funktion endet hinter ihrem Aufruf.

Philipp L. schrieb:
> Ich möchte die Funktion "Zwischenbit" nun entweder durchlaufen und
> dadurch in "Einlesen2" springen, oder es erfolgt ein Sprung innerhalb
> der Funktion "Zwischenbit" zurück in "praemabel".

Wo ist das Problem, einfach die Bedingung testen:

1

if (Bedingung)

2

  Einlesen2();

Wird die Bedingung in "Zwischenbit" generiert, kann man sie einfach als 
Returnwert übergeben:

1

int main(void)

2

{

3

// ...

4

if (Zwischenbit() == true)

5

  Einlesen2();

6

// ...

7

}

8

9

bool Zwischenbit(void)

10

{

11

// ...

12

if (Bedingung)

13

  return true;

14

return false;

15

}

Philipp L. schrieb:
> praemabel();   <- Hier wird ja die Funktion "Zwischenbit" nie beendet ?

Stimmt, es kommt zu einer Rekursion, bis der Stack überläuft.

Peter D. schrieb:
> Philipp L. schrieb:
>> praemabel();   <- Hier wird ja die Funktion "Zwischenbit" nie beendet ?
>
> Stimmt, es kommt zu einer Rekursion, bis der Stack überläuft.

Quatsch, sie wird natürlich nach "praemabel" beendet.
"praemabel" wird also zweimal ausgeführt.

Nur zur Info,

mir ist (und war von Anfang an) bewusst, dass meine Struktur und Ablauf 
für das Einlesen und die Auswertung des Protokolls bestimmt nicht dem 
bestmöglichen Code entspricht.

Aber darum geht es auch momentan noch nicht.

Ich möchte einfach nach und nach meinen Wissensstand erweitern und dies 
anhand von praktischen Projekten mit Spaß umsetzen.

wenn ich mir erst alle Möglichkeiten einer Programmiersprache aneignen 
soll, bevor ich dies an einem konkreten Projekt umsetze, macht das 
einfach keinen Spaß.

Ich habe einige Punkte auf dem Zettel, welche ich unbedingt noch lernen 
möchte und die meine Programme besser machen (z.B. Array`s)

Aber ich muss erstmal bisher gelerntes anwenden.

> Endliche Automaten sind gerade embedded und bei Protokoll-Sachen ein
> sehr nützliches und verbreitetes Konstrukt.

Jep, das werde ich machen.
Es gibt ganz viele tolle Sachen, welche ich mir auch noch ansehen werde.

PS:
Mein DCC Programm ist jetzt "fertig".
Es liest die Bytes nacheinander in Variablen ein.
Das ganze läuft super, wenn auch bestimmt nicht optimal programmiert.

Aber ich hatte Spaß und wieder etwas gelernt.

ich brauche 510 Bytes für die Protokollauswertung.

Philipp L. schrieb:
> Ich bin nur nicht sicher was passiert, wenn ich aus einer Funktion in
> eine andere Funktion Springe.

machbar ist das, aber du musst auch eine Ausstiegsstrategie haben, nicht 
das du eine Endlosschleife programmierst!

Statemachine wurde ja schon genannt!
Auch rekursive Aufrufe sind möglich bis der Stack am Ende ist!
also immer schön auf Überlauf prüfen.

leo schrieb:
>> Was ist denn dann 1<<15 auf einer Architektur mit 2er-Komplement, und
>> auf einer mit 1er-Komplement? Beides mal das Gleiche?
>
> Left shift schiebt 0 herein und ist eindeutig.

Das mit den Nullen stimmt, universell eindeutig ist es aber nicht.

1 << 15 ergibt ohne Beschränkung der Bits 32768. Dieser Wert ist in 
einem 16-Bit Typ nicht mit Vorzeichen darstellbar. Folglich ist diese 
Operation auf 16-Bit Maschinen undefiniert. Egal ob 2er Komplement, 
1er-Komplement oder sonstwie.

Hingegen ist x << 15 für vorzeichenloses x stets definiert.

zitter_ned_aso schrieb:
> Was bei 16 Bits folgenden Zahlenbereich ergibt:
>
> -32768 bis 32767

Zeit fürs Bettchen? Seit wann ist 32768 in diesem Bereich enthalten? In 
der Elektrik gibt es zwar die Regel "Rot ist Blau und Plus ist Minus" 
aber nicht in C.

Ok, besser formuliert: "Dieser Wert ist in einem 16-Bit Typ mit 
Vorzeichen nicht darstellbar."

zitter_ned_aso schrieb:
> aber 1<<15 liefert doch die kleinste 16-Bit Zahl (Zweierkomplement)

Mathematisch gesehen kann bei x << y und positivem x nie ein negatives 
Ergebnis rauskommen. Also erst unbeschränkt rechnen, dann ins Format zu 
quetschen versuchen. So denkt C. Im Sinn von C wird auch ein 
ausschliesslich inkrementierter positiver Wert bei vorzeichenbehafteter 
Rechnung nie negativ. Auf der Maschine vielleicht schon, aber das 
zählt nicht. Es kann auch eine Exception geben und die Maschine darf 
dich ohrfeigen.

"The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated 
bits are filled with zeros. [...] If E1 has a signed type and 
nonnegative value, and E1 × 2 E2 is representable in the result type, 
then that is the resulting value; otherwise, the behavior is undefined."

leo schrieb:
> Du wuerfelst hier {1.2}-Komplement und Left-shift einfach durcheinander.
> Mit 32bit Integern:

1 << 15 ist auf einer Maschine mit 16-Bit "int" Typ undefiniert, es sei 
denn sie codiert Integers in umgedrehtem Zweierkomplement 
(-32767..32768).

A. K. schrieb:
> universell eindeutig ist es aber nicht

Deutlicher: Es gibt C Plattformen, auf denen 1 << 15 nicht eindeutig 
ist. Dass es auch Plattformen gibt, bei denen es eindeutig ist, ändert 
daran nichts.

leo schrieb:
> Wir sprachen hier von C.

Ich auch. Ich beschrieb die Art, wie der C Standard denkt (ich bin mit 
damit leidlich vertraut). Du hingegen denkst nicht in C, sondern in 
"Maschine".

leo schrieb:
> Ich bitte um einen C-Compiler + Plattform als Beispiel.

Es geht mir um den C Standard, nicht um reale Compiler. Ein offiziell 
als undefiniert festgelegtes Verhalten wird nicht dadurch definierter, 
dass bei realen Compilern ein nachvollziehbares Ergebnis rauskommt.

Mir sind auch keine Compiler bekannt, bei denen bei einem Rechtsshift 
etwas anderes als das Vorzeichen reingeschoben wird. Trotzdem ist das im 
Standard undefiniert.

In irgendeinem YouTube-Video habe ich mal gehört, dass so um 1970 mal 
eine Architektur gab, die das Einerkomplement genutzt hat.

Heiko L. schrieb:
> In irgendeinem YouTube-Video habe ich mal gehört, dass so um 1970 mal
> eine Architektur gab, die das Einerkomplement genutzt hat.

Beispielsweise die CDC 6600 und Nachfolger. Seymour Cray war anfangs ein 
Fan davon, warum auch immer.

Ansonsten: "Ones-complement arithmetic: it lives!"
http://esr.ibiblio.org/?p=7413

A. K. schrieb:
> Heiko L. schrieb:
>> In irgendeinem YouTube-Video habe ich mal gehört, dass so um 1970 mal
>> eine Architektur gab, die das Einerkomplement genutzt hat.
>
> Beispielsweise die CDC 6600 und Nachfolger. Seymour Cray war anfangs ein
> Fan davon, warum auch immer.
>
> Ansonsten: "Ones-complement arithmetic: it lives!"
> http://esr.ibiblio.org/?p=7413

Na, das dürfte einen Performance-Hit geben, wenn das Zweierkomplement 
per Standard festgesetzt wird. Aber wer OS2200 für irgendeinen "COBOL 
Compatibility Layer" laufen hat kann bestimmt auch ein paar 
Programmierer bezahlen, die einen entsprechenden Switch in den Compiler 
einbauen.

zitter_ned_aso schrieb:
> Also gilt
> a << #bits == a * 2^(#bits)
> hier auch nicht?

Das kann auch noch interessanter werden, weil besagte CDC 6600 meistens 
mit 60 Bits rechnete, nicht aber wenn sie multiplizieren und dividieren 
sollte. Das machte sie nämlich nur mit 48 Bits, in der entsprechenden 
Fliesskomma-Einheit in Mantissenbreite.

Ob es für diese jemals einen C Compiler gegeben hat weiss ich nicht. Da 
allerdings der Wirth'sche Pascal Referenzcompiler als grösste Integer 
2^48-1 definierte, wird im Handbuch vorsorglich erwähnt, dass es auch 
grössere Integers als die grösste geben kann.

Shift-Operationen im 1er Komplement oder sign/magnitude erklären auch, 
weshalb im Shifts im C Standard auf negative Werte undefiniert sind.

NB: Wer mal einen TCP/IP Stack implementiert hat, dem wird eine 
Einerkomplement-Addition begegnet sein. In der Checksum-Berechnung.

Ja, und, also? "Das Phantom lebt"?