Nach den üblichen C vs. ASM Diskussionen, Lunaavr usw kommt jetzt Javascript für Microcontroller. Was haltet Ihr davon? http://hackaday.com/2013/08/16/microcontrollers-and-node-js-naturally/ http://technical.io/ Da sowieso alle jungprogrammierer fleissig Javascript lernen (wegen Web2.0, AJAX, usw.), wird Javascript für MCU wohl schnell Anklang finden.
Tim . schrieb: > Da sowieso alle jungprogrammierer fleissig Javascript lernen (wegen > Web2.0, AJAX, usw.), wird Javascript für MCU wohl schnell Anklang > finden. Das lernen die ganzen Informatiker. Der klass. Entwickler lernt das nicht oder nur akademisch zur Demonstration des OOP. Das ist was für die Embedded Entwickler. Höchstens. Interessant wäre vielmehr wieviel von der Leistung nach der Javaisierung des Mikrocontrollers noch über bleibt. Der CortexM3 ist ja nicht unbeliebt ... bin gespannt. Für die kleinen Hobbycontroller wird das sicher nichts.
"Microcontroller" - Sowohl PIC16 als auch ARM M4 laufen unter dem Begriff Microcontroller. Wer schreibt ein ARM Programm noch in Assembler? Oder hoch optimierten C-Tricksereien? Auch bei dem MCs wird die Programmierung teurer als die Hardware. Wenn JS-Programmierer am billigsten sind, nimmt ein BWLer halt M4 und Javascript.
Nein, bei dem Teil gehts nicht darum "professionelle" Sachen zu machen, sondern die Einstiegshürde für Bastler zu reduzieren. Mit dem Teil muss man sich nicht mehr eine aufwändige Entwicklungsumgebung installieren, sondern man kann einfach direkt loslegen. Ich denke das ist eine spannende Entwicklung, auch wenn der praktische Nutzen im Moment sehr klein ist.
Siehe "Jamaica-VM". Ist auch so was ähnliches... Gibt's schon seit 2..3 Jahren auf der Embedded. Ach, jedes Jahr wird ne neue Sau durch's Dorf getrieben, ein paar neue supertolle Programmiersprachen erfunden - die natürlich alles bisher dagewesene glatt in den Schatten stellen, Linux auf den PIC16C84 (endlich!) portiert... Aber wie man ne Taste entprellt oder zwei Byte zu einem Int zusammensetzt oder mit nem PT100 die Temperaatur und nicht die Versorgungsspannung mißt, das sind Sachen, wo das Wissen darüber mittlerweile verschütt gegangen ist. Witz von vor 30 Jahren: Mutter erklärt ihrem Söhnchen bei den Schulaufgaben: "Schau mal, wenn du 3 Taschenrechner hast und noch zwei dazulegst, wieviele Taschenrechner hast du dann?" W.S.
> We're launching soon!
Klingt sehr aufregend.
Im Ernst: die bellen nur, die beißen nicht.
Kein Name schrieb: > "Microcontroller" - Sowohl PIC16 als auch ARM M4 laufen unter dem > Begriff Microcontroller. > > Wer schreibt ein ARM Programm noch in Assembler? Oder hoch optimierten > C-Tricksereien? Auch bei dem MCs wird die Programmierung teurer als die > Hardware. Wenn JS-Programmierer am billigsten sind, nimmt ein BWLer halt > M4 und Javascript. Und ignoriert dabei ganz einfach die Tatsache dass die unterliegende JS-Runtime ganz sicher in C geschrieben ist, ebenso wie das evtl. vorhandene OS usw. Merke: ohne C geht nicht viel, um nicht zu sagen garnix. ;-) Ach ja, zu Javascript: es gibt ein Buch, "JavaScript: The Good Parts". Wer JS noch benutzen will nachdem er das gelesen hat ist offensichtlich durchgeknallt und sollte verurteilt werden mindestens 10 Meter Abstand von allem mit einer CPU, besser noch allem mit digitaler Logik, zu halten. Nur mal ein Beispiel-Zitat: "JavaScript has two sets of equality operators: === and !==, and their evil twins == and !=.". Und nun geh mal los und frag einen der Javascript-Jockeys ob sie überhaupt wissen dass es === und !== gibt und was die im Gegensatz zu == und != tun, und warum == und != die böse Variante sind. Muhahahahaha, wir benutzen Javascript, ja, genau, das ist hip, das ist cool! Wieso rennen eigentlich alle immer irgendwelchen Modetrends hinterher, macht Lagerfeld neuerdings Programmiersprachen?
Jasch schrieb: > frag einen der Javascript-Jockeys ob sie überhaupt wissen > dass es === und !== gibt und was die im Gegensatz zu == und != tun, und > warum == und != die böse Variante sind. -> Zwei Zeichenketten sind genau gleich, wenn sie die gleiche Abfolge von Zeichen, die gleiche Länge und gleichen Zeichen in entsprechenden Positionen haben. -> Zwei Zahlen sind genau gleich, wenn sie numerisch gleich (die gleiche Anzahl Wert) sind. -> Positive und negative Nullen sind einander gleich. -> Zwei boolesche Operanden sind genau gleich, wenn beide wahr sind oder beide falsch sind. -> Zwei Objekte sind gleich, wenn sie strikt auf das gleiche Objekt verweisen. -> Null und undefined Typen sind == (aber nicht ===). [D.h. Null == Undefined (aber nicht Null === Undefined)] Ein Beispiel: Beim "==" Operator (Equality) sieht es wie folgt aus: true == 1; // "true", weil 'true' zu 1 umgewandelt und dann verglichen wird "2" == 2 //"true", weil 2 zu "2" umgewandelt und dann verglichen wird wohingegen beim "===" Operator (Identity) true === 1 //"false" ist "2" === 2 // "false" ist
Und wo sind die Java-Mikrocomputer, die uns seit Jahren versprochen wurden?
Jasch schrieb: > Und ignoriert dabei ganz einfach die Tatsache dass die unterliegende > JS-Runtime ganz sicher in C geschrieben ist, ebenso wie das evtl. > vorhandene OS usw. Ja und? Ist doch in diesem Zusammenhang vollkommen egal. > Ach ja, zu Javascript: es gibt ein Buch, "JavaScript: The Good Parts". > Wer JS noch benutzen will nachdem er das gelesen hat ist offensichtlich > durchgeknallt und sollte verurteilt werden mindestens 10 Meter Abstand > von allem mit einer CPU, besser noch allem mit digitaler Logik, zu > halten. Blödsinn. Ich dachte du kennst C. Da gibt es doch noch viel mehr solcher Stolperfallen. Nur, dass JS mehr vergibt und es daher wohl mehr Amateurprogrammierer als bei C gibt. Aber wenn man die paar JS-Fallstricke (z.B. ===) einmal kennt - und so schwer ist das nicht - dann ist JS eine durchaus interessante Sprache.
Für nächstes Jahr erwarten wir AVR-Object-COBOL. Damit hat's der BWL(-Informatiker) noch einfacher. Das kann er selbst!
W.S. schrieb: > Siehe "Jamaica-VM". Ist auch so was ähnliches... > Gibt's schon seit 2..3 Jahren auf der Embedded. Bitte Java und Javascript nicht verwechseln.
C++ schrieb: > Für nächstes Jahr erwarten wir AVR-Object-COBOL. > Damit hat's der BWL(-Informatiker) noch einfacher. Das kann er selbst! Da würde ich mir aber lieber einen BF Interpreter wünschen! Da hab ich mal auf dem PC mit rumgespielt, ist echt witzig. http://de.wikipedia.org/wiki/ -Link geht nicht- Ja, ja der Link nach wikipedia funktioniert nicht: Der Beitrag scheint Spam zu enthalten: "f*ck" :) Bald wird er auch noch 'Anal'ogelektronik blockieren...
Rene Schube schrieb: > http://de.wikipedia.org/wiki/ -Link geht nicht- http://de.wikipedia.org/wiki/Brainf%75ck
Bevor ich Lua kennenlernte, habe ich Spider-Monkey benutzt (auf PC), um eine Scriptsprache zu erweitern mit neuen Funktionen und Klassen. So schlecht fand ich das nicht. Für uC würde ich natürlich schon aus Ressourcen-Gründen nur Lua verwenden.
javascript wird eh auf dem browser ausgefuehrt. was soll das auf einem comtroller ?
маленкий зеленый троль schrieb: > javascript wird eh auf dem browser ausgefuehrt. was soll das auf einem > comtroller ? JavaScript wird auch in Browsern ausgeführt. In den letzten Jahren hat sich die Sprache mit node.js, Rhino usw. allerdings auch in anderen Umgebungen verbreitet. Und jetzt ja vielleicht auch im Bereich der Mikrocontroller-Programmierung. Wenn Performance oder Kosten keine große ROlle spielen (also gerade beim Hobby-Entwickler) wäre das eine schöne Alternative zu C.
Tim . schrieb: > Nach den üblichen C vs. ASM Diskussionen, Lunaavr usw kommt jetzt > Javascript für Microcontroller. Was haltet Ihr davon? Abstand. Wenn man sowas haben wöllte, dann würde man ohnehin Lua nehmen. Was es - nebenbei bemerkt - schon ein paar Jährchen gibt. Aber natürlich braucht man sowas so gut wie nie. Den hardwarenahen Teil - Initialisierung, Zugriffe auf Ports und interne Resourcen - muß man ja sowieso erst mal in C machen, um es dann an seine Lua (oder meinetwegen JS) Programme zu exportieren. Und wenn man erst mal so weit ist, daß man den Zugriff auf z.B. den ADC oder PWM zu einer benutzbaren API abstrahiert hat, dann kann man den Rest des Programms auch gleich in C schreiben. XL
Axel Schwenke schrieb: > Und wenn man erst mal so weit ist, daß man den Zugriff auf > z.B. den ADC oder PWM zu einer benutzbaren API abstrahiert hat, dann > kann man den Rest des Programms auch gleich in C schreiben. Das wäre natürlich nicht gerade sinnvoll. Würde wohl auch niemand so machen. Wenn aber einer ein Framework schreibt, welches die Hardware abstrahiert, dann könnte man das natürlich in verschiedenen Projekten verwenden und bräuchte keinen C-Code zu schreiben. Wenn das gut gemacht wäre hätte das schon seinen Reiz.
Jan Hansen schrieb: > Wenn aber einer ein Framework schreibt, welches die Hardware > abstrahiert, dann könnte man das natürlich in verschiedenen Projekten > verwenden und bräuchte keinen C-Code zu schreiben. Wenn das gut gemacht > wäre hätte das schon seinen Reiz. Träum weiter. Da reicht nicht "einer". Das müssten dann schon viele sein die die gefühlten 10000 verschiedenen Controller anpassen. Und in was schreiben die den Anpassungscode? In C! Und warum sollten sie diesen Unsinn tun? Diese Leute sind dazu in der Lage die anfallenden Aufgaben problemlos in C/C++ zu lösen. Und das nicht fehleranfälliger als ein DAU in js oder so. Die müßten mit dem Klammerbeutel gepudert sein wenn sich sich da freiwillig noch eine zusätzliche Baustelle reinholen würden. Was nützt dir eine schicke neue Sprache wenn es dafür keinen Debugger gibt? Und bis das soweit ist gibt's schon die übernächste neue Sprache. Bleiben wir bei JS. Auf dem PC geht mittlerweile jeder davon aus, dass es Speicher ohne Ende gibt. In allen Programmiersprachen ist es hier so, dass der gesamte zur Laufzeit von Strings, Objekten usw. benötigte Speicher da sein muss. Ansonsten wird ausgelagert. Wenn es dann trotzdem nicht reicht gibt's maximal eine Fehlermeldung. Meistens aber nur einen Absturz. Da unterscheidet sich der new-Operator von C++ nicht von dem in Java oder JavaScript. Da das in "modernen" Programmiersprachen millionenfach aufgerufen wird, landet es maximal in einem einzigen Errorhandler der das Programm dann beendet. Sowas will keiner auf einem kleinen Controller haben. Zumal man es auch nicht abschätzen kann vieviel Speicher denn das wunderschöne JavaScript-Programm denn wirklich braucht. Sowas würde doch nur dazu führen, dass noch mehr Idioten glauben sie könnten Controller programmieren, können real aber nur ein paar Funktionen aufrufen und haben keinen Schimmer von dem was da passiert. Wenn das die Zukunft sein soll, dann ist es besser man erlebt es nicht mehr.
old man schrieb: > Träum weiter. Da reicht nicht "einer". Das müssten dann schon viele sein > die die gefühlten 10000 verschiedenen Controller anpassen. Und in was > schreiben die den Anpassungscode? In C! Und warum sollten sie diesen > Unsinn tun? Diese Leute sind dazu in der Lage die anfallenden Aufgaben > problemlos in C/C++ zu lösen. Und das nicht fehleranfälliger als ein > DAU in js oder so. Die müßten mit dem Klammerbeutel gepudert sein wenn > sich sich da freiwillig noch eine zusätzliche Baustelle reinholen > würden. Antwort: Weil sie können! Jeder der ein gutes Framework entwickeln kann, kann auch ohne dieses Framework sehr gut programmieren. Trotzdem gibt es viele Entwickler, die das einfach aus Interesse machen. Nicht nur für sich selbst, sondern eben auch für andere die nicht so geübt und erfahren sind. > Was nützt dir eine schicke neue Sprache wenn es dafür keinen Debugger > gibt? Und bis das soweit ist gibt's schon die übernächste neue Sprache. JS als interpretierte Skriptsprache lässt sich recht gut debuggen. Außerdem ist JS ganz bestimmt keine "neue Sprache". > Bleiben wir bei JS. Auf dem PC geht mittlerweile jeder davon aus, dass > es Speicher ohne Ende gibt. In allen Programmiersprachen ist es hier so, > dass der gesamte zur Laufzeit von Strings, Objekten usw. benötigte > Speicher da sein muss. Ansonsten wird ausgelagert. Wenn es dann trotzdem > nicht reicht gibt's maximal eine Fehlermeldung. Meistens aber nur einen > Absturz. Ja, der Speicher muss da sein. Das ist bei C nicht anders. Auf dem kleinsten Tiny wird man auch kein JS laufen lassen, aber auf den größeren Controllern wäre das für kleine Programme kein Problem. > Da unterscheidet sich der new-Operator von C++ nicht von dem in > Java oder JavaScript. Da das in "modernen" Programmiersprachen > millionenfach aufgerufen wird, landet es maximal in einem einzigen > Errorhandler der das Programm dann beendet. Sowas will keiner auf einem > kleinen Controller haben. Wer redet denn von einem "kleinen" Controller? > Zumal man es auch nicht abschätzen kann > vieviel Speicher denn das wunderschöne JavaScript-Programm denn wirklich > braucht. Doch, abschätzen lässt sich das durchaus. > Sowas würde doch nur dazu führen, dass noch mehr Idioten > glauben sie könnten Controller programmieren, können real aber nur ein > paar Funktionen aufrufen und haben keinen Schimmer von dem was da > passiert. Wenn das die Zukunft sein soll, dann ist es besser man erlebt > es nicht mehr. Ach darum geht es dir: könnte ja sein, dass dann jemand einfach so ein kleines Progrämmchen schreiben könnte, ohne C-Guru zu sein. Das wäre ja in der Tat schlimm...
Jan Hansen schrieb: > Axel Schwenke schrieb: >> Und wenn man erst mal so weit ist, daß man den Zugriff auf >> z.B. den ADC oder PWM zu einer benutzbaren API abstrahiert hat, dann >> kann man den Rest des Programms auch gleich in C schreiben. > > Das wäre natürlich nicht gerade sinnvoll. Würde wohl auch niemand so > machen. Die Alternative wäre ein Framework zu verwenden, das jemand anderes bereits geschrieben hat. Gibts schon. Heißt Arduino. BASIC-Stamp. Wilke-Tiger. Ist dann aber immer auch auf eher wenige Hardware-Plattformen beschränkt bzw. sogar fest an eine proprietäre Plattform geknüpft. Ist am Ende so ähnlich wie "Kochen lernen" vs. "zu McDoof gehen". Wer nix anderes kennt, findet Pommes und Burger womöglich sogar lecker. XL
Jan Hansen schrieb: > Ach darum geht es dir: könnte ja sein, dass dann jemand einfach so ein > kleines Progrämmchen schreiben könnte, ohne C-Guru zu sein. Das wäre ja > in der Tat schlimm... Ne, anders rum wird ein Schuh draus. Wenn die, die mit solchen Hilfsmittel ein kleines Progrämmchen schreiben auch ihre schöpferische Höhe und die dazu nötigen Kenntnisse real einschätzen könnten, wäre die Welt in Ordnung. Leider kommt aus dieser Richtung aber häufig eine maßlose Selbstüberschätzung. Es gibt ja den Spruch aus der Wissenschaft: "Je weiter wir in die Materie eindringen, desto mehr wissen wir, daß wir nichts wissen". JavaScript auf dem Controller generiert garantiert die komplette Negierung dieses Spruchs. Noch was. C-Guru muss man nicht sein um Controller zu programmieren. Nach einem 2 wöchigen Grundkurs hat man in C alles gelernt was für den Einstieg nötig ist. Was viel länger dauert ist einen Controller und die Art und Weise wie man damit umgeht zu verstehen. Dann muss man auch noch die Hardware verstehen die damit gehen soll. Bascom z.B lebt doch nicht von der Sprache. Es lebt davon dass 80% der Resourcen des MC als vorgekaute Libs zur einfachen Verfügung stehen. Das gibt's für C sicher auch. Nur nicht so DAU-komform, abgesehen von Arduino. Wer das machen will soll's machen. Einen Tiefgang kriegt das aber so nie.
Jan Hansen schrieb: > Antwort: Weil sie können! Jeder der ein gutes Framework entwickeln kann, > kann auch ohne dieses Framework sehr gut programmieren. Trotzdem gibt es > viele Entwickler, die das einfach aus Interesse machen. Nicht nur für > sich selbst, sondern eben auch für andere die nicht so geübt und > erfahren sind. Hier möchte ich auch noch ein paar Worte dazu sagen. Die Aussage stimmt zwar. Es ist aber bei sehr vielen Projekten so, daß das Interesse an einer Sache aufhört wenn der interessante Teil vorbei ist. Sprich, bis das Framework erst mal läuft ist es eine anspruchsvolle Aufgabe. Während dieser Zeit haben viele Entwickler auch noch den nötigen Antrieb. Nicht weil sie den weniger geübten was Guets tun wollen. Das ist ein Nebeneffekt. Spätestens wenn der 92te Controller angepasst werden soll ist es aber keine Herausforderung mehr. Dann ist es lästige Routine. So was macht man nicht gern. Da gibt es diesen Kick nicht mehr etwas neues gemacht zu haben. So ist jedenfalls der Zustand vieler OpenSource-Projekte. Nicht aller, aber vieler.
Tja, es ist wie mit dem Tauben füttern im Park. Je mehr man sich müht, es den nachfolgenden Generationen leichter zu machen, als man es selbst hatte, desto oberflächlicher und dümmer und fauler werden selbige, glauben aber, im Vergleich zu ihren Vorläufern wahre Giganten zu sein. Leute, DAS ist die Zukunft. Halleluja! W.S.
ImGalopp schrieb: > Jasch schrieb: >> frag einen der Javascript-Jockeys ob sie überhaupt wissen >> dass es === und !== gibt und was die im Gegensatz zu == und != tun, und >> warum == und != die böse Variante sind. > > > -> Zwei Zeichenketten sind genau gleich, wenn sie die gleiche Abfolge > von Zeichen, die gleiche Länge und gleichen Zeichen in entsprechenden > Positionen haben. > > -> Zwei Zahlen sind genau gleich, wenn sie numerisch gleich (die gleiche > Anzahl Wert) sind. > > -> Positive und negative Nullen sind einander gleich. > > -> Zwei boolesche Operanden sind genau gleich, wenn beide wahr sind oder > beide falsch sind. > > -> Zwei Objekte sind gleich, wenn sie strikt auf das gleiche Objekt > verweisen. > > -> Null und undefined Typen sind == (aber nicht ===). [D.h. Null == > Undefined (aber nicht Null === Undefined)] Hmm, ganz so einfach scheint es nicht zu sein, bloss Vergleiche zwischen praktisch gleichen Type aufzulisten ist auch etwas zu einfach, speziell gegeben den prinzipbedingten Mangel an statischer Typprüfung in JS... <Zitat> '' == '0' // false 0 == '' // true 0 == '0' // true false == 'false' // false false == '0' // true false == undefined // false false == null // false null == undefined // true ' \t\r\n ' == 0 // true </Zitat> Wie man sieht ist der Operator == nicht richtig transitiv, d.h. z.B ist false ungleich undefined, false ist auch ungleich null aber - Überraschung! - undefined ist gleich null. Sorry, ich nenne sowas eine inakzeptable Bastelsprache. Gegeben den Hintergrund von JS - entwickelt als etwas um in einem Browser minimale Interaktivität, vulgo meist sinnloses Herumgezappel, zu ermöglichen - wen überraschts? ;-)
Jan Hansen schrieb: > Jasch schrieb: >> Und ignoriert dabei ganz einfach die Tatsache dass die unterliegende >> JS-Runtime ganz sicher in C geschrieben ist, ebenso wie das evtl. >> vorhandene OS usw. > > Ja und? Ist doch in diesem Zusammenhang vollkommen egal. Ich würde sagen jein, aber na gut. >> Ach ja, zu Javascript: es gibt ein Buch, "JavaScript: The Good Parts". >> Wer JS noch benutzen will nachdem er das gelesen hat ist offensichtlich >> durchgeknallt und sollte verurteilt werden mindestens 10 Meter Abstand >> von allem mit einer CPU, besser noch allem mit digitaler Logik, zu >> halten. > > Blödsinn. Ich dachte du kennst C. Etwas. > Da gibt es doch noch viel mehr solcher Stolperfallen. Das würde ich vehement bestreiten, dazu ist C eine viel zu kleine Sprache. Das ist ja genau der Witz: C ist klein genug dass man die Stolperfallen relativ schnell verinnerlichen kann. C++ z.B. ist nicht so, und ich behaupte JS auch nicht. C-Bibliotheken sind wieder ein anderes Thema. > Nur, dass JS mehr vergibt Vergibt??? Ich rede von korrekter Software, nicht von SW die scheinbar tut was sie soll bis sie dann bei der kleinsten Provokation spektakulär in den Selbstzerlegungsmodus wechselt. > und es daher wohl mehr Amateurprogrammierer als bei C gibt. Ich möchte bitte keine Amateurprogrammierer an irgendwelchen embedded Systemen herumbasteln haben. Weisst schon, der ganze Computerkram in modernen Autos, mein Herzschrittmacher wenn es mal soweit ist usw. usf. Danke für Dein Verständnis. ;-) > Aber wenn man die paar JS-Fallstricke (z.B. ===) einmal kennt - und > so schwer ist das nicht - dann ist JS eine durchaus interessante Sprache. Streite ich ja nicht ab. JS ist interessant genug dass ich keinem JS-Programmierer über den Weg trauen würde der nicht auch ein gutes Wissen über Lisp hat... (Das meine ich ernst)
Tim . schrieb: > Javascript für Microcontroller. Was haltet Ihr davon? Wenn es so funktioniert wie bei TESSEL spezifiziert (bzw. versprochen) ist es wirklich interessant, sich das mal anzusehen. Zumal es ja freisteht kritische Funktionen immer noch in C zu implementieren. Kein Name schrieb: > Wer schreibt ein ARM Programm noch in Assembler? Das Programm nicht, und seit Cortex auch nicht mehr die Interrupt-Handler. Aber Software-Interrupt-Handler oder HardFault/BusFault schon immer noch. Wobei ARM-Assembler immer noch am einfachsten ist, ist ja ein 6502 Derivat (C64) und einiges älter als AVR, PIC, MIPS ...
Lothar schrieb: > ardFault/BusFault schon immer noch. Wobei ARM-Assembler immer noch am > einfachsten ist, ist ja ein 6502 Derivat (C64) und einiges älter als > AVR, PIC, MIPS ... Dss ist so aber nicht ganz korrekt. ARM hat mit 6502 nichts zu tun. Dafür aber mit MIPS. Hast Du Dir die von Dir genannten Prozessoeren schon einmal angeschaut?
Ich finde die Idee cool, da ich auch selber meine Controller gerne etwas abstrakter programmiere (in meinem Fall C#). Es schadet doch nix, die Vielfalt der Möglichkeiten zur µC-Entwicklung beliebig weit auszubauen. Wer will, darf ja gerne weiterhin zum Assembler greifen ;-)
Der eventbasierte Ansatz von JavaScript ist jedenfalls ein Fortschritt gegenüber dem prozeduralen, mit Delays und GOTOs gespickten BASIC-Code den Anfänger sonst produzieren. Wenn jemand damit seine Basteleien automatisieren kann und Spaß dabei hat, warum nicht. Die eingefleischten C- und Assembler-Programmierer hier müssen sich deswegen noch keine Sorgen um ihre Aufträge machen.
ShnikShnak schrieb im Beitrag #3287147: >> Ich finde die Idee cool, da ich auch selber meine Controller gerne etwas >> abstrakter programmiere (in meinem Fall C#). Es wurden diverse Betriebssysteme erfunden um die gewünschte Abstraktion zu erreichen. d.h. egal was für eine Hochsprache verwendet wird, der Zugriff auf die Hardware erfolgt über einheitliche Schnittstellen die die reale Hardware dahinter verstecken. Das ist so voll in Ordnung. Wenn du das willst, dann nimm einen Raspberry oder Beagle und Linux als Unterbau. Wenn jetzt wieder 1000ende Pseudobetriebssysteme auftauchen die einen winzigen Teil Hardware hinter den Libs verstecken, kommt am Ende nur ein Flickwerk raus. SchnickSchnak halt und das passte so schön zu deinem Nick. In meinen Augen geht es hier nur ganz oder garnicht. Entweder ein Betriebssystem oder der nackte Controller und eine Sprache die dem auch gewachsen ist, sprich C/C++ bzw. Assembler. Die gelöschten Beiträge enthielten max. etwas Satiere aber keine Beleidigungen in irgend einer Art und Weise. Was zu derer Löschung führte bleibt ist mir Schleierhaft. >Der eventbasierte Ansatz von JavaScript ist jedenfalls ein Fortschritt >gegenüber dem prozeduralen, mit Wartebefehlen gespickten BASIC-Code den >Anfänger sonst produzieren. Den eventbasierten Ansatz hat nicht JavaScript sondern node.js. Kaum ein Stück Software wurde in letzter Zeit so kontrovers diskutiert. Bergrenzung auf einen Thread und alles ausschließlich über Events. Den Anfänger möchte ich sehen der da ab einer bestimmten Größe noch durchblickt. Wenn das der Ansatz sein soll fehlerfreie oder fehlerarme Programme zu schreiben, dann prost Malzeit.
old man schrieb: > Wenn jetzt wieder 1000ende Pseudobetriebssysteme auftauchen die einen > winzigen Teil Hardware hinter den Libs verstecken, kommt am Ende nur ein > Flickwerk raus. SchnickSchnak halt und das passte so schön zu deinem > Nick. Ich kann dir da nicht so ganz folgen. Was hat das ganze jetzt mit Betriebssystemen zu tun? Und warum kommt am Ende Flickwerk und SchnickSchnack raus? Eigentlich ist die Sache doch ganz einfach: Du hast eine Aufgabe, die du Lösen möchtest. Dann wählst du die Hard- und Software, mit der du das Problem am effizientesten lösen kannst. Damit setzt du deine Lösung dann um und erfreust dich des Ergebnisses. Was nun konkret die effizientesten Hilfsmittel sind hängt stark vom Problem, den Randbedingungen und den indviduellen Kenntnissen des Entwicklers ab. JavaScript, C# oder Ähnliches können dabei durchaus optimal geeignet sein.
Vorerst: Ihr dürft mich als begeisterten ASM-Programmierer abstempeln! Ich habe es noch nicht mal geschafft in die "Hochsprache C" aufzusteigen, ASM ist mir viel lieber, zumindest auf AVRs. Als ich angefangen habe mit mit µC zu beschäftigen hat, wollte ich wissen wie sie im Detail funktionieren. Deshalb hab ich ASM gelernt. Wer hingegen mit einer Hochsprache wie Javascript einsteigt, dem Fehlt viel Wissen, sei es was Interrupts sind, wie sie funktionieren, was bei Funktionsaufrufen passiert, was passiert wenn der Stack in den schon definierten RAM hineinläuft, etc. Ich denke wenn man Javascript auf Mikrocontrollern ernsthaft lernt und sich länger damit beschäftigen will, kommt einem irgendwann das Problem das man zwar viele schöne Blinkprogramme schreiben kann, aber wenn es um Zeit und Speicherkritische Probleme gilt (extrem kurze Interrupts -> "wieso darf ich da keine 32bit Multiplikationen machen?!?" :P ), hat man nichts mehr in der Hand. Dann hat man drei Möglichkeiten: größeren und schnelleren Controller (meist auch teurer...); man beschäftigt sich mit einer fähigeren Sprache (ASM,C,?) oder man lässt es einfach ganz bleiben! Ich hatte am anfang selbst überlegt ob ich C oder ASM lernen soll, da ich aber bei C die ersten Probleme hatte, weil ich nicht wusste wie ein Interrupt funktionieren kann oder was passiert wenn das Programm die main Methode beendet, es aber unbedingt wissen wollte, hab ich mich entschieden auf ASM anzufangen. Ich stelle es also deutlich in Frage ob es einfacher bzw. sinnvoller ist mit Javascript zu beginnen, wenn man mehr damit machen will! Mfg julian
Julian R. schrieb: > Ich stelle es also deutlich in Frage ob es einfacher bzw. sinnvoller ist > mit Javascript zu beginnen, wenn man mehr damit machen will! Definiere "mehr" ;-) Man kann den Spieß ja auch umdrehen: mein letztes Projekt war z.B. das Auslesen von verschiedenen Sensordaten und die Bereitstellung der Daten über einen auf dem Controller befindlichen Webserver. Letzterer sollte per DDNS erreichbar sein, ein modernes AJAX Interface bieten und (für verschiedene Sicherheitskritische Funktionen) einen SSL verschlüsselten Zugang haben. Da war ich doch ganz froh das Ganze nicht in Assembler programmieren zu müssen, sondern eine Hochsprache verwenden zu können ;-)
ShnicShnac schrieb: > Julian R. schrieb: >> Ich stelle es also deutlich in Frage ob es einfacher bzw. sinnvoller ist >> mit Javascript zu beginnen, wenn man mehr damit machen will! > > Definiere "mehr" ;-) Für mich heist das, dass der Controller gut ausgelastet ist, weil ein anspruchsvolles Programm darauf läuft. In meinen Fällen waren das zum Beispiel ein Frequenzzähler in Echtzeitmessung für einen Funtionsgenerator, oder ein Geiger-Müller-Zähler, bei dem der Controller die Impulse, die bei hoher Radioaktivität durchaus mit mehreren kHz auftreten! verarbeiten muss. Einfache AVR-Controller sind für solche Zwecke gut geeignet, da bedarf nicht jeweils einem komplettem Raspberry pi ;) oder einem STM32 etc. ShnicShnac schrieb: > Da war ich doch ganz froh das Ganze nicht in Assembler programmieren zu > müssen, sondern eine Hochsprache verwenden zu können ;-) Das kann ich durchaus verstehen! Deshalb sind ja auch Hochsprachen entwickelt worden. Die Sache ist nur die, dass zwar ein Webserver auf einem ATmega durchaus zum laufen zu bringen ist mit ASM, aber das, wie du schon richtig sagst nicht mehr sinvoll/zu zeitraubend ist. Dann muss man einen größeren Conroller mit einer geeigneten Hochsprache verwenden. Ob dies für den Einstieg jedoch sinnvoll ist muss jeder nach seinen Zielen ausrichten. Für mich war es durchaus sinnvoll ASM zu lernen (demnächst folgt C!) Ein anderer will nur schnell ein Projekt ohne große Anforderungen hinklatschen, dann sei es ihm auch gegönnt Javascript zu verwenden. Aber dann nicht weinen wenn ein Stackoverflow auftritt und das erst während der Laufzeit. Dann habt ihr nämlich keine Erklärung für das Problem und es bleibt unlösbar!
Julian R. schrieb: > Aber dann nicht weinen wenn ein Stackoverflow auftritt und das erst > während der Laufzeit. Dann habt ihr nämlich keine Erklärung für das > Problem und es bleibt unlösbar! Ein Stack-Overflow außerhalb der Laufzeit wäre auch irgendwie seltsam ;-) Und ich glaube nicht dass man Assembler beherrschen muss um einen Stack-Overflow zu verstehen und zu beheben.
Tim . schrieb: > ARM hat mit 6502 nichts zu tun. Vielleicht mal den Befehlssatz verglichen? Interrupt-Handling? Der ARM1 wurde übrigens 1983 virtuell entwickelt und als Simulation auf dem 6502 getestet, bevor der erste Testchip gefertigt wurde, der dann sofort funktionierte. > Dafür aber mit MIPS. MIPS kam erst 1985 und nur weil beides RISC heisst bedeutet das nicht, dass Programmiermodel und Befehlssatz viele Gemeinsamkeiten haben: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0235c/index.html
ShnicShnac schrieb: > Julian R. schrieb: >> Aber dann nicht weinen wenn ein Stackoverflow auftritt und das erst >> während der Laufzeit. Dann habt ihr nämlich keine Erklärung für das >> Problem und es bleibt unlösbar! > > Ein Stack-Overflow außerhalb der Laufzeit wäre auch irgendwie seltsam > ;-) > Und ich glaube nicht dass man Assembler beherrschen muss um einen > Stack-Overflow zu verstehen und zu beheben. Ich wollte damit betonen, dass das Problem erst wärend der Laufzeit auftritt und evtl nicht vom Compiler abgefangen wird. Vllt n bischen doof formuliert... Nunja eigenlich schon, denn du musst wissen, dass es einen Stack gibt, was darauf abgelegt wird, dass er zB. bei AVRs in den RAM Bereich laufen kann wo deine Daten liegen und wie du das verhindern oder bemerken kannst! Dazu solltest du verstehen wie rcall/ret funktioniert und das ist meines Wissens ASM. Hinzukommt das man wissen muss welche Speicher ein uC hat, aber das sollte vorhandene Grundlagen sein. Julian
Julian R. schrieb: > Nunja eigenlich schon, denn du musst wissen, dass es einen Stack gibt, Was ein Stack ist, wie Funktionsaufrufe und zurückkehren funktionieren, wie der Stack überlaufen kann, findet sich wohl in jedem besseren C-Buch. Dazu muss man definitiv kein ASM zu können.
Kindergärtner schrieb: > Was ein Stack ist, wie Funktionsaufrufe und zurückkehren funktionieren, > wie der Stack überlaufen kann, findet sich wohl in jedem besseren > C-Buch. Dazu muss man definitiv kein ASM zu können. Das schon, und es ist ohnehin davon auszugehen, dass die JavaScript-Threads, um die es hier am Anfang mal ging, korrekt implementiert sind. Wenn aber in C der Stack überläuft, gibt es auf dem ARM einen MemoryFault, und der zugehörige Handler muss immer noch in Assembler gemacht werden. Der kann dann Platz schaffen, neu starten etc ...
Hier gibt es einen Kickstarter für eine weitere Implementierung von Javascript für Microcontroller. http://www.kickstarter.com/projects/48651611/espruino-javascript-for-things?ref=category Es wird kommen.
Gerade registriert will ich mich auch mal an der Diskussion beteiligen, vor allem weil es einigen Usern hier vielleicht einfach an Ideen fehlt, wo sich so etwas sinnvoll einsetzen lässt und auch Javascript selbst vielleicht sogar besser auf manche Anforderungen passt als C/C#/... Als Web Entwickler ohne echten µc Hintergrund aber mit großer Begeisterung für Heimautomation finde ich den Tessel persönlich eine geniale Idee und ein nützliches Werkzeug, das sich deutlich besser in mein bestehendes System integrieren lässt als das, was bis jetzt verbaut ist. Natürlich wird kein Webentwickler einen Herzschrittmacher bauen und auch sonst nichts vergleichbar sicherheitsrelevantes mit so hardwarefernen Sprachen konstruieren. Und hier wir wohl auch sicher keiner irgendwem Konkurrenz machen. Aber im Webentwicklungsbereich sind a) große Entwicklerressourcen b) Massen an für den µc-Bereich bislang ungenutzten Bibliotheken c) großer Bedarf an Zugriff/Steuerung von Hardware vorhanden. Ich als Webentwickler steuere bislang Recheneinheiten, Datenbanken, Interfaces, ... aber keine Motoren, Relais oder der gleichen. Natürlich kann ich das gleiche lernen wie vermutlich alle anderen hier auch, aber um mir die Ideologie und Architektur von Microcontrollern auf einem Niveau anzueignen, wie ich es von Web Anwendungen gewohnt bin, bräuchte ich sicherlich mindestens ~6 intensive Monate (aus dem Bauch raus). Das will sich kein Hobbybastler leisten, wenn er weiß, dass es nicht sein muss. Mit Tessel schreibe ich in 8h eine Zimmerbeleuchtung (Tessel -> JS) gesteuert über ein Web-Interface (sowieso HTML/CSS/JS) plus Android und iPhone App (Phonegap -> HTML/CSS/JS) mit Anbindung an einen Webdienst wie IFTTT (JS), wo ich dann von Hand einstellen kann, dass die Lampe ausgehen soll wenn mir meine Mom eine Email schreibt in der "gute Nacht" enthalten ist. Wild zusammengesponnen, aber sollte doch verdeutlichen warum das für einen Menschen mit meinem Background interessanter ist als jeder andere µc, oder? Allein die Ideen die mir beim schreiben dieses Posts einfallen: - Wer von euch würde sich die Mühe machen, seine µc so zu programmieren, dass sie einmal täglich von einem Github Repository den aktuellen Quellcode auschecken? In node.js keine Stunde Arbeit. - Webserver mit UI direkt auf dem µc, bedienbar per Smartphone, PC, Tablet..? In node fast selbstverständlich -TLDR- Im Großen und ganzen würde ich mich drauf freuen. Ich glaube eher dass es eine Bereicherung für beide Welten ist, wenn die grenzen zwischen zwei Entwicklercommunities langsam verschwimmen, die bislang nichts miteinander zu tun hatten. Da gibt's sicher einiges voneinander zu lernen. Und ja, es ist berechtigt sich hier und da über JS lustig zu machen, aber es hat die Web Welt aus gutem Grund für sich erobert.
Julian R. schrieb: > Das kann ich durchaus verstehen! Deshalb sind ja auch Hochsprachen > entwickelt worden. Die Sache ist nur die, dass zwar ein Webserver auf > einem ATmega durchaus zum laufen zu bringen ist mit ASM, aber das, wie > du schon richtig sagst nicht mehr sinvoll/zu zeitraubend ist. > Dann muss man einen größeren Conroller mit einer geeigneten Hochsprache > verwenden. Es ist doch nicht die Frage der Programmiersprache. Tcp/Ip-Stack mit SSL ist z.b. eine Sache, die kann und will nicht jeder selbst programmieren. Dafür gibt's Libs. Ganze gefühlte 5 verschiedene auf der Welt. Das dumme ist nur, dass diese Libs ausschließlich für C existieren. Man kann nun zwar Bindings für andere Programmiersprachen dafür schreiben, das tun sich aber auch nur wenige an. Das ist in der Regel viel Arbeit für nichts. Was die Leute die nach JS oder ähnlichen schreien wirklich wollen, ist doch ein HAL oder ein Betriebssystem was die Hardware versteckt. Ein schönes einheitliches für alle möglichen Controller. Gibts schon. Heißt Linux z.B. Aber ach, das ist denen die hier nach DAU-Sprachen schreien auch wieder zu komplex... Ansätze wie eMbed sind von der API für den Anwender schon gar nicht so schlecht. Da existieren auch HALs für Controller von NXP und Freescale. Aber man muss dabei auch sehen, die embed-Api ist sehr einfach zu lernen und gut Dokumentiert, aber auch sehr eingeschränkt auf Standardaufgaben. Sobald eine kleine Besonderheit hinzukommt ist Schluss und es geht wieder an die Register der Controller. Das ist jetzt zwar C++, diese API wäre auch gut in JS zu portieren. Kopf hoch, das wird schon. Ungefähr zu dem Zeitpunk an den Hurd fertig ist....
Aimo Künkel schrieb: > Mit Tessel schreibe ich in 8h eine Zimmerbeleuchtung (Tessel -> JS) > gesteuert über ein Web-Interface (sowieso HTML/CSS/JS) plus Android und > iPhone App (Phonegap -> HTML/CSS/JS) mit Anbindung an einen Webdienst > wie IFTTT (JS), wo ich dann von Hand einstellen kann, dass die Lampe > ausgehen soll wenn mir meine Mom eine Email schreibt in der "gute Nacht" > enthalten ist. Das hast du gut erkannt. Nur führst die Diskussion völlig falsch. Das was du dir wünscht ist eine Hochsprache die auf einer Schicht aufsetzt, die da drunter liegt und das macht um das es hier geht. Im PC-Bereich würde das Anwendungsentwicklung heißen. Wenn wir hier von Kontrollern sprechen ist aber das gemeint was sonst das Betriebssystem ist. Das sind zwei verschiedene Welten. Und das ist auch so völlig in Ordnung. Eine SPS ist auch nur ein Controller für den findige Entwickler ein Betriebssystem in C/C++/Assembler geschrieben haben das die Hardware bedient und eine Hochsprache interpretiert. Die Programmierung in dieser Hochsprache ist das was du machen willst. Den Tag an dem ein Betriebssystem in JavaScript o.ä.geschreiben wird, wirst du aber nicht erleben. Es haben alle Sprachen ihre Berechtigung, nur nicht alle an der selben Stelle der Kette. Frag mal in was das Betriebssystem auf dem tessel geschrieben wurde. Dann rechnest du die Zeit dafür noch zu deinen 8h dazu und landest bei 800h oder 8000h. Und einem Haufen Bugs von denen du noch gar nichts weißt. Deswegen, beim Tessel von einem Controller zu sprechen wie es in diesem Forum verstanden wird, ist völlig abwegig. Das ist eine fertige Baugruppe für vorgefertigte Aufgaben, die allerdings so aussieht wie jedes andere kleine Controllerboard.
> Es ist doch nicht die Frage der Programmiersprache. > Was die Leute die nach JS oder ähnlichen schreien wirklich wollen, > ist doch ein HAL oder ein Betriebssystem was die Hardware versteckt. > Gibts schon. Heißt Linux z.B. Da stimme ich Dir voll zu! Wer wirklich gut programmieren kann, für den spielt die Sprache eine untergeordnete Rolle. Hauptsache man hat überhaupt eine. Ich programmiere seit vielen jahren in jeweils der Sprache, die man mir vorschreibt. Ich lerne andere Sprachen nach Bedarf. Andere Sprachen lernen ist ein Klacks im Vergleich zu den Libraries, Frameworks und Toolkits. Wenn ich darf, wähle ich zuerst das am besten geeignete Framework bzw Libraries und schaue dann, ob das in einer der mir bekannten Sprachen verfügbar ist. Falls nicht, lerne ich die halt dazu. Die Programmiersprache ist meine geringste Sorge. An C führt allerdings kein Weg vorbei, das sollte man schon drauf haben. Auch wenn man nur selten in C programmiert. Denn praktisch alle aktuellen Betriebsysteme und Programmiersprachen wurden in C geschrieben. Und wann immer eine "höhere" Programmiersprache etwas nicht kann (z.B. serielle Ports in Java), greift man auf C zurück, um die Funktion nachzurüsten.
Ich geh da anders ran. Ich suche für die Anwendung einen µC. Ich bin bisher nicht über PICs hinausgekommen, dadurch, dass sie kleine und große, schnelle µCs haben, die ich in C programmiere. Doch sollte ich irgendwann mal auf ARM umsteigen/angewiesen sein oder welchen auch immer, kann ich mir immer sicher sein, dass es einen C-Compiler gibt. Vielleicht gibt es einen Java-Compiler für PICs, oder ein Pascal, Bascom usw und auch ggf sogar kostenlos, doch bei einem anderen Controller muss man dann ggf wieder lange suchen, wenn es denn überhaupt einen Compiler gibt. Die Chip-Hersteller, bei denen ich bisher geguckt habe, ob und welchen Compiler sie mit ihrer IDE anbieten, war es bisher immer ein C/C++ Compiler, keine einzige andere Sprache. Ist doch so ähnlich wie mit Windows. Linux und Mac werden in manchen Fällen oder Bereichen genau betrachtet ein Vorteil haben, doch wenn mir dieser spezielle Fall nicht wichtig ist, was nützt mir das dann, wenn ich mir bei Windows zu 99% sicher sein kann, dass das Programm, das ich gesucht und gefunden habe, auf Windows läuft, wohin gegen ich bei den anderen weniger Auswahl bei längerer Suchzeit habe. Dennoch gibt es bereiche, wo z.B. der MAC das Gerät der Wahl ist, so ist es auch bei JS (speziell Web). Ich verstehe dieses "die und die Programmiersprache ist besser" eh nicht. Die Sprachen sind ja nicht ohne Grund so populär, dass sie ansich jeder kennt. Ich finde, es ist davon abhängig, in welchem Bereich programmiert wird. Aus meiner Sicht ist das bei µC / PC eben C/C++/C# (mit ggf WPF o.ä., .Net usw) und bei Web PHP/CGI/JS/Java-Applets. Zumindest wenn man den Hobby-/Anfänger-Bereich anguckt. Wie weit das geht, weiß ich nicht. Ich glaube nicht, dass die Software in Flugzeugen oder ISS oder so in C geschrieben wurde, da gibts ja noch andere (Ada, FORTRAN, ...). Letztendlich kann man niemanden verbieten einen Compiler für einen µC und einer anderen Sprache zu entwickeln, ebenso kann man keinem verbieten, diesen dann zu nutzen. Doch für mich macht das aus oben genanntem Grund keinen Sinn, zudem durch die große Verbreitung mehr Beispiele und Libs für C existieren und auch alles mit dem µC machen kann, was geht.
old man schrieb: > Was die Leute die nach JS oder ähnlichen schreien wirklich wollen, ist > doch ein HAL oder ein Betriebssystem was die Hardware versteckt. Ein > schönes einheitliches für alle möglichen Controller. Gibts schon. Heißt > Linux z.B. Aber ach, das ist denen die hier nach DAU-Sprachen schreien > auch wieder zu komplex... Mit dem HAL hast du völlig recht. Nichts anderes brauche ich für meine Zwecke. Aber ein Linux zu booten um eine Lampe anzumachen ist doch ein ziemlicher Overkill und sicherlich eine größere Ressourcenverschwendung als ein Tessel. old man schrieb: > Frag mal in was das Betriebssystem auf dem tessel geschrieben wurde. > Dann rechnest du die Zeit dafür noch zu deinen 8h dazu und landest bei > 800h oder 8000h. Und einem Haufen Bugs von denen du noch gar nichts > weißt. Mit dem gleichen Argument könntest du begründen warum Anwendungsentwicklung für Windows Schmu ist. Da gibts noch viel mehr Bugs und es wurde noch mehr Zeit in die Entwicklung gesteckt. Aber das schöne ist ja dass man die Arbeit nur einmal machen muss und eben nicht der, der die Anwendung schreibt sondern der, der mit dem Tessel Geld verdient. Und wenn sich dann 10.000 Entwickler jeweils 100h Einarbeitungszeit sparen geht die Rechnung auf. old man schrieb: > Deswegen, beim Tessel von einem Controller zu sprechen wie es in diesem > Forum verstanden wird, ist völlig abwegig. Das ist eine fertige > Baugruppe für vorgefertigte Aufgaben, die allerdings so aussieht wie > jedes andere kleine Controllerboard. Da versteh ich dich entweder falsch oder ich hab in diesem Forum nichts verloren. Geht's hier tatsächlich nur um die Programmierung auf µc (wo natürlich JS nix verloren hat und ich dann auch die harschen Kommentare bzgl "Tessel ist völliger Quatsch" verstehen kann) oder auch um Fragen im direkten Umfeld (wie z.B. welcher der passendste Schrittmotor für xyz wäre, wo ja dann der Controller selbst vollig egal ist)?
Aimo Künkel schrieb: > Da versteh ich dich entweder falsch oder ich hab in diesem Forum nichts > verloren. Geht's hier tatsächlich nur um die Programmierung auf µc (wo > natürlich JS nix verloren hat und ich dann auch die harschen Kommentare > bzgl "Tessel ist völliger Quatsch" verstehen kann) oder auch um Fragen > im direkten Umfeld (wie z.B. welcher der passendste Schrittmotor für xyz > wäre, wo ja dann der Controller selbst vollig egal ist)? Da hast du mich falsch verstanden. Ich habe Tessel auch nicht harsch kritisiert. Hier werden nur immer wieder Äpfel mit Birnen verglichen und dann prallen die Argumente aufeinander. Eventuell sollte man das Forum ja in die Teilen die den Controller als solches programmieren! wollen und die die einen programmierten Controller verwenden! wollen. Und wenn sie ihn nur dazu verwenden um Scripte laufen zu lassen. Du gehörst dann in den 2. Teil und ich in den ersten. Das ist ja auch nicht weiter schlimm und wird von jedem respektiert. Was ist an der Aussage mit den Bugs falsch? Arbeite ich mit dem Controller direkt, habe ich mit dessen Fehlern zu kämpfen, und keiner ist fehlerfrei. Wenn ich dann noch ein weiteres Betriebssystem drunter habe, habe ich da auch wieder Fehler drin. Damit muss/will/kann man leben oder auch nicht. Noch was, der Tessel ist mit 180 Megahertz,32 Megabyte RAM und 32 Megabyte Flasch spezifiziert. Ne Kiste Bier würde ich darauf wetten wollen, dass da ein Linux-Kernel und eventuell die V8 oder was ähnliches drauf läuft. Selbst geschrieben ist der js-Teil sicher nicht, dazu sind Mannjahre Entwicklungsarbeit nötig. Dem Js-Interpreter Funktionen und Klassen zu spendieren um die Hardware anzusprechen ist kein Hexenwerk. Wenn du von node.js sprichst und willt die ganzen Libs oder Erweiterungen davon nutzen, dann muss der Unterbau dazu passen. Das ist noch ein Argument mehr dafür, dass da ein normaler minimalistischer Linux-Kernel drunter ist. Irgendwann werden wir das noch genau erfahren...
old man schrieb: > Hier werden nur immer wieder Äpfel mit Birnen verglichen und > dann prallen die Argumente aufeinander. Eventuell sollte man das Forum > ja in die Teilen die den Controller als solches programmieren! Hmm, wenn ich's mir so recht überlege, ist der Vorschlag gar nicht so schlecht. Vielleicht könnte man ja ein Unterforum für "Embedded Plattforms" einrichten, wo dann das ganze Zeugs mit Embeddend-Betriebssystemen (Arduino, QNX, etc.) reinkommt, wo's also weniger auf den Controller selbst als - ich sag's mal so salopp - auf die "Middleware" draufankommt. Schade, daß das Zeugs wohl nicht wirklich in die zwei "PC-Foren" mitreinpasst. > wollen und die die einen programmierten Controller verwenden! DORT die grenze zu ziehen wäre noch schwiriger, das liefe praktisch auf Hardware+Assemler und Abstraktion+Software raus. > und wenn sie ihn nur dazu verwenden um Scripte laufen zu lassen. Könnte man in http://www.mikrocontroller.net/forum/website diskutieren. > Selbst geschrieben ist der js-Teil sicher nicht, dazu sind > Mannjahre Entwicklungsarbeit nötig. Dem Js-Interpreter Funktionen und > Klassen zu spendieren um die Hardware anzusprechen ist kein Hexenwerk. Wenn's sowas mal gibt, dann kann man ja nochmal über eine Trennung nachdenken. Ich sehe nir den Sinn nicht, wozu man auf einem Controller z.B. DOM brauchen würde. Wo soll das Ganze denn hinführen? In ein paar Jahren kann man vielleicht auf 32MHz/128MB RAM irgendein "Monolith-Betriebssystem" ausführen, das dann eben von mir aus einen FPGA emuliert. Nur sehe ich da eben keinen Sinn. > Wenn du von node.js sprichst und willt die ganzen Libs oder > Erweiterungen davon nutzen, dann muss der Unterbau dazu passen. Ein reiner "JS-Interpreter" auf einem Controller wäre meiner persönlichen Meinung nach jedenfalls reichlich dämlich. Spannender wär dann schon eine mini-Shell auf einem DSP: #>ls / . ./bin inputstraem outputdream #>ls /bin .sin() .cos() .fft() .rect() .transform() .you_name_it() .wave::generate.sh
Bengurion schrieb im Beitrag #3307922:
> http://www.espruino.com/Video
Beim Beaglebone black ist das auch möglich.
ja, espruino, unterstützt auch die stm boards, die man billig haben kann. ich bin bastler, der noch mit arm entwickelt, und wo nicht arm, da dann gleich vollwertiges linux. ich bin sehr gespannt was da kommen wird, in einem anderen thread hier auf µc.net hatte ich node.js erwähnt - javascript auf dem server für webseiten etc. javascript kennt man vom browser, da tut sich auch einiges - three.js zum bleistift. in verbindung mit html5 und css3 ist das mächtig. dann gibt es javascript libraries, um eine einmal geschriebene app auf allen smartphone varianten zu haben - inklusive zugriff auf die internen sensoren. und schliesslich eben javascript für kleine arm µc - espruino ist hier nur eine variante. was ganz anderes: der '===' operator - auf english wird der gerne "boilerplate" genannt, zu deutsch "herdplatte" - finde ich hervorragend. aber dennoch wird javascript für mikrocontroller das gleiche problem haben wie zum bleistift forth für atmega: ram/speicher wird schnell voll werden, von da an gibt es unvorhersehbares verhalten.
Ich glaube es wird sich noch eine ganze Menge tun und es wird sicher immer mehr in Richtung "Klicken" gehen. Da wird dann alles zusammen geklickt und nur noch wenig Code geschrieben.
Im Tessel stellen auf jeden Fall der node.js Server und npm (Node Package Manager) das Grundgerüst. Spricht in der Tat ziemlich dafür dass da ein Linux Kernel mit V8 drunter steckt, da hast du Recht. > Ich habe Tessel auch nicht harsch kritisiert Die harsche Kritik bezog sich eher auf den Mittelteil des Threads, wo scheinbar sogar was gelöscht werden musste, das hab ich aber nicht mitbekommen ;) Einen neuen Forenteil zu eröffnen für µc "Benutzer" kann ja angesichts Tessel/Espruino/... auch nicht schaden. > Ich sehe nir den Sinn nicht, wozu man auf einem Controller z.B. DOM brauchen würde. Den sehe ich auch nicht, aber ich glaube auch nicht dass der auf irgendeinem µc landen wird. Er interpretiert ja auch nur Javascript als Sprache, die wie oben erwähnt auch außerhalb von Browsern häufig verwendet wird. Was die 32MB RAM angeht: ich denke da lässt sich einiges mit anfangen, ist nur die Frage wie viel für die Anwendung am Schluss zur Verfügung steht...
Aimo Künkel schrieb: > Was die 32MB RAM angeht: ich denke da lässt sich einiges mit anfangen, > ist nur die Frage wie viel für die Anwendung am Schluss zur Verfügung > steht... Die alten WRT54 hatten noch viel weniger Ram und da lief ein Linux. Hier braucht ja nur der Kernel und die Netzwerkschicht laufen. Und die V8?. Da könnte noch gut die Hälfte von den 32Mb an Ende über sein. Das ist aber nur über den Daumen gepeilt.
Falls es noch jemanden interessiert, Crowdfunding ist gerade gestartet: http://www.dragoninnovation.com/projects/22-tessel > "Tessel’s custom runtime is optimized for low level chips. It only takes up 256k of flash and RAM, so you’re free to push the limits of Tessel’s 32MB for whatever project you dream up." Sollte also massig reichen, der Speicher. > We're currently running a custom-built, real time operating system on top of a Lua Runtime. Your JavaScript is compiled to Lua bytecode when you push your code, and that bytecode is run on the runtime. It's this runtime that allows us to have such low memory overhead. We may switch over to an implementation of Libuv or a microLinux flavor in the future, but that shouldn't change anything about the user experience with Tessel (except it will be faster!) Also noch kein Linux. Und da ohnehin kein JavasScript interpretiert wird, braucht es auch keine V8. War ich aber auch erstaunt. 100€ Fundingpreis find ich aber echt heftigst, hatte mit maximal der Hälfte gerechnet...
Wow! We've had such an amazing response to Tessel since we've launched. Thanks to you, we're >175% funded. That's over $87,500 raised in just 24 hours... and we're just getting started!
>Wenn man sowas haben wöllte, dann würde man ohnehin Lua nehmen. Was es - >nebenbei bemerkt - schon ein paar Jährchen gibt. Aber natürlich braucht >man sowas so gut wie nie. Den hardwarenahen Teil - Initialisierung, >Zugriffe auf Ports und interne Resourcen - muß man ja sowieso erst mal >in C machen, Naja, ausser man nimmt ein Board, für das es Lua und alle Treiber schon gibt: http://wiki.eluaproject.net/Boards
Gerade gesehen: http://iop.io/ Jetzt gibt es auch Javascript für AVR. Sieht eigentlich recht interessant aus. Mir ist noch nicht ganz klar, ob der Interpreter Open source ist. Leider kann ich auf der Website nichts finden.
Jan Hansen schrieb: > Stolperfallen. Nur, dass JS mehr vergibt und es daher wohl mehr > Amateurprogrammierer als bei C gibt. Aber wenn man die paar > JS-Fallstricke (z.B. ===) einmal kennt - und so schwer ist das nicht - > dann ist JS eine durchaus interessante Sprache. Nunja, blutende oder sogar eiternde Hämorrhoiden sind ja auch irgendwie durchaus interessant. Aber das heißt doch nicht, daß man sie wirklich haben will, wenn man auch was anderes haben kann, oder? Sogar garnichts ist irgendwie besser als das, genau deswegen gibt es so überaus nützliche und beliebte Browswererweiterungen wie NoScript... Und wenn du jetzt rumtönen möchtest, was JS alles ermöglicht: Aus meiner Sicht ermöglicht dieser unsägliche Dreck vor allem eins: Sämtliche bekanntgewordenen "Browser-Sicherheitslücken" der letzen SIEBEN Jahre. Ja, in aller Regel ist auch noch eine Sicherheitslücke im Browser selber, irgendeinem verbreiteten Plugin oder im OS selber nötig, damit die Seuche sich ausbreiten kann, aber ohne den Einstieg über JS stellen alle diese ausgenutzten Schwachstellen kein nennenswertes Problem dar, weil sie von Außen einfach nicht erreichbar sind ohne JS. JS ist die blanke Seuche. Weg damit. Sofort. Wenn schon Scriptsprache, dann sowas wie Perl. Hat zwar auch diese eklige C-Style-Syntax, aber ist wenigstens durchdacht.
"Wo Liebe wächst, gedeiht Leben - wo Hass aufkommt droht Untergang." - Mahatma Gandhi Mehr wüsste ich darauf nicht zu antworten. Außer vielleicht, dass die Volkshochschule Internetkurse für Einsteiger anbietet. Da lernt man auch wie man seinen Browser updatet.
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.