Hallo Leute, heute habe ich im Büro entdeckt, dass auch andere Kollegen mit AVR Microcontroller arbeiten und einer davon hatte sogar alles, was man braucht (Testplatinen, sowohl gekauft wie auch selbst gepastelt, Programmer und co.) im Schrank. Was mich gewurdert hat, dass sogar "C eingefleischte", also Leute die Basic nur dann anrühren, wenn es anders nicht mehr geht und vorallem auf die Frage über "Microncroller-Sprache" nur eine Antwort kennen: "C und C und wieder C" doch mit BASCOM arbeiten... angeblich weil man damit viel schneller zum Ziel kommt und dies ohne viel unnötiger Ballast mitzuschleppen, also: BASCOM soll schnell und effektiv sein!!! Da ich diese Leute sehr gut kenne und genau weis, dass sie alles was mit BASIC zu tun hat (eigentlich) hassen, frage ich mich wie viel besser BASCOM als WinAVR sein muss! Hat jemand von euch Erfahrungen sowohl mit WinAVR wie auch mit BASCOM gemacht und kann vielleicht kurz was dazu sagen? Dabei geht es nicht um die Frage ob C oder BASIC! Die Antwort auf diese Frage ist ja eindeutig!!! Es geht viel mehr um die Frage wie mächtig die BASCOM-Library wirklich ist? Also übertragen auf die PC-Programmierung: muss ich das Befehl printf selbst codieren oder stellt WinAVR auch 'ne VERNÜNFTIGE LIB zur verfügung? Wie sehr steht diese der von BASCOM hinterher? Wurde mich freuen von Leute die beides gut kennen zu hören!!! Ciao + bis bald Giovanni!!!
Hi, ist bei mir auch so! C schreib ich nur wenn der Kunde das wünscht, bzw wenn der Vertrag die Herausgabe eines Quellcodes fordert (kostet halt das 10-Fache) und Bascom benutze ich wenns eilt und auf anhieb laufen soll. Im endeffekt kann bascom alle instruktionen wie auch der c. nur ist der dialekt anderst, und man hat schon fertige module bzw routinen dabei (config lcd... config spi, config graphlcd, config blablabla).
Giovanni Garamella wrote: > angeblich weil man damit viel > schneller zum Ziel kommt und dies ohne viel unnötiger Ballast > mitzuschleppen, also: BASCOM soll schnell und effektiv sein!!! Was sind denn das für Projekte, die diese C-Profis mit Bascom realisieren, d.h. welchen Umfang haben sie? Und wieviel Projekte realisierten sie schon mit AVRs? Man sieht hier z.B. oft, daß mit zunehmender Erfahrung und Projektgröße irgendwann der Umstieg von Bascom oder Assembler nach C erfolgt. Ich persönlich mag Wizzards und Black-Boxes nicht, sondern weiß lieber, was ich mache. Ich denke auch nicht, daß ich länger brauche, um z.B. Timer, UART, ADC usw. zu konfigurieren. Ich geh dann einfach ins Datenblatt unter Register-Description und setze die 2-3 Register entsprechend. Man sieht ja häufig, daß Anfänger geradezu heiß auf Wizzards sind und soger selber welche anfangen zu programmieren. Aber meistens verläuft dann sowas im Sande, da man sie dann nicht mehr braucht. Ich mache auch gerne Sachen (Debounce, LCD usw.) mit Interrupts, statt wie Bascom mit Polling oder Delays. Dadurch hat man deutlich mehr CPU-Leistung verfügbar. Peter
>und man hat schon fertige module bzw routinen dabei
Und genau da liegt die Gefahr. Wenn nämlich die fertigen Module
fehlerhaft sind bist du im Zweifelsfalle für Dinge haftbar von deren
Funktion du keine Ahnung hast, weil Du den Quellcode nicht kennst.
Die Projekte gehen von Überwachungselektronik, also einlesen von Sensoren und Aktuatorik, sowohl digital, wie auch analog, überprüfen ob das ganze zusammenpasst und im Notfall abschalten des Gerätes, bis zu (dann aber nur privat) Bau von Modellautos und -flugzeuge. Was sie bei diese private projekte genau mit ein Microcontroller machen weis ich jedoch nicht! Das Argument mit Interrups spricht meine Meinung nach auf jeden Fall für das "selber Programmieren" jedoch habe ich auch nichts dagegen fertige Module zu benutzen, und diese sollen bei BASCOM eben sehr Leistungsfähig sein... auch wenn das Entprellen über delay nicht gerade dafür spricht... Naja... bin gespannt was noch kommt, vieleicht auch mit konkrete Beispiele! Nicht, dass ich an einen Umstieg denke, und zwar schon deswegen nicht, weil ich mich kaum in BASIC auskenne, sondern vorallem, weil ich es immer noch nicht glauben kann, dass gerade die BASIC-Gegner auf einmal doch in BASIC programmieren. Ciao + bis Bald Giovanni
Peter Dannegger wrote: >Ich geh dann einfach ins Datenblatt unter > Register-Description und setze die 2-3 Register entsprechend. Genau das kostet Zeit und entfällt bei Bascom. Mir ist es auch völlig wurschd was andere denken. Ich muss damit Geld verdienen, und jede Minute die ich fürs rumlesen vertue kann ich nicht in andere Projekte stecken...
>>Ich geh dann einfach ins Datenblatt unter >> Register-Description und setze die 2-3 Register entsprechend. >Genau das kostet Zeit und entfällt bei Bascom. Mir ist es auch völlig >wurschd was andere denken. Ich muss damit Geld verdienen, und jede >Minute die ich fürs rumlesen vertue kann ich nicht in andere Projekte >stecken... Bei Bascom muß man wissen, wie man die Blackbox anspricht. Wenn man schon öfer Controller der gleichen Famlie programmiert hat, dann weiß man, wie man z.B. Timer programmiert; man muß höchstens nachgucken, wie die Register inzwischen benannt wurden. Die Balckboxes kann man sich auch schön selber in C programmieren und dann per include mit ins Programm laden. Wenn man das mal selber gemacht hat, dann kann man auch irgendwann die Programme optimieren, was ich mir unter Bascom schwer vorstellen kann; ausser man umgeht die Blackboxes und kümmert sich selber um das Register- und Bitgeschubse - dann kann man es aber auch gleich damit anfangen und spart sich die Sackgasse. Man kommt mit Bascom schnell zu Ziel - mit C und Assembler auch...
> Genau das kostet Zeit und entfällt bei Bascom. Mir ist es auch völlig > wurschd was andere denken. Ich muss damit Geld verdienen, und jede > Minute die ich fürs rumlesen vertue kann ich nicht in andere Projekte > stecken... Erfahrungsgemäß verläuft die eigentliche Codierung recht zügig. Der größere Zeitaufwand entsteht durch Bugfixing und das reinquetschen von letzten, noch schnell vom Kunden nach geforderten Features. Und gerade durch ausgereizte Ressourcen (Stack und Rechenzeit) verursachte Bugs sind echt eklig zu finden. Da ist man dann froh, wenn man die Funktion der Blackbox verstehen kann und ggf. auch mal eingreifen kann. Und das geht bei BASCOM doch nicht, oder? Die Hardware-Initialisierung einer Peripherie unter C mag dann nicht 10s sondern 5 Minuten dauern. Aber die paar Minuten spart man dann später, wenns im Controller eng wird. Ich denke mal BASCOM kürzt einzig die "Lern"-kurve ab, da man auf das verstehen der Architektur verzichtet. Das kann bei einem Einmal-Projekt mit überdimensionierter Hardware durchaus gut sein, auf Dauer halte ich es für eher ungesund.
Hmm... wrote: > Und das > geht bei BASCOM doch nicht, oder? Wieso nicht?
Habe mir die BASCOM-Libs noch nie tiefer angeschaut. Liegen die in Quellform vor?
Ich kenne BASCAOM nicht. Nach allem, was ich hier lese, scheint es ja dadurch zu bestechen, dass zahlreiche Hardware-Initialisierungs-(und mehr?)-Rountinen vorhanden sind, die man einfach benutzen kann, ohne zu tief ins Datenblatt zu schauen. Wie sind diese denn gestrickt? Wird der Quellcode mitgeliefert? Kann man diese Routinen verändern? Oder bleiben es für den Anwender 'Black-Boxes'?
@Giovanni >Da ich diese Leute sehr gut kenne und genau weis, dass sie alles was mit >BASIC zu tun hat (eigentlich) hassen, frage ich mich wie viel besser >BASCOM als WinAVR sein muss! Warum fragst Du dann nicht einfach "diese Leute", bzw. was sagen sie zu diesem Thema?
Ich hab ja eine gekaufte Version von Bascom hier. Hab gerade nachgeschaut und die "lib" sind nichts weiter als assmbler-files
Man kann im Bascom viele "Geräte" wie Timer, UART, AD-Wandler-Kanäle usw. mit der CONFIG-Anweisung einstellen. Darüber sind aber nicht alle möglichen Einstellungen zugänglich. Es ist aber auch erlaubt, die einzelnen Bits in ihrem jeweiligen Register "von Hand" zu konfigurieren. Damit kommt man dann auch an alle Möglichkeiten heran. Man muß im Datenblatt nachsehen, was das bedeutet, weiß dann aber auch, was geschieht und muß sich nicht (so oft) verwundert am Kopf kratzen.;-) Z.B.so: TIMSK.TICIE1=1 Fertige Befehle sind nicht schlecht, aber manchmal sind dann Kompromisse nötig. Beispiel: Der Servo-Befehl. Der benutzt den Timer0 und dieser Timer muß dann vom Benutzer in Frieden gelassen werden. Wenn man den Timer0 für andere Sachen braucht, dann muß man sich eben selbst eine Routine schreiben, um einen Servo anzusteuern. Etliche Sachen sind in Bibliotheken ausgelagert. Dabei gibt es 2 Arten: .lib, das sind die "richtigen" Bibliotheken, die man mit einem Editor anschauen kann und die auch lesbaren Assembler-Quelltext enthalten. Zweitens gibt es die .lbx-Dateien. Diese sind vorkompiliert und dort drin kann man nur Kauderwelsch erkennen. MfG Paul
Mit Bascom ist es halt genauso wie mit den 4th GLs, die in der IT vor ein paar Jahren (10-20) schwer in Mode waren: Man kann viele einfache Dinge schnell und ohne Kenntnisse der Details und Technologie erreichen. (80% in 25% der Zeit). Leider ist es halt oft so, daß man entweder für die letzen 20% nochmal die 5 fache Zeit braucht oder sie überhaupt nicht hinbekommt. Einfache Dinge, wie A/D Werte auf einem LCD darzustellen gehen natürlich schnell. Auch einen RC5 Fernbedienungscode kann man ruck-zuck einlesen - eine Routine zu bauen, die beliebige IR Codes einliest wird dafür schon sehr viel schwieriger bis unmöglich sein. Das Problem ist halt das Handling knapper Resourcen (wie z.B. Timer). Wenn mehrere Dinge gleichzeitig laufen sollen, muß man z.B. einen durchlaufenden Timer an mehreren Stellen nutzen. Wenn nur eine closed Box da ist, die irgendwie den Timer nutzt, wird das recht schwierig. Das mag zwar mit Bascom auch gehen - nur habe ich dann den gleichen Aufwand in einer Programmiersprache, die bei knappen Speicherresourcen und "Bitschiebereien" viel umständlicher ist als C. Es gibt natürlich auch noch die Anhänger von Assembler, die sagen, daß man bei C nie genau weiß was passiert - in Summe ist aber C der beste Kompromiss, auch komplexe Projekte Hardwarenah und doch verständlich zu realsieren. Das wird auch jeder feststellen, der sich in der Industrie umsieht - 90% aller Anwendungen für aktuelle Microcontroller sind in C realisiert. Auch die RISC Architekturen vieler aktueller Prozessoren sind für C optimiert worden. (Bei den älteren 8051 Architekturen mag das noch anders aussehen, hier überwiegt wahrscheinlich Assembler). Gruß, Marcus
Marcus Müller wrote: > Einfache Dinge, wie A/D Werte auf einem LCD darzustellen gehen natürlich > schnell. Auch einen RC5 Fernbedienungscode kann man ruck-zuck einlesen - > eine Routine zu bauen, die beliebige IR Codes einliest wird dafür schon > sehr viel schwieriger bis unmöglich sein. Ich hab in Bascom die komplette Steuersoftware für so einen Mikrokopter realisiert (inc GPS, Kompas und 2 Servos für Funkkamera)... Absolut kein Prob!
ist BASCOM nicht eigentlich nichts anderes, als eine andere art von assemler ?? nur etwas anders verpackt? und eigentlich nur gestützt, durch die schon vielen vorhandnen module.
gast wrote: > ist BASCOM nicht eigentlich nichts anderes, > als eine andere art von assemler ?? > > nur etwas anders verpackt? > und eigentlich nur gestützt, > durch die schon vielen vorhandnen module. Bascom ist ein Compiler mit Basic dialekt. Kann aber das gleiche wie C-Entwicklungsumgebungen! Das meiste davon geht aber komfortabler als bei c
nur der BASCOM-Compiler ist direkt auf den AVR-RISC-Code zugeschnitten, und kann das optimaler umsetzen, als die meisten C-Compiler ??
Alex W. wrote: > Peter Dannegger wrote: > >>Ich geh dann einfach ins Datenblatt unter >> Register-Description und setze die 2-3 Register entsprechend. > > Genau das kostet Zeit und entfällt bei Bascom. Witz komm raus, Du bist umzingelt. Du weißt also schon von Geburt an, wie Du unter Bascom was konfigurieren mußt, welche Befehle es dafüf gibt und wie sie funktionieren. Natürlich muß man auch unter Bascom irgendeine Doku lesen, um was einzustellen. > Mir ist es auch völlig > wurschd was andere denken. Ich muss damit Geld verdienen, und jede > Minute die ich fürs rumlesen vertue kann ich nicht in andere Projekte > stecken... Ich möchte damit auch Geld verdienen und deshalb "vertue" ich lieber ein wenig Zeit mit dem Lesen der Doku und spare damit viel mehr Zeit, weil ich es gleich richtig hinschreiben kann, statt planlos rumzuprobieren. Insbesondere die Unterschiede zwischen den AVRs kann man viel leichter und verständlicher dem Datenblatt entnehmen. Du wirst warscheinlich erst nach vielen vergeblichen Versuchen feststellen, daß z.B. ein AVR keinen T2 hat, der andere keine Dead-Time-Einstellung, wieder ein anderer keine ADC-Verstärkung von 32 usw. Peter
Peter Dannegger wrote: > Witz komm raus, Du bist umzingelt. geht nicht! Tür klemmt! > Ich möchte damit auch Geld verdienen und deshalb "vertue" ich lieber ein > wenig Zeit mit dem Lesen der Doku und spare damit viel mehr Zeit, weil > ich es gleich richtig hinschreiben kann, statt planlos rumzuprobieren. > Was soll das? Kritisierst Du hiermit meine Arbeit oder was? Denkst Du wirklich das ich wegen irgendeinem Heini der glaubt C ist das Göttliche auch sofort in C weiterschreibe? Nee, in keinem Fall! Ich arbeite weiterhin in Bascom, es sei denn man zahlt mir ordenlich... Und Du kannst nichts dagegen machen... Auch wenn Du mir hier drohen würdest Deine Suppe nicht auszuessen!
OK Leute, ihr seid wirklich super... und ein wenig gläubisch (http://www.aegisub.net/2008/12/if-programming-languages-were-religions.html), aber nur ein wenig ;-) So wie es aussieht verhält es sich zwischen BASCOM und C genau so, wie mit VB und C++... der einer ist für Anfänger einfacher, führt auch Profis schnell zum Ziel und ist so vollgepackt mit Funktionen, dass sogar die Office-Programmierer bei MS sich nicht davon lösen wollten, der andere ist flexibler und oft auch effektiver, eben das Richtige für Hardwarenahe Programmierung, aber man muss sich etwas mehr in Materie auskennen! Ich dachte dies wäre nur eine "PC-Krankheit" aber so wie es aussieht sind Microcontroller genau so davon betroffen... SCHADE!!! Nach das was ich hier gehört habe bleibe ich auf jeden Fall bei C... nicht, dass meine Anwendung jemals den ATmega88 überfordern könnte, aber mein Programmierstil hänelt sowiso Assembler... also was soll ;-) re-Danke Giovanni
Peter Dannegger wrote: > Witz komm raus, Du bist umzingelt. geht nicht! Tür klemmt! > Ich möchte damit auch Geld verdienen und deshalb "vertue" ich lieber ein > wenig Zeit mit dem Lesen der Doku und spare damit viel mehr Zeit, weil > ich es gleich richtig hinschreiben kann, statt planlos rumzuprobieren. > Was soll das? Kritisierst Du hiermit meine Arbeit oder was? Denkst Du wirklich das ich wegen irgendeinem Heini der glaubt C ist das Göttliche auch sofort in C weiterschreibe? Nee, in keinem Fall! Ich arbeite weiterhin in Bascom, es sei denn man zahlt mir ordenlich... Und Du kannst nichts dagegen machen... Auch wenn Du mir hier drohen würdest Deine Suppe nicht auszuessen! Ist doch jedes mal das selbe Katz und Maus Spiel! c ist umstanstädlich! Diese hin und her springerei und sonstiges, ekelhaft. bascom ist einfach und gut!
> Peter Dannegger wrote: > >Ich geh dann einfach ins Datenblatt unter > Register-Description und setze die 2-3 Register entsprechend. > Stimmt. > Insbesondere die Unterschiede zwischen den AVRs kann man viel leichter > und verständlicher dem Datenblatt entnehmen. > > Du wirst warscheinlich erst nach vielen vergeblichen Versuchen > feststellen, daß z.B. ein AVR keinen T2 hat, der andere keine > Dead-Time-Einstellung, wieder ein anderer keine ADC-Verstärkung von 32 > usw. Stimmt nicht! Es gibt eine sehr gute Hilfe in Bascom, wo von GCC nur Träumen kann.
Ich besitze Bascom und bin recht zufrieden damit. Ich bevorzuge im allgemeinen Basic-Dialekte, weil ich ausgeschriebene Wörter übersichtlicher finde als den C-Zeichen-Wirrwar, das mag aber auch Gewohnheit sein. In der Vollversion liegen die meisten Libs als kommentierter ASM-Code vor, wer will kann sich also diese Blackboxes im Detail ansehen und gegebenenfalls anpassen. Auch Inline-Asm, Register setzen etc. ist möglich. Man kann in Bascom (genauso wie in C auch) mit Polling etc. arbeiten, oder die Interrupts etc. benutzen. Mit Timern hatte ich auch noch nie ein Problem, verwende meistens einen Software Timer für die "langsameren" Sachen und die verbleibenden 1-2 Timer für die zeitkritischen Dinge. Man kann in Bascom genauso komplexe und umfangreiche Dinge wie in C realisieren, aber um eine genaue Kenntnis was man da eigentlich macht wird man in beiden Fällen nicht herumkommen. Am Rande bemerkt finde ich (und ein paar meiner Kollegen auch) die WinAVR-IDE recht unübersichtlich, allerdings lässt sich der GCC z.b. auch in die Visual-Studio IDE o.ä. integrieren. Die Bascom-IDE ist recht übersichtlich und schlank, der integrierte Simulator ist auch recht hilfreich beim Debuggen. Allerdings vermisse ich auch ein paar nette Features, IntelliSense wäre nicht schlecht :) Als Fazit könnte man sagen, beide Wege können meistens nach Rom führen ;) Welchen man wählt ist bis auf wenige Fälle eher Geschmacks- und Gewohnheitssache.
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.