Avatar for Raik


Member since Dec 2019 • Last active Feb 2020
  • 5 conversations

Most recent activity

  • in General
    Avatar for Raik

    Sorry for the confusion:

    So to make it clear:
    1) WebIDE on my laptop works in the sense that it can load properly. BUT I can't connect because the built-in bluetooth in my laptop doesn't not support BLE and the BT dongle doesn't work.
    2) The WebIDE on my phone using Chrome works; I can connect to the Pixl, but it's not comfortable to work with
    3) But: the relay page that used to work before on my phone doesn't work either on my phone and my laptop (just shows this empty page)


    I had to play with Settings >> Add Device (and remove - (un)pair) many times also.

    Strange thing is: the dongle (it's a TP Link UB400) is working fine with my desktop PC. But I just found no way to get it to work on my old HP 8440p yet. I guess this is a problem with USB ports/chipset. The dongle is connected and Chrome shows it in the chrome://bluetooth-internals page and in there also finds the Pixl. But then in the WebIDE popup it finds nothing (doesn't even seem to begin to search)
    -> hence, I tried to use the relay that doesn't work :(

    As @MaBe found out I guess this is a real issue with the page itself

    at Object.addIcon (app.js:376)

    Maybe this related to the changes that @Gordon made to the WebIDE by adding the storage icon?

  • in General
    Avatar for Raik

    What is this link for?

    As @Robin pointed out with the link, its for relaying the IDE in case you don't have an working BLE adapter, just like my old laptop.

    Is this the link you are after?

    Well no, I'm trying to connect to my Pixl from my old laptop using my mobile phone with the relay page. I am pretty sure I already successfully tested this a while ago (maybe 2 months or so)

    The normal IDE works fine, but can't connect directly because my laptops bluetooth does not support LE and my BLE dongle is for some reason not recognised by Windows/Chrome

    EDIT: Btw: I can connect to the Pixl using the Chrome app on my phone with the WebIDE, but of course it's not really efficient to develop on it.

  • in General
    Avatar for Raik

    Hi there,

    is it possible that the relay on the WebIDE is broken?

    https://www.espruino.com/ide/relay only shows an "empty" page?

  • in ESP32
    Avatar for Raik

    Hi @navas,

    can you please share us the details ( if possible, with the code) ?

    I'd be happy to: https://github.com/ps-igel/EspruinoModul­es

    It's basically a modified version of die SSD1606 paper driver.

    I'm sure there is a lot of room for improvement, especially making the data transfer of the buffers to the epapers ram faster.

    Wiring as in the example:
    mosi -> A7, sck -> A5, cs -> A4, dc -> A0, busy -> A1, reset -> B0

    Feel free to play around and improve. :)

  • in Interfacing
    Avatar for Raik

    Yes, by a small amount. But, . . . isn't the data bit rate set by the setup of SPI? (yes)

    Setting the baud rate, doesn't seem to matter much.

    //byte by byte transfer
    data 1 took: 3.80794239044s @20000000 baud
    data 2 took: 3.80806064605s @20000000 baud
    data 1 took: 4.26346969604s @1000 baud
    data 2 took: 4.26357555389s @1000 baud
    data 1 took: 4.26337814331s @100 baud
    data 2 took: 4.26357364654s @100 baud
    data 1 took: 4.22884178161s @software SPI
    data 2 took: 4.22821426391s @software SPI
    //byte by byte without switching CS
    data 1 took: 3.53529644012s @20000000 baud
    data 2 took: 3.53545284271s @20000000 baud

    There is definitively switching overhead to the CS pin, as mentioned here.

    As the image in #16 is helpful here, has the use of an inexpensive logic analyzer been used?

    No. Didn't fiddle with that.

    What about SPI.send() vs SPI.write() ?

    Tested, works, but same speed

  • in Interfacing
    Avatar for Raik

    So, I think I found the culprit. I (again) had a look at the display driver specs and on page 16 it shows the cycle graph(?) for the 4-wire SPI interface, see attached image.

    Below the graph it says:

    CSB can be “H”between parameter/ command. And SCL, SDA, D/C are invalid
    during CSB=”H”

    That and the rising flank of the CSB signal after the 8 databits on the right, leads me to believe that CS needs to be pulled down and up again for every byte written.

    So I changed my write function like so:

    function wData(data) {
     digitalWrite(dcPin, 1);
     digitalWrite(csPin, 0);
    for (let i=0;i<bufferSize;i++) wData(buffer[i]);
     digitalWrite(csPin, 1);

    Now this does not work anymore, because CS only changes once right before all the data writing.

    Changed it back to:

    function wData(data) {
     digitalWrite(dcPin, 1);
     digitalWrite(csPin, 0);
     digitalWrite(csPin, 1);
    for (let i=0;i<bufferSize;i++) wData(buffer[i]); 

    immediately starts working.

    I assume that


    also pulls down csPin only once.

    So now the questions would be: would it be feasible to create a native SPI write function that pulls the cs(nss) pin down for every byte written and does that make sense?

    Would my case still benefit speedwise? Otherwise I would be stuck to my single bytes write algorithm and the speed bottleneck it causes.

    EDIT: Just stumbled across Espruinos capability of inline C code. I guess that could speed up the data transfer loop...?

  • in Interfacing
    Avatar for Raik

    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.

  • in Interfacing
    Avatar for Raik

    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