Hi tonofsteel,

We use the RVCT compiler in ARM RVDS to compile Netduino firmware.

There have been some awesome community efforts to get the NETMF firmware to compile with GCC, but official NETMF support for GCC typically lags behind (i.e. not synced with releases). GCC used to compile really big code and so it was less desirable, but with more recent compiler improvements GCC support should probably be pulled in as a synchronized compiler option.

If you pull one of the NETMF-GCC projects from the web and the latest Netduino firmware source from the Downloads page, that will give you a starting point. [We will also be checking in Netduino source to the Netduino github site once NETMF 4.4 is released, like the core NETMF distribution.]

Most developers are interested in Netduino and NETMF for writing C# apps, so that is where most of the focus has been.

On native compilation (interop or otherwise): this is something we've been talking about with the team in Redmond for quite a while. There are certainly applications where this could be beneficial, and we may be able to bring this to a future release of NETMF, but nothing to announce today.

I know that's not a ton of helpful info to get you off and running, but does that at least get you started down the path?

Chris

 

Thanks Chris and neslekkim, I did happen across those two in the past and since posting I have found my original cache of links to relevant sites.  When looking I forgot to look at the NETMF-GCC code bases that were for the STM32 and not exactly for the Netduino, so yes that will be an excellent place to cross reference for clues.

 

If I ever get any headway on this I will post back and investigate creating a wiki article like referenced above with anything useful I find.....

I would like to start digging into native development with the Netduino.  I have been following the other previous threads and tutorials but they are getting dated now.  What is the current state of the tools and procedures for native development?

- What toolchain does Secret Labs use?  Can I use GCC and create something reasonable that works?

- There were tutorials on building the firmware in the wiki/forums, are these still relevant or is there something newer?

 

I did see in the past where it sounded like there was going to be a mechanism to load native compiled libraries to run native code easily but it does not look like this went anywhere.

 

It seems like if you use the Netduino for awhile and you end up wanting to use it for something that has fast (well, fast for netduino but slow for the rest of the embedded world) response requirements that you need to dive into the lower native layer to get it done.

 

Is the complete source available on github anywhere?  I searched and could find the IP components but not the native netduino parts.

 

Could there be a native development forum created that addresses just native development?  I have worked with native STM32 coding but it almost seems like the .NET micro / Netduino firmware development is the best kept secret.  Are there any resources that make it easier?

 

From what I know currently the steps are:

- get a GCC compiler and install

- Have Visual Studio with C++ installed (not sure if VS is even needed though, also not sure if C++ is required but I thought I saw reference to things not compiling without it?)

- Download .NET micro porting kit and extract to directory

- Overwrite with Netduino native firmware

- Overwrite with another firmware package (cant recall which forum post exactly had this) in order for GCC to actually work

- For this example add your driver solution to the source

- Add stubs

- Code

- Modify project files to include these driver projects, both native and managed

- Compile

 

Out of all of that it is not entirely clear as to what/why you need to modify/overwrite certain parts.  This whole .NET micro / Netduino thing would be massively more useful if you could actually get some clear information on how this all works.

 

I am used to the build process for native code on micro's directly.  There is much less indirection and complication to get around, it seems trivial to get a hello world demo going on almost any other firmware development project other than anything related to .NET micro native development.....

 

Ah ok I think I see it now.  So if I understand this correctly I can change the other clock prescalers in the firmware and end up with slower speed options since they APBx clocks are running at max right now?

Thanks CW2!  This helps a lot.

 

I downloaded the manuals and data sheets for the STM32 and read through them again today.  I think part of the reason why I was getting confused is that from the clock tree diagrams it shows the AHB prescaler going to the APBx prescaler.  The AHB has /1, /2, ... /512 while the APBx prescaler has /1, /2, ... /16

 

I see the max frequencies you reference in the data sheet and manual as being the max allowed for each bus.

 

I am not sure how to correlate the chart going to 256 with the manual/data sheet, does it go to 256 due to a combination of setting the AHB and APBx clocks in combination?

 

Are the values you list just for setting the SPI_I2SPR prescaler register?  I don't remember seeing anything in the .NET micro framework for changing clock settings so I am guessing that if I wanted to change the APB clocks this would be a firmware extension.

What are the possible speeds for the SPI port on the Netduino Plus 2?  I have read that you can use the .NET SPI config with any speed you want but internally the firmware will actually change this to a valid speed.  This valid speed is based on the internal STM32F4 SPI clock prescaler.

 

I have tried to read through the data sheets and look for any forum posts that reference how this would all tie together but I am still not clear on it all.

 

Even in the datasheet it says what the max rate for the SPI interface is but not much about what the valid ones are.  In the manual it said that it can have different values using the prescaler on fPCLK.

 

Is there any explanation for how this works or what the valid values are for this anywhere that does not involve reverse engineering the STM32 clock tree and .NET micro firmware?  Even if I calculate from the datasheets what the values are it is not clear what the Netduino firmware does when you select an arbitrary value for the SPI initialization, unless you are familiar with the firmware source I suppose.

 

I thought I read there were 8 or 12 valid prescaler values so this surely can't be too large of a table to include in any documentation? 

 

Was reading some more about .NET micro and found the following page:

http://msdn.microsof...y/cc533011.aspx

 

Which lists the following namespaces:

 

Microsoft.SPOT.Input Contains tools for collecting and managing user input. Microsoft.SPOT.Presentation Provides the ability to design and control the layout and display of graphical user interface elements. Microsoft.SPOT.Presentation.Controls Enables your program to create elements (known as controls) that make it possible for users to interact with the programs. This namespace also provides support for displaying text. Microsoft.SPOT.Presentation.Media Gives your applications the tools required to draw and manipulate bitmapped images. Microsoft.SPOT.Presentation.Shapes

Provides tools that enable your programs to draw two-dimensional (2-D) geometric shapes.

 

I asked a similar question previously but this one is different/more specific.  If I have a LCD would I need to create a native driver using the porting kit?  What capability does the above have out of the box for drawing on any physical device?  I do not see anywhere how to map the pins to a graphic device.

 

If you use the porting kit how do you wire up your driver so that when you use the above namespaces it draws to your LCD?

 

I cant find any information on the actual implementation of drivers (managed or native) for anything in the .NET micro framework.  I know with embedded c you write the driver and then use your code directly.  With the layer of abstraction that .NET micro adds it is not clear how the high level C# code gets down to the physical hardware and native code if it is required.

Is there anywhere to learn more about how the interfacing of hardware to the final software is done?  I search and see lots of examples showing basic 2x20 character LCD libraries and code but not so much when things get any more complicated than that.

 

I have read the following:

http://highfieldtale...0-eve-microwpf/

 

After going through the source code it looks like the Window object is part of the library he wrote and inherits ContentControl.  There are controls and code that are part of the library and then other parts that are part of the .NET micro WPF, but it is not clear what is part of which.

 

Is there any good documents/books/blogs/etc that shows more details about taking a piece of hardware like a Ethernet module or LCD and interfacing it to the point of using it in the software?  the LCD can have something like the EVE FT800 as above or it could be a "bare" LCD with only a parallel interface.  An Ethernet module can have the same, a serial/SPI interface or connect to the on-board interface (is it MAC onboard with the PHY as a separate chip?)

 

I know the chain goes something like this:

Hardware->Comm protocol/interface->driver->OS/bare metal interface->library usage in application code

 

For the Netduino Plus 2 how do I learn more about this chain?  I know in many cases you may have to write the driver portion of things, but where/how does this connect into .NET micro framework?  If there is WPF available I would think that somewhere as part of the .NET micro you implement an interface that calls your driver code.  This would handle all the logistics of drawing so then when you create a new form/window the WPF part of the framework calls the interface (which you would have told .NET micro about)

 

I think this concept comes up with almost any platform.  If you were using a Linux based system you would still have the hardware->driver->tell the OS about it connection.

 

Can anyone offer any insight?

What if you try: 

serverSocket.SetSocketOption(SocketOptionLevel.Udp, SocketOptionName.Broadcast, true);

or:

serverSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.Broadcast, true);

In case anyone else does similar -> the IC in the red square IS the 3.3V regulator.

 

Ordered this:

http://www.digikey.c...06-1-ND/1880284

 

I replaced it, and now have a fully functioning board again!

I have heard this referred to in a couple of posts that there is a gold pad that when connected to 3.3V will erase and reset the Netduino/STM32.  I also heard that this was not for Netduino/Plus 2, only first gen?

 

Is there a hardware reset for the STM32 or was this for the other microcontrollers that were used in other board revisions?