MicroPython Forum (Archive)

Hello,

I started porting micropython to the Raspberry Pi. You can find the current state in [1]. I had to do the following: in lib/utils/printf.c there were several occurances of a output-function probably used by the stm-port directly. I found the macro MP_PLAT_PRINT_STRN to be of more use here, so I changed the output-functions puts and putchar to use this macro instead. The macro is defined in the mpconfigport.h of the port.

The code for the port itself began rather barebones at the moment. I initiated the micropython-interpreter, had a run at five very small scripts to run (the latter two fail), and then put the Pi into an infinite loop blinking its LED.

Now I started adding a module for RawPtr-access and started implementing a "driver" for the GPIO-Pins of the Raspberry Pi.

The port uses newlib as a libc-implementation, especially for free and malloc, but also for some other functions (mostly string.h). The port uses the UART-chip of the Pi to communicate to the PC (you can use an Adafruit TTL-USB cable, or any other cable, which provides the right voltages!). The code utilizing the UART was copied from dwelch67 on github; the linkerscript, Makefile and parts of the port are based on the BakingPi-Tutorial of Alex Chadwick.

At the moment the code crashes after running for a while. My guess is, that either the memory managment gives up, or the compiler optimizes some loops out. The current code (see main.c:105-152) runs as far as calling gpio_write once, returning normally, enters the second and seems to not "return" from some of the if-statements - a print-statement placed directly after it will not be executed. Removing some of the print-statements scattered throughout the script will result in the code not even managing to run until that place. Your guess for what may be wrong is very welcome.

One side note, if I may: it would be really nice if the micropython-code was actually documented better. Doxygen-documentations help people like me, who just want to get the code running on a different plattform, to get started and understand error messages. I got several failed assertions all over the place testing the code until now, and I cannot figure out what causes them, why these assertions are there and what I can do to prevent them from failing.

[1] https://github.com/naums/micropython

Kind Regards,
Stefan Naumann

there were several occurances of a output-function probably used by the stm-port directly.

Why did you start with the STM build rather than the Unix build?

Indeed, as far as I know the unix build works out of the box (it definitely did once as I tried it, but that has been a while ago).

[quote="pythoncoder"][quote]there were several occurances of a output-function probably used by the stm-port directly.[/quote]
Why did you start with the STM build rather than the Unix build?[/quote]

I didn't. I started with the bare-arm. But I've seen wrong code (or what I believe to be wrong code, as it didn't compile for me) in lib/utils/printf.c. The original code used mp_hal_stdout_tx_strn_cooked, whereas my code uses the macro MP_PLAT_PRINT_STRN, defined in mpconfigport.h. E.g. puts:

original:
[code]int puts(const char *s) {
mp_hal_stdout_tx_strn_cooked(s, strlen(s));
char chr = '\n';
mp_hal_stdout_tx_strn_cooked(&chr, 1);
return 1;
}[/code]

my code:
[code]// need this because gcc optimises printf("string\n") -> puts("string")
int puts(const char *s) {
MP_PLAT_PRINT_STRN(s, strlen(s));
char chr = '\n';
MP_PLAT_PRINT_STRN(&chr, 1);
return 1;
}[/code]

I don't quite understand what use it would have to me, to port micropython to boot from Raspberry Pi Hardware, when I would have started with the Unix-port which uses e.g. memory managment of an Operating System, which would not be there for me.

As far as I read it, Stefan wants to build a bare-bone MicroPython port for the Pi, which is interesting.

Indeed ! One specific detail that would interest me tremendously, would be to see if the micropython "USB HID mode" would work as painlessly on a Pi Zero as it does on a pyboard...

This is because I have recently spent *hours* implementing various popular tutorials, which claim to enable multifunction "USB device (gadget) mode" on a Pi Zero under Raspbian... without any success (even with a single plain HID keyboard function, let alone several)...

So either I have a faulty board (as claimed by others with the same issue), or I'm missing something, or the howtos are... It would help to know if it would work with micropython !

Or maybe I could already try with the Linux build, if it's supposed to support that ?

Roberthh wrote:As far as I read it, Stefan wants to build a bare-bone MicroPython port for the Pi, which is interesting.

Ah, got it! A bare-metal port, especially one tested on a current Pi model, would be awesome

I'm currently working on python-code to implement REPL in micropython, documenting code and extending the documentation of micropython on my way. The next thing would be to use some test-skripts to test functionality of my micropython-build, trying to find out what works, what does not and how I could fix that.

Would you like to receive regular pull requests with the Raspberry Pi-port-code, docs and doxygen comments in the py/-headerfiles or just one pull request when I finished my project or depart to heavily from porting micropython?

EDIT: I'm getting weird errors in micropython based on where I put print-statements. For example I have the following code, which I want to execute with the do_str ()-C-function in FILE-setting. I have two code-examples:

cio.getchar gets a character from the uart-interface and returns it (correctly) as integer-object to python.

Example A:
The following assertion fails: Example B:
works okayish. The string will be concatenated correctly and printed correctly. Commenting the last print-statement will result in the above MP_CODE_BYTECODE-assertion failing.

What am I doing wrong? Am I compiling micropython wrong? Is it possible to output the asm-code micropython emits? Is it possible to get micropython into a verbose-state, so it tells me what may be wrong?

Also previosly I got the following error, what does that mean? What is wrong, how can I fix that?
Any help would be very much appreciated.

Has anybody done anything further on this?

running micropython on a pi zero would be a great tool.

running micropython as a raspbian process on a dedicated core inside the arm cpu would also be a great tool.

The openplc project appears to have mastered how to run openplc on a dedicated core. Might it be possible to modify the micropython environment to run in a manner similar to openplc?