DS18B20 return Fahrenheit instead of Celsius

Yes, another *C to *F conversion question ::).

I've been searching around the internet and looking over the DS1820 'c' & 'h' files for the last three+ hours and maybe I'm exceptionally dense, but I cannot figure out for the life of me exactly how it comes to the Celsius value that it displays on a LCD and transmits over a NRF24L01 transciever, or how I could get it to return Fahrenheit. I note a bunch of references to 'decicelsius' in the ds1820 files.

In what I believe can be considered the main code, there is 'lcd_puts(tempStr);', which puts the reading up on the attached LCD. There are absolutely no references to 'tempStr' in the ds1820 files, and in the main file, there is the following:

_delay_ms( DS18B20_TCONV_12BIT );
                ret = DS18X20_read_decicelsius_single( gSensorIDs[0][0], &decicelsius );
                if(ret==DS18X20_OK)
                {
                    mjerenjeOk = 0;
                    DS18X20_format_from_decicelsius(decicelsius,tempStr,7);

                    //change ',' to '.'
                    uint8_t j = 0;
                    while(tempStr[j] != ',') j++;
                    tempStr[j] = '.';

This appears to be where decicelsius and tempStr 'merge'. I'm guessing that it's here that the 'tempStr' value is determined.

How exactly is code parsed? Is it top down, and is it the 'main' file first? If so, would it make sense to add a value, 'tempStrF', for example, and add an entry to the effect of 'tempStrF = (tempStr* 9.0)/ 5.0 + 32;, and then in every place that I'd want Fahrenheit displayed or transmitted, change 'tempStr' to 'tempStrF'?

In the other example for the DHT22, the line was '*temperature = (*temperature * 9.0)/ 5.0 + 32;', which, although it works, doesn't make sense to me - it seems like that would throw it into a loop - at the end of '*temperature = (*temperature * 9.0)/ 5.0 + 32;', it would have a new value for '*temperature', thus now it has something new to compute, which I would think would go over and over into infinity as a new value for '*temperature' keeps getting created.... Or am I missing something?

Any thoughts on what I'd need to do here?

*temperature = (*temperature * 9.0)/ 5.0 + 32;

This is correct, and it is not a loop. The right side is evaluated, and the result stored where the left side is pointing. It has the effect that a number somewhere in memory is changed from degrees C to degrees F.

If this potentially confusing construction is inside a function, it is probably being used to return a value to the calling program.

If you are not using the OneWire and DallasTmeperature libraries, you are making life difficult for yourself.

I cannot figure out for the life of me exactly how it comes to the Celsius value that it displays on a LCD and transmits over a NRF24L01 transciever, or how I could get it to return Fahrenheit.

With the DallasTemperatue library, there are explicit sensors.getTempF and sensors.getTempC functions.

The code is using OneWire, but I'm not sure where the DS1820 library is from. I could potentially try changing the library that's being used for the sensor, but I don't know if that'll make the entire thing blow up... It seems virtually all of the libraries I'm finding are intended for the Arduino IDE, and seem 'simpler', or at least a slightly different format, than the ones in use in this project in Atmel Studio.

If you are using Atmel Studio, many of the Arduino libraries won't work as they make calls to Arduino-specific functions. What is your development system?

jremington: If you are using Atmel Studio, many of the Arduino libraries won't work as they make calls to Arduino-specific functions. What is your development system?

That's pretty much what I figured, which is part of the challenge here. Just about everything I've found seems to be geared for the Arduino IDE. This project was written in AVR Studio/Atmel Studio. I'm using Atmel Studio 6.2 for it.

Does anyone have any other thoughts?