Read DS18B20 with AVR (ATtiny261)

Go To Last Post
69 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cris, with this stuff, you need to get a lot of little things correct otherwise it wont work. Therefore you need a bit of persistence to work through all the little things to get a good result. Because someone has said onr wire is difficult - does that mean you give up at the slightest problem? Realistically, one wire is relatively simple - if you can't get it working, then most other things are going to cause you problems. The fact that you weren't even getting past the reset stage suggests you have some fundamental problems. And you haven't even got in deep to the one wire protocol. What happens if you hit problems with the MAX6675 stuff? This is why we suggested the Arduino - you have worked examples to give you a kickstart.

Let's have a look at the code you posted:

void getTempCandF(void){

    ConvertTemp(0x02);
    delnms(500);
    dstenthdegc=GetTemp(0x02);
    delnms(50); 
	dstenthdegf=((dstenthdegc*9)/5)+320;
}

You've hardcoded the mask value to 0x02 so ONEWIRE does not play a part - I pointed this out previously.

We know you don't get past the one wire reset, so lets look here:

unsigned char OneWireReset(unsigned char mask){

  ONEPORT &= ~(mask);             // Normal input no pull up
  if (!(ONEPIN & mask)) return 0; // detect 0V on buss error
  ONEDDR |= mask;                 // out at 0
  Delay_500us();
  ONEDDR &= ~(mask);              // Set to input
  Delay_70us();
  if ((ONEPIN & mask) == 0){
    Delay_500us();
    return(1);
  }
  Delay_500us();
  return(0);
}

The first thing it does is clears the port bit then checks the port state for zero - of course it fails every time. Why?

void port_init(void){
//tiny 261

  PORTA = 0x00;
  DDRA  = 0xff;

  PORTB = 0x00;
  DDRB  = 0xfe;
}

PortB.1 is set for output. DDRB should be set for 0xfc to make portb.1 an input to start with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman, I understand your comment and agree (in general) with what you say. I am weighing the cost/benefit for my specific needs and my abilities. I don't have the fluency in C to be able to debug the program without spending a lot of time learning it. There are things going on in the program that I know I will learn very slowly. I do know that I can get there, it's just a matter of when. Add to that, I don't really know what the heck the one-wire is really trying to do. Plus I would need a logic analyzer for many problems that may come up. My lousy scope won't do the job for a lot of the potential timing issues.

On the other hand, I have a handle on the SPI of the MAX6675. Having a clock pulse makes it a lot easier to work with.

I also want to stay within my capabilities as much as possible. I don't have a problem adding some hardware (or hardwiring LED segments) to make the programming simpler. Basically, you have a lot more tools available to yourself than I have - merely because I am so limited with C. I am less concerned about design elegance and more concerned with solving the problem.

I got to a place with the DS18B20 that I had no idea how to proceed. I didn't understand much of the code, and I couldn't find explanations or answers. I was stuck. Going with the MAX6675 and thermocouples is an option that looks "cheapest". And I need to solve the MAX6675 anyway. If I didn't have this option, I'd still be working on the DS18B20. ...Path of least resistance....

Cris

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But one must get the DDR correct for the pin and port used for the IO regardless of c, pascal, basic, fortran, ada, and maybe python, of which I Know Nothing like Sargent Shultze. Kartman says change one bit in the program and it might magically start working. In other words, perfect translation of this c program to basic will have the exact same init problem. I chose bit 0 originally, and looks like the bloke from Down Under has spotted my stoopid mistake. Sorry for the cornfusion.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cris, you might want to try the one wire thing again just to give Bob and I some satisfaction. I dare say you'll derive some satisfaction as well. The problem was fairly easy to solve - look at the evidence. It was assumed on my part that Bob provided a working piece of code. So what was changed? The port bit. The code was cleverly crafted to give us an error code that was traced back the the reset function. The first line tells us it expected to enable the pullup which implies the port bit is an input. Look at the init code... voila! No need for advanced debugging tools apart from the God given one. Most problems can be solved this way.

Ahhhhh! The old port direction not set correctly trick -- third time I've fallen for it this week! Hogan!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
But one must get the DDR correct for the pin and port used for the IO regardless
Kartman wrote:
Cris, you might want to try the one wire thing again just to give Bob and I some satisfaction.
Bob & Hogan, I apologize!

I wrote my last post without noticing the coding suggestion provided. Another example of me not paying attention.... :oops:

So Bob, if I were you and I read the above, it would kinda piss me off.... That's why I am apologizing to you. You have done so much work to help me get this going, I owe it to you to at least give the suggestion a try. And I would have if I had paid attention.

Hogan, I apologize to you because from your point of view, it probably looks like I'm actively ignoring you.

Well, I FINALLY noticed your coding suggestions and tried it.

Sorry, no joy.... :cry:

But now there is pulsing on the I/O pin. :)
And instead of temp of 9999 it is stuck at 127.9 C and correctly calculates 262.2 F. But there is no change with heat or cold.

Cris

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is more or less how all my debug sessions progress. First nothing, then garbage, then smething. There is probably one more small snafu in there. The yanks and the aussies have had their whack at it. Get old Cliff to give it a try.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hogan was is response to Bob's reference to Hogan's heroes. I'm probably more Colonel Klink than Hogan.

Sounds like we've made some progess. The temperature result is telling us something - exactly what i don't know. I'm suspicious of the delays. How can we confirm these are correct?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Hogan was is response to Bob's reference to Hogan's heroes. I'm probably more Colonel Klink than Hogan.
:oops: ... sorry I missed that. Thanks for the clarification.... :oops:
Kartman wrote:
I'm suspicious of the delays. How can we confirm these are correct?
I have the same question. The scope I have is no good for this because the rep rate is 1/2 second and the signal is so short in comparison.

Cris

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cris, you probably have a better 'scope right at your fingertips - your PC. The soundcard is quite handy for measuring low frequency signals. There's few free soundcard 'scope apps kicking around the interwebs. Write some test code to toggle a port pin and call the various delay functions a few times to get a low enough frequency to adequately measure. That should give a reasonable answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
So next time you're waiting in line at McDonalds, decode the customers by fat and skinny. That's one wire protocol.

Not the best example. 0x00 isn't a valid command, according to the data sheet ;)

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
The soundcard is quite handy for measuring low frequency signals.
This is COOL! I'm working on getting one set up. :wink:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Cris, you probably have a better 'scope right at your fingertips - your PC.
I downloaded a free sound card 'scope called Visual Analyser and I rigged up a scope probe to my sound card.
Kartman wrote:
Write some test code to toggle a port pin and call the various delay functions a few times to get a low enough frequency to adequately measure. That should give a reasonable answer.
I made a test program to output low, delay 70us seven times, output high, delay 500us one time, repeat....
This is the result. It's a little short but not by much. I tweaked the wait loops slightly and tried the DS18B20 again.

Still no joy. :? But we can check another item off the list....

Attachment(s): 

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the readtemp function, I'd be looking at the values that get loaded into lsb and msb. There might be some clues there. Also try scoping the one wire data to see if any useful info can be extracted.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have two other circuits that use the DS18B20. One is a kit I bought several years ago with an ATtiny2313, the other is a board I put together using a PIC16F628 that someone else wrote the code for (I bought them pre-programmed).

Since I am poking around this board with a scope probe, I thought it would be interesting to see what it would look like if I probed a DS18B20 that was working properly. In doing so, I discovered the DS18B20 I'm using is faulty (although I had tested it previously with good results :? ).

Anyway, after installing a good DS18B20...

:shock: :lol: :wink: IT WORKS!!! :wink: :lol: :shock:

I suspect the issue was the DDR not being set properly. I haven't done anything else except tweak the delays and poke around with a scope probe.

A BIG Thanks goes to Bob and Kartman! Thanks to both of you for refusing to let me quit (and also for your patience in ignoring my tantrums).

You both taught me a big lesson:

TRUST THE AVR FREAKS! And also... be patient.

Your commitment to having me stick to this has paid off. I also got a new tool... a soundcard oscilloscope (and it is free).

Cris

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We all enjoy a happy ending!

The DDR was the root cause, but this wouldn't have killed the DS18B20 methinks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
The DDR was the root cause, but this wouldn't have killed the DS18B20 methinks.
I did not intend to imply that the DS15B20 failure was due to software. It was more likely my installing it backwards or something. I had to unplug it everytime I uploaded a program to the ATtiny. So I probably wasn't paying attention... AGAIN! :oops:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try the max6675 code now?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Try the max6675 code now?
Yep, it's the next thing on the list.... I have the MAX6675 but I can't find my thermocouple, so I have one on order - it should be here by Monday. :wink:

I did some tweaks to the DS18B20 program so it polls the C/F switch during the wait loop. So it changes the display between C and F immediately, rather than taking as long as a half second to respond. So that piece of software is now finished! (well... as much as software is EVER finished)

Cris

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

Pages