Hi,
I have just downloaded the RTL8722DM port of MicroPython to my Ameba RTL8722DM mini board and feel there are some shortfalls compared with other processor implementations, these are:
No information on the pin names to use with the Pin object in the documentation (have tried both PA_23 and PB_23 to flash the on-board LED, but nether work.)
Does not run ‘boot.py’ or ‘main.py’ from an SD card.
No way to run a script on an SD card.
No way to download/upload scripts to flash memory (normally can use Pycom’s Pymkr plugin tool in VS Code to do this with certain versions of the ESP32 board.)
Dose not work with the Adafruit ampy command line tool.
Without these features, I feel the implementation is very limited and will make the board unattractive to the MicroPython community.
Hi @twister ,
Thanks for the feedback! MicroPython has been ported for RTL8722DM and open-sourced for a year but not much has been heard from users about the their feedback, so its hard to decide how much/what should be invested into this port.
Thankfully we are getting some feedback from the community, so we will look into all the points you mentioned here and see what should be focused on next.
A few things to notice:
The current MicroPython port is for RTL8722DM(aka the bigger board), thus many pins are unusable on the MINI and some of the MINI’s pins can not be controlled either, but this can be fixed fairly quickly and will be dealt with at higher priority.
The current SDFS module has been implemented in the way that is only for demonstration purpose, more works have to be done to implement Virtual File System(VFS) on MicroPython so that file on SD card can be recognized and run.
In order to download script directly into flash/SD card memory, there are 2 works have to be done-- 1) special extension for the IDE(in this case, the Pymkr), 2) An UF2 (USB Flash Format) bootloader. The former is easy and we can use the existing ones, but the latter one takes a lot of work as some of the bootloaders are not meant to be altered, we need to study and make sure it works and not sabotaging the MCU’s booting sequence.
This is new. Is it popular now? I have never heard of it before
From your perspective, which one of the 5 points you listed above is most important to you?
Hi @xidameng,
Thank you for your detailed reply to my points, I appreciate it.
Point 3 would be my number one priority, as this would make MicroPython ideal for rapid development. Having said that, I fully appreciate that you must target your development efforts where they are going to deliver most benefit to your customer base. Also, I have to acknowledge that MicroPython does not give the best performance compared with C/C++ development using the sdk or Arduino IDE.
Thanks @twister for your feedback, I also think this is important, we will look into this soon and update you again should there be any progress
Meanwhile, the best way to stay up to date with this MicroPython port development is to join the Ameba IoT Facebook group, we will post new features, demonstrations or development progress there more frequently~
I’ve briefly reached out on the Facebook group “MicroPython & Pything”; I run the Melbourne MicroPython Meetup and would like to help update your RTL8722DM port of MicroPython so that it could be considered as a PR for MicroPython upstream. I think the 8722DM could be a great addition to the MicroPython family.
I agree with @twister that there are a few rough edges - but I’m sure we can sort them out!
Currently I’m having difficulty accessing the technical documents (datasheets etc) as I can’t seem to reset my login password. Maybe with your help we can resolve this?
I have the larger 8722DM board and have ordered a Mini - I’d like to have MicroPython running on them both. Typically we’d create an ameba port and there’d have a board definition for each of the two boards which would configure the behaviour of the port. This should be fairly straightforward to implement.
I have some experience with filesystem issues so I’m sure we can figure them out. I don’t think it’s important for ampy to be supported but, if it doesn’t work, it’s likely that mpremote won’t work either - and that is critical.
Is this the best place to discuss the MicroPython port?
Hi @mattyt ! I am a big fan of your work, watched almost all the videos about MicroPython on Youtube because at the time I was porting for RTL8722, there is very little to no useful information about porting, so I had to search low and high for anything useful.
Fortunately , now MicroPython repo has some major updates and the online docs also look way better and more informative than before.
Yes, definitely, we can discuss it here or on Github if you prefer. Either way, let’s keep our discussion somewhere so that other developer can refer in the future~
Nice getting connected with other MicroPython developers on Facebook, let me add that Ameba also has an dedicated Facebook group (English) and we can bring some discussion there if we want to reach out to broader audience
A walkaround here is to download them directly from the Github repo at,
If you are having trouble logging into the official website, please try another email, if the issue persists, you can contact me directly on Facebook, here is my Facebook account,
Great! I was having trouble implementing VFS on this port as many VFS APIs have differed greatly from the original fatfs APIs which is currently used in the Realtek Standard SDK (equivalent of the IDF to ESP32)
I have been looking into this port fairly recently, and it seems to me the way the micropython is built is a little bit strange. The port uses its own (old) arm toolchain, which is embedded into the git repo.
Trying to build with an updated toolchain by removing the references to the embedded toolchain was so far unsuccessful for me; I have got as far as starting to edit the Makefiles for the project to get it to compile.
I have 3 of the full size boards and I also have 5 of the mini boards, and was hoping to get micropython running on the mini board soon-ish.
@mattyt - I see you’re in Melbourne; I’m in Brisbane so maybe being in the same timezone we can easily collaborate (although this is a skunkworks project for me so will be more or less out of work hours).
Over the next week or so I will get the build system fixed so that it will work using the system arm compiler (rather than the embedded one), and also so it will build in the correct directory. I will take cues from the STM32 port, which seems to be arranged well (and also deals with several different board varieties, so the mini- and normal- board versions can be similarly dealt with).
I have forked the micropython github repo; when I have the build system working I’ll push it and create a pull request. Then we can look at how to integrate upstream micropython developments.
The other thing about this port is there are a couple of tools used post-compile to arrange the binary upload. These have source in the repo, which is good; however looking at the source of at least one of them (don’t remember which off the top of my head sorry) it would be much better implemented as a shell script (it only calls some system utilities to arrange binaries IIRC).
Thanks for the feedback, I ported MicroPython to RTL8722DM about 1 year ago based on another maker’s port for RTL8195AM(also from Realtek), around that time there were very little documentation available online thus the porting work was more of a trial-and-error, and it has detached from the upstream since then (around 2019).
You can find out more about what I have done for this port on
It’s late here (we had the Melbourne MicroPython Meetup tonight!) but, just quickly @mvdw, hi, nice to meet you! And yes, it’s a little different to mainline; nothing we can’t fix though. I found building it straightforward however, try running this from the root of the amdb clone (may need to tweak $(pwd) if you’re not using WSL:
docker run -ti --rm -v $(pwd):/micropython --workdir /micropython micropython/build-micropython-arm bash -c "make -C MicroPython_RTL8722/mpy-cross && make -C MicroPython_RTL8722/ports/rtl8722"
Thanks to the active feedback from the community, we are also working on new low-level peripheral features and adding MacOS toolchain to supporting building on Mac.
If you you have some other preferred platform to discuss about the the future plan, please let me know, we can have a chat group over there to discuss more freely~
As a matter of fact, I would also like this port to rejoin the micropython upstream so as to keep the kernal updated, so it will help me greatly if you can share some tips on that
Although I use MicroPython as part of my day job, porting this would have to be done out-of-hours for me too. But yes! Being in the same timezone definitely helps. Happy to have an evening zoom call or whatever to discuss some of the details (offer goes to you too @xidameng).
The stm32 port is the most mature so it’s a good one to follow, though it’s also one of the most complex since it supports a handful of chip families and dozens of boards. In this case, both the IoT Dev Board and the mini use the same chip - the RTL8722DM so the port (ie the code) should be identical for those boards. However, the board definition (the board folder inside the port) will differ so that only the appropriate pins and features are available for that board configuration.
Even if we add support for the 8195AM it’s only a couple of micros rather than many like the stm32 port.
Maybe looking at the rp2 port might be a better bet; it’s much simpler and includes TinyUSB which we may also need to tackle (the RTL8722DM supports USB and it would probably be easiest to add support to TinyUSB and use that in MicroPython).
I help run the MicroPython Slack Channel (get an autoinvite here), maybe that would be a better place to discuss further? Happy to continue discussing things here if it’s easier…
I’d like to see it upstream too! It will be easier to keep up-to-date and more closely aligned with other ports. @mvdw has already identified some of the changes that would need to occur - reworking some locations of files and tidying up the use of some of the custom tooling. Generally everything is in a flat structure under a folder like ‘ports/ameba’. The SDK ought to be a submodule, maybe the tooling too. I don’t think it’ll take much to nudge what you have to make it compatible with typical upstream ports…
I just joined the Slack~ I think it would make it a lot easier to manage all the inccming msg on Slack, but ocassionally, we can bring our discussion here so that more Ameba hardware users can also give their feedback, that would be great~
The current RTL8722DM port is structured in the way that almost everything is done within the ports/rtl8722 folder thus no changes to the outer layer, tooling was put inside bcos of the same reason, and as for the embedded GCC toolchain, it is specially chosen bcos Realtek has reworked the toolchain and produce ones with their own flavor in it thus it works slightly different from the generic GCC ARM toolchain, I haven’t tested the latest toolchain yet, not sure what will happen
