Einen guten Morgen Ich möchte noch einmal versuchen in moderne Mikrocontroller einzusteigen, Schwerpunkt wären ATTiny zur Ablaufsteuerung und Signalverarbeitung. Mein Fachgebiet liegt sonst bei Analogtechnik und HF. "Damals als ich noch jung war" konnte ich ziemlich gut BASIC und ein bißchen Assembler. Was gibt es denn heute und für absehbare Zukunft an imperativen Programmiersprachen die einigermaßen Hardwarenah sind und eine recht einfache und klare Syntax haben? Besonder gut wäre wenn diese nativ für Ubuntu verfügbar sind und keinen Zwang zu Registrierung und Onlinebindung haben. "C" und verwandte Sprachen muß ich ausschließen. Alles was so mit "Pointer", "Casten", "Void()", "=" versus "==", Klammer-Konstruktionen und so Zeugs mir zu abstrakt, da habe schon mehrfach erfolglos versucht mir sowas in das Hirn zu prügeln. Ansonsten sind mir grundlegende Algorithmen und Abläufe sehr gut bekannt. Programmcode sollte ungefähr so aussehen Lesetemperatur: Rohwert=ADC(3) TemperaturinCelsius=Rohwert*1.11-68 Mit freundlichen Grüßen vom A-Freak
:
Sobald du auch nur irgendeine Hardware ansprechen möchtest, kommst du um C nicht herum. Alle Bibliotheken dafür basieren zu 99 Prozent auf C. Dokumentation ist C usw. Vergiss die Nischenprodukte wie Bascom. Sobald du die Plattform wechselst, steht es nicht mehr zur Verfügung und du mußt etwas neues lernen. Also am besten gleich C.
A-Freak schrieb: > Casten Sprachen ohne Casts sind also solche ohne Typisierung. Da fielen mir PHP und JS ein. Die haben natürlich nichts mit Embedded zu tun, und haben auch die C-artige Syntax. Untypisierte Sprachen sind aber letztendlich komplizierter als typisierte, weil sie oft unerwartetes Verhalten zeigen und man sich den Kopf zerbricht warum... A-Freak schrieb: > Void() Was ist das, hab ich noch nie gesehen? A-Freak schrieb: > "=" versus "==" Pascal, Ada. Aber die haben Casts (streng typisiert). A-Freak schrieb: > Klammer-Konstruktionen Schreibst du Mathematische Ausdrücke auch immer ohne Klammern? Also (a*(b+c^ln(5))) ist zu kompliziert? Solche Ausdrücke sind es eigentlich, die textuelle Sprachen mächtig machen... nur halt manche Opas wie Basic nicht.
A-Freak schrieb: > "C" und verwandte Sprachen muß ich ausschließen. Das wäre aber die offensichtliche Wahl, die auch alle deine Anforderungen erfüllt. Außerdem dürfte es die bei weitem am meisten verwendete Sprache auf Mikrocontrollern sein. > Alles was so mit "Pointer", "Casten", "Void()", "=" versus "==", Klammer- > Konstruktionen und so Zeugs mir zu abstrakt, da habe schon mehrfach > erfolglos versucht mir sowas in das Hirn zu prügeln. Wenn dir das schon zu abstrakt ist, wirst du wohl auf Assembler runter müssen. > Programmcode sollte ungefähr so aussehen > > Lesetemperatur: > Rohwert=ADC(3) > TemperaturinCelsius=Rohwert*1.11-68 Das sieht mir mehr nach sowas wie BASCOM aus. Das gibt's kostenlos aber nur in einer Demo-Version und nur für Windows. Dr. Sommer schrieb: > A-Freak schrieb: >> "=" versus "==" > > Pascal, Ada. Aber die haben Casts (streng typisiert). Da ist es statt "=" vs. "==" dann eben ":=" vs "=". Ist das nun so viel anders?
:
Bearbeitet durch User
A-Freak schrieb: > ATTiny Wenn Du kein C magst, dann bleibt bei den 8 Bit Controllern eigentlich nur noch Assembler. Allerdings würde ich dann über PIC-Controller statt über den ATTiny nachdenken. Der Assembler-Befehlssatz umfasst bei den PICs nur etwas über 30 unterschiedliche Befehle und ist somit (im Gegensatz zum ATTiny-Assembler) sehr schnell gelernt. Zudem ist er leistungsfähiger, da er z.B. auch einen Multiplikationsbefehl beinhaltet.
Pascal, Ada. Freepascal kann Avr Embedded für Atmega und Attiny, auch AtXmega. Andere Controller wie Pic und Stm wohl auch, hab ich aber noch nicht gemacht. Da Dir hier gleich erzählt wird, das ginge nur in C - wer nur einen Hammer hat, kann halt nur nageln... oder so - such Dir das deutsche Freepascal Forum, da kommst Du weiter.
Rolf M. schrieb: >> TemperaturinCelsius=Rohwert*1.11-68 > Das sieht mir mehr nach sowas wie BASCOM aus. In Bascom geht diese Rechnung nicht direkt, weil dieser Compiler nur 1 Rechenoperation pro Zeile kann. Deshalb kommt es logischerweise auch ganz ohne ohne Klammerungen aus... Da würde diese Rechnung also so aussehen: TemperaturinCelsius=Rohwert*1.11 TemperaturinCelsius=TemperaturinCelsius-68 Siehe dort bei "Tipps und Tricks" im letzten Viertel: https://rn-wissen.de/wiki/index.php?title=Bascom
Dr. Sommer schrieb: > Solche Ausdrücke sind es eigentlich, > die textuelle Sprachen mächtig machen... nur halt manche Opas wie Basic > nicht. Willst Du nicht doch wieder über das schreiben, von dem Du Ahnung hast - bei der Bravo? "Solche Ausdrücke" konnte Opas AmigaBasic schon vor 30 Jahren, und andere Basics auch. Und was der TO wahrscheinlicher meint, sind die {{({})(())}} Klammerorgien in C.
Hallo, falls Du ausschliesslich AVRs programmieren möchtest, kannst Du Dir mal Luna anschauen: http://avr.myluna.de
A-Freak schrieb: > "C" und verwandte Sprachen muß ich ausschließen Ich habe Z80 sehr effektiv in Pascal programmiert, aber das ist durch die Tätigkeit von Embarcadero wohl dem Untergang geweiht (den sehr guten Prospero-Compiler für Z80 gibt es sowieso schon lange nicht mehr). Aber egal, im Embedded-Bereich muss man unbedingt C zumindest AUCH beherrschen, wenigstens lesen können - auch wenn C von vielen eher dazu verwendet wird, die Funktion eines Programms zu verschleiern. Georg
@A-Freak Was nicht so ganz eindeutig aus Deinem Post hervorgeht, ob Du Dich privat oder beruflich damit beschäftigen möchtest. Privat zählt natürlich in erster Linie der Spass, wenn freepascal mit avr's umgehen kann, warum nicht. Beruflich würde ich aber auf alle Fälle C verwenden. Da geht es um Austauschbarkeit mit Kollegen/Kunden, Wiederverwendung, und dem Einsatz von fertigen Bibliotheken. Da ist einfach die Spielwiese insgesamt grösser.
Zille schrieb: > Der Assembler-Befehlssatz umfasst bei den > PICs nur etwas über 30 unterschiedliche Befehle und ist somit (im > Gegensatz zum ATTiny-Assembler) sehr schnell gelernt. Dafür macht es der eingeschränkte Befehlssatz aber umso komplizierter, reale Aufgaben zu lösen. Und auch die ständigen Bankumschaltungen und PCLATH-Berechnungen (Codepageüberlauf) sind häufige Fallgruben. Von PIC-Assembler würde ich daher einem Anfänger dringlichst abraten. Generell sehe ich keinen Grund, heutzutage noch mit Assembler anzufangen. Die Compiler und MCs sind leistungsfähig genug, daß marginale Vorteile in den Ausführungszeiten oder RAM/Flash-Nutzung weitgehend in den Hintergrund treten. Schnellere Entwicklung und geringere Fehlerquellen der Hochsprachen sind die entscheidenden Vorteile. C hat den entscheidenden Vorteil, daß es für alle Plattformen verfügbar ist. C-Programme lassen sich also leicht an 8051, PIC, AVR, MSP430, ARM usw. anpassen. Assembler-Programme sind dagegen bei Wechsel der CPU für die Tonne.
Karl K. schrieb: > "Solche Ausdrücke" konnte Opas AmigaBasic schon vor 30 Jahren, und > andere Basics auch. Bascom aber offenbar schon nicht. Ziemlich arm, denn das Parsen solcher Ausdrücke ist keine Raketenwissenschaft - lernt man selbst an der FH im 1. Semester Bachelor Informatik... Karl K. schrieb: > Und was der TO wahrscheinlicher meint, sind die {{({})(())}} > Klammerorgien in C. Das ist kein gültiger C Code. Irgendeine Form von Klammerung hat jede Sprache. Ist das jetzt so ein Unterschied ob da "{" oder "begin" steht? Sind nicht andere Dinge wichtiger - z.B. ob innerhalb der Klammern definierte Variablen außerhalb sichtbar sind?
A-Freak schrieb: > Was gibt es denn heute und für absehbare Zukunft an imperativen > Programmiersprachen die einigermaßen Hardwarenah sind und eine recht > einfache und klare Syntax haben? A-Freak schrieb: > "C" und verwandte Sprachen muß ich ausschließen. Alles was so mit > "Pointer", "Casten", "Void()", "=" versus "==", Klammer-Konstruktionen > und so Zeugs mir zu abstrakt, Das eine schließt das andere aus. "Zu abstrakt"? Abstraktion ist ja gerade Sinn und Zweck einer höheren Programmiersprache. Auf dem PC gäbe es noch Lazarus (Pascal), aber im Mikrocontrollerbereich ist C nun mal der Standard und wird es auf absehbare Zeit wohl auch noch bleiben. Gewöhn dich dran.
> Bascom aber offenbar schon nicht.
Klammern braucht man halt nicht.
Wenn man den Ausdruck zeilenweise auswertet.
90 % aller Profis programmieren in BASCOM!
P.Loetmichel schrieb: > Klammern braucht man halt nicht. > Wenn man den Ausdruck zeilenweise auswertet. Fahrzeuge braucht man auch nicht, wenn man überall zu Fuß hingeht!
Beitrag #5530988 wurde von einem Moderator gelöscht.
Beitrag #5530990 wurde von einem Moderator gelöscht.
A-Freak schrieb: > Programmcode sollte ungefähr so aussehen > > Lesetemperatur: > Rohwert=ADC(3) > TemperaturinCelsius=Rohwert*1.11-68 Sowas kann das Haustier meines Hundes schon programmieren. Und mein blinder Affe. Wer sollte dich für solch triviales Zeug bezahlen?
Dr. Sommer schrieb: > A-Freak schrieb: >> Void() > Was ist das, hab ich noch nie gesehen? Also noch nie C gesehen... Dr. Sommer schrieb: > A-Freak schrieb: >> Klammer-Konstruktionen > Schreibst du Mathematische Ausdrücke auch immer ohne Klammern? Er meint geschweifte Klammern! Dr. Sommer schrieb: > weil sie oft unerwartetes Verhalten zeigen und man sich den Kopf > zerbricht warum... Ja genau das Gegenteil ist der Fall! In Pascal und BASIC weisst Du was Du machst! Ich programmiere Mikrocontroller seit immer IN BASIC, und bin gut gefahren. Dass man für jedes simple I2C-Device eine Bibliothek braucht, ist Arduino - mässige Inkompetenz. @TO: Nimm einen Compiler von MikroE oder Oshionsoft. Gruss Chregu
Beitrag #5530996 wurde von einem Moderator gelöscht.
hilti schrieb: > falls Du ausschliesslich AVRs programmieren möchtest, kannst Du Dir mal > Luna anschauen: > > http://avr.myluna.de Da wäre auch die Plattform "Linux" erfüllt.
Christian M. schrieb: > Also noch nie C gesehen... Ich hab schon sehr viel C gesehen, aber "Void ()" noch nicht. Es sei denn, man definiert eine Funktion namens "Void" und ruft sie mit "Void ()" auf. Dann ist mir aber nicht klar, was daran schlimm sein soll. Christian M. schrieb: > Er meint geschweifte Klammern! Sprachen ohne Klammern (oder begin/end-Äquivalent) erlauben nur grausamen Spaghetti-Code. Davon gibt's auch nur sehr wenige, wie z.B. "LOGO" (hat nix mit Siemens Logo zu tun), aber selbst das hat so etwas ähnliches. Das ist übrigens auch untypisiert - genau das was der TO will. Läuft auch nur unter DOS. Ich durfte das mal zu Schulzeiten benutzen und habe mich gefragt, wie jemand so eine bescheuerte Sprache erfinden kann. Christian M. schrieb: > Ja genau das Gegenteil ist der Fall! In Pascal und BASIC weisst Du was > Du machst! Die sind aber statisch typisiert, brauchen also Casts, und haben auch Klammern. Christian M. schrieb: > Ich programmiere Mikrocontroller seit immer IN BASIC, und bin gut > gefahren. Dass man für jedes simple I2C-Device eine Bibliothek braucht, > ist Arduino - mässige Inkompetenz. Dann schreib mal eine USB-Ansteuerung oder TCP/IP-Stack selbst :-)
Manfred F. schrieb: > Auf dem PC gäbe > es noch Lazarus (Pascal), aber im Mikrocontrollerbereich ist C nun mal > der Standard und wird es auf absehbare Zeit wohl auch noch bleiben. Nur weil Du es nicht besser weißt, wird es durch ständige Wiederholung nicht wahrer. Die Leute, die professionell Controller in Ada oder Pascal programmieren, hängen halt nicht im uC Forum rum.
Christian M. schrieb: >>> Void() >> Was ist das, hab ich noch nie gesehen? > > Also noch nie C gesehen... Nenn' doch mal ein beispiel für void(). void(variable); kann man machen, um "unused argument" Warnungen loszuwerden, aber void()?
A-Freak schrieb: > C [...] mir zu abstrakt Sorry, aber wenn C schon zu abstrakt ist bleibt nur noch Assembler als nächst weniger abstrakte Sprache.
Vielleicht sollte der TO mal Python oder Ruby ausprobieren. Diese Sprachen erfüllen zwar überhaupt nicht die Anforderungen, sind aber sehr leicht zu erlernen und führen schnell zu Erfolgserlebnissen. Man muss sich nicht mit so vielen fiesen Details wie in C herumschlagen, aber dennoch nicht auf eine gute Sprachstruktur verzichten. Vielleicht erkennt er so, dass die Anforderungen nicht besonders sinnvoll sind und er lediglich von der C-Lernkurve geschädigt ist. Wenn man mithilfe dieser Sprachen grundlegende Sprachelemente gut verstanden hat, kann man immer noch zu C, Pascal, whatever wechseln. Tatsächlich läuft aber Python sogar teilweise auf Mikrocontrollern, oder auch auf dem R-PI.
Beitrag #5531032 wurde vom Autor gelöscht.
> Die Leute, die professionell Controller in Ada oder Pascal > programmieren, hängen halt nicht im uC Forum rum. Ada Programmierer sitzen in den Bundeswehrkantinen rum!
A-Freak schrieb: > Programmcode sollte ungefähr so aussehen > > Lesetemperatur: > Rohwert=ADC(3) > TemperaturinCelsius=Rohwert*1.11-68 In C sieht das nicht viel anders aus:
1 | float TemperaturinCelsius; |
2 | |
3 | void Lesetemperatur( void ) |
4 | {
|
5 | TemperaturinCelsius = ADC(3)*1.11-68; |
6 | }
|
Karl K. schrieb: > Die Leute, die professionell Controller in Ada oder Pascal > programmieren, hängen halt nicht im uC Forum rum. Mag sein. Aber wenn jemand, wie der TO, fast bei Null anfängt, dann kann ihm ein µC-Forum sehr viel helfen. Und z.B. hier gibt es nun mal viele, die C oder Assembler beherrschen. A-Freak schrieb: > Alles was so mit "Pointer", braucht man zu Beginn und für einfache Lernprogramme nicht unbedingt. > "Casten", ebenso. Definiere die Variablen sinnvoll und 'casten' fällt (fast immer) weg > "Void()", siehe oben die anderen Posts. Oder meintest du "int main(void)? >"=" versus "==", naja, irgend eine Unterscheidung zwischen einer Zuweisung und einem Vergleich braucht jede Sprache. Woher soll denn der Compiler wissen, was du gerade haben möchtest? > Klammer-Konstruktionen Wenn du die Prios der Operatoren kennst, dann brauchst du wenig Klammern. Wenn du nicht jedes mal darüber nachdenken willst, dann setze die Klammern und mach es für dich so übersichtlich wie möglich. Auch in der Schule hat man Klammer gebraucht, um die Priorisierung der Punkt- und Strichrechnung zu ändern. > und so Zeugs mir zu abstrakt, Naja, ohne Lernbereitschaft gewisser Grundlagen zu einer Sprache wirst du in jeder erfolglos bleiben. Besorge dir ein gutes Buch und beschäftige dich mal ein paar Tage damit.
HildeK schrieb: > Aber wenn jemand, wie der TO, fast bei Null anfängt, dann kann ihm ein > µC-Forum sehr viel helfen. Also mein erster Gedanke war TO -> TROLL (ansonsten stimme ich dir zu ;-)
> Welche Programmiersprache soll ich lernen? Das ist ja mal eine neue Frage. Hatten wir schon lange nicht mehr :-) Da du ATtiny Mikrocontroller programmieren willst, gibt es meiner Meinung nach nur eine sinnvolle Antwort: C Weil: > C hat den entscheidenden Vorteil, dass es für alle Plattformen > verfügbar ist. Da du C ausgeschlossen hast wäre der Plan B: Bascom Aber: > Vergiss die Nischenprodukte wie Bascom. Sobald du die > Plattform wechselst, steht es nicht mehr zur Verfügung und > du mußt etwas neues lernen. Ich zitiere die Kollegen hier, weil ich der gleichen Meinung bin.
Karl K. schrieb: > "Solche Ausdrücke" konnte Opas AmigaBasic schon vor 30 Jahren, und > andere Basics auch. > > Und was der TO wahrscheinlicher meint, sind die {{({})(())}} > Klammerorgien in C. Geht ja wieder sachlich hier zu. Dennoch, Recht hat er. @TO. Versuche es doch mal mit, nennen wir es mal, 'Arduino C'. Pass auf, ich schreibe Dir jetzt mal was in VB und dann in C:
1 | #VB
|
2 | Dim i as Integer |
3 | for i = 0 to 10 |
4 | SetLEDValue(i) |
5 | next
|
6 | |
7 | //C
|
8 | int i = 0; |
9 | for (i = 0; i < 11; i++) |
10 | {
|
11 | SetLEDValue(i); |
12 | }
|
Du siehst, soviel anders sieht das (erstmal) nicht aus.
:
Bearbeitet durch User
> 90 % aller Profis programmieren in BASCOM!
Echt? Wie kommst du auf die 90%?
Philipp G. schrieb: > //C > int i = 0; > for (i = 0; i < 11; i++) > { > SetLEDValue(i); > } for (int i = 0; i < 11; i++) SetLEDValue(i);
ACDC schrieb: > for (int i = 0; i < 11; i++) > SetLEDValue(i); Ich wollte exemplarisch zeigen, dass i wie in VB auf einer separaten Zeile initialisiert wird. Natürlich geht das auch direkt im Ausdruck, in beiden Sprachen.
1 | for (int_least8_t i = 0; i < 11; ++i) { |
2 | led [i].set (1); |
1 | for (auto& l : led) |
2 | led.set (1); |
Beitrag #5531110 wurde von einem Moderator gelöscht.
Lass den Tiny, der ist Murks fuer Sparer. Geeignet fuer sehr hohe Stueckzahlen, wenn es um cents geht. Aber fuer kleine Stueckzahlen nimmt man besser etwas grosszuegiger ausgestattetet Controller, zB etwas wie einen Mega644, oder so.
Peter D. schrieb: > Dafür macht es der eingeschränkte Befehlssatz aber umso komplizierter, > reale Aufgaben zu lösen. Und auch die ständigen Bankumschaltungen und > PCLATH-Berechnungen (Codepageüberlauf) sind häufige Fallgruben. > Von PIC-Assembler würde ich daher einem Anfänger dringlichst abraten. Trotz der geringen Anzahl an unterschiedlichen Befehlen ist der Assembler-Befehlssatz alles andere als eingeschränkt (der ATTiny schneidet in dieser Hinsicht schlechter ab, z.B. wegen dem fehlendem Multiplikationsbefehl). Für die Bankumschaltungen bei den Variablenaufrufe gibt es auch in Assembler Möglichkeiten, um daraus resultierende Fehler zu minimieren (bzw. ganz zu vermeiden). Die aktuellen PICs haben für den Code i.A. nur eine Page, somit gibt es den "Codepageüberlauf" nur, wenn Du mehr Code hast als in den Controller hineinpasst. Dieses Problem hat aber, ohne Ausnahme, jeder Controller.
Hallo C bzw. C++ oder auch "etwas schöner gemacht" wie im Arduino Universum ist im 8Bit µC Bereich schon die richtige Programmiersprache. Die praktische Anwendung und das erlernen sind gar nicht so kompliziert wenn, und das ist extrem wichtig und oft der Knackpunkt, die Bücher und Tutorials gut erklären und sinnvoll aufgebaut sind. Leider driften viele Autoren sehr schnell in ihre "Fachsprache" ab, wobei das jetzt nicht so auffällig sein muss das man es als "Wissender" direkt bemerkt, oft handelt es sich um vorgebliche Selbstverständlichkeiten für jemanden der in der Materie drin steckt die es aber für den lernwilligen Laien bei weiten nicht sind - nicht jeder hat ein Abitur oder hat mal ein Studiengang (schon gar nicht im technisch - mathematischen oder Informatik Bereich)absolviert. Was ist z.B. eine Funktion kann sehr gut verständlich und vor allem Praxistauglich erklärt werden, aber leider auch durch abstrakte und "versteckte" Fachsprache absolut unverständlich für einen Anfänger sein. Werden dann in diesen Beispiel noch die Begriffe Funktion und Methode lustig gemischt versteht man schnell gar nichts mehr und das lernen wird unnötiger Weise erschwert. Gerade der gut abgegrenzte 8Bit µC Bereich bietet eigentlich gute Chancen eine Programmiersprache wie C Praxisnah und ohne(!) starke Abstraktion und die sonst notwendige Verallgemeinerung (die Sprache soll sonst immer ja auf jeden System funktionieren) den Lerneilligen bei zu bringen, auch kann in solch einen abgegrenzten Bereich auf "Schwierige" Bestandteile der Sprache verzichtet werden die im 8Bit µC Bereich sowieso nie, oder nur äußerst selten gebraucht werden. Ein (viele) gute Bücher und Tutorials von Autoren die sich in Anfänger hineindenken können und die sehr genau drauf achten wann und wie Fachsprache (und hierzu zähle ich nicht nur die klar erkennbare Fachsprache) eingesetzt wird sind absolut entscheiden das eine Sprache passend für den Einsitzbereich frust frei und mit freude erlernt werden kann. Im von vielen "Profis" hier so verschmähte Arduinouniversum wird gezeigt wie es funktionieren kann - wobei es bei den Büchern dort leider auch sehr viel Oberflächlichen Mist gibt und die Autoren wenn es mal etwas tiefgreifender zugeht viel zu oft auch in die "Fachsprachenfalle" treten bzw. einfachste Hardware Grundlagen die in nahezu lächerliche "Babysprache" vermittelt wird mit für den Anfänger viel zu anspruchsvollen Programmierbeispielen und undurchschaubaren Erklärungen vermischt werden. Aber im Gegensatz zu sonstigen allgemeinen Literatur zu Programmiersprachen wie C und/oder µC Hardware und Anwendungs Bereich gibt es wenigsten manchmal was nützliches - allerdings nie in einen Buch oder Tutorial und ein 100 oder auch 200 Seiten Arduino Buch kann man eigentlich direkt liegen lassen wenn man richtig die "Sprache" (ist je nicht wirklich eine eigene Sprache) lernen will. So jetzt werden viele sagen: So lernt man aber keine Programmiersprache wie C wirklich richtig. Da gebe ich euch durch aus recht - aber wenn man eine Sprache wie C nur in einen festgelegt Umfeld wie den 8BiT µC anwenden will reicht das mehr als aus in besonders wenn dafür mehr und praktisch relevant auf die Besonderheiten und "Fallen" in so einen speziellen Umfeld eingegangen wird. Zuzel
(1) A-Freak schrieb: > "Damals als ich noch jung war" konnte ich ziemlich gut BASIC und ein > bißchen Assembler. Als ich noch jung war, programmierte ich mit Basic meine ersten Spaghetti-Codes und war sehr dankbar, als dann für meinen Rechner Turbo-Pascal verfügbar wurde. (2) A-Freak schrieb: > "C" und verwandte Sprachen muß ich ausschließen. Das solltest Du nicht. (3) > Alles was so mit > "Pointer", "Casten", "Void()", "=" versus "==", Klammer-Konstruktionen > und so Zeugs mir zu abstrakt, da habe schon mehrfach erfolglos versucht > mir sowas in das Hirn zu prügeln. Ansonsten sind mir grundlegende Du schreibst, Du bist in der Welt der Analog- und HF-Technik zuhause. Wenn das für Dich keine schware Magie ist, kann C Dich nicht wirklich überfordern und ich würde bezweifeln, dass Deine 'mehrefach erfolglosen Versuche' sehr ernsthafte waren. (4) > Algorithmen und Abläufe sehr gut bekannt. Das klingt für mich nach einem Widerspruch zu oben zitiertem. (5) Alles klar schrieb: > C, was sonst? Das würde auch ich grundsätzlich empfehlen, besonders in Hinblick auf: A-Freak schrieb: > Schwerpunkt wären ATTiny (6) Karl K. schrieb: > Pascal, Ada. > > Freepascal kann Avr Embedded für Atmega und Attiny, auch AtXmega. Meine letzten Berührungen mit Pascal und Ada fanden in meinen jungen Jahren an der Uni statt, was heißt, dass ich keine Ahnung habe, wie gut es sich damit auf µCs arbeitet. Allerdings gibt es in diesen Sprachen ähnliche Konzepte wie in C, lediglich die Syntax ist anders. Pascal empfinde ich als geschwätzig im Vergleich zu C: begin und end statt { und }.
:
Bearbeitet durch User
...real programmers can write Fortran in any language. ;-)
C/C++ ist nun mal DIE Universal-Sprache schlechthin wenn es um Programmierung von Mikrocontrollern geht. Eine einzige Sprache, sie alle zu knechten, in's Dunkel zu treiben und... ne, halt, das war was anderes. Assembler würde ich heutzutage definitiv die Finger von lassen. Das nimmt man sinnvollerweise nur noch dann und ausschliesslich in den seltenen Fällen, wo es aus irgendeinem Grund nicht anders geht. BASCOM scheint wirklich was zu sein, was den Wünschen des Threadstarters nahe kommen würde. Aber das ist halt auch wieder nur Windows, kommerziell etc. Ich habe ja irgendwie den Eindruck, dass der Threadstarter in Wahrheit gar keine besonders hardwarenahe Sprache sucht. Interessant wäre, warum der Threadstarter so ganz konkret auf Attinys abzielt. Sofern es dafür keinen wirklich guten Grund gibt, würde ich an seiner Stelle überlegen, ob es nicht auch ein deutlich leistungsfähigerer Mikrocontroller wie ESP8266 oder ESP32 sein kann. Die können nicht nur deutlich mehr als so ein popeliger Attiny, man kann sie auch in viel mehr Sprachen programmieren (C, (Micro)Python, LUA, JavaScript und und und)... Ein Attiny macht doch im Grunde nur dann Sinn, wenn man kommerzielle Absichten bzw. riesige Stückzahlen im Hinterkopf hat, wo paar Cent Kostenersparnis für den allerbilligsten Mikrocontroller doch in's Gewicht fallen. Aber wo es um kommerzielle Interessen mit riesigen Stückzahlen geht, wird man die Software doch nicht von einem Programmier-Laien in irgendeiner ominösen Programmiersprache programmieren lassen...
Joachim S. schrieb: > Ein Attiny macht doch im Grunde nur dann Sinn, wenn man kommerzielle > Absichten bzw. riesige Stückzahlen im Hinterkopf hat ...oder aber etwas räumlich sehr kleines bauen will aber QFN-Gehäuse scheut.
HildeK schrieb: > naja, irgend eine Unterscheidung zwischen einer Zuweisung und einem > Vergleich braucht jede Sprache. Woher soll denn der Compiler wissen, was > du gerade haben möchtest? In VHDL ist ein <= mal eine Zuweisung und mal ein Vergleich. Je nachdem, wo das steht:
1 | if a <= b then |
2 | a <= b; |
3 | end if; |
Man kann da wegen der syntaktischen Regulierung eben nicht in einer Abfrage gleichzeitig eine Zuweisung machen...
Da ich noch auf Lochraster löte, sind für mich einige ATtiny Modelle durchaus interessant. Ich habe mit einen üppigen Vorrat an ATtiny13 zugelegt - würde heute allerdings eher auf ATtiny85 setzen. Diese sind schön klein und ersetzen leicht eine sonst aufwändigere Logik- oder Timer-Schaltung. Der nächst größere, den ich benutze, ist dann aber schon der ATmega328, meist in Form eines Arduino Nano Klons. Ob man für Vergleich und Zuweisung einen oder zwei Operatoren hat, ist erfahrenen Programmierern ziemlich egal. Wer über solche Details diskutiert, hat wohl keine echten Herausforderungen zu meistern.
Lothar M. schrieb: > In VHDL ist ein <= mal eine Zuweisung und mal ein Vergleich. Ich hatte befürchtet, dass es Ausnahmen gibt. :-) Und hätte noch dazu schreiben können, dass man aus dem Kontext schon unterscheiden könnte. Bleibt die Frage, was sinnvoller bzw. weniger fehlerträchtig ist. Es schränkt jedenfalls gewisse Freiheiten ein, vielleicht wäre das manchmal auch von Vorteil. Fast jedem ist es schon passiert, dass man einen Vergleich wollte und eine Zuweisung schrieb - und dann gesucht hat ...
HildeK schrieb: > Es schränkt jedenfalls gewisse Freiheiten ein, vielleicht wäre das > manchmal auch von Vorteil. Das ist das, was einem Bekannten von mir an Bascom so gefällt: man MUSS alles Schritt für Schritt machen, deshalb kann man pro Zeile gar nicht allzuviel falsch machen. Mir ist ein Programm, das länger als 1 Bildschirmseite ist, schon suspekt. Da verliere ich langsam den Überblick... ;-)
Als Basic Compiler kann ich das Freie OpenSource GreatCowBASIC empfehlen. Es kann mit PIC 10-18 und AVR um. Eine sehr aktive Community, Libraries, bis der Arzt kommt. Eine sehr ausführliche aktuelle Dokumentation und ein Hilfesystem. Plattformunabhängig, ich nutze es mit Linux und verwende Geany als IDE, obwohl man auch die mitgelieferte IDE nutzen kann, aber mir ist es komplett nativ mit Linux lieber. Bitte schaue dich auf der Homepage und dem Forum um. http://gcbasic.sourceforge.net/Typesetter/index.php/Home Den compilierten Code kann man sich auch ansehen, es gibt einen Assembler output, der mit den Basic Code im Kommentarbereich eine schöne Sache ist. Bei Fragen zur Linux Installation stehe ich zur Verfügung
Bernd D. schrieb: > Als Basic Compiler kann ich das Freie OpenSource GreatCowBASIC > empfehlen. > Es kann mit PIC 10-18 und AVR um. Passt das auch in die kleinsten AVRs (sprich: die Tinies)?
M.A. S. schrieb: > Passt das auch in die kleinsten AVRs (sprich: die Tinies)? Ja. Es ist ein Compiler.
1 | ls tiny* |
2 | tiny10.dat tiny13a.dat tiny1634.dat tiny22.dat tiny24a.dat tiny261a.dat tiny28.dat tiny43u.dat tiny44.dat tiny461.dat tiny5.dat tiny84a.dat tiny861a.dat tiny88.dat |
3 | tiny11.dat tiny13.dat tiny167.dat tiny2313a.dat tiny24.dat tiny261.dat tiny40.dat tiny441.dat tiny45.dat tiny48.dat tiny828.dat tiny84.dat tiny861.dat tiny9.dat |
4 | tiny12.dat tiny15.dat tiny20.dat tiny2313.dat tiny25.dat tiny26.dat tiny4313.dat tiny44a.dat tiny461a.dat tiny4.dat tiny841.dat tiny85.dat tiny87.dat |
A-Freak schrieb: > "C" und verwandte Sprachen muß ich ausschließen. Das halte ich auch für einen Irrtum. OK, ich war nie ein C Freund, habe aber in tiefer Vergangenheit die C Grundlagen lernen können/dürfen. (SCO Unix) Bin seit ca 3 Jahren voll auf Arduino, und damit auf C++. 3 Jahre, intensives Hobby, und habe noch längst nicht alle Tiefen ausgelotet. Ich schätze mal, dass man insgesamt ca 10 Jahre braucht, um in C++ recht Sattelfest zu werden. PS: Die C++ Syntax/Sprachdefinition, hat man in 3 Monaten drauf.
A-Freak schrieb: > ATTiny zur Ablaufsteuerung und Signalverarbeitung. Signalverarbeitung auf einem ATTiny?? Ok, wenn du meinst... Von mir aus gesehen ist das wohl ein Thema für DSP, ARM oder FPGA. P.Loetmichel schrieb: > 90 % aller Profis programmieren in BASCOM! Mhm, hätte eher das umgekehrte Verhältnis vermutet. Da ich weder im Lehrbetrieb, Lehre, Studium oder jetzt in der "Profi-Welt" jemals einer gesehen habe der mit BASCOM ein uC programmiert... Ausserdem haben sie wohl die Profis in den aktuellen Studien vergessen: https://jaxenter.de/programmiersprachen-rankings-q1-2017-54308 Ich persönlich würde C empfehlen, wenn du dich wirklich nur in der uC Welt bewegst. Sobald du aber auch irgend welche kleinen Tools für den PC brauchst oder dich einmal von uC auf FPGA und SW-Programmierung bewegst, wirst du wohl nicht um C++ herum kommen. Mit der Kombination C/C++ kannst du von simplen uC Firmware, FPGA, DSP, PC (OS unabhängig) bis zur SPS alles umsetzen. Ob das dann in deinem Betrieb auch genutzt wird, ist eine andere Frage.
:
Bearbeitet durch User
Patrick B. schrieb: > Signalverarbeitung auf einem ATTiny?? Ok, wenn du meinst... > Von mir aus gesehen ist das wohl ein Thema für DSP, ARM oder FPGA. Das kommt auf die Signale an.
Karl K. schrieb: > Manfred F. schrieb: >> Auf dem PC gäbe >> es noch Lazarus (Pascal), aber im Mikrocontrollerbereich ist C nun mal >> der Standard und wird es auf absehbare Zeit wohl auch noch bleiben. > > Nur weil Du es nicht besser weißt, wird es durch ständige Wiederholung > nicht wahrer. > > Die Leute, die professionell Controller in Ada oder Pascal > programmieren, hängen halt nicht im uC Forum rum. Anstatt zu motzen wäre es wohl besser, hier mal einen wirklich guten und für bare-metal geeigneten Pascal-Compiler zu benennen. Pascal wäre auch für die µC-Programmierung die weitaus bessere Sprache als C, wenn es denn die dafür geeigneten Compiler gäbe. Aber das ist leider nicht der Fall, weil Pascal seit Jahren vernachlässigt worden ist. Das ist das eigentliche Problem. Und es soll mir keiner sagen, daß C da irgendwelche sprachlichen Vorteile hätte, die hat es nämlich nicht. Der einzige Grund, weswegen heutzutage C quasi ubiquitär ist, besteht darin, daß es dafür gute Compiler gibt. Also, jetzt sag mal, welche Ada oder Pascal Compiler für z.B. die Arm-Cortexe es gibt, die in ihrer Qualität an den Keil oder IAR herankommen. W.S.
W.S. schrieb: > Also, jetzt sag mal, welche Ada oder Pascal Compiler für z.B. die > Arm-Cortexe es gibt, die in ihrer Qualität an den Keil oder IAR > herankommen. Keine Ahnung obs was taugt, aber angeboten wird es: https://www.ghs.com/products/AdaMULTI_IDE.html
W.S. schrieb: > Und es soll mir keiner sagen, daß C da irgendwelche sprachlichen > Vorteile hätte, die hat es nämlich nicht. Ich bin kein Gegner anderer Sprachen als C. Aber: > Der einzige Grund, weswegen > heutzutage C quasi ubiquitär ist, besteht darin, daß es dafür gute > Compiler gibt. Wie erklärst Du, dass es so ist? Warum haben sich alle auf C gestürzt und Pascal vernachlässigt, wenn C keine Vorteile bietet?
Beitrag #5531569 wurde von einem Moderator gelöscht.
W.S. schrieb: > Pascal wäre auch für die µC-Programmierung die weitaus bessere Sprache > als C, wenn es denn die dafür geeigneten Compiler gäbe. Aber das ist > leider nicht der Fall, weil Pascal seit Jahren vernachlässigt worden > ist. Pascal ist nicht vernachlässigt worden, sondern Pascal ist tot. Denn der Nachfolger von Pascal ist seit 1978(!) Modula2 - ebenso von Niklas Wirth entwickelt. Der Nachfolger von Modula2 ist Modula3. Und der Nachfolger von Modula im allgemeinen ist seit 1994 Oberon, ebenfalls u.a. von Niklas Wirth. Wenn, dann lass uns besser über Oberon reden statt über einen Dinosaurier, den niemand mehr zum Leben erwecken will. Oberon ist strukturierter als Pascal, mächtiger, gleichzeitig aber erheblich weniger umfangreich als Modula-2. Man kann in Oberon auch Betriebssysteme schreiben, das heisst, es gibt Interfaces zur Hardware, welche für Pascal als rein akademisches Werk gänzlich fehlen. Du willst einen Dino (C) durch einen anderen Dino (Pascal) ersetzen. Allein schon dieser Ansatz ist zum Scheitern verurteilt.
Frank M. schrieb: > Und der Nachfolger > von Modula im allgemeinen ist seit 1994 Oberon, ebenfalls u.a. von > Niklas Wirth. Gibt es Oberon-Compiler für µCs? PS: Danke übrigens für das Anheben des SNR! ;)
:
Bearbeitet durch User
Beitrag #5531581 wurde von einem Moderator gelöscht.
Beitrag #5531587 wurde von einem Moderator gelöscht.
Herr B. schrieb im Beitrag #5531581:
> Der Mann heißt Niklaus Wirth.
Trotzdem danke für den Hinweis.
PS: irgendwie empfange ich hier wieder so ein Rauschen...
:
Bearbeitet durch User
M.A. S. schrieb: > Gibt es Oberon-Compiler für µCs? Glaube ich nicht, genausowenig wie es verwendbare Pascal-Compiler für µCs gibt. Daher ist diese ganze Diskussion C vs. Pascal für den TO wenig hilfreich. Apropos Pascal: Es wurde schon einmal wiedergeboren, nämlich als "Component Pascal". Hier diente Oberon als Vorlage. "Component Pascal" hieß 1994 erst "Oberon/L", wurde dann später aber in "Component Pascal" umbenannt. Mit dem ursprünglichen Pascal, von welchem W.S. immer mal wieder schwärmt, hat es natürlich nur noch wenig gemeinsam. Interessant: https://de.wikipedia.org/wiki/Component_Pascal Allein schon die dort aufgeführten Programmbeispiele wecken Lust auf mehr. Trotzdem wird sich auf dem µC-Sektor in absehbarer Zeit nicht viel tun, C/C++ also als Standard bestehen bleiben. Wahrscheinlich ist dem TO mit einem µC-tauglichen Basic am besten geholfen, auch wenn er es für Linux als Plattform wahrscheinlich nicht finden wird.
Um nochmal zu Basic zurück zu kommen. Ich hatte letztes Jahr in meinem Blog dazu etwas geschrieben. http://zockertown.de/s9y/index.php?/archives/1677-Great-Cow-BASIC-Compiler-v0.98.00.html Da mein Blog rein privat und Werbefrei ist, geht das hoffentlich in Ordnung
ich weiß nicht wir ihr das seht, ich halte den TO für einen Edel-Troll. Der sondert hier ein einziges Mal sein 'Duftmarke' ab und meldet sich dan anschließend nicht mehr :-( bis jetzt) (der Thread hat mittlerweile schon 68 Einträge) A-Freak schrieb: > da habe schon mehrfach erfolglos versucht > mir sowas in das Hirn zu prügeln A-Freak schrieb: > Ansonsten sind mir grundlegende > Algorithmen und Abläufe sehr gut bekannt. Das passt irgendwie nicht zusammen (einmal IQ=0 das andere Mal IQ=100 :-)
Beitrag #5531615 wurde von einem Moderator gelöscht.
Beitrag #5531616 wurde von einem Moderator gelöscht.
Beitrag #5531619 wurde von einem Moderator gelöscht.
Frank M. schrieb: > Wahrscheinlich ist dem TO mit einem µC-tauglichen Basic am besten > geholfen, auch wenn er es für Linux als Plattform wahrscheinlich nicht > finden wird. Wie bereits geschrieben Great Cow BASIC erfüllt diese Bedingungen und ist zu dem für PIC und AVR zu verwenden
Frank M. schrieb: > Pascal ist nicht vernachlässigt worden, sondern Pascal > ist tot. ...und Klämpfl und van Canneyt sind die Chefpathologen, oder wie?!
Beitrag #5531626 wurde von einem Moderator gelöscht.
Beitrag #5531628 wurde von einem Moderator gelöscht.
Beitrag #5531629 wurde von einem Moderator gelöscht.
Beitrag #5531630 wurde von einem Moderator gelöscht.
il Conte schrieb: > ich weiß nicht wir ihr das seht, ich halte den TO > für einen Edel-Troll. Ja -- und? Ich hatte das hier bis jetzt immer für ein Diskussion- forum gehalten: Über interessante Themen wird diskutiert, und von uninteressanten Themen hält man sich fern.
Beitrag #5531632 wurde von einem Moderator gelöscht.
Beitrag #5531633 wurde von einem Moderator gelöscht.
Frank M. schrieb: > Trotzdem wird sich auf dem µC-Sektor in absehbarer Zeit > nicht viel tun, C/C++ also als Standard bestehen bleiben. Was ich ehrlich nicht verstehe, das ist, wieso nicht jemand dahergeht und C als Zwischensprache verwendet. Man könnte alle Systeme programmieren, für die es einen C-Compiler gibt (also ungefähr alle), müsste sich aber nicht mit dem Gepointere und ähnlichem Zeug herumärgern...
Beitrag #5531641 wurde von einem Moderator gelöscht.
Beitrag #5531642 wurde von einem Moderator gelöscht.
Beitrag #5531643 wurde von einem Moderator gelöscht.
Beitrag #5531644 wurde von einem Moderator gelöscht.
Beitrag #5531646 wurde von einem Moderator gelöscht.
Beitrag #5531648 wurde von einem Moderator gelöscht.
Egon D. schrieb: > Was ich ehrlich nicht verstehe, das ist, wieso nicht jemand dahergeht > und C als Zwischensprache verwendet. Das wurde ganz früher mal bei C++ gemacht. Der C++-Compiler hat dabei klassisches C erzeugt.
Beitrag #5531651 wurde von einem Moderator gelöscht.
Hallo Frank, Frank M. schrieb: > Glaube ich nicht, genausowenig wie es verwendbare Pascal-Compiler für > µCs gibt. Daher ist diese ganze Diskussion C vs. Pascal für den TO wenig > hilfreich. Die Firmware zu den einzelnen Modulen des Messplatzsystems c't-lab wurde vom Autor mit Hilfe von "E-Lab AVRCo Pascal" erstellt. Ein bisschen Assemblercode ist wohl auch noch dabei: https://www.heise.de/ct/projekte/machmit/ctlab/wiki/FirmWare
Beitrag #5531655 wurde von einem Moderator gelöscht.
Beitrag #5531656 wurde von einem Moderator gelöscht.
Beitrag #5531657 wurde von einem Moderator gelöscht.
Beitrag #5531658 wurde von einem Moderator gelöscht.
Peter M. schrieb: > Die Firmware zu den einzelnen Modulen des Messplatzsystems c't-lab wurde > vom Autor mit Hilfe von "E-Lab AVRCo Pascal" erstellt. Wenn ich es richtig verstanden habe, unterstützt AVRCo Pascal nur ATmegas oder XMegas. Dann muss sich der TO halt vom ATTiny verabschieden.
Egon D. schrieb: > Was ich ehrlich nicht verstehe, das ist, wieso nicht jemand > dahergeht und C als Zwischensprache verwendet. Derlei Ansätze gibt es. Z.B. bei MATLAB.
Sorry, da Moby, der Hausverbot hat, den Thread gerade massiv zuspamt, musste ich ihn nach Offtopic verschieben, um ihn dem Zugriff von Moby zu entziehen.
Pascal gibt es immer noch. Wird auch immer noch weiter entwickelt. Siehe hier: https://www.mikroe.com/mikropascal-avr Gibt es für verschiedene Controller Familien.
Frank M. schrieb: > Wenn ich es richtig verstanden habe, unterstützt AVRCo Pascal nur > ATmegas oder XMegas. Das weiß ich nicht. >Dann muss sich der TO halt vom ATTiny > verabschieden. Es passiert ja oft, dass der Fadenstarter im Gesprächsverlauf die Vorgaben ändert. :) Ich finde es interessant, dass man so etwas Systemnahes auch in Pascal schreiben kann. Andere Benutzer haben dann die Firmware nach C portiert. Kommerzielle Anwender gucken wahrscheinlich auf maximale Portabilität.
M.A. S. schrieb: > Egon D. schrieb: >> Was ich ehrlich nicht verstehe, das ist, wieso nicht >> jemand dahergeht und C als Zwischensprache verwendet. > > Derlei Ansätze gibt es. Z.B. bei MATLAB. Klar -- aber mir ist kein freies Werkzeug bekannt, das sich auch für kleinere Maschinen eignet. Es scheint die Überzeugung vorzuherrschen, dass komplexe Sachverhalte sowieso NUR von Leuten programmiert werden, die C++ beherrschen und anwenden wollen -- was ich für grundfalsch halte. Eher verwendet man Pascal mit eingebettetem Assembler, als irgendwas Neues mit eingebettetem C einzusetzen.
Beitrag #5531699 wurde von einem Moderator gelöscht.
Beitrag #5531732 wurde von einem Moderator gelöscht.
Beitrag #5531746 wurde von einem Moderator gelöscht.
Beitrag #5531748 wurde von einem Moderator gelöscht.
Es kommt nicht nur auf die Fachliche Information an, sondern auch auf die Art, wie man sie überbringt. Wenn ich schreibe: "Ey du dummer Eber, du hast + mit - verwechselt", dann wird das zu Recht gelöscht.
Beitrag #5531767 wurde von einem Moderator gelöscht.
Jetzt muß ich auch mal meinen Senf dazugeben. Für den privaten Gebrauch und wenn die Aufgaben nicht zu komplex sind eignet sich Assembler durchaus. Es ist meiner Meinung nach leichter zu erlernen als c. Auch bei den AVR gibt es einen mul Befehl für die Multiplikation, wird aber nicht von jedem Chip unterstützt. Trotzdem würde ich C empfehlen, zumindest wenn absehbar ist, dass die gewünschten Anforderungen an die Projekte mit der Zeit größer werden. Noch ein paar Tipps für den Einstieg: Mit einem kleinen Attiny zu beginnen halte ich für eine gute Idee. Gerade zum Anfang ist das Datenblatt des Chips Pflichtlektüre und das DB vom Tiny ist um ein vielfaches kleiner als das vom Atmega. Gleiches gilt für die IDE, AVR Studio 4.19 ist viel schlanker gehalten als eine aktuelle 7.xx oder was es da aktuell so gibt. Ansonsten gibt es halt erstmal eine lange Lernphase um "Softwarebedienungsingenieur" zu werden.
Fred F. schrieb: > Auch bei den AVR gibt es einen mul Befehl für die Multiplikation, wird > aber nicht von jedem Chip unterstützt. Ja, und zwar gerade den Tinys fehlt er.
Patrick B. schrieb: > Signalverarbeitung auf einem ATTiny?? Ok, wenn du meinst... > Von mir aus gesehen ist das wohl ein Thema für DSP, ARM oder FPGA. Signalverarbeitung heißt nicht automatisch immer nur Audio oder Video. Man kann auch Signale von Sensoren (Temperatur, Druck, Position usw.) verarbeiten wollen und da reicht oft eine langsamere Architektur völlig aus.
@Karl2go: > Und was der TO wahrscheinlicher meint, sind die {{({})(())}} Klammerorgien in C. @Geiserp01: #VB Dim i as Integer for i = 0 to 10 SetLEDValue(i) next //C int i = 0; for (i = 0; i < 11; i++) { SetLEDValue(i); } @ACDC: for (int i = 0; i < 11; i++) SetLEDValue(i); @Barrex: Ausschließlich privat. Daher, und weil ich doch schon älter bin, habe ich nicht mehr den Kopf daß daß ich diese abstrakten Sprachbeispiele wie oben wie oben noch wirklich auswendig lernen kann. Vor allem eben dieses "=" versus "==" kommt mir total falsch vor weil ich eben so denke: IF Schalterstellung = 3 THEN ... END Ich muß auch offen zugeben daß ich nicht Programmieren an sich als Tätigkeit lernen will, sondern das nur als notwendigen Teil von gemischten Projekten. Zum Beispiel ein Bedienteil für einen Kurzwellenempfänger der mit DDS statt Kapazitätsioden-VFO abgestimtm wird. Oder ein Akkuladegerät bei dem die Ablaufsteuerung nicht in 12 Logikgattern steckt sndern in einem uC. Oder eine Spulenwickelmaschine. @Vloki: @il_conte: Wenn du im Forum nach meinem Benutzernamen suchst wirst du sehen daß ich doch schon ein paar Jahre länger dabei bin und wo meine Fachgebiete liegen zu denen ich konstruktiv beitrage. Danach kannst du gerne noch einmal entscheiden ob du mich weiter Troll bezeichnen möchtest. > Der sondert hier ein einziges Mal sein 'Duftmarke' ab und meldet sich dan anschließend nicht mehr :-( bis jetzt) Da ich auch noch anderes in der realen physikalischen Welt zu tun habe bin ich nicht stündlich online in Foren unterwegs. @Bernd_D56: > Als Basic Compiler kann ich das Freie OpenSource GreatCowBASIC empfehlen. DANKE! DANKE! DANKE! Das ziehe ich mir die nächsten Wochen mal rein, sieht super aus. @rmnagnus: Die neueren Tinys haben jetzt auch einen Mul-Befehl z.B. der 817 @peda: Exakt so Also z.B. Spannung vom NTC einlesen und PWM für dne Lüfter hochfahren währen für mich schon Signalverarbeitung wie ich sie ich bisher halt mit TLC393 gemacht habe. @All: Danke für die paar hilfreichen Kommentare, ganz besonders noch einmal zu dem super interresantem GQBasic
A-Freak schrieb: >> Und was der TO wahrscheinlicher meint, sind die {{({})(())}} > Klammerorgien in C. Die Klammern sparen Schreibarbeit ein. Ob ich nun: THEN .. END schreibe oder einfach nur: { .. } A-Freak schrieb: > Vor allem eben dieses "=" versus "==" kommt mir total falsch vor weil > ich eben so denke: Es macht den Code besser verstehbar und weniger fehlerträchtig, wenn völlig verschiedene Aktionen (Zuweisung oder Vergleich) auch verschieden codiert werden. Man muß dann nicht erst mühsam aus dem Kontext lesen, was gemeint sein könnte. Außerdem ist man damit flexibler, man kann mehrere Zuweisungen und Vergleiche in einem Ausdruck haben. Auch möchte man einen Vergleich manchmal erst später auswerten, d.h. einer Variable zuweisen:
1 | bool success = result == expected; |
2 | // ..
|
3 | if( success ) |
4 | do_something(); |
:
Bearbeitet durch User
A-Freak schrieb: >> Als Basic Compiler kann ich das Freie OpenSource GreatCowBASIC > empfehlen. > > DANKE! > DANKE! > DANKE! > > Das ziehe ich mir die nächsten Wochen mal rein, sieht super aus. Ich habe mir GreatCowBasic auch mal angeschaut, man lernt ja gerne dazu. Aber ich muss sagen, da bleibe ich lieber bei LunaAVR. Da habe ich unter Linux eine funktionierende IDE und muss mir nicht mühsam einen Editor anpassen.
A-Freak schrieb: > Vor allem eben dieses "=" versus "==" kommt mir total falsch vor weil > ich eben so denke: Der richtige Compiler wird bei richtigem Warnlevel eine fehlerhafte Verwendung dieser 2 Operatoren als Fehler kennzeichnen ;) merciless
A-Freak schrieb: > Das ziehe ich mir die nächsten Wochen mal rein, sieht super aus. Das ist statisch typisiert und hat Casts, verschachtelte Klammern & Ausdrücke, und so etwas wie Pointer namens "Alias". Zuweisungen und Vergleiche werden beide mit "=" gemacht, also noch verwirrender als in C wo es mit "=" und "==" eindeutig ist; manche finden es ja in Pascal besser wo ":=" Zuweisung ist. Entspricht also nicht so ganz deinen Anforderungen...
Peter D. schrieb: > A-Freak schrieb: >>> Und was der TO wahrscheinlicher meint, sind die {{({})(())}} >> Klammerorgien in C. > > Die Klammern sparen Schreibarbeit ein. > Ob ich nun: > THEN > .. > END > schreibe oder einfach nur: > { > .. > } Python vermeidet Klammern (oder Schlüsselwörter wie BEGIN und END). Leider isses (soweit mir bekannt ist, bitte melden, wenn wer was anderes weiß!) nix für Mikrocontroller. @MISTER-MINUS-MAN: Der TO hat seine Anforderungen klar dargestellt und wohl begründet. So, wie er sich und seine Vorhaben beschreibt, ist eine Art Basic sicher das beste für Ihn. Schön, wenn er durch den Rat einzelner hier fündig wird. Ich weiß nicht, was es daran schon wieder mit Minus zu bewerten gibt!
Peter D. schrieb: > Die Klammern sparen Schreibarbeit ein. > Ob ich nun: > THEN > .. > END > schreibe oder einfach nur: > { > .. > } > > A-Freak schrieb: >> Vor allem eben dieses "=" versus "==" kommt mir total falsch vor weil >> ich eben so denke: > > Es macht den Code besser verstehbar und weniger fehlerträchtig, wenn > völlig verschiedene Aktionen (Zuweisung oder Vergleich) auch verschieden > codiert werden. Ich denke in diesen Punkten ganz genau wie Du. Aber man sollte akzeptieren, dass es Geschackssache ist und andere Menschen es anders sehen.
Den Unterschied zwischen = und == musst Du Dir bei C nicht merken. Der Compiler weist Dich ggf. schon darauf hin, wenn du alle Warnungen eingeschaltet hast (gcc Parameter -Wall). Die meisten Entwicklungsumgebungen (außer Arduino) tun das auch schon direkt im Editor.
M.A. S. schrieb: > Aber man sollte akzeptieren, dass es Geschackssache ist und andere > Menschen es anders sehen. Bourne, der Programmierer der legendären Unix-Shell, benutzte folgende Makros:
1 | #define IF if(
|
2 | #define THEN ){
|
3 | #define ELSE } else {
|
4 | #define ELIF } else if (
|
5 | #define FI ;}
|
6 | |
7 | #define BEGIN {
|
8 | #define END }
|
9 | #define SWITCH switch(
|
10 | #define IN ){
|
11 | #define ENDSW }
|
12 | #define FOR for(
|
13 | #define WHILE while(
|
14 | #define DO ){
|
15 | #define OD ;}
|
16 | #define REP do{
|
17 | #define PER }while(
|
18 | #define DONE );
|
19 | #define LOOP for(;;){
|
20 | #define POOL }
|
Damit konnte er in C folgendes schreiben:
1 | LOCAL VOID gsort(from,to) |
2 | STRING from[], to[]; |
3 | {
|
4 | INT k, m, n; |
5 | REG INT i, j; |
6 | |
7 | IF (n=to-from)<=1 THEN return FI |
8 | |
9 | FOR j=1; j<=n; j*=2 DONE |
10 | |
11 | FOR m=2*j-1; m/=2; |
12 | DO k=n-m; |
13 | FOR j=0; j=0; i-=m |
14 | DO REG STRING *fromi; fromi = &from[i]; |
15 | IF cf(fromi[m],fromi[0])>0 |
16 | THEN break; |
17 | ELSE STRING s; s=fromi[m]; fromi[m]=fromi[0]; fromi[0]=s; |
18 | FI
|
19 | OD
|
20 | OD
|
21 | OD
|
22 | }
|
Und schon ist das Klammernproblem obsolet :-)
Frank M. schrieb: > Bourne, der Programmierer der legendären Unix-Shell, benutzte folgende > Makros:#define IF if( > #define THEN ){ > #define ELSE } else { > #define ELIF } else if ( >.... Mit Makros kann man ja eiiinige Schweinereien treiben. :) Ralf H. schrieb: > da bleibe ich lieber bei LunaAVR. Es gab schon zu Beginn meiner Studienzeit anno '85 zuviele Programmiersprachen, um sie alle zu kennen aber langsam nimmt's überhand und ich blicke schon lange nicht mehr durch.
Frank M. schrieb: > Und schon ist das Klammernproblem obsolet :-) :-D ...ähm, nein danke. Wenn man doch schon C hat, warum sollte man dann so etwas machen? Für mich ist das alles andere als übersichtlicher oder lesbarer.
:
Bearbeitet durch User
Ich habe das Gefühl, dass die meisten neuen Programmiersprachen von Anfängern initiiert werden. Sie glauben, sie hätten eine ganz tolle Idee wie man das Handwerk der Programmierer revolutionieren können. Ziel: Kleiner, schneller, besser. 10 Jahre später, nachdem jeder seinen Senf dazu gegeben hat und die Anforderungen aller Anwender eingebaut wurden, haben sich die Ziele in Luft aufgelöst. Die guten Ideen hingegen wurden längst in die alten Sprachen übernommen. Sei es als Library/Modul oder als Bestandteil der Sprache selbst. Ganz markant finde ich, dass bei neuen Sprachen und Frameworks permanent Performance-Verbesserungen beworben werden. Und doch sind sie allesamt immer noch langsamer als das gute alte C. Ich habe das Gefühl, sie lösen primär Probleme, die sie sich vorher selbst eingebrockt haben - und zwar bei dem Versuch, das Programmieren zu vereinfachen.
M.A. S. schrieb: > Es gab schon zu Beginn meiner Studienzeit anno '85 zuviele > Programmiersprachen, um sie alle zu kennen aber langsam nimmt's überhand > und ich blicke schon lange nicht mehr durch. Geht mir auch so ;-) Egal, dann bleibt man eben pragmatisch, solange kein Wechsel nötig ist, bei dem was man kennt, und wenn es nötig wird, dann am besten die am weitesten verbreitete Sprache, die nicht in naher Zukunft schon obsolet sein könnte. So kam ich irgendwann von Assembler zu C auf Mikrocontrollern (weil das eben gerade großflächig verfügbar war) und C++ für PC Software. C++ habe ich dabei noch nicht mal wirklich gelernt. Ich programmiere eigentlich C in einer C++ Umgebung (im Moment Qt). Für meinen Kleinkram reicht das. Auch wenn neue Sprachen vielleicht ganz toll sind - die Faulheit siegt ;-) <edit> Adam P. schrieb: > wenn man doch schon C hat, warum sollte man dann so etwas machen? > Für mich ist das alles andere als übersichtlicher oder lesbarer. Für mich auch, weil ich lange genug nur C gesehen habe ;-)
:
Bearbeitet durch User
Volker S. schrieb: > Geht mir auch so ;-) > Egal, dann bleibt man eben pragmatisch, solange kein Wechsel nötig ist, > bei dem was man kennt, ... Das halte ich auch so. Früher, als ich noch jung und naiv war, hatte ich den Ehrgeiz, jede Programmiersprach zu erlernen. (Damals wußte ich noch nicht, wie viel es zu der Zeit schon gab, ganz zu schweigen davon, dass ich keine Ahnung hatte, wie sich das weiterentwickeln würde.) Heute ist mir klar, dass das nicht geht, es beunruhigt mich aber, dass ich es nichtmal schaffe, einen Überblick darüber zu haben, was es alles gibt und worin im Groben die Eigenschaften und Anwendungsmöglichkeiten bestehen.
M.A. S. schrieb: > Ralf H. schrieb: >> da bleibe ich lieber bei LunaAVR. > Es gab schon zu Beginn meiner Studienzeit anno '85 zuviele > Programmiersprachen, um sie alle zu kennen aber langsam nimmt's überhand > und ich blicke schon lange nicht mehr durch. Da gebe ich Dir recht. Aber viele Programmiersprachen sind Weiterentwicklungen einer oder mehrerer ursprünglichen Sprache, um diese zu "verbessern". Wenn man die ursprüngliche Sprache beherrscht, kann man meistens nach kurzer Einarbeitungszeit auch in der "neuen" Sprache programmieren. Aber mir geht es wie dem TO: Ich bin mit BASIC (Schneider CPC464) gross geworden, habe danach Assembler und Pascal gelernt und später auch noch C. Mit C konnte ich mich nie richtig anfreunden, da C für mich als Gelegenheitsprogrammierer in vielen Bereichen zu kryptisch bzw. zu maschinennah ist. Vorteile, die meiner Meinung nach für LunaAVR sprechen: - kein C, sondern an BASIC und Pascal angelehnt, für mich also leicht verständlich und erlernbar - Verwendbar unter Windows und(!) Linux mit eigener IDE - sehr gute Bibliotheken - erzeugter Code ist klein und schnell - Quasi-Objektorientiere Programmierung möglich, wenn man möchte Natürlich gibt es auch Nachteile, aber der TO hat nach Alternativen zu C gefragt und LunaAVR ist definitiv eine ;)
Stefanus F. schrieb: > Ich habe das Gefühl, dass die meisten neuen Programmiersprachen von > Anfängern initiiert werden. Sie glauben, sie hätten eine ganz tolle Idee > wie man das Handwerk der Programmierer revolutionieren können. Das kann ich mir nun nicht vorstellen, dass ein 'Anfänger' mal eben eine Prgrammiersprache baut. (Oder: Definiere Anfänger!) Stefanus F. schrieb: > 10 Jahre später, nachdem jeder seinen Senf dazu gegeben hat und die > Anforderungen aller Anwender eingebaut wurden, haben sich die Ziele in > Luft aufgelöst. Die guten Ideen hingegen wurden längst in die alten > Sprachen übernommen. Sei es als Library/Modul oder als Bestandteil der > Sprache selbst. Hmm ja, in der Evolutionsbiologie nennt man sowas 'konvergente Entwicklung'. Ich habe irgendwie auch das Gefühl, dass inzwischen jede Sprache versucht, alles zu sein. (Ich laß z.B. irgendwo von objektorientierem Fortran...) Irgendwann sind dann alle Sprachen (zumindest die, deren Entwickler diesen Trend mitmachen) abgesehen von der Syntax gleich. Ob das sinnvoll ist, darf man bezweifeln.
Stefanus F. schrieb: > dass bei neuen Sprachen und Frameworks permanent > Performance-Verbesserungen beworben werden Es gibt verschiedenste Formen von "Performance". z.B. für mich ist selten das letzte Zehntel bei den Rundenzeiten wichtig. Insbesondere bei dem Laufzeitverhalten der Anwendung. Auch Speicherverbrauch ist mir nahezu egal, solange es rein passt. Ich lege meist eher wert auf -Schnelle Entwicklung -Wartbarkeit -Portabilität --- Dieses Great Cow BASIC habe ich mir in der Vergangenheit mal angesehen. Nix für mich. Passt nicht gut in/an meine Denke. Wobei ich zugeben muss, dass es sowohl lernbar, als auch funktionsfähig ist.
Ralf H. schrieb: > Ich bin mit BASIC (Schneider CPC464) gross geworden, habe danach > Assembler und Pascal gelernt der CPC464 war mein erstes Desktop-Gerät. Davor hatte ich einen Sharp PC1500, auf dem habe ich Basic gelernt. Auf dem CPC464 lief (nach Einbau einer Speichererweiterung) CP/M und Turbopascal, das war für mich erstmal das Paradies. Später kam ein Amiga, auf dem C und Modula-2 verfügbar waren. Die Vielfalt von nur für IBM-kompatible PCs verfügbaren Programmen zwang mich dann allerdings bald in diese Richtung... PS: mit Assembler habe ich nur sehr selten und sehr wenig gearbeitet.
:
Bearbeitet durch User
M.A. S. schrieb: > PS: mit Assembler habe ich nur sehr selten und sehr wenig gearbeitet. Wenn man als Schüler/Student in den 80er- und 90er-Jahren des letzten Jahrhunderts mit einem geringen Budget Microcontroller programmieren wollte, musste man das notgedrungen beherrschen. Assembler waren oft kostenlos oder recht billig im Gegensatz zu Compilern. Da wurden schnell mal einige kDM für einen C-Compiler fällig. Die heutige Jugend weiss gar nicht, in welchen pardiesischen Programmiererzeiten sie leben ;)
Allerdings. Meinen ersten 8051 Assembler hatte ich mir sogar selbst in Pascal geschrieben. Es gab halt nichts anderes (bezahlbar). Und das Pascal Paket kostete mehrere hundert DM, das war damals etwas mehr als ein halbes Azubi-Monatsgehalt.
Wem C zu kryptisch ist, dem empfehle auch ich LunaAVR. Diese Sprache ist sehr leicht zu erlernen. Auch die IDE LunaStudio ist sehr gut gelungen. Für große und kleine Projekte sehr gut geeignet ! http://avr.myluna.de/doku.php?id=de:download Einfaches Beispiel für blinkende LED
1 | avr.device = atmega168 |
2 | avr.clock = 8000000 |
3 | avr.stack = 32 |
4 | |
5 | #define LED1 as portB.0 'LED1 wird als Bezeichner für portB.0 definiert |
6 | LED1.mode = output,low 'Port als Ausgang definieren und auf Low setzen |
7 | |
8 | do |
9 | LED1 = 1 'LED einschalten |
10 | waitms 500 '500ms warten |
11 | LED1 = 0 'LED auschalten |
12 | waitms 500 '500ms warten |
13 | 'alternativ fuer die Befehle oben koennte man auch folgendes benutzen |
14 | 'LED1.toggle 'Aktuellen Status des PortPins umschalten (toggle) |
15 | 'wait 1 '1 Sekunde warten |
16 | loop |
Mr. K. schrieb: > #define LED1 as portB.0 'LED1 wird als Bezeichner für portB.0 > definiert Und http://gcbasic.sourceforge.net/help/__define.html Anscheinend haben sowohl LunaAVR als auch GCBasic die C-Makros als simple Textersetzung mit all ihren Problemen übernommen. "Moderne" Sprachen wie C#, Java, Python, ... erlauben so etwas nicht. Warum hat man das bei einer neuen sauberen Sprache übernommen?
> Warum hat man das bei einer neuen sauberen Sprache übernommen?
Weil das irgend jemand haben wollte. Auch in Java wurden nachträglich
zahlreiche Konstrukte anderer Sprachen übernommen, die als
fehlerträchtig gelten. Dabei sollte Java gerade damit aufräumen.
Wie ich schon sagte, jede Sprache verkommt irgendwann. Die
ursprünglichen Ziele gelten nicht mehr. Man fragt sich zu Recht, wofür
wir denn so viele prinzipiell gleichwertige Programmiersprachen
brauchen.
Die Oldies kehren dann wieder zu den alten Klassikern zurück, die sie am
Besten beherrschen. Die wurden ebenfalls weiter entwickelt und können
daher prinzipiell auch alles irgendwie.
Mr. K. schrieb: > Einfaches Beispiel für blinkende LED Das Problem ist nur, dass einfache Beispiele nichts aussagen. Einfache Programme kann man in jeder Sprache gut programmieren. Die Knackpunkte kommen dann bei realen komplexen Anforderungen.
Ralf H. schrieb: > Wenn man als Schüler/Student in den 80er- und 90er-Jahren des letzten > Jahrhunderts mit einem geringen Budget Microcontroller programmieren > wollte, musste man das notgedrungen beherrschen. Da hast Du ganz bestimmt recht. Was mich angeht, ich habe damals keine selbstgebauten Sachen programmiert sondern meinen Homecomputer und später PC. Mit Mikrocontrollern habe ich erst rumgemacht, als schon C-Compiler verfügbar waren. Ralf H. schrieb: > Die heutige Jugend weiss gar nicht, in welchen pardiesischen > Programmiererzeiten sie leben ;) Einerseits ja. Andererseits erhöht die verfügbare Vielfalt auch die Unübersichtlichkeit. Ich persönlich bin dankbar dafür, in einer Zeit aufgewachsen zu sein, in der man das Aufkommen und die Entwicklung allgemein verfügbarer Computerhardware miterleben konnte. Der Aufbau damaliger Computer war vergleichsweise übersichtlich und verstehbar, das kam mir sehr zugute. Wer heute anfängt, steigt notgedrungen auf einem so hohen Level ein, dass die Grundlagen weit entfernt sind und man viel weniger als damals druchschaut, was man gerade tut.
Mein posting galt dem TO >Was gibt es denn heute und für absehbare Zukunft an imperativen >Programmiersprachen die einigermaßen Hardwarenah sind und eine recht >einfache und klare Syntax haben? zu >Das Problem ist nur, dass einfache Beispiele nichts aussagen. Einfache >Programme kann man in jeder Sprache gut programmieren. Die Knackpunkte >kommen dann bei realen komplexen Anforderungen. Da wäre es doch mal interessant wenn jemand vom Fach sich neutral an einen Vergleich macht. Testen könnte man Programmgröße, Geschwindigkeit, Zuverlässigkeit
M.A. S. schrieb: > Wer heute anfängt, steigt notgedrungen auf einem so hohen Level ein, > dass die Grundlagen weit entfernt sind und man viel weniger als damals > druchschaut, was man gerade tut. Deswegen mein Augenzwinkern. Früher hatte man kaum eine Wahl. Heute hat man dafür die Qual :)) Vor allem nervt total, dass nach Auswahl, Anschaffung und Erlernens einer neuen Plattform diese schon wieder veraltet ist. Sogar Prozessoren, die erst vor zwei Jahre auf den Markt kamen sind schon wieder obsolet und man muss nach Ersatz suchen. Da macht das Entwickeln langsam keinen Spass mehr... Eventuell bin ich einfach auch nur alt geworden ;)
Ralf H. schrieb: > Heute hat > man dafür die Qual :)) > Vor allem nervt total, dass nach Auswahl, Anschaffung und Erlernens > einer neuen Plattform diese schon wieder veraltet ist. Nun ja, wenn man das als Hobby betreibt(?) zwingt einen niemand, ständig state of the art zu sein. AVRs z.B. gibt es ja nun schon ein paar Jahre, C-Compiler dafür ebenfalls. Nichts kann einen zwingen, einfach dabei zu bleiben (ausser braucht wesentlich mehr Performance). Von der Programmiersprach-Auswahl her ist das allerdings wieder ein klares Argument für C (weil bislang eben für [so ziemlich] jeden Controller verfügbar).
Mr. K. schrieb: > Da wäre es doch mal interessant wenn jemand vom Fach sich neutral an > einen Vergleich macht. Testen könnte man > > Programmgröße, Geschwindigkeit, Zuverlässigkeit Täte mich auch interessieren.
M.A. S. schrieb: > Wie erklärst Du, dass es so ist? Warum haben sich alle auf C gestürzt > und Pascal vernachlässigt, wenn C keine Vorteile bietet? Mein Infoprof hatte dafür den Spruch: Millionen Fliegen können nicht irren - und fressen Scheisse. Nun kommt gleich MaWin um die Ecke und erklärt: Das ist auch gut so, weil Scheisse für Fliegen das Beste ist. Nur bin ich keine Fliege.
M.A. S. schrieb: >> Programmgröße, Geschwindigkeit, Zuverlässigkeit > Täte mich auch interessieren. Ich habe meine Heizungssteuerung erst in ASM angefangen. Da ich endlich eine Hochsprache für den µC wollte, habe ich - weil das laut Forum das einzig Wahre ist - die Steuerung komplett auf C umgeschrieben. Ich finde es leichter, sich eine Sprache anhand eines bereits bekannten Konstrukts zu erarbeiten als mit einem komplett neuen Projekt anzufangen. Nebenher hab ich einige kleine Projekte nur in C angefangen (nRF24 Kommunikation...). Dann wollte ich die Steuerung erweitern, hatte aber sowas von keine Lust auf C mehr. Gleichzeitig ist mir Freepascal Compiler untergekommen und ich habe die Steuerung nochmal für Pascal umgeschrieben und erweitert. Ich habe mir dabei immer wieder den erzeugten Assembler-Code angesehen und muss sagen: Das nimmt sich nix. Die zusätzlichen Erweiterungen in Pascal abgezogen ist der erzeugte Code nahezu gleich groß. C optimiert hier besser, bläht dafür woanders Code auf, während Pascal dort wieder besser optimiert. Und bei Bitoperationen an den IOs oder Bitvergleichen nutzt Pascal die Möglichkeiten der AVRs optimal aus, das bekomme ich in Assembler nicht besser hin. Allerdings muss ich feststellen, dass ich bei Pascal deutlich weniger oft auf die Fresse fliege bei mathematischen Operationen, wo bei C schnell mal der Wertebereich überschritten wird. Und es gibt ein paar nette Gimicks wie bitpacked records. ABER: Ich programmiere, da ich vom Assembler komme auch hardwarenah, sprich keine Floats, keine ausufernden Stringoperationen. Achso, die Steuerung beinhaltet: Sensorerfassung, Auswertung, Fehlererkennung, Pumpenansteuerung mit Schwingungspaketen, Datenlogging, Display mit Menuführung, serielle Schnittstelle für Parametrisierung und Datenausgabe und so Kleinkram wie RTC. Ist also schon ausreichend umfangreich, um einen Vergleich zuzulassen.
Karl K. schrieb: > Gleichzeitig ist mir Freepascal Compiler untergekommen und > ich habe die Steuerung nochmal für Pascal umgeschrieben und erweitert. Danke für Deinen Erfahrungsbericht mit Freepascal. Ich kann mir denken, was Du mit Bereichsüberschreitungsproblemen in C meinst. Wodurch wird dieses in Pascal verhindert (noch dazu, wenn die Code-Größe vergleichbar ist)?
Frank M. schrieb: > genausowenig wie es verwendbare Pascal-Compiler für > µCs gibt. Daher ist diese ganze Diskussion C vs. Pascal für den TO wenig > hilfreich. Ach, gibt es nicht? Was programmier ich denn da gerade... Nur weil Du es nicht kennst, heisst das nicht, dass es nicht exisitert.
Karl K. schrieb: > Mein Infoprof hatte dafür den Spruch: Millionen Fliegen können nicht > irren - und fressen Scheisse. > > Nun kommt gleich MaWin um die Ecke und erklärt: Das ist auch gut so, > weil Scheisse für Fliegen das Beste ist. > > Nur bin ich keine Fliege. Karl K. schrieb: > Ach, gibt es nicht? > > Was programmier ich denn da gerade... Wenn Du es schaffen würdest, in einen REIN sachlichen Kommunikationsmodus zu wechseln, könnten wir vielleicht alle von Deinem Wissen profitieren, ohne, dass hier der tausend-und-erste Flame-War über die beste Programmiersprache ausbricht.
Peter D. schrieb: > In C sieht das nicht viel anders aus:float TemperaturinCelsius; > > void Lesetemperatur( void ) > { > TemperaturinCelsius = ADC(3)*1.11-68; > } Eine Multiplikation mit Floats auf einem ATtiny. Klingt man nach einer richtig guten Idee.
Karl K. schrieb: > Eine Multiplikation mit Floats auf einem ATtiny. Klingt man nach einer > richtig guten Idee. Kein Problem, solange der Code ins ROM passt.
Karl K. schrieb: > Nur weil Du es nicht kennst, heisst das nicht, dass es nicht exisitert. Ja, sorry, ich wusste es nicht besser. Ist auch schon längst vor Deinem Beitrag geklärt worden.
Karl K. schrieb: > Eine Multiplikation mit Floats auf einem ATtiny. Klingt man nach einer > richtig guten Idee. Das ist es auch. Damit vermeidet man, sich mit irgendwelchen Ganzzahltricks ein Bein zu stellen. Und selbst die 8-Pinner ATtiny85 haben schon 8kB Flash. Da sind die einmalig 1kB der float-Lib leicht zu verschmerzen.
Stefanus F. schrieb: > Wie ich schon sagte, jede Sprache verkommt irgendwann. > Die ursprünglichen Ziele gelten nicht mehr. Man fragt > sich zu Recht, wofür wir denn so viele prinzipiell > gleichwertige Programmiersprachen brauchen. Braucht man nicht. Das Problem ist: Man kann deren Entstehung nicht wirksam verhindern. Schöpfer von Programmiersprachen haben (notwendigerweise) von Compilerbau deutlich mehr Ahnung als der Durchschnitts- programmierer. In Kombination mit dem stets vorhandenen Spieltrieb (=Drang zum Overengineering) bewirkt das, dass jede Sprache ein Unzahl neuer (Fehler-)Möglichkeiten bietet -- aber nur ein kleiner Teil der neuen bzw. veränderten Eigenschaften ist wirklich sinnvoll. WELCHER Teil das ist, weiss man aber immer erst hinterher :)
> Wer heute anfängt, steigt notgedrungen auf einem so hohen Level ein, > dass die Grundlagen weit entfernt sind und man viel weniger als damals > durchschaut, was man gerade tut. Allerdings schätze ich, dass der Fortschritt noch weiter in diese Richtung gehen wird. Während in den 90er Jahren die bare-metal Grundlagen noch hilfreich waren, um einen guten Job zu machen, muss man heute eher damit klar kommen, sie eben nicht zu beherrschen. Im Enterprise Umfeld (nicht µC) kommt man gar nicht mehr umhin, Libraries und Frameworks zu verwenden, deren Funktionsweise völlig unklar ist. Man muss allerdings imstande sein, anhand der verfügbaren Doku herauszufinden, wie man sie korrekt verwendet. So wie man auch Auto fahren können muss, ohne einen blassen Schimmer von der Funktionsweise des Motors zu haben. Die Mikrocontroller wird dieses Schicksal hoffentlich erst nach meinem Ableben betreffen. Ich interessiere mich für µC und Elektronik nämlich gerade deswegen, weil ich mich dort noch mit Grundlagen beschäftigen kann. Das ist für mich ein netter und hilfreicher Ausgleich zum Job als Java Enterprise Programmierer. Die Grundlagen geben mir ein Gefühl von Sicherheit, welche ich im Job vermisse.
Hallo, > Ach, gibt es nicht? Ich habe gerade mal mit den Suchberiffen "free", "pascal" und avr" danach gesucht Und tatsächlich, Free Pascal Compiler (FPC) für AVR gibt es wirklich: http://wiki.freepascal.org/AVR Aber was muss ich da direkt in der ersten Zeile lesen: "Warning: The FPC-AVR port is experimental and might be broken from time to time. If this is the case, please fill a bug report" Also, ich kann da nur für mich sprechen, aber stände ich vor der Entscheidung des Diskusionsstarters, würde ich nicht mit einer experimentellen Portierung einer für mich unbekannten Programmiersprache anfangen wollen. In der zweiten Zeile steht dann: "It uses the GCC AVR tool chain and will be compatible with GCC regarding calling conventions etc." Aus offensichtlich pragmatischen Gründen orientiert sich FPC an der GCC-AVR-Tool-Chain. Dagegen ist ja im Prinzip nichts zu sagen, aber dann kann ich doch genau so gut direkt bei allen GCC-Werkzeugen, einschließlich des C-Compilers, bleiben. rhf P.S.: Die Art und Weise des "Inline-Assemblings" finde ich allerdings deutlich schöner gelöst als im GCC-C-Compiler. http://wiki.freepascal.org/AVR_Programming#Inline_assembler
Ja, früher, Ende 80iger / Anfang 90iger war es auch noch schwieriger. Hatte damals auch eine Arbeitsamt-Maßnahme zum PC-Programmierer (halbes Jahr ganztags) absolviert. Bevor man an den PC zum Programmieren durfte, mußte man erst das Rechnen mit den 3 Systemen (Dezimal, Binär und Hexadezimal) auf einem Blatt Papier beherrschen. Sowas braucht heutzutage keine Sau mehr. Höchstens, wenn man Zustände (an/aus) platzsparend binär speichern will.
Ralf H. schrieb: > Früher hatte man kaum eine Wahl. Im Sinne von "für diese HW". Insgesamt aber ist die Anzahl der Programmiersprachen wohl schon solange etwa 2000, wie das Öl noch 40 Jahre reicht.
M.A. S. schrieb: > Wenn Du es schaffen würdest, in einen REIN sachlichen > Kommunikationsmodus zu wechseln Wenn die C-Freaks es schaffen, mal andere Sprachen neben ihrem C zu aktzeptieren, denk ich wieder drüber nach.
Karl K. schrieb: > Wenn die C-Freaks es schaffen, mal andere Sprachen neben ihrem C zu > aktzeptieren, denk ich wieder drüber nach. Ich bin C-Freak und durchaus geneigt andere Sachen zu akzeptieren. Zwar würde ich nicht zu etwas anderem wechseln, wenn dieses andere nicht große Vorteile hätte, interessant finde ich es aber trotzdem und ich gehöre auch nicht zu denen, die etwas niederreden, bloß weil es nicht C ist.
:
Bearbeitet durch User
Roland F. schrieb: > Aber was muss ich da direkt in der ersten Zeile lesen: > "Warning: The FPC-AVR port is experimental and might be broken from time > to time. If this is the case, please fill a bug report" Das Problem bei den Tuts ist, dass die irgendwann mal geschrieben wurden und dann ewig rumstehen. Diese Warnung geht zurück auf 2008. Roland F. schrieb: > Aus offensichtlich pragmatischen Gründen orientiert sich FPC an der > GCC-AVR-Tool-Chain. Was schlichtweg daran liegt, dass der FPC wie auch der GCC die avr-binutils für die Übersetzung des Assembler-Codes in Maschinencode verwendet. Prinzipiell läuft das so ab, dass der Compiler für jede Unit Assembler-Code erzeugt, der dann mit noch einigen Extras wie Stackpointer- und Sram-Initialisierung aufgehübscht, zusammengelinkt und zur Übersetzung in Maschinencode an die binutils übergeben wird, die dann das .hex oder .elf File zurückgeben. Mit der Compileroption -al werden die zwischengenerierten Assemblerfiles nicht gelöscht, so dass man sich auch anschauen kann, was der FPC aus Deinem Code macht.
M.A. S. schrieb: > Zwar würde ich nicht zu etwas anderem wechseln, wenn > dieses andere nicht große Vorteile hätte, Was wäre denn ein hinreichend großer Vorteil, um zu wechseln?
Egon D. schrieb: > Was wäre denn ein hinreichend großer Vorteil, um zu > wechseln? Ich habe zur Zeit keinen speziellen Leidensdruck und warte auf nichts bestimmtes.
Jörg H. schrieb: > Hallo A-Freak, > > vielleicht ist MicroPython was für Dich: > https://en.wikipedia.org/wiki/Micropython Interessant, danke für die Info. Für den TO ist das aber nix: A-Freak schrieb: > Schwerpunkt wären ATTiny Ich habe am schnellsten hier etwas über MicroPython gefunden: https://www.digikey.de/de/articles/techzone/2017/sep/develop-real-time-mcu-based-applications-micropython Zu den Anforderungen heißt es dort: "Auswahl des richtigen Mikrocontrollers .... für die Ausführung von MicroPython eingesetzt werden soll: mindestens 256 KB Flash-Speicher mindestens 16 KB RAM mindestens einen mit 80 MHz getakteten Prozessor ..." Was dann doch ein wenig mehr ist, als der Durchschnitts-Tiny von heute aufzuweisen hat. ;)
:
Bearbeitet durch User
Karl K. schrieb: > Wenn die C-Freaks es schaffen, mal andere Sprachen neben ihrem C zu > aktzeptieren, denk ich wieder drüber nach. Die wenigsten sind vermutlich Freaks und die meisten einfach nur Pragmatiker. (Ich komm damit gut zurecht, also warum sollte ich was anderes wollen?) Was andere machen ist mir eigentlich völlig egal. NUR - Jeder sieht eben den Weg, den er gut kennt, als den einfachsten/besten an. Diejenigen, die nicht zur "Mehrheit" gehören, werden dann oft zu einer Art "Freiheitskämpfer", die alle "pro" Äußerungen zur verbreitetsten Sprache (hier C) gleich als Angriff auf Ihre Nischensprache sehen ;-) M.A. S. schrieb: > Wenn Du es schaffen würdest, in einen REIN sachlichen > Kommunikationsmodus zu wechseln, könnten wir vielleicht alle von Deinem > Wissen profitieren, +1
Volker S. schrieb: > Die wenigsten sind vermutlich Freaks und die meisten einfach nur > Pragmatiker. Der Hund des Nachbarn kläfft, der eigene gibt Laut. ;-)
Volker S. schrieb: > M.A. S. schrieb: >> Wenn Du es schaffen würdest, in einen REIN sachlichen >> Kommunikationsmodus zu wechseln, könnten wir vielleicht alle von Deinem >> Wissen profitieren, > +1 Danke. Und Zustimmung zu Deinem Beitrag. Ich kann Karl aber auch durchaus verstehen. Schließlich hat er weiter oben für seine Beitrag, in dem er Pascal und Ada erwähnt hat, drei Minusse bekommen, die er meiner Meinung nach nicht verdient (weshalb dort aktuell noch zwei Minusse stehen).
M.A. S. schrieb: > Schließlich hat er weiter oben für seine Beitrag, in dem er > Pascal und Ada erwähnt hat, drei Minusse bekommen, Von mir hat er im gesammten Thread bisher nur ein mal ein + bekommen. (Für den Post direkt nach den Ausschweifungen zu Fliegen und Mitkäfern ;-) Also kein Minus. (Da sollte man sich doch immer vorher überlegen, was man selber oft so schreibt) Ada und Pascal? Kann ich vermutlich nicht bewerten. <edit> und irgendwie auch nicht finden <edit2> ähhhm doch noch gefunden...
:
Bearbeitet durch User
Es gibt hier Leute, die verteilen Minusse mit der Gießkanne. Einfach nicht drauf schauen, die Bewertungen sind sowieso quatsch.
Volker S. schrieb: > Ada und Pascal? Kann ich vermutlich nicht bewerten. > <edit> und irgendwie auch nicht finden Karl K. schrieb: > Pascal, Ada. > > Freepascal kann Avr Embedded für Atmega und Attiny, auch AtXmega. Andere > Controller wie Pic und Stm wohl auch, hab ich aber noch nicht gemacht. > > Da Dir hier gleich erzählt wird, das ginge nur in C - wer nur einen > Hammer hat, kann halt nur nageln... oder so - such Dir das deutsche > Freepascal Forum, da kommst Du weiter. Hmm, vielleiiicht gab's die Minusse ja auch nicht wg. Pascal und Ada sondern für die Bemerkung weiter unten. Egal, trotzdem +1.
:
Bearbeitet durch User
Stefanus F. schrieb: > Es gibt hier Leute, die verteilen Minusse mit der Gießkanne. Einfach > nicht drauf schauen, die Bewertungen sind sowieso quatsch. Bei Leuten wie dem Blödmichel wäre es eigentlich gerechtfertigt, aber auch da wird es einem irgendwann zu blöd. Das sieht hoffentlich jeder, dass da nur Unsinn kommt.
Roland F. schrieb: > Die Art und Weise des "Inline-Assemblings" finde ich allerdings deutlich > schöner gelöst als im GCC-C-Compiler. Sie unterstützen aber auch nur einen Subset dessen, was der C-Compiler an Constraining beherrscht. Wenn ich das richtig sehe, dann sind das nur Konstanten und Speichervariable. Register muss man sich selbst mit der Hand zuweisen und dann als „clobber list“ angeben. Sowas kann die C-Version zwar auch, aber es ist in aller Regel die (von der Optimierung her) schlechteste Wahl, wenn man die Register als Programmierer selbst festlegt. Das Constraining innerhalb des C-Compilers gibt sich Mühe, dass man gegenüber dem Compiler letztlich seine Wünsche äußert („ich brauche ein Zeigerregister“, „ich brauche ein Register oberhalb r16“), er dann aber dennoch die Wahl hat, welche Objekte er konkret in welchen Registern hält. Damit steht man dem Compiler nicht mehr so dämlich bei der Optimierung im Weg herum. Kehrseite der Medaille ist natürlich, dass man viel mehr Feinheiten einschätzen muss, um eben ein vernünftiges Constraining zu formulieren. Letztlich ist diese Form von inline asm jedoch am besten geeignet dafür, in einer (System-)Bibliothek untergebracht zu werden, wo sie dann möglichst viele Leute nachnutzen können, die von den Untiefen des inline asm selbst einfach nichts mehr wissen müssen. Karl K. schrieb: > Wenn die C-Freaks es schaffen, mal andere Sprachen neben ihrem C zu > aktzeptieren, denk ich wieder drüber nach. Erstens gibt es vermutlich nur wenige „C-Freaks“. Zweitens weißt du bei den Diskutanten doch in der Regel gar nicht, was sie sonst noch alles akzeptieren. Du siehst doch eher nur, dass sie deinen Favoriten nicht so mögen. Darum ging's aber gar nicht, sondern du wurdest nur darauf hingewiesen, doch bitte sachlich zu bleiben. Das ist für eine vernünftige Diskussion ohnehin die Grundvoraussetzung. Sowie du unsachlich wirst, werden alle Mitdiskutanten sich wegdrehen nach dem Motto: „Wer schreit, hat Unrecht.“
Jörg W. schrieb: > Darum ging's aber gar nicht, sondern du wurdest nur darauf hingewiesen, > doch bitte sachlich zu bleiben. Das ist für eine vernünftige Diskussion > ohnehin die Grundvoraussetzung. Ach bitte, ich glaube Du bist lang genug im Forum um zu wissen, dass hier alles totgeredet wird womit man µCs programmieren könnte und was nicht C und C++ ist. Und das ohne sich überhaupt vorher zu informieren, so wie oben ein Moderator - also offenbar auch jemand, der nicht nur vorbeischaut - mal eben behauptet, Pascal wäre tot und es gäbe keinen Compiler für Pascal auf µC. Oder man postet Pascal-Code, und dann kommen so Kommentare wie "was soll das für eine Sprache sein".
Karl K. schrieb: > Ach bitte, ich glaube Du bist lang genug im Forum um zu wissen, dass > hier alles totgeredet wird womit man µCs programmieren könnte und was > nicht C und C++ ist. Das ist trotzdem keinerlei Begründung dafür, unsachlich zu werden. Davon abgesehen, ist es halt auf Controllern jenseits von C / C++ in der Tat nicht gerade übertrieben gut bestellt. Selbst, falls die genannte Pascal-Portierung des GNU-Pascal-Compilers mittlerweile viel besser ist als das, was da geschrieben steht: sie ist viel zu spät, um noch eine breite Akzeptanz zu erlangen. Die Welt hat sich weiter gedreht, Microchip entwickelt nach der Atmel-Übernahme durchaus AVRs weiter, aber für eher kleine Controller. Um gegen C irgendwie „anstinken“ zu können, bräuchte man mittlerweile wohl einen gut florierenden Pascal-Compiler, der zumindest die gängigeren Cortex-M unterstützt. Mich hätte es persönlich durchaus gefreut, wenn Ada an dieser Stelle ein wenig mehr Fahrt aufgenommen hätte, aber auch da ist nicht so viel los, wie man sich wünschen würde. Mit größer werdenden Controllern werden wir wohl in Zukunft stattdessen viel mehr mit Python oder vielleicht auch Lua zu tun haben denn Pascal oder Ada – so meine Vermutung.
Hallo, Karl K. schrieb: > Das Problem bei den Tuts ist, dass die irgendwann mal geschrieben wurden > und dann ewig rumstehen. > > Diese Warnung geht zurück auf 2008. Na ja, das sind immerhin 10 Jahre und spricht nicht gerade für die Wichtigkeit der AVR-Variante. > Was schlichtweg daran liegt, dass der FPC wie auch der GCC die > avr-binutils für die Übersetzung des Assembler-Codes in Maschinencode > verwendet... Das ist interessant und, wie ich finde, eine gute Idee AVR-Code zu erzeugen. rhf
Hallo, Jörg W. schrieb: > Mit größer werdenden Controllern werden wir wohl in Zukunft stattdessen > viel mehr mit Python oder vielleicht auch Lua zu tun haben denn Pascal > oder Ada – so meine Vermutung. Warum in der Zukunft? Warum nicht jetzt? In den Anfängen der "Computerei" wurden 8 oder 16-Bit-Rechner mit ein paar Kilo-Byte RAM eingesetzt und den damals verfügbaren BASIC-Interpretern programmiert. Heute verfügen Controller über Speichergrößen und Rechenleistungen, die damaligen Großrechnern entsprechen und das reicht nicht aus um eine, Entschuldigung, popelige Script-Sprache laufen zu lassen? rhf
Roland F. schrieb: >> Diese Warnung geht zurück auf 2008. > > Na ja, das sind immerhin 10 Jahre und spricht nicht > gerade für die Wichtigkeit der AVR-Variante. Nein -- es spricht dafür, dass (wie üblich) viel zu wenig Arbeitskraft für Dokumentation vorhanden ist.
Ein recht gutes Basic, vor allem kostenlos, ist Great Cow Basic. Ist auf die AVRs abgestimmt. Einfach mal anschauen.
Beitrag #5533363 wurde von einem Moderator gelöscht.
Roland F. schrieb: >> Mit größer werdenden Controllern werden wir wohl in Zukunft stattdessen >> viel mehr mit Python oder vielleicht auch Lua zu tun haben denn Pascal >> oder Ada – so meine Vermutung. > > Warum in der Zukunft? Warum nicht jetzt? Mach doch. ;-) OK, Lua ist ja mittlerweile da schon ein bisschen angekommen. Python gibt es zwar, aber ich habe noch nicht viele Leute gesehen, die es wirklich dafür nutzen.
Jörg W. schrieb: > OK, Lua ist ja mittlerweile da schon ein bisschen angekommen. Python > gibt es zwar, aber ich habe noch nicht viele Leute gesehen, die es > wirklich dafür nutzen. Was der Bauer nicht kennt... Ich möcht gar nicht wissen wie viele Mannjahre allein durch konservative Entwicklungsleiter vernichtet werden die meinen man könne Prototypen oder Testgeräte ausschließlich mit C programmieren. Dabei bieten sich Skriptsprachen wie Lua oder Python hierfür optimal an. Selbiges gilt übrigens für den Hobbygebrauch. Eine Heizungssteuerung für daheim in C, Pascal, Assembler oder sonst was zu schreiben klingt für mich nach dem ewigen Fegefeuer. Was für eine Verschwendung von Lebenszeit.
Vincent H. schrieb: > Was der Bauer nicht kennt. Das ist eine ziemlich kurzsichtige Anschuldigung. Python hat sich im PC-Bereich gut breitgemacht, obwohl auch dort „der Bauer das nicht kannte“. Gerade im Hobbybereich gibt es ja durchaus Akzeptanz für Werkzeuge jenseits des Mainstreams – siehe Bascom-AVR. Man sollte es also nicht immer auf „die anderen“ schieben, wenn etwas nicht so greift, wie man das erwartet.
Jörg W. schrieb: > Das ist eine ziemlich kurzsichtige Anschuldigung. Sry aber das Forum beweist immer wieder eindrucksvoll dass das alles andere als kurzsichtig ist. Die die am lautesten Schreien sind immer die, die am wenigsten Ahnung und meist keinen Dunst haben. Siehe Karl K., der Pascal Evangelist... Die, die sachliche und objektive Beiträge schreiben werden niedergebrüllt und runtergevoted (siehe Dr.Sommers Post über Python ganz oben der ein -1 hatte). Dabei kommen jene Beiträge immer von Leuten die tatsächlich mehrere Sprachen beherrschen und damit vernünftige Aussagen über deren Anwendungsgebiet, deren Stärken und Schwächen machen können. Ich würd ja jetzt noch meinen Senf zum eigentlichen Thema dazugeben, aber der Thread ist eh schon wieder lange tot und ... ja Lebenszeit und so.
:
Bearbeitet durch User
Was erwartest du? Ein Diskussion über Computersprachen, hat immer mit persönlichen Vorlieben zu tun. Und mit Sachzwängen. Sobald sich Vorlieben unterscheiden, ist der Startimpuls für Grabenkriege und Eskalationsspiralen gesetzt. Ganz normal.... Dumm, völlig dumm, aber normal.
Egon D. schrieb: > Nein -- es spricht dafür, dass (wie üblich) viel zu > wenig Arbeitskraft für Dokumentation vorhanden ist. Es gibt durchaus brauchbare Doku und Tuts dazu, momentan im AVR Bereich vor allem deutschsprachige. Allerdings erstellen diese Leute dann eher eigene und kapern nicht andere und noch dazu anderssprachige Einträge.
Arduino Fanboy D. schrieb: > Was erwartest du? > > Ein Diskussion über Computersprachen, hat immer mit persönlichen > Vorlieben zu tun. Und mit Sachzwängen. Das seh ich nicht so. Ich bin Ingenieur und kein Linguist. Natürlich hab ich auch eine Meinung über die Ästhetik einer Sprache, darüber streite ich aber mit niemandem. Genauso wenig hab ich einen persönlichen Bezug zu dem Werkzeug das ich nutze. Ab und zu fühl ich mich hier so als würd der Dreher dem Fräser vorschlagen seine Nut auf der Drehbank zu "fräsen"...
Hallo Vincent, Vincent H. schrieb: > Genauso wenig hab ich einen persönlichen Bezug zu dem Werkzeug das ich > nutze. Ab und zu fühl ich mich hier so als würd der Dreher dem Fräser > vorschlagen seine Nut auf der Drehbank zu "fräsen"... ob nun Betriebssystem oder Programmiersprache, die Forendynamik bei diesen Themen ist immer diesselbe. Leute, die mehrere Werkzeuge zur Lösung von Problem besitzen, weisen sachlich auf das richtige Werkzeug hin. Diejenigen, die nur ein Werkzeug kennen, fühlen sich im Innersten minderwertig, dass ein anderes Werkzeug besser sein soll, das sie nicht beherrschen. Dieser Minderwertigkeitskomplex wird dann durch lautes Geschrei, dass das eigene Werkzeug das Beste für die Problemlösung sei, bewältigt.
Vincent H. schrieb: > niedergebrüllt und runtergevoted (siehe Dr.Sommers Post über Python ganz > oben der ein -1 hatte). Eine Bewertung von -1 betrachte ich weder als "niedergebrüllt" noch als "runtergevoted", sondern liegt noch im Rauschen.
Ich halte fest. A-Freak (Gast) ist kein Troll, sondern hat ernst gemeinte Ratschläge gewollt und auch bekommen. Ich möchte zu Luna anmerken, dass ich das durchaus als Alternative anerkenne. Ich arbeite momentan nahezu ausschliesslich mit PIC. Stehe AVR aber nicht ablehnend gegenüber, werde ich bestimmt auch mal nutzen. Aus meiner Perspektive ein klares Plus, wenn ich schon Erfahrung mit einem Compiler habe, der beide Prozessor Familien unterstützt. Als Hobby Tüftler mache ich vielleicht 1-3 Sachen im Jahr, da muß man sich überlegen, ob man zwischendurch mal die Sprache wechselt. Ich bin mit Great Cow BASIC bisher gut gefahren. Dazu kommt, sollte ich wirklich in die Verlegenheit kommen und eine Library für einen exotischen Sensor o.ä. benötigen, dann erleichtert mir der Zugriff auf alle Sourcen der mitinstallierten Libs dies ausserordentlich. So bin ich übrigens überhaupt zu GCBASIC gekommen, weil ich mich für ein OLED Display eine Bibliothek suchte und bei Great Cow BASIC fündig wurde. Was nebenbei bemerkt recht leicht ist, ich glaube es werden fast alle Grafik Displays unterstützt, wenn sie älter als ein paar Monate sind... Ich habe in den entsprechenden Artikeln hier auf mc.net Einträge um GCBASIC ergänzt. Ich fand, das fehlte.
Karl K. schrieb: > Egon D. schrieb: >> Nein -- es spricht dafür, dass (wie üblich) viel zu >> wenig Arbeitskraft für Dokumentation vorhanden ist. > > Es gibt durchaus brauchbare Doku und Tuts dazu, momentan > im AVR Bereich vor allem deutschsprachige. Mag ja sein. Bei der testweisen Nutzung von FreePascal in einem Projekt habe ich den Eindruck gewonnen, dass die offizielle Projekt- dokumentation schlecht strukturiert ist und man über die Aktualität im Zweifel gelassen wird. Das ist auch kein Vorwurf, sondern eine rein sachliche Feststellung, denn die Schwierigkeiten müssen rein aufgrund der schieren Größe des Projektes beträchtlich sein. Es ist mir völlig logisch, dass Programmierer lieber programmieren als die Dokumentation zu pflegen. Van Canneyt tut da einiges, aber die Ergebnisse würde ich als durchwachsen bezeichnen. > Allerdings erstellen diese Leute dann eher eigene und > kapern nicht andere und noch dazu anderssprachige Einträge. Du hast eine merkwürdige Art, Dir die Welt so zu machen, wie sie Dir gefällt. Von offizieller Projektdokumentation erwarte ich, dass die Dokumente bei Bedarf aktualisiert (und die alten gut zugänglich archiviert) werden. Nennst Du das "kapern"? Von jeder Art Dokumentation (offizieller wie privater) erwarte ich, dass eindeutig klar wird, auf welchen Stand der Software, welche Compilerversion etc. sie sich bezieht.
Vincent H. schrieb: > Die, die sachliche und objektive Beiträge schreiben > werden niedergebrüllt und runtergevoted (siehe > Dr.Sommers Post über Python ganz oben der ein -1 > hatte). Dabei kommen jene Beiträge immer von Leuten > die tatsächlich mehrere Sprachen beherrschen und > damit vernünftige Aussagen über deren Anwendungsgebiet, > deren Stärken und Schwächen machen können. Du übersiehst das Kernproblem. Diejenigen, die mehrere Programmiersprachen so beherrschen, dass sie fundierte Aussagen darüber machen können, haben in der Regel einen beträchtlichen theoretischen und empirischen Wissenshintergrund, was die Programmiersprachen angeht. Häufig interessieren sie sich für den Computer als Ding an sich, als Gegenstand der Forschung. Die Proteste kommen von den Leuten, die im Computer ein Hilfsmittel sehen, das sie lediglich sach- und fachgerecht verwenden wollen. Für diese Leute -- zu denen ich mich auch zähle -- ist nicht einzusehen, wieso man eine geradezu babylonische Sprachverwirrung schaffen muss, um genau dieselben Probleme wie vor 30 oder 50 Jahren auf immer wieder andere, aber stets kompliziertere Weise als früher zu lösen. Es besteht der Eindruck, dass künstlich (Stichworte: Spiel- trieb, Overengineering) eine Kompliziertheit geschaffen oder gefördert wird, die gar nicht notwendig wäre, wenn man sich auf die Problemlösung fokussieren würde.
Egon D. schrieb: > Es besteht der Eindruck, dass künstlich (Stichworte: Spiel- > trieb, Overengineering) eine Kompliziertheit geschaffen > oder gefördert wird, die gar nicht notwendig wäre, wenn man > sich auf die Problemlösung fokussieren würde. Es ist wesentlich einfacher, eine neue Sprache zu definieren, als eine bereits gut eingeführte Sprache offziell zu verändern.
A. K. schrieb: > Egon D. schrieb: >> Es besteht der Eindruck, dass künstlich (Stichworte: Spiel- >> trieb, Overengineering) eine Kompliziertheit geschaffen >> oder gefördert wird, die gar nicht notwendig wäre, wenn man >> sich auf die Problemlösung fokussieren würde. > > Es ist wesentlich einfacher, eine neue Sprache zu definieren, > als eine bereits gut eingeführte Sprache offziell zu verändern. Klar -- aber das erklärt nicht, warum man (=ich) bei neuen Sprachen häufig den Eindruck hat, sie würfen genau DAS über den Haufen, was an den alten Sprachen gut war, und fügten komplizierten neuen Krempel hinzu, den nur Informatik- Studenten für den "obfuscation contest" brauchen.
Es gibt immer wieder jemanden, der für seinen aktuellen Anwendungsfall eine spezialisierte Programmiersprache (oder ein Framework) erfindet. So mag es gelingen, die Programmierung einfacher Roboter (Linienverfolger und so) mit seiner neuen Sprache sogar 8 jährigen Kindern verständlich zu machen. Dann dreht er die große Werbetrommel, was dazu führt, dass auch Erwachsene diese neue Programmiersprache ernsthaft einsetzen wollen. Plötzlich stellt sich heraus, dass die Abfrage einfacher Schalter, Distanz-Sensoren und das Steuern von zwei Antriebsmotoren nicht genügt. Man will auch Internet Kommunikation vereinfachen. Und schwupps, wächst das Paket auf die zehnfache Größe an. Der Nächste will ein grafisches Touch-Screen Display benutzen. Da Grafik ursprünglich gar nicht vorgesehen war, kommt ein großer Balkon aus Libraries an die neue Programmiersprache. Natürlich zu nichts bekanntem kompatibel - es soll ja nach wie vor auf irgendwie auf den ursprünglichen kleinen µC laufen, die immer noch im diversen Baukästen im Handel sind. Und so kommt es, dass die neue elegante kompakte einfache Programmiersprache all dies nicht mehr ist. Schaut euch doch mal die großen aktuellen Sprachen an. Die Unterschiede zwischen C++, Java und .NET sind meiner Meinung nach verschwindend gering. Wer mehr Sprachen kennt kann dieser Liste sicher noch einige andere hinzufügen. Am Ende der Entwicklungsphase (>20 Jahre) kann jede Sprache fast alles fast gleich. Es sei denn, sie bleibt ihrer ursprünglichen Spezialisierung treu.
Egon D. schrieb: > Von jeder Art Dokumentation (offizieller wie privater) > erwarte ich, dass eindeutig klar wird, auf welchen Stand der > Software, welche Compilerversion etc. sie sich bezieht. Du hast schon verstanden, was das "Free" in Freepascal bedeutet? Leute machen das größtenteils freiwillig und in ihrer Freizeit. Und zumindest im deutschsprachigen Forum wird angefragt, wenn da jemand ein Tut geschrieben hat, ob man das erweitern darf. Ja, ich hätte das auch gern, dass immer deutlich da steht, von wann das ist und auf welche Version es sich bezieht. Die Welt ist aber nicht ideal und auch bei anderen Projekten ist das so. Wie oft hab ich ein Tut zum Raspberry gefunden, welches mein Problem lösen könnte, um dann festzustellen: Nee, bezieht sich auf Jessie, geht mit Stretch ganz anders, oder geht nur auf dem RPi 2. Da muss man halt mal gucken. Dafür gibt es eine Erfindung namens Internet. Ist ja nicht mehr so, dass man wie vor 30 Jahren mit "Basic für den Kleincomputer KC85" eine Programmiersprache gelernt hat und keine anderen Quellen hatte. Egon D. schrieb: > Bei der testweisen Nutzung von FreePascal in einem Projekt > habe ich den Eindruck gewonnen, dass die offizielle Projekt- > dokumentation schlecht strukturiert ist... Zumindest zu allen Befehlen, die ich bisher brauchte hab ich schnell die Beschreibung gefunden. So schnell, dass ich lieber in der Online-Doku geschaut habe, als mich durch die durchaus auch vorhandenen zahlreichen Beispielcodes in der Installation zu hangeln. Und ganz ehrlich, ich hab ja oben geschrieben, dass ich mal C für µC und PC versucht habe. Da war das noch viel mehr Sucherei und Code aus Beispielen raussuchen, und der Buildprozess mit make war eher Glückssache als deterministisch. Das kommt Dir nur besser vor, weil Du es schon länger kennst und dran gewöhnt bist.
Karl K. schrieb: > Egon D. schrieb: >> Von jeder Art Dokumentation (offizieller wie privater) >> erwarte ich, dass eindeutig klar wird, auf welchen Stand >> der Software, welche Compilerversion etc. sie sich bezieht. > > Du hast schon verstanden, was das "Free" in Freepascal > bedeutet? Ja, das habe ich. Und -- nein, ich gehe nicht weiter auf Dein Gestänkere ein. Auf dieses "Niveau" lasse ich mich nicht herabziehen. Soweit ich das über die Jahrzehnte beobachten konnte, leiden viele FOSS-Projekte unter genau dem Problem, dass die faktische Entwicklung schneller ist, als die Dokumentation folgen kann. Das ist für neue bzw. sporadische Nutzer der Software ziemlich ärgerlich. Wenn Du eine nüchterne und sachliche Tatsachenfeststellung immer als Anlass zum Rumgepisse nehmen musst, dann ist das eben so. Ich bin IPx5 (strahlwasserfest). > Egon D. schrieb: >> Bei der testweisen Nutzung von FreePascal in einem Projekt >> habe ich den Eindruck gewonnen, dass die offizielle Projekt- >> dokumentation schlecht strukturiert ist... > > Zumindest zu allen Befehlen, die ich bisher brauchte hab ich > schnell die Beschreibung gefunden. Siehst Du, und ich eben nicht. Ich bin Debian-User; Debian hängt bekanntermaßen oft ziemlich hinterher. Es hat teilweise erheblicher Sucherei in der Online- Doku bedurft, um herauszufinden, welche Aussage denn nun für MEINE Compilerversion zutreffend ist.
Egon D. schrieb: > Ich bin Debian-User; Debian hängt bekanntermaßen oft ziemlich > hinterher. Und das ist jetzt Schuld der Freepascal-Entwickler, dass Debian die Pakete jahrelang abhängen läßt? Ich installiere Freepascal und Lazarus mittlerweile nur noch über den Installer, weil die Pakete immer hoffnungslos veraltet sind. Egon D. schrieb: > Soweit ich das über die Jahrzehnte beobachten konnte, leiden > viele FOSS-Projekte unter genau dem Problem, dass die > faktische Entwicklung schneller ist, als die Dokumentation > folgen kann. Das ist doch nicht nur bei Foss so. Wenn eine Doku mal aktuell ist, dann weil sich am Programm seit Jahren nix getan hat. Oder die Doku ist nur Geschwafel und man muss sich die relevanten Infos doch anderweitig im Internet zusammensuchen. Andererseits kenne ich das Problem auch vom eigenen Doku schreiben: Wie machst Du das am besten? Der eine liest und denkt sich "erzähl mir was Neues", dem anderen müsstest Du eigentlich erstmal die Grundlagen erklären, weil für ihn "das Internet" der große bunte Kreis ist.
Karl K. schrieb: > Egon D. schrieb: >> Ich bin Debian-User; Debian hängt bekanntermaßen >> oft ziemlich hinterher. > > Und das ist jetzt Schuld der Freepascal-Entwickler, > dass Debian die Pakete jahrelang abhängen läßt? Siehst Du, genau das ist der Grund, warum Diskussionen mit Dir so nervtötend sind: Ich habe immer das ungute Gefühl, Du drehst mir die Argumente absichtlich im Mund herum. Nein, es ist natürlich nicht die Schuld der FreePascal-Leute, dass die Debian-Pakete hinterherhängen -- es ist die Schuld der FreePascal-Leute, dass aus deren Dokumentation nicht eindeutig hervorgeht, für welche Compilerversion sie gilt. War das wirklich so schwer zu verstehen? > Ich installiere Freepascal und Lazarus mittlerweile nur > noch über den Installer, weil die Pakete immer hoffnungslos > veraltet sind. Mir ist weitgehend wurst, wie alt mein Compiler ist, wenn ich eine Doku habe, die auf genau diese Version zutrifft. > Egon D. schrieb: >> Soweit ich das über die Jahrzehnte beobachten konnte, >> leiden viele FOSS-Projekte unter genau dem Problem, >> dass die faktische Entwicklung schneller ist, als die >> Dokumentation folgen kann. > > Das ist doch nicht nur bei Foss so. Nein -- aber es zeigt sich dort in besonderer Schärfe. Bei kommerziellen Auftragsentwicklungen steigt Dir der Kunde schon auf's Dach, wenn die Doku zwar Vertrags- bestandteil war, aber von Dir nicht geliefert wird. Bei FOSS wird halt keine Dok geschrieben, wenn keiner Lust dazu hat. > Andererseits kenne ich das Problem auch vom eigenen Doku > schreiben: Wie machst Du das am besten? Der eine liest > und denkt sich "erzähl mir was Neues", dem anderen müsstest > Du eigentlich erstmal die Grundlagen erklären, weil für > ihn "das Internet" der große bunte Kreis ist. Natürlich -- GUTE Dokumentation schreiben ist eine Kunst. Aber um das Problem zu LÖSEN, muss man erstmal anerkennen, dass es überhaupt ein Problem GIBT -- und nicht immer mit "Wenn Du zu blöd bist, lass es einfach bleiben" kontern.
Egon D. schrieb: > Mir ist weitgehend wurst, wie alt mein Compiler ist, wenn > ich eine Doku habe, die auf genau diese Version zutrifft. Es gibt für jede Version von FPC einen Satz zugehöriger Dokumentation. Wenn Du zum Beispiel den 2.4.4 nutzt dann lädtst Du Dir die 2.4.4er Doku runter: https://sourceforge.net/projects/freepascal/files/Documentation/
Beitrag #5534805 wurde vom Autor gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.