Most recent activity
-
Thanks, this made a huge difference and I now get ~4.5kB/s instead.
I wonder what the bottleneck is now, and if there's more tweaking that could be done.
-
I'm using a puck.js v2 + esp8266 (ESP-01) module on Serial1 to serve files stored on an SD-card.
While I understand that this will never be a super fast file transfer method, I wonder what kind of speed could be expected? I'm currently getting between 600-700 bytes/s, and increasing the UART speed from 115200->460800 didn't really make a difference so I suspect that the UART is not the bottleneck.
Example code:
var wifi; function mountSDCard() { SPI2.setup({mosi:D30, miso:D28, sck:D29, baud: 8000000}); E.connectSDCard(SPI2, D31); try { console.log(require("fs").readdirSync()); } catch(error){ console.log(error); } E.setFlags({unsyncFiles:1}) } function onInit() { Bluetooth.setConsole(true); mountSDCard(); Serial1.setup(460800, { rx: D1, tx : D2 }); setupWifi(); } function setupWifi() { var WIFI_NAME = "UseThisOneMom"; var WIFI_PASS = "asdf"; wifi = require("ESP8266WiFi_0v25").connect(Serial1, function(err) { if (err) throw err; console.log("Connecting to WiFi"); wifi.connect(WIFI_NAME, WIFI_PASS, function(err) { if (err) throw err; console.log("Connected"); // Now you can do something, like an HTTP request require("http").createServer(onPageRequest).listen(8080); }); }); } function onPageRequest(req, res) { var a = url.parse(req.url, true); var f = E.openFile(a.pathname, "r"); if (f !== undefined) { res.writeHead(200, {'Content-Type': 'text/plain'}); f.pipe(res); // streams the file to the HTTP response } else { res.writeHead(404, {'Content-Type': 'text/plain'}); res.end("404: Page "+a.pathname+" not found"); } } -
Just checking to update you on that moving to HW I2C made a huge difference. Getting approx 350kbit/s read speed when emptying the buffer now.
Again, thanks a lot for your help!
-
First, let me just thank you for being so helpful!
I'm using this to build, so it's a release build:
DFU_UPDATE_BUILD=1 BOARD=PUCKJS RELEASE=1 makeOh, I didn't realize it's using software I2C! Switching over to HW I2C should just be a matter of using the jshI2C* functions instead of jsi2c*, after initializing using jshI2CSetup(EV_I2C1,...) right? I still have much to learn here I see :)
-
Basically we want to be able to sample as fast as possible. Currently we can do 416 Hz with the built in IMU, if we try 833 Hz the FIFO will fill faster than we can empty it and will end up overflowing after just a short while.
-
And now the code is available on GitHub: https://github.com/erikboto/Espruino/tree/imu-fifo
-
I'm looking into getting the code online sooner rather than later, since the end goal is to see if the FIFO changed could be upstreamed.
In the meantime, here's the code snippet that empties the FIFO.
JsSysTime time3 = jshGetSystemTime(); // Read samplesToRead * 6 (3 words gyro + 3 words accel) * 2 (two bytes per word) bytes unsigned char fifo_read_addr[1]; fifo_read_addr[0] = 0x3e; jsi2cWrite(&i2cAccel, ACCEL_ADDR, 1, fifo_read_addr, false); jsi2cRead(&i2cAccel, ACCEL_ADDR, samplesToRead*6*2, (unsigned char *)dst, true); JsSysTime time4 = jshGetSystemTime();If I read e.g. 104 samples, so 1248 bytes of data, time4-time3 is approximately 150 ms. This seems like a lot slower then expected then, since it's only ~66kBits/s.
So I hooked up two USB-TTL converters and had a look at the traffic going to and from the ESP8266 and I have a few findings.
The network_js.c implementation limits the number of bytes sent on each AT command to ESP to 536 bytes, even though the AT command can take up to 2048 bytes of data for each command. This is probably for a good reason, since that code can be used for other transports then the ESP, but maybe it could be possible to tweak it if you know what transport that will be used.
The "ESP8266WiFi_0v25" module uses the AT+CIPSEND command for sending, which is a synchronous version that means that Espruino will say "I want to send X bytes", ESP: "OK", Espruino: "here's the data", ESP "Got that, and now I have sent it". Then the Espruino can send the next chunk of data. There's another command called AT+CIPSENDBUF that can be used to add data to the ESP:s send buffer, so that more data can be pushed in without waiting for all data to be sent. It's more complex to use since it requires you to make sure the buffer has space etc.
Just tweaking the chunksize so that 2048 bytes of data in sent in each AT+CIPSEND increases throughput to ~12kB/s, but in order to go above that I guess the logic needs to be rewritten to use AT+CIPSENDBUF instead so that the wifi connection have data to send at all times. I'll see if I have the possibility to make a working implementation of this.