". Net Micro Framework portingkit–14" TINYCLR compilation and testing

Since TINYCLR's code is not related to hardware, what we do is add different feature to the actual needs, in addition to a reasonable configuration of the stack and the location of the code store. Its main work, specifically, is to fix the \SOLUTIONS\STM3210E\TINYCLR directory of TinyCLR.proj and Scatterfile_tinyclr_mdk.xml files.

The TinyCLR.proj file is similar to the NativeSample.proj content, but adding some libraries written by managed code (C #) is more important than mscorlib.pe, which is the TINYCLR core file, about 29k in size. Here, perhaps, the reader will be surprised to know what the extension is for PE rather than the DLL on the Windows system, but the. Net Micro Framework's managed code compilation and Desktop edition are no different, with VS2008 Csc.exe in the environment, our MF program refers to the library under the Files\Microsoft. NET Micro Framework\v4.0\assemblies Directory (the file with the extension DLL), It is actually compiled by Csc.exe, and it is not fundamentally different from the. Net framework and can be referenced directly in each other's projects. In other words, the DLL file is for us to compile the. Net Micro Framework on the PC, and the PE file is the file that is actually downloaded to our embedded system on the hardware platform.

What is the relationship between the PE file and the DLL file? In fact, the PE file is Program Files\Microsoft. NET Micro framework\v4.0 \tools \ MetaDataProcessor.exe the DLL (or more precisely the deletion and processing) after the file, its size is probably half of the original DLL file, such as mscorlib.dll file for 85.8k, and mscorlib.pe file is 29k. Our tinyclr is the execution engine for these PE files (the more detailed content I will be writing in the "Topsy. Net MF" series of articles to introduce the relevant knowledge of PE files).

As we said, because the em-stm3210e Development Board has too little RAM, we have to debug the Flash version of TINYCLR in the first instance, because TINYCLR defines an array of the same size as the assembly when it creates the assembly instances. So our stack is at least bigger than the largest PE file we have to load, like at least 29k. The heap is for the object of managed code, can be defined according to the actual needs, the final configuration for the em-stm3210e Development Board Scatterfile_tinyclr_mdk.xml is as follows:

<if name= "targetlocation" in= "FLASH"
<!--120k
<set name= "Heap_begi 　　　　　　　　 N "value=" 0x68000000 "/>"
<set name= "heap_end" value= "0X6801DFFC"/>
<!--8k
<set name= "Custom_heap_begin" value= "0x6801e000"/>
<set name= "Cust　　　　　　　　Om_heap_end "value=" 0X6801FFFC/>
<!--32k;
<set name= "Stack_bottom" Value= "0x20008000"/>
<set name= "stack_top" value= "0X2000FFFC"/>

<se T name= "code_baseaddress" value= "0x08000000"/>
<set name= "code_size" value= "0x00080000"/&G T　　　　　　　　　

<set name= "config_baseaddress" value= "0x00000000"/>
<set name= "Config_size" Value= "0x00020000"/>

<set name= "deploy_baseaddress" value= "0x00020000"/>
<se　　　　　　　　T name= "Valid"　　　　　　　Value= "true"/>
</if>

Where config is placed on the Nandflash.