Next step in porting: DISC0-STM32F746

TinyCLR OS
103

That’s not good news, graphics, and possibly UI, would be a significant advantage TinyCLR on Discovery (F7xx) boards.
But - in version 0.10.0 the graphics worked. Code copy to 0.12.0 generates the above problem - NotSupportedException.

GHI guys - try to consider the possibility of providing these functions for “unofficial” FW.

104

It is really not that hard to add drawing functions on managed side. In fact we already have the code running on the BrainPad. We will be sharing that code soon.

2 Likes
105

Here is some code for nanoFramework that looks like it could be ported easily.

https://github.com/nanoframework/Samples/blob/master/I2C/STMPE811.Driver/STMPE811.cs

2 Likes
106

Mhhh @dweaver that’s code for touch screen management. Anyway I do like native code for screens. I have some native code written for MMB (F4 & F7) and I will use as basic starting point for Disco’s, next weeks I’ll deep inside.
For the moment I love to use Nextion and 4D System displays, a very nice solution!

1 Like
107

I’m testing disco-f746 and nucleo-f767 with v1.0.0 preview…
Not yet ported HS usb …

1 Like
108

At the moment all F746 boards crash and lockup. I couldn’t deep inside too much, so I don’t know the reason. I will wait for now. No problem with F767 nucleo.
Still problem in the Startup code where member variable configuration is not initialized.

#elif defined(DEBUGGER_FORCE_API) && defined(DEBUGGER_FORCE_INDEX)
    api = DEBUGGER_FORCE_API;
	configuration = (const void*)&STM32F7_Startup_UsbDebuggerConfiguration; // <--- need to be added!!!
#else
109

After wasting a couple of hours on the F746 boards, I think something is going wrong with memory allocation… It is not clear why F767 works fine (bigger RAM and/or bigger FLASH does matter?).

110

I’m back with a bit of spare time so I’ve ported preview2 to Disco F769 and Nucleo F767. They work fine (except DSI display on Disco F769 for the moment).
Looking at UC5550 device.h I see you are using flash in 128bit wide dual bank from sector 0x14 to 0x17 (total 512KB). Why you don’t set (nDBANK bit in option byte) 256bit from sect 0x06 to 0x0B, it will give you ~1500KB for deployment on big STM32F76x chip…

Total deployment size is 131.968 bytes.
Incrementally deploying assemblies to the device:
	- Erasing sector 3 (262.144 bytes).
	- Writing sector 3 (7.560 bytes).

Assemblies deployed. There are 1.440.896 bytes left in the deployment area.

For what I see in the .map file from gcc compiler-linker the tinyclr rom code ends at 0x0804063c (ok, your bootloader need some more space …)

3 Likes
111

@John_Brochue, a couple of notes v1.0.0.0pw2:

  1. I see that finally you are going to enable F7 MPU to get a faster SDRAM (nice news!!). Be aware that the function STM32F7_Startup_CacheDisable() will create trouble to boards not using a sort of bootloader that startup the MCU. The code from ST to disable cache imply a cache enabled (or initialized) otherwise it locks the MCU F76x (it will misalignes the PC in many case). I’ve faced the issue on the Disco-F769 and Nucleo-F767.
  2. I’m looking to make a FAT16 open source driver for SD (ach … not very soon :sob:) and I suggest to give the possibility to use not only SDMMC1 but also SDMMC2 controller, present on many STM32 chips.
1 Like
112

Thanks for the notes, we’ll take a look!

2 Likes