Please give a big welcome to Walter, who is coming from the Netherlands for an introduction
to MicroPython.
Well, hello everyone, take your seats, few more people.
I cringe at every extra person who walks in, because it's an extra hundred watts of heating.
It's already quite hot here.
OK, it can start, I think.
OK, that's me, and that's a Python subject for today.
I welcome questions.
If anyone wants to ask something while I'm talking, please raise your hand and we'll get a microphone.
And if that takes too much time, I just skip subjects.
Interaction is always nice.
OK, I'm Baud van Olje.
I did informatics, the technical version, but it didn't just exist.
I worked in industry for quite a long time.
I still have a web shop and sell things like these stuff.
I worked at Hoogschoo Utrecht and for a year at Avants to teach technical informatics, of course,
and now I'm employed by a company who does robotics in industry.
But this is about MicroPython.
First context, I guess you all know what a microprocessor is.
Way back when they first made a single processor on one chip.
It was a very feeble, small thing, and since then we have progressed a lot.
Now we can pack a lot of power in one chip, but that's still a processor.
It cannot do anything on itself.
It needs external stuff like memory, I.O., hard disk to store things permanently,
probably a lot of cooling like we all do here.
That's one way to use what we can put in a chip.
The other route is don't make necessarily the processor much powerful,
but put more things on a single chip.
More RAM, Flash ROM to store code,
peripherals to do things with the outside world,
and then you have a microcontroller.
Everything in one chip and, well, that's a nice thing not to run your windows on,
but to think of things in the real world,
with motors, LEDs, relays, and all kind of stuff.
That is if you can still buy them.
Maybe that will be solved in the near future
when ASML produces more chip machines.
Compilers and interpreters.
You know, an interpreter looks at source code,
writes a line by line, sees what's there, does it,
and then it looks at the next line and does it again.
That's not very quick, but there is no extra steps involved,
so when you change your source code, it immediately has effect.
And when you interact, you interact in its way with that interpreter.
Compiler takes source code, translated to native machine code,
and that is the thing that runs.
When you interact, when you're interacting with a program,
you interact with the running native code.
All clear?
Yeah, I used to be a lecturer, so I'll ask everyone clear.
And then, of course, no one raised a finger.
It's not clear to me.
Things cannot be that simple,
so there's combos of compile interpreter.
That's actually how Python generally works.
You have a source code.
You have a compiler that translates that source code
to an intermediate representation,
and then you have an interpreter that interprets that intermediate code.
Now, you have either the best of both worlds or the worst.
I don't know.
This takes some time, but less than real compilation,
and this is slower than real running native code,
but it's still somewhat faster than directly interpreting the source code.
Still clear?
Yeah.
Okay.
Python typically runs interpreted, which has benefits,
and this is fun with this, but we'll come by that.
What's Python's place in the larger world of things?
And there are program language, I think,
you can recognize the symbols that make it easy to change your code,
to run it quickly, to tinker with it, to try things.
That's the one end of the spectrum.
There's the other side of the spectrum.
When you write high-performance codes like operating systems,
graphical tools, games, and things like that,
those languages are much less forgiving in what you do.
It takes a lot of time to compile it correctly,
but then they filter out a lot more errors
than those type of languages do,
especially Vitorius for that.
And somewhere in between, under compromises,
that's generally used for not too high-performance,
but really reasonably performance,
user interaction thing, websites, simple graphical applications.
That's the whole scheme of things.
And traditionally, microcontrollers, these kind of things,
were programmed with these kind of languages
because they simply didn't have the resources,
the speed of the processor, size of the RAM, size of the flash,
they just didn't have the resources,
and they just didn't have the resources to run
with these kind of languages.
What really distinguishes the language
is whether you are runtime-typed.
In Python, when you have a variable,
the runtime system has no idea
whether it's a string or an integer or a list or whatever.
It will find out runtime.
In strongly-typed languages, that's fixed.
It's flexible for you.
Easier on that processor.
It compiles to, well, the left side compiles
some intermediate languages.
Some of them are even really source interpreted.
Right-side languages are compiled to mostly machine language.
And memory management, an important one.
In Python, you rarely wonder about where your memory is,
what memory is used, the runtime system solves it.
In, well, C and C++, you have to worry a lot
about which memory you claimed, what you released,
don't release it too early,
or you'll get a nice crash or something else.
And in between, well, you take some care of it,
maybe give some hints to the runtime system,
but in general, you don't bother too much with it.
So left side, ease of programming, right side, quick running.
That's how traditional C Python works.
You have your source.
You translate it to an intermediate language representation.
That is runs.
And that's all done by your Python system you install.
That's both compiler and interpreter.
Wow, this is a lot more complex.
This is my Python.
You still have a Python system,
but now it no longer runs on your quick-fast desktop.
It runs on a small mic controller.
Both the compiler and interpreter run on the mic controller.
And when your Python application runs,
you interact with that mic controller.
You still have your laptop because you do the editing.
I don't have an editor running on this thing,
so that's still the desktop.
I use Tony, it's a simple Python application,
but it's quite useful to interact with Michael Python.
So I interact with Tony.
I edit my code there.
It's sent or stored or kept on the mic controller itself.
There it is compiled and runs.
And then it runs here and hopefully does nice things with the outside world.
Still clear?
Nothing new, nice.
On the mic controller,
let's say standard, read, evaluate,
what is it, print loop,
so you can do things just like you did on the prompt
on the Python on your normal computer.
And it evaluates what you do, prints it,
and it can do more interesting things like linking leads
or reading files that are stored on the chip.
I think we should just show,
because it's too...
Okay, here I have a Raspberry Pico,
RP2040 chip,
when I plug it in
and I press the boot button,
it goes into load mode.
You can hear a very faint bleep for my laptop.
And when I now look at,
well, my explorer,
I see an extra drive here
that's the drive he created,
and I can copy...
Here's the FOSDM image.
I copy my Python image to that drive.
It copies it.
When it's done, it reboots.
Now the extra drive is gone,
and I can see...
Oh, I have to put it first.
Right.
There's an extra communication port here.
That's what the chip made.
I always rename my communication ports to 42,
because...
Okay.
Just replete it to be sure.
Now let's start.
Tony.
Okay.
Now here I have a prompt
that is running on that small chipie.
And just like a good Python,
it can print,
hello.
Doesn't seem like much,
but that's happening here.
It's not my laptop that's doing it.
And if you're a bit lazy
and you don't want to fiddle with files,
you can also boot again.
Here in Tony,
you can select under options interpreter.
I want to install Michael Python,
and for the Raspberry Pi Pico,
it just knows where to find it.
Internet is working.
It just grabbed the latest version, installed it.
Close.
And I have it running.
Yep, it runs.
Nice.
Okay.
Now I must do something.
Let's take some code.
I can put code simply in the editor and say run this.
No.
Are you able to make it larger, please?
I think that's the wrong direction.
Largely enough for you.
And, well, it didn't show that the LED was not on,
but now it's on, so it worked.
No, well, maybe I can convince you if I put a zero here
and then run it again.
Ah, let's off.
You can all see that?
Well, just on is not that interesting.
Let's blink.
Blink is simple.
Define the pin.
I import the libraries that are standard for this chip,
and it allows me to access a pin.
Pin 25 happens to be the onboard LED.
I say it's an output pin.
Then I make it high, sleep a little time,
make it low, sleep a little time,
and repeat it forever.
Okay.
That should blink.
Ah, it blinks.
Oh, nice.
Don't applaud for any day more,
otherwise your hands will get sore.
Okay, but now when I stop it, it stops,
and this thing doesn't do anything.
It should stop, it doesn't.
Well, there's always the reboot for that.
It's supposed to be interruptible by that stop button,
but since a week it doesn't do anything.
I don't know why.
If I want to do the chip do something on itself,
I have to store this file on the chip.
So I make the blink.py on the chip.
Now it's here, and I can run it from there.
Yeah, it still blinks.
That's not very interesting.
Now, if I stop it and put it on a power bank,
it doesn't do anything.
That's a pity.
When it starts, it looks for a main.py
and exudes that file.
So if I wanted to start, I have to make a file.
Import, blink, save that as main.py.
Ah, it's a mess.
Well, this irritating, there is a small file system here.
I can make a new file directly delete,
but I cannot rename a file.
So let's do the poor man's way of doing that.
Save as main, not neon.
Now I can delete that one.
Yeah, nice.
Main, yeah?
I deleted the correct one.
And that's the important thing.
So now, if I put it on a power bank,
it starts blinking on its own.
But now, at least that's what happened yesterday.
One is thought to hold it again now.
It doesn't want to.
I cannot get into it anymore.
It's bricked.
But okay, I can still reload.
But if I reload the micropyton interpreter again,
it keeps the file system, so it keeps the main.py,
so it doesn't work.
So some clever guy made a flash nuke.
I'm going to put that there.
It reboots with that code.
Now it's nothing.
And if I now reboot it,
I can put the normal code on it again.
Where it is.
Force the pickle images.
Okay, put it one over there.
It's just USB transfer, it's quite quick.
And now I have a normal behaving.
Yeah.
Okay, that behaves again.
Nice.
The name's real port.
You've seen Blinky.
You've seen the startup.
Demo of the startup, okay.
I was going to demonstrate blinking a LED on the breadboard,
but it's too feeble to bring here,
so let's blink more LEDs.
More is better.
Okay.
Now you know why I put all the things on the table,
so I have the correct order of driving everything.
What's on here?
I did it.
I want that one.
I can blink a single LED.
Oh, it should.
Now I use a library I wrote,
and it's loading all those library files.
It takes some time.
After that, yeah, it really blinks.
I'll come back to that later.
And this one, if I'm a bit insistent,
it will probably stop.
Yeah, there it is again.
We can also have more LEDs.
I've made a system that, whatever target ship I use,
it has eight pins that are connected here,
so we can swap it for another board.
There's a whole different processor,
and it still has the same eight pins.
That's the edge library,
and edge.port is those eight pins
gathered together in one port,
and then I give it to the kit demo,
and then it should first load everything.
And then it's kits.
Okay, kits on eight LEDs.
If that's not enough,
you take an I2C extender chip,
and the chip...
Does it work?
Yes, it works.
And it has more output pins.
Load, load, load, load.
And then have a kit with 16 ports,
and if that's too slow,
I think it's boringly slow.
Maybe 10 milliseconds is nice.
Load, load, load, load, load.
Yeah, that's a bit quicker.
Okay, back to the sheets.
On morelets, we have seen morelets.
Okay, you saw that it spent some time
at the beginning by loading a few libraries.
It showed, because I coded it that way,
because I wanted to know how long it takes
to load the libraries and how much RAM it uses.
In general, you can have three ways
of putting library code on MicroPython.
You can have the source files,
the simple.py files,
and then when you load them,
they're first compiled and then loaded.
You can also pre-compile those files on your laptop
and then load the compiled version,
that's the.mpi files.
You can also take the files
and build them into the image you load anyway.
You saw me copying that image onto the chip.
You can put your files in there.
And that has effect for how much time it takes.
When I demoed it, it was irritatingly long.
My files took about 12 seconds to get loaded
from the flash compiled and ready for run.
When I pre-compiled, it's a little bit faster.
And when I freeze it,
I build an image of MicroPython with those files included,
it gets really fast.
And then it also uses less RAM.
RAM, memory on those chips,
is always a very scarce resource.
This chip has about, I think,
130K left after loading this library.
Looks like a lot, but you can eat it quickly,
especially if you make screen buffers for LCDs and things like that.
240 by 320 LCD with full color, that's 2 bytes per color.
I think that's more than is left there.
So you couldn't still use it.
So it's very important to conserve that.
When I develop things,
I simply take a very fast target.
A TNG is maybe 10 times faster than a PyPico,
and it has, I think, one megabyte memory.
So that's ample.
But there's always the but, but it comes later.
Okay, embedding your code into MicroPython image
is not that complex.
I had it running on my Linux machine in maybe an hour.
Then I tried the same recipe on Windows and it fails.
So when it happens, what do you do?
You make a Docker container.
So I made the Docker container on the Linux machine
that does exactly the same thing, worked.
Then I run it on Windows, works too.
It's fine.
And I can show if I take this chipy here.
There it is. If I import my library, it's...
Okay, you can do it.
There's a license statement, a lot of text.
Okay, here I have that license statement in the source.
Let's add this is FOSDEM.
FOSDEM?
Whatever.
Okay, start the Docker container.
Internet works, otherwise it doesn't do it.
It takes some 40 to 400 seconds.
I cannot predict how long.
Of course, it's Docker, so all the preparations,
loading the Linux image, loading all the development tools,
that's cached.
But then after it, it takes my library code
and then it compiles the MicroPython system
with that library code added, and that takes some time.
Okay, it's running now.
Well, didn't take that long.
So what do I do now?
I reboot my chip again and now take the new code.
This is the new code.
Copy that to the boot.
Okay, let's see what we have here.
Now you no longer see the library files there
because they're not present on the internal file system.
They're built into the MicroPython interpreter.
But I can still...
Oops, it's a bit faster now than it used to be.
Now the license text is expanded, so I really have put
the changed version of the library in there.
Okay, let's go on.
I showed freezing code.
I still want more LEDs.
Not enough.
Why is more LEDs?
I think this is enough.
Okay, that needs more power.
I cannot power it off the USB port of my laptop,
so I need external power for that.
All right, now I take...
Oh, it's a microphone.
Okay, let's see what's on this chip.
Let's try that code.
Now I loaded the code from the chip.
I prepared it on the chip there.
I don't need to load it from my PC there.
And it runs over there.
And it still loads the library.
So, enough LEDs for you.
Okay, put it over there.
With so many LEDs, you can do nicer things
and just put them in the long line.
Put them in a square and make displays with it.
So, take that one off.
Does it stop?
Yeah, it stops.
And let's run that one.
And we are at FOSDEM, so it prints an F on it.
The code takes a long line of 64 LEDs,
and it folds it after 8888 LEDs to make a square.
That's what we call a canvas, and I can write text on that.
You can also print the old code letters after each other.
Sorry?
You can also show the old code letters after each other.
Timed, you mean?
Yeah.
I'm not going to do them all, but...
FOSDEM, let's say gf.
Wait a little bit.
What did I do wrong?
Ah, slap.
Won't work.
And then...
Because we can't get enough of it.
While true.
Sorry, conventions will take one.
Yeah, I need a flush, and I need to wait after that.
And I need this flush over here.
Oh, this should work.
I didn't prepare this one, so let's see.
Something like that.
What did I...
Ah!
Yeah, yeah, yeah, yeah.
Okay, demo.
What am I missing?
Yeah.
A flush and sleep.
I have a sleep here.
Clear right flush sleep.
It's because flush is up to sleep,
and it should be good for...
Oh, you guys are wonderful.
It gets even more hot now, so...
Oh.
But I guess two letters is not enough, isn't it?
Where are more stuff here?
Ah, here are my flexies.
They also sell these things on flexible PCBs.
It's nice.
And I put on this one again.
Like this one.
And now it's garbage.
Anyone has any idea why it's garbage?
It's another shame.
Yeah.
The first one, they go tuk, tuk, tuk, tuk, and then tuk, tuk, tuk.
And this one goes tuk, tuk, tuk, tuk, tuk.
Instead of going the same direction, it's niksacht.
Okay.
So we must fold it in...
Inzigsacht version. Yeah.
If you know a better term for it, feel free.
Oh, hit the bug.
Oh, fortunately I know where to correct this.
Get to source.
It's in canvas.
And I made an error there in the zigzagging.
Rotate it.
Yeah, somewhere like here.
It's a fold one here.
It's, of course, an off-by-one error.
I have to subtract one more here because size is one beyond.
So... Ah, plus one, yeah.
Okay, save it.
And run it again.
And just a hint, this won't work.
Why doesn't this work?
I made a stupid mistake.
And it's not in the code.
No, that was a different chip.
But you're hot.
It's hot anyway here, but...
What did I just edit?
I edited the source code on my laptop.
That's the upper screen here.
This one is a source code on my laptop.
This one is the code on the chip.
I made that mistake a gazillion times.
So, do the same thing, but now on the code here.
That one...
Now, you see it's a bit slower
because the most first retrieve that code from the chip
to the laptop.
Then I can edit it.
It's the same code, but still I have to edit it.
Flash is going to take...
Well, which one on the mark?
Ah, that's quick.
Okay, thanks.
I'm not... 25, okay, near.
Ah...
I'm doing something stupid here.
Control Z is your friend.
And now I've changed it on the...
Okay, there.
And I'm still at saving.
Now I run that one again.
It should compile...
There's not the baked-in version.
It's the from-source version.
And now it's...
Now it works.
Well...
Okay.
I prepared all kinds of versions.
They do all kinds of things with the ordering of the LEDs on the screens.
Ah...
Not again.
Okay.
Shouldn't it be just X and melted?
Sorry?
Shouldn't it be just X and melted, not both X and Y?
Actually, it is not an accident.
Okay, so what I do is the X, Y inverted.
And that should be in here somewhere.
Where is that X, Y inverted?
You asked me to enlarge your ledger, so I'm scrolling slowly.
Swapped?
Ah, it's called swapped.
What's this one?
Okay.
But do reflect on what I was about to do.
That is, to edit it in the code stored on the chip.
That's another problem.
But then I decouple the chip and start working on the chip.
And I just lost my code.
Or I don't know where it is on one of the 20 chips I have.
And now it's FO again.
So that works.
So I frequently don't know where I have put my last version of the code.
And Tony doesn't support GitHub via the mark controller.
That, in fact, would be very nice.
Okay, never enough.
Let's take more.
Now it doesn't know it has more leds, so let's tell it.
Where is that code?
I'll just top it first.
That one, run that one.
Sorry?
Oh, that takes a lot of time.
You might do that for consistency.
Downloading the live takes one minute.
So not for...
You wouldn't know where your editor is.
That's true.
But then you lose a bit of the essence of using Python.
The essence is you can quickly make a modification.
If I can afford one or two minutes,
I might as well use a really compiled language and spend that much time.
So, yeah, you couldn't need to do it.
Okay, so I could add one more display, but that's more of the same.
Let's not do that.
Go back to these things.
Yeah, you saw that again loading such a library from source is slow.
You can also use a faster chip.
If I take my fast chip, this one,
and take that connection from it,
and use that one.
Tony, stop again and recognize a new chip, please.
Yes, it does.
And this one even has a separate flash card,
so I can store more files on it if I want.
And I can blink on it.
This loads the library quite a bit faster.
It doesn't have an onboard LID,
so I blink on how LCD screen works, too.
But sadly, I cannot use this target with the new pixels
because it doesn't have the new pixel library built into the
Python version for this chip.
Sometimes you're just screwed.
But I can...
Oh, it doesn't want that.
Sometimes when the communication goes wrong,
Tony is very confused about what's happening.
You just have to restart the chip
and restart Tony or whatever you want.
You can do this one.
Well, now that it will leave that.
I'll go to the sheets again.
Okay.
I've compared a few target chips that you could use
for this kind of work.
The teensy is what I just showed, a very fast one,
but then it costs 36.
So this might be real.
36, maybe I'll photograph you all.
It's quite expensive.
If you want to have lots of fun with things that are expendable,
the ESP32 and the PyPico are very good competitors.
Less than 10 euros and really available everywhere.
And for ESP32s, there are a lot of funny versions of it.
There's a watch with ESP32 in it.
I don't know my Python on it.
In a previous situation, I did a demo with it,
but it uses Wi-Fi,
and it has the habit of working perfectly
before you all walk in,
over tens of meters,
and then when you're all present with all your phones,
the reach is reduced to five centimeters.
Let's break half our condemos.
These are other things.
A doorbell camera has a built-in ESP32.
It can run Michael Python,
and then you can transmit the images over Wi-Fi,
at least if you're not all present.
And then...
Do you all know these ones?
You see one bit...
Well, they can run MicroPython, sort of.
They cannot store files on the flash system,
and they can run about 50 lines or so of Python.
So it's nice for a kindergarten Python course,
but not for real work.
And this one, I sure hope I can get it to work sometime.
It's a kendrite.
It's down here.
It's quite powerful, and it also has neural network hardware on it.
But it uses some Chinese version of MicroPython,
and Tony doesn't recognize it,
so maybe it works, but I don't know how.
Ten minutes left. Thank you.
If you have questions,
those are more important than the rest of my sheets,
so interrupt me.
A few of those more interesting chips we saw
are, in fact, not a pure mark controller
or pure mark processor.
They have a microcontroller core,
but an external ROM added,
and in some cases even external RAM.
That is overall a cheaper configuration,
because optimal, let's say, process parameter
for making microchips, flash and RAM,
are quite different.
So you can make a cheaper, more effectively make a RAM chip,
when you have only RAM cells on it.
So, for instance, the ESP32 doesn't have that many,
not that much RAM on board,
but it can use an external coupled RAM chip
as a buffer for it, it caches the things,
and then you suddenly have a few megabytes of RAM,
small actually, but it's a bit slower.
Not that much, but a bit slower.
Excuse me, can you make the slides real screen, please?
I will, if I get my cursor back.
Where's my cursor?
Yeah.
Oh, they'll publish this slide, so don't worry.
So that's, then it's nice appearing,
and then you have the hybrid version in between.
Okay.
When you work with this thing, RAM is very scarce.
So the more RAM you have, the better,
especially if you work with screen buffers or images
or things from a camera or so.
The thing is, when files are loaded by Michael Python,
it first loads the source,
then from that builds intermediate representation,
that intermediate representation is smaller than the source,
but the peak memory use is still the full source.
So I cannot load my library as one file,
or let's say in eSp3.2,
because it doesn't have enough RAM to load that peak amount.
It can load it in compiled form, but not as source form.
So what I do, I split it in a lot of small files,
and one trick I often use is I don't,
I have a main file which imports all sub files,
and for, let's say, basic classes you must do that,
but for utility things like a driver for an LCD,
I use a trampoline function.
It pretends to be the class, but it's a function,
and when it's called, it loads the real submodule,
so it's loaded only when it needs it,
and then it calls that with all the arguments.
And such a trampoline takes maybe 50 bytes,
while this full file could take a few kilobytes,
so it saves a lot of RAM and loading time.
Can you get a version of MicroPython
which only takes pre-compiled to save space on smaller machines?
Yeah, you sure can.
So when you really develop something,
I think you should take a larger machine,
and when it's in production,
take a smaller machine and use a pre-compiled version, yes, of course.
Oh, sorry, he asked whether using pre-compiled version
saves RAM, yes it does.
Well, whether you could have a smaller MicroPython program
with complete MicroPorts to save space?
Yeah, but you still want to tweak with your own main code
if you're developing.
If you have a finished product, then all things are different,
and I think the main power of MicroPython
is that you can tinker with it at a late stadium.
If you have a finished product,
well, indeed you can freeze it,
but if you want that, how do you develop it?
Presumably on a different processor with more RAM.
Let's tinkle it.
Limitations.
Should we pre-compile large libraries and put them on the chip,
and then we can tinker with our own code,
but have to pre-compile libraries?
Is that something to do?
Yeah, indeed, but there are a lot of pre...
Oh, is it a good idea to have pre-compiled libraries
incorporated in the Python interpreter
and then tinker with your own code?
Yeah, I think that's a good approach.
These libraries are stable,
because if you must change in those libraries,
you don't have the source code,
at least not on your target chip,
and you're stuck in a much slower development cycle.
So it's, well, if things are indeed stable,
freeze them in the MicroPython interpreter.
If not, take a large chip and develop on that.
Five minutes left.
Well, you can really develop limitations.
Time-wise, if you're in the, let's say, clock cycles,
time domain, if it must be that fast,
then even C or C++ won't do it.
You need hardware or Raspberry Pico Pios.
If you're in the tens or hundreds of cycles,
you can use compiled language.
If you're in the thousands of cycles,
you can use an interpreter language like Python
to concrete driving those new pixels
that requires microseconds timing.
You cannot do that in Python code.
In the MicroPython interpreter,
they do it in C code, and that's built-in.
Driving a servo motor, a hobby servo back and forth,
that's millisecond timing.
You can easily do that in Python,
in the Python source code.
Oh, there's a list of deviations from C Python.
You can read it.
They didn't bother me much,
except that it doesn't support type hints,
and I like type hints from my testing,
so I must do the testing on my laptop.
You can test a lot of basic things,
not on the small machine between your desktop.
Question.
When it's compiled, is it the same by code as Cpyto?
No.
When it's compiled, MicroPython intermediate code
is different from Cpyto code.
It has its own pre-compiler, which you can download,
and you can pre-compile it,
but it's different from the standard Cpyto.
Question.
Does MicroPython have a garbage collector?
You can bet it has, yes.
And when you want to do really time-critical things,
call the garbage collector and do it after that.
Then you can be reasonably sure that it's called.
But if you want to do really time-critical,
life-critical things, don't use Python.
Sorry.
Okay, I'll skip this one.
Where is it good for?
Well, maybe not for volume production.
For that you use compiled language,
but for anything that requires tinkering,
exploration, lab setups, experiments, education,
it's really nice tool.
Okay, what is problems?
I'm always confused where my latest version of the source code is.
I changed what's something on that ship.
Maybe it's on my PC or on GitHub, I don't know.
Remember, USB port cannot supply a large current,
which you want things like these pixels
have a separate power supply.
The terminology of Tony with upload and download
is reversed from what I think is normal,
but you have to use it.
No problem.
If you want to have your code safe from prying eyes,
I think forget it.
The intermediate code can be back-compiled
so anyone can see into your code.
If you have large invested interest in your code,
maybe Python root is not the way.
Then probably you want to make a large amount of products
so it's not the way anyway.
Okay, I did cover some things.
Take away.
Well, start tinkering.
It's always a good idea.
Get the same hardware as you would use for an Arduino.
Get some micro-python cable board loaded on it.
Five minutes work and start doing things.
Okay, well, if I did that demo,
then those pixels would show questions,
but I think we're at times up anyway.
One minute.
One last question.
Yeah.
In the beginning, you showed the custom
that you called it, like,
machine or pin.
Yeah.
Where does it come from?
That's...
Micro-python is a bulk of...
Sorry.
He asked, where does this code come?
The pin and the machine.
Micro-python is common parts
and then the specific part for specific chips.
And accessing a GPO pin of a chip
is very different from chips.
But that's a very shallow part.
Once you have that,
you can build a lot of things on top of that.
So the micro-python distribution
that I used here to compile,
I'm a specifier for which target chip I compile
and then it grabs the correct code.
Okay.
Thank you.
Thanks a lot, Walter.
Will you be available outside for questions?
I'll be here around.
So Walter will be around for questions
if you have questions and hesitate.
Python may have lost the smartphone wars,
but for the smartwatches, we still have hope.