espruino / espruino Goto Github PK

Also better error reporting generally, but I2C often gives 'INTERNAL' timeout errors if it doesn't get a response on a certain address.

In functions and root scope - move a variable to the front when it is accessed - this should speed up accesses in things like loops quite a lot.

I believe this is an ArrayBuffer iterator problem:

new ArrayBuffer(1)  ==> 'new ArrayBuffer([])' // bad
new ArrayBuffer(2)  ==> 'new ArrayBuffer([0,0])' // good

STM32F1 boards have USB flow control, but the F4 doesn't - so copy/pasting code tends to lose characters

An important one - allow Espruino to be woken from deep sleep mode by Serial and USB. Currently not having this means that Deep sleep is disabled by default.

Potentially these guys:

http://wiki.ecmascript.org/doku.php?id=test262:command

When flashed onto Olimexino board it just lights up the green LED. This probably means that something bad happened during the hardware initialisation in jshInit

The STM32 chips can be overclocked - some people say by as much as 2x. It'd be fun to have a mode that allowed this :)

Firmly an 'enhancement', but it should be possible to modify the parser to have a built-in debugger that allows s/n/p/q type commands which can single-step through statements.

Ctrl-C could break into this and then Ctrl-C could break out of execution completely. It'd massively help with debugging.

We need to check if we have any watches left on the given pin before clearing. It could also be a good reason to set hardware flags for detecting rising/falling edges (currently it responds to both, and software detects which edge it was)

A common way of sending an Array or ArrayBuffer using:

• Digital outputs (>1 at a time)
• DAC
• PWM

Or receiving into an Array/ArrayBuffer:

• Digital inputs (>1 at a time)
• ADC

Faster than you could manage with setInterval, but:

• at a user-defined speed
• optional repetition
• a callback on completion or for new buffers

IMO this doesn't need to be complicated with DMA, and we have UTIL_TIMER which we should be able to extend to handle this.

Technical IO have something called 'Signal' that might be able to be extended: http://hardwarejs.io/

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty

Array.map must pass 3 arguments to the callback function: the current element, the current index and the array itself. But the current implementation passes only the first argument. Example:

var chars = ['a', 'b', 'c'];
chars.map(function( char, index, arr) {
 //do something
});

On the 'HY' boards you need to copy/paste a touchscreen driver. This should be added as a 'module' at the very least, with a well-defined callback

The first JSV_STRING in a chain could actually store only 8 characters (but a link to the last JSV_STRINGEXT in that chain). It'd allow us to do much faster appends which would help out in a number of areas.

It has to be aware of scope/proto elements and JSV_PARENTINFO so that it can rebuild code snippets that contain heavier Object orientation.

Even if only filesystem-based, there should be some built-in support for this in linux/src/jshardware.c. It should be pretty easy.

It seems there's a bug in the F3 implementation where you can't use an 'alternate function' Serial port

Add the JavaScript delete keyword. Should be a lot easier now we have parentinfo

Otherwise it gets hard to put different fonts/colours end to end

There should be a way of getting a 'shortened' JSON that can be used in the interactive console. For instance:

[0,1,2,3 ... 100,101,102]

and

function (a,b,c) { ... }

It'd be a bit faster and would save some RAM...

Not done yet, so the following doesn't work:

Serial1.onData(function(data) { this.write(data); })

As the title - it'd allow you to store different programs really easily, and also to swap them between Espruino boards (of the same type ;) )

We should be able to do:

new SPI({mosi:A0,miso:A1,sck:A2})

And have Espruino treat it like normal SPI - but to instead just bit-bash the output. This would be way more useful than a shiftOut function.

It'd also be super-handy if it could take an argument called bits, as the hardware SPI implementation doesn't support 9 bit output and many devices (like LCDs) can work without a Data/Command (DC) pin.

Immediately after checkout:

$ make
...
Outputting decision tree
Traceback (most recent call last):
  File "scripts/build_jswrapper.py", line 135, in <module>
Traceback (most recent call last):
  File "scripts/build_platform_config.py", line 90, in <module>
    wrapperFile = open('gen/jswrapper.c', 'w')
    IOErrorheaderFile = open(headerFilename, 'w')
: [Errno 2] No such file or directory: 'gen/jswrapper.c'IOError
: [Errno 2] No such file or directory: 'gen/platform_config.h'
make: *** [gen/platform_config.h] Error 1
make: *** Waiting for unfinished jobs....
make: *** [gen/jswrapper.c] Error 1

That's because there's missing "gen" folder, which is becasue git doesn't store empty dirs, and way to work that round is to add ".empty" or similar file.

Tim from technical.io has come up with this proposal http://hardwarejs.io/ - but at the moment it's a big departure from Espruino's implementation (which already has a bunch of code written for it).

As a starting point (and to be compatible with J5-type arrangements where you can have more than one board) we'll want to have a 'hardware' object with all the existing API calls in. Hopefully this could be the root namespace, so you can still do digitalWrite(LED1,1) but also hardware.digitalWrite(hardware.LED1,1) in order to be compatible...

Currently the filesystem uses hard-coded pins for SPI - which makes it hard to port to other platforms.

a[5]===a["5"]
a[5]!=a["05"]

Espruino doesn't have this behaviour. Easy enough to fix but it's debatable if we want another check to slow down array access even more.

From here:

http://ascii-table.com/ansi-escape-sequences-vt-100.php

Rather than sending spaces - it'd be a lot quicker for multi-line editing over bluetooth, but would also need implementing in the WebUI.

While arrays are still linked lists, it's possible to speed access up by looking at the last element and working backwards if the index > last_element/2

It'd be nice if setWatch had some debounce capability. It'll be used quite a lot for interfacing switches, and it's quite a hurdle for beginners to implement debounce.

This could be handled quite easily by modifying the event in the event queue, but it would require that 'debounced' events weren't automatically pulled off of the event queue.

The numbered tests are a pain - it'd help if each test was given a descriptive name, and then test fails could be seen easily.

Add JavaScript exceptions - we just need to find a nice way of doing this that doesn't slow us down when we're not using them.

This needs some experimentation to find a fast way of detecting built-in functions.

It seems like function names should be detected first, and the parent object should then be checked (rather than the other way around) but when I tried this it massively increased the code size.

This would save you having to write initialisation code into an onInit function...

I believe SPI already saves state, so it's just a matter of adding other peripherals - although we'd require a jshGetPinState added to jshardware.h

Currently you can just type:

fs.readDir()

But really you should type:

var fs = require('fs');
fs.readDir()

Same for http.

We only need one JsParse active at a time - it'd be good to remove this, we could save some code space as well as a few bytes of stack.

toJSON should be aware of line wrappings - it'd really help when dumping to the console

There's the outline of some code for this in jsdevices.c/h already but it's not yet implemented. It'd be pretty handy when copy/pasting code over Bluetooth.

Causes glitches like are seen here:

http://www.youtube.com/watch?v=RBHP4xDCRk4

I guess ideally SPI would be driven via interrupts, so this fix could form part of a larger bit of work

We need a USB bootloader so that Espruino devices can be reflashed.

While we could use DFU, it makes a lot of sense to use a USB CDC (fake serial) bootloader implementing a protocol that's compatible with the built-in RS232 one. That way, Espruino can be reflashed from the Web IDE.

The current filesystem implementation only allows reading an entire file. Given the limited memory we need to implement the part of node's filesystem API that allows files to be read a bit at a time:

http://nodejs.org/api/fs.html#fs_fs_open_path_flags_mode_callback

Writing is not such a big deal because we can append - but would be nice to have.

setTimeout must return positive id. Currently it starts from 0. Zero (false) id usually is used to distinguish initialized and not initialized values.
Example:

if( timer)
 clearTimeout(timer);

timer = setTimeout(function(){}, 1000);