NETMF 4.3 Community Ports

Archive
1

EDIT: Link to the ports collection:


Alright, I’m ready to take the plunge and start a community edition fork of NETMF. I’m looking for suggestions, ideas, and organizational tips from other members of the community.

Right now, I can picture the community edition consisting of two branches:

Mainline 4.3 + community extras + community ports
This branch would use a stable NETMF 4.3 base, but also include extra functionality in the form of additional interop libraries (Native DSP, image processing routines, whatever).

It would contain forks of all the GHI OSHW ports with community bugfixes (as well as other ports for other platforms). It would also contain support for non-GHI boards and other new platforms (we could really use a SAM4S port right now, as well as a high-performance port targeting one of the 400 MHz ARM9 MCUs) .

This branch would also contain native drivers for devices (and device types) not currently supported by NETMF.

This branch would compile under both GCC and MDK, and all components would be Solution Wizard-compatible, which would allow novice users to quickly add and remove features without having to mess with all the XML configuration files. Since solutions would compile against the mainline 4.3 branch, users would be able to use the existing 4.3 SDK to develop applications.

Experimental branch
This branch contains everything above, but breaks compatibility with the 4.3 SDK by introducing bug fixes and new features to core NETMF components. Because of this, this branch’s ports would not work with the 4.3 SDK.

Two separate branches can be a hassle to take care of, but while I’m interested in making core modifications to NETMF, I’m sure there are lots of developers who just need something simple fixed, or would like a native method to do ____. The Community Edition would provide a place for people to experiment, as well as to get problems fixed quickly.

Current Progress
I have an SVN repository set up with mainline 4.3 + the GHI open source ports + NicolasG’s Cerberus changes with quadrature encoder functionality. My changes that are part of the initial fork:
[ul]New “PacketRadio” HAL library category, which will support packet-based wireless transceivers.
CC1101 support for the above-mentioned HAL category
Managed interface to the PacketRadio HAL library category
Bugfixes to SPI interface on STM32F4 builds
Additional native utilities methods for doing things with arrays[/ul]

And soon to come:
[ul]Full power management support for STM32F4
Managed partial implementation of SimpliciTI WSN protocol
Native DSP library[/ul]

I’d love to hear people’s comments, concerns, and questions!

6 Likes
2

@ jay - This sounds very exciting! Especially the part about " high-performance port targeting one of the 400 MHz ARM9 MCUs". I don’t think I have the skills to contribute to the effort, but I would be very interested in following your progress and hopefully using the results. Have you published your SVN anywhere?

3

The plan is to open up the SVN very soon – I want to get a bit more feedback from people first. At that point, the SVN will allow anonymous check-outs. I’ll need to come up with some method of allowing contributions, too, obviously. I’m open to suggestions!

Code organization is going to be critical. Where should interop methods live in the porting kit? What about HAL support for new devices? Should managed-only libraries be allowed into the porting kit? And what sorts of namespace conventions need to be established?

1 Like
4

My suggestion would be to put it on GitHub. Then if people want to make a contribution, they can simply fork the repo, make their changes, then send you a pull request. This is the way most modern open source projects operate.

5

This is fantastic. Hopefully we will see serious contributors and GHI can find a way to help as well.

6

My lab uses SVN internally, so I had initially leaned toward using that. However, using GitHub makes a lot of sense – thanks for the suggestion!

1 Like
7

I like CodePlex - but it would be best to choose a repository that other developers on the project prefer.

8

CodePlex is OK too if you choose the Git repo option so that you have the “Fork” option. IMO, CodePlex doesn’t really compare to GitHub when it comes to the tools for community collaboration. It is prettier, though :wink:

9

VS2012 integrates with GitHub…

http://www.hanselman.com/blog/GitSupportForVisualStudioGitTFSAndVSPutIntoContext.aspx

10

Alright, the initial commit is on GitHub:

I have some initial ramblings on the Wiki page; hopefully the project stays well-documented.

I’d love to see library contributions – just please try to follow the best practices I’ve outlined in the documentation. There’s nothing more frustrating than trying to get someone else’s code to compile properly into a firmware image!

I’ve included the GHI OSHW libraries, even though they’re not properly declared in the framework. I hope someone can find time to get in there and add appropriate featureproj’s for the individual features.

3 Likes
11

I have to set up a GitHub account and learn how to use it.

Some features I can share for Cerb:

  • debug interface configuration (change USB to COM…)
  • config block access (store data in flash)
  • hardware serial number read
  • signal generator

Still need some work to cleanup the code and review some quadrature encoder features.

1 Like
12

Great, that’ll be awesome! I’m super excited about this project. I think it’ll be extremely useful to the community once we get some good libraries in there.

I’ve actually already implemented the hardware serial number read – in Solution Wizard, the feature is named “MC2.SerialNumber” – there’s a HAL abstraction layer for it. I’ve included an STM32F4 driver that should auto-select when you add the feature. If you want to support additional processors, just create a copy of the STM32F4 driver.

2 Likes
13

Excellent start Jay!

14

The organization of HAL-level code is going to be a mess. Initially, I thought everything could live in DeviceCode\ThirdParty[username or company]\Drivers[name of module]

But that only makes sense for external peripheral drivers (sensors, motor drivers, etc), but not internal peripheral drivers that are processor-dependent.

The SerialNumber driver is a great example. Many targets (processors) provide a unique device ID register, so it would make sense to have a HAL project for processors that support this feature. Additionally, there are many 1-wire/i2C read-only serial number chips that could work with any target. So, that should also be another option.

So, what I ended up doing what creating a new HAL library category (SerialNumber_HAL), and put a new project in the STM32F4 target folder that implements that functionality. Makes sense.

But where should the managed code live? And under what namespace?

My initial thinking was that everything would live under the name of the user/company that created the interface. That way, we wouldn’t run into conflicts; everyone could submit their own code, with their own way of doing things, and users could decide which implementation best suited their needs.

But we already have a possible conflict. It sounds like NicholasG has his own SerialNumber driver, which may be implemented differently from mine (probably for the better – as mine is sort of silly). Is he forced to use my library category (SerialNumber_HAL)? Should he make his own library category?

Do we really want different implementations of the same feature floating around? Maybe it makes sense to just have a “Community” namespace that all the features live under, and we all share in the code upkeep?

I’ll be honest – this is the first distributed software project I’ve ever worked on, so I’m not sure the best way to do this.

Anyone have any suggestions or ideas?

15

I think Generic Community namespace would make sense. The conflict is due to the fact that there were no central depository for this before.

I think for this particular feature you need to decide between two of you which implementation should go to the Community namespace.

16

Welcome to the Community namespace! We really need this to structure our contributions.
I used Cerberus namespace because I don’t feel like adding something on GHI.OSHW namespace as I’m not related to GHI.

[quote=“jay”]The organization of HAL-level code is going to be a mess
[/quote]
That’s why I published my work on CodeShare: no maintenance…

An open source project need to be organized and this takes time. You need to decide to integrate contributions. Only one implementation can live on the master branch.

Implementing a HAL driver for serial number is great. I think that a common use is to create a Guid. This need a 16 bytes array. That can be the standard length, keep zeros on left bytes.

Beyond this, such a feature shouldn’t be available in Microsoft.SPOT.Hardware.Cpu class, or Hardware.SystemInfo or Hardware.SystemId ? Should we create a Community.System class (I made this in my Cerberus namespace)?
If we plan to keep sync with the official NETMF, it is wise not to change the porting kit code itself and try to add feature by adding file like the serial number HAL driver.
But it is not always possible…

17

Agreed. Let’s do that. Community namespace it is.

We’ll probably want to sub-space is later on, but for now, let’s just do Community for any software libraries, and Community.Hardware for all of the hardware-related stuff.

Should Features show up in Solution Wizard as “Community.[Feature]” or just “[Feature]”?

It may be useful to remind people what’s part of the official NETMF and what’s only available in this fork.

18

I would prefer it listed as just [Feature ]. Keep it simple.

19

Alright

20

Thanks for the pull request, @ NicolasG!