pi_Pico limitations

1

What a great device supporting micro python promised a great future. Experience using the device has highlighted a couple of serious apparent limitations -

  1. Anyone can easily look at your code loaded onto the Pico, unlike Arduino.
  2. Programs work connected to your computer which has internet access however running on battery you cannot load elements like time to implement delays.

Now I would be happy to be corrected but searches to find time.sleep without internet have not found any work around. So I have a for loop which prints nul a thousand times to get some sort of delay.

1 Like
2

Hey Brian,

Great points, these are more limitations with the language itself. Micropython is an interpreted language where each line is/can be run in isolation. On the Pico there will be another program running through your .py file, interpreting each line, as you’ve run into it has its pitfalls but also some good bits. It allows for a REPL to run on-top, to test code and make changes on the fly.
There are ways that you can upload a compiled program to the Pico much like Arduino, RPi foundation discuss it over in their docs.

In regards to using delays I would look at the module ‘utime’ it’s catered specifically for microcontrollers. I’m unsure why time.sleep wouldn’t work though.

1 Like
3

Hey Brian,

Great observations! I’ve got a couple points to add on

  1. My understanding is that you can compile C++ code into a uf2 file no-one can poke around in. I’ve compiled the 3D printer firmware Klipper to a .uf2 file with gcc, and copied that onto the Pico just fine. It’s also worth considering that the Pico is primarily for education, and MicroPython brings the coding closer to english and a lot easier to grasp. Industrial/commercial solutions, if they used the RP2040, would likely use C++ and possibly a custom board that uses the RP2040 chip.
  2. As Liam said (he snuck in his post a little sooner) time. sleep should work… :thinking:

Keen to hear the results of your future experimentation!
-James

4

Hey Brian,

Just throwing in my 2c here too :grin: if you’re looking to hide your code, I suggest looking into a Python obsfuscation tool, they’re often used even against compiled binaries to make it much much more difficult for your code to be reverse engineered (yet alone read :sweat_smile:)

2 Likes
5

Thanks Liam, James and Bryce.
I was hoping there were solutions.
Now I have some work to do.
Will let you know the results.
The background of this is I am making a movement alarm for my ebike.
Like many makers, I dream of commercializing hence the code issue.
I will look at ‘utime’.
PS I started programming in Borland Turbo Pascal (probably before most of you were born) hence enjoying the similar high level Python.

2 Likes
6

I looked at utime but again it needs to be loaded on startup. As the pico may have to be started out on the road, that isn’t possible.
Here is my crude work around for the delay by calling this function -

def sleepProc(sleepCount): # approx 3000 per second
    loopCount = 0
    for loopCount in range(sleepCount):
        #print("")
        throwVar = 10
        throwVar = throwVar * 100
        if throwVar > 1000:
            throwVar = throwVar / 10
        throwGPIO.value(1)
        throwGPIO.value(0)
        some_result = None
        if some_result:
            print("Got a result!")

It equates to a call of sleepProc(30000) to delay for a second.
having a print in the procedure is cleaner but stops my print when connected to the computer (RPi4) to tell me where the program is at. Anyone with something tidier, I’m all ears.

3 Likes
7

Thanks Bryce. That looks like the solution I can use.
I also retired loading time when not connected and it worked fine. So I have gotten rid my messy delay :slight_smile:

2 Likes