STM32G474xx on NUCLEO-G474RE

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
User avatar
RealSparky
Posts: 17
Joined: Tue Sep 29, 2020 4:38 pm
Location: Carlsbad, California USA

Re: STM32G474xx on NUCLEO-G474RE

Post by RealSparky » Mon Feb 22, 2021 8:35 pm

Status update:
Sorry about the delay on posting my STM32G4xx MicroPython port source. The multi-phase HRTIM 'C' code is working now and being merged into my G4xx uPy port. I want to share my very first port done last year just so you have something to tinker with.
https://drive.google.com/drive/folders/ ... sp=sharing

The .jpg shows G4xx MicroPython talking to a 128x128 TFT display.

Once I have finish testing my HRTIM integration I will share the source at Github.
best regards, RealSparky

User avatar
RealSparky
Posts: 17
Joined: Tue Sep 29, 2020 4:38 pm
Location: Carlsbad, California USA

Re: STM32G474xx on NUCLEO-G474RE

Post by RealSparky » Tue Mar 02, 2021 10:01 pm

Reconsidering External Module approach:

Today I have realized maybe extending the MicroPython Timer module to include HRTIM (high resolution) might not be the best approach. Mostly, because the HRTIM only exists in a very limited number of STmicro controllers. In the G4xx series it is only available in the G474 & G484. I have updated my temporary google drive location now to include the pre-git version of my Win10 Embitz project 63MB upyNUC_G474RE.7z for your entertainment.
https://drive.google.com/drive/folders/ ... sp=sharing

You will also find a file: HRTIM MicroPython initial testing.pdf which I came to the realization that there is enough different to my HRTIM requirements that the external module approach might be a better solution.

The HRTIM is an advanced feature that not many people will consider and minimizing its impact on the existing timer.c code to the community is my concern.

The second point to ponder is: Do we want to clean this project up to make a git version available?

Now is the time to pick the best path forward so let me know your thoughts if you have a few spare minutes.

best regards, RealSparky

User avatar
RealSparky
Posts: 17
Joined: Tue Sep 29, 2020 4:38 pm
Location: Carlsbad, California USA

Re: STM32G474xx on NUCLEO-G474RE

Post by RealSparky » Sun Mar 14, 2021 10:40 pm

RE: New modg4ex.c G4 Expansion module for HR High Resolution (16bit) PWM

I have completed the initial testing with the stm32G4xx expansion module. My shared code is still a 7z packaged as a Embitz project, sorry about that. The MicroPython firmware.hex is in the stm build folder so no need to compile to evaluate.
https://drive.google.com/drive/folders/ ... sp=sharing

See the PWM_TIM_benchmark.py file comparing the standard MicroPython PWM and new HR version to set the PWM duty cycle. The pwm command uses a signed 16bit value range +/- 32767 where 0 (zero) represent a 50% duty cycle. You can control both existing MicroPython pwm(s) and HR pwm(s) using the same value range as the c code scales the 16bit to 12bits automatically before writing to the Compare registers. The HR multiphase pwm allows the 6 channel phase relationship to be adjusted on-the-fly by addressing the Master timer starting at chan 16 through 19. The G4 HRpwm runs a true 16bit control at 83Khz without dithering.

I have been using ATOM PyMakr ever since it was available but tried the Thonny IDE today to address a REPL overflow issue. Thonny is an EXCELLENT program and will be my new MicroPython IDE moving forward. Definitely, worth the install effort. https://thonny.org/ The debugging features far exceeds PyMakr and supports 7 different MicroPython platforms. And no more script downloading issues! Thank you, Thonny development team, kudos to you.

RealSparky, the hardware guy

User avatar
RealSparky
Posts: 17
Joined: Tue Sep 29, 2020 4:38 pm
Location: Carlsbad, California USA

Re: STM32G474xx on NUCLEO-G474RE

Post by RealSparky » Sat Mar 20, 2021 5:45 pm

RE: LPUART1 on STM32G474 w/ AEMICS build
I was is the process of adding LPUART1 to my G474 project and to my amazement found another G474 port here:
https://github.com/AEMICS/micropython/t ... ICS-boards
There is a note in the mpconfigboard.h:
#define MICROPY_HW_UART_REPL (PYB_LPUART_1) // not working yet for Nucleo, no response after startup
But this appears to be fixed now as it works fine on my NUCLEO-STM32G474RE.
KUDOS to Damien George and H-Grobben for a professional release for the G474 series. I will be using their more up-to-date release moving forward and integrate the ST7735 LCD and HRTIM pwm modules into it for my custom PCBA designs.

RealSparky, the hardware guy

User avatar
RealSparky
Posts: 17
Joined: Tue Sep 29, 2020 4:38 pm
Location: Carlsbad, California USA

Re: STM32G474xx on NUCLEO-G474RE

Post by RealSparky » Thu Mar 25, 2021 7:58 pm

RE: Update on AEMICS build
I have updated my shared google drive with a few minor fixes to the initial AEMICs shared release. Now we have the LPUART1 for REPL and has LittleFS integrated in a more stable fashion, ADCs are working as well as the HRTIM module g4ex and ST7735 LCD.
https://drive.google.com/file/d/1ESzj1g ... sp=sharing
My changes are listed gitstatus_v01.txt and the 7zip includes the non-debug hex file for immediate flashing and testing.

Thonny needed a small mod to configuration.ini with the MicroPython v1.14 release. Just add submit_mode = raw. I'm running with the suggested ESP32 write block_size =255 and write_block_delay = 0.03, but suspect only the raw mode was important.

RealSparky, the hardware guy

HGrobben
Posts: 3
Joined: Thu Mar 25, 2021 9:09 pm

Re: STM32G474xx on NUCLEO-G474RE

Post by HGrobben » Thu Mar 25, 2021 9:13 pm

Seems like we are working on the same type of projects...
https://github.com/AEMICS/st7789_mpy :D

User avatar
RealSparky
Posts: 17
Joined: Tue Sep 29, 2020 4:38 pm
Location: Carlsbad, California USA

Re: STM32G474xx on NUCLEO-G474RE

Post by RealSparky » Fri Mar 26, 2021 7:19 pm

Thanks, HGrobben
For your ST7789 Github link. I have updating the MicroPython scripted ST7735 interface on my TODO list. I think Guy wanted to keep the concept simple to understand by using single pix writes rather than a window write approach. Your ST7789 'C' approach with window writes is really the best design for serious graphics performance.
Is your STM32G474 project still active?
best regards,
RealSparky, the hardware guy

HGrobben
Posts: 3
Joined: Thu Mar 25, 2021 9:09 pm

Re: STM32G474xx on NUCLEO-G474RE

Post by HGrobben » Mon Mar 29, 2021 5:25 pm

yes, still busy with development. We're busy with a small cheap version of the board in git (in git STM32WB) but now I'm busy getting the USB connection to the G4 on our cheaper board ready. In the G4 the USB is a bit different than in other families (other families use Alternate Function for USB pins, G4 doesn't..). But its not my main project, so progress is slower as I hoped for.

I also tried to show a logo on our 320x240 screen but with pixel placement it took too long, and as the LCD did support partial writes, I got that to work (not all the work was mine, I also forked the repo..)

User avatar
RealSparky
Posts: 17
Joined: Tue Sep 29, 2020 4:38 pm
Location: Carlsbad, California USA

Re: STM32G474xx on NUCLEO-G474RE

Post by RealSparky » Mon Mar 29, 2021 7:39 pm

My applications for the G4xx are all embedded so I do not need a USB connection. I will be using the FDCAN bus for my COMs. I do not know much about your G4xx project but suspect the USB is not your main COM. You might consider having a socket on your low-cost board to plug-in a STLINK-V3MODS (U$D 8.60) This is a lot of bang for the cost and you get a programmer and VCP without any USB development which can be tricky. Just include the socket for the STLINK-V3MODS and you are good to go. BTW, there is a small glitch, to use the VCP at the moment. You need to start the debugger to initialized the STLINK-V3MODS before the VCP works. I am using another solution if I'm only using the VCOM with a FTDI cable TTL-232-RPI (U$D 16.00)
RealSparky, the hardware guy

HGrobben
Posts: 3
Joined: Thu Mar 25, 2021 9:09 pm

Re: STM32G474xx on NUCLEO-G474RE

Post by HGrobben » Wed Mar 31, 2021 12:41 pm

Most of our applications are also USB-less (as our EMC guru always calls it: Universal Sh*t bus), but for this small development kit we're making (to have a platform for our customers to build their application on) is would be a nice, actually need-to-have, feature to use the embedded USB functionality (with DFU, which sometimes is a real life safer).
If you find any issues in the G4 FDCAN, please let me know (preferably via github issue). We are already using it, seems to be okay. Haven't stress tested it though.

Post Reply