STM32 F7 Discovery

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
mapy
Posts: 9
Joined: Sat Sep 29, 2018 9:49 am

Re: STM32 F7 Discovery

Post by mapy » Fri Sep 20, 2019 1:06 pm

Yes, regarding git rebase, how will be the required steps for this specific case. I have successfully cloned the https://github.com/forester3/micropytho ... f7disc-lcd , compiled and deployed. I´ve read about rebase command but it is not clear enough for a beginner like my.

Thank you very much.

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: STM32 F7 Discovery

Post by jimmo » Fri Sep 20, 2019 3:09 pm

"rebase" is how you tell git that you'd like to replay a set of commits from a different branch onto your current branch. So the simple case is:

- clone some repo
- do some work on a branch (commit A, B, C)
- meanwhile, the upstream repo moves forward
- now you're behind, so you fetch upstream, then rebase your branch

In this case, that branch is someone else's branch (forester3).

Code: Select all

git clone git@github.com:micropython/micropython.git
cd micropython
git remote add forester3 git@github.com:forester3/micropython.git
git checkout f7disc-lcd
So now we're on forester3's f7disc-lcd branch, in a repo that has two remotes: origin=micropython/micropython, forester3=forester3/micropython

Code: Select all

git fetch origin
git rebase -i origin/master
This will do an "interactive rebase", showing the set of commits that are going to be rebased. It should just be forester3's commits. Close that, and it will run.

Now what happens is for every commit it attempts to replay it on top of master, and asks us to deal with the conflicts.

OK at this point I retract my "fairly straightforward" comment... sorry. This was complicated because of three things:
- This branch introduced it's own SDRAM controller (conflicts with recent work in MicroPython)
- The README.md was updated a bunch (lots of conflicts because this file changes occasionally)
- They changed the stm32lib submodule version (not sure why)

I did the rebase myself and the results are here -- https://github.com/jimmo/micropython/tr ... cd-rebased

I undid all the sdram changes (except for the linker script so that the ST code has the right symbols), and did some quick hacky fixes to deal with the change to the hal_conf headers. The way this driver works (using the ST reference code) is unlikely to be able to be merged upstream, so I didn't try too hard to make it neat.

But unfortunately I do not own this board (I only have a similar F769disco) so I cannot test it. The branch above does compile, but I have no idea if it will work. At some point I'll try adapting it to my board (I've always wanted to get the LCD working) but probably won't be able to get to this for a couple of weeks.

If you want to try out building that branch, I'd be keen to know how you go.

mapy
Posts: 9
Joined: Sat Sep 29, 2018 9:49 am

Re: STM32 F7 Discovery

Post by mapy » Sat Sep 21, 2019 9:49 pm

Hello jimmo, I´ve tried your branch and works very well, thank you very much.
I had an issue compiling because not finding the stm32746g_discovery_sdram.h I've compied from forester repo and that's all.

I was a bit surprised about the welcome screen in the REPL I was expected to see 1.11 but it is:
MicroPython v1.9.3-2150-ge28185c on 2019-09-21; F7DISC with STM32F746
Do you have any explanation?

As you mentioned finally it was not easy to rebase forester code, I hope we will have soon a more convenient way to add C libraries to the ports.

Thank you very much.

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: STM32 F7 Discovery

Post by jimmo » Sun Sep 22, 2019 2:17 am

mapy wrote:
Sat Sep 21, 2019 9:49 pm
I had an issue compiling because not finding the stm32746g_discovery_sdram.h I've compied from forester repo and that's all.
Ah sorry about that -- actually this file isn't needed, but I forgot to remove the #include. I've updated the branch. https://github.com/jimmo/micropython/tr ... cd-rebased
mapy wrote:
Sat Sep 21, 2019 9:49 pm
I was a bit surprised about the welcome screen in the REPL I was expected to see 1.11 but it is:
MicroPython v1.9.3-2150-ge28185c on 2019-09-21; F7DISC with STM32F746
Do you have any explanation?
Hrmm, I think this means you're still running forester3's version.

Code: Select all

$ strings build-STM32F7DISC/firmware.elf | grep F7DISC
MicroPython v1.11-329-ge28185c73-dirty on 2019-09-22; F7DISC with STM32F746
mapy wrote:
Sat Sep 21, 2019 9:49 pm
As you mentioned finally it was not easy to rebase forester code, I hope we will have soon a more convenient way to add C libraries to the ports.
I think the issue here was that this LCD driver just wasn't written in the same style as regular MicroPython drivers. It was nice to be able to reuse the ST driver, but ST drivers are written with a very different use case in mind. There are lots of other good examples of port-specific C libraries.

User avatar
ta1db
Posts: 53
Joined: Mon Sep 02, 2019 12:05 pm
Contact:

Re: STM32 F7 Discovery

Post by ta1db » Sun Sep 22, 2019 5:57 pm

@jimmo

Code: Select all

git clone -b f7disc-lcd-rebased https://github.com/jimmo/micropython.git
cd micropython
git submodule update --init
cd mpy-cross
make
cd ../ports/stm32
make BOARD=STM32F7DISC
built and worked flawlessly, firmware has both lcdF7D, tchF7D and the latest modules like ssh etc, upip also worked without any problem, all OK !

Thanks.

However I couldn't make the rebase by myself, I got some errors, I will try again.

On the other hand I appreciate very much similar help to make our own driver instead of clone and rebase an existing one :roll:

mapy
Posts: 9
Joined: Sat Sep 29, 2018 9:49 am

Re: STM32 F7 Discovery

Post by mapy » Sun Sep 22, 2019 9:10 pm

Hello, I´ve followed same steps as ta1db , except make command as I needed to specify the libgcc.a location (as I saw in other post):
make BOARD=STM32F7DISC LIBS="/usr/lib/gcc/arm-none-eabi/4.9.3/armv7e-m/fpu/libgcc.a"
I see two issues:
I still don't undestand why jimmo's REPL welcome is (not V1.11) :
MicroPython v1.9.3-2150-g3e32db2 on 2019-09-22; F7DISC with STM32F746
clearly different form forested one:
MicroPython v0.4.1-f7dlcd on 2019-09-21; F7DISC with STM32F746.

Testing jimmo's branch I see a kind of "missing pixels" when wrinting strings (that does not happend in forester code), executing next simple code:

import lcdF7D
lcdF7D.init()
lcdF7D.set_font(20)
lcdF7D.display_string_at_line(1,"Hello world!!")
lcdF7D.display_string_at_line(2,"Hello world!!")
lcdF7D.display_string_at_line(3,"Hello world!!")
lcdF7D.display_string_at_line(4,"Hello world!!")

always the last line is not propertly written and shows missing pixels, if you write another line, the previous is filled with the missing pixels.

Please ta1db could you check what version is reported in REPL and test this simple code and look to the last line to see if this effect also happen to you.

Thank you very much.

User avatar
jimmo
Posts: 2754
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: STM32 F7 Discovery

Post by jimmo » Mon Sep 23, 2019 12:13 am

ta1db wrote:
Sun Sep 22, 2019 5:57 pm
However I couldn't make the rebase by myself, I got some errors, I will try again.
Yeah you'll see a bunch of conflicts which need to be resolved manually.
mapy wrote:
Sun Sep 22, 2019 9:10 pm
Testing jimmo's branch I see a kind of "missing pixels" when wrinting strings (that does not happend in forester code), executing next simple code:
I'm glad it works at all :p

I think it's fairly like that this is due to the fact that it's put the framebuffer in the region now available to the heap, so micropython is interfering with it.

It actually needs the full sdram size (64 Mb) for the framebuffer, so the best thing to do is just to prevent the heap from using sdram (use internal sram only). In board/stm32f7disc/mpconfigboard.h, comment out these two lines like so:

Code: Select all

// #define MICROPY_HEAP_START              sdram_start()
// #define MICROPY_HEAP_END                sdram_end()
ta1db wrote:
Sun Sep 22, 2019 5:57 pm
On the other hand I appreciate very much similar help to make our own driver instead of clone and rebase an existing one
I'm not sure that's an easy thing to do over the forum... but here's a rough idea where I'd start. (Sorry it's a really complicated driver).
- Split out the pin definitions from the driver into mpconfigboard.h so they can be used in different boards
- Move the DMA2D and LTDC stuff into a generic MicroPython driver
- Make the SDRAM framebuffer configuration more generic (maybe make it use the MicroPython framebuf class).

User avatar
ta1db
Posts: 53
Joined: Mon Sep 02, 2019 12:05 pm
Contact:

Re: STM32 F7 Discovery

Post by ta1db » Mon Sep 23, 2019 4:47 am

mapy wrote:
Sun Sep 22, 2019 9:10 pm
Please ta1db could you check what version is reported in REPL and test this simple code and look to the last line to see if this effect also happen to you.
@mappy
My welcome message is same of yours:
MicroPython v1.9.3-2150-g3e32db2 on 2019-09-22; F7DISC with STM32F746
However I don't see a problem in display. When I run the following code as to start from line 0 to 13, the screen becomes full, only the line 13 characters are displayed about half height probably because of display pixel size.

Code: Select all

import lcdF7D
lcdF7D.init()
lcdF7D.set_font(20)
lcdF7D.display_string_at_line(0,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(1,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(2,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(3,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(4,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(5,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(6,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(7,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(8,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(9,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(10,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(11,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(12,"Hello world!! Hello world!! Hello!")
lcdF7D.display_string_at_line(13,"Hello world!! Hello world!! Hello!")

JohnieBraaf
Posts: 9
Joined: Mon Jan 06, 2020 12:08 am

Re: STM32 F7 Discovery

Post by JohnieBraaf » Fri Aug 20, 2021 11:37 am

There is a very nice graphical library available LVGL which has a binding for Micropython and drivers for the STM32F7 Discovery.

See: https://github.com/lvgl/lv_binding_micr ... TM32F7DISC
And: https://github.com/lvgl/lv_binding_micr ... ed_demo.py

It seems to work pretty smoothly and make use of the double buffering capabilities. :D

tonyek
Posts: 2
Joined: Tue May 12, 2020 1:28 pm

Re: STM32 F7 Discovery

Post by tonyek » Sun Oct 23, 2022 11:32 am

Hi I've got one of these boards and I can get the display to work using
firmware_v1.12-210_LCD_TS_DFP_Thread_STM32F7DISC.hex

But I've tried using the new firmware for this board STM32F7DISC-20220618-v1.19.1.hex
and I can't get to work. lcdF7D driver is no longer used in the new firmware.
Does anyone know which driver is now being used.

Post Reply