Search results for:

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/download

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

Hi guys.
This following post refers to the "Chirp" soil moisture sensor (https://www.tindie.com/products/miceuz/i2c-soil-moisture-sensor/).

I just successfully integrate this sensor into Espruino. As far as I know, nobody did it yet (or did not publish a basic example code), so I decided to post it here.

You will notice that this piece of hardware integrate a capacitive sensor, as well as a luminosity & temperature sensor.
The temperature result is in [°c/10] : if result is 226, temperature is 22.6°c.
The capacitive & luminosity sensor are both relative.

If you try it, do not forget to add two ~10k Pull-ups on both SDA and SCL.

// Soil Moisture Sensor Example | JRY | 26.06.2015
var Temp;
var Lumi;
var Capa;
I2C1.setup({scl:B6,sda:B7});

function getLuminosity(){//takes ~2 sec. to acquire
  I2C1.writeTo(0x20,0x03);
  setTimeout(function(){
    I2C1.writeTo(0x20,0x04);
    Lumi=I2C1.readFrom(0x20,2);
    print("Lumi:"+(Lumi[0]*256+Lumi[1]));
  },2000);
}

function getCapacitance(){
  var Res;
  I2C1.writeTo(0x20,0x00);
  Res=I2C1.readFrom(0x20,2);
  Capa=Res[0]*256+Res[1];
  print("Capa: "+Capa);
}

function getTemperature(){
  var Res;
  I2C1.writeTo(0x20,0x05);
  Res=I2C1.readFrom(0x20,2);
  Temp=Res[0]*256+Res[1];
  print("Temp: "+Temp);
}
I2C1.writeTo(0x20,0x06);//reset the sensor
//setInterval(getTemperature,10000);
//setInterval(getLuminosity,4600);
setInterval(getCapacitance,1000);

If anyone has a better code or a dedicated .js class, do not hesitate to publish it! :-)

I totally agree with this approach.

Oh I totally forgot to update to 1v79! Thank you Gordon for that fast reply.
Did you publish the schematic of the Pico? I didn't find it on Github.

Anyway, thank you for the support!

Hi guys,

I ordered a few days ago 2 Espruino Pico from Tindie, and yesterday I came accross some very strange behaviour/bug (?!?) : When I run this code on the Pico (revision 1v75), the VCC rail (usually 3.3V) raises up to ~4.6V, which seems to be approximately the same voltage as VBAT.

" Serial1.setup(4800);
Serial1.on('data', function (data) { print(" "+data); });
Serial1.print("hello"); "

I checked the hardware, no visual damage. The solder pad which is meant to control the battery Mosfet with B0 is NOT soldered.

Using Serial2 instead of Serial1 avoids this behaviour, therefore I suspect a software bug related to Serial1. Furthermore, this bug appears on both Picos.
Any ideas?

Thank you!

@Gordon: Gordon, you got the answer! "Luckily, there is an easy fix ! Just put a solder bridge between pins 19 and 20 of the flat cable going to the OLED and everything works :-)"
I soldered pin 19&20 together, and, TadaAAAAaM, it just works!
I spent hours reading threads and comments, I did not cross that one!

Thank you Gordon!

Just a bit of further information: For those who bought their OLED displays on Hobbyking (the ones that are manufactured by hexTronik). You should not have to patch the reset circuit, it already exists on the PCB (R3 and C10, next to pin 14). If someone wants to have a look at the patch, you'll find nice pictures of the patch here: https://github.com/hallard/ArduiPi_SSD1306/issues/1

@Gordon: I tried to power the display through the VBAT and 3V3 (right next to the GND pin).
I am using the connector on the display side. I tried to swap SCL and SDA too. I got 3 displays out of the box, I tried each display, same behaviour.

@DrAzzy: I have 10k pull-ups on both SDA and SCL. I although tried to put 4k7 resistors, without any better results. The display is rated between 3V3 and 5V. In my case, I could not damage it (or should I say , damage them, because I tried each of my 3 displays)

Weird, isn't it?

Hi folks,

I spent hours trying to print something on some OLED displays I received from HobbyKing (http://www.hobbyking.com/hobbyking/store/__55110__Multiwii_OLED_Display_Module_I2C_128x64_Dot_MWC_AU_Warehouse_.html).
I guess the silicon is SSD1306.
However, Espruino tells me "Timeout on I2C Write Transmit Mode 2" everytime, in every configuration. I tried to downgrade Espruino, I tried putting some Pull-up on 3V3, I tried powering the module on 3V3 or on VBAT, I tried I2C1 and I2C2, I tried to decrease the clock down to 1kHz,I tried to modify the SSD1306 module in order to change its I2C address (browsed whole range from 0x00 to 0x7F), I tried to shake my display, I tried almost everything.... "I2C timeout" tells my Pico......

If someone used to play with those Multiwii OLED displays, I will be grateful to learn from your experience.

My current config is:

• Espruino Pico
  
• firmware 1v77
  
• trying to run that example code http://www.espruino.com/SSD1306.
  
  

"I2C timeout" . . . aaaAARARRGHHHHHH !!!!!

What I like:

• Espruino
  
• IoT
  
• More Espruino
  
  

What I do:
80% Hardware
15% Firmware
5%Software

Linkedin: linkedin.com/in/jprey
Twitter: https://twitter.com/yerpj

Thank you for the link, I did not realize I could do digital waveforms with digitalPulse() !
Actually this LCD has a ST7036i controller, which is slightly different... That said, I did not use a I2C based HD44780, I don't know if, in this mode, the command set is the same or not...
I already used a LCD with HD44780 controller and a 4-bit interface, that was "far too easy" to drive ;-)

Hi,

I would like to interface my Espruino Pico with an NHD-C0220BiZ LCD from Newhaven display. It is quite easy to drive. I used to do it with an Electricimp a few months ago ( https://forums.electricimp.com/discussion/3198/using-the-newhaven-i2c-2x20-char-display-nhd-c0220biz-fsw-fbw-3v3m ) but now I have some problem for the reset waveform generation (optional, but it is a good practice). I would like to drive the reset pin HIGH, LOW for some time, and finally HIGH (´´´´´______/´´´´´´´´´´´). This is really easy to do with some kind of a "delay()" function, but Espruino is not intended to work this way... I though to use 2 setTimeout() in order to control the positive&negative pulses duration, but finally I ask you if someone could give me a cleaner method?