MicroPython progress

This is a Pokitto drawing loop implemented in Python :slight_smile:

Credits of the Pokitto bitmap to @spinal !

The Python code (in simulator) as follows:

import umachine as machine
import framebuf
import urandom as random

# screen buffer
w = 220
h = 176
buf = bytearray(w * h // 2)
fbuf = framebuf.FrameBuffer(buf, w, h, framebuf.GS4_HMSB) # 4 bit color depth

# pokitto picture
w2 = 32
h2 = 32
pokittoPixels = [
pokittoBuf = bytearray(pokittoPixels)
pokittoFBuf = framebuf.FrameBuffer(pokittoBuf, w2, h2, framebuf.GS4_HMSB)

# Event / update loop
while( machine.isRunningPokitto() ):

	if( machine.updatePokitto()):
		x = random.getrandbits(7) + 50
		y = random.getrandbits(7) + 20
		fbuf.blit(pokittoFBuf, x, y, 0); # 0 is transparent color

So now it runs the Pokitto event/update loop in Python. Next I will implement bindings of Pokitto key event reading in Python.

One thing to consider in the future is porting of some gaming library over uPy (e.g. PyGame), or rather a subset of it (“uPyGame”). I would not like us to have a Pokitto custom gaming or gfx API in Python, but something also other MCU boards can use and build games on, and something that is familiar to Python game devs.


That’s look quite impressive, and It progress very fast to have something usable in near future. Great job!


How is this going? I’ve been asked to give a talk on embedded python at our local Python users group the 13th, and there’s a place for the Pokitto in it (if I get it in time). But it would fit better - and be more likely to be ready - if I could use Python on it!

Python port has been progressing quite well. I can do graphics demos with the simulator. Lets hope the Pokitto comes before your presentation.

I have been implementing a subset of a PyGame like API for uPython. The ultimate goal is to make it as easy as possible to port games from PC Python & PyGame to Pokitto. A short term goal is just make it possible to create python games for Pokitto. Now, I have implemented some needed methods from PyGame display, surface, and event modules, to make it possible to draw a surface and move it according the key events. Unfortunately, I do not have any screenshots to share this time, but just a code snippet, which you might find familiar if you know PyGame.

import upygame as pygame

screen_sf = pygame.display.set_mode() # full screen

# pokitto picture
w2 = 16
h2 = 16
pokittoPixels = [
pokittoBuf = bytearray(pokittoPixels)

hero_sf = pygame.surface.Surface(w2, h2, pokittoBuf)

vx = 0;
vy = 0;
while True:
    eventtype = pygame.event.poll()
    if eventtype != pygame.NOEVENT:
        if eventtype.type() == pygame.KEYDOWN:
            if eventtype.key() == pygame.K_RIGHT:
                vx = 1
            if eventtype.key() == pygame.K_LEFT:
                vx = -1
            if eventtype.key() == pygame.K_UP:
                vy = -1
            if eventtype.key() == pygame.K_DOWN:
                vy = 1
        if eventtype.type() == pygame.KEYUP:
            if eventtype.key() == pygame.K_RIGHT:
                vx = 0
            if eventtype.key() == pygame.K_LEFT:
                vx = 0
            if eventtype.key() == pygame.K_UP:
                vy = 0
            if eventtype.key() == pygame.K_DOWN:
                vy = 0

    x = x + vx
    y = y + vy
    screen_sf.blit(hero_sf, x, y)


The next step is porting needed parts of pygame.sprite. After that the real fun begins and I can start making a uPython demo game for Pokitto :slight_smile: I was thinking of space shooter like Scramble with a scrolling background. https://www.youtube.com/watch?v=kjIbk1Lpr4I

I just want to say a BIIIIIIIIIIIIIG thank you!

As someone who is pretty new to programming and seeing C and it’s kin kinda scary I am really happy for python implementation!

Not to mention that I am currently learning python and pygame to expand on the roguelike the Pokitto Community Team worked on for CGA jam :smiley:

Will I be able to use python libraries in uPython?

1 Like

I am glad you are interested in this port :slight_smile: Not all Python libraries are available due the memory or performance limits of MCUs. In the MicroPython sources, you can configure what libraries the specific port includes. For Pokitto port, I started with the minimal project, and have been adding libraries based on what is needed. It is also totally possible to choose the ROM libraries based on what a certain python application needs, and take unnecessary libs away. Also note that many of the libraries are “micropythonized”, i.e. not all the methods are available.

Is there some specific Python libraries you need?

1 Like

I think it’s worth mentioning that (much like pretty much all scripting languages) some python methods are actually implemented as machine code rather than in python itself, so those would have to be re-implemented for ARM before they’ll work.

All the others can easily be rebuilt from their Pyhton source code (though there are memory limitations of course).

Right now I don’t have a lot of experience in Python, so I don’t have a list of libraries that I use.

I am using libtcodpy which is a library that handles some of roguelike backend (I am using it for FOV mostly). I am using some other stuff for things like text rendering etc, but those things already seem to be implemented in Pokitto :slight_smile:

But as long as I get access to pygame surfaces and have decently fast blitting I will be happy :smiley:

Not sure how well that will work since that appears to be a C++ library with a python binding. It also appears to be reliant on SDL2.

Yes, a good point. Have to check from other uPy ports if there is assemby code involved.

1 Like

About libtcodpy. It is possible to call C/C++ from a Python code, but the size of the code will be an issue as we have only 256 kb of flash rom.

This morning I stumbled in this article about python:

I was surprised about its popularity but soon @Hanski porting come to my mind.

1 Like

Truth be told I think all of these “which language is the most popular” articles are a load of tripe.

Every language has a user base and it’s the user base that really matters.
As long as a language is being used by people and is liked by people (no matter how many) then it is just as valid as any other language.

People will learn the languages they want to learn, and businesses will use whatever language their technology advisor tells them to or whatever language they need to support their awful legacy code.

The only reason to be choosey about which language you learn is if you have a particular goal in mind.
For example, C++ isn’t particularly going to help you make a website, and Javascript won’t help you much if you’re programming embedded systems.

Every language is a tool, and you must choose the right tool for the job.

1 Like

I’ve formulated a theory about real professionals.

Real professionals:

  • always answer every question with equal respect. There are no “dumb questions” to them.
  • never blame their failures on other people or their choice of tools (languages). If you are a real pro, you understand that developing tools and understanding others is an integral part of solving the problem. You can’t separate the technology, the human factors and the economic factors. You need to scale the solution if your resources are limited.

Nowadays, when I come across someone that is projecting zero ego and doesn’t complain about anything (languages, tools, co-workers, food in cafeteria, spouse), I immediately think “this person is a pro”… and thats how it usually turns out.

If on the other hand the person is a loudmouth wiseguy, I normally think they lack experience and probably really don’t know anything about the problem at hand. And thats usually true as well.

Summary: rabid fanboyism is usually just a symptom of lack of experience.


However, I am SO waiting to get to program this thing in Python. I am very very happy @Hanski took on this project.


The article spoke about “popularity”, aka what people like most. Not the best neither the one you have to learn. A measurable trend, not related to any quality.
Simply I thought python was way less attractive/trending as programming language. Anyway @Hanski do a great think porting it for pokitto. It could bring more users to appreciate this little wonderful device.


I didn’t mean to imply that it was.
What I meant is that ‘popularity’ tells you nothing of worth about a language.
It tells you how many people use a language, it doesn’t tell you why or whether they enjoy using it.

The article’s figures aren’t actually a measure of how many people like the languages, they’re a measure of how many times question on StackOverflow are viewed, which only gives an indication of how many people are using python, not how many people like it.

A lot of people only use certain languages because their jobs require it and whenever a university or college course picks a language to teach its students, the number of users of that language typically leaps in response. Python falls under both of those conditions, being heavily used and promoted by Google, being used for scientific research and being used a lot by universities and colleges to teach students (and it’s often now used in favour of Java for various reasons).

I’m not saying Python is a bad language, I’m just saying that not everyone uses a language because they choose to use it. When I was at college, they taught us Visual Basic, and for those two years my class probably contributed a lot to the annual Visual Basic viewing figures. After the course was over, none of us ever touched Visual Basic again.

Like I say though, the popularity of a language doesn’t really affect much even if you could find a decent measure for it, which is why I think articles discussing language popularity are “a load of tripe”.

It depends who you ask.

It’s very popular with beginners and people who had it as their first major language (as well as other people), but there are various reasons why some people don’t like it.
A lot of programmers with experience in C-like languages (C++, C#, Java) just can’t get on with it because it has ‘significant whitespace’ (i.e. the syntax enforces the layout).

It’s also understandable that people interested in embedded systems wouldn’t be interested in Python. MicroPython is quite a new development (introduced in 2014) and still isn’t massively well known, and plain old Python isn’t very useful for embedded systems.

I agree. @Hanski has picked a very interesting project.

I must admit I have my reservations because even MicroPython is technically a scripting language, but I’m prepared to be impressed by what it can pull off despite its limitations.

I’d certainly like to read the source code when it’s released.
Parsers, interpreters and compilers are some of my favourite topics.

I would be great to have the code reviewed and improved by somebody more pragmatic than I am. I tend to lose interest soon if there is not something visible progress (graphics!) to try out.

I wouldn’t agree with that. It doesn’t tell you anything about whether it’s a good language for some purpose, or whether learning it will make you a better programmer, or what using it is like, but those aren’t the only things worth knowing about a language

Popularity tells you that lots of people are talking about the language, which - depending on why you’re interested in it - could be worth knowing. If you’re looking for a language to give a talk about that will draw interest, it’s a good candidate. If you want a language that has an active community, or good online help, or a good employment prospects, then this tells you the language is worth a deeper look.

1 Like

Progress: Now I have minimal PyGame.Sprite & SpriteGroup classes in place. Ready to test the new graphics on the simulator :slight_smile: