-
I'm not 100% sure if anyone uses it already... Are you using hardware or software SPI? I'm not sure about hardware, but software SPI definitely should work with 9 bits.
I just looked at the code and it seems like there is a bug that means that individual numbers being sent to
spi.send
are cropped to 8 bits, so that could be causing you grief?spi.write
seems fine though.If you need to use spi.send, for now, just use
spi.send([data], chipSelectPin)
-
Just got back from a holiday and I have a million e-mails and posts to get through, so sorry for not reading this fully, but this might help:
- Modules can be used from another module
- Modules are only 'loaded in' once, even if used multiple times. If you put
console.log
in the main scope of a module, it will only be called once. But it'll be called right at the start, not when you first dorequire
. - If your module is
var A = {}; exports.A = A;
, every time you require that module you will get access to the same version ofA
- The order of loading should be correct (i think) - that is, if A requires B, B is loaded before A.
- Modules are executed in their own scope (called
module
IIRC). If you want to stick stuff in the global scope I think you can still useglobal
, but that's probably frowned upon.
- Modules can be used from another module
-
Looks great! I've been interested in this kind of thing for a while (I really like the dataflow idea when used in the right place). Node-red's something I was planning on doing stuff with on the Puck.js hub as well.
So at the moment, you have a bunch of yellow espruino nodes, and all of those nodes run on Espruino itself - connected via MQTT?
I don't know how possible it is, but did you consider having just
Node-red -> Espruino
andEspruino -> Node-red
nodes? Then you could decide where the nodes ran based on which side of one of those nodes they were on... It might save you re-implementing a bunch of nodes, specifically for Espruino? -
Using RAM you'd have maybe 30kB available, so if using 2 bytes for temp + light, it's 15000 samples, so if measuring once a minute it's 10 days worth.
Having said that, you can use the on-chip flash too, but it'll drain the battery a bit more. There's 512kB flash, but Espruino + the bluetooth stack and bootloader will take a lot of that. I'd hope there would be 100kB free but I can't be sure about that. SD cards are also supported so you could wire one of those up - but realistically the power consumption will drain the battery quickly - there are also some flash, EEPROM or RAM chips that you could wire on.
The chip is the nRF52832 - it's easy enough to google for the datasheet. It can wake up on a digital IO changing state, a timer, or a bluetooth event - so realistically you probably don't need to go up a tree for it :)
In terms of power consumption, on average with normal Bluetooth advertising it uses 15uA. I'll need to do some proper measurements of the power consumption when running, but I think it's around 5mA. JS execution speed isn't that fast, so you could expect that it might take 2ms to wake up, read temperature and light and write it to memory - so you can work out battery life based on that.
Realistically, as long as you're sampling every minute or more, you shouldn't suffer a big hit on battery life.
-
You might have some luck using
pipe
and setting the chunk size to 1? That might be slow enough that it doesn't fill up the output stream - but it's not very efficient. You're probably better off manually reading from the file and outputting via an interval.We were considering putting another MCU (eg. STM32F030) for this kind of stuff...
There's always the upcoming Espruino WiFi board :)
-
There's a GDB macro called
whereami
in.gdbinit
that should tell you what the call was.Looks to me like that's an issue when running
jsvCopy
on a 'bound' function parameter. Could be it's an argument type thatjsvCopy
doesn't usually get run with.If you can find out what the parameter was (
p jsvTrace(value,0)
injspeFunctionCall
's scope) it should be trivial to reproduce. -
The objects should be created 'on-demand' via jswrapper.c - after they're created, the function pointer inside them points to the constructor function for that object - and that is used by jswrapper to figure out what' inside them.
All I can think is that the function pointer has changed somehow.
I guess, most likely, you've saved some code and then updated the firmware without clearing out the area reserved for saved code? That'll have moved the function addresses around and will have broken the pointers.
That's been a common thing all along... one of the reasons I've been pushing for all-in-one hex files that overwrite saved code.
I guess you could change the hex file to write another
blank.hex
over the area reserved for saved code? -
-
This is for anything related to the Puck.js Bluetooth Beacon that was just launched on KickStarter: https://www.kickstarter.com/projects/gfw/puckjs-the-ground-breaking-bluetooth-beacon
-
Yes, it wouldn't be too painful for someone to add this
However perhaps timezone support in
Date
would be better?Although (and one of the reasons I've been slow to do this) - I'm unsure how Daylight Saving Time would work. Last thing I want to do is to add all the calendar offsets for each timezone into Espruino.
Perhaps just a module called
timezoneGB
or something that had asetInterval
that ran once an hour and updated the timezone based on the current date? -
-
I'm pretty sure that
str += "more text"
will do a proper append automatically as-is, so it should be pretty fast.If you're interested the code is here
It won't work if the string is referenced elsewhere though:
var str = "Hello "; var foo = str; str += "more text"; // It's done a copy in this case.
-
Is that
process.memory()
that you put what you get right after uploading?It's possible that it's not the code that's using up memory, but stuff that it allocates (arrays/etc?)
Having said that, 20k of code is quite a lot for a module. At the moment, to load it Espruino ends up having to store the same thing 3 separate times (momentarily), so that's ~60kB, which is going to end up being too much.
It might be worth looking at http://www.espruino.com/Performance for some ideas about how to save memory/get your module size down.
You should definitely try and avoid stuff like
getFoo = function() { return foo; }
though (if you have them) - it wastes space and slows execution down quite a lot on Espruino... -
If you just removed the:
JSON{ "type" : "library", "class" : "Telnet" }
that might fix it? I guess everything would be on the global object
Telnet
instead, but that's not such a big deal as the object is going to exist anyway? Or you could use a lowercasetelnet
library.If that fixes it then it could possibly be fixed in
build_jswrapper
- however there's then some confusion about how to add stuff to a library. There's a branch on GitHub where I was trying to sort this mess out a bit (using more sensible JSON namings), but I haven't got around to merging/test enough yet. -
-
The Puck.js KickStarter is almost over, and I'd really like to be able to use this as an opportunity to make it easier for all of Espruino's users to re-use and share code.
For Puck.js itself, I'm trying to make it easy for people who might be scared off code, so I'm thinking:
- puck-js.com will have a bunch of simple recipes (image + description + code). Code could be JS or Blockly, but will be hidden from sight initially. You'll be able to click a link to upload, or one to 'remix'
- When you upload/remix, that will pop up the Web IDE (the Chrome app if installed, or the Web Bluetooth IDE)
- You'll be able to either upload the code directly or tweak it first, then upload.
- You'd be able to save your tweaked code somewhere, and then submit it as a new 'recipe' for puck-js.com
Hopefully I'll add the same system to espruino.com too, and puck-js.com will just be the same list of recipes, but filtered on Puck.js.
I'm seeing puck-js.com as a very simple, clean list of recipes and a getting started guide - and then proper documentation would still go back to espruino.com.
So the questions really are:
- How should code be saved? I'm veering towards GitHub at the moment (maybe Gists?)
- How should documentation be saved? I'm thinking Markdown in a comment at the top of the code.
- How should code be submitted? I could use Github logins on the side, and could just have a list of links to Gists, that then got pulled into the website...
- And then images... They can't go into Gists, but I could have a way to upload thumbnails on the site.
Then there's also the question of the totally web-based stuff, like this:
https://www.youtube.com/watch?v=N5cp4OoSt-o
Not sure if I really want to host arbitrary HTML/JS code locally? Probably not, but at the same time these are probably the things that will really get people excited about Puck.js, so they need to be nice and easy to show off.
- puck-js.com will have a bunch of simple recipes (image + description + code). Code could be JS or Blockly, but will be hidden from sight initially. You'll be able to click a link to upload, or one to 'remix'
-
-
And http://www.espruino.com/FlashEEPROM for a cleaner wrapper around it
-
-
it is definitely worthwhile to think about NPM
Yes, we need to come up with a good solution. It's a hard balance between being totally friendly to new users (having a 'curated' list of non-duplicated modules that are searchable, well documented and 'just work') and being totally open for anyone to publish whatever they want, with versions and stuff like that.
There's also this issue of having NPM modules be nicely usable with the Web IDE - things like
npm install
and minification become way more painful if you're working within the confines of the browser.@chalkers is working on some tools that should make Espruino easier to use in a more Node-style way (there's also
espruino
on NPM)... it's just finding a way to have everything work together, as the Node.js/NPM workflow is very different to the 'plug in and go' that many other Espruino users are used to. -
Thanks - looks good! Shame about the constants though - must have taken you ages to inline them, and it's something that the minifier would have done for you just by changing
prototype.C
tovar C
:)Super minor, but it looks like
bitMaskArray
andpixelBitPosArray
are no longer needed now?A pull request via Espruino's GitHub is still definitely the preferred way... Then people can find stuff just by searching the site for something like 'epaper'.
-
this.scd(this.C.cmd[5], 0x00);
Ahh - I definitely wouldn't do that... it's probably less confusing to just write the actual number in there :) The first option (well, just
C.CMD_SOMETHING
) works well.Is that possible with the arraybuffer Graphics instance?
Yes, totally - it's made for exactly this kind of thing. There are even options for some of the really bizarre pixel ordering that some displays use :)
Graphics.createCallback( this.C.DISPLAY_SIZE_X, this.C.DISPLAY_SIZE_Y, 2, {msb:true});
or:
Graphics.createCallback( this.C.DISPLAY_SIZE_X, this.C.DISPLAY_SIZE_Y, 2);
should do it... Then just use
g.buffer
(which is a standard ArrayBuffer - you may need to usenew Uint8Array(g.buffer)
on it to get at the data).Try drawing a diagonal line first (it usually helps to see what's wrong :).
-
I'm not really sure what the plan is with
cmd: new Uint8Array
?I think really the goal is to ensure that the minimizer can actually totally inline the constants and then remove
C
altogether, so a Uint8Array may not help.Having extra constants doesn't matter at all as long as they can get minimized away, in fact it's probably handy for people later on.
I think the Writing Modules and Performance pages are about all there is right now. To be honest the code you had already looks really good.
Things that'd make it a bit more efficient...
- Change
sendCommandAndData
to something with a short name, likescd
- it's public so the name won't get changed, so the smaller it is the smaller the final code will be. - There's no need to
return;
at the end of functions, you can just ditch that - The
var C
thing - Make
lutRegisterData
aUint8Array
and define it outside the function - that'll make a big difference to memory usage. If it's possible to use an arraybuffer Graphics instance, that'll be so much quicker than the callback one. It looks like a 2 bit instance would work fine - if the bytes are the wrong order you can define
msb
like:Graphics.createCallback( this.C.DISPLAY_SIZE_X, this.C.DISPLAY_SIZE_Y, 2, {msb:true});
- Change
-
The closure compiler won't shorten any publically available names. Best thing is to make
GDE021A1.prototype.C
into justvar C
, and the compiler will then be able to shorten, inline, and even remove unused elements of that array automatically.That way your could is easy to view and modify, and small. The only downside is that to add to it, you'd have to change the file itself rather than just adding a prototype.
Just a quick idea - if you have WiFi access, I just grab the
Date
header out of the HTTP response when I contact my server. Not as accurate as NTP, but more than good enough for most things - and I can do it without having to have access to the internet.