Search results for:

Hi Jurgen,

That's strange - so it looks like Espruino itself is starting up (because of the brief LED flash).

Does windows react in any way when you connect CN5 (eg. a 'connection' sound)? Does 'LD7' (by CN5) light up?

Hi,

Oliver - thanks! Yes, if others can suggest good places maybe post them here - I'd like to add a page which shows various suppliers.

In the UK there's also http://www.phenoptix.com/

DS18B20/OneWire : OneWire itself is a way of communicating (like SPI or I2C) and is built onto the board. It's the DS18B20 sensor that you need - as Oliver says you can easily get them on eBay - some of them look like transistors, but you'll want the ones that come with a long wire and a stainless steel end.

Hi,

When you press and release the reset button on your board, does one of the LEDs right by it flash for a fraction of a second? That would show that Espruino is installed on the board and working...

Also, it's worth leaving the board plugged in for maybe 15 minutes. While the process is automatic, Windows 7 (at least) takes a long time to install the drivers it needs.

A11/A12 are used for USB (they're the only available pins), and D0/D1 are the only available pins for the crystal. B8/B9 seem to be available though - and on pins:

http://www.espruino.com/ReferenceESPRUINOBOARD

If someone wants to put the effort in to add CAN support to the software (it may really not be too hard, and all source is available) then I'd love to include it. At the moment I'm afraid I just don't have time to implement it myself though.

The problem really is who will actually use it...

The main use case for it seems to be to look at OBD signals from car engines - but to be honest you can buy an OBD-Serial adaptor that handles multiple protocols (ELM323) ready-wired with the connector for a few pounds on eBay - and Espruino will happily talk to the ELM323 as-is via the USART...

It's ok, I made a note on that page about the different types of dongle. I only realised a month ago when I got a different type that was wired the other way around!

Hi Andrey,

Thanks for that - I've corrected those now and searched the site for other 'localhost' links - that seemed to be the only page.

I have changed the table for Wiring, however on many USB-TTL dongles I have (not all though!) the connections mentioned in the table are in fact the correct way to wire them up. It may be that dongles labelled TXD and RXD and different to those labelled TX and RX.

Hi, No - perhaps that needs changing.

Espruino uses all 12 bits - it just divides the value by 4096 (in this case) so the number you get is between 0 and 1.

This means that if you use another board with a different ADC (maybe a 10 bit one) the values will still be between 0 and 1 and your code will still work.

Great!

It's ok - it looks like an issue with USB flow control on the Espruino Board itself (in fact on all operating systems). It is something I'll be trying to look at, but there isn't so much urgency now.

I've just updated the terminal app to fix a bunch of outstanding issues (including - hopefully - this one). The new version is 1v29 and should be appearing in the next hour or so.

Please let me know if it updates automatically or not - you may have to uninstall and reinstall it from https://chrome.google.com/webstore/detail/espruino-web-ide/bleoifhkdalbjfbobjackfdifdneehpo.

Note that serial writes are now throttled so should be more reliable - but will be slower. I'll look into whether I can modify Espruino's USB implementation (as it looks like it is something strange in there) - but for now I hope you won't hit this any more.

Hi user6065,

Can you start a new thread for your problem, as we're trying to sort out an issue with the Espruino KickStarter board here.

In your case I'd be 90% sure that your problems will be fixed by just trying the other USB port on your board (there is no flow control on the standard serial port, and as Espruino sends more characters back than it receives, after some time it will run out of buffer space).

Ok, Just checked. Current state is:

OS	Web App	Local App
Windows	Lost chars	Ok
Mac Os	Lost chars	Lost chars
Linux	Lost chars	Ok

So when I fix the Web App, that'll just leave local apps on Mac OS that have problems...

Hi Neil, can you confirm that this doesn't happen when pasting code in via putty? (Eg, that it is only a web app problem).

I think there are two problems here - web terminal losing characters (on some platforms) and then Espruino USB losing chars on Mac OS.

It's a strange one because the USB code has been in use for over a year and I haven't had any reports of lost characters (it only seemed to happen on boards that used serial, or non-f103 chips)

By the way - you may need drivers for the USB-TTL dongle: https://forum.espruino.com/conversations/202/#comment1239

I wouldn't worry about it though - hopefully you won't need it now.

Ok, thanks - I'll check it out. Pasting via 'screen' shouldn't drop characters - it doesn't seem to on Linux - but I'll do some tests with Mac OS.

For now I'll add some kind of delay into the Web UI on Monday - which should patch up any problems until I fix this properly.

Great!

It's probably best to handle it in C (the less people writing in JS have to be aware of the better). Perhaps you could do something like data & ((1<<databits)-1) and then it'd be vaguely compatible with any number of bits.

Hi, thanks for letting us know. What operating system are you using?

Could you try plugging in the USB to serial dongle that you have (instead of the Espruino), and then connecting one strand of the wire up such that RX and tx are connected?

That way, if you connect with the terminal and do the same thing, you should get the data sent right back to you and we can see if it is an Espruino problem or a web app one.

You could also try using a different terminal app and copying and pasting code in - I believe there are some other examples on http://www.espruino.com/Quick+Start

Even better would be 'you don't seem to have an ARM compiler, would you like me to install one?' :)

Thanks!

As far as build goes, if the build could be completely based on boards/XXX.py, that would be awesome. I think it's probably more useful than menuconfig as there's a lot of duplication at the moment between the Makefile and the py file.

Of course if menuconfig was just a kind of 'where's your compiler', 'what board do you want to build for' - that could be pretty handy...

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/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fUART%207%20data%20bits&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&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).