A request for some help understanding NetMF, and lower level code

The specific request centers around the 1-Wire driver, but looking for that aha moment where the directory structure, compiling, and access to underlying features all come together.

This specific case example, I’m looking at switching the speed from normal to Overdrive.

Using Object Browser / Redgate, I can drill into the "v4.3\Assemblies\le\Microsoft.SPOT.Hardware.OneWire.dll"
And go thru every command, included the parameters that are available for each, and no where is there a mention of speed.

So then, go back to the basics, "NETMF/netmf-interpreter/blob/dev/DeviceCode/pal/OneWire/OneWireLinkLevelDriver.cpp"
and this code exists

SMALLINT owSpeed(int portnum, SMALLINT new_speed)
{
   if((portnum >= MAX_PORTNUM) || (portnum < 0) || (owPortPin[portnum] ==0)) return 0;

   USpeed = new_speed;
   // not supported yet

   // TODO: Research overdrive.  33mhz should handle it.

   return 0;
}
  1. I may have answered my first question, that the // not supported yet, means why I’m not able to find the command?
  2. If I do want to use that feature, does it mean I need to figure out how to compile the complete Netmf Framework?
  3. If I do recompile the complete framework, do I loose all the Custom GHI, G400 features?
  4. If its a simple as getting the timing correct, is there any way to override the

/DeviceCode/pal/OneWire/DallasSemi/ownet.h
SMALLINT owSpeed(int portnum, SMALLINT new_speed);

variable without recompiling the entire framework?

There is just a Large number of features that are in these files, ie CRC16, (as I discover it, after recreating it in managed code), that are of value.

Also, trying to find the file
// external One Wire functions from link layer owllu.c
so wouldn’t mind if someone pointed me the right direction there…

Also, given most of the code was originally written by Dallas Semi, If I was able to put a little pressure on Maxim to get them to complete the function(s), Is there any way to get it merged with the current version (4.3) that I’m using, or would it have to wait till the next official release? Where I worked previously, we would buy sensors literally millions / year, so, still have a few contacts there.

When you’re updating code in NETMF, yes, you’ll need to recompile the entire framework. Be aware that once you do this, however, you’re no longer on GHI’s version of NETMF, so you lose any GHI-specific features (such as RLP).

If you contribute the updated code to NETMF, you’d need to wait for it to get accepted (which would take an unknown amount of time), and then wait for a release to happen (unknown amount of time) and finally wait for GHI to take the updated NETMF release and build an updated framework with it (don’t hold your breath).

You could contribute the code directly to GHI, who could incorporate it directly into their NETMF version, but don’t count on that happening either.

Your most sure bet is to bust out your wallet and call GHI for some custom consulting work.

@ godefroi - That’s already been done, (the wallet thing), but it still doesn’t change the fact I want to understand for myself whats going on… Helps in avoiding those fond of Buzzwords (and just to be clear, that was NOT a reference to GHI, but new programmers being brought on)…

@ godefroi - After thinking about it for a second, and this is part of what I’m asking for help understanding, is I download the original framework online, then ADD GHI’s SDK;s, so as long as I’m only tinkering with the Microsoft part, why can’t I add on GHI’s portion after? (For the record, not using RLP, but definitely see the benefits of that option). This isn’t so much about getting the exact answer for the above question, as it is about trying to wrap my head around just how deep these waters are… I’ve already substituted a standard speed IC for the one I needed overdrive for, but needed a way to frame my questions.

@ michaelb - GHI’s version of NETMF is no longer open source. You can’t add GHI’s custom additions, because they rely on underlying support in NETMF. You’d have to get them to include your code in their version, and have them provide that version to you.

In the past, they have not proven eager to include features developed by the community into their fork of NETMF.

@ godefroi - Fair enough, although I’ve been trending away from anything custom, (including Gadgeteer). I still say, if you don’t “change”, anything that already exists in the Microsoft Version, you shouldn’t break any dependencies, but, if the SDK is compiled to look at a specific CRC, or other identifying feature, fair enough, they are a company, but good to know.

That said, I still want to learn a bit more about how all of this goes together, and I’m slowly, getting a much better picture. There recently was a post on here, how to add custom stubs that cleared a LOT of confusion for me, why there was two copies, (c#, vs C++) of everything. (I still don’t get why there didn’t need to be a VB version, but I assume, the C# version could be a VB version as my understanding is they compile down to the same symbols on the CRL.

Either way, I’m not asking these questions with a couple of hours into to this, but trying to ask educated questions, after spending a lot of time learning what I don’t know…

I do appreciate the help