Main Site Documentation

GHI SDK 4.1 is online and it includes RLP


#1

This is good news. We have 4.1 ready for you to use. Not only that, we also added RLP support too for those super users!
This is a beta release but it should be very stable so do not worry about having problems as you will probably not have any! If you have access to the beta then PLEASE use it.

There are some VERY important notes on this SDK that you must keep in mind.

  1. This SDK is for NETMF 4.1 NOT 4.0.
  2. You will need Visual Studio 2010. VS2008 will NOT work.
  3. You will need to install NETMF 4.1. The one you have now (4.0) will NOT work. You MUST uninstall 4.0 first.
  4. GHI found couple problems in the Microsoft’s 4.1 SDK and worked with Microsoft on the fixes. There are 2 files in the SDK zip file and a text wilt with instructions on where to place these files. You MUST copy those 2 files to the right place or you will have some random problems.
  5. This GHI 4.1 SDK is independent from the old GHI 4.0 SDK and so you can have both installed on your PC. We HIGHLY recommend that you remove 4.0 off your machine to eliminate any confusion in selecting the right assemblies.

This is a VERY important contribution from you to the FEZ community so please start using the beta ASAP.

If you do not have access to the beta but you are experienced user then contact GHI (phone/email) for the SDK download. Asking here will not get you the link.

See release notes http://www.tinyclr.com/release-notes-beta/


#2

I am sure we have talked about this before but don’t we need access to the LPC JTAG for RLP ?


#3

Yes , good question ;D

[quote]Developing RLP code on EMX requires JTAG access which is locked by default and it is
available only for select customers[/quote]

Why is JTAG access required? Normally the RLP “dll” is added as a resource.

So we can add it in VS and use the procedures in our code.


#4

RLP may not work that way. We can not import a native code DLL as in the Full framework. RLP is a GHI innovation and requires the native code to be at a specific location in memory and then loaded or invoked from managed code.


#5

Also need to mention that the native code needs to be built using a compiler that supports the LPC chip and can be in C,C++ or assembler.


#6

Regarding the beta documentation you can use nearly everything to load the binary image

But what is the meaning of “locked”?

Were there some bits to set?

The user manual is not so helpful in this case ::slight_smile:


#7

Thanks for the extra heads up on copying over the two files, I missed that one when I installed the GHI 4.1 SDK beta


#8

RLP/JTAG open security holes in the system. We do not want to see a pirated Chinese version of Cobra :wink: This is why using RLP requires that you know who you are and you sign agreements forcing you to be responsible.

The documentation is wrong, RLP does NOT require JTAG. We will fix the docs.
Yes RLP works just like DLLs. JTAG is needed fro debugging but it is optional.

Yes you need an ARM compiler to compile RLP but the compiler is free and we give you full instructions on how to compile RLP. Do not worry it is going to be freakin’ easy :slight_smile:

Let us considerate on moving to 4.1 and VS2010 fro now and we will discuss RLP later. This is a major move especially that you need to change all software on your PC. We will have a million support email everyday from those users that do not read instructions or get confused between 4.0 and 4.1…we will try to help as much as we can.


#9

cypher, where did you read about required JTAG access? Were you looking at the EM vs EMX?


#10

Hi Mike ,

I read it in the actual EMX documentation delivered with the new beta firmware

Page 10 in the EMX user manual

I also check the EMX vs EM doc

At point 7 it is also described as “locked by default”

[quote]RLP and JTAG: With JTAG and RLP support, users can now write real-time code
and handle tasks with higher efficiency using C or Assembly. Developing RLP code
on EMX requires JTAG access which is locked by default and it is available only for
select customers[/quote]


#11

If I copy the “Microsoft.SPOT.Debugger.CorDebug.dll” included in the GHI 4.1 beta SDK and replace the existing one at “C:\Program Files\Microsoft .NET Micro Framework\v4.1\Tools” then VS2010 Pro will NOT open any MicroFramework projects as it says they are not supported. Restoring this file to the original version resolves the problem.


#12

This release uses 4.1 not 4.0 so you will most likely need new projects. I am not sure if using old won would work and even if it did you need to update the assemblies to 4.1

Keep it simple, does it work with new projects?


#13

No you cannot start a new project either; a dialog that says “The Microsoft Micro Framework SDK package did not load correctly.”

If I use the original file everything works fine: VS2010 pro, MS MF 4.1SDK, GHI 4.1Beta SDK, Win 7-32


#14

Keep on using the original file and we will contact Microsoft about the error.


#15

Thanks cypher for pointing this out.

Jeff please try this:
Close all programs, especially Visual Studio.
Copy the new file.
Now open visual studio and make new micro framework console project. Does it work?

If it didn’t work please try copying the file, restarting the computer and then making a new project.


#16

I just tried it with the emulator and make a console and window project and they both worked just fine!

I am using express on win7-64bit


#17

Here it works perfectly :dance:

I’m using VS2010 Express , MS MF 4.1SDK, GHI 4.1Beta SDK, Win 7-32

I deinstalled the old framework and SDK and followed the instruction in the text file supplied by GHI

After installation is finished I updated the firmware without any problems

Then I start with a new Console program and deploy it to a FEZ Cobra and had fun :clap:


#18

Visual Studio Professional works fine too.
Also, make sure you installed the correct v4.1 SDK.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cff5a7b7-c21c-4127-ac65-5516384da3a0


#19

Rebooting does not help either. When you create a new project it acts like the project is created and you get the error I described earlier. Once I revert to the original dll I can’t open the newly created project either.


#20

Why is there still this error? I have erased, deployed and checked twice.
The version on cobra is too old. (4.0.1681.0) where mscorlib is trying to deploy version 4.1.2821.0.

[quote]Device capabilities:
ClrInfo.targetFrameworkVersion: 4.0.1681.0[/quote]

Why? :o