As much as I’d love to discuss this further, this is pulling the thread off topic and I do not want to distract any further from @Hanski’s good work.
If you really want to pursuit this further, PM me, though I suspect we both have better things we could be doing.
Hi,
I have now enough building blocks to make a short gfx demo using MicroPython and very minimal subset of PyGame. I have derived from pygame.Sprite and used pygame.SpriteGroup classes to create and move sprites. The graphics for this demo has been made by @VonBednar, and they look excellent! The demo is much smooter on the Pokitto simulator that in this video, because my old laptop did not quite handle the video recording.
It’s awesome to see the progress. Can’t wait to check it out myself!
As for the libtcodpy, I wouldn’t worry about it. I can always find a way to implement FOV and A* on my own. On the other hand, if those two options could be ported from libtcodpy I wouldn’t complain 
Yup, just express or opinions, then back to the topic.
Sounds like the port is far enough along for my purpose. I want to connect a Bluetooth serial module to the pokitto and use it as a remote control for my micropython-based robot. Not clear I can get that in the emulator, though - and there lots of work to do on the robot waiting for the pokitto.
Are you using SPI interface then ? There is a simple example of using it with MicroPython: https://learn.adafruit.com/micropython-hardware-spi-devices?view=all
Everyhing is certainly not yet in place for Pokitto uPython but we can look at it more closeöy when we get the HWs. I really like to get also pins and interfaces at the top connector to work with uPython. It would be also nice just to use interactive Python prompt to communicate with the device on the top connector, like read the temperature values etc.
No, I’m using a UART interface: http://docs.micropython.org/en/latest/pyboard/library/pyb.UART.html. It connects to a Bluetooth module (HC-05 or similar) that translates it to SPP to connect to control software running on my Android phone or desktop.
If I read the specs correctly, the pokitto header pins ext6 and 7 provide the required connections. I run the REPL over the same connection, so I can use the same term program I use to talk Arduinos and stock micropython REPLs, just using the SPP comm device instead of the USB one.
I am a bit uncomfortable at @Hanski having to cover up things, at my request. Especially now that we are very close to shipping. PCBs arrived in Finnish customs control today, should be here monday.
So fyi: Hanski is working on hardware, on an earlier Pokitto prototype. I saw uPython as a very important initiative and offered a proto for development - to make sure it runs on hardware.
Ok Hanski you’re off the hook of secrecy now.
And people: please do not be offended. Hanski lives close, is a fellow finn and a good programmer & he has helped with bug squashing. Soon we will all have HW to play with, I promise.
Yes, porting MicroPython is a big task, and it is not practical to go over certain point without testing on real HW. Otherwise you could end up doing a lot of work that is not really usable.
I am happy that I can say now that uPython works fine on Pokitto! I tested PyGame surface with blitting 100 “Pokitto” bitmaps (16x16 pixels, 16 colors) and it did not cause a drop in fps (currently limited to 16 fps). I can configure uPython to use interactive prompt (REPL) over USB, and either type individual commands on the terminal on PC, or copy-paste a block of code at once to the terminal window. Another option is to include the frozen python code in the binary image and flash that to Pokitto, so that the game starts right away after restart.
Have to say that while I already have a HW proto, I am also eagerly waiting for the finished product !
Edit: Pokitto uPython port is still in “preliminary” state. I have only started to implement a demo game with it.
Suitability for other than gaming purposes should very probably be tested and implemented by somebody else than me (I can still help, of course)
As it stands what you already have done is very impressive.
I may have to sit down and learn Python just to give it a try when the time comes.
(I read a book about Python once so I have a vague idea of what it’s like, but I never got round to writing anything beyond a basic print and playing around with tuples.)
Experimenting with limited resources. The python garbage collector (gc) heap is currently limited to about 20 kb in the Pokitto port. That should contain all loaded python codes and created objects. I was going to make another perf test, but use animated sprites instead of bare surfaces. So I derived my class from pygame.Sprite class, tried to create 100 sprites. The program did not create even half of the sprites before the heap was exhausted. After investigation I noticed that each sprite took about 250 bytes (due the member data). The size for 100 sprites would have been 25 kb
I will next be cleaning up the codes and make the uPython available in the Pokitto simulator GitHub, so you can test it if you will.
I have taken PyGame collision detection into use. After I have added rect variable to my sprite class, detecting collision to any car is just:
hit = sprite.spritecollideany( frogittoGob, all_cars )`
Note: MicroPython is now available in the Pokitto Simulator. Instructions are in Wiki. Give it a try, it’s easy!
Small progress:
It is used like this:
pygame.display.set_palette16([
0, 6438, 18917, 10825, 47398, 688, 41764, 17475,
58225, 13598, 60486, 40179, 42596, 46845, 63245, 65535
]);
You can use the same bmp2pok tool as with C++ to generate the bitmap data and palette for the image,and easily copy-paste the values to the python code.
Hi,
MicroPython has now been released (as beta) for Pokitto. It works both on HW and on the simulator. It can be found in two repositories:
Forked from MicroPython:
This contains MicroPython port to Pokitto and Pokitto Simulator. It also contains a uPyGame C-implementation, which is a small subset of PyGame module. This repository is not necessarily needed as the resulted libmicropython.a and libmicropython-win.a files are already copied to the PokittoLib repository. Use this repository if you want to add or remove Python library modules, or otherwise change the implementation.
Forked from PokittoLib:
This repository contains:
Todo:
I was working on the first draft of my tutorial for using the PEX and it got me thinking, does your MicroPython port have an equivalent of the classes for working with the PEX?
I’m wondering if it might be worth using MicroPyhton’s REPL to demonstrate one or two of the circuits.
That would be a very important feature to have in Pokitto MP. There are examples of these in the other MP ports. Below is documentation of PyBoard HW , which kind of official MP board.
Pin class:
https://docs.micropython.org/en/latest/pyboard/library/pyb.Pin.html?highlight=pin
SPI class:
https://docs.micropython.org/en/latest/pyboard/library/pyb.SPI.html
UART class:
https://docs.micropython.org/en/latest/pyboard/library/machine.UART.html?highlight=uart
Unfortunately, I have nothing to test it with. I am a SW guy So could you try to implement that for the Pokitto MP? That would be most likely just configuring the existing MP core library implementation to work with Pokitto. In the worst case you have to copy the code from another port, but that is not bad either. I am more than happy to help on any issues in MP implementation.
I think the best approach would be to just wrap the relevant parts of mbed’s library rather than trying to reimplement it. (I’m pretty sure it’s wrappable, if not we might have to ask for Jonne’s input since I suspect he’ll have a better idea than me.)
mbed’s library is here:
https://docs.mbed.com/docs/mbed-os-api/en/mbed-os-5.5/api/namespacembed.html
It looks a lot but some of it is just infrastructure (like the callbacks and circular buffer).
The main things are:
DigitalInDigitalOutDigitalInOutAnalogInAnalogOutPWMOutAnd maybe some of the I2C and SPI stuff. I haven’t looked into the rest yet, e.g. the timer stuff might be useful if it’s linked to hardware timers, but otherwise I think those are the minimum required to do stuff with the PEX.
Also I’m not actually a hardware guy, I’m just doing the PEX stuff because I got an Arduino starter kit a week (or so) ago, so I thought it would be fun to try to replicate some of the experiments using the Pokitto and develop the PEX tutorials (or at least their draft versions) as I go.
I agree that just make wrappers for MP. Python is implemented in C, so I have made C-wrapper API in PokittoLib already, PythonBindings.cpp/h.
At first we could try just set the screen background light or the Usb led on or off. @jonne , do you know if that is possible and what would be the ID for DigitalOut class?
A C++ example from mBed docs:
// Toggle a LED
#include "mbed.h"
DigitalOut led(LED1);
int main() {
while(1) {
led = !led;
wait(0.2);
}
}
I think you should stay with the µ-python libraries. That way, you can piggyback on their documentation instead of needing to write your own. Of course, I’ve got a half-dozen or so boards that run µ-python, including one that’s controlling my current robotics project, so I might be biased. Unless the NXP hardware is radically different from the STM32 hardware used in the PyBoard (and a slew of other ports to various dev boards), it should be more a matter of porting those classes rather than rewriting them.
I just got my Pokitto, so haven’t really looked at getting µ-python on it yet. While testing some of these things is high on my list of things to look at now that I’ve got games on it, I’m recovering from major surgery last month. I’ve got trips to the clinic for therapy every other day, and hours doing therapy of various kinds on the “off” days, and have just gotten to the point of being able to sit at a desk.
If you can provide a “.bin” that I can load (can I load µ-python off of the SD card?) that lets me get to a REPL somehow, it would expedite my testing quite a bit. I’ll figure it out eventually, but I have to deal with those other things.
Great! Here is MP with REPL enabled. Unfortunately, you cannot flash it from SD. There is some weird problem in that. But with USB drive flashing it works. Note that REPL insists that the USB cable is connected and wont’t boot without it.
pythrepl.bin (196.8 KB)
Got it, installed it, REPL comes up but doesn’t reboot. Seems like many of the micropython facilities are missing - in particular, “help” which I would normally use to get a list of precompiled modules. The machine module - where I’d expect to find all the hardware interfaces - isn’t there. uos - for checking for python source modules - is missing. Nothing interesting seems to be imported at boot.
Is there a list of modules you wanted tested?