tonofsteel

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.....

 

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?

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?