blog.bkpt.party

GSoC Project Updates, Threads!

Mon, 18 Aug 2025 00:00:00 +0000

Since my last update I have been busy with MicroPython tests- enabling new features and testing them, isolating problematic test cases, sometimes placing appropriate definitions and function calls in the C code.

I traced the failure of builtin_compile to the __globals__ attribute not being available for function objects. Enabling that fixed it.

I also now include the previously ignored float test group, giving us 9 more passing tests.

Turns out that the int_big_div and int_big_mul tests that I mentioned in my previous post were failing because of hardware flow control issues and I fixed it by enabling the IXON termios flag.

The latest update with test cases is that I have 588 passing test cases out of 591 executed. The failing test cases are:

io_iobase
print_exception
sys_atexit

I am tracking progress on test cases in this issue. Here is a list of all MicroPython modules that have been enabled so far:
array, builtins, cmath, collections, errno, gc, heapq, io, json, math, os, platform, random, re, struct, sys, time, machine, uctypes

The highlighted ones are either partially enabled, or have a failing testcase.

io: failing io_iobase test
os: no filesystem, so the fs functions are not enabled
re: failing re_stack_overflow test
sys: settrace, ps1, ps2, std{out,in,err} not enabled. failing sys_atexit test
machine: only the bare minimum is enabled as we are using the qemu pc-686 BSP and there is no I2C, SPI, etc.

threads

I have also been able to get threads working on MicroPython. The threads use RTEMS Tasks internally. As for testing threads, I currently have five passing test cases. There are around 8 to 9 more tests but those need locks on the MicroPython side, which is still a work in progress.

I wanted to talk more about how threads are implemented in MicroPython. MicroPython doesn’t have documentation for the _thread module as it is “highly experimental and its API is not yet fully settled”, so I think that makes it a really good topic for a blog post. The thread functions are listed in py/mpthread.h. Ports that implement threads, i.e. the _thread module, need to implement these functions in a mpthreadport.c. Here’s a link to my current mpthreadport.c.

Here’s some debugging output that visualizes the order in which different functions are called:

MicroPython v1.26.0-preview.154.g0dbda0e0c.dirty on 2025-08-20; rtems-i386/pc686 with unknown-cpu
THREAD: get_state
>>> import _thread as th
THREAD: get_state
THREAD: get_state
...
THREAD: get_state
THREAD: get_state
THREAD: get_state
>>> x = lambda: print("thread!")
THREAD: get_state
...
THREAD: get_state
THREAD: get_state
>>> th.start_new_thread(x, ())
THREAD: get_state
...
THREAD: get_state
THREAD: get_state
167837698
THREAD: get_state
THREAD: get_state
>>> THREAD: set_state
THREAD: get_state
THREAD: mutex_lock
THREAD: thread_start
THREAD: get_state
thread!
THREAD: get_state
THREAD: thread_finish
THREAD: get_state
THREAD: get_state
...
>>>

The state for multiple threads is tracked using a linked list, access to which is protected by a mutex. An internal task is created for a new thread using the RTMS task API and a new node is added to the linked list. Here’s the structure of a node:

typedef struct _mp_thread_t {
    rtems_id id;               // RTEMS task ID
    bool ready;
    void *arg;                 // thread-entry args
    struct _mp_thread_t *next;
    mp_state_thread_t *state;  // pointer to this thread's mp state
} mp_thread_t;

I will document the threads implementation in detail when I’m able to get MicroPython locks working.

final work

GSoC coding period ends on 25th August! Here’s a list of action items I am currently working towards:

implementing MicroPython mutexes (this will help pass all or most of the threads test cases)
getting the 3 failing testcases to pass, making more skipped tests pass
preparing a code cleanup branch
collecting project learnings and milestones for the final work product

Thank you for your time :)

GSoC Project Updates, Progress with MicroPython Tests

Mon, 04 Aug 2025 00:00:00 +0000

The first item we decided to focus on after the mid-term was getting the MicroPython test suite to work with the RTEMS Port. In the previous post I wrote about the test “framework” (run-tests.py) and how it works, along with features required on the MicroPython side that allow the test framework to communicate with it (a “raw” REPL, and a so-called “raw paste mode”). There was a problem with raw paste mode where MicroPython would freeze up and not send the ACKs back to the test runner that are expected in this mode. I wanted to focus on getting the tests to run first, so I decided to look into this later and commented out the lines in the pyboard module that ask the device if raw paste mode is supported and flip a flag to use that mode.

So I focused on making the tests pass. I have been recording the progress on that in this issue.

This is still just the “basics” tests. We currently ignore the “extmod”, “micropython” and “float” test groups because they require dependencies (probably not float, I haven’t changed these since my early trials with run-tests.py where I wanted to get at least something to run, and I kept adding test groups to the “exclude” flag until I got there), like the unittest module to be installed at runtime (using a tool like mpremote, that once again needs Raw Paste mode).

I have made steady progress and currently, 501 out of 504 executed tests (around 16119 individual testcases) pass, 46 are skipped, and 3 are failing. As guided by my mentors, I wanted to get to this point with the “basics” tests where I could no longer just enable a feature in mpconfigport.h and make the test pass, and it is here (at least with the current set of excludes). Currently I am looking closely at the three failing testcases: builtin_compile, int_big_div and int_big_mul.

int_big_div stands out here as it mostly fails. There is no random number generation in the test, here’s the code:

for lhs in (1000000000000000000000000, 10000000000100000000000000, 10012003400000000000000007, 12349083434598210349871029923874109871234789):
    for rhs in range(1, 555):
        print(lhs // rhs)

# these check an edge case on 64-bit machines where two mpz limbs
# are used and the most significant one has the MSB set
x = 0x8000000000000000
print((x + 1) // x)
x = 0x86c60128feff5330
print((x + 1) // x)

# these check edge cases where borrow overflows
print((2 ** 48 - 1) ** 2 // (2 ** 48 - 1))
print((2 ** 256 - 2 ** 32) ** 2 // (2 ** 256 - 2 ** 32))

Looking at a diff of expected and logged outputs (expected ouptut on the right):

28258772161551968764006933464242814350651                       28258772161551968764006933464242814350651
28194254416890891209751209871858698336152                       28194254416890891209751209871858698336152
281300306027294008541847448573745124991423                    | 28130030602729408541847448573745124991423
280660987149959326133432498269866133                          | 28066098714995932613343249826986613343715
28002456767796395351181473750281428279443                       28002456767796395351181473750281428279443
27939102793208620701065678560801153554829                       27939102793208620701065678560801153554829

We see that one of the numbers seems larger than it should be, and the next one has a lot of digits missing. This might be related to the port using the MPZ module as the longint implementation, but I am currently not sure. I did try switching to MICROPY_LONGINT_IMPL_LONGLONG, but that just causes a crash, so it is also worth looking into.

I solved builtin_compile after I started writing this post. That testcase uses the __globals__ attribute on a function object, and I didn’t have that functionality enabled. So now we have 2 failing tests: int_big_div and int_big_mul. I am currently trying to fix int_big_div as I think it could be something related to the serial output. I did try calling fflush before printing stuff to the console but that didn’t fix it. And there’s of course the fact that it randomly fails. (so we have 1.5 passing testcases? :P)

I also compared the output of int_big_mul to the expected output but the diff tool just highlights the whole file so that is interesting.

more passing tests!

I also tried not ignoring the float group and got 55 more tests to pass! Here’s a snippet from the end of my latest run:

$ ./run-tests.py -t /dev/pts/2 -e "(extmod|micropython)/*"

...

559 tests performed (18668 individual testcases)
557 tests passed
55 tests skipped: async_await async_await2 async_def async_for async_for2 async_syntaxerror async_with async_with2 async_with_break async_with_return attrtuple2 builtin_help builtin_next_arg2 cexample_class cexample_module cexample_subclass class_inplace_op cmath_dunder cmath_fun cmath_fun_special exception_chain float2int_doubleprec_intbig float_divmod float_format_ints_doubleprec float_parse_doubleprec fun_code io_buffered_writer io_bytesio_cow io_bytesio_ext io_bytesio_ext2 io_iobase io_stringio1 io_stringio_base io_stringio_with io_write_ext math_constants_extra math_domain_special math_factorial_intbig math_fun_special math_isclose memoryview_slice_size nanbox_smallint print_exception rge_sm subclass_native_call subclass_native_init sys_atexit sys_exc_info sys_path sys_settrace_features sys_settrace_generator sys_settrace_loop sys_stdio sys_stdio_buffer sys_tracebacklimit
2 tests failed: int_big_div int_big_mul

Other than the test groups I explicitly ignore, the tests that are being executed are determined by run-tests.py based on the detected “minimal” (the default) configuration of the port. Before executing any tests it sends a little script to MicroPython that checks for certain features and returns a detected platform type (pre-defined). The RTEMS MicroPython port could, in the future, have its own set of test groups/individual testcases to ignore specified directly in the test runner (like the other “platforms”/ports), but the minimal configuration seems like a good set of tests for now.

raw-paste mode now works

I also mentioned raw-paste mode being a problem and how I had to comment out some lines from tools/pyboard.py to get the tests to run. Well now that is also fixed!

I started using write in my implementation of mp_hal_stdout_tx_strn instead of printf (I thought it was only used for printing characters to the screen but apparently it is also relevant for stuff like raw-paste mode) as using printf was leading to poorly formatted output that was making a lot of tests fail in the beginning. I removed the comments in tools/pyboard.py to see if the problem had changed now, but it just worked.

Raw Paste mode also brings niceties like being able to use mpremote run and mpremote connect. We can now also start looking into what’s required to be able to install mip packages to MicroPython at runtime.

I am currently working on getting the remaining tests to pass and simultaneously looking into how threads can be implemented. I looked at other ports’ implementations of this a few weeks ago so I already have some idea of it. They are not finalized yet but threads would be nice to have in the final deliverables. Networking is also something worth looking into. There are other available modules listed at docs.micropython.org that can simply be enabled, so I will be going through these and see if there’s anything there that needs implementation at the port level.

Thank you for your time!

GSoC Project Updates, Post-Midterm

Sun, 27 Jul 2025 00:00:00 +0000

We are now past the GSoC midterm and the second phase of this project is now underway. I want to quickly share what I worked on during this first week after the midterm.

The main deliverables I covered in my proposal were (we also ended up doing other things):

“MicroPython implementation (as a shell subcommand or standalone app as per discussion with mentors) - REPL and script running support.”

This is partially complete. “script running support” is a bit vague, but we do have an interactive shell and a raw mode (more on this later) for the same, along with imports from IMFS. The scope for this can be discussed.

Full support for using RTEMS APIs through MicroPython.

Implementations of the time and machine modules rely directly on RTEMS APIs. The second phase will see more such modules, along with perhaps a separate rtems module that could be used to perform specific system tasks. This is a point of discussion as we can’t use things like GPIO, I2C in the pc686 BSP that we are using for development.

Test cases for API support.

This is what I have been working on this week. MicroPython has a test suite and runner (tests/run-tests.py) that tests the unix port by default, and can test other ports by communicating with them over a serial port.

MicroPython Test Suite

MicroPython’s tests can be run for a platform (other than the default unix port) by providing a serial port to the -t flag. We can make the serial output from our test application available at a pseudoterminal using:

qemu-system-i386 --cpu core2duo -no-reboot -append "--console=/dev/com1" -serial chardev:char0 -chardev pty,id=char0,logfile=chardev.log,signal=off -kernel build/test_app.exe

We can then run the test suite using (N is the pty number assigned to the output by qemu):

./run-tests.py -t /dev/pts/N

So this didn’t work at first, and now I’ll talk about each problem I faced.

Raw REPL

I have covered this before, but MicroPython supports a “Raw” REPL alongside the normal “friendly” REPL. There’s this problem I faced early on with serial input where calls like fgets() or getchar() wouldn’t block for input. I eventually figured out the required termios flags and calls from shell-wait-for-input.c and was able to get input working. Thing is, input is line-buffered (ICANON, “canonical input” mode) so even if I send a Ctrl+A (MicroPython’s expected sequence that makes it drop into a Raw REPL), I have to send a newline after it. Sure, I can do that, but the tools won’t. They just send Ctrl+A and start listening for the Raw REPL prompt:

raw REPL; CTRL-B to exit
>

Earlier in the first phase this wasn’t a priority (the “tool” at that point was mpremote, not the test runner), so we decided to spend more time on stuff like import, the time and machine modules.

I picked this up again this week and found some “raw mode” flags from the termios man page. These, along with changes to the “micropython” readline implementation, allow us to instantly drop into a Raw REPL. The problem here is that the “friendly” input doesn’t work very well, in that we can’t see what we are typing. Fixing this is simple enough, we can just have an if-elseif-else chain and simply print the normal characters :D

Earlier I was trying to fix everything using termios flags. I think that was a mistake.

This works nicely but I have to discuss this with my mentors because a readline function now needs access to internal state (a variable, pyexec_mode_kind stores the currently active type of REPL) to work properly.

Raw Paste Mode

With that fixed, the tool was able to send Ctrl+A and the shell would immediately change to a Raw REPL, and it was also detected, but I wasn’t seeing any characters being sent. I just saw this:

That ‘R’ at the end there means that Raw Paste Mode is supported on the port. Raw Paste mode is a mode in the MicroPython Raw REPL where bytes are sent as a sequence of fixed-size windows, terminated by Ctrl+D. As soon as the terminator is received, the sent code (bytecode) is executed and the output is displayed. We are not supposed to see the bytecode being sent, just the output so the test runner can process it.

I got the tests (well, a large subset of them) to run on the RTEMS MicroPython port by commenting out these lines that try to use Raw Paste Mode if it is available, in the helper module pyboard.py.

The output can be found here.

At first it seemed to randomly stop at certain test cases, i.e. the test runner would just freeze. I tried sequentially excluding those test groups as I ran into this problem until I got it to complete. This freezing issue is encountered with three test groups, specifically “extmod”, “micropython” and “float”. There’s quite a lot of test groups besides these that amount to 452 testcases. Out of these, the RTEMS MicroPython port passes 250 tests. There are cases that are skipped automatically because there are no “settings” right now for the RTEMS port in the test runner. It is an unidentified port and the test runner uses the “minimal” test configuration, skipping a lot of tests. Many that fail could also be irrelevant to the current scope of the port. Overall, the test runner needs an “RTEMS” configuration that, like the other ports, will specifically exclude some tests and include special tests for this port.

Other than that, the freezing issue- I haven’t been able to fix it yet, but a possible reason could be that the test case code being transmitted is longer than the size of some internal buffer which rolls over by default, so MicroPython is just waiting for more input, while the test runner is waiting for the output. This would also explain the need for a fixed-window transfer mode. Even in the friendly REPL, the input buffer size is only 32 bytes, so my test programs have to be very short.

So, a big task up ahead would be to get this Raw Paste mode working so we can run all the test cases and then start working on filtering them out and enabling/implementing more features.

Thank you for your time!

I made a RISC-V SoC!

Fri, 18 Jul 2025 00:00:00 +0000

I recently finished building a RISC-V RV32I core on my GOWIN GW1NR-9 based FPGA (here’s the exact board). This was my second attempt ever at implementing some sort of instruction set. First was a CHIP-8 emulator I wrote in Python.

I want to document the features of the SoC here as I keep working on it and adding new stuff.

Current Hardware:

CPU Core implementing the 32-bit Base Integer instruction set (RV32I)
Memory-mapped UART TX, RX
6 onboard memory-mapped LEDs

Current Software:

super minimal C library with getc, getchar, putchar implemented in RISC-V assembler using the ilp32 ABI
headers with #defines for the memory map
working on a no-std Rust example
looking at picolibc as a candidate for a standard library
working on an SPI peripheral for external Flash+RAM
looking at adding a Wishbone or AXI bus for easier integration of pre-built open-source peripherals into the SoC

Fun tools I learned about while building this:

Some related links:

Verilog: HDLBits
riscv-gnu-toolchain
Open-Source RISC-V: Hazard3, SERV, Bruno Levy’s LearnFPGA Repository
RISC-V Specification

GSoC Project Updates, Mid-Term

Tue, 15 Jul 2025 00:00:00 +0000

I have completed work on all the mid-term deliverables that I finalized with my mentors and wanted to make a quick summary of the work done so far in this post.

Here’s the list of deliverables:

Getting Serial input to work
Working on an RSB Recipe
Implementing time, random and machine to be able to get uptime, reset the machine
Getting floating point values to work on the pc686 BSP
Working on an initial version of Imports (.py files mounted in QEMU)

The main branch right now is port-files.

Serial Input

This was one of the first things I worked on. We launch the built “test_app” executable using:

qemu-system-i386 \
    --cpu core2duo \
    -append "--console=/dev/com1" \
    -serial stdio \
    -kernel build/test_app.exe

The problem was that fgets or getc wouldn’t block. I looked in the the fileio sample (it takes user input after presenting a menu), and eventually found some termios flags that are set when rtems_shell_wait_for_input is called that set the terminal up for user input. The example application currently just has a call to this RTEMS shell function that properly sets up input for us:

rtems_shell_wait_for_input(STDIN_FILENO, 0, NULL, NULL);

I have identified the termios flags that this function uses but I use this “hack” right now because of the reasons discussed below.

Some more context on this is around the mpremote tool. The tool can be used to interface with MicroPython installations over serial or network. We tried it with the RTEMS Port by redirecting QEMU’s serial device to a new pseudoterminal using -serial chardev:char0 -chardev pty,id=char0 and observed that mpremote sends CTRL+A to make the default “friendly REPL” drop into a “raw REPL”. The CTRL+A (along with other codes) handling is present in MicroPython’s pyexec_friendly_repl implementation that we use. I made some progress with this and identified two sets of termios flags where each lets us use either the friendly REPL or the Raw REPL properly. The goal is to have a set of flags that allow us to easily use both, or just be able to switch to the Raw REPL immediately after sending CTRL+A (which mpremote expects to happen) and the having some logic to change terminal settings. More info on the exact flags I tried can be found in my Week 5 Blog Post.

My mentors decided that getting mpremote to work is not a priority for now so I’ll pick the work-in-progress code up later from the termios_experiments branch. When we have working code for this, I’ll replace the “hack” call to rtems_shell_wait_for_input in the test application’s main function with termios code.

RSB Recipe

As per the discussions with my mentors, I’m only responsible for half of this - a Makefile that can build the port as a library, libmicropython.a and the test application test_app.exe that demonstrates available features. This was decided because my mentors suggested that learning the RSB would take up too much time. Here are the currently defined make targets:

(default): builds libmicropython.a
build/pytest.tar: archives test/test.py into build/pytest.tar
build/pytest.c: converts build/pytest.tar to build/pytest.c and build/pytest.h, allowing the test module to be imported at runtime using MicroPython
test_app: builds test_app.exe using libmicropython.a, test/init.c and test/main.c
I’m waiting for Chris, one of my mentors, to write an RSB Recipe using this, so we should have one soon. I talked about the build system progress in my week 4 and week 5 blog posts.

time, random and machine modules

I have been able to get all three modules listed in the last mid-term deliverable working. time and random are fully supported and I’m looking for feedback on their implementation. machine has many classes like Pin, I2S, PWM, etc. that I can’t enable right now because we are using the pc686 BSP with QEMU. So currently the only implemented machine functions are reset and soft_reset (which was the goal) along with 8, 16 or 32 byte read/write access to memory, making up its basic functionality outside of those protocols and GPIO.

Reference for MicroPython libraries can be found here.

Implemented features for each module:

random: all functions available after simply enabling the module
time: all functions implemented
- sleep(N): sleep for N seconds
- sleep_ms(N): sleep for N milliseconds
- sleep_us(N): sleep for N microseconds
- time(): Returns the number of seconds, as an integer, since the Epoch (defined by the port, boot time here)
- all “ticks” functions: ticks_cpu(), ticks_ms(), ticks_us(), ticks_add(), ticks_diff(), with RTEMS MICROSECONDS_PER_TICK set to 1000
- bug: time_ns() leads to an “OverflowError: small int overflow”. Currently looking into this
machine:
- mem8, mem16, mem32: allow direct memory access
- reset(): hard resets the machine using bsp_reset()
- soft_reset(): breaks out of pyexec_friendly_repl (or pyexec_raw_repl in the future), cleans up all the heap objects and runs into a goto that restarts everything

remaining in machine:
- reset_cause(): returns the cause of reset. A list can be found here
- bootloader(): used to put the device in a state where it can be upgraded to a new firmware
- interrupt related and power related functions
- classes for various peripherals like machine.Pin for GPIO, machine.I2C, machine.I2S, etc. Potential candidates for implementation on the current pc686 BSP are Timer and WDT (watchdog timer).

I had to implement the following functions to get these to work:

mp_obj_t mp_time_time_get(void)
uint64_t mp_hal_time_ns(void)
void mp_hal_delay_ms(uint64_t delay)
void mp_hal_delay_us(uint64_t delay)
uint64_t mp_hal_ticks_cpu(void)
uint64_t mp_hal_ticks_ms(void)
uint64_t mp_hal_ticks_us(void)

I also recorded some demos using asciinema:

I started this work in the modules branch and it has been merged into port-files and there have been some rebases related to the time module.

Floating Point

This turned out to be easier than expected. I only had to define MICROPY_FLOAT_IMPL in mpconfigport.h and enable floats on the BSP using CONFIGURE_RTEMS_FLOATING_POINT. I learned that i386 doesn’t have floats by default and needs a separate “i387” chip for floating point functionality. I wrote about this in my week 5 blog post.

An Initial Version of Imports

We now also have an IMFS based imports system. The previously mentioned pytest.c, pytest.h are compiled along with the test application and rtems_tarfs_load is used to load that at “/”. I implemented mp_import_stat as follows:

mp_import_stat_t mp_import_stat(const char *path) {
    char file_path[256] = { 0 };

    sprintf(file_path, "/%s", path);

    struct stat file_info;
    int ret = stat(file_path, &file_info);

    if (ret == -1) {
        return MP_IMPORT_STAT_NO_EXIST;
    }

    if (file_info.st_mode & S_IFDIR) {
        return MP_IMPORT_STAT_DIR;
    }

    if (file_info.st_mode & S_IFREG) {
        return MP_IMPORT_STAT_FILE;
    }
}

I recorded a demo for this too: imports demo. Here’s the related commit.

The Makefile could later be modified to make a tar archive of not just one file, but many in a test/modules directory that we can then import at runtime.

This completes all of the planned mid-term goals. I am currently working on the time_ns() overflow bug and making changes as per my mentors’ feedback, which has so far included:

moving the mp_hal_delay_ms implementation away from rtems_task_wake_after, to nanosleep (by switching the example from classic RTEMS Tasks to POSIX)
using bsp_reset in machine.reset instead of the call to rtems_shutdown_executive I was using earlier

I will continue to work on these small changes this week and discuss next steps and the post-midterm plan with my mentors. GSoC has been an amazing experience so far and I’m excited for the second phase of this project.

Thank you for your time!

GSoC Project Updates, Week Five

Fri, 04 Jul 2025 00:00:00 +0000

We finally have a Makefile that can generate object files for MicroPython core, along with mphalport.c (the file that uses RTEMS APIs to actually “port” MicroPython). It can also generate an archive libmicropython.a using the pre-defined lib target.

In this post I want to talk about the things I learned about Make (GNU Make specifically), ABIs and why using the correct CFLAGS and LDFLAGS is very important. We also have a test_app directory now in the port (along with a Make target, creatively named “test_app” to build it) to demonstrate linking an RTEMS application with libmicropython, the application in this case being a simple demo that outputs the so-called “friendly REPL”. I also want to cover what I’m currently doing now that we have a stable Makefile, which brings us very close to the completion of the second mid-term deliverable, i.e., an RSB Recipe.

Makefile

The build process earlier was something like this:

use MicroPython’s Makefile based build system to build core platform-independent objects (based on enabled features in mpconfigport.h).
use RTEMS’ Waf based build system to build mphalport.c along with a test application (init.c, main.c) and link everything together.

We don’t really want to have any Waf stuff in MicroPython and the ideal way to build the library should be using purely Makefiles. Enter, pkgconf / pkg-config. The Man page describes it as “a system for configuring build dependency information”, and RTEMS supports it. Package config allows RTEMS BSPs to create .pc file in a set location that we can then use with the pkg-config command like so:

pkg-config --with-path=/path/to/rtems-workspace/rtems/7/lib/pkgconfig --cflags i386-rtems7-pc686

This simply outputs the Cflags described in the i386-rtems7-pc686.pc file at the provided path. CFLAGS are simply additional switches that are supplied to a C compiler. Part of this information is ABI_FLAGS=-mtune=pentiumpro -march=pentium. The ABI, or Application Binary Interface is a specification that sits directly on top of the ISA. It standardizes aspects like register usage and calling conventions. We need to ensure that we consistently use the correct ABI flags because mixing different ABIs can lead to undefined behavior.

Similarly, we can pass --libs to the above command to print the required linker flags. We can append these and the Cflags to the as RTEMS_TARGET_CLFAGS and RTEMS_TARGET_LDFLAGS to the already defined CFLAGS and LDFLAGS in the MicroPython Makefile.

Here’s where the Makefile fun began. I have been using Makefiles in a limited manner for a long time now. I use one to generate this blog! It’s rather simple, with targets to fetch dependencies like the Tailwind compiler (this is a static site but I just prefer tailwind CSS). More about the blog Makefile some other time.

We ended up just needing to pass three variables to the make command to allow it to build libmicropython.a, regardless of the BSP: RTEMS_PREFIX, RTEMS_VERSION and RTEMS_BSP. We already know that pkgconfig files are present in RTEMS_PREFIX/lib/pkgconfig. The format of RTEMS_BSP is “arch/bsp”, so we use the subst and word commands provided by Make to extract RTEMS_ARCH and RTEMS_TARGET from this string. We use the shell command to assign the output of the pkg-config commands to RTEMS_TARGET_CFLAGS and RTEMS_TARGET_LDFLAGS. Here’s the relevant section from the Makefile:

RTEMS_ARCH = $(word 1, $(subst /, ,$(RTEMS_BSP)))
RTEMS_TARGET = $(word 2, $(subst /, ,$(RTEMS_BSP)))
RTEMS_PKGCONFIG = $(RTEMS_PREFIX)/lib/pkgconfig/
RTEMS_PKGCONFIG_PKG = $(RTEMS_ARCH)-rtems$(RTEMS_VERSION)-$(RTEMS_TARGET)

CROSS_COMPILE ?= $(RTEMS_ARCH)-rtems$(RTEMS_VERSION)-

# ... skipped some lines ...

RTEMS_TARGET_CFLAGS += $(shell pkg-config --with-path=$(RTEMS_PKGCONFIG) --cflags $(RTEMS_PKGCONFIG_PKG))
RTEMS_TARGET_LDFLAGS += $(shell pkg-config --with-path=$(RTEMS_PKGCONFIG) --libs $(RTEMS_PKGCONFIG_PKG))

We also use the extracted RTEMS_ARCH and RTEMS_TARGET to create the tools prefix, “i386-rtems7-” in this case.
Here’s a resource I found very helpful in learning more about Makefiles.

That is pretty much it. We can now run

RTEMS_PREFIX=~/rtems-workspace/rtems/7 RTEMS_VERSION=7 RTEMS_BSP=i386/pc686 make

and it creates build/libmicropython.a that we can link against. I also added a test_app directory with an init.c and main.c with an example application demonstrating how we can use MicroPython. We can build it using the Make target “test_app”.

One of my mentors suggested that learning the RSB would take up a significant chunk of time and it would be better if I worked on getting a Makefile that builds a library, and then he could step in to write the final RSB Recipe that will allow applications to very easily build the library and use it. I think the current Makefile can be used for that and we should be able to reach that milestone within the first half of next week whenever my mentor gets time to work on the Recipe.

Serial Input Fun

So we have serial input (first mid-term deliverable) working already, and the second one (RSB Recipe) should be done soon. My mentors suggested that we focus on the Makefile first because as I mentioned earlier, undefined behavior, and they highlighted that it is very much possible that we were having problems with serial input (before the hack) because of incorrect ABI flags. Now that we’re using them, I was able to confirm that the problem doesn’t go away with the new Makefile, so we were back to figuring out a cleaner way to set up input than calling some random function like rtems_shell_wait_for_input.

So I looked into the implementation of this function and found the termios flags responsible for properly setting up the terminal for user input here. We see these flags being set here:

new_term.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON);
new_term.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
new_term.c_cflag &= ~(CSIZE | PARENB);
new_term.c_cflag |= CS8;

new_term.c_cc [VMIN] = 0;
new_term.c_cc [VTIME] = 10;

rv = tcsetattr(fd, TCSANOW, &new_term);

We can have a function in our test application (remember that for now this is just an application on i386 available over a serial console. On other BSPs this would be a UART or Network).

We have been trying to get the mpremote tool to work with this port. We can expose the console over a pty by passing the relevant flags to Qemu:

qemu-system-i386 --cpu core2duo -no-reboot -append "--console=/dev/com1" -serial chardev:char0 -chardev pty,id=char0,logfile=chardev.log -kernel build/test_app.exe

and then we can use (pty number is assigned after running the above command)

mpremote connect /dev/pts/2 run ./hello_world.py

to execute scripts on the port (exciting!), but this is what I’m currently facing problems with. Getting mpremote to work is not a mid-term deliverable but my mentor mentioned during one of our meetings that it would be nice to have, so I tried to set it up today.

I looked through the termios Man page and saw what these flags did, tried various others, but currently it’s stuck here (with the above flags):

MicroPython v1.26.0-preview.133.g4739a06d5.dirty on 2025-07-05; rtems-i386/pc686 with unknown-cpu
>>> 
>>> 
>>> ^A

Ctrl-A is supposed to drop MicroPython into a “Raw REPL”. mpremote sends Ctrl-A and then has some logic that detects if we are indeed in a Raw REPL, sends the script as a string line-by-line, and then sends Ctrl-D to exit back into the normal REPL (the so-called “friendly” REPL). The Ctrl-A above is sent by mpremote, but with those termios flags, we have to add a newline for it to process Ctrl-A.

I can disable “Canonical Mode” on the console to disable line buffering and also set the VTIME to 0 to instantly get the entered characters, but that leaves this in a state where the REPL switches to the Raw REPL the instant I press Ctrl-A, and back to the friendly REPL when I press Ctrl-B, but I cannot input text into either of them, and this is the behavior I see with mpremote as well. It sends Ctrl-A, probably sends the “print(‘hello’)” inside hello.py, sends Ctrl-D, but errors out because it doesn’t get any output, and I also don’t see anything in the log beyond the REPL switching to Raw mode and exiting it and printing “OK”. These are the flags that give me this behavior:

term.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON);
term.c_oflag &= ~OPOST;
term.c_oflag |= ONLCR; /* But with cr+nl on output */
term.c_lflag &= ~(ECHO|ECHONL|ICANON|ISIG|IEXTEN);
term.c_cflag |= CLOCAL | CREAD;
term.c_cc[VMIN]  = 1;
term.c_cc[VTIME] = 0;

Floating Point

I also got the 4th deliverable done! This was expectedly very simple to do. MicroPython allows us to enable floats at build time by defining:

#define MICROPY_FLOAT_IMPL                      (MICROPY_FLOAT_IMPL_FLOAT)

To build the test_app we also need to link it with the math library by adding -lm to our gcc command. This was giving me link-time errors regarding missing symbols powf, floorf, etc. (i.e., floating point versions of math library functions).

I found out that the the i386 architecture (the Intel 80386 microprocessor) didn’t originally have an FPU (Floating-Point Unit), and that functionality existed as separate hardware in the form of the i387 chip. So I thought that this target in RTEMS didn’t have floats and I would have to use another BSP, which would not have been ideal as it would be nice to get everything working on one BSP first. I got some help on Discord regarding this, and turns out the only thing I was missing was a simple line of configuration in the test application’s init.c:

#define CONFIGURE_RTEMS_FLOATING_POINT

The application built cleanly and I was able to use floating-point values in MicroPython.

Next Steps

So Serial Input is done (mpremote is still a work-in-progress but getting it to work is more of a configuration thing that can vary widely across BSPs), we are very close to an RSB Recipe for MicroPython, and I also got floating-point values working. The remaining mid-term deliverables are:

Implementing time, random and machine to be able to get uptime, reset the machine
Working on an initial version of Imports (.py files mounted in QEMU)

I am currently looking through the RTEMS Documentation to try and implement time so we can have functionality like sleep_ms, uptime, etc. The idea behind implementing these modules, as I discussed with my mentors, was that these should be mostly BSP agnostic and will provide us some surface area to build the BSP-specific configuration upon, and I’m hoping this will help us with that.

Imports were suggested by a mentor because this BSP has a nice feature where we can pass a directory to Qemu and there’s a driver that can be enabled that will create a virtual filesystem with the files in that directory. I have seen other ports’ mpconfigport.h files containing MICROPY_VFS and seems like that is something they define a standard interface for just like with mp_hal_stdout_tx_strn and mp_hal_stdin_rx_chr. I will share more updates on this in the next blog post :)

Thank you for your time!

GSoC Project Updates, Week Four

Mon, 23 Jun 2025 00:00:00 +0000

We are about to enter the 4th week of GSoC, and my project is definitely starting to take shape! I couldn’t post updates here because I had my third year end-term exams from May 29th to June 20th. Future GSoC contributors should note that this sort of thing is not a problem, given that you discuss this with your potential mentors during the Application Period and mention it in your proposal.

I didn’t stop completely, though. I continued to participate in the weekly Organization meeting to share progress and the one I’ve set up with my mentors for project discussions. Progress was slow, and this post documents everything (I think), but here are the highlights of work after the first blog post:

fixed serial input for the MicroPython REPl
finalized mid-term deliverables
created a script to build the MicroPython library as a precursor to an RSB Recipe

Just to recap, during the application period I took the MicroPython embed port that gives us the function mp_embed_exec_str which can execute strings containing Python code. This is easy to use because the MicroPython implementation here is just a bunch of C source files without any external dependencies.

However, it’s not very useful if we want to interact with the hardware RTEMS is running on. So, I moved away from the embed port and followed MicroPython’s porting documentation that asks us to implement a few functions like readline (yes I know, the signature here is readline(vstr_t *vstr), where vstr_t is MicroPython’s variable-length string type), etc. and then we have a very minimal port.

Here’s what that looks like:

MicroPython v1.26.0-preview.135.g5139cedab on 2025-06-23; rtems-i386/pc686 with unknown-cpu
>>>

Initially my readline (heh) implementation was broken so I wasn’t able to input anything, because of two reasons:

First, I didn’t look at the function header closely and was trying to write the characters being read directly to the vstr_t* pointer.

Second. Interestingly, input functionality on the serial device (a console on QEMU in this case) was not being initialized, so my fgets() calls wouldn’t block and I got an endless stream of >>>. I looked through the fileio sample and found:

rtems_shell_wait_for_input(
    STDIN_FILENO,
    20,
    notification,
    NULL
  );

For context, this sample has a little loop that presents a menu of actions to the user, and this function is called before that menu is first printed. I found that if I remove this call, I get similar behavior in the fileio sample, i.e., it just keeps printing the menu repeatedly and doesn’t block to read user input.

I placed the call

rtems_shell_wait_for_input(STDIN_FILENO, 0, NULL, NULL);

in my example application, and got input to work! I was now able to write Python code:

MicroPython v1.26.0-preview.135.g5139cedab on 2025-06-23; rtems-i386/pc686 with unknown-cpu
>>> def test(x, y):
...     return x + y
... 
>>> test(1, 2)
3
>>> import gc
>>> dir(gc)
['__class__', '__name__', '__dict__', 'collect', 'disable', 'enable', 'isenabled', 'mem_alloc', 'mem_free', 'threshold']
>>> gc.mem_free()
3024
>>>

This nice REPL is printed by the MicroPython function pyexec_friendly_repl(), and it has a weird limitation where a single expression/statement (anything, including functions like test above) should fit within 32 characters, not a lot!

A limit made sense to me, but I wasn’t sure why this wasn’t configurable. One of my mentors pointed out the mpremote utility that is used to interact with MicroPython, so we tried to point it to the QEMU virtual console. Expectedly, it couldn’t connect to it, but we saw something interesting - the utility was trying to open something called a “Raw REPL” over the port. It would send ^A (Ctrl+A) and expect a Raw REPL to be available. After looking through the implementation of pyexec_friendly_repl a bit more, I also expected it to connect because the function does have code to handle codes like ^A (among others). Sending ^A to the function should make it execute pyexec_raw_repl, but that wasn’t happening.

I’m still trying to figure this out. It could something related to how we expose the console through QEMU. Unlikely (to me, because this is just an fgets() call under the hood, and also, I see the actual characters “^A” appear on the REPL), but RTEMS could be consuming the input. Something I’m currently inspecting is the termios flags used in rtems_shell_wait_for_input to see if there’s any flags to enable Ctrl+key combinations that are missing. This is of interest to others, including the Organization Admin as well because these flags could be used globally so people don’t have to struggle to get input working.

Mid-Term Deliverables

I have set up weekly meetings with my mentors on Mondays. Last week we finalized these deliverables for the mid-term.

This is similar to what I mentioned in my proposal: “Partial support for using RTEMS APIs through MicroPython”. In the previous post I talked about configuration across BSPs, but focusing on some support (that is general enough, like the time module) first gives us some surface area to to figure out better ways of configuration other than mpconfigport.h (if there are any).

Build System

There seems to be some confusion about it so I’ll document it here too - my current MicroPython “port” in my fork has an init.c with some startup configuration and an mpy.c with an Init task. I am aware that these two files are found in applications, not libraries.

During the Application Period I went through the Quickstart Guide in the RTEMS Documentation, that uses the Waf build system to build a “Hello, World!” application. So, when I set up my MicroPython port, I compiled the MicroPython objects using a Makefile (Micropython makes heavy use of make), compiled mphalport.c, a file that implements the input/output functions I mentioned above, using Waf, and then finally linked everything together with the application.

To package MicroPython for RTEMS, we need an RSB (RTEMS Source Builder) Recipe, and I’ll be doing that with some help from one of my mentors. The first step here is to have a script that can build MicroPython, and we cannot use Waf.

This is what I did today. Earlier I had a simple Bash script that used the old approach that kind of mixes the MicroPython Makefile and RTEMS Application wscript because of the port file, but now there is a single Makefile that generates the whole “library” (all the required object files, including the one for mphalport.c). An RTEMS application just need to link against these.

Next Steps

Progress was slow during exams, but now I’ll be able to focus more on this project. I’m hoping to make progress with some of the modules this week.

Other than the listed mid-term deliverables:

Awaiting a mentor’s feedback on the integrated Makefile, which is the first step towards an RSB Recipe
Trying to figure out the relevant termios flags to get Ctrl+key combinations to work

I’ll try to post these more frequently now. Thank you for your time!

Introducing my GSoC Project!

Wed, 04 Jun 2025 00:00:00 +0000

I will be contributing to the RTEMS Project under Google Summer of Code (GSoC) 2025!

RTEMS is an open source Real-Time Operating System. It is used in space flight, medical, networking and many more embedded devices. RTEMS currently supports 18 processor architectures and approximately 200 Board support packages. You can learn more here.

My project is titled “Implementing MicroPython Support and Packaging It For RTEMS”. MicroPython is a Python 3 implementation designed to run on microcontrollers and in other constrained environments. Being able to interact with an embedded device using Python is very cool, because you can just spin up an interpreter and start playing with the thing. No compilation and fiddling around with random vendor IDE parameters required.

This is the first post of many that I will be writing throughout the program as I work with my mentors and the larger community to add this support to RTEMS. For this post, I want to share what I’ve done so far and give you an idea of what this will look like.

During the Application Period, I created a simple proof-of-concept using a special MicroPython port which they call the “embed” port. As the name suggests, this is designed to make “embedding” MicroPython easier. The build output is a bunch of C source files with no other dependencies that you can directly include in your project and execute MicroPython code by passing it as a string to the the function mp_embed_exec_str. There’s also some other housekeeping functions like mp_embed_init, but the main functionality here is the ability to execute MicroPython code and get some output which you might decide to process further based on your application. This works for a small demo, and the fact that I was also able to bring this proof-of-concept up on actual STM32F4 hardware helped me learn more about using RTEMS with different BSPs as I had to tweak the Linker Script to get RTEMS to boot up on my board.

This, however, is not enough. We need a higher level of integration between MicroPython and the “host” system (RTEMS in this case) to really call it a “port”.

The “Porting MicroPython” page in the MicroPython docs gives an example of a very basic port. We can follow this and the source code of the other available ports to get our RTEMS port going. Currently it has a mphalport.c file that implements mp_hal_stdin_rx_chr, mp_hal_stdout_tx_strn and readline that allow us to output a MicroPython shell over serial by calling pyexec_friendly_repl() in our main code. We can’t yet enter things into the shell so that needs to be fixed.

You can take a look at the current mphalport.c and the main mpy.c. Additionally, mpconfigport.h is used to enable and disable features like the machine module at compile-time.

Now here’s the problem - we need this to work across a lot of different boards (RTEMS BSPs or “Board Support Packages”). Taking a simple example like machine.SPI in MicroPython, not all BSPs might have SPI support, and it’s not a good idea to compile all of this code and take up useful Flash space on a device that doesn’t have those features.

Here’s my current mental model of what this could end up looking like:

An ideal solution would really be one that simply doesn’t build features that aren’t available on the BSP being used. Let me quickly go through the ones discussed in the diagram:

Simply using `mpconfigport.h`

So we include the MicroPython library, and it will be a requirement for all applications that use this library to define this config file. If you’re wondering what this file looks like, here you go:

#include <stdint.h>

// Python internal features.
#define MICROPY_ENABLE_GC                       (1)
#define MICROPY_HELPER_REPL                     (1)
#define MICROPY_ERROR_REPORTING                 (MICROPY_ERROR_REPORTING_TERSE)

#define MICROPY_READLINE_HISTORY_SIZE           (0)

// Fine control over Python builtins, classes, modules, etc.
#define MICROPY_PY_ASYNC_AWAIT                  (0)
#define MICROPY_PY_BUILTINS_SET                 (0)
#define MICROPY_PY_ATTRTUPLE                    (0)
#define MICROPY_PY_COLLECTIONS                  (0)
#define MICROPY_PY_MATH                         (0)
#define MICROPY_PY_IO                           (0)
#define MICROPY_PY_STRUCT                       (0)

// Type definitions for the specific machine.
typedef intptr_t mp_int_t; // must be pointer size
typedef uintptr_t mp_uint_t; // must be pointer size
typedef long mp_off_t;

// We need to provide a declaration/definition of alloca().
#include <alloca.h>

// Define the port's name and hardware.
#define MICROPY_HW_BOARD_NAME "rtems-i386/pc686"
#define MICROPY_HW_MCU_NAME   "unknown-cpu"

#define MP_STATE_PORT MP_STATE_VM

You can see that we have a lot of control over Python builtins like set, collections, etc. We can also choose to define things like MICROPY_PY_MACHINE to build the machine module that further gives us access to machine.I2C, machine.SPI and friends. If you look at how the Zephyr Port does it, you’ll notice some interesting definitions:

#define MICROPY_PY_MACHINE          (1)
#define MICROPY_PY_MACHINE_INCLUDEFILE "ports/zephyr/modmachine.c"
#define MICROPY_PY_MACHINE_I2C      (1)
#define MICROPY_PY_MACHINE_SPI      (1)

namely MICROPY_PY_MACHINE_I2C and MICROPY_PY_MACHINE_SPI.

These are used to conditionally compile I2C and SPI support in machine_i2c.c and machine_spi.c. I think this is probably going to be how we specify the features we want to include. So based on the BSP being used and our requirements, we create a config file to enable the relevant MicroPython internal features and modules.

There will of course be examples config files and documentation for the supported “flags” here.

Higher Level Configuration

This is still a bit vague, but it would be neat if there was a way to enable/disable support without leaving the Python environment / using a high level config file (not sure what that would look like yet) / automatically selecting features based on the BSP being used.

This post was supposed to come out sooner (last week) but here we are, in week 1 of GSoC 2025! I am currently looking into the RTEMS Source Builder (RSB) and create a “recipe” so my “port”, which is right now more of a test application can be used as a library. So basically I will remove mpy.c (contains the actual “program” entry point) and mpconfigport.h out of the “port”, write an RSB Recipe so that I can include it in an RTEMS Application where I will have the main code along with the config.

Thank you for your time.

Baby's First UART on FPGA

Sun, 23 Feb 2025 00:00:00 +0000

So I got this Sipeed Tang Nano 9K FPGA development board recently (last year), and I wanted to write a bit about what I did as one of my first little projects, just to get this blog started.

As the title suggests, I implemented a UART controller. I started by making a tx module that would print an “S” over the serial console when I pressed a button. Then I implemented an rx that received a byte and displayed it using the onboard LEDs.

I will write about the tx (Sender) part because I think people would find that more interesting. Before I explain the Verilog logic, let me tell you about a UART Frame:

Here’s what a UART frame looks like:

start bit: UART wires (rx and tx) are pulled high (in state 1) by default. UART works in a master-slave configuration so there is always a sender and receiver. To begin a transmission, the sender pulls its tx low. This is called the “start bit”.
d0..d7: This is the byte being transmitted, LSB first.
pb: Parity Bit. UART devices agree on Even, Odd or No parity. I went with Even parity.
stop bit: similar to the start bit, the sender sends the line high again to end the frame. UART doesn’t specify a frame length, but the typical UART frame has 1 start bit, 8 data bits, an optional parity bit and 1 stop bit.

UART operates on a “baudrate” concept, in contrast with other serial protocols like I2C and SPI that need separate clock lines to synchronize the data between sender and receiver. UART sender and receiver agree on a baudrate, basically listening for and sending data after the same time intervals, eliminating the need for a separate clock wire. Baudrate here is 115200 and it is specified using the CLK_PER_BIT parameter, calculated based on the FPGA’s clock frequency. (27 MHz)

Here’s the module (Verilog):

module uart_tx #(
    parameter CLK_PER_BIT = 234
) (
    input       clk,
    input       start,
    input [7:0] data,
    output reg  tx
);

assign start_tx = start;

localparam BTN_PRESS_TIMEOUT = 27000000;

localparam S_IDLE       = 4'b0000;
localparam S_START_BIT  = 4'b0001;
localparam S_SEND_BYTE  = 4'b0010;
localparam S_PARITY_BIT = 4'b0011;
localparam S_STOP_BIT   = 4'b0100;
localparam S_DELAY      = 4'b0101;

reg [3:0] state = S_IDLE;
reg [7:0] data_reg = 0;
reg data_parity_reg = 1; // even parity

reg [31:0] counter = 0;
reg [4:0] bit_index = 0;

initial tx = 1;

always @(posedge clk) begin
    case (state)

        S_IDLE: begin
            if (start_tx) begin
                data_reg <= data;
                data_parity_reg <= 1;

                state <= S_START_BIT;
            end
            else begin
                state <= S_IDLE;
            end
        end

        S_START_BIT: begin
            tx <= 0;

            if (counter < CLK_PER_BIT-1) begin
                counter <= counter + 1;
                state <= S_START_BIT;
            end
            else begin
                counter <= 0;
                state <= S_SEND_BYTE;
            end
        end

        S_SEND_BYTE: begin
            tx <= data_reg[bit_index];

            if (counter < CLK_PER_BIT-1) begin
                counter <= counter + 1;
                state <= S_SEND_BYTE;
            end
            else begin
                counter <= 0;

                if (bit_index < 8) begin
                    bit_index <= bit_index + 1;
                    state <= S_SEND_BYTE;
                end
                else begin
                    bit_index <= 0;
                    state <= S_PARITY_BIT;
                end
            end
        end

        S_PARITY_BIT: begin
            tx <= data_parity_reg;

            if (counter < CLK_PER_BIT-1) begin
                counter <= counter + 1;
                state <= S_PARITY_BIT;
            end
            else begin
                counter <= 0;
                state <= S_STOP_BIT;
            end
        end

        S_STOP_BIT: begin
            tx <= 1'b1;

            if (counter < CLK_PER_BIT-1) begin
                counter <= counter + 1;
                state <= S_STOP_BIT;
            end
            else begin
                counter <= 0;
                state <= S_IDLE;
            end
        end

    endcase
end


endmodule

I know this is shit code and kind of naive because state transitions should be handled separately in a clocked always block, and the corresponding logic for each state should be handled in a combinational logic block. Just trying to record how I did it as a noob.

Let me explain how this works, piece by piece:

module uart_tx #(
    parameter CLK_PER_BIT = 234
) (
    input       clk,
    input       start,
    input [7:0] data,
    output reg  tx
);

This is the module declaration. It is the “function header” or the “interface” which usually follows this kind of structure - the module name followed by parameters, followed by port specification (clk here is a 1-bit input, data is a 7-bit input, etc.). Parameters are constant values that can be passed into the module when it’s instantiated. We can use parameters for many things, from controlling bus widths to conditional compilation using ifdefs.

Scrolling down, we see a bunch of localparams:

localparam S_IDLE       = 4'b0000;
localparam S_START_BIT  = 4'b0001;
localparam S_SEND_BYTE  = 4'b0010;
localparam S_PARITY_BIT = 4'b0011;
localparam S_STOP_BIT   = 4'b0100;
localparam S_DELAY      = 4'b0101;

These are the states for the finite state machine that generates the actual UART output.

Numbers are specified in Verilog in the format: <width>'<format><value>. Widths of all assignments to the localparams here are 4, the format we’re using is binary (b) and then the values have been specified using that format. We could also do 4d0, 4d1, 4d2…

reg [3:0] state = S_IDLE;
reg [7:0] data_reg = 0;
reg data_parity_reg = 1; // even parity

reg [31:0] counter = 0;
reg [4:0] bit_index = 0;

initial tx = 1;

reg stands for “register”. These are basically mutable variables from a language PoV. state stores the current state, and I have set it up to have the initial value of S_IDLE (0). data_reg stores the actual byte to be transmitted. data_parity_reg stores the parity bit. The byte being transmitted here is the ASCII value of ‘S’, i.e. 83 (1010011), which has an even number of 1s. Since we are going with an even parity setup, we hardcode the parity as 1.

counter is used to maintain the baudrate using this bit of redundant code in every state (by counting up to CLK_PER_BIT):

if (counter < CLK_PER_BIT-1) begin
    counter <= counter + 1;
    state <= S_SEND_BYTE;
end
else
	// state logic, transitions
end

bit_index is the bit position in the byte being sent, starting from LSB.

tx has already been declared as reg in the module declaration, so we just set it to have the initial value of 1.

When control moves into the else block, the actual operation(s) related to that state can be performed, like sending the start bit, data bits, parity bit and stop bit.

With this, the UART tx was done. I went on to make an rx (receiver) core that, well, does the opposite of this and samples at the baudrate instead of transmitting, and I was able to display the data I sent using Python pyserial on my laptop using the 6 LEDs on my FPGA board. I further connected the two cores to make an “echo”, where I would send some character using Python and receive that character back. I will write about the rx and echo bits in the future after some refining. Instead of supporting only single characters, I would like to use a small buffer with it so I can echo back any number of characters.

That’s it for the first blog post! Thank you for your time.

blog.bkpt.party

GSoC Project Updates, Threads!

threads

final work

GSoC Project Updates, Progress with MicroPython Tests

more passing tests!

raw-paste mode now works

GSoC Project Updates, Post-Midterm

MicroPython Test Suite

Raw REPL

Raw Paste Mode

I made a RISC-V SoC!

GSoC Project Updates, Mid-Term

Serial Input

RSB Recipe

time, random and machine modules

Floating Point

An Initial Version of Imports

GSoC Project Updates, Week Five

Makefile

Serial Input Fun

Floating Point

Next Steps

GSoC Project Updates, Week Four

Mid-Term Deliverables

Build System

Next Steps

Introducing my GSoC Project!

Simply using mpconfigport.h

Higher Level Configuration

Baby's First UART on FPGA

Simply using `mpconfigport.h`