search

NETMF / llilum

Development Platform for MSIL and UWP apps targeting Micro Controllers. Part of the .NET Micro Framework family.
Other
159 stars 52 forks source link

Llilum application template #237

Open tkatsch opened 7 years ago

tkatsch commented 7 years ago

I could build and install Llilum (LLVM, Zelig project, Board Configuration, Llilum SDK MSI and application template VSIX). In VS2015 (community version) I can create a new Llilum Application. After some bugfixes with the board confuguration and the wrong folder for storing managed_opt.o my build goes up to the end... I used the default values predefined for using LPC1768 - I just created and build the solution, but I get linker failure with the following message: ############################################################################## c:/program files (x86)/gnu tools arm embedded/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region RAM overflowed with stack 1>collect2.exe : error : ld returned 1 exit status ##############################################################################

Thus, it seems that the build image needs more RAM than available!? Where can I find the RAM usage of the build? I just wondering that the default project uses LPC1768 but I cannot build it? Does any other person had the same issue? Maybe by Zelig SDK is wrong in some way?

Thank you for any hints.

vgolovanov commented 7 years ago

Hi. Can you please share how did you fix folder problem with managed_opt file ?

Thank you.

tkatsch commented 7 years ago

Hi,

to say it more precisly... its the workaround another user initcated this here under issues. I simply copied the file after first failed build into the parent folder folder. Thank you for notify me, it is not a bug fix, it's a workaround.

Thank you!

tkatsch commented 7 years ago

Short update:

I build today a small Windows Desktop App (first quick and easy for testing) acting as File System Watcher. This app will watch the target subfolder in ARM/Debug and looking for 'llilum.Managed_opt.o' file creations or changes. Once detected, I auto copy this file to the ARM\Debug folder. Because this is so fast, the Llilum application build runs without failure and can create the application image to deploy or debug. It works fine for me.

I used a K64F project due to LPC1768 failed to build due to RAM issues...

What I discovered during Debug session, that - and I do not know why - certain breakpoints never get triggered even the code has to run through... but application seems to run...

And every time I initiate a debug or build the whole native project will be rebuild which needs some time. Normally all the native code coming from the Llilum SDK (except m own interop code normally will not be changed once tested... why the Llilum SDK rebuild everthing again? What I do not understand?

Many Thanks