Netduino home hardware projects downloads community

Jump to content

The Netduino forums have been replaced by new forums at This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Blake Ramsdell

Member Since 18 Aug 2010
Offline Last Active Nov 16 2012 11:12 PM

Posts I've Made

In Topic: Reading binary resources piecemeal

20 December 2011 - 05:21 PM

If only there was a way to implement a test of code to see if it works. An "automated test" if you will.


if(offset + length >= size)
    length -= size - offset; 

Seems like this is wrong in at least a couple of ways. I think:

if((offset + length) > size)
    length = (size - offset);
Is both clearer and less buggy.

So I think in your first case you ended up with:

if(0 + 8 >= 8)
    length -= 8 - 0;
So your length ended up as 0 in this case.

if(0 + 20 >= 8)
    length -= 8 - 0;
So your length ended up as 12 in this case (8 bytes of your resource data and four bytes of god knows what).

Happy to submit a patch, but I need to spend an hour and figure out how to do it and get the code. I was able to figure this out by browsing the source on CodePlex.

I'd say in the interim just make your resource one byte larger than you need. So nine bytes and then just know that the first eight are the "real" resource.

In Topic: What is "variable-bit SPI"?

25 January 2011 - 08:38 PM

The same thing happens with SPI. Most devices use 8-bit transfer (or 16-bit), but there are some that need 9-bit transfers. Or 11-bit. This seems to happen most frequently in SPI-based graphical displays.

OK, thanks Chris -- I have Xilinx SPI myopia and that's all 8-bit. Thanks for all the followup.

In Topic: What is "variable-bit SPI"?

25 January 2011 - 09:49 AM

Thanks for all of the followup, and I understand that there are some changes in alpha 6 that should help. I would be interested to hear some more about the rationale for the change. That is, I presume that this field was added to handle a particular SPI use case. What is it? Is there some environment that takes a stream of bytes, but those bytes are padded with leading / trailing zeroes up to some field length? Certainly if there is another forum post about this, I'd appreciate a pointer and I'll go read it and comment there as appropriate. I guess as long as the default value in the final release keeps all of the existing SPI code working, I don't care. But something smells wrong here.

In Topic: NETMF constants

09 January 2011 - 10:49 PM

In part this makes sure the user is aware of how many SPI modules are available. Also vendors can assign SPI1 to another constant other than zero. Microsoft recommends building a HardwareProvider for each board this way in the porting kit...

Now I'm really confused. So they provide a constant. That might not work at all on some particular platform. How is that useful?

It sounds like you should never, ever used the Microsoft-provided one, and always use the vendor-provided one, since it's possible that the vendor might choose a different SPI identifier than Microsoft...

In Topic: NETMF constants

09 January 2011 - 09:15 PM

IMHO there are two possibilities:

1) #if preprocessor directive and set appropriate symbol in Project Properties "Conditional Compilator symbols", you'd probably need to create new build configuration for each platform (i.e. "Debug - Board_XXX", "Debug - Board_YYY")

#if Board_XXX
Cpu.Pin pin = (Cpu.Pin)xx;
#elif Board_YYY
Cpu.Pin pin = (Cpu.Pin)yy;
#error Unsupported board.

This path is a little futzy and problematic. For example:

Cpu.Pin pin = SecretLabs.NETMF.Hardware.Netduino.Pins.GPIO_PIN_D3;
Cpu.Pin pin = (Cpu.Pin) GHIElectronics.NETMF.FEZ.FEZ_Pin.Digital.Di3;
#error Unsupported board, smooth move. Why don't you figure all the possible #defines and stop wasting my time?

As well as custom build code so that you include the right assemblies for the right variant of NETMF in the csproj file:

For Netduino:

<Reference Include="SecretLabs.NETMF.Hardware" />
<Reference Include="SecretLabs.NETMF.Hardware.Netduino" />

For FEZ:

<Reference Include="FEZDomino_GHIElectronics.NETMF.FEZ" />

And I presume there's a way to stick those in a PropertyGroup with an appropriate Condition on it.

2) Check SystemInfo.SystemID properties in runtime - if they are not filled correctly, you'd probably need to examine SystemInfo.OEMString

if(SystemInfo.SystemID.OEM == ... && SystemInfo.SystemID.Model == ...)
  return (Cpu.Pin)xx;
if(SystemInfo.OEMString.IndexOf("Board_YYY") == 0) // For demonstration purposes only
  return (Cpu.Pin)yy;

This is what I actually did in the code. So I have one function that does the magic based on SystemInfo.OEMString:

// SetupCurrentShieldConfiguration is a little fragile -- it uses
// Microsoft.SPOT.Hardware.SystemInfo.OEMString to try and figure out
// which configuration to use. If that string isn't handled, you will
// not survive.

private static void SetupCurrentShieldConfiguration()
    var oemString = SystemInfo.OEMString;

    switch (oemString)
        case "GHI Electronics, LLC":
            CurrentShieldConfiguration = FezShieldConfiguration;

        case "Netduino by Secret Labs LLC":
            CurrentShieldConfiguration = NetduinoShieldConfiguration;


And then I cribbed the constants from the various places:

private class ShieldConfiguration
    public Cpu.Pin RedLedPin { get; set;  }
    public Cpu.Pin GreenLedPin { get; set;  }
    public Cpu.Pin SpiChipSelectPin { get; set;  }
    public Cpu.Pin OnboardLedPin { get; set; }

private static class NetduinoConstants
    public const Cpu.Pin GPIO_PIN_D0 = (Cpu.Pin) 27;
    public const Cpu.Pin GPIO_PIN_D1 = (Cpu.Pin) 28;
    public const Cpu.Pin GPIO_PIN_D2 = (Cpu.Pin) 0;
    public const Cpu.Pin GPIO_PIN_D3 = (Cpu.Pin) 1;
    public const Cpu.Pin GPIO_PIN_D4 = (Cpu.Pin) 12;
    public const Cpu.Pin ONBOARD_LED = (Cpu.Pin) 55;

private static ShieldConfiguration NetduinoShieldConfiguration = new ShieldConfiguration
    RedLedPin = NetduinoConstants.GPIO_PIN_D3,
    GreenLedPin = NetduinoConstants.GPIO_PIN_D4,
    SpiChipSelectPin = NetduinoConstants.GPIO_PIN_D2,
    OnboardLedPin = NetduinoConstants.ONBOARD_LED

private static class FezConstants
    public const Cpu.Pin LED = (Cpu.Pin) 4;
    public const Cpu.Pin Di4 = (Cpu.Pin) 19;
    public const Cpu.Pin Di3 = (Cpu.Pin) 31;
    public const Cpu.Pin Di2 = (Cpu.Pin) 33;

private static ShieldConfiguration FezShieldConfiguration = new ShieldConfiguration
    RedLedPin = FezConstants.Di3,
    GreenLedPin = FezConstants.Di4,
    SpiChipSelectPin = FezConstants.Di2,
    OnboardLedPin = FezConstants.LED

I kinda feel icky about cribbing the numbers for everyone's pins, but this was the most elegant way I could come up with a solution.

Thanks for all of the help -- further suggestions welcome.

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.