Search results for:

Guilty...
It seems that it is too late for me to write code... :-/

I explicitely wrote myVar=STATUS somewhere at the bottom of my script. Nothing related to Nucleo nor "code footprint minimizer", I apologize for having suspected them :-)

And thank you @allObjects for your help.

I was first thinking about a problem with the compiler (or "code footprint minimizer") integrated within the Espruino Web IDE, but according to your kind experiments this seems to work perfectly on a Pico.
I wonder why this issue could come from the Nucleo 411....

Hi!

Is there a way to rename a pin? Let's say that a LED is mapped on C0, and is representing some kind of status of the device. I would like to do a digitalWrite(STATUS,x).
I tried doing this:

digitalWrite(STATUS,1);```

This seems to work perfectly. But then I add a variable:

STATUS=C0;
var myVar=32;
digitalWrite(STATUS,1);`` With this last example, when uploading the script to the Espruino (in my case this is right now the Nucleo-411 because each of my Espruinos are already in use) , it appears thatmyVarequalsC0` !

I suspect the STATUS=C0 to be misunderstood by myself, right?

I already had this kind of garbage when using a serial port. In my case, the device (which was not an Espruino nor an ESP8266) had a very bad clock reference, and the baudrate was not totally aligned with one of the 'standards' baudrates. Just to be sure, could you try to connect with putty with , by example, a baudrate like 115000, 114000, 115500, 116000 ?

It seems that the AT21CS01 is slightly cheaper than the DS2502. (At least, comparing the prices on Digikey...) . Maybe this could be of importance in some case.

Anyway, that point is not of great importance, I understand your point of view. I don't think that removing the diode is relevant. For some reason, at Particle.io, they chose to put a reverse voltage protection diode on the Core, even if they put a micro-usb connector on it, just as this board you are designing.

@Gordon

@DrAzzy I've just removed the FET and resistor, so it's just USB->Fuse->Diode->5V->regulator now. The diode is just so you can't force power back into USB if you run from >5v and connect USB, it also gives the regulator a slightly easier time :)

For some projects, I needed to power other things with the 5V of the USB. In order to do that, I had to solder an extra wire just between the USB connector and the schottky diode, because the latter causes a voltage drop of nearly 0.3 or 0.4V depending on the current. Do you think it is possible to add a pin, providing the direct 5V of the USB?

I would reconsider the uselessness of the battery support... (JST header and/or step-up/down)
This is definitely the first feature I look at when I want to leave something running in the field.
If no remaining place on the PCB, why not providing only 2 pads, BATTERY_IN and GND ?

Just a tip for the reverse voltage protection, you can try this mosfet based solution, which requires only 1 component http://rs20.mine.nu/w/wp-content/uploads­/2013/02/pfet.png

Could we imagine this board providing a mechanical hole, in order to ease the mounting ?

Thank you @Gordon, for always trying to improve the Espruino and its user experience.

If you accept to set up a reduced I2C speed, such as <10kHz, the internal pull-ups should work well. Anyway, as @DrAzzy said, the best solution is by far, connecting external pull-ups, as you don't want to encounter I2C errors, they are rather boring to handle.
Be careful by using the poke method (http://www.espruino.com/Reference#l__glo­bal_poke32), this is not safe at all...

Sounds good !!

Microchip provides an evaluation board for this module : http://www.microchip.com/DevelopmentTool­s/ProductDetails.aspx?PartNO=dm164138 , unfortunately it is not cheap at all. (60~70$)
if you just want to try the radio on a short distance, let's say, between 2 devices on your desk, you don't need to take a special care about the ground connexions, therefore you can just solder wires between pads.

(The module draws a maximum of 38.9 mA when transmitting @ 868MHz: http://ww1.microchip.com/downloads/en/De­viceDoc/50002346A.pdf )

Hi @gnz,

I look forward to see projects taking their power both from LoRaWAN and Espruino :-) That is a good thing too, to see such projects in Switzerland.. There is not so many people here to work on IoT .

Your wiring seems OK. For the antenna, you could just solder a wire 8.6[cm] long, which is a 1/4 wavelength antenna. This should work fine. (it is important that the ground pins 22 and 24 of the RN27483 are connected to ground, as they will act as the reference voltage for the antenna.

Once done, the software should be straightforward:

//UART init
var RN2483=Serial1.setup(57600/*baud*/,{tx:B­6,rx:B7});
// RN2483 Reset
RN2483.print("sys reset\r\n");
// your application code...

the wifi.scan() method has been updated recently. the previous callback prototype was "function(aps,...)" ans is now "function(res,aps,...)". You may have to use the second parameter instead of the first one, to work on given ssid list

OK now it works. I think the espruino_esp8266_board_0x10000.bin was not the one I needed, moreover it seems that it is an exact copy of espruino_esp8266_board_0x00000.bin (at least the size is the same). Instead, I used the binaries that I found in the ZIP file (https://github.com/espruino/EspruinoBuil­ds/blob/master/ESP8266/espruino_esp8266_­board_binaries.zip), and it works like a charm!

Thank you Kolban for your help :-)

Dear all,

Tonight I had a few hours to try the ESP-01 port of Espruino. I think the firmware upload succeeded (from this source : https://github.com/espruino/EspruinoBuil­ds/tree/master/ESP8266). I flashed the binaries at 0x00000, 0x10000, as well as the script (main.js) at 0x60000, but after a reset (as well as GPIO0 released), I got bad news: ESP-01 sent me
"ets Jan 8 2013,rst cause:1, boot mode:(3,0)
ets_main.c"

I read on a forum that this is probably that the ESP did not find any application code to run.

Did you ever had to deal with this issue?

(the build date is "Build 2015-10-25 6:02pm CT" )

Thanks Gordon. Currently I solved the problem by using an intermediate stm32 which is responsible to convert PS/2 commands into an UART based command protocol. I will wait for the 1v80 release, then I will try again with the example you tested (BTW, thank you for that example code).

It works. I did a mistake. I assumed that at start up, every GPIO was set to "input", which is not the case (B6 is set to "af_output" by default on Pico). The control of a bidirectional line with pull-up seems alright now.
Unfortunately, I am still unable to decode a digital bitstream from a PS/2 device with Espruino. It seems that despite the use of event-triggered setWatch() function, the code is interpreted too slowly.

I remember that Espruino exposes a function to sample an analog bitstream (in & out). It may be really cool to have such a function for a digital bitstream, which can not be decoded by a UART nor a SPI. Whatever, Espruino is not meant to be efficient on sampling bitstreams. I would use an external MCU to interface my PS/2 device with Espruino (PS/2 <--> UART converter).

Thank you @DrAzzy for your support!

I had a doubt about it, but after a quick check, it seems that a setWatch remains active until it is explicitly cleared by clearWatch.
BTW, @Gordon, are you planning to implement an additional configuration of an IO, that could be set as "digital output, open-collector (== open-drain)" ? This is largely used in the low-level sensors<-->MCUs interfaces (typical bidirectionnal lines).
I believe this may be done by using some low-level function such as peek() and poke(),but this is a kind of dangerous method, as the memory does not seem to be protected at all.

In order to achieve a bidirectional protocol (PS/2 mouse), I have to simultaneously monitor a pin with a setWatch, and drive it (open drain with external pull-ups).

I set this pin LOW with digitalWrite(X,false), and HIGH with pinMode(X,'input') (External pullup drives it HIGH ).

What is happening with the previously declared setWatch on this pin? Does it remains active or is it discarded as soon as I drive this pin with digitalWrite?

Hi guys,

I am trying to interface an old Synaptics touchpad with the Espruino.
Basically, the protocol is PS/2. (http://www.synaptics.com/sites/default/f­iles/ACF126.pdf)
I started implementing something with some setWatch functions in order to react at CLK falling edges.
I am encountering many problems, as the scripting machine is not fast enough to handle things in time.

In order to correctly sample the input digital stream (on DATA line), I tought using an USART (in synchronous mode, with a clock line) but, ... , it is currently not available in Espruino, is it?

Did someone already work on PS/2 interfaces?

Thank you Gordon, calling "echo(0)" is exactly what I needed.

Hi guys,

I am sniffing data coming from the Espruino Pico through virtual COM port (Windows, Python), and I ran into a problem. It seems that each print(X) adds the special "Backspace" character before X, and finally adds "carriage return" +"Line feed".
I wonder if this "Backspace" character is really useful for anything? I am using the serial port for long time, I never had to use this "Backspace" character. If anyone could explain why it is so important, that would be great!

I am a beginner with Python, and I had to find a trick to remove this "BS" character. I tried this one:

myData=comPort.readline()
    myData=myData[2:]

Why "2" characters removed? I don't really understand, I thought only had to be removed, but Espruino seems to send another useless character in front of the printed string, maybe '>' ?

If anyone has a better idea on how to keep only the useful data, do not hesitate to post it :-)

Have a nice day.

I tried to get the Pico HID work with Windows (7) , same behaviour, the HID class does not enumerate as well. I wonder if the Device Descriptor field "bDeviceClass" should be set to 0x00 (line 62 of usbd_cdc_hid.c). I read in a (great) document from Cypress those few lines:

"bDeviceClass, bDeviceSubClass, and bDeviceProtocol
are used by the operating system to identify a driver for a
USB device during the enumeration process. Filling in this
field in the device descriptor prevents different interfaces
from functioning independently, such as a composite
device. Most USB devices define their class(es) in the
interface descriptor, and leave these fields as 00h."

The document can be found here: http://www.cypress.com/file/134171/downl­oad

I don't know the Tiny family, but it is written "ATTINY 441" on the chip