Forum: Mikrocontroller und Digitale Elektronik Arbeiten mit Registern(STM32F103)

Und wie geht es dann mit Pointer in Pascal?

memcpy,arbeitet aber auch mit Zeigern

in Pascal move(a^, b^, size).

Tilo P. schrieb:
> Und wie geht es dann mit Pointer in Pascal?

STM32F103 und Pascal? Tu dir einen Gefallen und lerne was vernünftiges. 
In Pascal scheinst du ja sowieso nicht so bewandert zu sein, sonst 
würdest du die Frage nicht stellen. Also, wenn die Ausgangsbasis nahe 0 
liegt, lerne C oder simple C++ oder noch simpler C++ in Form der Arduino 
Api.
Libs für die verschiedensten Dinge, die auf github zu tausenden liegen, 
findest du nach meinem Gefühl: 80% Arduino 19.9% C/C++ und 0.1% irgend 
was anderes.
Oder du erfindest das Rad neu. Wird bestimmt eins mit Ecken, weil das 
die Welt noch nicht kennt

Zur absoluten Adressierung von Variablen gibt es einen Thread auf 
*stackoverflow*:

https://stackoverflow.com/questions/4067811/how-to-place-a-variable-at-a-given-absolute-address-in-memory-with-gcc

Der Direktzugriff auf Register geht am besten mit Fortran.

"Tu dir einen Gefallen und lerne was vernünftiges. "
danke für diesen Tollen Tipp.
Sorry, aber das ist keine Antwort auf meine Frage

@ Domian (Gast)14.10.2021 08:39
Danke, schaue ich mir gleich mal an

@ Anarchist (Gast)
Was für Probleme hast du?

Also Leute,

schwätzt doch nicht so herum, sondern gebt ein Beispiel.
ich zumindest tue das hier mal:

1

#define RCC_APB2RSTR (*((volatile dword *) (RCC + 0x0C)))

Das ist ein kleiner Auszug aus stm32f103.h und hier wird das Register 
APB2RSTR des RCC Peripheriecores deklariert, so daß man von einem C 
Programm auf dieses Register ganz einfach zugreifen kann.

So etwa geht das in C und wenn es einen guten Pascal-Compiler für die 
Cortex Controller gäbe (ja, WENN), dann hieße das vermutlich
RCC_APB2RSTR: dword; absolute RCC+$0C;

Ist aber nicht, da es keinen Compiler dafür gibt. Das ist die Realität 
und es ist recht egal, wie wir das nun finden.

W.S.

@ W.S. (Gast)14.10.2021 10:03
Danke, werde ich nachher mal Testen.
Es gibt mehrere Pascal Compiler, werden teils sogar Kommerziell 
eingesetzt

@Dann solltest du die Finger von Mikrocontrollern lassen.
Danke für diese schlaue Antwort,.

Ehrlich Leute, das ist die dritte Antwort dieser Art.
Was stimmt mit euch nicht?
Seit ihr auch die, wenn man von Windows redet, die mit Linux anfangen?!
Wird man so, wenn man viel Linux benutzt oder ist man vorher schon so?

Ich habe noch nie Pointer beim Controller unter Pascal benötigt und mich 
daher nie damit beschäftigt

Tilo P. schrieb:
> Wenn ich z.B. die Seriennummer eines STM32F103 auslesen möchte

Beim Original kannst du die Seriennummer nicht so auslesen (wegen einem 
Bug). Wenn du da eine Nummer vorfindest, dann hast du einen gefälschten 
Chip.

Moin, -

einmal google liefert (unter anderem):

https://wiki.freepascal.org/ARM_Embedded_Tutorial_-_Entry_FPC_and_STM32

Der Programmierer braucht dabei keine Pointer (latuernich macht das 
schon der Compiler, aber wenn schon sinnlose Requests dazupackt. But I 
digress... ).

Es gibt auch noch https://www.mikroe.com/mikropascal-arm

Pascal ist offensichtlich nicht tot. Kennt jemand einen COBOL-Compiler 
fuer ARM? Auch bei FORTRAN wird es eng.

Gruesse

Th.

unter FreePascal:

1

const

2

  Base = 0x1FFF F7E8

3

  Offset = 2;

4

var

5

  EinRegister: uInt16 absolute (Base + Offset);

6

begin

7

  WriteLn(EinRegister);

8

9

end;

Nachtrag:
Error: fehlender Strichpunkt hinter 'Base = 0x1FFF F7E8'

:)

Stefan ⛄ F. (stefanus): (wegen einem Bug) -> Deutsch: (wegen eines Bugs)

@ Maxe (Gast)14.10.2021 12:08
Danke, so etwas habe ich gesucht:-)

Thomas W. schrieb:
> Pascal ist offensichtlich nicht tot.

Nein, ist es nicht. Aber hier wie auch in anderen Kreisen möchte man 
lieber mit C sich befassen. Die Gründe dafür sind zumeist 
nichttechnischer Art, sollten hier also lieber nicht diskutiert werden 
müssen.

Das Zeug von Mikroe ist eigentümlich, es ist irgendwie ein halbes C und 
per schlecht oder gar undokumentierter Steuerdateien nur für von Mikroe 
ausgesuchte Chips geeignet.

Und der Port von Freepascal ist - wimre - nur für Linux gedacht.

W.S.

Oder als Record verpackt:

1

Type TCPUID = record

2

  lw1,

3

  lw2,

4

  lw3: uInt32;

5

end;

6

7

var

8

  CPUID: TCPUID absolute(0x1FFF F7E8);

9

begin

10

  WriteLn(CPUID.lw1);

11

12

end;

W.S. schrieb:
> Und der Port von Freepascal ist - wimre - nur für Linux gedacht.

Nein, auch für ohne OS.
FreePascal gibt es übrigens auch für den AVR.

"Beim Original kannst du die Seriennummer nicht so auslesen (wegen einem
Bug). "

Die reinste Katastrophe:-( Da will man "einfache" Aufgaben als Anfänger 
lösen und scheitern dann an solchen Bugs:-(


"Nein, ist es nicht. Aber hier wie auch in anderen Kreisen möchte man
lieber mit C sich befassen. Die Gründe dafür sind zumeist
nichttechnischer Art, sollten hier also lieber nicht diskutiert werden
müssen."


Da ich aber auf dem PC sowieso mit Pascal arbeite...
Aber richtig erkannt, diese Diskussion gehört hier nicht hin.


Und richtig, Freepascal und ARM geht auch ohne Linux


Linux ist übrigens auf dem Desktop sowas wie Pascal, beide haben nur 1% 
Marktanteil;-)

NOCH viel witziger, eine MENGE Linux Programme sind in PASCALÖ 
geschrieben, nur wissen das viele nicht mal.
Das kommt daher, das mit Lazarus eine komfortrable Oberfläche bereit 
steht, da es unter Linux kein MS Visuall C++ gibt

untersützte CPUs von Freepascal / Lazarus Pascal
https://wiki.lazarus.freepascal.org/Platform_defines

bessere Übersicht
https://wiki.freepascal.org/Platform_list

Hans-Georg L. schrieb:
> Bist du dir sicher ?

Bin ich, weil das schon x mal im Rahmen der fake vs original Erkennung 
diskutiert wurde.

> Ich hatte mir im Debugger das schon angeschaut.

Das ist der Punkt. Der Debugger kann die Seriennummer auslesen, das 
Programm nicht. Auf STM32F103, wohlgemerkt. Nur der hat den Bug.

Tilo P schrieb:
> Sorry, aber das ist keine Antwort auf meine Frage

Trotzdem ist es der beste Rat den du bekommen kannst.

Klaus W. schrieb:
> stefanus war natürlich wieder schneller...

Aber du warst schneller, aus dem Errata zu dokumentieren. Ich hatte 
gerade (woanders) nach einer Bestätigung von ST gesucht und nicht 
gefunden.

Übrigens ist das moderne Pascal, kein C Mischmasch. Es ist lediglich das 
aktuelle Pascal.

So wie C sich weiterentwickelt hat, seit den 80er Jahren, ist das auch 
mit Basic und Pascal und anderen Sprachen passiert

Man muss sich nur mal etwas umschauen und nicht nur in seiner Bubble 
leben;-)


Und klar hat auch C eine Vorteile(z.B. die größere Verbreitung und 
dadurch mehr Sourcen) aber auch Pascal hat seine Vorteile, und wenn es 
nur die wäre, das ich es mag und immer schon nutze:-)


Ab Turbo Pascal 6 oder 7, sollte kaum jemand was daran auszusetzen 
haben.
Ganz abgesehen von den aktuellen Varianten

"Pascal ist sowas von tot. Und für die Controllerprogrammierung war es
noch nie lebendig."

ja, wie Linux, wenn du es so sagst ;-) und den Marktanteil vergleichst, 
und bei Linux ist es sogar rückläufig so wie es die letzten Jahre 
aussieht

Also wen du sagst, Pascal ist tot, ist es Linux offenbar auch, siehst du 
das so? hmm...nun gut

Im übrigen programmiert ein Deutscher Hersteller von Gasthermen seine 
Geräte in Pascal...aber wenn du glaubst das es Tot ist..dann muss da ja 
was dran sein ;-)

Tilo P schrieb:
> Und klar hat auch C eine Vorteile(z.B. die größere Verbreitung und
> dadurch mehr Sourcen) aber auch Pascal hat seine Vorteile, und wenn es
> nur die wäre, das ich es mag und immer schon nutze:-)

Sorry, das bezweifle ich. Wenn du es immer schön nutzen würdest auf 
einem Controller, würdest du die blöde Frage ganz oben nie gestellt 
haben.

Tilo P schrieb:
> Man muss sich nur mal etwas umschauen und nicht nur in seiner Bubble
> leben;-)

Da kannst du dich umsehen wohin du willst. Pascal findet man im Cortex-M 
Umfeld nur mit dem Microsscope und es ist auch nicht so dass sich da was 
entwickeln würde.

Kann natürlich sein dass sich dein Schwanz etwas länger anfühlt von der 
Überzeugung der einzig wahre Held zu sein der Pascal auf kleinen 
Controllern macht. Dann macht das für dich Sinn und alles ist gut.

"Aber gut; man kann sich natürlich die größte Sch**ße schönreden."

Jepp, so machen es die Linuxer ja immer.
Jetzt ist das Thema, auch langsam mal gut.
Es hat nichts mehr mit dem Einstiegsthema zu tun.
Du nutzt weiter dein Linux das niemanden interessiert und ich mein 
Nischen Pascal und bin ebenfalls sehr glücklich damit:-)

"Sorry, das bezweifle ich. Wenn du es immer schön nutzen würdest auf
einem Controller, würdest du die blöde Frage ganz oben nie gestellt
haben."
ähm, ich habe vielleicht, im Gegensatz zu dir noch anderen Hobbys und 
eine  Familie?!
Nein, programmieren ist bei mir Mittel zum Zweck und ich erhebe nicht 
den Anspruch gut darin zu sein das ist aber auch gar nicht mein Ziel..
Wenn es dein Lebensziel darstellt, ist es doch gut, freut mich für dich.

"Da kannst du dich umsehen wohin du willst. Pascal findet man im 
Cortex-M
Umfeld nur mit dem Microsscope und es ist auch nicht so dass sich da was
entwickeln würde.

Ja, sehr verbreitet ist es nicht erst recht nicht im Vergleich zu C, 
aber du würdest staunen welches Deiner Lieblingsprogramme in Pascal 
geschrieben ist;-)

Und nein, es ist mir eigentlich egal, aber ich nutze es immer schon und 
habe keine Lust mich in C einzuarbeiten.
Aber offenbar hast du ganz andere Probleme wenn du solche Vergleiche 
heranzeihst.
Ich denke das Thema ist jetzt langsam verbrannt.
Ich bedanke mich für die wenigen hilfreichen Beiträge, die restlichen 
üblichen Verdächtigen Clowns, naja,  dafür ist dieses Forum ja 
hinlänglich bekannt...

"Da kannst du dich umsehen wohin du willst. Pascal findet man im 
Cortex-M
Umfeld nur mit dem Microsscope und es ist auch nicht so dass sich da was
entwickeln würde."

Ist übrigens falsch, derzeit steigt die Zahl der Benutzer durch Arduino 
und RasPi sogar an

Tilo P schrieb:
> Ist übrigens falsch, derzeit steigt die Zahl der Benutzer durch Arduino
> und RasPi sogar an

Was hat Arduino mit Pascal zu tun?

Weil dadurch offenbar merkwürdigerweise immer mehr Freepascal entdecken. 
So beobachte ich es im Freepascal Forum

Es sind immer mehr dort, die sagen das sie von der Arduino Soft weg 
wollen,  nur etwas C können und lieber zu Freepascal wollen

Ich habe das aber nicht aktiv weiter verfolgt. Stelle es immer nur fest, 
wenn ich dort ins Forum im Embedded Bereich reinschaue

schön ist auch, wie dir Pascal Community zusammenarbeitet.
Im Gegensatz zu allen gängigen Free C Compilern, wo man sich alle von 
zig Seiten und Projekten zusammensuchen muss bis man mal anfangen kann,
bündeln sich hier alle und arbeiten zusammen
Man kann sich auch sein ganz individuellen Compiler zusammenstellen wenn 
man es umfangreich will, oder eben einfach die eine Installationsdatei 
direkt herunterladen

Thomas Z. schrieb:
> Das Auslesen
> geht zumindest mit meinen BluePill Boards. Und da sind Originale von STM
> drauf.

Dun hast eindeutig gefälschte Chips bekommen. Gerade bei dem Board 
stehen die Chancen auf Fälschungen seit 2 Jahren bei 100 Prozent.

> Kann ich u. A. auch daran erkennen, dass die vollen 128k Flash
> ansprechbar sind.

Das heißt nichts, die Fälschungen haben ebenfalls 128k.

Horst G. schrieb:
> Na, DANN ist ja alles gut!

Nanana.
Allerdings sehe ich, daß Embarcadero trotz der exorbitanten Preise für 
sein Zeugs noch immer lebt. Es muß also einen durchaus finanzkräftigen 
Markt dafür geben. Und mal abgesehen davon halte ich eine Vielfalt nicht 
nur bei der Hardware für gut, sondern das gleiche gilt auch für 
Software.

Und nochwas: gar mancher wäre erstaunt, wieviele Geräte noch so 
existieren, bei denen die Firmware auf BASCOM basiert.

W.S.

viel witziger finde ich, das die "Experten" hier meinten, das es ja 
eigentlich ohne Pointer gar nicht ginge.
Ich denke daran sieht man, wie versaut einige durch C sind.
Klar haben Pointer Vorteile und sicher auch in diesem Fall die richtige 
Entscheidung, aber das viele schon gar nicht mehr ohne umgehen können, 
spricht auch Bände...


Generell werde ich dieses Rumgehacke auf andere Programmiersprachen von 
der C Leuten nie verstehen...ist das der gleiche Schlag wie die Linuxer?

Merkwürdige Menschen, wirklich.

Windows hat ebenfalls seine Vorteile.
Nur nerven die User nicht so rum

Witzig ist, wenn es bei Linux Diskussionen hitzig, wird,melden die 
Linuxer es gleich, das Beiträge gelöscht werden.
Den Windows Leuten ist das ziemliche egal, und lassen nichts löschen.

Auch das spricht Bände....

Etwas Weitblick und Toleranz täte einigen hier gut und weniger Bubble

Tilo P schrieb:
> Ich denke daran sieht man, wie versaut einige durch C sind.

Er wollte auf Register Zugreifen, die an bestimmten Adressen liegen. 
Adressen sind Pointer. Im Maschinencode wird nirgendwo zwischen 
Adressen und Pointern unterschieden. Das ist ein und das Selbe.

Klaus hatte schon recht als er schrieb:

Klaus W. schrieb:
> Diese Adresse ist ein - pointer.

Tilo P schrieb:
> Witzig ist, wenn es bei Linux Diskussionen hitzig, wird,melden die
> Linuxer es gleich, das Beiträge gelöscht werden.

Woher glaubst du das zu wissen? Phantasie, würde ich mal sagen.

> Den Windows Leuten ist das ziemliche egal, und lassen nichts löschen.

Auch das kannst du nicht wissen.

> Auch das spricht Bände....

Ja gut, wenn man sich ausdenkt, wie bestimmte Leute denken könnten und 
denen dann eine gedachte Gruppe gegenüber stellt die genau umgekehrt 
denkt, dann denkt man ... das man sich was gedacht hat. Oder wie jetzt?

> Etwas Weitblick und Toleranz täte einigen hier gut

Weniger Denken in Schubladen und mehr Fakten statt Phantasie täte dir 
gut.

das weiß ich, weil ich teilweise von den Moderatoren darauf hingewiesen 
wurde...
Hat mit Schubladen nichts zu tun.
Ist ja nun auch Wurscht

"Klaus hatte schon recht als er schrieb:"

Ok, dann hatte ich das anders interpretiert
Also das man es ohne den Umgang mit Pointer nicht könnte..und mit 
Records ist es, wenn auch auf Maschinenseite das selbe, im Code doch 
kein direktes Arbeiten mit diesen:-)

Tilo P schrieb:

> Ich habe noch nie Pointer beim Controller unter Pascal benötigt und mich
> daher nie damit beschäftigt

Dann hast du niemals ernsthaft programmiert. Hart, aber so sieht's aus.

Nunja, irgendwann muss man halt damit anfangen. So kompliziert ist das 
nicht (egal ob Pascal oder C). Am besten lernen kann man das Konzept 
allerdings, wenn man Assembler kann. Der entzaubert die Magie der 
Zeiger. Man kann direkt sehen, was da passiert.

Das Problem der "Hochsprachen" ist nämlich, dass sie das Konzept der 
"Variablen" erfunden haben. Und das ist eigentlich die größte Verarsche 
aller Zeiten. Tatsächlich handelt es sich nämlich bei jeder gewöhnlichen 
Variablen bereits um einen "Zeiger". Die Sprache bemüht sich nur, diesen 
Sachverhalt vor ihrem Benutzer zu verstecken. Damit kommt aber der 
unbedarfte Benutzer zu einem komplett falschen Denkmuster, was es ihm 
schwer macht, später das Zeigerkonzept zu verstehen.

Da musst du durch! Das ist nicht so schwer. Millionen andere haben es 
auch geschafft.

c-hater schrieb:
> So kompliziert ist das nicht ...

Es kommt selten vor, aber dieses mal stimme ich dem gesamten Beitrag von 
c-hater voll zu. Recht hat er.

Thomas Z. schrieb:
> Ich glaube du verwechselst den ID Code mit der UUID.
> Der ID Code kann tatsächlich bei den Original STMs nicht gelesen werden.
> Die UUID aka Seriennummer ist davon nicht betroffen.

Stimmt. Ich habe inzwischen nochmal das Testprogramm auf einem 
originalen Board laufen lassen:

1

[08:09:02:129] Serial = ff53:066b:7549:4948:5843:6717␍␊

2

[08:09:02:132] Flash Size  = 64kB␍␊

3

[08:09:02:134] Device ID = 0x0000␍␊

4

[08:09:02:136] Revision  = 0x0000␍␊

Tilo P schrieb:
> Ich denke daran sieht man, wie versaut einige durch C sind.

nanana. Also andere Programmiersprachen haben auch ihre Pointer, bloß 
sieht man die nicht so offensichtlich.
Denke mal an:

1

 procedure Ottokar(var Karlheinz: longint)

2

 oder

3

 procedure Ottokar(var Karlheinz)

Natürlich stecken da Zeiger auf die eigentliche Variable drin, in der 
ersten Zeile obendrein noch die Typinformation.

Ich würde auch nicht 'versaut' sagen. Bei C geht es an sehr vielen 
Stellen unlogisch zu, weswegen C nicht einfach logisch verstanden werden 
kann, sondern erlernt werden muß. Und da heißt es oft "Das ist hier eben 
so, basta!" Das muß man irgendwie verinnerlichen ohne es hinterfragen zu 
können. Und deshalb haben sich die C Leute mit Mühe eben dieses logische 
Hinterfragen an vielen Stellen abgewöhnt, was dich zu der Einschätzung 
'versaut' führt.

Natürlich hat so etwas seine Folgen, zumeist dahingehend, daß vieles 
nicht erklärt werden kann und deshalb entweder abgelehnt oder ohne zu 
fragen akzeptiert werden muß. So etwas prägt dann auch den Umgangs-Stil 
von Linuxern.

W.S.

Stefan ⛄ F. schrieb:
> Er wollte auf Register Zugreifen, die an bestimmten Adressen liegen.
> Adressen sind Pointer.

Nö, das sind zwei verschiedene Paar Schuhe.
Eine Adresse ist eine Adresse.
Ein Pointer ist eine Variable, die nicht einen Rechenwert enthält, 
sondern eine Adresse.
Das Blöde an der Verklemmtheit von C (bzw. deren 'Gestalter') ist, daß 
sie zwar sowas wie 'typedef' als Schlüsselwort eingeführt haben und auch 
'static', aber sich zieren wie die Zicke am Strick, für all die 
Anwendungen, wo die Lokalisierung einer Variable (wie z.B. ein 
HW-Register) feststeht, sowas wie das in Pascal mittlerweile geläufige 
'absolute' auch in C einzuführen.

Da man trotzdem den dringenden Bedarf hat, solche Register auch zu 
lesen/schreiben, haben sich findige C-Programmierer solche Ungetüme wie:

1

#define GPIOA_BSRR  (*((volatile dword *) (GPIOA + 0x10)))

einfallen lassen. Sowas ist eigentlich ein heftiger Murks, ohne den es 
aber in C nicht geht. Und das alles nur, weil uneinsichtige Leute in der 
C Fraktion den echten Fortschritt verhindern.

Und so scheint es dann den Leuten wie dir, daß Adressen gleich Pointern 
sind usw.
Nein, Pointer sind keine Adressen, genauso wie die Pappschachtel kein 
Keks ist, bloß die Gewöhnung an C läßt dich das gleichziehen.

W.S.

Axel S. schrieb:
> Sie tun das deshalb nicht, weil sie es nicht brauchen.

Nun ja, man könnte dazu sagen, daß es Mikrocontroller erst NACH C zu 
geben angefangen haben. Von da her haben K+R sowas noch nicht gekannt. 
Aber das ist Historie und heutzutage brauchen wir sowas eigentlich bei 
jedem µC, den wir mit Benutzung von C programmieren. Es geht ja auch mit 
obigem Konstrukt, aber schön oder gut oder sauber ist etwas anderes.

Ich ordne das alles unter 'rückwärtsgewandt und verkalkt' ein. Aber das 
alles ist mir nicht so wichtig.

W.S.

Ich denke auch, dass C nicht für Mikrocontroller gedacht war. Mir 
scheint, dass 16 Bit Computer mit Betriebssystem die Basis waren.

Warum C dann auf Mikrocontrollern zum Platzhirsch wurde obwohl es 
durchaus bessere Alternativen gab, ist mir ein Rätsel. Aber so ist es 
halt. Man kann das Spiel mit spielen, ein anderes Spiel spielen, oder 
sich ein Leben lang daran aufreiben. Was ist wohl besser?

Stefan ⛄ F. schrieb:
> Warum C dann auf Mikrocontrollern zum Platzhirsch wurde obwohl es
> durchaus bessere Alternativen gab, ist mir ein Rätsel.

Ist kein Rätsel, sondern etwas außertechnisches, was wir aber um den 
lieben Frieden hier zu wahren, in diesem Thread nicht diskutieren 
sollten.

Und mal abgesehen davon: es ist zwar an vielen Stellen unelegant bis 
rumpelig, aber man kann C auch für Mikrocontroller benutzen. Wenn es für 
die Controller, die ich benutze, einen ordentlichen Pascal-Compiler 
gäbe, würde auch ich darauf umschwenken. Ist aber nicht in Sicht, also 
lassen wir das Heulen.

W.S.

W.S. schrieb:
> Wenn es für
> die Controller, die ich benutze, einen ordentlichen Pascal-Compiler
> gäbe, würde auch ich darauf umschwenken.

Welche Controller sind das?

Stefan ⛄ F. schrieb:

> Er wollte auf Register Zugreifen, die an bestimmten Adressen liegen.
> Adressen sind Pointer. Im Maschinencode wird nirgendwo zwischen
> Adressen und Pointern unterschieden. Das ist ein und das Selbe.

Das ist nicht ganz richtig. Adresse ist leider nicht immer gleich 
Adresse, auch wenn der numerische Wert übereinstimmt.

Es gibt da nämlich oft verschiedene Adressbereiche. Worauf ggf. 
natürlich auch der Maschinencode Rücksicht nehmen muss. Und das betrifft 
nicht nur Harvard-Style µC, sondern durchaus auch Von-Neumann-Maschinen. 
Siehe z.B. den IO-Bereich der x86.

Nur in der völlig stumpfsinnig idealisierten C-Welt ist das alles eine 
Soße und Abweichungen von diesem Ideal müssen mit enormem deklarativen 
Aufwand (und/oder Rückgriff auf Asm) kompensiert werden.

c-hater schrieb:
> Das ist nicht ganz richtig. Adresse ist leider nicht immer gleich
> Adresse,...

Ähem, nicht nur dieses. Ich hatte ja schon geschrieben, daß eine 
Pappschachel nicht gleich dem darin liegenden Keks ist. Oder mit anderen 
Worten: Eine Adresse ist nicht gleich einem Register/einer Variablen, 
wenngleich dort auch der numerische Wert einer Adresse drin sein kann.

W.S.

p.s. die Sache mit der Pappschachtel stammt von Ernie aus der 
Sesamstraße und sie war leer, weil das Krümelmonster vorbei gekommen war 
und den Keks gefuttert hatte.

c-hater schrieb:
> idealisierten C-Welt

Die "Idealisierung" schafft zudem viele zusätzliche, künstliche 
Problemstellungen. Arbeitet Asm nur mit dem was ist und versucht die 
Anwendungsproblem-Lösung 1:1 in Code zu implementieren schaffen C und 
höhere Sprachen viele neue Konstrukte auf einer höheren Ebene, die 
wiederum mit sich und fehlerfrei agieren müssen. So ein künstliches 
Konstrukt sind z.B Datentypen, so eine künstliche sich daraus ergebende 
Problemstellung sind etwa CAST Typüberführungen. Das ist zusätzliche 
Gedankenarbeit, die mit dem eigentlichen Anwendungsproblem bzw. seiner 
Lösung im Code herzlich wenig zu tun hat.

c-hater schrieb:
> Es gibt da nämlich oft verschiedene Adressbereiche.

Ja ist wie Hausnummern. Ich wohne in der 12 aber ohne Straße wirst du 
mich nur schwerlich finden.

> Nur in der völlig stumpfsinnig idealisierten
> C-Welt ist das alles eine Soße

Was wohl daran liegt, das C für Computer gemacht wurde, in denen alle in 
einem einzigen Adressraum liegt. Wenn wir jetzt aufzählen, warum C nicht 
mehr Zeitgemäß ist, kommen wir auf eine ziemlich lange Liste. Denn ist C 
noch der Platzhirsch, daran können wir alle nichts ändern.

Robin schrieb:
> Die "Idealisierung" schafft zudem viele zusätzliche, künstliche
> Problemstellungen.

Man kann das nicht an einer einzigen Programmiersprache festmachen. 
Stattdessen ist es eigentlich immer so, daß die Paradigmen einer 
maschinenunabhängigen Programiersprache nicht komplett und reibungslos 
auf eine reale Hardware abgebildet werden können. Daher gibt es immer 
Reibungsstellen. Mal weniger mal mehr.

W.S.

> Man kann das nicht an einer einzigen Programmiersprache festmachen.

Yes

Problematische finde ich Bibliotheken, welche die Funktionen von vielen 
anderen bündeln und "vereinfachen".

Ich weiß nicht wie viele es davon in C gibt. In Java sind sie zu einer 
Pest geworden. Es würde mich mal interessieren, ob das für euch in C 
ebenso relevant ist.

"Nimm mich, und du kannst viel schneller entwickeln. Ich kann alles was 
du brauchst und jemals brauchen wirst, und das alles mit nur 10 Zeilen 
Code."

So ungefähr ist der O-Ton ihrer Werbung. Bei mir kommt es oft vor, dass 
ein Projektleiter oder gar der GF (beide keine Programmierer) die 
Nutzung einer konkreten Bibliothek vorschlagen, weil sie scheinbar 
(fast) alles kann, was das Projekt erfordert. Es ist schwierig dagegen 
zu argumentieren, solange man diese Bibliothek noch nicht gut kennt.

Das Problem ist: All diese Bibliotheken sind schlecht dokumentiert. Sie 
setzen voraus, dass man mit den Protokollen und den (lock bis zu 100) 
Basis Bibliotheken auf die sie aufbauen bereits vertraut ist. Wenn das 
so wäre, bräuchte ich den Wrapper nicht. Sie erscheinen nur deswegen 
einfach, weil sie viele konfigurierbare Parameter mit Standardwerten 
belegen oder einfach weg lassen. Immer wieder fehlt mir z.B. die 
Möglichkeit, Timeouts für Kommunikation einstellen zu können. Oder 
spezifische HTTP Header die das System des Kunden zusätzlich zum 
jeweiligen Standard voraus setzt. Auch schön: Wenn man mehr als einen DB 
User braucht, um auf alle Tabellen eines Schemas zuzugreifen.

Wenn man später genug schlechte Erfahrung gesammelt hat, ist es oft zu 
spät solche wrapper-Libraries wieder zu entfernen weil bereits das 
gesamte Programm strukturell daran gebunden ist und neue Programme meist 
als wesentliche Teile aus alten Programmen "übernehmen" sollen. 
Schließlich bekommt man Aufträge, weil man bereits vieles von dem 
gemacht hat, was der Kunde braucht, also quasi sofort etwas vorzeigbares 
liefern kann.

Stefan ⛄ F. schrieb:
> Problematische finde ich Bibliotheken, welche die Funktionen von vielen
> anderen bündeln und "vereinfachen". ... noch viel weiterer Text
Alles richtig und geanau aus diesem Grund predigen einige User hier im 
Forum, speziell die die den jeweiligen µC richtig verstanden haben, 
möglichst auf die Bibliotheken des Herstellers zu verzichten und sich 
was eigenes zu schreiben. Das ist in aller Regel kürzer und 
übersichtlicher. Der Preis dafür ist halt, das man sich mit Teil 
intensiver befassen muß. So eine Blibliothek macht es halt einfacher und 
führt auch meist schneller zu gewünschten Ergebnis, allerdings bleibt 
dann das Verständis für den µC meist auf der Strecke (Arduino ist dafür 
ein prägnantes Beispiel).
Nun sollte man letztere auch nicht verteufeln, kommt halt immer darauf 
an was man will und wo die Reise am Ende hin gehen soll.

schön das ich ja mit meinem Eingangspost dann doch nicht so ganz falsch 
lag.
Nur bin ich natürlich nicht argumentationsfest.
Daher hatte ich es mal so hingenommem

Rolf M. schrieb:
> Welche gab es denn, die in ihrer damaligen Form auch gut dafür geeignet
> waren?

Damals gab es keine.

Rolf M. schrieb:
> C ist eigentlich weitestgehend sehr logisch aufgebaut.

Nö. Das sieht man schon an der allereinfachsten Stelle: dem 
Zuweisungsoperator. Wie mathematisch ungebildet muß man eigentlich sein, 
um ausgerechnet das Gleichheitszeichen dafür zu benutzen, so daß man für 
Vergleiche nix anderes tun kann, als zwei Gleichheitszeichen 
hinzuschreiben? Und wenn das mit den C-artigen 
Programmiersprachen-Entwicklungen so weiter geht, dann erwarte ich 
irgendwann einmal Vergleiche mit 10 Gleichheitszeichen.

Und das alles für eine Schriftsprache, die auch für Berechnungen, also 
mathematisches Zeug geeignet sein soll? Wenn C nur für den Zweck 
erfunden wäre, um die Schleifen an dem neuen Kleidchen der Barby-Puppe 
zu beschreiben, dann wäre das ja läßlich. Aber SO nicht!

Wohlgemerkt, das mit dem '=' ist nur ein einziges kleines Detail, die 
Sprache C steckt voll von solchen Bolzen, die da im Entwurf geschossen 
wurden.

Und du bezeichnest das als 'weitestgehend sehr logich'.
Kopfschüttel.

W.S.

Rolf M. schrieb:
> Welche gab es denn, die in ihrer damaligen Form auch gut dafür geeignet
> waren?

PL/M gab (gibt?) es noch, zumindest für die µProzessoren Intel 
MCS-51/85/86

1

DCL BUF_ADR PTR;

2

DCL BUF BASED BUF_ADR (1) BYTE;

3

4

IF STATUS = 0

5

THEN DO;

6

 CALL PRINT(@('O.K.     ',0));

7

END;

8

ELSE DO;

9

 CALL PRINT(@(ESC,'[5m',ESC,'[7m',0));

10

 CALL MOVB(@('        ',0),@BUFFER,9);

11

 CALL BYTE_ASCII(STATUS,@BUFFER(2));

12

 CALL PRINT (@BUFFER);

13

 CALL PRINT (@(ESC,'[0m',0));

14

END;

aber nein, das möchte ich heute wahrlich nicht mehr...

Klaus W. schrieb:
> Extra für dich...

Ach nö. Ich komme auch so mit C zurecht, sehe aber zugleich dessen 
Kehrseiten. Viele andere offenbar nicht. Die glauben, daß mit dem 
Auswendiglernen einer Programmiersprache die logischen Probleme 
beseitigt seien und bemerken dabei nicht, daß sie sich lediglich in 
ihrer logischen Denkfähigkeit selbst an C angepaßt haben.

Das merkt man dann an solchen Stellen, wo menschliches Denkvermögen 
benötigt wird.

Bitte mal erinnern: die Maschine soll dem Menschen dienen und nicht 
umgekehrt.

W.S.

Stefan ⛄ F. schrieb:
> "Nimm mich, und du kannst viel schneller entwickeln. Ich kann alles was
> du brauchst und jemals brauchen wirst, und das alles mit nur 10 Zeilen
> Code."
>
> So ungefähr ist der O-Ton ihrer Werbung.

Dazu fällt mir die Begeisterung von Yalu in einem anderen derzeitigen 
Thread ein, wo er schreibt, daß es jetzt für Python eine neue (und 
VIEL bessere) Variante der switch-case Anweisung gibt.

Ich sag dazu bloß eines: einem jeden Programmierer seine persönliche 
Programmiersprache - und wir haben ein neues Babylon.

W.S.

@Frank M. (ukw) (Moderator) Benutzerseite18.10.2021 10:35
Ich weise darauf hin...

Wen auch immer das stört...eine lächerliche Regelung die niemand erst 
nimmt.
eher ist schon alleine dieser Hinweis mehr störend als wenn hier jemand 
mit 5 Namen schreiben würde

Mich interessiert besonders der Beitrags-Inhalt. Welche Namen da drüber 
stehen eher weniger. Schon gar nicht, um davon die Bewertung des Inhalts 
abzuleiten.

W.S. schrieb:
> bemerken dabei nicht, daß sie sich lediglich in ihrer logischen
> Denkfähigkeit selbst an C angepaßt haben.

Ein gewisses Maß an Anpassung wird immer nötig sein. Nichts ist perfekt. 
Wer das partout nicht glauben mag ist aufgefordert, es selber perfekt zu 
kreieren- und wird es schließlich dabei lernen.

Micha schrieb:
> Ein gewisses Maß an Anpassung wird immer nötig sein.

Nö. Die Kenntnis von sowas ist zwar nötig, um es zu benutzen, aber sich 
dran anpassen nicht.

Und unvermittelt sind wir hier mal wieder in einer fruchtlosen 
Grundsatz-Diskussion. Um mal auf das Thema zurückzukommen: Mit einer 
passenden Header-Datei, wo der Kram drinsteht, den man braucht, um auf 
die HW-Register des STM32F103 zugreifen zu können, ist das Thema 
gegessen. Funktioniert, wenngleich schön und gut gemacht auch was 
anderes ist.

W.S.

"Mich interessiert besonders der Beitrags-Inhalt."

Genau so siehts es aus. Ob hier jemand Selbstgespräche 
führt,interessiert niemanden und ich auch nicht prüfbar.
Bis auf paar wenig Spinner, achtet doch niemand überhaupt darauf wer was 
schreibt.
Das ist eher jedes mal ein Grund für Streitdiskussionen...mir selber 
passiert es oft, wenn ich an verschiedenen Geräten schreibe.

Manipuliert wird dann sowieso, und das macht die Person dann 
geschickter+, da kann der Mod auch nichts sehen
Also ich bleibe bei meiner Aussage lächerlich

"Welche Regel der Logik wird dadurch verletzt?"

echt jetzt??! Jetzt wirds wieder Spitzfindig-oder?!
Es ist doch wohl für alle klar was gemeint ist

Tilo P. schrieb:
> Bis auf paar wenig Spinner, achtet doch niemand überhaupt darauf
> wer was schreibt.

Warum bezeichnest du diese anderen Leute als Spinner?

Sind wir wieder so weit, dass wir andere Menschen nicht mehr 
respektieren können bloß weil sie anders sind?

Smartphone in der Tasche, aber Mittelalter im Kopf.

Rolf M. schrieb:
> Das gleiche könnte man dann aber auch über Pascal sagen. Dort wird das =
> für den Vergleich verwendet. Das = der Mathematik ist aber weder eine
> Zuweisung, noch eine Prüfung auf Gleichheit.

Das Gleichheitszeichen wird dort für exakt DAS verwendet, wofür es 
auch in der Mathematik steht. Zum Ausdrücken von Gleichheit - was dann 
zu Gleichungen führt und nicht zu Ergibtanweisungen. Deine Ausführungen 
zeigen mir deutlich, daß du unter Logik etwas anderes verstehst, als der 
Rest der Menschheit.

Rolf M. schrieb:
> Ich habe das Gefühl, dass du unter "logisch" was anderes verstehst als
> ich.

In diesem Punkte stimme ich dir völlig zu. Siehe oben. Das ist genz 
offensichtlich ein gewaltiges Problem, denn als Mathematiker kann man 
trotz gemeinsamer Wörter mit einem C Programmierer nicht wirklich reden, 
weil ein jeder etwas ganz anderes darunter versteht als der andere.

Mir kommt da ein Sketch von Monty Python in den Sinn: Ein ausländischer 
Tourist und ein englischer Tabakwaren-Verkäufer wollen miteinander 
reden, weil der Tourist nach dem Weg gefragt hatte. Dabei benutzten 
beide ihr jeweiliges Wörterbuch, aber offenbar war in der jeweiligen 
Übersetzung immer ein Knack drin, die Verständigung ging in die Irre, 
weswegen sie sich schlußendlich geprügelt haben.

So offenbar auch hier.

W.S.

Tilo P. schrieb:
> lächerlich

Das wirkt nur so weil tatsächlich andere Dinge dahinterstecken die man 
hier nicht aussprechen darf.

Stefan ⛄ F. schrieb:
> Warum bezeichnest du diese anderen Leute als Spinner?
> Sind wir wieder so weit, dass wir andere Menschen nicht mehr
> respektieren können bloß weil sie anders sind?

Ich denke er bezieht sich auf

Frank M. schrieb:
> Besonders schräg wird es dann, wenn diese drei Leute dann noch mit sich
> selbst reden

Rolf M. schrieb:
> Es wird zum prüfen auf Gleichheit verwendet.

Ach nö, laß mal. Du verstehst es eben nicht, weil du in C denkst. Das 
Gleichheitszeichen ist das Zeichen für Gleichheit auf beiden Seiten 
desselben.

Wenn da etwas geprüft werden soll, dann ob die Aussage richtig oder 
falsch ist. Das macht man mit einem Beweis und nicht mit einem 
Gleichheitszeichen.

Du verwechselst mal wieder die Pappschachtel mit dem Keks.

Aber was hat das alles mit der Verwendung des Gleichheitszeichens als 
Zuweisungsoperator zu tun? Oder mit anderen Korken dieser Art?

W.S.

wie logisch ist dann '===' und was sagt der Mathematiker dazu? :)

Rolf M. schrieb:

> W.S. schrieb:

>> Das Gleichheitszeichen wird dort für exakt DAS verwendet, wofür es
>> auch in der Mathematik steht. Zum Ausdrücken von Gleichheit
>
> Nein, eben nicht. Es wird zum prüfen auf Gleichheit verwendet. Das
> Ergebnis ist die Information, ob Gleichheit besteht oder nicht. In der
> Mathematik ist das dagegen einfach die Aussage, dass Gleichheit besteht.

Ach? Und wo ist jetzt der Unterschied?

Natürlich wird auch in der Mathematik das Gleichheitszeichen im Sinne 
einer Prüfung verwendet, z.B. bei der Formulierung von Beweisansätzen. 
Und das Ergebnis des Beweises ist dann eben entweder die Bestätigung, 
dass das "=" im Ansatz zu Recht verwendet wurde oder eben nicht.

Du machst dich einigermaßen lächerlich mit deiner vehementen 
Verteidigung dieses offensichtlichen C-Dummfugs!

Der darüber hinaus NACHWEISLICH für Unmassen Programmierfehler 
verantwortlich ist und darüber hinaus NACHWEISLICH auch bei Leuten die 
C durchaus beherrschen und denen die korrekte Verwendung der Operatoren 
im Prinzip vollkommen klar ist, die einfach nur einen Typo gemacht 
haben.

Sprich: Das Problem ist hier ganz eindeutig und fern jeden Zweifels die 
Sprachdefinition selber! Die ist nicht menschenfreundlich!

In Pascal könnte dem Auge eines Fehlersuchenden ein versehentliches "if 
a:=b" keinesfalls entgehen (weil schon der Compiler an der Stelle einen 
Fehler melden würde). C? Sieh' die endlosen Wüsten des realen Drecks, 
den versehentliche "Vergleiche" mittels "=" in den letzten 60 Jahre 
produziert haben. Ich würde mal darauf tippen, dass das in die 
Milliarden geht.

Und das nur, weil die Sprachdefinition einfach Scheiße ist. Weil C 
einfach in vieler Hinsicht Scheiße ist.

c-hater schrieb:
> In Pascal könnte dem Auge eines Fehlersuchenden ein versehentliches "if
> a:=b" keinesfalls entgehen (weil schon der Compiler an der Stelle einen
> Fehler melden würde). C? Sieh' die endlosen Wüsten des realen Drecks,
> den versehentliche "Vergleiche" mittels "=" in den letzten 60 Jahre
> produziert haben. Ich würde mal darauf tippen, dass das in die
> Milliarden geht.
>
> Und das nur, weil die Sprachdefinition einfach Scheiße ist. Weil C
> einfach in vieler Hinsicht Scheiße ist.

Komisch nur, dass ohne C nicht ein einziger der ganzen Ergüsse hier je 
das Licht der Welt erblickt hätten. Und noch komischer ist, daß die 
ganzen tollen anderen Sprachen zum Übersetzen einen C/C++ Compiler 
brauchen. Scheiße hin oder her, es gibt halt auch den Fall wo die 
Millionen Fliegen nicht irren und nur der Igel, der in der Klobürste das 
einzig wahre erkennt, der Depp ist.

Ich hätte nicht im Ansatz gedacht, dass der c-hater noch W.S. 
unterbieten kann was das Niveau angeht!

"tollen anderen Sprachen zum Übersetzen einen C/C++ Compiler
brauchen"

au Backe, was für ein Unsinn

temp schrieb:
> Komisch nur, dass ohne C nicht ein einziger der ganzen Ergüsse hier je
> das Licht der Welt erblickt hätten.

Nanana... wenn man an dieser Stelle den Satz mit den Milliarden Fliegen 
heranzieht, ist das Niveau dieses Threads damit ins Bodenlose gesunken.

Also: Einigen wir uns doch drauf, daß die Erfinder von C eigentlich nur 
BCPL verbessern wollten, dabei aber das Ganze nicht überschaut hatten, 
genau so wie der Klempner, der eine Ingenieursarbeit machen will, ohne 
ein passendes Studium im Kreuz. Das Ergebnis C ist deshalb ein Sack voll 
workarounds geworden, die notwendig wurden aufgrund der logischen 
Nebeneffekte vorheriger workarounds. Ich schrieb es ja bereits: C kann 
man sich nicht durch Logik erschließen, sondern muß es lernen, eben 
wegen der vielen 'ordre de mufti' in seiner Definition. Und die 
Verwendung des "=" als Zuweisung zieht natürlich einen workaround "==" 
für Vergleiche nach sich. Wer dieses als Logik begreift... bittesehr. 
Jedem Tierchen sein Pläsierchen.

W.S.

... schrieb:
> Ich hätte nicht im Ansatz gedacht, dass der c-hater noch W.S.
> unterbieten kann was das Niveau angeht!

Vielleicht übt er für eine Rolle. Bald tritt er damit im Comedy Club 
auf.

W.S. schrieb:
> dabei aber das Ganze nicht überschaut hatten,
> genau so wie der Klempner

Man sollte auch bedenken, auf was für Computern der Compiler damals 
laufen können sollte. Speicher und CPU Leistung waren im Vergleich zu 
heute sehr begrenzt.

Stefan ⛄ F. schrieb:
> Man sollte auch bedenken, auf was für Computern der Compiler damals
> laufen können sollte. Speicher und CPU Leistung waren im Vergleich zu
> heute sehr begrenzt.

Das stimmt gar sehr. Ebenfalls war damals das mögliche Potential zur 
Optimierung durch den Compiler weitaus geringer als heute.

Aber: Das hat mit einem nur wenig durchdachten Sprachentwurf nichts zu 
tun. Wirth hat es ja mit seinem Ur-Pascal vorgemacht: Das war weitaus 
logischer konstruiert als C. Allerdings hatte es außer einem einfachen 
Interpreter damals keinerlei Ausführungsplattform, war ja zuerst nur als 
Lehr-Sprache auf Basis von Algol60 gedacht. Borland kam da erst später 
dazu und hatte im Rückblick aus heutiger Sicht eine ähnlich wichtige 
Rolle wie bei C das damalige ANSI-Kollegium. Denke mal an die 
ursprünglicher K&R Notation. Mit der war auch schon damals kein 
Blumenpott zu gewinnen, Bedeutung erhielt C erst durch die von ANSI 
eingeführten Korrekturen.

W.S.

W.S. schrieb:
> Nanana... wenn man an dieser Stelle den Satz mit den Milliarden Fliegen
> heranzieht, ist das Niveau dieses Threads damit ins Bodenlose gesunken.

Eigentlich erst seitdem du hier postest!

Klaus W. schrieb:
> Wer für alles auf der Welt Assembler propagiert, redet von Realität?

Ob man zu Fuß geht oder den SUV benützt, hängt von den jeweiligen 
Umständen ab. Für ganz kleine Plattformen ist Assembler noch immer das 
sinnvollste Mittel - die Programm-Logik in einem 32 Bit Controller 
schreibt man hingegen eher mit einer 'höheren' Programmiersprache.

Es ist also immer ganz falsch, nur eine Seite als alleinig sinnvoll zu 
sehen. Die näheren Umstände legen das eine oder das andere (oder ein 
Gemisch aus beiden) nahe.

W.S.

@Cyclops
"
Was denkst du, in was ist dein Pascal Compiler geschrieben?"


Na, was denkst du? Googel doch einfach mal, ist doch sonst so ein 
beliebter Tipp von dir.
Pack dir mal an deine eigene Nase

und nein, es ist nicht in C geschrieben auch nicht in ++

ich helfe dir mal, ich traue dir nicht zu das du es schaffst..
https://en.wikipedia.org/wiki/Free_Pascal

Das mit Assembler ist auf jeden Fall ein Argument das nicht von der Hand 
zu weisen ist.
Ich werde mir jedenfalls auch mal ASM Beispiele dazu ansehen

Tilo B. schrieb:
> Ich werde mir jedenfalls auch mal ASM Beispiele dazu ansehen

Dir ist aber hoffentlich klar, daß sowohl die Notation als auch die 
Mnemonics plattformabhängig sind? Assembler für den Z80 ist anders als 
Assembler für PIC16 und das ist anders als Assembler für AVR und das 
wiederum ist anders als das für ARM, usw.

W.S.