MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

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.
OutoftheBOTS_
Posts: 627
Joined: Mon Nov 20, 2017 10:18 am

Re: MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

Post by OutoftheBOTS_ » Mon Jul 22, 2019 9:24 am

Roberthh wrote:
Mon Jul 22, 2019 8:17 am
Using the mem_xx() functions is very slow. For initialization, that's fine. But for other operations like setting coordinates or data transfer using native code and direct pointers is way faster. I used that for my SSD1963 driver (https://github.com/robert-hh/SSD1963-TF ... or-PyBoard), which uses 8 bit parallel data transfers. The file TFT_io.py contains the functions for accessing the memory, both native and assembly code. Native code only takes twice the time of assembly code, but is much easier to write and maintain, since the control structures of Python are available.
Geez I now have so many question to ask you Roberthh

Q1. What's the difference between machine.mem16[] and ptr16 ???

Q2. considering that you resorted to using assembler for speed why didn't you write it in C and then just compile into the firmware??

Q3. why did you bit bang in software instead of using the FSMC HW peripheral?? The HW peripheral is much faster than bit bang and a little less programming to make it work. The FSMC also can make use of DMA to write large blocks of data at insane IO speeds to the TFT, using DMA I could update the TFT GRAM quicker than it could refresh at the screen at 50hz

User avatar
Roberthh
Posts: 1517
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

Post by Roberthh » Mon Jul 22, 2019 10:00 am

I made that code very early in my Python & MicroPython learning phase. So, about your questions:

Q1: ptr16 is a pointer much in the sense of C. It directly points to memory like a C Pointer. There are not safebelts when using it. A pointer access is directly compiled into a few assembler instructions. I tried mem16 operations, and found that each of them require a few µs.
Q2: When I wrote that, I was not ready yet for writing C code module for MicroPython. And I did /and do) not like a s special firmware for that purpose.
Q3: It seemed easier that way, starting form an Arduino C implementation. I could consider using FSMC. Not sure if it is possible. The TFT is not memory mapped. And some of the my operations require reading byes, modifying them and writing them back, because the frame buffer is on the TFT, not in the MPU's RAM. For my actual use case the slowest part is reading image data from a SD card (~600ms for a 480x800 RGB16 image).

OutoftheBOTS_
Posts: 627
Joined: Mon Nov 20, 2017 10:18 am

Re: MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

Post by OutoftheBOTS_ » Mon Jul 22, 2019 10:22 am

Thanks for your answers Roberthh

You can use FSMC to both write and read from the GRAM of the TFT exactly the same as your bit bang version.

And I found the same thing once that I went to 16bit FSMC that IO to the screen was now way quicker than any other part of the pipleine. I used DMA to stream from a OV cam using the DCMI to the TFT and TFT could go as fast as the cam could go and as said on last post that using DMA I could update the TFT GRAM faster than it could refresh the screen.

Anyway the guys that are trying to port my C implementation of FSMC to python will do much better using ptr32 and ptr16 instead of machine.memxx[]

DJShadow1966
Posts: 13
Joined: Sun Jun 23, 2019 4:55 am
Location: Gateshead, Tyne and Wear

Re: MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

Post by DJShadow1966 » Mon Jul 22, 2019 10:46 am

Helllo

Many thanks for all the help that has been provided.

Is there any tutorials for how to use the ptr32, ptr16 and a little stuck on that.

Regards Mike

User avatar
Roberthh
Posts: 1517
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

Post by Roberthh » Mon Jul 22, 2019 10:53 am


DJShadow1966
Posts: 13
Joined: Sun Jun 23, 2019 4:55 am
Location: Gateshead, Tyne and Wear

Re: MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

Post by DJShadow1966 » Tue Jul 23, 2019 2:39 pm

Hello

Just received my 2nd vet board and currently working on writing code so I can fully utilize the W5500 chip I have found that the board / micropython doesnt request a IP address from my server.

Mike

DJShadow1966
Posts: 13
Joined: Sun Jun 23, 2019 4:55 am
Location: Gateshead, Tyne and Wear

Re: MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

Post by DJShadow1966 » Wed Jul 24, 2019 8:05 am

Hello

What would be the best options for LAN, I seem to be stuck as the W5500 module I have isnt getting the right IP from the DHCP server, I have just ordered a LAN8270 RMII module as this seems to be fully supported on the MCU.

The W5500 module doesnt have a MAC address which is why it doesnt work, I hold better for the LAN8270 module.

Regards Mike

OutoftheBOTS_
Posts: 627
Joined: Mon Nov 20, 2017 10:18 am

Re: MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

Post by OutoftheBOTS_ » Wed Jul 24, 2019 10:51 am

DJShadow1966 wrote:
Wed Jul 24, 2019 8:05 am
Hello

What would be the best options for LAN, I seem to be stuck as the W5500 module I have isnt getting the right IP from the DHCP server, I have just ordered a LAN8270 RMII module as this seems to be fully supported on the MCU.

The W5500 module doesnt have a MAC address which is why it doesnt work, I hold better for the LAN8270 module.

Regards Mike
STM32F407 has builtin hardware Ethernet see 1121 of the reference manual https://www.st.com/content/ccc/resource ... 031020.pdf

DJShadow1966
Posts: 13
Joined: Sun Jun 23, 2019 4:55 am
Location: Gateshead, Tyne and Wear

Re: MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

Post by DJShadow1966 » Wed Jul 24, 2019 12:49 pm

Hello

After adding the relevant code in the following as per the guide you gave :-

mpconfigboard.h

Code: Select all

// Ethernet via RMII
#define MICROPY_HW_ETH_MDC          (pin_C1)
#define MICROPY_HW_ETH_MDIO         (pin_A2)
#define MICROPY_HW_ETH_RMII_REF_CLK (pin_A1)
#define MICROPY_HW_ETH_RMII_CRS_DV  (pin_A7)
#define MICROPY_HW_ETH_RMII_RXD0    (pin_C4)
#define MICROPY_HW_ETH_RMII_RXD1    (pin_C5)
#define MICROPY_HW_ETH_RMII_TX_EN   (pin_PB11)
#define MICROPY_HW_ETH_RMII_TXD0    (pin_B12)
#define MICROPY_HW_ETH_RMII_TXD1    (pin_B13)
pins.csv

Code: Select all

ETH_MDC,PC1
ETH_MDIO,PA2
ETH_RMII_REF_CLK,PA1
ETH_RMII_CRS_DV,PA7
ETH_RMII_RXD0,PC4
ETH_RMII_RXD1,PC5
ETH_RMII_TX_EN,PB11
ETH_RMII_TXD0,PB12
ETH_RMII_TXD1,PB13
Unable to make the firmware gets a couple of errors

Code: Select all

eth.c:38:25: fatal error: lwip/etharp.h: No such file or directory
compilation terminated.
network_lan.c:34:24: fatal error: lwip/netif.h: No such file or directory
compilation terminated.
../../py/mkrules.mk:74: recipe for target 'build-BLACK_F407VE/genhdr/qstr.i.last' failed
make: *** [build-BLACK_F407VE/genhdr/qstr.i.last] Error 1
make: *** Deleting file 'build-BLACK_F407VE/genhdr/qstr.i.last'
Other boards that use the RMII interface like this one do not throw any errors.

Regards Mike

DJShadow1966
Posts: 13
Joined: Sun Jun 23, 2019 4:55 am
Location: Gateshead, Tyne and Wear

Re: MCUDev Black STM32F407VET6 + STM32F407ZET6 dev boards

Post by DJShadow1966 » Wed Jul 24, 2019 1:01 pm

Hello

Cracked it by comparing file and found this missing from the mpconfigboard.mk file

Code: Select all

# MicroPython settings
MICROPY_PY_LWIP = 1
MICROPY_PY_USSL = 1
MICROPY_SSL_MBEDTLS = 1
There is also a bug in the stm32f405_af.csv

Code: Select all

PortA,PA1,,TIM2_CH2,TIM5_CH2,,,,,USART2_RTS,UART4_RX,,,ETH_MII_RX_CLK/ETH__RMII_REF_CLK,,,,EVENTOUT,ADC123_IN1

Should be :-

PortA,PA1,,TIM2_CH2,TIM5_CH2,,,,,USART2_RTS,UART4_RX,,,ETH_MII_RX_CLK/ETH_RMII_REF_CLK,,,,EVENTOUT,ADC123_IN1

Regards Mike

Post Reply