Main Site Documentation

Next step in porting: DISC0-STM32F746


#23

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 …:sunglasses:


#24

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


#25

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.


#26

Finally I could arrange Github publication for the STM32F7 code.

https://github.com/dobova86/TinyCLR_Port

Notes:

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

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


#27

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! :scream:
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 …


#28

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();
}

#29

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


#30

I will test tomorrow … :smiley:
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 )


#31

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


#32

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!


#33

@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… :japanese_goblin:

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.


#34

New fixes pushed on github:

  1. Fixed a problem in STM32F7_Deployment.cpp api that was not deploying correctly program to the F7 boards due to D-Cache enabled.
  2. 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.
  3. Some minor fixes to DSI code.
  4. Added .ldf files to devices … fixed .gtignore file (I’m too dumb user of github…).
  5. 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.


#35

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


#36

Awesome! thank you for all your hard work!


#37

@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 … :scream:
Sure 0.9.0 UART managed libs are wotking fine ? Does it pass buffers to native code?


#38

it works fine as we just tested yesterday.


#39

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


#40

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() ?


#41

I used this:

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


#42

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