Blog article using VB for simple Netduino Application http://blogs.msdn.co...a-netduino.aspx

Hi Newbie here,

I Have just got my Netduino Plus as I saw it now has BETA VB.net support.

I'm using VB2010 Express. I updated the the firmware TinyBooter and the new beta firmware I installed the beta SDK everything seemed to go fine.

So I then made the blinky program to test out. It works sort of... When I click the start debugging button the status at the bottom left of the screen gets hung up at 'Preparing to deploy assemblies to the device' after a minute or two VB comes back saying it can't communicate with the device.

If I cancel the deploy and unplug the Netduino and then hit 'start debugging' while the device is booting, the code gets downloaded to the netduino without error, however, VB gets hung up. The status reports 'The debugging target is not in an initialised state; rebooting'. It hangs here and gets no further.

If I hit the reset button on the netduino the netduino reboots and the code is executed and the LED starts flashing. VB stays hung on 'The debugging target is not in an initialised state; rebooting'. If I hit 'stop debugging' VS goes back to the editor window.

I know the software is in beta so it may be a bug or it may be me doing something wrong?

There is a glitch which is resolved by going to the Project Properties Tab and it will probably be on USB but reselect the Netduino item and then try again and this should succeed.

This is most likely cause and is being worked on.

Thanks for your offer Stefan, I did not see my post was published earlier. In fact, I created another (identical) project, and it all went just fine. Don't know what happened, maybe some initialisation when i used the project template for the first time?

Anyway, VB works and it's fun to use it for Netduino, as I am now more familiar with it than with C#, due to my job.

Do a simple windiff on the VBproj files to see if there is any obvious differences.

Any chance supporting DHT11/DHT22 humidity and temperature sensors? They're not one-wire, but the communication is similar and needs to be done native, not in managed C# code. I see Steve88W wrote earlier in this topic that there is a "huge step closer to supporting the DHT11 and DHT22". Any progress on that?

Add one for DHT11 sensors support.

That's fixed now, but when deploying attached app, it gives:

I believe there is another update to the firmware that is possibly required. You may want to check with Chris and try reflashing the latest firmware as well.

The joys of Beta software. Obviously finding issues is part of the process - so its great that people are starting to use it and we can find these.

Some of these will be VB Only issues as Withevents is a VB Only construct. So at least it is not completely blocking event scenarios as its always possible to use the addhandler construct in the same way C# sets up event handlers. Not Ideal but we are working to resolve issues.

Found yet another bug, in VB.NETMF, while typing this line and pressing Enter the IDE crashes the hard way:

Public WithEvents button As InterruptPort = New InterruptPort(Pins.ONBOARD_SW1, False, Port.ResistorMode.PullDown, Port.InterruptMode.InterruptEdgeBoth)

Now there are more ways to handle events but a crashing IDE, not good!

Download the latest version of the MF 4.2 (Beta).

This issue should now be resolved.

Could you explain? I thought that (on "normal" .Net) both languages after being pre-compiled by MSIL were basically the very same code. Is it very different for NETMF ?

Sure, the hit is the additional assembly that is being used when you are using VB. Look at the list of assemblies and you will see one called Microsoft.VisualBasic.dll which is included for VB applications. This contains some important items as well as conversion functions which enable VB to work.

This occurs on ALL .NET platforms not just MF. When compiled VB and C# both produce IL. These functions consume additional memory, I think its around 17 KBytes. However this may be more important on the MF devices which are much more memory constrained.

The WP7 / XNA project types now use a feature called VB Core which embeds these items in the assembly avoiding having to deploy an additional assembly but this still requires these items to be present.

If you look at what else is in this Microsoft.Visualbasic.dll assembly on the desktop you will see it contains the Late binder, legacy function (Left, right, mid....), Constants etc. Many of which are simply wrapper classes around existing .NET framework functionality or are simply not supported on other platforms. So reduced runtimes were created for these new platforms and this unsupported functionality was removed to reduce the hit you would take.

If you want these function then you can simply create them yourself.

As these are all new platforms the general idea was that basic VB.NET support would be provided. Some desktop code would need to be modified when porting to these platforms but using the .NET framework functionality is probably a better bet than the vb runtime because it allows easy conversions between languages.

Thanks Stefan, did not thought of that. Cool, going to try this code immediately.

If you want to implement functionality such as Round etc. that are contained in Microsoft.VisualBasic.Dll on the desktop framework you can use reflector or Telerik's Decompiler to decompile the assembly and create your own functionality.

The reason why all these functions are not supported out the box is that they consume memory and memory is in rather short supply for microframework. There is a hit you already take for using VB and unneccessrily bloating it with a lot of functions that you don't need all the time would reduced down amount of memory available for your code.

If you want this functionality you can simply implement you own as these functions tend to be just wrapper classes around .NET Framework functionality. Many are already implemented in C# solutions - so you may want to consider taking C# functionality and wrapping it in familiar method signature.

You may want to check out the system.Math namespace which has most of these functions in. If you use these then you code will be easily converted between C# and VB - should users of the other language want to use you code examples.

This is tremendous. I'm a capable C# dev, but, because I live in it all day, I have a tendency to think VB. Will make the rapid development of code a little more rapid for me. Thanks to everyone that contributed to this for their hard work!

Its great to see that people are excited about VB Support. I work in both and love VB. The VB stuff is still in Beta so please do provide feedback on things that are not working 100% so we can work to get them resolved.

Just to keep you busy;

Module Module1

    Sub Main()
        On Error GoTo testing

        ' write your code here

        Exit Sub
testing:
        Resume Next
    End Sub

End Module

Results in:

Old style on error goto handling is not supported in this just as it is not supported in Win Phone 7 / XNA / VBCore functionality.

Should use Try Catch exception handling.

For more about items which are not supported check out VBCore http://blogs.msdn.co...o-2010-sp1.aspx

This will detail pretty much what is left out and what is included. VB support on these platforms is not the same as full desktop version. Older legacy function, late binding, generics, old style error handling are all not supported. If your writing modern VB.NET code you should be fine but functionality is not full desktop functionality. So please be aware of the limitations.

Also enure optimization is enabled for all projects - by default it is turned on for new project but turning it off will prevent debugging from working correctly because of the limited framework functionality.

Let me ping the folks on the Visual Studio team and see where we should report bugs.

VB support is brand new, and in beta...so I'm guessing that we'll find quite a few glitches.

I also noticed that watchpoints like "led.Read()" don't work yet.

Chris

Already know issue Withevent and Handles with this release - workaround use addhandler.