In part 1 of this series, I added WiFi connectivity to the Pi Pico using an ESP32 moduleand MicroPython. Part 2 showed how Direct Memory Access (DMA) can be used to get analog samples at regular intervals from the Pico on-board Analog Digital Converter (ADC).
I’m now combining these two techniques with some HTML and Javascript code to create a Web display in a browser, but since this code will be quite complicated, first I’ll sort out how the data is fetched from the Pico Web server.
Data request
The oscilloscope display will require user controls to alter the sample rate, number of samples, and any other settings we’d like to change. These values must be sent to the Web server, along with a filename that will trigger the acquisition. To fetch 1000 samples at 10000 samples per second, the request received by the server might look like:
GET /capture.csv?nsamples=1000&xrate=10000
If you avoid any fancy characters, the Python code in the server that extracts the filename and parameters isn’t at all complicated:
ADC_SAMPLES, ADC_RATE = 20, 100000
parameters = {"nsamples":ADC_SAMPLES, "xrate":ADC_RATE}
# Get HTTP request, extract filename and parameters
req = esp.get_http_request()
if req:
line = req.split("\r")[0]
fname = get_fname_params(line, parameters)
# Get filename & parameters from HTML request
def get_fname_params(line, params):
fname = ""
parts = line.split()
if len(parts) > 1:
p = parts[1].partition('?')
fname = p[0]
query = p[2].split('&')
for param in query:
p = param.split('=')
if len(p) > 1:
if p[0] in params:
try:
params[p[0]] = int(p[1])
except:
pass
return fname
The default parameter names & values are stored in a dictionary, and when the URL is decoded, and names that match those in the dictionary will have their values updated. Then the data is fetched using the parameter values, and returned in the form of a comma-delimited (CSV) file:
if CAPTURE_CSV in fname:
vals = adc_capture()
esp.put_http_text(vals, "text/csv", esp32.DISABLE_CACHE)
The name ‘comma-delimited’ is a bit of a misnomer in this case, we just with the given number of lines, with one floating-point voltage value per line.
Requesting the data
Before diving into the complexities of graphical display and Javascript, it is worth creating a simple Web page to fetch this data.
The standard way of specifying parameters with a file request is to define a ‘form’ that will be submitted to the server. The parameter values can be constrained using ‘select’, to avoid the user entering incompatible numbers:
<html><!DOCTYPE html><html lang="en">
<head><meta charset="utf-8"/></head><body>
<form action="/capture.csv">
<label for="nsamples">Number of samples</label>
<select name="nsamples" id="nsamples">
<option value=100>100</option>
<option value=200>200</option>
<option value=500>500</option>
<option value=1000>1000</option>
</select>
<label for="xrate">Sample rate</label>
<select name="xrate" id="xrate">
<option value=1000>1000</option>
<option value=2000>2000</option>
<option value=5000>5000</option>
<option value=10000>10000</option>
</select>
<input type="submit" value="Submit">
</form>
</body></html>
This generates a very simple display on the browser:
On submitting the form, we get back a raw list of values:
Since the file we have requested is pure CSV data, that is all we get; the controls have vanished, and we’ll have to press the browser ‘back’ button if we want to retry the transaction. This is quite unsatisfactory, and to improve it there are various techniques, for example using a template system to always add the controls at the top of the data. However, we also want the browser to display the data graphically, which means a sizeable amount of Javascript, so we might as well switch to a full-blown AJAX implementation, as mentioned in the first part.
AJAX
To recap, AJAX originally stood for ‘Asynchronous JavaScript and XML’, where the Javascript on the browser would request an XML file from the server, then display data within that file on the browser screen. However, there is no necessity that the file must be XML; for simple unstructured data, CSV is adequate.
The HTML page is similar to the previous one, the main changes are that we have specified a button that’ll call a Javascript function when clicked, and there is a defined area to display the response data; this is tagged as ‘preformatted’ so the text will be displayed in a plain monospaced style.
<form id="captureForm">
<label for="nsamples">Number of samples</label>
<select name="nsamples" id="nsamples">
<option value=100>100</option>
<option value=200>200</option>
<option value=500>500</option>
<option value=1000>1000</option>
</select>
<label for="xrate">Sample rate</label>
<select name="xrate" id="xrate">
<option value=1000>1000</option>
<option value=2000>2000</option>
<option value=5000>5000</option>
<option value=10000>10000</option>
</select>
<button onclick="doSubmit(event)">Submit</button>
</form>
<pre><p id="responseText"></p></pre>
The button calls the Javascript function ‘doSubmit’ when clicked, with the click event as an argument. As this button is in a form, by default the browser would attempt to re-fetch the current document using the form data, so we need to block this behaviour and substitute the action we want, which is to wait until the response is obtained, and display it in the area we have allocated. This is ‘asynchronous’ (using a callback function) so that the browser doesn’t stall waiting for the response.
function doSubmit() {
// Eliminate default action for button click
// (only necessary if button is in a form)
event.preventDefault();
// Create request
var req = new XMLHttpRequest();
// Define action when response received
req.addEventListener( "load", function(event) {
document.getElementById("responseText").innerHTML = event.target.responseText;
} );
// Create FormData from the form
var formdata = new FormData(document.getElementById("captureForm"));
// Collect form data and add to request
var params = [];
for (var entry of formdata.entries()) {
params.push(entry[0] + '=' + entry[1]);
}
req.open( "GET", "/capture.csv?" + encodeURI(params.join("&")));
req.send();
}
The resulting request sent by the browser looks something like:
GET /capture.csv?nsamples=100&xrate=1000
This is created by looping through the items in the form, and adding them to the base filename. When doing this, there is a limited range of characters we can use, in order not to wreck the HTTP request syntax. I have used the ‘encodeURI’ function to encode any of these unusable characters; this isn’t necessary with simple parameters that are just alphanumeric values, but if I’d included a parameter with free-form text, this would be needed. For example, if one parameter was a page title that might include spaces, then the title “Test page” would be encoded as
GET /capture.csv?nsamples=100&xrate=1000&title=Test%20page
You may wonder why I am looping though the form entries, when in theory they can just be attached to the HTTP request in one step:
// Insert form data into request - doesn't work!
req.open("GET", "/capture.csv");
req.send(formdata);
I haven’t been able to get this method to work; I think the problem is due to the way the browser adapts the request if a form is included, but in the end it isn’t difficult to iterate over the form entries and add them directly to the request.
The resulting browser display is a minor improvement over the previous version, in that it isn’t necessary to use the ‘back’ button to re-fetch the data, but still isn’t very pretty.
Graphical display
There many ways to display graphic content within a browser. The first decision is whether to use vector graphics, or a bitmap; I prefer the former, since it allows the display to be resized without the lines becoming jagged.
There is a vector graphics language for browsers, namely Scalable Vector Graphics (SVG) and I have experimented with this, but find it easier to use Javascript commands to directly draw on a specific area of the screen, known as an ‘HTML canvas’, that is defined within the HTML page:
<div><canvas id="canvas1"></canvas></div>
To draw on this, we create a ‘2D context’ in Javascript:
var ctx1 = document.getElementById("canvas1").getContext("2d");
We can now use commands such as ‘moveto’ and ‘lineto’ to draw on this context; a useful first exercise is to draw a grid across the display.
var ctx1, xdivisions=10, ydivisions=10, winxpad=10, winypad=30;
var grid_bg="#d8e8d8", grid_fg="#40f040";
window.addEventListener("load", function() {
ctx1 = document.getElementById("canvas1").getContext("2d");
resize();
window.addEventListener('resize', resize, false);
} );
// Draw grid
function drawGrid(ctx) {
var w=ctx.canvas.clientWidth, h=ctx.canvas.clientHeight;
var dw = w/xdivisions, dh=h/ydivisions;
ctx.fillStyle = grid_bg;
ctx.fillRect(0, 0, w, h);
ctx.lineWidth = 1;
ctx.strokeStyle = grid_fg;
ctx.strokeRect(0, 1, w-1, h-1);
ctx.beginPath();
for (var n=0; n<xdivisions; n++) {
var x = n*dw;
ctx.moveTo(x, 0);
ctx.lineTo(x, h);
}
for (var n=0; n<ydivisions; n++) {
var y = n*dh;
ctx.moveTo(0, y);
ctx.lineTo(w, y);
}
ctx.stroke();
}
// Respond to window being resized
function resize() {
ctx1.canvas.width = window.innerWidth - winxpad*2;
ctx1.canvas.height = window.innerHeight - winypad*2;
drawGrid(ctx1);
}
I’ve included a function that resizes the canvas to fit within the window, which is particularly convenient when getting a screen-grab for inclusion in a blog post:
All that remains is to issue a request, wait for the response callback, and plot the CSV data onto the canvas.
var running=false, capfile="/capture.csv"
// Do a single capture (display is done by callback)
function capture() {
var req = new XMLHttpRequest();
req.addEventListener( "load", display);
var params = formParams()
req.open( "GET", capfile + "?" + encodeURI(params.join("&")));
req.send();
}
// Display data (from callback event)
function display(event) {
drawGrid(ctx1);
plotData(ctx1, event.target.responseText);
if (running) {
window.requestAnimationFrame(capture);
}
}
// Get form parameters
function formParams() {
var formdata = new FormData(document.getElementById("captureForm"));
var params = [];
for (var entry of formdata.entries()) {
params.push(entry[0]+ '=' + entry[1]);
}
return params;
}
A handy feature is to have the display auto-update when the current data has been displayed; I’ve done this by using requestAnimationFrame to trigger another capture cycle, if the global ‘running’ variable is set. Then we just need some buttons to control this feature:
<button id="single" onclick="doSingle()">Single</button>
<button id="run" onclick="doRun()">Run</button>
// Handle 'single' button press
function doSingle() {
event.preventDefault();
running = false;
capture();
}
// Handle 'run' button press
function doRun() {
event.preventDefault();
running = !running;
capture();
}
The end result won’t win any prizes for style or speed, but it does serve as a useful basis for acquiring & displaying data in a Web browser.
You’ll see that the controls have been rearranged slightly, and I’ve also added a ‘simulate’ checkbox; this invokes MicroPython code in the Pico Web server that doesn’t use the ADC; instead it uses the CORDIC algorithm to incrementally generate sine & cosine values, which are multiplied, with some random noise added:
# Simulate ADC samples: sine wave plus noise
def adc_sim():
nsamp = parameters["nsamples"]
buff = array.array('f', (0 for _ in range(nsamp)))
f, s, c = nsamp/20.0, 1.0, 0.0
for n in range(0, nsamp):
s += c / f
c -= s / f
val = ((s + 1) * (c + 1)) + random.randint(0, 100) / 300.0
buff[n] = val
return "\r\n".join([("%1.3f" % val) for val in buff])
Running the code
If you haven’t done so before, I suggest you run the code given in the first and second parts, to check the hardware is OK.
Load rp_devices.py and rp_esp32.py onto the Micropython filesystem, not forgetting to modify the network name (SSID) and password at the top of that file. Then load the HTML files rpscope_capture, rpscope_ajax and rpscope_display, and run the MicroPython server rp_adc_server.py using Thonny. The files are on Github here.
You should then be able to display the pages as shown above, using the IP address that is displayed on the Thonny console; I’ve used 10.1.1.11 in the examples above.
When experimenting with alternative Web pages, I found it useful to run a Web server on my PC, as this allows a much faster development process. There are many ways to do this, the simplest is probably to use the server that is included as standard in Python 3:
python -m http.server 8000
This makes the server available on port 8000. If the Web browser is running on the same PC as the server, use the ‘localhost’ address in the browser, e.g.
http://127.0.0.1:8000/rpscope_display.html
This assumes the HTML file is in the same directory that you used to invoke the Web server. If you also include a CSV file named ‘capture.csv’, then it will be displayed as if the data came from the Pico server.
However, there is one major problem with this approach: the CSV file will be cached by the browser, so if you change the file, the display won’t change. This isn’t a problem on the Pico Web server, as it adds do-not-cache headers in the HTTP response. The standard Python Web server doesn’t do that, so will use the cached data, even after the file has changed.
One other issue is worthy of mention; in my setup, the ESP32 network interface sometimes locks up after it has transferred a significant amount of data, which means the Web server becomes unresponsive. This isn’t an issue with the MicroPython code, since the ESP32 doesn’t respond to pings when it is in this state. I’m using ESP32 Nina firmware v 1.7.3; hopefully, by the time you read this, there is an update that fixes the problem.
Copyright (c) Jeremy P Bentham 2021. Please credit this blog if you use the information or software in it.
Lean2 