Lorenez Clock

For how complicated the mathematics are describing this particular set of differential equations, the MicroPython code to numerically solve the ODE is quite simple.

https://en.wikipedia.org/wiki/Lorenz_system

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

RE: RPI Pico & ST7789 Display

Poster

Upload Preview

Ok

Cancel

from machine import Pin, SPI, mem32
import time
import random
import math
from ulab import numpy as np
from random import random as randf
from breakout_colourlcd240x240 import BreakoutColourLCD240x240
np.set_printoptions(threshold=1000)

rst = Pin(13,Pin.OUT)
rst.value(1)

width = BreakoutColourLCD240x240.WIDTH
height = BreakoutColourLCD240x240.HEIGHT

display_buffer = bytearray(width * height * 2)  # 2-bytes per pixel (RGB565)
display = BreakoutColourLCD240x240(display_buffer)
display.set_pen(255, 255, 255)  # Set pen to white
display.clear()           # Fill the screen with the colour
mem32[0x4003c000] = 0x007 # Configure SPI0 CLKFREQ for Fsys/2

# From CPython Lib/colorsys.py
def hsv_to_rgb(h, s, v):
    if s == 0.0:
        return v, v, v
    i = int(h * 6.0)
    f = (h * 6.0) - i
    p = v * (1.0 - s)
    q = v * (1.0 - s * f)
    t = v * (1.0 - s * (1.0 - f))
    i = i % 6
    if i == 0:
        return v, t, p
    if i == 1:
        return q, v, p
    if i == 2:
        return p, v, t
    if i == 3:
        return p, q, v
    if i == 4:
        return t, p, v
    if i == 5:
        return v, p, q

# Lorenz State Model from Wikipedia
# https://en.wikipedia.org/wiki/Lorenz_system#Python_simulation
rho = 28.0
sigma = 10.0
beta = 8.0 / 3.0

def f(state, t):
    x, y, z = state  # Unpack the state vector
    return np.array([sigma * (y - x), x * (rho - z) - y, x * y - beta * z])  # Derivatives

state0 = np.array([1.0, 1.0, 1.0])
state = state0

display.set_pen(0, 0, 0)  # Set pen to black
display.clear()           # Fill the screen with the colour

xo = 120
yo = 40
tscreen = time.time() # time of last screen clear
h=0 # hue angle
while True:
    h += 1
    r, g, b = [int(255 * c) for c in hsv_to_rgb(h / 360.0, 1.0, 1.0)] 
    display.set_pen(r, g, b)  # Set pen to a converted HSV value
    
    for i in range(10):
        state = state + f(state,0)/1e3
        
    display.circle(int(xo+4*state[0]),int(yo+4*state[2]),1)
        
    display.set_pen(0, 0, 0)
    display.rectangle(50,0,200,50)
    display.set_pen(255, 255, 255)
    tm = time.localtime()
    display.text("{:02d}:{:02d}:{:02d}".format(tm[3],tm[4],tm[5]), 35, 0, 240, 5)  # Display Time
    display.text('Scottie',160,225,240,2)
    display.update()          # Update the display
    
    # clear screen every 2 minutes
    if time.time() - tscreen > 120:
        tscreen = time.time()
        display.set_pen(0, 0, 0)
        display.clear()

I might look into implementing an actual ODE solver, but for now the solution it creates appear quite elegant (regardless if they may not be accurate).

Still kind of amazed how simple that was to implement when using the demo examples as a starting point.

This might be a project that deserves a real enclosure.

Nice project, and actually an excellent example showing the power of Python versus (say) C. It's so much easier to do all the maths algorithms in Python. Sure it won't run as fast as optimised C code, but efficiency of personal time use getting projects out of the door, or the ability to rapidly modify algorithms, may be more important than raw performance during execution.

I wonder, has anyone implemented a pocket calculator or pocket computer with Pi Pico yet? I'd have thought that was a project screaming out for someone to implement.

Thank you for the kind words. I'm not sure if anyone has but together a pico calculator yet, with python it would be easy to support complex expressions. I have considered playing around with with a making a keypad layout for technical individuals not accountants. I still use my pocket scientific calculator all the time. Recently with micropython I have found myself holding a scope probe in one hand (or multimeter probe) and trying type with the other. I wish my keyboard keypad was had some of the same keys as my scientific calculator.

From what I gather making a USB HID device is supposed to be simple with the Pico. Though, I have yet to try it myself.

Thank you for the kind words. I'm not sure if anyone has but together a pico calculator yet, with python it would be easy to support complex expressions. I have considered playing around with with a making a keypad layout for technical individuals not accountants. I still use my pocket scientific calculator all the time. Recently with micropython I have found myself holding a scope probe in one hand (or multimeter probe) and trying type with the other. I wish my keyboard keypad was had some of the same keys as my scientific calculator.

From what I gather making a USB HID device is supposed to be simple with the Pico. Though, I have yet to try it myself.

I learned a major problem with CircuitPython today; it is single-precision! I was hitting all manner of problems trying to do PLL configurations, and eventually realized it was due to that : ( I've not found out about MicroPython, but if it supports double precision on the Pico then I'm swapping over immediately : ) I've already hit two bugs with CircuitPython, one each on two separate releases, so CircuitPython is not giving me stability confidence either : ( originally I thought a benefit of CircuitPython would have been the vast amount of libraries, but of the few I tried, they all had limitations so I had to write my own code in place of the libraries : (

I ran into the single-precision issue with CircuitPython also.  MicroPython can do double-precision floating and multi-precision integer but I haven't tried it yet: Maximum and minimum int and float values? - MicroPython Forum.  It can also do interrupts of some sort if I remember correctly and has experimental threads that haven't been implemented.

I suppose it is still early days for embedded python. I would have hoped ulab may would have supported 64 bit soft floats, but does not appear that way just yet. For a small number of calculations would working with a numpy datatype would be okay. Hopefully this is something they will add.

I have had other floating point woes on the PICO with regarding execution time. I wasn't getting anywhere near the avg cycle times stated in the datasheet:

But I made up the difference converting my ADC integer arrays to floating point arrays using a lookup table, there is lots of memory to spare. A floating point lookup table of 256 elements is only 1 KB.

Though you do appear to get 64-bit integers:

I'm finding it unacceptable to not have double precision hehe. I had some luck today compiling MicroPython, and put a couple of Pi Pico double-precision MicroPython binaries here.

I'm just typing up the procedure, so anyone can build them at any time, however the ones at that location are up-to-date (one is version 1.17 release code, and the other is the latest code in GitHub).

That is really helpful. I suppose that means there would no longer be singles? When I think about it, one probably wouldn't notice the performance difference compared to the python overhead.

Hi Scott,

This is true, processing time for the rest of Python will be quite large anyway, so it may not be very noticeable as you say. I'm still a Python beginner so I may have missed it, but I've not found so far if the type can be forced to be single-precision like (say) C.