Temperature or Temperature & Humidity? - Page 2 - Netduino Go - Netduino Forums
   
Netduino home hardware projects downloads community

Jump to content


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

Temperature or Temperature & Humidity?


  • Please log in to reply
24 replies to this topic

Poll: Temperature or Temperature & Humidity? (41 member(s) have cast votes)

On a Temperature Sensor how important is Humidity sensing?

  1. 1 (Not Important) (5 votes [12.20%])

    Percentage of vote: 12.20%

  2. 2 (1 votes [2.44%])

    Percentage of vote: 2.44%

  3. 3 (Nice) (13 votes [31.71%])

    Percentage of vote: 31.71%

  4. 4 (15 votes [36.59%])

    Percentage of vote: 36.59%

  5. 5 (Very Important) (7 votes [17.07%])

    Percentage of vote: 17.07%

Vote Guests cannot vote

#21 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 10 May 2015 - 03:07 PM

Yesterday I received my Netduino 3 WiFi board and wanted to start to connect modules to the three ports on the board.  First up was the Temperature and Humidity board developed a while ago.  I did not have the original binaries available and so had to recompile the library.

 

Enter stage left, compilation errors.

 

It looks like there have been a few nice additions to the GO! Which mean a few software modifications are required.

 

So let’s look at the original DHT22 module code and the current version.  But before I start I need to acknowledge the fact that 40% of the modifications made were me figuring stuff out, the remaining 60% were as a result of looking through Matt Issenhowers driver for the Komodex seven segment display module.
 

GoSockets are now GoPorts

Trivial change

 

ModuleGuid Property
This was not required in the first GoBus specification.  Not too complicated, it just returned the GUID of the module.
 

OnInterrupt Event

The initial version of the protocol required that the driver provided an InterruptPort variable which could be used to bind to an

/// <summary>
/// Interrupt port which will be connected to the Netduino GO! module.
/// </summary>
private InterruptPort _irqPort;

In the constructor / initialisation method you would bind the InterruptPort to a pin etc.

//
//  Now wire up the event handler so that we can respond to interrupts
//  from the module.
//
_irqPort = new InterruptPort((Cpu.Pin) socketGpioPin, false, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow);
_irqPort.OnInterrupt += _irqPort_OnInterrupt;

The new code is a lot simpler, the new code becomes an override method:

Protected override void OnInterrupt()
{
}

The interrupt code previously placed in the _irqPort_OnInterrupt method is now placed in OnInterrupt.
 

SPI Binding
The first drivers required the driver to bind to the SPI interface like so:

//
//  Get the resources which have been allocated to this module.
//
Cpu.Pin socketGpioPin;                  //  IRQ pin.
SPI.SPI_module socketSpiModule;         //  SPI module.
Cpu.Pin socketSpiSlaveSelectPin;        //  CS pin.
socket.GetPhysicalResources(out socketGpioPin, out socketSpiModule, out socketSpiSlaveSelectPin);
//
//  Now we know which SPI resources have been allocated to the module we 
//  can create an instance of the SPI bus in order that we can communicate
//  with it.
//
_spiConfig = new SPI.Configuration(socketSpiSlaveSelectPin, false, 0, 0, false, false, 10, socketSpiModule);
_spi = new SPI(_spiConfig);

The new code appears to do this for you automactically.  Less code - always nice  :D

 

Initialize Method
The Initialize method mandatory but a lot of the code from my previous initialisation method has now been made obsolete.  So the original method was:

private void Initialize(GoSocket socket)
{
    if (!base.BindSocket(socket, _moduleGuid))      //  Bind to the socket if possible.
    {
        throw new ArgumentException();
    }
    //
    //  Get the resources which have been allocated to this module.
    //
    Cpu.Pin socketGpioPin;                  //  IRQ pin.
    SPI.SPI_module socketSpiModule;         //  SPI module.
    Cpu.Pin socketSpiSlaveSelectPin;        //  CS pin.
    socket.GetPhysicalResources(out socketGpioPin, out socketSpiModule, out socketSpiSlaveSelectPin);
    //
    //  Now we know which SPI resources have been allocated to the module we 
    //  can create an instance of the SPI bus in order that we can communicate
    //  with it.
    //
    _spiConfig = new SPI.Configuration(socketSpiSlaveSelectPin, false, 0, 0, false, false, 10, socketSpiModule);
    _spi = new SPI(_spiConfig);
    //
    //  Now wire up the event handler so that we can respond to interrupts
    //  from the module.
    //
    _irqPort = new InterruptPort((Cpu.Pin) socketGpioPin, false, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow);
    _irqPort.OnInterrupt += _irqPort_OnInterrupt;
    _irqPortInterruptEvent = new AutoResetEvent(false);
    AlarmInterruptsEnabled = AlarmState.InterruptsEnabled;
}

It is now:

protected override void Initialize()
{
    AlarmInterruptsEnabled = AlarmState.InterruptsEnabled;
}

The final change is in the way the SPI reads/writes are handled.  In the initial drivers this was performed by the developer, the current library has these provided for you.  So the original code looked something like this:

private void WriteDataToModule()
{
    for (int index = 0; index < GO_BUS10_FRAME_LENGTH; index++)
    {
        _readFrameBuffer[index] = 0;
    }
    _writeFrameBuffer[_writeFrameBuffer.Length - 1] = CRC8.Compute8(_writeFrameBuffer, 0, _writeFrameBuffer.Length - 1);
    _spi.WriteRead(_writeFrameBuffer, _readFrameBuffer);
}

And the new code looks like this:

private void WriteDataToModule()
{
    for (int index = 0; index < GO_BUS10_FRAME_LENGTH; index++)
    {
        _readFrameBuffer[index] = 0;
    }
    _writeFrameBuffer[_writeFrameBuffer.Length - 1] = CRC8.Compute8(_writeFrameBuffer, 0, _writeFrameBuffer.Length - 1);
    GoBusSpiWriteRead(_writeFrameBuffer, _readFrameBuffer);
}

I have added the original and the modified versions of the driver to this post for those who are interested in developing modules.

Hope you find this useful,

Mark

Attached Files


To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#22 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 10 May 2015 - 06:52 PM

Hey Nevyn,

Thanks so much for sharing your experiences here, and for building such cool stuff.

More streamlining and simplification to come...

Chris

#23 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 10 May 2015 - 07:07 PM

The simplification was very welcome :)

Cheers,
Mark

To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#24 Matt Isenhower

Matt Isenhower

    Advanced Member

  • Members
  • PipPipPip
  • 74 posts
  • LocationSan Diego, CA

Posted 11 May 2015 - 05:37 PM

It looks like there have been a few nice additions to the GO! Which mean a few software modifications are required.


Great overview of the differences in the new GoModule base class. Just to add a little background, the SPI changes became necessary because (as of NETMF v4.3?) it was no longer possible to have multiple SPI objects open on the same SPI bus. In my experimental library I just create/dispose of an SPI object for each message, but I think in Chris' library he routes everything through a central, shared instance.

This change and the IRQ/GPIO line changes also help prepare for changes that could come with GoBus 1.5 (for things such as routing messages to GoBus hubs, etc.).

Making the module GUID an abstract property is mostly cosmetic but it does help simplify/standardize the module discovery and instantiation processes. It also makes sense since the ID is literally a property of the module :)

Matt
Komodex Labs
Follow me on Twitter: @mattisenhower

#25 Rx7man

Rx7man

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationInterior BC, Canada

Posted 12 May 2015 - 04:27 PM

It really depends on the application.. for some things humidity is completely irrelevant, and on others it is essential.

 

I was thinking of making a tobacco curing oven.. humidity would be critical on that application :)


I'm at the point on this learning curve where I have more questions than I do answers.. sorry about that!





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

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.