Most recent activity
-
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.
-
Hi there,
is it possible that the relay on the WebIDE is broken?
https://www.espruino.com/ide/relay only shows an "empty" page?
-
Hi @navas,
can you please share us the details ( if possible, with the code) ?
I'd be happy to: https://github.com/ps-igel/EspruinoModules
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 -> B0Feel free to play around and improve. :)
-
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 baudThere 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
-
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); _spi.write(data); } 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); _spi.write(data); digitalWrite(csPin, 1); } for (let i=0;i<bufferSize;i++) wData(buffer[i]);immediately starts working.
I assume that
_spi.write(data,csPin);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...?
-
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: 5808I 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 beDISPLAY_REFRESH:0x12
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)
@Robin
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
Maybe this related to the changes that @Gordon made to the WebIDE by adding the storage icon?