Compacte javascript-controller voor aansturen elektronica verschijnt in april

De Espruino Pico, een compacte microcontroller die javascript draait, heeft op Kickstarter voldoende geld opgehaald om geproduceerd te gaan worden. Volgens de makers kan de Espruino Pico gebruikt worden om allerhande elektronica aan te sturen.

De Espruino Pico, die direct in een usb-poort kan worden geprikt, is de opvolger van de Espruino, een variant die vorig jaar op Kickstarter verscheen. De mogelijkheid om de Pico-uitvoering direct in een usb-aansluiting van een pc te prikken, moet het programmeren van de microcontroller verder vergemakkelijken.

Met de Espruino Pico kan volgens de makers ook een beginnende softwareontwikkelaar snel aan de slag omdat de ARM Cortex M4-microcontroller direct via het relatief eenvoudige javascript is te programmeren. Omdat de aansturing gelijk is aan die van de oorspronkelijke Espruino is er bovendien al veel documentatie online te vinden, evenals allerhande code om eenvoudige elektronicaprojecten op te zetten. De Pico-uitvoering moet in twee versies beschikbaar komen: een uitvoering met gesoldeerde pinnetjes en een versie zonder. Ook komen er diverse kits beschikbaar om snel projecten te kunnen bouwen.

Inmiddels hebben de makers de Kickstarter-doelstelling van 15.000 pond, circa 18.777 euro, ruimschoots gehaald; de teller staat op moment van schrijven op meer dan 44.000 pond, ofwel ruim 55.000 euro. Naar verwachting zullen de eerste Espruino Pico's in april volgend jaar geleverd gaan worden.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (84)

Waarom. Waarom in hemelsnaam zou je Javascript op een Microcontroller willen. Een processor met beperkte snelheid, SRAM, RAM en zonder dynamische geheugenallocatie. Waarom.

Was Arduino niet al makkelijk genoeg als laag boven C++?

[Reactie gewijzigd door Cilph op 18 november 2014 13:24]

Programmeren in C++ kost toch nog altijd vrij veel tijd. Programmeren voor deze javascript controller moet makkelijker én sneller zijn.

Je bouwt geen enterprise systemen of webapps op een microcontroller. Dingen zijn niet veel complexer dan pinnetjes setten, interrupts afvangen, filteren en loggen. Hier is er praktisch weinig verschil tussen Javascript en C++ in makkelijkheid.

Ik ben het eens met het tweede deel van je reactie, maar niet met je eerste deel. Er zijn wel degelijk projecten denkbaar die meer nodig hebben dan alleen 'pinnetjes setten'. Je zou er bijvoorbeeld een spelcomputertje van kunnen maken?

Niet met deze hardware ben ik bang

Toegegeven, echt snel is hij niet (3.5kHz als je een pin togglet, bron: http://www.espruino.com/Performance ) maar als de Engine je hardware support hoef je toch alleen nog maar je game logic in te bouwen?

3.5kHz pin toggling is toch rampzalig als je bedenkt dat een simpele Arduino al makkelijk 2MHz haalt. Meer als je ruwe assembly zou gebruiken.

Daar kan ik het alleen maar mee eens zijn. Toch denk ik dat je nog best wat leuke dingen kunt doen met dit ding.

Ik ontvang hem -hopelijk- in April. Ben benieuwd of hij inderdaad te sloom is om er fatsoenlijkerwijs wat mee te doen.

Helemaal mee eens, een beetje overhead ten kosten van gebruikersgemak is niet zo erg, moet beetje middenweg zien te vinden. Maar M4(meestal 72Mhz of 168Mhz) zo erg toetakelen dat die nog maar 3.5Khz overhoud is echt te veel van goede.

Dit is meer gevalletje van, kosten wat het kost zullen we javascript erop draaien.

Maak gewoon wat eenvoudig te gebruiken C macro's of functies die simpel in gebruik zijn zoals Arduino dat ook heeft gedaan. Maak er simpel IDE voor en zorg voor community, dat laatste is het lastigste. C en C++ zul je ook meeste aan hebben als je later verder wilt in uC land.

[Reactie gewijzigd door mad_max234 op 18 november 2014 20:05]

VGA bitbangen kost best wel wat CPU time. Gaat met een javascript interpreter -echt- niet lukken.

Edit: onderstaand klopt niet. Er is wel een graphics library ingebouwd maar de support voor displays is met javascript gemaakt.

De engine heeft support voor bepaalde displays (nou net geen vga, maar wel bijvoorbeeld een SSD1351, full color oled display). Dat wordt niet gebitbanged maar dit zit in de engine (is met C, C++, Assembler etc. geschreven). De processor zelf zou krachtig genoeg moeten zijn om ook nog wat cpu tijd over te laten voor de engine.

Bron: http://www.espruino.com/Modules

[Reactie gewijzigd door Veda88 op 18 november 2014 14:27]

VGA signaal genereren is iets anders dan LCD controller aansturen. Eerste moet je timings regelen en wat extra werk om signaal te genereren, maar dat is ook niet zo zwaar dat M4 zover op de knieën krijgt. AVR kan dat al als je die ligt overklokt(24Mhz), wel met beperkte resolutie en kleuren. M4 is 25% krachtiger dan AVR klok voor klok en is ook nog eens heel stuk hoger geklokt, 72Mhz of 168Mhz

Zolang controller bij de LCD zit, zoals SSD1351(dat is een lcd controller en geen lcd) dan maakt niet uit hoe traag de uC is, vraag is dus hoeveel FPS je hebt met dit ding.

Als ik AVR(bijv. arduino) op 500Khz laat lopen dan kan die nog steeds SSD1351 aansturen, SPI bus zal dat 250Khz max zijn en dat vind SSD1351 prima, zal alleen erg trage FPS hebben.

Geldt voor zowat alle lcd controllers en ook voor parallelaansturing, controller regelt aansturing van lcd, enige wat jij doet is data in ram zetten van die controller en aangeven dat controller opnieuw ram moet uitlezen en weergeven, de lcd controller doet de rest.


Vraag me af, zetten ze de code nu om op de pc naar C code, of zit er in de M4 een java interpreter?

JavaScript is bij veel mensen bekend, C++ niet. Dat op zich maakt het voor een heel groot publiek opeens heel makkelijk om met dit soort dingetjes snel meuk in elkaar te flansen. Maakt het voor je thuisprojectje nou uit of je C++ of JavaScript gebruikt? Lijkt me niet.

Hier is er praktisch weinig verschil tussen Javascript en C++ in makkelijkheid.

Toch wel. In de Espruino interpreter kan je gewoon JavaScript commando's intypen en uitvoeren, variabelen lezen enzovoorts. Je zit als het ware live op de hardware. Dat maakt het ontwikkelen en debuggen van software een stuk gemakkelijker en sneller.

Dat zal toch liggen aan welke libraries beschikbaar zijn en wat je precies ermee wilt doen. Ik heb ook mijn twijfels hoeveel makkelijker javascript gaat zijn tov een Arduino, mbed of Teensy. Eén ding is zeker: Trager gaat het in ieder geval zijn.

Overigens @Cilph, er is geen reden waarom een microcontroller geen dynamische geheugenallocatie zou hebben. ARMs die ik gebruik hebben dat iig gewoon. Tegelijk is het niet iets wat je wilt gebruiken als het niet echt moet.

Eén ding is zeker: Trager gaat het in ieder geval zijn.

Maar is dat erg?
Tegenwoordig zijn zelfs kleine microcontrollertjes leuke ARM cores.
En wat ga je met dit dingetje doen? 'Druk knopje' -> 'lampje aan'.
Dan maakt het weinig uit dat dat 10 x trager is...
(En je ziet nu in de browser zelfs 3D spelletjes of een virtuele oude Mac of PC geprogrammeerd, (ja dat is met een leuke JIT javascript engine), maar had je dat een paar jaar geleden gedacht?)

Tuurlijk, maar voor 'Druk Knopje' -> 'Lampje Aan', is er ook maar enig nuttig verschil tussen C en Javascript om te kunnen zeggen dat Javascript makkelijker is?

Ja, je kunt met JavaScript ondertussen allerlei andere dingen doen.

....en met C niet?

Als je deze code voor de Arduino neemt:

http://arduino.cc/en/tutorial/blink

En je wilt ook een knopje of een sensor uitlezen, dan wordt het ineens wat lastiger.

Met JavaScript niet.

Met deze code inderdaad niet.

Als je de code anders schrijft waardoor er elke tik (of milliseconde, of wat je dan ook wil), een andere taak uitvoert, waarbij je bijhoudt wat wanneer uitgevoerd wordt, kun je vrij simpel hetzelfde bereiken.

Voor een schoolproject dit ook zo op een arduino geïmplementeerd. Motoren aansturen terwijl je seriële commando's verstuurt (over meerdere poorten), kan prima 'tegelijk'. Het is niet werkelijk tegelijk, maar wanneer goed geïmplementeerd, is het nog vele malen sneller dan deze Javascript intrepreter kan.

Zoals hier in de comment staat:
edwinjm in 'nieuws: Compacte javascript-controller voor aansturen elektronica verschijnt in april'

Scheelt het een factor 1000. Laten we zeggen de helft, wat alsnog enorm overdreven is. Dan kan je op deze manier taken 'tegelijk uitvoeren', terwijl dit effectief nog steeds 2x sneller is ook.

Dat is waarschijnlijk ook gewoon wat deze code doet, maar dan met extreem veel overhead, waardoor het dus veel langzamer is.

Ook zijn er in javascript de beruchte objecten. Alles is een object in javascript. Functies zijn objecten, properties van objecten zijn objecten. (Check maar eens in je console. Ik geloof in Chrome/webkit dat wanneer je daar een object logt, je oneindig door kan klikken op bepaalde properties). Dit moet allemaal bijgehouden worden. Daar zit volgens mij ook een deel van snelheids verlies van deze intrepeter.

Als eerste wat Cilph zegt. Maar daarnaast waarom ga je in een core M4 gebruiken voor druk lampje, lampje aan. Een kleine core M0 of een 8-bitter is wat je dan zoekt.

Het blijkt dus meer dan 1000x trager te zijn (en je mag geen commentaar in je functies zetten als je wilt dat het nog een beetje op schiet). Al die tijd kan hij niet in een slaap modus doorbrengen, en zit hij dus energie te vreten. In een slaap modus vreet hij nog steeds veel meer energie dan een kleine M0 die meer dan genoeg performance heeft voor wat er moet gebeuren.

En als ik de code voorbeelden zie, lijkt het me ook echt niet makkelijker dan bijvoorbeeld mbed gebruiken om zo eentje in C++ te programmeren.

[Reactie gewijzigd door Sissors op 18 november 2014 14:18]

Trager moeten we nog zien. Er is niet echt duidelijk hoe het er uiteindelijk op draait. Als het uiteindelijk ook geconverteerd wordt, is het even snel en het is nou niet bepaald high-end stuff wat je erop gaat doen. Als een ledje wordt aangestuurd en de delay is 5ms ipv 2ms, dan zie je dat ook niet

[Reactie gewijzigd door Martinspire op 18 november 2014 13:44]

Totdat dat LEDje heel snel moet knipperen (soft-PWM). En in C heb je het over <<<1us om een LEDje aan te zetten. Als dat ding toch niks te doen heeft, dan ja. Maar anders nee.

En laten we zeggen dat een knopje uitlezen ook 2.5x zo lang duurt (random voorbeeld), dan betekend het ook dat hij 2.5x zo lang buiten een sleep mode moet zijn, en dus zijn accu veel sneller leegtrekt. Om het nog maar niet te hebben over de veel lagere lekstromen van gemiddelde M0 tov gemiddelde M4.

Edit: Gezien bovenstaande is de factor niet 2.5 maar boven de 1000! Dat is nogal significant, zowel in wat je ermee kan, en al helemaal in verbruik.

[Reactie gewijzigd door Sissors op 18 november 2014 14:15]

Voor snel knipperende LEDjes heeft de Espruino dan ook hardware PWM in huis ;-)

En nee, voor tijd- of vermogenkritische toepassingen is hij niet gebouwd.

Vreemd dat men fietsen gelijk met vrachtwagens gaat vergelijken en het dan niets vinden :-|

Totdat je door je hardware PWM units heen bent. Of gewoon in het algemeen als je korte stukjes code vaak moet uitvoeren.

En het probleem is niet dat men fietsen vergelijkt met vrachtwagens, maar dat dit een fiets is gemaakt op het chassis van een vrachtwagen met de performance van lopen en het verbruik van een tank. Of welke andere analogie je maar wilt trekken. Fietsen staat tot vrachtwagens als een microcontroller staat tot een PC. Beide hebben een prima bestaansreden. Echter wat de bestaansreden is van de performance van een microcontroller met een factor 1000 verlagen en daarbij ook nog eens je energieverbruik met een veelvoud te laten toenemen ontgaat me.

De Espruino heeft 26 PWM pins, ik kan niet zo snel een project bedenken waar dat te weinig is

Bron: http://www.espruino.com/EspruinoBoard

Je kunt al aardige dingen met de Espruino doen met minder dan 100uA.

Bron: http://www.espruino.com/Small+Solar+Powered

En nee, je moet geen snelheidsmonster verwachten, maar voor hoeveel (Arduino) hobbyprojecten zou de Espruino echt te langzaam zijn?

Punt is voor een microcontroller zit er wel een snelheidsmonster op. Het is niet de allersnelste, maar zit wel aan de bovenkant. Qua rekenkracht zit een Espruino echter compleet aan de onderkant, ver onder de langzaamste 8-bitters.

En zo'n overkill aan rekenkracht voor wat je ervoor terugkrijgt zal je altijd op een manier benadelen. Bijvoorbeeld in een veel kortere accuduur. Die 100uA is zijn accuduur in deepsleep. Wat 1 dus veel hoger is dan van een M0/8-bitter, en twee hij zal veel meer tijd buiten deepsleep moeten doorbrengen omdat hij zo traag is. Als hij wat moet doen wanneer je een knopje indruk is dat geen enkel probleem (ervan uitgaande dat je een interrupt daarvoor kan gebruiken in die omgeving). Moet je echter kijken of iemand voor langs loopt met een lichtsensor die je 10x per seconde wil uitlezen dan wordt dat een ander verhaal. Ofi ets van keypad uitlezen kost hem relatief een hele hoop tijd.

Overigens vraag me af waarom hij enkel in veelvouden van hele secondes in deepsleep kan doorbrengen, er is geen enkele hardware reden voor bij zijn microcontroller, milli-seconde resolutie moet prima kunnen.

Praktisch ding wat nogal problematisch voor hem wordt: Elk one-wire device proberen te bitbangen.

[Reactie gewijzigd door Sissors op 18 november 2014 16:07]

Die 100uA is zijn accuduur in deepsleep.

Als je de voltage regulator vervangt door een diode is 100uA deepsleep en code uitvoeren samen

Voor knoppen uitlezen gebruik je gewoon watches. Ook analoge watches zijn mogelijk: http://www.espruino.com/LM393

Nogmaals, de Espruino is inderdaad geen snelheidsmonster, maar voor de meeste projecten / gebruikers snel genoeg.

Dat stuk over een diode gebruiken als vervanging voor een voltage regulator las ik ook met stijgende verbazing. Vooral dat ze zoiets aanbevelen.

Ideaal gezien heeft een diode altijd 0.7V spanningsval. Maar ideale diodes bestaan niet, en in de praktijk bij de kleine stroompjes waar het hier over gaat is de spannignsval heel veel kleiner. Meer dan 0.3V zou ik niet vanuit gaan! Oftewel ja het gaat goed, als je een li-ion niet compleet oplaadt, of accepteerd dat je microcontroller buiten spec werkt.

Hoeveel het totaal is hangt natuurlijk af van hoeveel code hij moet uitvoeren en hoe vaak. Als hij vaak eventjes wakker moet worden kom je uit op een ruwweg duizend keer hoger stroomverbruik, simpelweg omdat hij 1000x trager is en dus 1000x langer wakker is.

Omdat je lekker async kan programmeren zonder gedoe lijkt me..

Javascript is re-entrant, niet async!

Nee, JavaScript is niet re-entrant!

JavaScript is event driven. En wel degelijk asynchroon, maar dat hangt misschien ook van je definitie af.

Zolang je met JavaScript gemakkelijk een bestand kan inladen, een muisklik afvangen en een animatie afspelen, allemaal tegelijk, is dat toch echt asynchroon volgens de meest gangbare definities.

Het is niet asynchroon. Open je Javascript Console maar eens en typ "while(true){}" in. Niks werkt meer, geen animaties, geen bestanden (in)laden.

Event-driven is het wel, maar alles werkt op één thread en de interpreter zal geen dingen onderbreken om wat anders te gaan doen.

Ontopic:
Javascript is hier een waardeloze taal voor. JS zie je in steeds meer non-clientside scripting toepassingen en daar ben ik niet zo blij mee, en eigenlijk om maar één reden: Javascript heeft geen integers. Alles is een float, met de leuke obscure problemen die je daarmee kunt krijgen. Javascript is erg handig om bijvoorbeeld click listeners mee te registreren of om credentials te valideren, maar voor "business logic" vind ik het erg ongeschikt.
Grappige sidenote: Ze lijken hiervan op de hoogte te zijn want de ARM Cortex M4 CPU heeft niet per-se een FPU, maar die op de Pico wel.

Het is niet asynchroon. Open je Javascript Console maar eens en typ "while(true){}" in.

Wat heb je dan aangetoond denk je? Dat javascript in z'n algemeenheid niet asynchroon is, of dat de javascript-implementatie in de browser dat niet is?

Is dat je enige reden?

Zolang je binnen JavaScript met integers werkt, is er geen verschil met een apart interger-type.

Toon mij maar eens waar het fout gaat met integers in JavaScript.

Ben je bekend met hoe floats werken?
Met floats heb je niet zozeer een minimum en een maximum (die zijn er natuurlijk wel en die zijn bij floats overdreven hoog) maar een precisie. Bij kleine getallen is deze heel hoog - met floats kun je 0.000051 en 0.000052 onderscheiden. Maar bij grote getallen wordt deze preciesie snel minder. Een voorbeeld: http://i.imgur.com/zt9rSmv.png
Dat is btw gewoon de Chrome Javascript console.

Die "max safe integer" had een 53 bit integer kunnen zijn, terwijl elke float 64 bits in het geheugen inneemt. 64 bits is voor veel dingen overkill, en hier juist weer te weinig (omdat het floats zijn). Helemaal rekenen met geld en floats is niet aan te raden.
Zoals ik al zei, voor taken zoals knopjes klikbaar maken en menu's animeren is Javascript een prima taal, maar daarbuiten is het gewoon net te beperkt. Cryptografie met Javascript is al helemaal geen feest omdat je daar veel bitwise operaties op integers moet uitvoeren. En dan natuurlijk de problemen die anderen al aanstipten: geen multithreading.

Maar bij grote getallen wordt deze preciesie snel minder. Een voorbeeld: http://i.imgur.com/zt9rSmv.png

Je precisie wordt dus niet minder. Je hebt nog steeds dezelfde hoeveelheid significante cijfers (bits), alleen omdat de ordegrootte groter is, is de waarde van het minst significante cijfer ook groter.

Maar bottom line past elke int tot 2⁵³ in een 64-bits float, en kun je floats derhalve ook gewoon gebruiken om integer logica mee te doen.

Helemaal rekenen met geld en floats is niet aan te raden.

Klopt, daarvoor gebruik je liefst fixed point getallen in basis-10. Sommige talen hebben een decimal datatype (er is overigens geen reden dat je zoiets niet kunt hebben in een javascript implementatie), in een andere taal zul je het misschien handmatig doen door ints te gebruiken, bijvoorbeeld door gewoon het aantal centen op te slaan. En dus kan het ook met floats, alleen moet je de komma niet als zodanig gebruiken, en dezelfde representatie in centen nemen.

Ook bitwise operators werken prima, zolang je binnen de 53 bits blijft. Prima dus voor 8, 16 en 32-bit bitwise operaties

En dan natuurlijk de problemen die anderen al aanstipten: geen multithreading

Nogmaals, dat is niet inherent aan javascript.

Haha, omdat een int 64 in plaats van 53 bits is, is JavaScript niet geschikt om businessapplicaties mee te maken.

En zeker ook nooit van asm.js gehoord?

Slaap lekker verder, terwijl JavaScript steeds belangrijker wordt.

Bitwise operaties. Daar doe je er doorgaans veel van.

Geen probleem in JavaScript.

Jazeker wel. Je moet conversies doen vanuit floating point. Heb je enig idee hoeveel CPU cycles dat kost zelfs op een x86?

Maar wie gaat er dan ook number crunchen met JavaScript? Daar zijn betere talen voor.

Het number type in JavaScript is een van de vele abstracties die worden gebruikt.

Maar stel, het converteren van IEEE 754 naar een 32 bit int kost 10 CPU cycles. Op een 72MHz Espruino is dat 0,14 microseconden. Als dat binnen een Espruino project 1000 keer gebeurt, is dat veel. Het kost dan 0,14 milliseconden. Oh, je moet het natuurlijk ook steeds terugconverteren naar float. 0,28 milliseconden. Ja, echt traag. </ironie>

In de embedded tak worden zulke prestaties gewoon gezien als absurd en werkelijk onnodig. Iemand leren te bitmasken op ints is veel goedkoper dan apparatuur ontwerpen en verkopen met te dure processors erin. Dat niet alleen, ook hogere accu eisen.

Want dat is wat je wellicht teweeg gaat brengen. Embedded programmeurs die niet in C kunnen werken.

[Reactie gewijzigd door Cilph op 19 november 2014 11:04]

De Espruino is bedoelt voor hobbyprojectjes. Niet voor gebruik in commerciële massaproducten. Je hoeft echt niet bang te zijn dat er straks embedded programmeurs zijn die niet in C kunnen werken

Heb je enig idee hoeveel CPU cycles dat kost zelfs op een x86?

Ja, 2. CVTTSD2SI. Of met CVTTPD2PI, kun je er twee tegelijk doen.

Als performance een issue is moet je sowieso geen javascript gebruiken. Float-to-int conversion is dan echt het minste van je problemen.

Doet boost::asio het niet op een microcontroler target dan?

Okay, Boost is nou niet echt bepaald gebruiksvriendelijk. Echter kan ik wel tig manieren bedenken om in C++ makkelijk async events te doen zonder een hele interpreter mee te slepen.

Boost niet gebruiksvriendelijk? Er is niets mis met (de meeste) boost libraries. Boost is de proeftuin voor de standaard library van C++, en de meeste boost libraries zijn dan ook van hele hoge kwaliteit die je niet bij veel andere libraries zult vinden. Voor een C++ ontwikkelaar die de standaard library geregeld gebruikt is boost simpelweg een power-pack voor de standaard library, en is boost::asio net zo gebruiksvriendelijk als NodeJs dat is voor een JavaScript ontwikkelaar of Twisted voor een Python ontwikkelaar. Alleen is espruino absoluut geen NodeJs, als dat wel zo was, dan kan ik mij nog voorstellen dat je liever Node draait dan boost::asio, maar espruino is zo bare-bones dat boost::asio je gewoon meer geeft, nog los van de performance van een interpreter.

Boost niet gebruiksvriendelijk?

Nee. En zeg ik met 10+ jaar professionele C++ ervaring. Nou wil ik overigens niet alle libraries binnen Boost over één kam scheren, maar gebruikersvriendelijkheid is niet direct een van de speerpunten van Boost - maar dat pretendeert het dan ook helemaal niet te zijn.

Boost is de proeftuin voor de standaard library van C++, en de meeste boost libraries zijn dan ook van hele hoge kwaliteit die je niet bij veel andere libraries zult vinden.

Dit verhaal heeft echter totaal niets met gebruikersvriendelijkheid te maken. Het gaat vooral om genericiteit. Je zegt het zelf al, Boost is een power-pack. Een tool voor professionals met een hoge configureerbaarheid, want dat is wat professionals eisen. Dingen die gebruikersvriendelijk zijn, zijn over het algemeen juist simpel en straight-forward. Oftewel een apparaat met zo min mogelijk knoppen en mogelijkheden, ipv zoveel mogelijk. Maar dat past niet echt in de algemene filosofie van C++.

Point in case: boost::regex, en inmiddels dus ook std::regex. Als je eenmaal doorhebt hoe het in elkaar zit is er prima mee te werken hoor, maar feit blijft dat je het juist niet meteen door hebt als je andere regex libraries gewend bent. Elke keer dat ik het nodig heb moet ik weer de documentatie induiken om uit te vogelen hoe het nou ook alweer zat met die matches en iterators. En uiteindelijk heb je een hele krachtige tool waarbij je gebruik kan maken van de standard algorithms om de boel te transformeren, maar het blijft best geavanceerd spul en zeker niet voor de meeste novices om dat effectief te gebruiken.

Misschien ken je die quote van Jamie Zawinski wel:
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
Gebruik std::regex, en je hebt drie problemen

[Reactie gewijzigd door .oisyn op 18 november 2014 23:09]

Probleem is dat C++ een oude en zo'n veel omvattende taal is en dat er in de loop der tijd een soort dialecten onder programmeurs zijn ontstaan die C++ al spelend geleerd hebben vanuit hun kennis van een andere taal.

Dit zie je ook terug in libraries.

* Het C met strings dialect: oude C programmeurs die niet al te veel
met OO of generics hebben gebruiken dit vaak. Heeft vaak ook C
type bugs.
* Het Java dialect. Heel veel 'new' overal in de code en gebruik van
diepe class hyrarchieen zoals je in Java kunt verwachten. Dit dialect
kampt vaak met memory management bugs (waardoor de Java folks
terug vluchten naar hun Java).
* Het functionele dialect. C++ templates zijn in beginsel een
functionele programmeertaal, en template meta programming is
daar een voortvloeisel van, maar ook run-time krijgt C++ met nieuwe
standaarden een meer functioneel tintje dat in dit dialect de overhand
krijgt..
* Het JavaScript dialect. Sinds een paar jaar heeft C++ lambda' s en
een generieke interface for functie achtige objecten. Dit maakt C++
toegankelijker voor JavaScript programmeurs, maar creeert daarmee
een nieuw dialect.
* Modern/Idiomatic C++: De combinatie van 'modern' C++ zoals dat
door Alexandrescu in z'n beroemde boek is geintroduceerd, en zoals
dat samen werkt en in de loop der tijd is aangevuld met een veelheid
an C++ specifieke idiomen.

Voor mensen die de laatste hebben geleerd en niet al spelend op een van de eerdere dialecten zijn uitgekomen is boost::asio bijvoorbeeld een stuk gebruiksvriendelijker dan bijvoorbeeld ACE of Poco.

Verder bevat boost ook libraries die ronduit triviaal in gebruik zijn. Ik noem bijvoorbeeld boost::lexical_cast. Het idee is wel vaak dat simpele dingen simpel zijn en niet simpele dingen mogelijk. In die lijn is bijvoorbeeld boost::random het beste voorbeeld van echte gebruiksvriendelijkheid. Als je een dobbelsteen wilt hebben dan is boost::random zo simpel als de lexical_cast. Wil je iets doen met een verzwaarde dobbelsteen, dan kan dat ook maar moet je er even iets meer in duiken.

Voor beginnende softwareontikkelaars kan het handig zijn, als zij alleen maar ervaring hebben met JavaScript.

Dat geldt dan toch voor elke taal?

Voor een beginnende ontwikkelaar is het altijd handiger als hij kan programmeren in een taal waar hij alleen maar ervaring mee heeft.

Dat verklaart nog steeds niet waarom er voor JavaScript gekozen is.

[Reactie gewijzigd door defixje op 18 november 2014 13:30]

Dat geldt dan toch voor elke taal?

Ja dus? Als je al goed bent in C++ kan je al 100den verschillende dingen kopen die je daarmee kan programmeren, en met JS misschien een handje vol...

Dus ja het kan wel nut hebben, de groep die liever C++ schrijft spreek je hier niet mee aan maar een ander /nieuwe groep wel. Dit spreekt gewoon een nieuwe markt aan...

Maargoed doe mij de WE IO maar 2x zo duur maar 4x zo vet (Node)JS icm HTML/CSS is voor mij als webdeveloper natuurlijk wel zo relaxt

[Reactie gewijzigd door watercoolertje op 18 november 2014 13:39]

Dat geldt dan toch voor elke taal?

Voor een beginnende ontwikkelaar is het altijd handiger als hij kan programmeren in een taal waar hij alleen maar ervaring mee heeft.

Dat verklaart nog steeds niet waarom er voor JavaScript gekozen is.

Precies, een microcontroller met ondersteuning voor COBOL lijkt me bijvoorbeeld veel leuker

Omdat er meer javascript 'programmeurs' zijn dan c++. Een van de redenen waarom tegenwoordig steeds meer richting javascript, html en css wordt getrokken. Je hebt ineens een scala aan designers die ermee kunnen werken.

Zo zag ik dat veel linux grafische omgevingen als gestijld kunnen worden via CSS. Huh? Ik kan ineens enorm makkelijk en snel mijn eigen linux thema maken? Toppie!

Gelukkig komt er een opmars naar statisch getypeerde javascript derivatives, want iedereen is er nu wel achter dat Javascript niet onderhoudbaar is op grote schaal.

Het grote voordeel van JavaScript op de Espruino is dat je 'm "live" kunt programmeren. Je kunt gewoon functies toevoegen, aanroepen, variabelen bekijken enzovoorts.

Ontwikkelen gaat zo vele malen sneller.

Ook gaat hij vanzelf in slaapmodus als er niets gebeurt, veel slimmer dan de domme oneidige loopjes die je vaak in Arduinocode tegenkomt.

En wat ufear zegt: veel makkelijker asynchroon programmeren. Tegelijk een knipperlichtje, de temperatuur uitlezen en een knop in de gaten houden? Heel simpel.

Arduinos kunnen gewoon slapen als je het ze verteld hoor.

Dat ontken ik ook niet ;-)

Het werkt allemaal wel wat lastiger.

Javascript kruipt waar het gaan kan. Daarom.
En Javascript evolueert denk aan Ecmascript 6.. en daarna 7.

- Servers;
- Clients;
- Microcontrollers / Embedded toepassingen;
- Offline WebApp oplossingen; ( Denk aan Popcorn Time )
- Netwerk toepassingen.

Dit was ook mijn eerste reactie. Waarom zou je dat willen? In assembly programmeren voor een microcontroller is zelfs te doen, C++ al helemaal. Dat maakt het programmeren van zo'n microcontroller des te leuker als je het mij vraagt

Ik moest eigenlijk meteen aan deze xkcd comic denken

Welke JavaScript Engine wordt hiervoor gebruikt?
Is dit een engine die zelf wordt gebouwd of gebruiken ze een reeds bestaande engine?

Edit:
Even rondgekeken op Kickstarter en hier een uitstekend antwoord op ontvangen:
Which JavaScript Engine does Espruino Pico use?

Espruino boards use our own JavaScript engine that is specially designed to fit into microcontrollers.

Microcontrollers have so little memory (around 1,000,000 times less than a desktop) that existing engines such as SpiderMoney, Rhino, or V8 just don't stand a chance.

[Reactie gewijzigd door Mikke8 op 18 november 2014 13:30]

Espruino boards use our own JavaScript engine that is specially designed to fit into microcontrollers.

Microcontrollers have so little memory (around 1,000,000 times less than a desktop) that existing engines such as SpiderMoney, Rhino, or V8 just don’t stand a chance.

Net zoals we vroeger met C++ op mobile hebben gezien in de Symbian tijd verwacht ik. JavaScript in naam, maar zover verwijdert van de standaard dat je niet moet proberen bestaande code te gebruiken ofzo.

Persoonlijk zou ik veel eerder voor eLua gaan dan voor Espruino of Micro Python. JavaScript en Python zijn gewoon full-fledged applicatie capable programeer talen die als je aan de runtime gaat knippen nog maar weinig met de oorspronkelijke taal te maken blijven houden. Lua is een stuk meer light-weight, en het verschil tussen normaal Lua en eLua is dan ook beduidend minder dan voor Espruino of Micro Python.

Heb je ervaring met JavaScript op Espruino of bedenk je maar wat?

JavaScriptondersteuning is in ieder geval goed genoeg om zelden tegen verschillen aan te lopen.

"goed genoeg om zelden tegen verschillen aan te lopen" is een bagger definitie, je moet weten WAT er wel en niet werkt. De site is daar met de 95% claim en vele sussende woorden erg vaag over.

Gelukkig is er een manier om er zelf achter te komen hoe goed/bar e.e.a is.
Het is even pielen, maar op test262.ecmascript.org kun je uit een aantal json files een hoeveelheid tests trekken die je met wat moeite ook aan b.v. Rhino of Espruino kunt voeren.

JavaScriptontwikkelaars zijn wel gewend dat runtimes zich niet altijd aan de spec houden en code een beetje aan te passen zodat het overal werkt.

Misschien vind jij dat bagger en ken jij wel de spec van je taal uit je hoofd, maar met JavaScript sta je hier toch wat flexibeler in

Maar vergelijk dat nou eens met eLua!

http://www.eluaproject.net/overview

De keuze voor een compacte script-taal based oplossing is:

1) Manke JavaScript
2) Manke Python
3) Volwaardige Lua

Lijkt mij een no brainer.

Perl is ook leuk om mee te spelen als script-taal

Op dergelijke hardware?

De maker schreef:
The interpreter is 'Espruino'. It's been written to run in the low memory that a microcontroller has. It's been in use for over two years now, so is pretty stable.
Bron: https://www.kickstarter.c...t-on-a-usb-stick/comments

[Reactie gewijzigd door Veda88 op 18 november 2014 13:33]

In hoeverre verschilt dit van https://tessel.io/ Die kun je toch ook op USB aansluiten?

De principes zijn inderdaad gelijk. De prijs in ieder geval niet.

Espruino Pico: 21 euro

Tessel: 60 euro

het principe wel, maar dat ding is geloof ik stukken krachtiger, gebruikt meer stroom en is veel groter.
Dit dingetje is zo groot als een USB stick.
Niet te vergeten dat de Tessel ook nog Wi-Fi built-in heeft.

[Reactie gewijzigd door space_octopus op 18 november 2014 16:58]

Jammer dat er niet meer info over de I/O op staat. Met name de uitgangen lijkt me wel interessant om te vermelden? PNP? 0-10V? 4-20mA?

De CPU is een STM32F401, dus je kunt de datasheet opzoeken.
Verder schrijft hij dit:
On-board 3.3v 150mA voltage regulator.
Dus de IO zal wel 3.3v zijn (inputs zijn 5v tolerant).

Omdat je lekker async kan programmeren zonder gedoe lijkt me..

Kan ook prima zonder Javascript. Dus als dat het enige zou zijn...

EDIT: Respons aan verkeerd/geen persoon. Excuses.

[Reactie gewijzigd door Cilph op 18 november 2014 13:30]

Javascript+usb+firmware+malware=bad bad usb..:

https://srlabs.de/badusb/

Niet veel anders dan een arduino, die is ook herprogrammeerbaar als je hem aan je computer hangt.

Ligt eraan hoe je je arduino gebruikt. Die van mij staat momenteel als HID apparaat. Die moet ik eerst terugflashen wil ik er andere code uploaden.

Het lijkt me dat het hier wel om hardware gaat die niet echt naar onbekenden wordt uitgeleend

Oh ik hou van deze microcontroller. Ik ga deze gebruiken om te experimenteren met zowel hardware als software.
De rede dat ik niet gewoon een Raspberry pi daarvoor koop is omdat dit er speciaal voor bedoeld is, de "starter kit" heeft een breadboard met wat kleine dingetjes en daarmee kun je geweldige dingen maken.
LEDje erin doen, "LED1.turnon();"(of iets dergelijks), en je ledje staat aan!
Je hoeft ook niet te compilen en je kunt ook vanaf een afstand commando's geven als je een netwerk chip erbij doet.
Het mindere is is dat 'ie niet zo krachtig is, maar hij kan ook wel 10 jaar op een lithium batterij mee!
[Offtopic: net gebacked, zie ik het project terug op Tweakers! :P]

Wel ff een pull-up weerstandje gebruiken anders vreet je LED de uitgang op.