Search results for:

At L9a console.log( "buf: " + this.buffer ) What is the result?

console.log( "buf: " + this.buffer );
buf: 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0....

console.log( "buf-length: " + this.buffer.length );
buf-length: 5808

I also tried initializing it as Uint16, same result.

Looking at L26 L27 L30 L31, are CS and DS backwards?

I tried switching hard- and software-wise, with negative result.

but that transmission follows the update of the display cell by cell with looking up the waveform and pushing it out

Actually, you can (should?) set the waveform on initialization of the display. I guess it is then stored on the chip. In the SSD1606 implementation it is done the same way.
For updating the paper after tranferring the pixel data, you just send one command with no data. In my case it would be

DISPLAY_REFRESH:0x12

I don't suppose you have some kind of oscilloscope you could use to check if the data is being sent?

Nope, I'm not the hardware guy ;-)

Should be perfectly fine

I assumed so as well. I'm quite confident it is an issue with the paper itself.

You could give software SPI a go in case it makes a difference?

I did and it didn't change a thing.

I'll investigate more tonight.

I'll test again tonight to see (proof ;-)) that the buffer is indeed 5808 bytes of data, not just one byte.
I'll also try switching CS/DC pins and/or modifying the data write functions to set those pins differently.

I read about controller and displays the documentation mentioned that the OTP / LUT data is (usually) factory set for best display (quality) performance.

I noticed that the OTP works better for me, the custom LUTs turn the red into rosy (like your display sitting around).

But: I saw that Ben Krasnow from YT channel Applied Science
made a nice video about hacking the ePaper update rates. That'll be next when getting the data transfer fixed up (if possible). :-)

to co-bang-head-on-wall

Sounds good |:|

Ok, so I did a little more testing and sending the data as Uint8Array only writes the first byte of the array to the papers RAM, see pictures (first (red one) is actual, second is supposed to be).

Strange. Could still be an issue with the papers ability to handle all the data transferred to quickly maybe? I lowered the baud rate to 100. It slows everything else down of course, but sill no success.

Just read the specs for the controller. Seems like it supports clock rates up to 20MHz.

3-wire/4-wire (SPI) serial interface for system configuration: Clock rate up to 20MHz

15secs for a refresh / full update

Yes I know it updates slowly and I understand the technology behind it. And I chose it merely because the technology itself intrigues me.
But: the 15s is only the update of the display itself using the waveforms. It has nothing to do with transferring the data.

I'm pretty sure that ePaper displays do not have built-in buffer.

From what it says in the documentation it actually has two buffers: one for old data and one for new data. I guess it is because the display will do other update waveforms if the pixels didn't change between updates.

I think writing the data in the for loop might be slow additionally because of pulling the pins high/low before writing (overhead?).

I will try to do a time measurement on the Arduino example, just to see what speed the display is capable of receiving. The Arduino example uses 4M baud rate if I see correctly.

_bufferSize is the length of the graphics buffer, in my case 5808 bytes (176*264/8).

So the code is this (inside a lot more code):

IL91874.prototype.grfxBlackWhite = function () {  
  var _display = this;
  var g = Graphics.createArrayBuffer(
            this.display.displaySizeX,
            this.display.displaySizeY,
            this.display.bpp,
            {msb: true}
          );
  g.clear = function(clearColor){    
    new Uint8Array(this.buffer).fill(clearColor);print(this);
  };
  g.flip = function(callback){     
	//this does not work
	_display.wCmd(_display.display.CMD.DATA_START_TRANSMISSION_1);
	_display.wData(this.buffer); 
    
	//this works
    //_display.wCmd(_display.display.CMD.DATA_START_TRANSMISSION_1);
    //for (let i=0;i<this.buffer.length;i++) _display.wData(this.buffer[i]);
     
    _display.waitBusy(callback);
  };
  return g;
};
IL91874.prototype.wCmd = function (command) {
  digitalWrite(this.dcPin, 0);
  this.spi.write(command, this.cs1Pin);  
};
IL91874.prototype.wData = function (data) {
 digitalWrite(this.dcPin, 1);
 this.spi.write(data, this.cs1Pin);
};

So what it does is, when flip is called, transmit the buffer data to the papers ram.

It is actually only a modification of the SSD1606 module code. In there the flip function it does exactly the same: transmit the buffer data via SPI as an Uint8Array (as I just learned, more a view to the buffer?).
Maybe that's the problem? I'm assuming that what works in the example code also would work in my case.

Otherwise I can only think of a problem in transmitting speed. I played around with the SPI baud rate (set it lower) but to no avail.

I mean, the code does work, but writing 2 buffers (one for red, one for black) takes about 3.5s each + the 15s update cycle of the paper. I think there is potential for speeding up things.

Hi,
while I am fiddling around with driving an epaper display with Espruino Wifi I'm still having issues with writing data. Just to be sure:

Is this:

var a=0x0;
for(let i = 0; i < _bufferSize; i++) SPI.write(a);

different from that?

var a=0x0;
SPI.write(new Uint8Array(_bufferSize).fill(a));

First one actually writes the RAM of the paper correctly and after update it will display correcty, but its slow (3.5s for 5800bytes).

Second one is fast, but seemingly doesn't update the RAM of the paper, because after update it still displays the same.

In the reference it says:

For maximum speeds, please pass either Strings or Typed Arrays as arguments.

Quick update: I got it to work. Turned out I did not explicitly set the CS (nss) pin while writing data.

If the last argument is a pin, it is taken to be the NSS pin

@navas I'm interested as well if you got it to work.

I'm having a GDEW027C44 2.7" 3-color e-ink display. It works fine with an Arduino Uno and the Arduino sample code.

I gutted the code to the bare minimum needed to make it refresh. Then I ported the code (its really only a few lines) to Espruino. No luck, the display doesn't change, it just keeps showing the same image.

I tested all hardware SPIs as well as software SPI. I tested it with a Espruino Wifi and a Pixl. I quadruple checked the wirings. Nothing.

The only thing I can imagine is that the 3.3v power supply isn't enough, though I is rated as an 3.3v display.

Ahh yes, that did it, thanks!
I was looking at the http.request reference and basically tried using the code there , which has no call to end.

Hi all,
I can for the life of me not get the http.request to work but the http.get works just fine. Please see the code I use below. The http.request just does nothing, seemingly the callbacks don't get fired at all.
I played around with all kind of different options, but none seem to work. I'm puzzled... once again.

var wifi = require("Wifi");
var WIFI_NAME = "xxxx";
var WIFI_OPTIONS = {
  password: "yyyyy"
};
var http = require("http");

function onInit() {
  print("connecting...");
  // Connect to WiFi
  wifi.connect(WIFI_NAME, WIFI_OPTIONS, err => {
  if (err !== null) {
    throw err;
  }
  // Print IP address
  wifi.getIP((err, info) => {
    if (err !== null) {
      throw err;
    }
    print("http://"+info.ip);
        
    //works
    simpleGet();
    
    //doesn't work
    requestGet();
    
  });
});
}

function simpleGet(){
  http.get("http://www.pur3.co.uk/hello.txt", function(res) {
  res.on('data', function(data) {
    console.log(data);
  });
});
}

function requestGet(){
  var options = {
    host: 'http://www.pur3.co.uk',
    protocol: 'http:',
    port: 80,
    path: '/',
    method: 'GET',
  };
  http.request(options, function(res) {
  res.on('data', function(data) {
    console.log(data);
  });
  res.on('close', function(data) {
    console.log("Connection closed");
  });
}); 
}

Thanks for the follow up!

I kinda realized JS is "dumb", but expected a behavior similar to other language and got frustrated.
Oh well, at least I learned something.

I'll try out the arrow functions.

@Raik, is the above code in one monolithic file, as the modules file, or is there a calling page?

It's the piece of code from the editor I upload to experiment with modules. Later on this will be put to the file system as one file (that's the plan).

It's possible that L21 needs to also pass 'freq' 'time' as arguments

Well it's referring to the beep function, that only has two argument. So it should work, right?

change this. to SOUND. in line 21.
or add ‘that’

Thanks for the hint: creating a new reference for this worked, though I'm not sure why?

Is it because the module code runs in its own scope? And this is not referring to SOUND but rather to the main scope?

When a module is loaded, Espruino executes the file in its own scope
(from Writing Modules)

Hey all, I'm trying to write my first module for the pixl and I'm having difficulties with setInterval in the modules function. I was closely following the writing modules page.

I use the code below to develop in the WebIDE. The beep function works fine, so does the second function that just calls the beep function. But then the third function involves calling beep from a setInterval. And that is not working.

What am I doing wrong?

var exports={};
var PIN;
var VOLUME;

function SOUND(pin,volume){
	this.PIN = pin;
	this.VOLUME = volume;
}

SOUND.prototype.beep = function(freq,time){
  analogWrite(this.PIN,this.VOLUME,{freq : freq});
  setTimeout(function(){analogWrite(this.PIN,0); },time);
  print("beep");
};

SOUND.prototype.multibeep_works_fine = function(freq,time,nr){
  this.beep(freq,time);  
};

SOUND.prototype.multibeep_works_not = function(freq,time,nr){
  setInterval(function(){ this.beep(freq,time); }, 1000);
};

exports.setup = function(pin,volume){
	return (new SOUND(pin,volume));
};

var s = exports.setup(A0,0.005);

//works
s.beep(1000,10);

//works
s.multibeep_works_fine(1000,100,1);

//does NOT work?
s.multibeep_works_not(1000,100,1);

Is there a reason you put save() at the end of the code you uploaded to flash?

Well, I didn't really think about it, but it is normal code that I would use to paste into the editor and then upload without having to type save() manually after the upload.

Not sure if maybe you could automatically replace/delete the save commands on pushing to RAM.

Just added as a 'play' button.

Awesome! But doesn't seem to work right. I just uploaded two clocks (code attached) both with a trailing save().
Upload to file system works fine. But then when I hit the play button for one clock it puts it to ram incompletely (pixlClk for example is missing the onInit() function, see screenshot.

Then when I use save() in the console, the pixlClk file suddenly disappears from the file system...?

EDIT: ok, maybe my mistake, I saw there is an function() onInit() instead of function onInit().

But new problem: I fixed the file, uploaded it. Then hit the play button on the file, now dump() shows this:

>dump()
function onSecond() {?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255]}
function onInit() {?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255] ?[255]}
=undefined
> 

You mean as if you clicked 'open file' then 'upload' in the IDE?

Well not exactly. I talking about already existing files on the device. Let's assume there are already two "apps" (clock 1 and clock 2) in the file system. Wouldn't it make sense to open the storage menu and click the file you want to load into the ram to be executed?

Otherwise you would have to download the file (takes time) and open the file (where did it put it?!) and then upload (takes time).

Sorry for bringing up an old topic, but it kinda fits:

I'm using a (fresh) CR2032 battery on my Pixl.
When I switch on the backlight it flickers when ever code is executed, i.e. clock updating etc.
It also flickers when typing in the WebIDE console.

Is this normal behaviour for running Pixl with a CR2032 or do I happen to have some minor quality batteries that can't provide the necessary power/voltage under load?

I just tested it with the Pixl, works too. Does it make sense to have another button to load the contents of a existing file (an app) directly to RAM? Would make switching between apps easier (at least on the Pixl).

@Gordon:
I know you reverse engineered several watches before deciding for that specific model. The same manufacturer also has watches with a round display. Is it feasible to assume that with the experiences gathered there could be Bangle.js ports to other models too? Or maybe another KS campaign?
Ooops, holding you off of the more important work... ;-)

Thanks all for the input. I see I have a lot to read and catch up. One final question for now: what does it take to implement a module for a new display type. If I understand correctly, it should support SPI. Would I need to develop a new module with the specs from some datasheet?

Specifically I am amazed by an ePaper display like that: https://eckstein-shop.de/Waveshare-27-inch-264x176-E-Ink-E-Paper-Raw-Display-three-color-Arduino

@allObjects It's indeed the small footprint including the display that intrigues me. But it would also be nice to query a internet service for data to display.

Oh, and the Pixl.js doesn't have enough memory for SSL/HTTPS, so you are limited to http. While the Espruino-Wifi has enough ram for https!

Well that's a stopper then.

If it is the display, there are other display that can be combined with Espruino-Wifi.

Can you give me a hint where to look for that? I'm just beginning to dive into the Espruino world! :)

@Bernd: Were you already successful?

I'm also thinking about getting the Pixel.js, but I really would like it to have wifi too. So in here https://shop.espruino.com/accessories/esp8266-esp01 it says:

Other boards such as the Espruino Original and Pixl.js do not contain powerful enough 3.3v voltage regulators to reliably power the ESP01, so while it can be added you'll need a separate 3.3v voltage regulator.

So what would I need to do? Replace the voltage regulator on the Pixel.js with another on? I really would like to have a small footprint wifi module on it instead of an extra shield.

Would be Pixel.js together with the above ESP8266 module fit in the acrylic case?

Would see reason being located in browser and/or OS

With that being said: would it still be possible to modify the emulator to run with the same speed as the actual watch? Maybe enabled by option?

This could be helpful to see if the code written in emulator would be efficiently running on the watch as well.