I am not sure what exactly you are asking... you kind of answered your own question in the last sentence in the original article.

It is certainly possible to program Netduino boards in C/C++, using toolchains you mentioned above. I am not familiar with ARM DS-5, but if you are looking for IDE then there are for example free/evaluation version of commecial products like Keil MDK Lite,  IAR EWARM, CrossWorks for ARM, free CooCox CoIDE etc. Usually, they come with a few sample applications and sometimes even with higher level libraries...

You can use any RTOS, as long as the appropriate microcontroller port is available, using supported toolchain/IDE - you'd have to check the particular RTOS documentation, based on what exactly you need/want to do.

For STM32F-based Netduinos (gen 2), you can use DfuSe utility to upload firmware when the device is in USB bootloader mode. During development, it is better to use JTAG or SWD in-circuit debugger/programmer, such as ST-LINK/V2.

Usually, the IDE supports at least one such debugger, so it is relatively easy to deploy the compiled binaries, place breakpoints and step through the code...

Those are libraries and stubs for tools and Windows2 solution, which do not need to be rebuilt when you make changes to a particular solution (your firmware).

There are a few 'clean' targets, you can display them for example by launching

msbuild Solutions\Netduino2\dotnetmf.proj /t:Help 

For a 'complete clean' build, delete the build output directory

rmdir /s /q BuildOutput

Does this affect the Netduino build? Do I need to install .Net2.0 framework?

No, you can safely ignore this warning. IIRC it is caused by incorrect ToolsVersion attribute value in a few project files, which causes MSBuild 3.5 to be run, instead of 4.0. I have already fixed such issues, but in separate 'cleanup' branch, which will be integrated into a future release...

Prerequisites

• GCC ARM Embedded 4.8-2013-q4-major (installer or zip)
• Visual Studio 2012 or both .NET Framework 4.0 and Windows SDK for Windows
• .NET Micro Framework Porting Kit 4.3 QFE1
• Netduino 2 Firmware v4.3.1 source
• Netduino 2 Firmware v4.3.1 source for GCC (attached below)
• NetduinoUpdate_4.3.1.0.zip

How to build the firmware with GCC

• Install GCC, preferably to short path with no spaces, e.g. C:\GCC
• Install .NET Micro Framework Porting Kit 4.3 QFE1 (C:\MicroFrameworkPK_v4_3)
• Copy C:\MicroFrameworkPK_v4_3 to C:\Netduino2
• Extract Netduino 2 Firmware v4.3.1 source to C:\Netduino2, overwrite all
• Extract Netduino 2 Firmware v4.3.1 source for GCC to C:\Netduino2, overwrite all
• Launch cmd.exe
  

  cd \Netduino2
  setenv_gcc 4.8.3 C:\GCC
  msbuild Solutions\Netduino2\dotnetmf.proj /p:Flavor=Release /v:m
  

• The build should succeed, with a few warnings
• Extract NetduinoUpdate_4.3.1.0.zip (C:\NetduinoUpdate_4.3.1.0)
• Copy the firmware image C:\Netduino2\BuildOutput\THUMB2\GCC4.8\le\FLASH\release\Netduino2\bin\tinyclr.hex\ER_FLASH to C:\NetduinoUpdate_4.3.1.0\Firmware\Netduino2_4_3_1_0\ER_FLASH.s19 (rename - add extension)
• Open ER_FLASH.s19 in you favorite text editor and delete the first line (starts with S0), save.
• Launch NetduinoUpdate.exe, plug in your Netduino 2 and update the firmware.

Important notes

• GCC support added and verified only for Netduino 2 (mainly due to resource/time constraints),
• Other GCC toolchains might work or need only minor changes, but make sure they have support for long-long and long-double (IIRC Yagarto does not have it by default) - otherwise formatted string output for C# long and double does not work,
• Included are a few bug fixes and modifications from my NETMF Fork project (which will be released probably later this year):
  • Fixed MMP : error MMP0000: 0x80131700 (#221, #2202),
  • Fixed GCC compiler errors in BitConverter.cpp (#2216),
  • Added ABORTS_REDUCESIZE symbol to exclude interactive debugging code (#1908),
  • Added support for recent Keil MDK-ARM toolchain (#1795)

Attached Files

•  Netduino2-4.3.1.0-GCC.zip   122.61KB   235 downloads

Edit 2014-03-18 19:30 UTC: Added Visual Studio to prerequisite list

So it appears there are some more Prerequisites that should be in the top list. I've got Visual Studio 2013 Ultimate installed, and it contains Visual C++.

According to .NET Micro Framework Porting Kit 4.3 ReleaseNotes.txt "Either Visual Studio 2012 (Express edition or greater) or both .NET Framework 3.5 and Windows SDK for Windows" is required.
 
In order to get Visual Studio 2013 working, you'd have to modify setenv_base.cmd - add %VS120COMNTOOLS% to the block of conditions, or simply change the existing %VS110COMNTOOLS% to 12. However, I am not sure this would be enough, due to the MSBuild 2013 changes and several project files having incorrect and/or missing ToolsVersion attribute.

One clarification please. When you say Netduino 2 only - do you mean that no support for ND Plus 2?

Yes, the GCC-related modifications have been made for Netduino 2 firmware only. But the most-important ones were made in the core .NET Micro Framework source code and are shared by Netduino Plus 2 firmware too - basically, adding a proper scatterfile and fixing possible GCC compiler errors in the additional libraries the Plus 2 firmware uses (network etc.) should be all that is needed to make GCC built firmware for the Plus 2.

Any thoughts on how to keep this work up to date as new versions of the MF and SL firmware are released over time?

Well, the modifications are available under Apache 2.0 license, so both Microsoft .NET Framework and Secret Labs teams can easily integrate them into their respective code    And there are always alternative ways 

Well, assuming that you don't have JTAG/SWD in-circuit debugger, the options are... ...challenging 

• At first, modify the value of <OEMSystemInfoString/> in Solutions\Netduino2\Netduino2.settings - you can then verify (e.g. in MFDeploy) that the device is running your updated firmware,
• For diagnostic output that appears in the debugger (Visual Studio or MFDeploy) use CLR_Debug::Printf(...) (#include <TinyCLR_Debugging.h> or #include <TinyCLR_Runtime.h>).
• For low-level diagnostic output you could use hal_printf or debug_printf; it is usually better to reconfigure STDIO and DEBUG_TEXT_PORT to serial port (e.g. COM1) instead of USB (default).
• The above functions significantly affect code timing and might not be available/should not be called in a particular context (such as interrupt handler) - there you are left with pin toggling (LED blinking, logic analyzer).

Don't get me wrong but can maybe also explain the advantages, why I should use that? What's the benefits or what problem is solved? Just have no clue and ask myself if I should take a look at it ;-)

Well, you don't have to use that (if you mean the firmware source). Adding GCC support allows you to use free GCC-based toolchains to compile the firmware - otherwise, you have to pay several thousand dollars for commercial ARM toolchains (such as Keil MDK).

Quiz question: What return value do you expect from an unconnected input pin?

The thing is that you created input pin with ResistorMode.PullUp, which means the pin is in logic high (returns true), unless it is connected to other logic level (logic low, ground). Thus, if you want your input pin Read() method to return false, you have to wire the pin to GND.

If you use a port in output mode, its Read() method basically just returns the current state - i.e. the initial state passed via constructor parameter or what was set in the last call of Write() method.

Because on N2 and N2+ i have connected digital input with 3V then i get tue Value....

 
Hm, does that mean that on N2 and N2+ unconnected input pin created with ResistorMode.PullUp returns false? That does not seem to be right - it's either a bug or you've inadvertently used ResistorMode.PullDown (?)

... C# is interpreted but I'll write that down to a language barrier :-)

 

That is correct, in the current implementation of .NET Micro Framework, managed code (CIL) is interpreted (there is no JIT).

Unfortunately, Visual Studio does not support deployment over JTAG and I am not sure its ARM compiler can generate code for Cortex-M series. Probably the closest thing is VisualGDB.

Well, it depends on what exactly do you mean by "MiniJTAG"?

You'd need in-circuit debugger/programmer to deploy and debug the code, popular choices are for example ST-LINK/V2 or Segger J-Link. There are many others, but you should check VisualGDB support; they have tutorials for ST-Link and J-Link, so these two should work. They have standard 20 pin 0.1" pitch JTAG connector, so you'd need also an adapter for 10 pin 0.05" pitch mini JTAG, which looks like this or this, and if your Netduino does not come with the pin header, you'd need it too (FCI part at Digikey, or similar).

Tip: You can make el cheapo mini JTAG header from a copper wire: cut 10 pieces about 10 mm long from solid core copper wire that fits into Netduino board holes, insert them all into the female header so they stay in place and have proper length, stick through the board, solder and carefully cut the excess 

The erase pad is available only on the first gen Netduinos - it is connected to the [AT91SAM7] microcontroller ERASE pin, which enables you to perform full flash memory erase. Netduino gen 2 [STM32F] microcontrollers do not have this feature, you have to erase the flash memory via software (DFU utility or using a programmer).

+-------+   +-------+       +-------+
| SRF01 |   | SRF01 |  ...  | SRF01 |
+-------+   +-------+       +-------+
    |           |               |
    |           |               |
    +-----------+----- ... -----+   Serial I/O
                |
                | TX
          +-----+----+
          | Netduino |
          +----------+

Click to see larger version...

I guess the output of toggling switch UP is affected by DisableInterrupt() and EnableInterrupt() calls in the event handler - it most likely causes the other interrupts to be ignored/missed.

I would recommend you to remove those Disable/EnableInterrupt() calls; and also change the interrupt trigger to InterruptEdgeHigh, so the button release event is not generated (you can add it back again later, if you need it). Also, apparently the switch bounces, so you'd need to implement either hardware or software debouncing (or both).

You can make the circuit a little bit simpler by switching to pull-up resistors, because you can enable the built-in ones (in the InterruptPort constructor); then you'd need to use InterruptEdgeLow instead.

So, I'm not going to be able to create any kind of radio signal by toggling a port on the Netduino ... at least not in the amateur bands (2 meter band). That would require about 145 MHz.

You should have mentioned that in the original post - Shield Base has STM32F205 microcontroller that runs at 120 MHz, Netduino Go STM32F4 at 168 MHz. So, not enough for 145 MHz pin toggling even when done in assembly...

5V

All Netduino-s use MC33269DT-5.0G (datasheet pdf) linear regulator (LDO), which has "Output Current in Excess of 800 mA".

3.3V

Netduino gen 1 use 3.3V variant of the same LDO (MC33269DT-3.3G), which means max 800 mA, but it is connected to 5V LDO, so the effective max current will be smaller, due to losses.

Netduino gen 2 use DC/DC converter based on ST1S12GR (datasheet pdf), which has output current 700 mA (again connected to 5V LDO, so the effective max current will be smaller due to losses).

The 125 mA limit applies to microcontroller pins, not power rails. You have to subtract current consumed by Netduino onboard circuitry (30 ~ 100 mA) from the regulator output.

There is one very interesting comment (the first one) for channel9 Visual Studio Team Interview Fun with the Interns: Santiago Fernandez on LLVM Based Optimizer for MSIL, which mentions SharpLang - a .NET (MSIL) compiler front-end for LLVM. Has anyone had a chance to play with it already? Any thoughts?

IMVHO it will be rather hard - as you can see in the datasheet, the LCD requires complex driving signals with precise timing (e.g. t_CPH is 99 .. 107 ns) and multiple voltages (for an overview how to drive LCD with a microcontroller have a look for example at AN658). You'd also need some serious tools for troubleshooting, like oscilloscope and/or logic analyzer.

There are microcontrollers with dedicated (hardware) LCD drivers, e.g. STM32F427/37, which makes it a little bit easier, but still it is going to be a lot of work...

Much easier is to use the existing driver board from the TV and hope it has some usable interface. Almost certainly undocumented, so you'd need to decode the protocol...

But my code is confirmed in native project(Keil), now I'm finding the problem.

When you use your ISR handler, have you disabled/removed the one in the firmware? There will be a conflict - .NET Micro Framework does not have any support for hardware resource sharing/management, so one must be a little bit careful when adding custom functionality.

Also, there are some things you have to add to your native code (which works in Keil) to make it work correctly in .NET Micro Framework - such as properly reserve the pins, use lock macros, etc.

You should be able to hit a breakpoint in an ISR handler - if you can't, it can indicate it is never called (do you actually activate/enable it in your code?).

What version of Netduino do you have? Are you developing a port for a new microcontroller? There is already USART ISR handler implemented in the firmware - you can use it as a reference for things needed to get it work (e.g. configure pins, enable peripheral clock, activate interrupt, setup USART module, use locks etc.).

Default PK use GPIO ISR handler for checking out the stream on usart. I will test and share results.

 
Well, not really - STM32F4 firmware uses USART interrupt handlers, see STM32_usart_functions.cpp:

CPU_INTC_ActivateInterrupt(g_STM32_UART_Irq[uartNum], STM32_USART_Interrupt0, 0);

GPIO ISR is used in STM32_GPIO_functions.cpp to handle pin interrupts, does not do anything with USART.