Next step in porting: DISC0-STM32F746

dobova · March 14, 2018, 5:51pm

Just for info, now STM32F7 can use USB FS,USB HS and USB HS with ULPI PHY for USB debug&deploy.

As a plus, today thanks to a friend of mine, I get a Discovery STM32F769NI as a gift. It’s just runnig fine basic TinyCLR 0.9.0 using USB HS ULPI for dbg&deploy …

zeroaviation · March 15, 2018, 4:45pm

Nice work! Are you contributing back to the main github? or do you have a fork somewhere?

dobova · March 15, 2018, 7:41pm

I will setup my own github for the moment. After rel 1.0 of the tinyclr will see. I’m aa very dummy user of github.

dobova · March 16, 2018, 5:24pm

Finally I could arrange Github publication for the STM32F7 code.

https://github.com/dobova86/TinyCLR_Port

Notes:

Parallel Display is working for Disco-STM32F746 and has external SDRAM enabled. Use USB FS for default.
DSI Display on Discovery STM32F769 is under development. External SDRAM is disabled. Use USB HS + ULPI as default

More work is needed to get a working I2C bus on the F7 chips.

dobova · March 18, 2018, 5:38pm

I’ve pushed on GitHub a working version of DSI Display working on a Disco-F769 using external SDRAM in 32Bit mode.

The DSI display is very high density (800x480) and TinyCLR fonts are really too tiny!
The heap memory needed for Graphics is 768KB !! So no way to use internal SRAM.
On the Disco-F746 and Disco-F769, except I2C & CAN bus, all other peripheral are working.
Next to come is Wolfson chip driver …

dobova · March 18, 2018, 5:48pm

The result…

The code:

public DisplayTest()
{
    _display = DisplayController.GetDefault();

    ParallelDisplayControllerSettings _settings = new ParallelDisplayControllerSettings()
    {
        Width = 800,
        Height = 480,
        PixelClockRate = 9600000, // not used in native code
        PixelPolarity = false,
        OutputEnablePolarity = true, // this must be true
        OutputEnableIsFixed = true,
        HorizontalFrontPorch = 8,
        HorizontalBackPorch = 43,
        HorizontalSyncPulseWidth = 2,
        HorizontalSyncPolarity = false,
        VerticalFrontPorch = 2,
        VerticalBackPorch = 2,
        VerticalSyncPulseWidth = 10,
        VerticalSyncPolarity = false,
        DataFormat = DisplayDataFormat.Rgb565 // not really correct: it is Rgb888 for Disco-746 display...

    };
                
    _display.ApplySettings(_settings);
    _display.WriteString("\f\n\n* Discovery STM32F69 board *\n\n");
    _display.WriteString  ("* TinyCLR 0.9.0 for STM32F7 *");
    _screen = Graphics.FromHdc(_display.Hdc);
}

public void DrawSomething(string s, int x, int y)
{
    Font f = Resource1.GetFont(Resource1.FontResources.NinaB);
    _screen.Clear(Color.Black);
    Pen pen = new Pen(Color.Green);
    _screen.FillRectangle(pen.Brush, x, y, 160, 160);
    _screen.DrawString(s, f, new SolidBrush(Color.Red), x, y + 170);
    _screen.Flush();
}

Justin · March 18, 2018, 7:22pm

Does changing external SDRAM to 32Bit change the speed test results?

dobova · March 18, 2018, 7:33pm

I will test tomorrow …
Anyway f769 is faster than f746 on internal sram… with last fw the benchmark of 20 pi decimals reach 0.85 sec on f769 and 1.2 on f746 ( without sdram )

Justin · March 18, 2018, 7:36pm

Sweet, i am very much impressed with your efforts on the F7 port and am sure alot of people will benefit greatly.

dobova · March 18, 2018, 7:40pm

Thanks Justin … anyway it is a great chip the stm cortex m7 and tinyclr can really run very fast.
Dsi display is interesting … using an external dedicated phy chip can go out to hdmi directly!

dobova · March 19, 2018, 10:44am

@Justin the sdram it’s very slow also on 32bit bus. it sports a 2.72 sec vs 0.85 sec on internal sram , weird 3 times slower…

I don’t really know if there is any tricks to optimize access. I didn’t yet experiment with Cortex M7 Memory Protection Unit feature, because by default 0xC000000 sdram area is not cached.

dobova · March 19, 2018, 12:15pm

New fixes pushed on github:

Fixed a problem in STM32F7_Deployment.cpp api that was not deploying correctly program to the F7 boards due to D-Cache enabled.
Fixed SDRAM performance issue. Now it works at same performance as the internal sram, remapping to addr 0x60000000, instead of 0xC0000000, where by default MPU enables cache. Note: the same trick can be done on F429 discovery as well.
Some minor fixes to DSI code.
Added .ldf files to devices … fixed .gtignore file (I’m too dumb user of github…).
Updated built fw for F746 and F769 discovery boards

Lesson learned about cache in the F7 mcu… PI bench run now 0.90 sec for 20 decimals, half time than an F429.

dobova · March 27, 2018, 4:30pm

First step in F7 I2C bus implementation. It is mostly working now, but it needs more adjustment …

LA image shows a read from the ADC chip MCP3424 at 18bit convesion

zeroaviation · March 27, 2018, 5:13pm

Awesome! thank you for all your hard work!

dobova · April 3, 2018, 4:12pm

@Dat_Tran have you tested USART native driver on STM32F7 ?? It seems stuck with TXEIE int bit cleared, so it doesn’t trasmit anything through the serial port. I can’t enable it writing USART CR1 register. I’m sure it worked fine with 0.8.0 code …
Sure 0.9.0 UART managed libs are wotking fine ? Does it pass buffers to native code?

Dat_Tran · April 3, 2018, 6:00pm

it works fine as we just tested yesterday.

Dat_Tran · April 3, 2018, 6:27pm

Just duple check. Work fine as TinyCLR UART port and Serial debug mode. Tested at port 0.

dobova · April 3, 2018, 7:10pm

Thank you @Dat_Tran for the info. I will check better.
I’m using disco stm32f746 and port 0 usart1.
What is the correct string Id for the call serial device.fromid() ?

Dat_Tran · April 3, 2018, 7:34pm

I used this:

("GHIElectronics.TinyCLR.NativeApis.STM32F7.UartProvider\\0");

dobova · April 3, 2018, 7:42pm

Ok, I use the same… tomorrow will check better the code.