Nur aus reinem Interesse: Gibt es hier jemanden der ernstzunehmende Programme in BASCOM schreibt? Beantwortet bitte nur die Frage, wenn jemand über „BASCOM vs. Irgendeine andere Programmiersprache“ diskutieren will: Jeder kann sich hier einen eigenen Thread dafür aufmachen.
:
Verschoben durch Moderator
Ich bin jetzt Kein Basic Fan, aber man kann da auch ordentlich was machen von der Perfotmance ist es halt schlechter als c oder Assembler. Bei Basecom bist du halt nicht so nahe an der Hardware.
(Gast) schrieb: > Beantwortet bitte nur die Frage, wenn jemand über „BASCOM vs. Irgendeine > andere Programmiersprache“ diskutieren will: Jeder kann sich hier einen > eigenen Thread dafür aufmachen. Oh schon wieder....
(Gast) schrieb: > Nur aus reinem Interesse: Gibt es hier jemanden der ernstzunehmende > Programme in BASCOM schreibt? Ja, denn ich schreibe Programme, die einen Zweck erfüllen und funktionieren; demnach ernstzunehmen sind. @Jan R. Warum hast du geantwortet?
Ob ein Programm "ernsthaft" ist oder nicht, macht sich nicht an der Programmiersprache fest. Nur weil eine bestimmte IDE es erlaubt, unübersichtlich und liederlich zu progrsammieren, muss man das ja nicht so machen. Ein guter Programmierer hat sicher seine persönliche Lieblingssprache oder gewisse Zwänge (z.B. verfügbare Bibliotheken, Teamarbeit) bedingen eine konkrete Programmierumgebung - d.h. aber nicht, dass alles andere automatisch Mist ist.
:
Bearbeitet durch User
Hallo, auch wenn gleich wieder viele über Bascom schimpfen werden hier unsere Erfahrung und Nutzung: Wir nutzen es für alle Elektroniken und zwar ausschließlich. C wird zwar ebenfalls beherrscht. Die Software für die MCUs lässt sich mit Bascom wesentlich schneller erstellen als mit C (ACHTUNG: Unsere Erfahrung, andere sehen das bestimmt etwas anders). Man muss aber erstmal sehr viel Erfahrung mit Bascom gesammelt haben, um Projekte damit Umzusetzen. Es gibt immer wieder mal Stellen an denen man sonst hängen bleibt (Ohne ersichtlichen Grund). Ist man damit vertraut, dann können sehr gute Programme in sehr kurzer Zeit erstellt werden. Für richtig Zeitkritische Anwendungen (RT) sehe ich Bascom eher als schwierig an.
Normalerweise antworte ich nicht auf solche Fragen von einem (Gast), weil es oft genug nach Stunksuche aussieht. Trotzdem: Hier ein Link zur Codesammlung von MCS-Electronic (Hersteller von Bascom). Dort kannst Du auch ziemlich umfangreiche und anspruchsvolle Aufgaben- lösungen finden: http://www.mcselec.com/index.php?option=com_content&task=category§ionid=7&id=79&Itemid=57
Es gibt Leute, die haben ein Problem zu loesen, und verwenden nun Bascom. Moeglicherweise weils schneller geht.
Bascomnutzer schrieb: > Für richtig Zeitkritische Anwendungen (RT) sehe ich Bascom eher als > schwierig an. Daß Inline-Assembler möglich ist, ist Dir nicht bekannt?
Kai Mauer schrieb: > Daß Inline-Assembler möglich ist, ist Dir nicht bekannt? Das ist bekannt. Es gibt immer eine Möglichkeit sowas zu lösen. Die Frage ist immer wie RT die Anwendung sein muss. Die Reaktion auf einen Interrupt ist so leicht umzusetzen. Wenn die RT Anforderung sehr komplex ist, dann wird es schon aufwendiger. Je nach Projekt.
Hallo, jede Sprache hat ihre Vor und Nachteile. Nutze selber auch Bascom, ab und zu auch in Verbindung mit Assembler. Gruß fragender
(Gast) schrieb: > Gibt es hier jemanden der ernstzunehmende Programme in BASCOM schreibt? Ist dir der Vektor-Antennen-Analyzer FA-VA3 von DL1SNG „ernsthaft“ genug?
Ich programmiere das Meiste in Bascom... der Umfang an fertigen Funktionen ist enorm und eine Idee ist nullkommanix in Code umgesetzt. Ich habe anfangs auch schon Funktionen selbst gebaut, bevor ich bemerkt habe, dass diese in den unzähligen Bascom-Funktionen bereits vorhanden sind. Das Einzige was mich wirklich nervt, ist die Tatsache, dass im Code als Operanden keine arithmetische Mehrfachoperationen oder Klammerausdrücke verwendet werden können, so dass man alles in Einzelschritten erledigen muss. Ich kann es nicht nachvollziehen, wieso man sich seitens der Entwickler durch diese Flapsigkeit den Sprung über die semiprofessionele Hürde hinaus vergeben hat. Durch die Möglichkeit, an jeder Stelle auch Assemblerbefehle verwenden zu können, relativiert sich dieses Manko etwas, indem man manche Abläufe eben auf Registerebene erledigt. Ausserdem lassen sich selbstgestrickte Assemblerfunktionen als Bibliotheken einbinden. Ich programmiere eh gerne maschinennah und weiß dann, was der µC im Detail macht, ob und wo noch Optimierpotenzial ist. Wenn ich mir den compilierten Bascom-Code im Disassembler anschaue, kann ich nicht feststellen, dass Bascom generell "langsamen" Code generiert. Manches würde ich in Handarbeit vielleicht anders angehen. Es hängt wie immer von den eigenen Erfahrungen und nicht zuletzt von der Kenntnis der unzähligen Bascom-Funktionen ab, wie komplex und effektiv man damit coden kann. Gruss
Man liest immer wieder "Bascom, weils schneller geht". Heutzutage ist schnell doch eigentlich das wichtigste! Bascom müßte demnach viel populärer sein. Warum heißt es hier also immer C ist besser, bzw. wird gegen Bascom geflamt (ehrliche Frage)?
kamillentee schrieb: > Man liest immer wieder "Bascom, weils schneller geht". Heutzutage ist > schnell doch eigentlich das wichtigste! Bascom müßte demnach viel > populärer sein. jeder der regelmäßig µC Programm hat auch in C seine eigenen libs, damit ist es auch nicht langsamer als mit Bascom.
Es gibt Leute (C), die schwatzen viel von Portierbarkeit. Andere wollen nur ein Problem geloest haben und nachher vergessen. Ja, es gibt auch Loesungen, die man portieren moechte. Sofern das denn ueberhaupt geht.
Jetzt Nicht schrieb: > Andere wollen nur ein Problem geloest haben und nachher vergessen. Das ist kein Grund, denen, die in C programmieren, zu unterstellen, dass sie etwas anderes möchten. Auch die wollen ihr Problem gelöst haben und es danach vergessen. Wenn man die Sprache kennt und sich über die Zeit seine eigenen Codeschnipselchen oder Bibliotheken gezimmert hat und/oder auf solche aus dem Netz zurückgreifen kann, ist das absolut kein Problem. Aber es ist eben auch überhaupt keine Frage, dass man deshalb nun mit einem Tool wie Bascom irgendwie schlechter arbeiten müsste als jemand, der all seinen Kram in C macht. Bascom hat neben der anderen Programmiersprache einfach einen anderen Anspruch und verhilft damit (vermutlich – ich kenne es nicht selbst) Einsteigern und Gelegenheitsprogrammierern zu einem schnellen Start.
@kamillentee Jeder der "seine" Programmiersprache aus dem FF kennt, beherrscht und im Detail versteht was dabei auf der Hardware abläuft, kann damit schnell und effektiv coden. Jedem Tierchen sein Plaisierchen... Dem Basic-Dialekt als solchem, hängt ja leider noch der urzeitliche Nimbus einer Interpreter-Ausführung an, die im Gegensatz zum Compiler-Basic oder sonstigen compilierten Hochsprachen doch deutlich langsamer war. Aus dieser Ecke, des leicht verständlichen, hardwarefernen Dialekts für Anfänger, der langsamen Code produziert, kann sich Basic eben nur schwer befreien. Dabei steht die Funktionsvielfalt, die hardwarenahe Einflussmöglichkeiten und die Geschwindigkeit des generierten Codes der modernen Basic-Varianten, den anderen Sprachen in nichts mehr nach. Bei den Basic-Dialekten erscheint mir die Syntax ungeschlagen intuitiv und spontan einleuchtend, so dass jeder Neueinsteiger und jeder "Fremdsprachler" sowieso, den Quellcode ohne Klimmzüge verstehen kann. Bei den anderen Hochsprachen geht das ohne gründliche Einarbeitung in ihre syntaktischen und systemischen Eigenarten nicht so einfach. Auch was das Procedere der Weitergabe der Quellcodes und den diversen Dateien und Bibliotheken zur Compilierung betrifft.
kamillentee schrieb: > Man liest immer wieder "Bascom, weils schneller geht". Heutzutage ist > schnell doch eigentlich das wichtigste! Bascom müßte demnach viel > populärer sein. > Warum heißt es hier also immer C ist besser, bzw. wird gegen Bascom > geflamt (ehrliche Frage)? Weil es (zu oft) nicht stimmt. Bascom ist nur dann schneller, wenn man von den mitgelieferten fertigen Modulen profitiert. Wenn man etwas erledigen will wofür es kein fertiges Modul gibt, geht es entweder langsam oder schlimmstenfalls gar nicht. Bascom ist vergleichbar mit Fertigteilhäusern. C ist ein Haufen Steine, Mörtel und eine Auswahl an Maurerkellen. Assembler ist eine Lehmgrube. Und so wie es auf dieser Stufenleiter immer mehr einzelne Schritte zum fertigen Haus werden, je (scheinbar) einfacher das gewählte Werkzeug ist, so steigen andererseits auch die kreativen Möglichkeiten. Aus Steinen kann man ein Haus bauen, daß es als Fertighaus nicht gibt. Aus Lehm kann man sich sogar Ziegel in einer Form machen, die man sonst nicht fertig bekommt.
Axel Schwenke schrieb: > Aus Lehm kann man sich sogar Ziegel in einer Form machen, die man sonst > nicht fertig bekommt. Aber es ist eben noch mehr Aufwand. ;-) Andererseits kann man gewiss auch im Fertigteilhaus problemlos leben, sofern man nicht gerade Extrawünsche hat, für die es keine Fertigteile gibt und die sich auch nicht ohne Weiteres in das Fertigteilkonzept integrieren lassen.
Solange ich an jeder Stelle Assemblerbefehle im Quellcode platzieren kann, habe ich mit Bascom ein Fertighaus mit Lehmgrube... muss ja nicht immer ein Swimmingpool sein... ;-)
Axel Schwenke schrieb: > Bascom ist vergleichbar mit Fertigteilhäusern. C ist ein Haufen Steine, > Mörtel und eine Auswahl an Maurerkellen. Assembler ist eine Lehmgrube. Das erscheint mir nicht ganz richtig. Bascom würde ich eher mit einer ganzen Reihe von Fertig_Bauteilen wie sie im Plattenbau üblich sind, vergleichen. Die kann man benutzen -muß man aber nicht. Es ist natürlich auch möglich, sich "Großbauteile" aus einzelnen Steinen und Mörtel selbst zu bauen, wenn es das "Ferigbauteil" nicht gibt oder nicht so gibt, wie man es sich vorstellt.
Axel Schwenke schrieb: > Bascom ist vergleichbar mit Fertigteilhäusern. C ist ein Haufen Steine, > Mörtel und eine Auswahl an Maurerkellen. Assembler ist eine Lehmgrube. > > Und so wie es auf dieser Stufenleiter immer mehr einzelne Schritte zum > fertigen Haus werden, je (scheinbar) einfacher das gewählte Werkzeug > ist, so steigen andererseits auch die kreativen Möglichkeiten. Aus > Steinen kann man ein Haus bauen, daß es als Fertighaus nicht gibt. Aus > Lehm kann man sich sogar Ziegel in einer Form machen, die man sonst > nicht fertig bekommt. Ach deshalb gibts mittlerweile so viele Fertighäuser :-P Ich programmiere Mittlerweile auch in Bascom. Weils schneller geht! Und Zeit ist Geld!
:
Bearbeitet durch User
kamillentee schrieb: > Warum heißt es hier also immer C ist besser, bzw. wird gegen Bascom > geflamt (ehrliche Frage)? Ich sehe hier eigentlich viel öfter das Bascom 'Anhänger' gegen alles was nicht Bascom ist 'flamen' Warum eigentlich?
Bascom kann doch noch nichteinmal ordentliche mathematische Ausdrücke verarbeiten, geschweige denn iterative Programmierung, da stürzen die Programme gerne aus unersichtlichen Gründen ab. Unser Fazit war: je anspruchsvoller das Projekt um so schlimmer werden Fehlersuche, Übersichtlichkeit und Stabilität. Von der jahrzentealten, völlig überholten IDE fangen wir erst gar nicht an. Wer sich das heutzutage in anebetracht der zahlreichen, auch kostenlosen Alternativen antut, bitte. Nicht mehr als ein Spielzeug für Hobbyisten.
@ Alex W. (a20q90)
>Ich programmiere Mittlerweile auch in Bascom. Weils schneller geht!
Weil du nie eine ordentliche Hochsprache gelernt hast?
Auch wenn C nicht der Weisheit letzter Schluß ist, es ist ein sehr weit
verbreiteter Industriestandard. Auf den unterschiedlichsten Plattformen,
vom winzigen uC bis zur fetten Workstation (auch wenn es diesen begriff
heute so kaum noch gibt). Wenn man die Finger von den linken Tricks in C
lässt und alles etwas konservativer angeht, kommt man mit C sehr gut und
schnell zu soliden Ergebnissen.
BASCOM hat schon seine Berechtigung für Anfänger und
Gegenheitsprogrammierer. Es soll auch Leute geben, die BASCOM in
größerem Umfang im proifessionelem Umfeld einsetzen. Wenn sie damit gute
Ergebnisse erreichen, OK. Das Gleiche gilt für Arduino & Co. Mir wären
aber diverse Einschränkungen zu nervig, allen voran die verkrüppelten
Formeln mit nur EINER Operation pro Zeile! Wenn es etwas flotter sein
soll (Interrupts), ist der BASCOM-Compiler nicht so toll, der sicher mal
pro forma ALLE Register.
:
Bearbeitet durch Moderator
@Udo Schmitt (urschmitt) >Ich sehe hier eigentlich viel öfter das Bascom 'Anhänger' gegen alles >was nicht Bascom ist 'flamen' >Warum eigentlich? Viele Menschen haben einen geistigen Horizont mit dem Radius Null. Das nennen sie dann ihren Standpunkt.
Ich kann ja die C-Jünger verstehen, wenn sie ihre Programmiersprache verteidigen. Ist aber hier doch gar nicht gefragt.
In BASCOM habe ich vor einiger Zeit ein Projekt unter der Adresse www.ups.bplaced.de gefunden. Das Projekt ist so umfangreich, dass ich glaube, dass damit auch alles zu machen ist.
Falk Brunner schrieb: > Weil du nie eine ordentliche Hochsprache gelernt hast? Das schließt Du woraus?
@ Alex W. (a20q90) >> Weil du nie eine ordentliche Hochsprache gelernt hast? >Das schließt Du woraus? Schrieb ich das nicht? Beitrag "Re: Ernstzunehmende Programme in BASCOM"
Alex W. schrieb: > Falk Brunner schrieb: >> Weil du nie eine ordentliche Hochsprache gelernt hast? > > Das schließt Du woraus? Fragen mit Gegenfragen zu 'beantworten' bringt einen nicht wirklich weiter. Wenn du sie einfach beantwortest hättest wäre uns das herumraten und Schlussfolgerungen ziehen erspart geblieben.
Wie wäre es wenn die BasCom 'Profis' statt sich hier zu zoffen sich mal um die Anfragen kümmern, die für bascom hier im Forum reinkommen. z.B: Beitrag "Benötige Unterstüzung bei Variablen"
:
Bearbeitet durch User
Wenn sich die C-'Profis' um alle C-Probleme kümmern würden, würden sie in diesem thread wenigstens nicht stören.
@ Franz (Gast) >Fragen mit Gegenfragen zu 'beantworten' bringt einen nicht wirklich >weiter. Wenn du sie einfach beantwortest hättest wäre uns das herumraten >und Schlussfolgerungen ziehen erspart geblieben. Nun, für die nicht ganz so auffassungsschnellen. >> Weil du nie eine ordentliche Hochsprache gelernt hast? >Das schließt Du woraus? Das schließe ich aus der Aussage von ihm, die da lautete. "Ich programmiere Mittlerweile auch in Bascom. Weils schneller geht!" C ist nicht wirklich langsamer in der Entwicklung, WENN man ein paar sinnvolle Codeschnipsel für LCD-Ansteuerung, UART, SD-Karte etc. hat. Das ist der kleine Vorteil von BASCOM/Arduino etc., dass dort all diese Codeschnipsel drinstecken.
> Wie wäre es wenn die BasCom 'Profis' statt sich hier zu zoffen sich mal
um die Anfragen kümmern, die für bascom hier im Forum reinkommen.
z.B:
Beitrag "Benötige Unterstüzung bei Variablen"
Weshalb sollte man jeden Artikel lesen ? Wenn's um Bascom geht koennte
das auch schon im Titel drin stecken. Das waer effizienter.
Falk Brunner schrieb: > Wenn es etwas flotter sein soll (Interrupts), ist der BASCOM-Compiler >nicht so toll, der sichert mal pro forma ALLE Register. Das ist die Default-Einstellung. Es geht auch individuell. Optionen: ...ON interrupt label [NOSAVE|SAVE|SAVEALL]... Gut, dass hier nur Leute schreiben, die mit der Materie vertraut sind... :-)
Simpel schrieb: > Es geht auch individuell. Neugierig: Warum eigentlich nicht automatisch? Er sollte doch wissen, welche Register er zerstört und daher sicher muss.
@ Simpel (Gast) >Das ist die Default-Einstellung. Es geht auch individuell. >Optionen: ...ON interrupt label [NOSAVE|SAVE|SAVEALL]... Wozu soll ein SAVEALL gut sein? NOSAVE ist bestenfalls für reine ASM-Funktionen/Interrupts gut. Was macht SAVE? Intelligent sichern? Warum ist DAS nicht der Standardwert?
Jetzt Nicht schrieb: > Weshalb sollte man jeden Artikel lesen ? Wenn's um Bascom geht koennte > das auch schon im Titel drin stecken. Das waer effizienter. Dumme Ausrede, jetzt kennst du den Thread ja, aber du solltest auch richtig zitieren lernen. Ist einfacher als Bascom, einfach Markierenund den richtigen Butten im Beitrag unten rechts drücken.
Als typischer Gelegenheitsprogrammierer habe ich meine ein, zwei Projekte pro Jahr früher in BASCOM Basic gemacht. Die haben (meistens) auch funktioniert und tun das heute noch. Das auch in diesem Thread angesprochene Ärgernis, dass pro mathematischem Ausdruck eine eigene Zeile fällig ist und die vorsintflutliche IDE haben mich inzwischen zu LunaAVR geführt. Das ist doch schon wesentlich angenehmer! Ach, hätte es das doch schon vor 10 Jahren gegeben. Etwas ärgerlich bei Luna sind die Bugs der jeweils aktuellen Betas, da suche ich immer wieder Fehler in meinem Code, die in Wirklichkeit im Compiler stecken. Es ist eben noch eine recht junge Sprache. Ich muss aber auch sagen, dass die gemeldeten Bugs innerhalb kürzester Zeit abgestellt werden. Ein Plus bei Luna ist für mich die Nähe zu C (im Vergleich mit Bascom), so dass bewährter Code, z.B. die 'Standardlösungen' von Peter Dannegger für Tasterentprellung und Drehgeber oder Display Treiber recht einfach in Luna übertragen werden kann, wenn man Grundkenntnisse in C hat. Beim Bascom Basic fiel mir das noch viel schwerer. Zusammenfassend kann ich aus meiner Sicht sagen, dass in jeder Sprache 'ernstzunehmende' Programme geschrieben werden können. Nur muss man sich bei manchen Sprachen mehr plagen oder ärgern als bei anderen. Soll also jeder das Werkzeug benutzen, das für ihn persönlich das geeignetste ist. Allerdings sollte man die verschiedenen Sprachen zumindest oberflächlich kennen, wenn man urteilen will.
Erwin Endres schrieb: > in Plus bei Luna ist für mich die Nähe zu C (im Vergleich mit Bascom), > so dass bewährter Code, z.B. die 'Standardlösungen' von Peter Dannegger > für Tasterentprellung und Drehgeber oder Display Treiber recht einfach > in Luna übertragen werden kann, wenn man Grundkenntnisse in C hat. Wenn du Peters Tastenentprellung fehlerfrei portierst, dann könntest du doch auch in C programmieren. Warum hast du dann eine ich sag mal so viel exotischere Programmiersprache wie Luna gelernt, zumal du selbst schreibst das du dann oft Fehler suchst, die nicht in deinem Code sondern an Luna liegen. In C ist es ziemlich schwer auf einen Bug zu stossen. Erwin Endres schrieb: > Soll also jeder das Werkzeug benutzen, das für ihn persönlich das > geeignetste ist. Seh ich genauso, allerdings muss eine sachliche Diskussion um Vor und Nachteile möglich sein, ohne dass glaich wieder der Kindergarten losgeht. Aber das funktioniert leider selten.
Vor einer Stunde habe ich hier auf den Thread verwiesen, in dem ein Bascom Anfänger Hilfe benötigt. Resonanz bis jetzt: NULL! Versucht zu helfen haben die, die eher wenig mit BasCom zu tun haben. Traurig Ihr Nurmis und JetztNichts und bascomnutzer, ... könnt ihr nur in diesen Diskussionthreads diskutieren oder auch mal einem Gleichgesinnten helfen?
Udo Schmitt schrieb: > Wenn du Peters Tastenentprellung fehlerfrei portierst, dann könntest du > doch auch in C programmieren. Nach einem halben Jahr oder längerer Programmierpause fällt es mir jedesmal wieder von neuem schwer, mich an die C Syntax zu erinnern/gewöhnen. Da ist Luna oder auch Bascom für mich deutlich intuitiver. Außerdem ist es schon zweierlei, ob man einen Algorithmus in eine andere Sprache überträgt oder ein komplettes Programm schreibt. Btw: Die bewährten Peda Routinen sind inzwischen auch in Luna als Bibliotheken enthalten. > Traurig > Ihr Nurmis und JetztNichts und bascomnutzer, ... Wie war das mit dem Kindergarten? Und was sind Nurmis? Finnische Leichtathleten?
Hallo Udo, Udo Schmitt schrieb: > Wenn du Peters Tastenentprellung fehlerfrei portierst, dann könntest du > doch auch in C programmieren. Die hat er nicht portiert, das war ein anderes Team, die jetzige Lib (Interface genannt) ist in Assembler codiert und entsprechend schnell. PeDa's Drehimpulsgeber Algorithmus zur Auswertung eines Drehencoders habe ich gerade für 4 Drehimpulsgeber als Lib (interface) implementiert und Mehrfach Drehimpulsgeber (MultiRotaryEncoder) genannt. > Warum hast du dann eine ich sag mal so viel exotischere > Programmiersprache wie Luna gelernt, zumal du selbst schreibst das du > dann oft Fehler suchst, die nicht in deinem Code sondern an Luna liegen. > In C ist es ziemlich schwer auf einen Bug zu stossen. Da hast Du bestimmt etwas falsch verstanden, die LunaAVR V2015 R1 Beta sind ja genau deshalb veröffentlicht um, Fehler die durch Codeoptimierungen entstanden sind, zu finden. Sie dienen nicht der Programmgenerierung für produktive Projekte. Die Stabel heißt *LunaAVR V2014 R2.4* # http://avr.myluna.de/doku.php?id=de:lunaavr_2014.r2
:
Bearbeitet durch User
Uwe S. schrieb: > Die hat er nicht portiert, das war ein anderes Team, die jetzige Lib > (Interface genannt) ist in Assembler codiert und entsprechend schnell. Doch, hat er schon! ;) Das war bevor die Routinen als Interface zur Verfügung standen...
Mir fällt gerade der Name nicht mehr ein, aber der Typ, der den Tricopter gebaut hat, hat auch alles in Basecom geschrieben. Ist alles Open Source. Einen Kopter finde ich jetzt schon etwas anspruchsvoller, das macht kein Anfänger. Und zu langsam darf die Sprache dann auch nicht sein. Achso, der Typ hat auch was mit Biologie studiert und das hinbekommen, man muss also nicht immer Informatiker oder E-Techniker sein, um etwas "ernsthaftes" auf die Beine zu stellen :-) Dennis
Erwin Endres schrieb: > Und was sind Nurmis? Finnische Leichtathleten? Das waren die Nutzernamen der Nutzer die hier sehr 'aktiv' 'pro BasCom' diskutiert haben. Beispiel: nurmi schrieb: > Wenn sich die C-'Profis' um alle C-Probleme kümmern würden, würden sie > in diesem thread wenigstens nicht stören. Es fällt mir hier schon länger auf das vor allem bei Themen um BasCom schnell sehr hitzig diskutiert wird, wenn aber ein Anfänger mal eine Frage stellt, dann findet man praktisch nie diejenigen, die den "Flame" Threads den Mund am weitesten aufmachen. Jetzt habe ich sie praktisch auf den BasCom Thread gestossen, aber keiner hat geholfen. Ich selbst kenne etwas Basic von ganz früher auf dem PC aber lein BasCom, deshalb kann ich dem genannten Thread nicht helfen.
:
Bearbeitet durch User
Udo Schmitt schrieb: > Jetzt habe ich sie praktisch auf den BasCom Thread gestossen, aber > keiner hat geholfen. ??? Oliver
Udo Schmitt schrieb: > Es fällt mir hier schon länger auf das vor allem bei Themen um BasCom > schnell sehr hitzig diskutiert wird, Ach, das siehst du falsch. Hitziges Herumflamen gibt es hier zu eigentlich allen Themen. Aber, wenn wir mal ein paar Jahre zurückdenken, dann war Visual Basic der damalige Renner, eben weil man damit recht schnell Programme mit einer ganz ordentlichen Windows-Oberfläche hingekriegt hat und weil man sich eben nicht durch kryptische Sprachsyntax durchbeißen mußte. So ähnlich läuft's eben auch mit Bascom. Da kriegt man relativ hardwarefern seine eigentliche Anwendung eben hin - sofern selbige eher geradlinig ist. Das sit durchaus gut für Leute, die ihren Daseinssinn nicht im Programmieren sehen, sondern anderweitige Ingenieur-Ziele verfolgen. Ein bissel ähnlich sieht das mit den Pascal-Implementierungen von mikroe aus. Die sind durchaus in ihrem Ansatz für ähnliche Leute gedacht wie das Klientel von Bascom - allerdings auf anderer Hardware. Das Ganze hat natürlich auch seine Kehrseite: Bascom auf einer anderen Platform als AVR geht sicherlich, Mikropascal auf anderen ARM's als denen, die vom Hersteller bereits berücksichtigt wurden geht vielleicht auch, aber WER sollte das machen bzw. einpflegen? W.S.
W.S. schrieb: > Bascom auf einer anderen > Platform als AVR geht sicherlich Ja, geht sicherlich auch 8051 -d.h. nicht nur sicherlich, sondern sicher
Udo Schmitt schrieb: > Traurig > Ihr Nurmis und JetztNichts und bascomnutzer, ... > könnt ihr nur in diesen Diskussionthreads diskutieren oder auch mal > einem Gleichgesinnten helfen? Dieser thread war überhaupt nicht als Diskussionsthread angelegt. Bis auf die Unklarheit, was mit "ernstzunehmend" genau gemeint sei, war die Frage des TO selten klar und er hatte auch noch vorbeugend geschrieben, das er eben nicht eine Diskussion "BASCOM vs. Irgendeine andere Programmiersprache" wünscht. Wer das nicht mehr weiß, kann das ja ganz oben nochmal nachlesen. Wenn das Wort Bascom auftaucht, fühlen sich aber immer wieder irgendwelche User berufen den thread abseits des Themas zu zerreden. Obwohl nicht mein thread aber Danke dafür :( Um da mitzuhalten werde ich wohl, anstatt den Gleichgesinnten zu helfen, den erkennbaren "C-Spezialisten" empfehlen müssen auf Bascom umzusteigen.
>Ihr Nurmis und JetztNichts und bascomnutzer, ... könnt ihr nur in diesen
Diskussionthreads diskutieren oder auch mal einem Gleichgesinnten helfen?
Sorry, ich verwend kein Bascom, dafuer Pascal.
Einen Tiny2313 wuerd ich sein lassen. Hat zu wenig von allem. Allenfalls
in ASM. Die Kostenersparnis gegen einen vernuenftigen Mega ist marginal.
Jetzt Nicht schrieb: > Einen Tiny2313 wuerd ich sein lassen. Hat zu wenig von allem. Allenfalls > in ASM. Die Kostenersparnis gegen einen vernuenftigen Mega ist marginal. Wenn dann tauscht man ihn gegen einen Tiny84 oder gleich 841. Der Vorteil der Tinys im Vergleich zu megas ist die Größe vs. Handlebarkeit. SOIC ist für viele (auch für mich) ein optimales Gehäuse. Weil es relativ klein ist, sich aber sehr prozessicher löten lässt. Sowohl von Hand als auch per Hobby-Reflow. Megas bieten sowas nicht. Die sind entweder groß, oder haben gleich richtig winzige Gehäuse, welche dann oft Probleme beim löten machen.
Ich als Bascomfan siehe ich die Sache so... Wenn einer ein Quereinsteiger ist wie ich, habe Elektronik nicht gelernt, kam ich mit Bascom sehr schnell zum Erfolg. Sowas wie RGB Steuerung, Uhr, Thermometer usw..was man halt am Anfang baut wenn man sich mit uC anfängt. Wenn ich aber sehe, wieviel Threads existieren "LCD Anzeige nur schwarze Balken", oder ADC Werte..dann sehe es ist meistens C. Habe zwar auch mal versucht mit C was zu machen, aber mir persönlich ist ein C Code schlechter "lesbar"( haufen klammern ) usw aber ist meine persönliche Meinung. Also für Hobby sehe Bascom wirklich super ausreichend. Die andere Seite wie Industrie ( unsere Zulieferer schreiben ausschliesslich in C..) also scheint mir als Industriestandard zu sein. Ist schon fast wie Microsoft und Linux. ich komme sehr viel bei Großkunden herum..also keine 100 Man Buden..habe NIRGENDS..Linux bisher gesehen , (Windowsserver, Axapta..Office) oder sind diese "Free Programme" bisher nicht über den Weg gelaufen, trotz daß ich relativ viel in EDV Bereich bzw. Produktion unterwegs bin. Dann ist die Frage wieder warum : Industrie - C und Windows Privat - Linux..naja wer was mag..und wöfür er Geld hat...Lol
Udo Schmitt schrieb: > Jetzt habe ich sie praktisch auf den BasCom Thread gestossen, aber > keiner hat geholfen. Auch die hier Beteiligten vermögen im von Dir verlinkten Thread im Moment nichts auszurichten, weil wesentliche Informationen seitens des TE fehlen. Das hättest Du aber durchaus erkennen können. Udo Schmitt schrieb: > Vor einer Stunde habe ich hier auf den Thread verwiesen, in dem ein > Bascom Anfänger Hilfe benötigt. Der TE ist im Moment abgetaucht, wofür es mehrere Gründe gibt: a) er muss arbeiten b) er hat wild geändert und jetzt geht's, er weiß aber nicht mehr warum c) der Fehler war so simpel, dass er sich geniert, sich wieder zu melden d) es war was ganz was Anderes
Jetzt Nicht schrieb: > Einen Tiny2313 wuerd ich sein lassen. Hat zu wenig von allem. Allenfalls > in ASM. Hm, also ich hatte da ganz nette Sachen untergebracht: USB-HID-Geräte mit V-USB, Software-PWM mit so vielen Kanälen wie Pins plus Animationen damit usw. Allerdings mit C und nicht BASCOM. :o Das Problem an BASCOM ist ja nicht, dass es ein BASIC-Dialekt ist, sondern der dilletantisch schlecht implementierte Compiler. Genug Alternativen gibt es ja, wenn es BASIC sein muss.
drama schrieb: > Allerdings mit C und nicht BASCOM. :o Dann ist das für diesen Thread ja völlig unwichtig.
Cyblord ---- schrieb: > Wenn dann tauscht man ihn gegen einen Tiny84 oder gleich 841. Die haben allerdings beide nicht so viele Pins wie der 2313 und die Zahl der Pins ist ja auch oft wichtig, nicht nur die Menge des Speichers. Was übrigens diesen betrifft, steht ja auch für den 2313 bei gleichbleibender Pinzahl der Upgrade-Pfad auf 2313A (neue Hardwarefunktionen) oder 4313 offen (gleiche neue Hardware und zusätzlich auch noch mehr Speicher). > Der > Vorteil der Tinys im Vergleich zu megas ist die Größe vs. Handlebarkeit. > SOIC ist für viele (auch für mich) ein optimales Gehäuse. Weil es > relativ klein ist, sich aber sehr prozessicher löten lässt. Nunja, 2313A und 4313 gibt's nach wie vor in DIP und SOIC. Also genau so, wie es sein sollte.
Thomas der Bastler schrieb: > aber mir persönlich ist ein C Code > schlechter "lesbar"( haufen klammern ) usw aber ist meine persönliche > Meinung. Alle Bascom-Beispiele, die ich bislang gesehen habe, sind grauenvoll formatiert und minimalst kommentiert. Das erinnert mich an Zeiten, als jedes Leerzeichen noch Platz im Programmspeicher belegte. Das schreckt zunächst jeden Interessierten ab, der gerne strukturiert programmieren möchte. Aus Jux habe ich mir die Demo-Version geladen, um ein wenig zu spielen und zu sehen, wieweit man mit 4K Code-Limit kommt. Aber offensichtlich schaffe ich es nicht einen AVR ISP MKII Prommer anzusprechen. Die Treiber von AVR Studio reichen wohl nicht und die Nachinstallation von USBLIB-Treibern (oder so ähnlich) schaffen auch keine Verbindung. Ich weiß nicht wie andere Anfänger damit klarkommen. Simpel schrieb: > Das Einzige was mich wirklich nervt, ist die Tatsache, dass im Code als > Operanden keine arithmetische Mehrfachoperationen oder Klammerausdrücke > verwendet werden können, so dass man alles in Einzelschritten erledigen > muss. Das würde ich nicht sonderlich schlimm finden, weil man dann sehen kann, wie die Reihenfolge der Auswertung ist. Bei Assembler muß ich das ja auch machen ;-)
c-hater schrieb: > Nunja, 2313A und 4313 gibt's nach wie vor in DIP und SOIC. Also genau > so, wie es sein sollte. Sagmal hab ich die null gewählt oder warum meldet du dich dauernd von den billigen Plätzen? Langeweile? Dein DIP Gesülze nervt langsam aber sicher. Wenn dir die Features der DIP Varianten reichen dann nimm sie. Niemand zwingt dich den 841 zu verwenden. Und den 84 gibts auch in DIP. Dafür hat er 8kb Flash und auch nen HW-UART.
:
Bearbeitet durch User
m.n. schrieb: > Aber offensichtlich > schaffe ich es nicht einen AVR ISP MKII Prommer anzusprechen. Die > Treiber von AVR Studio reichen wohl nicht und die Nachinstallation von > USBLIB-Treibern (oder so ähnlich) schaffen auch keine Verbindung. Ich > weiß nicht wie andere Anfänger damit klarkommen. Die verwenden einfach die Hilfe, die MCS dafür bereitstellt: http://avrhelp.mcselec.com/index.html?libusb.htm Ich sage Dir: Das funktioniert tatsächlich...
m.n. schrieb: > Aber offensichtlich > schaffe ich es nicht einen AVR ISP MKII Prommer anzusprechen. In der Tat..5 Min Google..dann weißt Du ja wie es geht, aber wenn man an die Sache eh so rangeht.."ist sowieso nichts"..dann wirds an nicht gehen. Ich habe Bascom und den besagten USB Programmer..null Problem.Win7 64Bit Ultimate.
Thomas der Bastler schrieb: > In der Tat..5 Min Google..dann weißt Du ja wie es geht, aber wenn man an > die Sache eh so rangeht.."ist sowieso nichts"..dann wirds an nicht > gehen. Du meckerst ja so rum, als ob die Überschrift wäre: "Darf man Bascom-Nutzer ernst nehmen?" Soll ich darauf antworten? Daß man bei einem AVR ISP MKII ein STK500 wählen muß, erschließt sich mir allerdings nicht :-(
Thomas der Bastler schrieb: > aber mir persönlich ist ein C Code > schlechter "lesbar"( haufen klammern ) usw aber ist meine persönliche > Meinung. Wenn man den C-Code vernünftig formatiert und einrückt, ist es IMHO kein Problem, wenn man hingen keine Wert auf Formatierung legt kann man in den meisten Programmiersprachen 'kryptische' Konstrukte erzeugen.
m.n. schrieb: > Daß man bei einem AVR ISP MKII ein STK500 wählen muß, erschließt sich > mir allerdings nicht :-( Nur mal aus Interesse: Was glaubst Du, warum ich den Link zu der Hilfedatei angegeben habe? Damit Du (immer noch falsch) behauptest, daß der MK2 als STK500 angesprochen werden soll? LIES die Anleitung oder schau Dir die Bilder an, falls Du mit dem Text nicht klarkommst! m.n. schrieb: > "Darf man Bascom-Nutzer ernst nehmen?" > Soll ich darauf antworten? Darf man Leute ernst nehmen, die nicht mal einen Programmer in Betrieb nehmen können? Soll ich darauf antworten?
:
Bearbeitet durch User
Kai Mauer schrieb: > Darf man Leute ernst nehmen, die nicht mal einen Programmer in Betrieb > nehmen können? Nana.. nicht gleich weißglühen. Also: Im Grunde habe auch ich etwas gegen alle µC, zu deren Programmierung man zwangsweise einen speziellen Programmer braucht. Egal ob es nun einer ist, der sich JTAG oder SWD oder was proprietäres nennt. Natürlich geht so ein Equipment, und für jemanden, der das Geld für einen JLINK oder ULINK2 oder was Vergleichbares hat, ist das auch gar kein Thema. Ebenso nicht für diejenigen, die irgend ein Eval-Board mit darauf enthaltenem JTAG/SWD-Adapter haben. Aber: Es gibt trotzdem Leute, bei denen die Situation anders aussieht - und genau deshalb sind mir µC sympathischer, die einen eingebauten Bootlader haben, so daß man auch mit sehr simplem Equipment (COM-Port+MAX232 oder USB-Serial Adapter vom Chinesen oder gar USB direkt) zu Potte kommt. Ja, früher gab's auch mal nen Atmel-Programmer für den PP, aber das ist lang her. Heutzutage sind mir aus o.g. Gründen die ARM's und Cortexe von NXP und ST mit ihren fest eingebauten Bootladern lieber als all die bisherigen kleineren µC, wozu ich eben auch all die AVR's zähle. So ein Cortex, der sich dank eingebautem USB-Lader schlichtweg ganz ohne irgendwelches Geschirre programmieren läßt, wenn man mal von einem Jumper und einem Taster absieht, erscheint mir derzeit als das ideale Einsteiger-Equipment. Eigentlich wäre aus Sicht der Bascom-Leute durchaus zu wünschen, für selbigen eben auch so eine Cortex-Plattform zu haben. W.S.
Erwin Endres schrieb: > Das auch in diesem Thread angesprochene Ärgernis, dass pro > mathematischem Ausdruck eine eigene Zeile fällig ist und die > vorsintflutliche IDE haben mich inzwischen zu LunaAVR geführt. Das ist > doch schon wesentlich angenehmer! Jetzt nicht mehr! Ein Forum das nicht mal mehr für Gäste öffentlich lesbar ist taugt nicht. Mein Interesse an LunaAVR ist damit auf null erloschen. Schade drum!
W.S. schrieb: > So ein Cortex, der sich dank eingebautem USB-Lader schlichtweg ganz ohne > irgendwelches Geschirre programmieren läßt, wenn man mal von einem > Jumper und einem Taster absieht, erscheint mir derzeit als das ideale > Einsteiger-Equipment. Je komplexer der Controller, desto schwieriger wird's für den Benutzer, vor allem wenn er das Gros der Funktionalität nicht benötigt. Andererseits gibt's das ja schon, es lässt sich als Programmer "Arduino" unter Bascom einstellen (57600 Baud). Damit wird der Bootloader der Arduinos verwendet und die Arduino AVR-Plattform ist so direkt einsetzbar. Kaputt-fusen per Bootloader ist ausgeschlossen, Lock-Fuses können natürlich nur über ISP gesetzt werden, der Clock-Prescaler hingegen kann über den Code eingestellt werden. Voila, eine überschaubare Plattform mit z.B. ATM328P mit genau den gewünschten Vorzügen und nicht ein aufgeblasener Cortex.
W.S. schrieb: > Aber: Es gibt trotzdem Leute, bei denen die Situation anders aussieht - > und genau deshalb sind mir µC sympathischer, die einen eingebauten > Bootlader haben, so daß man auch mit sehr simplem Equipment > (COM-Port+MAX232 oder USB-Serial Adapter vom Chinesen oder gar USB > direkt) zu Potte kommt. Blöde Frage, aber bei welchen (Mainstream)-MCUs ist das nicht der Fall? MSP430, TI Stellaris, NXP LPC, STM32, Gecko. etc. haben allesamt mindestens einen Bootloader über UART.
alt geworden schrieb: > Jetzt nicht mehr! Ein Forum das nicht mal mehr für Gäste öffentlich > lesbar ist taugt nicht. Mein Interesse an LunaAVR ist damit auf null > erloschen. Schade drum! Eigentlich ist das eher schade für dich. Aber so ist das, der eine verliert das Interesse an einer Sprache, weil er den Programmer nicht zum Laufen bekommt, der andere weil er sich erst bei einem Forum anmelden müsste, bevor er dort Rat und Hilfe bekommt. Häkeln soll ja auch ein schönes Hobby sein... Obwohl, da muss man Maschen zählen und links und rechts unterscheiden können. Oder war das beim Stricken?
Kai Mauer schrieb: > Nur mal aus Interesse: Was glaubst Du, warum ich den Link zu der > Hilfedatei angegeben habe? Das weiß ich doch nicht. Ich merke nur, daß Bascom-Fans wohl recht empfindliche Gemüter haben. Vielleicht ist das auch eine Vorbedingung. Kai Mauer schrieb: > Damit Du (immer noch falsch) behauptest, > daß der MK2 als STK500 angesprochen werden soll? Wenn ich STK500 wähle, funktioniert die Programmierung. Warum, das ist mir mittlerweile egal ;-)
drama schrieb: > Blöde Frage, aber bei welchen (Mainstream)-MCUs ist das nicht der Fall? Bei so gut wie allen Automotive z.B. Flug- und Medizintechnik wirds ähnlich sein.
m.n. schrieb: > Daß man bei einem AVR ISP MKII ein STK500 wählen muß, erschließt sich > mir allerdings nicht :-( Du kannst mit STK500.EXE prima einen AVRISP MkII ansprechen, unabhängig von der benutzten Programmierumgebung (allerdings braucht man MS Windows). Hier mal ein Drag&Drop Batchfile, welches einen AT89S52 programmiert:
1 | set prog="C:\xasm\AVR\STK500\Stk500.exe" |
2 | %prog% -cUSB -dAT89S52 -e -if%1 -pf -vf |
3 | pause |
Da lässt du das Hexfile rauffallen, und der MC wird programmiert.
:
Bearbeitet durch User
Ich finde es gut, das Bascom inkl. Compiler und Simulator auch unter Linux (mit Wine) funktioniert. Zum Brennen muss man halt avrdude verwenden. Geht das mit AVR Studio auch, oder ist man da imer noch an MS gebunden? Inline Assembler nutze ich auch, wenn's sehr schnell gehen muss. UNd dank Simulator sieht man auf den Takt genau und für jede Programmzeile, wie das Programm nachher läuft, wo er die Variable im Ram hinschreibt, wie die Register belegt sind etc. Ist mir "ernsthaft" genug. ;-)
:
Bearbeitet durch User
Rainer, lern erstmal den Unterschied zwischen IDE und Toolchain bevor du dich in Diskussionen um Bascom, C und Assembler stürzt. Die avr-gcc Toolchain um AVRs in C zu programmieren gibts natürlich auch für Linux. Das brauchts kein Wine. Und Eclipse läuft da auch nativ. Das Atmel Studio hat damit wenig zu tun. Aber die Tatsache dass Bascom nur auf Windows oder eben in Wine läuft, als pro-Argument für Bascom herzunehmen, weil es so toll unter Linux läuft, dazu gehört schon Chuzpe.
:
Bearbeitet durch User
Falk Brunner schrieb: > @ Simpel (Gast) > >>Das ist die Default-Einstellung. Es geht auch individuell. >>Optionen: ...ON interrupt label [NOSAVE|SAVE|SAVEALL]... > > Wozu soll ein SAVEALL gut sein? > NOSAVE ist bestenfalls für reine ASM-Funktionen/Interrupts gut. > Was macht SAVE? Intelligent sichern? Warum ist DAS nicht der > Standardwert? SAVE ist der Standardwert, das hatte Simpel flasch aufgeschrieben. . Quelle, Bascom hilfe: Store: This is the default and is the same as when no parameter is provided. The most common used registers, SREG, and RAMPZ are saved and restored. Saved : SREG , R31 to R16 and R11 to R0 with exception of R6,R8 and R9. If RAMPZ exists, it will be saved as well. Saveall: This will save all registers that SAVE will save, but it will also save R12-R15. You should use this option when using floating point math in the ISR. Sogesehen wird fast alles gesichert, aber man kann das eben beeinflussen. bye uwe
Uwe R. schrieb: > Sogesehen wird fast alles gesichert, aber man kann das eben > beeinflussen. Beantwortet aber noch nicht die Frage, warum nicht genau das gesichert wird, was auch in der Funktion benutzt wird. Ich mein', so macht das jeder andere Compiler auch …
Jörg Wunsch schrieb: > Beantwortet aber noch nicht die Frage, warum nicht genau das > gesichert wird, was auch in der Funktion benutzt wird. Weil Bascom blöd ist? Ich hab mir mal mit der Testversion die Umsetzung einiger Berechnungen angeschaut. Danach war die Option Bascom für mich gestorben.
Jörg Wunsch schrieb: > Uwe R. schrieb: >> Sogesehen wird fast alles gesichert, aber man kann das eben >> beeinflussen. > > Beantwortet aber noch nicht die Frage, warum nicht genau das > gesichert wird, was auch in der Funktion benutzt wird. > > Ich mein', so macht das jeder andere Compiler auch … Hmm, wäre keine schlechte sache, stimmt. Halten wir erstmal fest: die Aussage das immer alle Register gesichert werden ist falsch. Stattdessen werden viele gesichert, man kann es aber auch ganz abschalten und nur die benötigten sichern. Die muss man dann aber genau kennen (sollte in kritischen Assemblerfunktionen gegeben sein). Ein Automatismus wäre wünschenswert und würde Zeit/Fehlerquellen sparen. Es geht aber ganz manuell (mit Lehmgrube sozusagen ;o)). bye uwe
Nu ich oooch noch... Wer mich kennt, der weiß, programmieren ist meine Sache nicht. Andererseits kommt man manchmal nicht ohne aus, also habe ich mich manchmal doch hingehockt und was zusammengestoppelt. Zu Z80-Zeiten war das noch reiner Assembler, heute erfolgreich vergessen. Als es AVRs sein mussten, lief mir zunächst irgendein C über den Zeh. Grottig! Lauter Klammern und Gedöhns, zumindest für mich zunächst unverdaulich. In einer Zeitschrift gab es in älteren Ausgaben einen Kurs in Bascom, der war didaktisch gut gemacht, also das Steckbrett vorgekramt und los. Nach ein paar Minuten schon die ersten Erfolge, die Befehle und die IDE leuchteten auf Anhieb ein.... Fazit: Die wenigen Anwendungsfälle in denen ich was programmieren musste, habe ich erfolgreich mit Bascom erschlagen! Was will ich als Amateur also mehr? Ob nun Assembler oder C oder weis der Geier, das wird alles seine Berechtigung haben. Wichtig für mich ist: Als Gelegenheitsprogrammierer versteh ich was da abläuft und die IDE erschließt sich mir. Es wird ja keiner mit vorgehaltener Tastatur gezwungen damit zu arbeiten. Warum aber wollen mich die C-Jünger immer zu ihrem Glück zwingen? Argumente wie "sauberere Code" oder bessere IDE sind doch eh nur vorgeschoben. Am Ende zählt: Blinkte die Kiste, zählt der Zähler... Nur das ist wichtig! Zur Überschrift: Jedes Programm, für das ich mir "ne Waffel mache" ist für mich ernsthaft! Old-Papa
>Beantwortet aber noch nicht die Frage, warum nicht genau das >gesichert wird, was auch in der Funktion benutzt wird. > >Ich mein', so macht das jeder andere Compiler auch … Nein tut er nicht. Banale Ausrede der Compilerbauer: Es kann nicht vorhergesehen werden was Funktionsaufrufe alles mit sich ziehen. Denn es gibt Leute, die spulen umfangreiche Switch/Case Konstrukte ab. Das muss dann nicht zwingend lange Ausfuehrungszeiten nach sich ziehen, ist aber nicht mehr mit einem Ein- oder Zweipasscompiler machbar. Da waer dann Backtracking angesagt. Ich haett auch erwartet, bei einer kurzen ISR, in der vielleicht ein Zaehler incrementiert, ein Flag gesetzt, ein Register geladen wird, waere es moeglich nach Bedarf zu sichern.
Jetzt Nicht schrieb: > Banale Ausrede der Compilerbauer: Es kann nicht vorhergesehen werden was > Funktionsaufrufe alles mit sich ziehen. Dass man bei Funktionsaufrufen alle Register sichern muss, die per ABI als durch den Aufrufer zu sichernd festgelegt sind, ist logisch. Aber ob es überhaupt einen Funktionsaufruf gibt, kann ein Compiler natürlich schon merken, und wenn es keinen gibt, dann hat er einen guten Überblick, welche Register er selbst tatsächlich zerstört. > Denn es gibt Leute, die spulen umfangreiche Switch/Case Konstrukte ab. > Das muss dann nicht zwingend lange Ausfuehrungszeiten nach sich ziehen, > ist aber nicht mehr mit einem Ein- oder Zweipasscompiler machbar. Das ist 'ne lahme Ausrede. Ein GCC ist auch ein Einpasscompiler. Beweis:
1 | % avr-gcc -Os -x c -mmcu=atmega8 -o - -S - |
2 | #include <avr/io.h> |
3 | #include <avr/interrupt.h> |
4 | uint16_t adcval; |
5 | |
6 | ISR(ADC_vect) |
7 | {
|
8 | adcval = ADC; |
9 | } |
10 | ^D |
11 | .file "" |
12 | __SP_H__ = 0x3e |
13 | __SP_L__ = 0x3d |
14 | __SREG__ = 0x3f |
15 | __tmp_reg__ = 0 |
16 | __zero_reg__ = 1 |
17 | .text |
18 | .global __vector_14 |
19 | .type __vector_14, @function |
20 | __vector_14: |
21 | push r1 |
22 | push r0 |
23 | in r0,__SREG__ |
24 | push r0 |
25 | clr __zero_reg__ |
26 | push r24 |
27 | push r25 |
28 | /* prologue: Signal */ |
29 | /* frame size = 0 */ |
30 | /* stack size = 5 */ |
31 | .L__stack_usage = 5 |
32 | in r24,0x4 |
33 | in r25,0x4+1 |
34 | sts adcval+1,r25 |
35 | sts adcval,r24 |
36 | /* epilogue start */ |
37 | pop r25 |
38 | pop r24 |
39 | pop r0 |
40 | out __SREG__,r0 |
41 | pop r0 |
42 | pop r1 |
43 | reti |
44 | .size __vector_14, .-__vector_14 |
45 | .comm adcval,2,1 |
46 | .ident "GCC: (GNU) 4.7.2" |
47 | .global __do_clear_bss |
(Mir geht es hier ausdrücklich nicht um die Sprache C, sondern um das Verhalten des Compilers. C als Eingabe dient nur als einfach zu handhabendes Beispiel.) Der Compiler liest direkt von der Standardeingabe, da kann er also nicht zweimal darüber iterieren, denn nachdem er ein Zeichen gelesen hat, ist es unwiederbringlich weg aus dem Eingabestrom. Trotzdem kann er die benutzten Register optimieren. (r0/r1 optimiert er nicht, sondern das ist eine Art Standard-Prolog/Epilog, durch die Sonderrolle dieser Register für den AVR-GCC bedingt. Ja, das ist verschenktes Optimierungspotenzial.) Wenn GCC jetzt ein BASIC-Frontend hätte, könnte er auch in dieser Sprache vergleichbares Optimierungspotenzial anbieten, denn die Optimierung läuft ja viel weiter hinten ab. Schicke Gerätebibliotheken kann man auch durchaus unabhängig von der benutzten Programmiersprache anbieten; die Arduino-Umgebung ist der beste Beweis dafür (und sicher auch ein Grund, warum diese Plattform bei vielen beliebt ist).
Nachdem ich ein wenig mit BASCOM gespielt habe, wird schon klar, daß die Möglichkeiten doch recht einschränkend sind. Für den Einstieg ist es in Ordnung, da man schnell kleine Erfolge erzielt. Und wer dabei bleibt, weil er keine besonderen Anforderungen hat, soll es machen. Aber wer einmal auf den C-Zug aufgesprungen ist, holt sich an vielen Stellen blaue Flecke ;-) Mich hatte interessiert, wie es mit der 64-Bit double-Unterstützung aussieht; das wäre für einige Berechnungen ein Vorteil gegenüber AVR-GCC. Soweit ich aber sehe, gibt es dafür kein PRINT und auch kein formatierendes PRINT USING. Die Geschwindigkeit für mein Beispielprogramm ist gut; aber im Vergleich dazu ist das Kompilat vom AVR-GCC etwa Faktor 2,5 schneller. Die BASIC-Interpreter vor 30-40 Jahren hatten den Nachteil, daß Syntaxfehler erst zur Laufzeit erkannt wurden, was sehr ärgerlich sein konnte. BASCOM als Compiler vermeidet dies, was wiederum für einen Anfänger hilfreich ist. Wenn es um die Frage "BASIC oder nicht?" geht, würde mir eher ein Interpreter auf einem größeren µC gefallen, wie es hier diskutiert wird: Beitrag "PIC 32 schneller Basic Interpreter" Dabei geht es dann nicht um schnellste Ausführungszeit, sondern um eine flexible Programmentwicklung im Zielsystem. Dies wird auch dadurch ermöglicht, daß die auszuführenden Programme im RAM liegen. Mein Fazit: wer mit BASCOM spielen will, soll es tun. Und auch, wer größere Programme als 4K benötigt, kann den Entwicklern ruhig ein paar Euro zukommen lassen und ganz wichtig: die Voreinstellungen für die Stacks kräftig erhöhen! Wer aber an die Grenzen stößt, sollte sich nicht damit abplagen, diese zu umschiffen, sondern auf C umsteigen.
> Ernstzunehmende Programme in BASCOM
ich hab nicht mal MINI code-beispiele von irgnedwelchen Programmen
gefunden
(immer nur mini-turtorials die kaum über blink.bas hinausgehen..)
kann mir wer helfen, würde mir bascom gerne anschauen
die kombi, BASCOM und Arduino klingt theoretisch ja recht interessant,
z.b. für Kinder zum Anfangen ?!
(für mich ist BASIC immer wesentlich kompliziert gewesen als alles
andere, z.b. musste ich mal Windows Scripts (WSH oder auch Excel) in
Basic schreiben/erweiter .. z.B. WANN man da genau Klammer setzten
muss,bei funktionsaufrufen, und wann nicht, ist mir bis heute unklar...)
:
Bearbeitet durch User
Robert L. schrieb: > kann mir wer helfen, würde mir bascom gerne anschauen Ja, Du Dir selbst, indem Du dort hingehst: Hier ein Link zur Codesammlung von MCS-Electronic (Hersteller von Bascom). Dort kannst Du auch ziemlich umfangreiche und anspruchsvolle Aufgaben- lösungen finden: http://www.mcselec.com/index.php?option=com_conten... Edith sagt: Die Seite läßt keine tiefen Links zu, Du kannst über Applikation-> Bascom AVR zu der Quelltexctsammlung gelangen.
:
Bearbeitet durch User
Falk Brunner schrieb: > Wenn es etwas flotter sein > soll (Interrupts), ist der BASCOM-Compiler nicht so toll, der sicher mal > pro forma ALLE Register. Was man aber abschalten kann. Ich frage mich wirklich warum dieses Null-Argument immer wieder auftaucht. Aber daran kann man wenigstens leicht erkennen wer sich wirklich damit befasst hat.
Bernd T. schrieb: > Aber daran kann man wenigstens leicht erkennen wer sich wirklich damit > befasst hat. An deinem Kommentar erkennt man dafür, dass du den Rest des Threads nicht gelesen hast … Nein, ein „Null-Argument“ ist das nun nicht gerade.
danke Paul Baumann diese Seite hab ich zwar per google auch ein paar mal entdeckt, aber nicht ernst genommen/ignoriert (aufgrund der Optik) auch mit deiner Anleitung viel es mir schwer dort, Beispiele zu finden (habs dann aber geschafft, auch wenn einige "russich" kommentiert sind, oder zumindest mein Text-Editor kuriose Zeichen anzeigt?!) egal: mir (Programmieren, Pascal, C usw) scheint das ganze extrem "kompliziert" zu sein (in mehrerlei Hinsicht) da Frage ich mich ernsthaft wie ein "Anfänger" da was zustande bringen soll.. die Zielgruppe scheint eher "Lötkolbenspezialisten" zu sein, die (noch) nicht Programmieren können... Seit es Arduinos gibt, kannst das imho getrost vergessen..
Robert L. schrieb: > da Frage ich mich ernsthaft wie ein "Anfänger" da was zustande bringen > soll.. > > die Zielgruppe scheint eher "Lötkolbenspezialisten" zu sein, die (noch) > nicht Programmieren können... Du widersprichst Dir gleich im darauffolgenden Satz, merkst Du das nicht? Robert L. schrieb: > Seit es Arduinos gibt, kannst das imho getrost vergessen.. Das kannst Du vergessen, daß Du das vergessen kannst. ;-) Die "Arduino-Sprache" ist auch ein C-artiges Ding. Wer das nicht will, der benutzt weiter Bascom. Schon alleine die Bedienoberfläche ist viel komfortabler und auch ziemlich umfangreich. Damit kann sich die Arduino- Oberfläche nicht messen. MfG Paul
@ Paul Baumann (paul_baumann)
>Die "Arduino-Sprache" ist auch ein C-artiges Ding.
Es IST einfaches, im Sprachumfang reduziertes C++. Wobei niemand
gehindert wird, mehr zu nutzen, der Compiler dahinter kann es (99,9% der
Anwender allerdings nicht, ich auch nicht).
:
Bearbeitet durch User
> Damit kann sich die Arduino- >Oberfläche nicht messen. findest? http://www.visualmicro.com/page/Arduino-for-Atmel-Studio.aspx ;-) >Du widersprichst Dir gleich im darauffolgenden Satz, merkst Du das >nicht? ja aber auch nein: ich implizierte, dass sich inzwischen auch der "Lötkolbenspezialist"/Programmieranfänger es nicht selber schwer machen wird und einen "großen" µC verwenden und einen Haufen "Krempel" rundherum löten wird wenn er einen auch nicht größeren Arduion Pro/micro/nano/mini nehmen kann und dort (s)einen Haufen "Krempel" rundherum lötet...
Hallo ich kann einigermaßen mit einem Fahrrad (Bascom) umgehen. Warum soll ich unbedingt auf ein Einrad (C..) umsteigen? Klar, das Einrad ist viel kompakter, man kann unwahrscheinliche Kunststücke machen, sogar auf der Stelle drehen und und und. Aber das Ganze muss man auch erst lernen. Und ist das alles notwending, wenn ich nur von der Kneipe nachhause möchte? Beispiele hinken ja immer, verdeutlichen aber auch ;-) Old-Papa
BASCOM: rickshaw C: fahrrad noch fragen... ernsthaft: ICH schreibe z.B: C Code auch einfach so (quasi "Pascal ähnlich), dass ICH ihn wieder leichter lesen kann, und lasse viele "Features" absichtlich aus .. das was ich bisher in BASCOM gesehen hab, war mehr als kryptisch .. anderen Code lesen, muss ein "Anfänger" eh nicht und ob das bei den ASM libraries von Bascom einfacher ist??
:
Bearbeitet durch User
Robert L. schrieb: > findest? Ja, das finde ich. Robert L. schrieb: > ich implizierte, dass sich inzwischen auch der > "Lötkolbenspezialist"/Programmieranfänger es nicht selber schwer machen > wird und einen "großen" µC verwenden und einen Haufen "Krempel" > rundherum löten wird > wenn er einen auch nicht größeren Arduion Pro/micro/nano/mini nehmen > kann und dort (s)einen Haufen "Krempel" rundherum lötet... So, implizierst Du... Es ist auch möglich jedweden Arduino aus Bascom heraus zu programmieren. Aber gut: Ich merke, daß Du Recht haben willst und siehe da -Ich gebe Dir Recht. Ja, weil ich alt genug bin, um einzusehen, daß man Niemanden von seiner einmal gefassten Ansicht abbringen kann. MfG Paul
Old Papa schrieb: > Hallo ich kann einigermaßen mit einem Fahrrad (Bascom) umgehen. Warum > soll ich unbedingt auf ein Einrad (C..) umsteigen? Wenn Bascom ein Fahrrad ist, müsste dann C nicht eher ein Motorrad sein? Denn: - Ein Motorrad ist schneller als ein Fahrrad. - Wenn man mit dem Motorrad halbwegs umgehen kann, ist es auch weniger anstrengend. - Als Fahranfänger wird man das Motorrad ständig umschmeißen und darüber fluchen, dass es so schwer wieder aufzustellen ist. - Wer noch nie Motorrad gefahren ist, sollte erst einen Blick ins Handbuch werfen, um danach Dinge wie Kupplung und Schaltung so bedienen zu können, dass sie nicht gleich kaputt gehen. - Fahrfehler haben auf dem Motorrad meist schlimmere Folgen als auf dem Fahrrad.
Das Programm 'reziproker Frequenzzähler mit BASCOM-AVR' habe ich in zwei Stufen optimiert (siehe Codesammlung). Zunächst wurden nur die Register reduziert, die beim Interrupt gerettet werden, was schon eine deutliche Geschwindigkeitssteigerung zeigte. Im zweiten Schritt habe ich dann die Interruptroutinen komplett in Assembler geschrieben, was recht einfach umzusetzen war, da auf die globalen Variablen sehr einfach zugegriffen werden kann. Die maximale Eingangsfrequenz erhöhte sich insgesamt von ursprünglich 100 kHz auf nun > 600 kHz, was ich noch skeptisch prüfen werde, aber tatsächlich zu funktionieren scheint. Damit sieht BASCOM ganz gut aus!
ernstzunehmende Programme kann man in jeder Sprache schreiben. Da ich von Python und anderen Sprachen verwöhnt war, hatte ich beim Beginn mit Mikrocontrollern keinen Bock auf das damals noch nötige Zusammensuchen von GCC+IDE+libs. Stattdessen habe ich mit Bascom angefangen und bin dabei hängen geblieben, siehe: http://www.photonenhuette.de -> Anlage -> Programm. Bascom hat den Vorteil, das es viele Funktionen mitliefert, andererseits ist Basic nicht gerade förderlich um größere Projekte brauchbar zu modularisieren
alt geworden schrieb: > Jetzt nicht mehr! Ein Forum das nicht mal mehr für Gäste öffentlich > lesbar ist taugt nicht. Mein Interesse an LunaAVR ist damit auf null > erloschen. Schade drum! ich begreife hier nicht wieso man sich dann nicht einfach einen Instant-Account bei gmail o.Ä. macht und sich anmeldet wenn es dir denn sooo wichtig ist. Diese ganze Argumentation ist absoluter Nonsense. Ich betreibe auch ein Forum für unseren Verein und wenn nicht sicherzustellen ist das man jeden Tag auf irgendwelche juristisch problematische Beiträge prüfen kann, muss man das Ganze einfach zur eigenen Sicherheit nicht-öffentlich machen. So habe ich das dann auch gemacht. Die entsprechende Gesetzgebung und die Pflichten dazu hast du demnach noch nicht zu Gesicht bekommen wie mir scheint. Das es genügend Bekloppte gibt (MWS wird z.B. komplett ignoriert/ausgeblendet, ich will gar nicht wissen was die Tütensuppe schreibt), sieht man ja an diesem Forum. Die Moderatoren haben hier reichlich zutun.
:
Bearbeitet durch User
Ehrhardt Balstein schrieb: > muss man das Ganze einfach zur eigenen Sicherheit nicht-öffentlich > machen. Das mag für eine kleine geschlossene Benutzergruppe wie deinen Verein passen, aber für etwas wie LunaAVR, bei der du ohnehin nicht mehr jeden persönlich kennst, ist das Augenauswischerei. Wenn ich mich (deine Argumentation) mit einem Instant-Account da drumrum mogeln kann, dann kann man den Quatsch auch sein lassen, und jeden das Forum dort lesen lassen.
> Wenn ich mich > (deine Argumentation) mit einem Instant-Account da drumrum mogeln > kann, dann kann man den Quatsch auch sein lassen, und jeden das > Forum dort lesen lassen. Eine notwendige Anmeldung zum Lesen ist juristisch "nicht öffentlich". Nehmen wir an irgendein Fanatiker kommt auf die Idee hier in das Forum einen Beitrag zu schreiben der zu einem Anschlag aufruft. Wenn der Betreiber des Forums wie es in meinem Fall nur ich bin nicht schnellstens darauf reagieren kann, kann man sich recht schnell mitstrafbar machen. Hier macht es dann den entscheidenden Unterschied ob das Ganze öffentlich war oder nicht und das entscheidet dann auch im schlimmsten Fall ob man kriminalisiert wird oder nicht. Nun ist dieses Beispiel natürlich überzeichnet und mag am Ende des Spektrums liegen, aber die Abstufung bis zu "harmlos" ist sehr breit. Nicht jeder Forenbetreiber hat die Zeit und Muße und einen Wald voller Moderatoren. Ich bin auch seit Jahren erstaunt das man z.B. hier immernoch als Gast posten darf. Irgendwann wird den Moderatoren vieleicht dann doch mal was durch die Lappen gehen, was sicher einen Lernprozess zur Folge hätte. Zu wünschen ist es dem Betreiber nicht. Ich kann mir gut vorstellen, das es bei anderen Foren ähnlich gelagert ist wie bei meinem Vereinsforum.
Frank Esselbach schrieb: > Ob ein Programm "ernsthaft" ist oder nicht, macht sich nicht an der > Programmiersprache fest. Nur weil eine bestimmte IDE es erlaubt, > unübersichtlich und liederlich zu progrsammieren, muss man das ja nicht > so machen. Was hat jetzt genau die IDE damit zu tun? Es liegt wenn, dann schon an der Sprache selbst. Die IDE tut da nichts zu. Es kommt darauf an, was man von der Sprache erwartet. Abgesehen vom abgedroschenen "es liegt alles nur am Programmierer", was so natürlich auch nicht stimmt, bieten verschiedene Sprachfamilien, verschiedene Features. Dabei ist der eigentliche Syntax (vulgo "Syntaktischer Zucker") völlig egal. Die höheren Konstrukte wiederrum nicht. BASIC Dialekte bietet vor allem eines, eine sprechende Syntax. D.h. viel tippen für wenig Substanz. Dafür sieht der Code vielleicht für Anfänger schöner aus, die Syntax lässt sich leichter merken. Es fehlen kompliziert anmutende Sonderzeichen wie geschweifte Klammern oder Semikolons. Das alles ändert Objektiv nichts, hat aber subjektiven Einfluss und wird als leichter empfunden. Aber gerade BASCOM offenbart einige große Schwächen. Es sind (oder waren zumindest) nicht beliebig komplexe Ausdrücke möglich. Und das ist ein No-Go für eine ernstzunehmende Programmiersprache. Dazu kommen eigene (zusammengesetzte) Datentypen, die praktisch nicht existent sind. Das sind nur 2 Punkte einer ganzen Liste. Ein erfahrener Programmierer erkennt hier, dass man so für viele Probleme keine elegante oder saubere Lösung realisieren kann, egal wie gut man ist. Die vielgescholtene Pointerarithmetik von C, offenbart dem Programmierer auf elegante Weise viele Möglichkeiten ohne dafür viel Syntax aufwenden zu müssen. Es lassen sich viele Konzepte (auch OO) recht gut umsetzen ohne dass die Sprache selbst dafür Konstrukte enthalten muss. Bei allen Schwächen die nackte Pointer mitbringen (no seatbelts), die aber für eine hardwarenahe Entwicklung dennoch wünschenswert sind. Fazit: "Ernstzunehmend" ist sehr subjektiv und nicht zu definieren. Wem der BASIC Syntax gefällt, und nicht an die Grenzen der Sprache stößt (weil die Programme einfach bleiben oder er es nicht anders kennt), der ist mit BASCOM glücklich. Wer besseres kennt, der erkennt zu schnell den Käfig den BASCOM um das eigene Programm errichtet.
Cyblord -. schrieb: > Die vielgescholtene Pointerarithmetik von C, offenbart dem Programmierer > auf elegante Weise viele Möglichkeiten ohne dafür viel Syntax aufwenden > zu müssen. Ja, wunderbar. Diesem tollen C haben wir so ziemlich sämtliche Einfallstore zu verdanken, die mit Buffer-Overflows, Pointern, zu langen Strings usw. in den letzten Jahren aufgetreten sind. Weil dieses tolle C sich zu fein ist, darauf zu prüfen. Bzw. weil die Programmierer glauben, daß sie sooo klever sind und keine Prüfung brauchen. Ich greif mir immer an den Kopf, wenn ich von wieder mal neu entdeckten "Bugs" lese, die auf diese Weise einen Zugriff auf den Rechner erlauben. Was unter Basic oder Pascal überhaupt nicht möglich wäre, weil da einfach sauberer deklariert und geprüft wird, und solcher Dreck wie in C von vornherein ausgeschlossen ist. Aber ist ja cool und 1337, den Code so unübersichtlich wie möglich zu machen. Und Bounds prüfen ist was für Weicheier.
Timm T. schrieb: > Ja, wunderbar. Diesem tollen C haben wir so ziemlich sämtliche > Einfallstore zu verdanken, die mit Buffer-Overflows, Pointern, zu langen > Strings usw. in den letzten Jahren aufgetreten sind. Meinst du, das wäre bei den alten Assemblerprogrammen (für deren Ablösung C letztlich verantwortlich ist) besser gelaufen? > Was unter Basic oder Pascal überhaupt nicht möglich wäre, weil da > einfach sauberer deklariert und geprüft wird, Auch beim typischen Pascal-Programm wurde das bounds checking für gewöhnlich nur während der Entwicklungsphase benutzt, aber bei Auslieferung aus Performancegründen deaktiviert. Damit bist du dann kaum besser dran als bei C. Wenn die Bugs schon während der Entwicklung aufgetaucht wären, dann hätten sie wohl auch die von dir gescholteten C-Programmierer von vornherein beseitigt. Inwiefern BASIC-Dialekte vie Bascom, um das es hier ja geht, in der Tat noch Laufzeit-Boundarychecks machen, entzieht sich meiner Kenntnis.
Timm T. schrieb: > Aber ist ja cool und 1337, den Code so unübersichtlich wie möglich zu > machen. Und Bounds prüfen ist was für Weicheier. Hmm also ich sprach von "elegantem Code". Wie du da jetzt auf unübersichtlich kommst verstehe ich nicht. Billige Polemik? Ja ich glaube so ist es. Und Boundary Prüfung zur Laufzeit bläht dir viel Code in dein Projekt. Wie soll das bei kleinen Controllern gehen? Das will man meist nicht. Natürlich wäre es schön zu haben, bei einem ausgewachsenen PC Programm das mit zig MB Binarys daherkommt und sich mal schnell 500MB Speicher reserviert sieht das vielleicht anders aus. Aber dann nimmt eine andere Sprache, welche die Sicherheitsfunktionen bietet, die man will. C bietet sie nicht. Aber das ist Absicht.
Jörg W. schrieb: > Auch beim typischen Pascal-Programm wurde das bounds checking für > gewöhnlich nur während der Entwicklungsphase benutzt, aber bei > Auslieferung aus Performancegründen deaktiviert. Bei welchen Anwendungen ist den ein Check der Bounds wirklich so performancefressend, daß man den deaktivieren müßte? Die meiste Zeit wartet der Rechner doch eh auf den Benutzer bzw. auf neue Daten. Cyblord -. schrieb: > Und Boundary Prüfung zur Laufzeit bläht dir viel Code in dein Projekt. > Wie soll das bei kleinen Controllern gehen? Das will man meist nicht. Bitte? Ich mache auf dem AVR immer Bound Checking bei Benutzereingaben oder Daten, die über Uart reinkommen. Das ist halt so. Meistens sind sowieso 20% eigentliche Aufgabe des Controllers und 80% User-Interface, Display, Eingabe und Uart. Da kann ich mir die paar "wenn kleiner, begrenze auf Minimum" und "wenn größer, begrenze auf Maximum", oder "schreibe in Ringbuffer, wenn Buffer 90% voll, deaktiviere Uart" auch noch leisten, und muß mich dafür nicht mit ominösen Programmfehlern durch überschriebene Speicherbereiche rumschlagen. Dafür hab ich hier eine sauteure Kläranlagensteuerung, die vorschriftsmäßig Aktionen (Neustart, Strom weg, Pumpenfehler...) protokolliert. Dabei aber regelmäßig die Datumsangaben verwürfelt, weil der Programmierer anscheinend zu faul war, einen Plausibilitätscheck des Datums zu machen. Das verkaufen die dann aber als "mit Protokollfunktion gemäß gesetzlichen Vorgaben". Cyblord -. schrieb: > Aber dann nimmt eine andere > Sprache, welche die Sicherheitsfunktionen bietet, die man will. Nimmt man anscheinend nicht, sonst würde es nicht regelmäßig darauf beruhende gravierende Sicherheitslecks geben. Das fängt schon mit der bescheuerten Idee der nullterminierten Strings an...
Timm T. schrieb: > Bitte? Ich mache auf dem AVR immer Bound Checking bei Benutzereingaben > oder Daten, die über Uart reinkommen. Das kannst du doch nicht mit einem eingebauten Boundary Check für alle Arrays vergleichen... Dazu braucht man komplexe Datenstrukturen für jedes Array, inkl. Funktionen die darauf arbeiten. Bei JEDEM Zugriff. Heute ist ein Array nichts anderes als ein Pointer an das 1. Element. Ich denke du übersiehst den Aufwand deiner eigenen Forderungen nicht wirklich. Hast du mal näher mit solchen Konzepten auf Compiler bzw. Laufzeitbasis beschäftigt? Mir kommen solche Forderungen immer etwas blauäugig vor. Als würde man den Tischlerhobel kritisieren, weil der so scharf ist und außerdem kann man damit ganz üble Macken in die Möbel machen. Man benötigt manchmal auch derbes Handwerkszeug (C) für manche Aufgaben oder will es nutzen, und nicht nur die große schwere teure CNC Maschine. > Nimmt man anscheinend nicht, sonst würde es nicht regelmäßig darauf > beruhende gravierende Sicherheitslecks geben. Das fängt schon mit der > bescheuerten Idee der nullterminierten Strings an... Auch hier müsste sonst eine spezielle String-Datenstruktur in der Sprache eingebaut sein. Aber du kannst doch eine solche Struktur einführen in deinen Projekten. Nur warum muss man das alles zwingend in die Sprache selbst reinpacken? C ist hardwarenah geplant. No Seatbelts ist ein Feature. Keine Einschränkung. Auf kleinen Controllern machen deine Sicherheitskonzepte keinen Sinn. Der Code dafür würde manchen AVR Flash bereits sprengen.
:
Bearbeitet durch User
Timm T. schrieb: > Ich mache auf dem AVR immer Bound Checking bei Benutzereingaben oder > Daten, die über Uart reinkommen. Dann schau dir doch bitte mal die Bugs an, die du kritisiert hast. Nein, an einer Überprüfung externer Eingaben liegt das in aller Regel nicht. Das sind deutlich subtilere Fallen, in die da getappst wird. Keiner behauptet, dass C der Stein der Weisen sei. Aber ehrlich, wenn wir außer C nur BASIC gehabt hätten, dann würden Betriebssysteme wohl auch heute noch in Assembler geschrieben werden, so wie es vor C und UNIX gang und gäbe war. Ob das nun sicherheitsmäßig wirklich besser gewesen wäre, wage ich mehr als zu bezweifeln.
Cyblord -. schrieb: > Bei JEDEM Zugriff. > Heute ist ein Array nichts anderes als ein Pointer an das 1. Element. Doch ja, natürlich. Das Array hat eine Größe, und es wird geprüft, ob die angesprochene Adresse innerhalb des Arrays liegt. Wenn nicht, gibts schlimmstenfalls einen Programmfehler, aber es wird nicht außerhalb des Arrays geschrieben. Das machen Basic und Pascal genau so. Das kann man bewußt umgehen, wenn man mehr Peformance will. Aber dann muß man wissen, was man tut, und macht das nicht "aus Versehen" wie bei C. Jörg W. schrieb: > Nein, an einer Überprüfung externer Eingaben liegt das in aller > Regel nicht. Dochdoch, wenn ein Webbrowser / Mediaplayer zuläßt, daß eine Webadresse / ein Filename so lang ist, daß ein Teil des Strings im ausgeführten Speicherbereich landet, und darüber dann Zugriff auf den Programmbereich erfolgt, dann sind das genau solche fehlenden Eingabechecks. Oder wenn ein Programm mehr Daten einliest, als die Datei eigentlich lang ist, mit den gleichen Folgen. Jörg W. schrieb: > Aber ehrlich, wenn > wir außer C nur BASIC gehabt hätten, dann würden Betriebssysteme wohl > auch heute noch in Assembler geschrieben werden Du solltest Dich mal von der Vorstellung verabschieden, daß Basic im Interpreter läuft, lahm ist und nix kann. Das stimmt schon seit 20 Jahren nicht mehr.
Timm T. schrieb: > Cyblord -. schrieb: >> Bei JEDEM Zugriff. >> Heute ist ein Array nichts anderes als ein Pointer an das 1. Element. > > Doch ja, natürlich. In C meine ich. Da ist ein Array ein Pointer auf das 1. Element. Thats it. Fertig. Aus. > Das Array hat eine Größe, und es wird geprüft, ob > die angesprochene Adresse innerhalb des Arrays liegt. Wenn nicht, gibts > schlimmstenfalls einen Programmfehler, aber es wird nicht außerhalb des > Arrays geschrieben. Das machen Basic und Pascal genau so. Ist aber zur Laufzeit mit extremem Overhead verbunden. Und bringt auf Controllern wenig. Was soll das Programm tun wenn es eine illegalen Zugriff erkennt? > > Das kann man bewußt umgehen, wenn man mehr Peformance will. Aber dann > muß man wissen, was man tut, und macht das nicht "aus Versehen" wie bei Nein im Gegenteil. Man muss die Prüfung bewusst EINBAUEN. Mit viel Code.
Timm T. schrieb: > Aber dann > muß man wissen, was man tut, und macht das nicht "aus Versehen" wie bei > C. Das wesentliche Manko an C ist es, die Längeninformation des Arrays nicht mit durchzureichen, sodass die Implementierung einer solchen Prüfung nicht problemlos möglich ist. > Jörg W. schrieb: >> Nein, an einer Überprüfung externer Eingaben liegt das in aller >> Regel nicht. > > Dochdoch, wenn ein Webbrowser / Mediaplayer zuläßt, daß eine Webadresse > / ein Filename so lang ist, daß ein Teil des Strings im ausgeführten > Speicherbereich landet, Du solltest dich mal davon verabschieden, dass nach derart primitivem Muster noch nennenswert was passiert. Ja, auch sowas kommt vor, aber das meiste sind irgendwelche race conditions oder viel subtilere buffer overflows als die, die man mit so einer primitiven Methode bereits hätte erkennen können. Besonders „beliebt“ sind integer overflows, aber gerade hier hättest du ein mächtiges Problem mit der Performance, wenn du bei jeder Multiplikation vorab die Argumente überprüfen willst. >> Aber ehrlich, wenn >> wir außer C nur BASIC gehabt hätten, dann würden Betriebssysteme wohl >> auch heute noch in Assembler geschrieben werden > > Du solltest Dich mal von der Vorstellung verabschieden, daß Basic im > Interpreter läuft, lahm ist und nix kann. Das stimmt schon seit 20 > Jahren nicht mehr. Nichtsdestotrotz kann ich mir in BASIC beim besten Willen kein OS vorstellen. Da fehlen einige Features, auf die man in C von vornherei geachtet hat, indirekte Funktionsaufrufe beispielsweise. Hat BASIC inzwischen Datestrukturen? Vor 45 Jahren jedenfalls (als C angetreten ist, den Assembler beim OS abzulösen) war da wohl weit und breit nichts dergleichen, und auch die von dir genannten 20 Jahre helfen da nicht – da waren die Messen bereits gesungen. Pascal war einigermaßen parallel entstanden, aber halt als Lehrsprache, weshalb gezielte Typumwandlungen eben auch dort fehlen.
Timm T. schrieb: > Doch ja, natürlich. Das Array hat eine Größe, und es wird geprüft, ob > die angesprochene Adresse innerhalb des Arrays liegt. Das kann man machen, solange man noch weiss, dass man es mit einem Array zu tun hat. Aber spätestens, wenn man dann mit Arrays und Funktionen arbeitet, ist dem in C nicht mehr so. Da verschwimmen die Grenzen. Und das ist ganz bewusst so gemacht worden. Daher ist in C ein nicht gemachter Bounds Check kein vergessenes Feature sondern ist schlicht und ergreifend nicht möglich. Dazu müsste man die Sprache in wesentlichen Bereichen komplett umbauen. > Das kann man bewußt umgehen, wenn man mehr Peformance will. Aber dann > muß man wissen, was man tut, und macht das nicht "aus Versehen" wie bei > C. Sicherlich. Wer die Tante zum Lulu gehen braucht, für den ist C die falsche Sprache. Hier ist schon der Entwickler gefragt, sorgfältig zu arbeiten. Das wiederum, da bin ich ganz bei dir, geht öfter schief als einem lieb ist. Die Intention von C war von vorne herein keine Sprache mit Sicherheitsnetz sondern ein "You asked for it, you got it" Es gibt nur 2 mögliche Auswege * eine andere Sprache nehmen * die 'ich kann nur 20% von C aber mehr interessiert mich nicht' Fraktion der Jungprogrammierer von der ernsthaften Entwicklung fernhalten, bis sie erwachsen geworden sind und nicht nur ihre Rechte sondern auch ihre Pflichten kennen, denen sie sich mit der Programmierung in C unterwerfen.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.