Thanks, this is very good feedback! I will look if I can easily enable help and uos. The machine module is by the name “umachine”.
Here is the configuration of Pokitto port where you can see which modules are enabled:
This file has been truncated.
// options to control how MicroPython is built
// You can disable the built-in MicroPython compiler by setting the following
// config option to 0. If you do this then you won't get a REPL prompt, but you
// will still be able to execute pre-compiled scripts, compiled with mpy-cross.
#define MICROPY_ENABLE_COMPILER (1)
#define MICROPY_QSTR_BYTES_IN_HASH (1)
#define MICROPY_QSTR_EXTRA_POOL mp_qstr_frozen_const_pool
#define MICROPY_ALLOC_PATH_MAX (256)
#define MICROPY_ALLOC_PARSE_CHUNK_INIT (16)
#define MICROPY_EMIT_X64 (0)
#define MICROPY_EMIT_THUMB (0) //!!HV kokeile kytkeä päälle
#define MICROPY_EMIT_INLINE_THUMB (0) //!!HV kokeile kytkeä päälle
#define MICROPY_COMP_MODULE_CONST (0)
#define MICROPY_COMP_CONST (0)
#define MICROPY_COMP_DOUBLE_TUPLE_ASSIGN (0)
#define MICROPY_COMP_TRIPLE_TUPLE_ASSIGN (0)
What do you mean that reboot is not possible?
My understanding is that mpconfigport is a list of capabilities, not modules. But I normally just use it to add/move devices around.
Control-D didn’t work as described here:
http://docs.micropython.org/en/latest/pyboard/reference/repl.html?highlight=reset#soft-reset. Instead of a soft reset, it just exits the REPL.
BTW, if you want a simple-to-implement powerful way to get to IO, it’s the LPC equivalent of the stm module. This has 3 real objects - mem8, mem16 and mem32 (I believe they’re actually defined in the machine module) and then a bunch of integer constants for the bases and offsets into the various registers in the device, copied directly from the user manual of the chip. Probably want to call it lpc or nxp instead of stm, though.
Here’s some excerpts from the help for that module, showing a few GPIO values:
object <module 'stm'> is of type module
__name__ -- stm
mem8 -- <8-bit memory>
mem16 -- <16-bit memory>
mem32 -- <32-bit memory>
TIM2 -- 1073741824
GPIOA -- 1073872896
GPIOB -- 1073873920
GPIOC -- 1073874944
GPIO_MODER -- 0
GPIO_OTYPER -- 4
GPIO_OSPEEDR -- 8
GPIO_PUPDR -- 12
GPIO_IDR -- 16
GPIO_ODR -- 20
GPIO_BSRR -- 24
So I could toggle an LED on the STM with something like:
from stm import *
mem16[GPIOA + GPIO_MODER] |= 1 << (2 * 4) # Set GPIOA Pin 4 to output
turn_on = True
mem16[GPIOA + GPIO_BSRR] = 1 << 4 # Set Pin A4 high
mem16[GPIOA + GPIO_BRR] = 1 << 4 # Set Pin A4 low
turn_on = !turn_on
You can also enable/disable internal (C-impl) Python modules in mpconfigport.h, like e.g. MICROPY_PY_FRAMEBUF enables the framebuf module.
I have now enabled help() in REPL. I also updated GC heap to have 20 kb of memory.
Umachine looks to have those memx objects. Would you care to test if they actually work?
pythrepl.bin (190.5 KB)
Ok, latest report.
The REPL control function processing isn’t there at all - no auto-indent, can’t interrupt running code, etc. Those apparently configure to off by default. My guess would be this needs MICROPY_REPL_EVENT_DRIVEN.
While I can see the memx objects, I can’t test them because I can’t create integer values as big as the addresses of the IO port registers.
>>> GPIO_DIR2 = 0xA0002008
OverflowError: long int not supported in this build
OverflowError: long int not supported in this build
I believe this needs MICROPY_LONGINT_IMPL to (MICROPY_LONGINT_IMPL_LONGLONG).
I forked the source, but doing “make” in the ports/pokitto directory doesn’t work on Linux. Doing “make” in the ports/stm32 directory does. I’ll look into that next time I get some time.
I did find the documentation on the contents of the mpconfigport file: it’s in py/mpconfig.h.
I’d like the uos module in order to look at the flash file system, but that appears to be port specific, not a generic module. And it’s not clear that the flash file system is there yet.
Final question: is there a tutorial showing how to run a python script - preferably using the upygame module - somewhere?
Just a quick answer for now. Not a tutorial, but an introduction:
It is easier to develop Python scripts first on Pokitto Simulator, as the development and testing cycle is faster on PC. An exception is the case when there are features the Simulator do not support, like GIOP-port usage. Also, simulator has a lot of memory and CPU power which makes it to behave different than the real HW. Anyway, your final target is Pokitto, so sooner or later you will try to run your scripts on HW.
Build the example application
1) Start the EmBitz application and select th…
Every time I see this thread I read it as ‘Monty Python Progress’…
Guess where Python got Its name from? Yes, thats right!
I commited latest changes to the repository. The readme.MD contains now information that should help you to get in working in Linux.
Is there any documentation on what is implemented and what still missing?
In generic level, I have implemented in uPyGame:
key event handling
Not all functions of those classes have been implemented and that is not the intention either. The proof of concept is the Mars Attack game, where all those classes have been used.
upygame import module
Python Modules, Classes and methods provided:
(internally implemented in C language).
poll - Gets the next key event.
EventType - The key event data.
set_mode - Returns the screen surface.
flip- Updates the screen and subsustems (audio, events, etc.).
update - Updates the screen and subsustems (audio, events, etc.).
set_palette - Sets the palette with rgb colors.
set_palette16bit - Sets the palette with 16-bit colors.
get_rect - Returns the surface rect.
fill - Fills the given rect with a color.
blit - Draws the surface to the screen.
setHwSprite - Defines a HW sprite.
setHwSpritePos -Changes the HW sprite position.
set_clip - Sets the clipping rect for the screen surface.
reset - Resets audio.
fill_buffer - Fills the buffer with audio data.
get_current_soundbuffer_index - Gets current sound buffer index.
get_current_soundbuffer_pos - Gets current position in the buffer.
get_soundbuffer_size - Gets the size of the sound buffer
play - Starts playing.
pause - Pauses palying.
colliderect - Checks if two rect collide.
x, y, width , height, centerx, centery - Rect data.
Additional Python classes
(implemented in Python language in a separate *.py file)
The Sprite class (different from HwSprite above). See the class for method descriptions.
Look for an usage in the Mars Attack game, where almost every module and class is used in.
Maybe I’m wrong but surface.fill() seems not working as expected. Can you confirm it’s implemented?
Do you plan to implements also upygame.draw to manage primitives?
I am not right now going to implement primitives, but if there is demand I can do that.
Updated short descriptions to each method in
upygame in the post above.
Note: Just noticed that the (audio) mixer functions are missing from Gitlab (however they are there in PokittoLib). I will make a new commit to add it to the GitLab MP repo.
Does anyone else keep reading this topic as ‘monty python progress’?
yes, and it makes me smile every time
gets over 500 compiler errors
'Tis but a flesh wound