Search results for:

No problem - sorry you didn't have any luck with it.

Radio stuff is tricky. It's always hard to know if it's software, the hardware, or just interference that's at fault :)

I'm not quite sure I understand. You'd expect Hello World to appear on the terminal program connected to your USB-TTL - but it doesn't? Have you checked that the baud rate of the connected terminal program is set to the same baud rate you set for Serial3?

Or you've left C10/C11 completely disconnected and you were expecting things to be echoed back?

It might be worth trying:

Serial3.on('data', function (data) { console.log("<Serial3> "+JSON.stringify(data)); });

That'll make sure that if there are nonprintable characters, they get escaped so you can see them.

Are you using an up to date (1v81) firmware? Some of the older ones had issues with Serial3/4.

You can use an older version of firmware using 'advanced flasher' but I'd advise you just use a more recent firmware that'll have this (and other things!) fixed.

it's ok to have Bat+V to battery +V, Gnd to battery Gnd, and be connected to USB at the same time ( for Rx /Tx ) ?

Yes, that's fine - the Pico has circuitry in there to auto-switch between power sources (if you have instability you could actually remove that diode, but either way nothing will get fried :) ).

For the LiPo batteries, make sure you've got one with protection (a little PCB on the battery - most of them have this now). It restricts the power that can be drawn from the battery and makes everything a lot more safe :)

You could also use a breadboard power supply?

is the following actually doing something or just a nonsense ? ^^
// ( .. ) if ( at.isBusy() ) return cb; // ( .. )

Personally I think it's nonsense. isBusy will always return true if called from that callback I think.

I'd like to keep FlashEEPROM in a state where it still works on a normal 1v81 release, but I think reporting free flash areas in process.memory could be really neat - and it could be modified to check and use those if they existed.

Perhaps something like:

unused : [
 { addr : ..., length: ... },
 { addr : ..., length: ... },
]

I guess for now, only one might get reported, but in a lot of cases I imagine there may be several small areas free that could potentially be used. I don't know if we'd only report whole free pages, or maybe we could report if there were parts of pages that were free as well.

Any thoughts?

Presumably if Aptana is based on Eclipse it's actually written in Java?

I'd say realistically merging isn't going to work (and if Espruino 'moved' IDE it'd have to be as multiplatform and easy to install as the Web IDE currently is). But there's nothing to say that you couldn't write a plugin that used the EspruinoTools package to contact Espruino from Aptana.

... or @Ollie made a very cool program that monitors a file for changes and uploads it to Espruino when it has changed. Presumably with that kind of thing you could do what's needed easily enough.

It's not that high up my priority list at the moment... I do offer consultancy work though, so if you or your company did need it then you could pay for my time to implement it.

I'm not sure I understand. 'Still floating'?

So the median filter code works, but the value is still not reliable? If so, you may need to median filter over a longer time period - perhaps including samples that you have previously taken.

but could not download a proper Virtual COM port driver package version 1.3

Was it a dead link? Anything I can do to help out? XP should still work fine.

@allObjects the Espruino won't output the welcome logo (apart from after reset() if you have saved code to it). It's to help avoid the problem where print statements fill the output buffer and cause Espruino to wait for you to run a program on the PC.

If there's some other problem (like you mentioned involving browser restart) please could you try and come up with some repeatable steps that can get it to happen reliably and create a new topic about it? I can hopefully debug it then.

Ahh, sorry - I literally just scanned over it this morning while answering mail and forum posts and saw:

However, he has chosen to NOT expose the physical address within the address space where the flash is read and written

But as you spotted that's not right. So no, not much of a rant :)

I don't think so... I think ESP8266 is all line-delimited.

I guess given the lack of regex it's a bit difficult. You could search for > or # separately I guess

What happens if you plug it in without the button pressed and follow the rest of the tutorial? It should 'just work'.

The flashing lights only happen when the Pico is in firmware update mode (which you get to by plugging in with the button pressed). The update is a good thing to do, but to prove it's all working ok it's best to just try and connect with the Web IDE first.

I suppose it's possible that the wireless (ESP8266?) is causing quite a lot of noise on the power supply lines, and that could be upsetting your receiver?

Ahh, interesting - I thought it was the opposite (that cu was non-exclusive, and tty was exclusive?). Surprising that it doesn't recognise the tty ports though - the tool itself doesn't do any filtering so I assume the issue is with serialport (although it's written by someone who I believe is mainly a Mac user, so I assume he has good reasons for only allowing cu access).

I'm actually working on Linux, where there don't seem to be cu devices - so I have to use tty :)

That seems very strange... The Pico's RTC can sometimes be as much as 10% out because it's using the internal oscillator (that will be fixed soon hopefully), but it shouldn't be out by any more than that.

Maybe you could connect an LED across the signal wire from the radio so you can see what it's really doing?

It's possible that it's just receiving a lot of noise alongside the signal. The signal itself is very weak. To get to reliable I had to put mine right near the window.

Ok, I think I've fixed it now:

espruino-tools
--------------

Connecting to '/dev/ttyACM0'
Connected
--]
--]=undefined
--]>reset();
--]=undefined
--]
--] _____                 _ 
--]|   __|___ ___ ___ _ _|_|___ ___ 
--]|   __|_ -| . |  _| | | |   | . |
--]|_____|___|  _|_| |___|_|_|_|___|
--]          |_| http://espruino.com
--] 1v80 Copyright 2015 G.Williams
--]
--]>echo(0);
--]=undefined
--]124

Seems strange - looks like the code that listened for the return value expected a String, when it was getting an ArrayBuffer. Not sure how that ever worked at all really.

If you update from GitHub now, it should be better?

Just fixed it. It'll update next time I push the website

Just to add, it looks like there's a big rant on Gitter that this doesn't 'just work' on ESP8266.

All you have to do is var f = new (require("FlashEEPROM"))(whatever_addres­s_works_on_esp8266);

if you want to use this at the moment.

Well, I think the main one is that Espruino's 'console' works over the same USB connection as you're trying to send data on, so you want to move it out of the way. Maybe try Serial1.setConsole() in onInit.

When you do that you might want to avoid using save() though (just manually run onInit()), as then you'd have to reflash the board to get access to the console again.

You are also printing quite a lot of data - I guess it's for debugging, but that could slow things down a lot.

To help you out, you might want to get a USB-TTL converter and attach it to Serial1 (B6/B7 on the Pico). You can then interact with the Pico and debug it while using the USB connection to receive data.

... or you can do it the other way (might be easier to debug) - send the data from Glediator to the USB-TTL converter on Serial1, and then keep using USB to uploading code and debugging.

Well, there's:

SerialX.on('data', function(s) {
  s.split("").forEach(obj.onData);
});

But what I tend to do is handle a line at a time, which I think is easier?

var line = "";
SerialX.on('data', function(s) {
  line += s;
  var i = line.indexOf("\n");
  while (i>=0) {
    handleLine(line.substr(0,i));
    line = line.substr(i+1);
    i = line.indexOf("\n");
  }
});

Thanks - yes, luckily we seem ok at the moment. Not sure why as we seem to have pissed terrorists off more than most. It's awful what's happened though.

The Pico red light thing could be because there's some issue with the SIM800 and you basically ended up shorting out 5V and GND? That would cause the Pico's diode that takes USB power to fry.

To check, you could try powering Espruino externally? Connect a breadboard power supply or battery between Bat and GND and see if the light goes off, and then try and connect via USB?

With the AT commands, I'm not sure what the problem is? You were just getting AT+CMGR=1 repeated back to you? If so, it's because you want to turn off echo with ATE0\r\n first... or you could work around it with:

at.cmd("AT+CMGR=1\r\n", 1000, function cb(d) {
 if (d===undefined) ; // we timed out!
 // d is now the result
 if ( d == "AT+CMGR=1" ) return cb;
 else console.log('AT+CMGR=1 result: ' + d);
});

I said in another post, but I really don't want two versions of the same code in the EspruinoDocs repo - I'll add a keyword you can stick in the unminified file that will force minification using advanced optimisations though.

For local versions, you're using the Web IDE's 'projects' thing?

It looks like there might be some issue with that - I bet it ignores the 'module search order' setting on the settings page :( I'll look into it.

There is no need to free memory or 'clean up the internals of Espruino', because if the socket times out then it's a socket error, which should be reported by sending -1 from the ESP8266 drivers, and Espruino will then see the error and automatically free everything.

It only doesn't do that right now because the ESP8266 port is broken. When it is fixed the problem will go away.

Look at it this way: Right now, if Espruino gets an error reported on the socket it frees everything automatically. Sure, it doesn't report the error to your code, but everything gets freed. It's broken right now because it's not getting told there's a socket error.

So suppose I spend time and add this error reporting code you want? It won't work on ESP8266 right now because ESP8266 isn't reporting the error back to Espruino.

There's absolutely no point me doing it until the ESP8266 port is working as it should... but then when it's working nobody will have this problem any more and the urgency will go away.

Well, as you say, something defining a spare area could be good? I'm happy to add something like that - and maybe it could be pulled out of BOARD.py. At least if it isn't defined, the module could throw an error rather than soldiering on regardless.

Ahh, great! Glad you got it sorted!

I guess it could have been a firmware issue then? I'm surprised if the pin that was used made any difference.