Search results for:

Thanks! It'd be awesome if you could contribute it back when it's done - Espruino could really do with a bit more control of its peripherals.

Could you also check it compiles on ESPRUINO_1V1=1 ? :)

Great, let me know how it goes!

How about Serial.setup({databits:7,stopbits:2}) - you could add this to JshUSARTInfo in jshardware.h pretty easily, and it'd be nice and compatible with anything that didn't support it (or that supported other modes).

Maybe just add the following in jshardware:

if (databits==7 && stopbits==2) ...
else if (databits==8 && stopbits==1) ...
else jsWarn("Specified combination of stop and data bits is not available");

does that sound ok?

I know as much as you about this - but if it's possible in the STM32 then it shouldn't be a big deal to implement in Espruino.

I did a quick google and found the following - it looks like if you're happy with 2 stop bits then you can bodge it, but otherwise you can't do it.

https://my.st.com/public/STe2ecommunitie­s/mcu/Lists/cortex_mx_stm32/Flat.aspx?Ro­otFolder=https%3a%2f%2fmy%2est%2ecom%2fp­ublic%2fSTe2ecommunities%2fmcu%2fLists%2­fcortex_mx_stm32%2fUART%207%20data%20bit­s&FolderCTID=0x01200200770978C69A1141439­FE559EB459D7580009C4E14902C3CDE46A77F0FF­D06506F5B&currentviews=252

Ok, so you mean a standard consumer amp? Does it have outputs for lots of speakers - or just two, and you want to switch the speakers in and out?

It depends on your amp really - if the amp will do everything you need (and it's just a matter of controlling it remotely) then faking the infra-red remote control is probably a really nice easy thing to do...

Hi Josh,

Yes, you could use the analogs to change the volume, but you'll need some extra components (like FETs). Realistically it's probably not the best way.

You may be better off with a specially designed chip - see http://hackaday.com/2009/02/16/parts-i2c­-audio-volume-potentiometer-ds1807/ (or the manufacturer's page: http://www.maximintegrated.com/datasheet­/index.mvp/id/2782)

You can connect that up to Espruino with 2 wires, and then connect your left and right audio through it - I don't think you need any extra components apart from maybe 2 resistors for the I2C.

As far as switching audio around, you could connect up some relays (we'll try and cover this in our documentation), or there are probably similar chips to the one above that handle switching multiple audio sources as well.

Of course if you wanted to control your amplifier without wiring much up externally then you could always use servo motors to move knobs on the front panel (if it's old) or even make a fake IR remote control (if it's newer).

Bluecamel - new code comment? Sorry, I realise that you weren't having a go. Complete was probably the wrong word (I meant that the stretch goal had been reached)

Thanks for the comments - I'll try and get better at this. I guess it is the nature of things that generally I don't hear anything back when it works properly - I guess I should be happy that the only things being reported are really pretty minor :)

I guess given the downloads I'd hoped that there would be more people going 'look what I made!' though, so that's a bit sad for me. Hopefully when the board is released with some better docs that will happen more.

I didn't mean to sound so aggressive there - the issue is that I'm now currently spending more time answering questions about Espruino's source than I am improving Espruino - which IMO is not good for Espruino's KickStarter backers. When I actually do get time to make a change (like drawVectorString) then I have 'bug reports' posted on GitHub and the forums from people who haven't even bothered to check the Changelog or up to date documentation (let alone the source).

Contributions are welcome though, and some really good things are coming out of it - for instance Eyal has already found a few issues and contributed fixes for them.

Personally I'd really love some constructive contributions (bug reports with patches), patches to implement more JS built-in functionality, simple projects with write-ups, etc.

It's just a bit frustrating to be inundated with random bug reports where someone has made no attempt to fix the problem - it's easy to pick holes, and while it's good to document the problems I feel that it's not really helping much at the moment unless the reports come from someone using Espruino properly (rather than just creating contrived cases where it might not work as they expect).

Hi. This was covered on GitHub - basically the API has changed to be more Java-like. The documents that come along with that build do describe the correct API - but the ones on the website are for 1v39 which has the old API.

As explained on GitHub, everything is in flux before the Espruino board release.

Hi Graham, you may just be unlucky... The STM32 has a bunch of timers, but not enough for each pin - so sometimes if you set one pin and it uses a timer that was in use by another, it gets reset.

I guess this is something that we could warn about with a little work...

Yes - you can use peek and poke commands to access the ADC directly - just follow the relevant datasheet.

Although if you implemented the functionality in Espruino itself it'd be great (it could be as easy as modifying build_pininfo to include an additional pin that referenced the correct ADC channel).

I think it's because it's trying to include an stm32f1 header file. You'll have to edit libs/fat_sd/* and #ifdef STM32F4 all the includes. You'll also need to modify the header file to have the correct pin definitions. If you want to change that and modify build_patform_config.h to automatically set the pin definitions that'd be awesome though.

Personally I wouldn't use SDIO as it's just ore complexity - just stick with normal SPI and follow the circuit from https://github.com/espruino/EspruinoBoar­d

I think this was a regression on 1v39 - it does work on the latest version in Git. You just need to hang on until I release a new one - or you can use an unofficial nightly build: https://espruino-nightly.noda.se/

Hi, no - it just says that when our backers get the board, it'll have CC3000 support - same for NPM, tutorials etc.

Surprisingly it takes time to implement these things - they weren't done already or they wouldn't have been stretch goals.

I probably should have done like everyone else and released source 'when it was done'.

If you mean using Espruino directly from C code, you want something like:

JsVar *v = jsvNewFromString("......");
jsvUnLock(jspEvaluateVar(jsiGetParser(),­ lineToExecute, 0));
jsvUnLock(v);

Note that EvaluateVar returns a result as well.

Espruino can't execute directly from char* strings (only from JsVar-based strings).

I guess the more sensible thing is to put a Raspberry Pi SD card image online somewhere.

It doesn't take that long to compile on a Pi, and a lot of folks have one.

We're still adding CC3000 support - so some code is in there but it's not working yet.

Espruino does have modules - you put them on the SD card in the node_modules dir and they work like this:

https://github.com/espruino/EspruinoDocs­/blob/master/devices/DS18B20.js

If you do make some modules, please issue me with a pull request for EspruinoDocs - I'm trying to build up the library. The API may change slightly soon so that we can be relatively compatible with Firmata + Tessel and use their drivers (hence the use of the 'hardware' module).

There's also going to be something added to the Web UI that will allow you to do something like 'npm install' even if your board isn't itself connected to the net.

Hi Frida,

So I think you actually mean:
digitalPulse(LED1, 1, 1200)

This is expected... So what happens is that digitalPulse sets the pin to 1, then starts a timer in the background, which sets the pin low after 1200ms = 1.2 seconds.

If you then call digitalPulse again, it waits for the first timer to finish before it starts the next pulse. Rather than hang the device, it only waits around a second for the pulse before giving up and raising an error.

Perhaps it should produce a better error message, but I think the behaviour is right. If you typed digitalPulse(LED1, 1, 100000000000) you wouldn't want the device to just stop working while it waited.

digitalPulse is for short 'pulses' that need to be very accurate. For longer pulses, use setTimeout instead.

I learnt it for websites too - I wanted to do animations with it...

There is actually Python for Microcontrollers called PyMite (I'm not sure it has the interactive console though).

I just really don't 'get' Python though. I love the huge amount of libraries it has (and I do use it because of that), but I don't understand why it has a completely different syntax to every other modern language.

Thanks! Using a VM is definitely a good way to go - I wonder if someone could wrap this up in a script that could be executed once a VM was set up?

There's also USB stick Ubuntu as well - could be worth a try:
http://www.ubuntu.com/download/desktop/t­ry-ubuntu-before-you-install

Also, I'll be auto-generating the docs from this repo soon:

https://github.com/espruino/EspruinoDocs­

So if you have anything (drivers, help, etc) please just add it and issue a pull request. Hopefully once I have the auto-generation properly done, everything will be a bit better organised in there.

Hi, Yes, that should be possible!

Once you have created a module, you just stick it in the node_modules folder of the SD card. There's an example of what it should look like here:

https://github.com/espruino/EspruinoDocs­/blob/master/devices/DS18B20.js

HOWEVER This is likely to change - specifically in order to make modules compatible with Tessel, Firmata etc, the I2C commands may change slightly in the next few weeks.

Thanks! I can't wait to get some boards out and see what happens ;)

Hi everyone - we're expecting a bit more traffic to our forums after the KickStarter, and Google Groups isn't really up to it so we're using our friends at http://microcosm.app/ ...