Can I use 1-Wire devices with Spark Core?

General
41

Thanks for all your help. Here is a link to my project files (displaytemp is the main file)
https://drive.google.com/folderview?id=0B6e1_AXIkeDPZFBqaGdsamxBSGs&usp=sharing

I still get the same error despite removing that block of code. I don't understand as in DallasTemerapture.cpp line 3 is now blank and line 4 is completely different now I have removed that chunk of code but I am getting the same error..... (I have copy and pasted the first 15 lines of the file below):

DallasTemperature.cpp:3:32: error: expected constructor, destructor, or type conversion before ';' token
DallasTemperature.cpp:4:25: error: expected constructor, destructor, or type conversion before ';' token
make: *** [DallasTemperature.o] Error 1

(Contents of DallasTemerapture.cpp)

#include "DallasTemperature.h"
#include "spark_wiring.h"

DallasTemperature::DallasTemperature(OneWire* _oneWire)
  #if REQUIRESALARMS
  : _AlarmHandler(&defaultAlarmHandler)
  #endif
{
  _wire = _oneWire;
  devices = 0;
  parasite = false;
  bitResolution = 9;
  waitForConversion = true;
  checkForConversion = true;
}
42

gorstj, you really need to post your code because I am having difficulties figuring out how you have everything loaded. Can you do that?

43

@gorstj also please use this method as it will pretty up your code posting:

44

@gorstj and @gilius, I think I have found the issue, but am not sure about the correct solution.

The error is cause at the end of the DallasTemperature.cpp file. There is a statement:

#if REQUIRESNEW

// MnetCS - Allocates memory for DallasTemperature. Allows us to instance a new object
void* DallasTemperature::operator new(unsigned int size) // Implicit NSS obj size
{
  void * p; // void pointer
  p = malloc(size); // Allocate memory
  memset((DallasTemperature*)p,0,size); // Initalise memory

  //!!! CANT EXPLICITLY CALL CONSTRUCTOR - workaround by using an init() methodR - workaround by using an init() method
  return (DallasTemperature*) p; // Cast blank region to NSS pointer
}

// MnetCS 2009 -  Unallocates the memory used by this instance
void DallasTemperature::operator delete(void* p)
{
  DallasTemperature* pNss =  (DallasTemperature*) p; // Cast to NSS pointer
  pNss->~DallasTemperature(); // Destruct the object

  free(p); // Free the memory
}

#endif

Since the header declares REQUIRESNEW=false, these are unneeded (unless you want the new and delete operators).
If you simple remove that whole logic block, it compiles just fine.

Any other gurus know how to get that code to compile properly using the WebIDE?

45

Thanks Bill
Deleting this line worked a treat.
How did you figure it was this bit of code causing the error?

I note this bit of code seems to free the memory - will this cause memory leak issues?

Thanks

46

I just ran through the code looking for unusual declarations. I also tested out by removing large chucks of code and seeing if it would compile.

As for the impact, I am not 100% sure. If you look in the header, the ifndef statement looks like that chunk of code would not have even been included unless you added the REQUIRESNEW=true somewhere else in your app.

Semi unrelated, but I ended up porting a 1-wire lib from another project that is much smaller than this one. Give it a shot if you like. Here is the link to the github.

47

Anyone have a link to the hardware 1-Wire library another user posted awhile back? Search isnā€™t turning it up for me. (IMO I think itā€™s the best implementation for the Core so far.)

48

@timb I wrote the hardware onewire implementation and my forum post was here: Interrupt driven OneWire bus using USART hardware

The branches I have published on github are a bit out of date with the current spark master but should still merge up just fine.

49

mattande, if I understand correctly, your interrupt driven OneWire library is now incorporated in the core master? Or is it a separate implementation of the OneWire library than the master?

50

None of this work has been merged (or pull requested) to the spark repositories. If you are building locally you can merge the mattande/core-firmware@onewirehw and mattande/core-common-lib@onewirehw branches to bring in the hardware onewire support.

The onewirehw,cpp, onewirecrc.c and onewire_ds18b20.cpp files could be used as external libraries in the web ide (by including the required files), except there is a change in it_stm32.cpp which is needed to add the interrupt sharing between the OneWireHW object and the Serial1 object (They both use the STM32ā€™s USART2). At least this USART2 interrupt sharing change would have to be merged on the spark master.

I am open to pushing this upstream if there is interest.

51

+1 on that pull request for me.

52

I like the spirit of using the UART for one-wire, but the extra external hardware is going to put off some, especially novices.

53

I added an option to use the STM32ā€™s internal open drain driver and bridge the USART RX and TX pins internally (half-duplex mode), eliminating the need for an external drive circuit. The only required hardware is the 4.7K pull up resistor if you use that option.
Thereā€™s an update on this a few posts down in the thread.

54

Sorry I missed that! That is quite nice then.

The only issue is how to make sure the user doesnā€™t try to use both Serial1 and one-wire. Hopefully users would figure out the problem when they tried to connect to the coreā€™s pins!

55

I donā€™t think thatā€™s really an issue as theyā€™d physically be hooking the 1-Wire device up to the TX pin, which means they canā€™t very well hook something else up to it. (Well, I guess they can but in that case Serial1 wouldnā€™t work either!)

And yes, please do a pull request on this! Itā€™s awesome! (It actually inspired me to do my own implementation on the MSP430 using a spare USART.)

56

I would be interested in this too

+1 for pushing this upstream

57

Iā€™ve been testing the code form Google Drive and got it to compile with @billprozacā€™s tips. It all compiles. When I hook the DS18B20 sensors up, though, with any combination of pull-up resistors ranging from 1k-5k, I get ā€œ85.0ā€ readings indicating an error somewhere. Iā€™ve re-wired and triple-checked the wiring a dozen times over (so it feels anyway). Iā€™ve tried the sensors backwards, which makes them get extremely hot, so at least I know they are orientated correctly.

Also: sensor.getDeviceCount()) is returning ā€œ0ā€ when run in setup(). Seems plenty is not right here but Iā€™m a little new to this.

Whatā€™s the consensus on the best library to use at this point? I may have exhausted my attempts with the Gdrive version.

58

I used this one from @wgbartley but you have to edit out all the other stuff you donā€™t need since this was from a time before the webIDE supported multiple files.

Find this section and copy starting here:

// ONE-WIRE CLASS
#define OneWire_h
#include <inttypes.h>

and end here:

    return crc;
}
 
 
// THERMISTOR CLASS

The example in that gist does not check crc but I have tried adding those checks and it works fine. I took the CRC calculation out for now since on the breadboard they were not needed. Over a longer wire,I would put them back in.

I am using 4.7k a pullup. Here is the code to read the temp:

void getTemp() {
    // Get the ROM address
    one.reset();
    one.write(0x33);
    one.read_bytes(rom, 8);
    // Get the temp
    one.reset();
    one.write(0x55);
    one.write_bytes(rom,8);
    one.write(0x44);
    delay(10);
    one.reset();
    one.write(0x55);
    one.write_bytes(rom, 8);
    one.write(0xBE);
    one.read_bytes(resp, 9);
    
    byte MSB = resp[1];
    byte LSB = resp[0];
    
    int16_t intTemp = ((MSB << 8) | LSB); //using two's compliment 16-bit
    tempC =   ((double)intTemp)/16.0;
    tempF = (( tempC*9.0)/5.0+32.0);

}

One other point: with heavy use, the spark core runs warm and can get the DS18B20 up a few degrees if it is in close proximity. The one on the desk next to me is reading 76.2 degrees in room where the air temp is closer to 70.0. They are very sensitiveā€“try putting your finger tip on it and see if it doesnā€™t jump up quickly.

1 Like
59

Thanks very much for replyingā€¦ I meant to get around to looking at this much earlier!

The link to the Gist you referenced was missing, but I think I found it ā€“ this one https://gist.github.com/wgbartley/8301007 ?

I got it working with one sensor. Great success! Hereā€™s my code (I had no luck breaking this into multiple files): https://gist.github.com/rypalmer/9696170

When I add a subsequent sensor, though, (2x DS18B20ā€™s, one ~5k pullup) I get really high readings in the serial output:

Sensor 1 temperature: 4095.94

Iā€™ve alternated sensors verifying both work great independently. Any idea how to use this example to read multiple sensors?

Thanks again for the help!

2 Likes
60

Hi @rypalmer

When you have more than one 1-wire sensor on a shared data line, there is different discovery protocol you have to use to find them all and address them individually.

This web page has a good summary:

2 Likes