free75degrees - 12 May 2008 10:39 PM

OK, the ds18s20 sensors are finally working with my ts7800 controller board!  They are telling me it is 68*F in here.  I can’t wait to get that boiler hooked up so that I can crank it to 75!  As a confirmation, I can hold one between my fingers and the temp goes to 77.

Congratulations on your success!  I am interested on how you accomplished the required signaling between the ts7800 and the ds18s20. Sure would like to see the code on this!

Don

When I get home tonight I’ll clean up the code a bit, add some comments, then post it.  Where should I post it?  I’d rather not post it in this thread where it will get lost.  Maybe i’ll start a wiki page.

free75degrees - 13 May 2008 10:08 AM

When I get home tonight I’ll clean up the code a bit, add some comments, then post it.  Where should I post it?  I’d rather not post it in this thread where it will get lost.  Maybe i’ll start a wiki page.

If you have somewhere permanent, put it there and post a link to it. If it helps, I’ll be glad to host it on the nofossil site - a variant is going to end up there anyway (properly attributed, of course).

Ok, I have posted the code to a wiki page I just made:
http://www.hearth.com/econtent/index.php/wiki/free75degrees_gasification_project/

This is just a test program to make sure everything works.  I am thinking about learning how to write a linux kernel driver based on this.  A friend tells me that if I write a kernel driver I can make it so that each device looks like a file where you can just read the contents to get the temperature.  Sounds pretty slick so I might have to try it out…

Interesting. I’m concerned about tying up the kernel with all the little waits that you need, though. More stuff to experiment with.

I just added the following code to set the process to use FIFO scheduling policy.  I have never used this before, but from what I have read this should prevent the process from getting preempted.

const struct sched_param *param;
sched_setscheduler(0, SCHED_FIFO, param);

That should do it as long as this task doen’t take too much time and thereby defer all the following tasks. I need to figure out two things:

1) How much time this task would take to read all the sensors at a reasonable frequency (all sensors every 20 seconds would be good for me)

2) How much time all the other tasks are consuming

There must be some profiling tools that could get me some of that data. In my case, I have several tasks that run at different frequencies:

- data collection and simple logic - every second
- data logging - every 30 seconds
- control logic - every 35 seconds

It’s pretty important that these don’t get preempted. I’ll have to study the 1wire spec and see how much time it takes to read a couple dozen sensors. Maybe I could read them in small groups, a few every second in round-robin fashion.

My code may not be totally efficient on time - I was more concerned with making it work and tried to set the timings to the center of the spec timings so it might be possible to squeeze some more time out.  There are also some other efficiencies to be had.  For example, the convert T command can be sent to all devices at once.  By far the longest part of getting a temperature is the delay that the sensor needs to convert the temperature to a digital value and store it in its on board register.  This takes on the order of 1/2s.  Not doing them together would probably take a huge chunk of your 20 s interval.

Another possibility is to put each device on a separate I/O.  This way you wouldn’t have to send the ROM code to get the temperatures.  The ROM codes are 64 bits, so this would cut the time significantly.

free75degrees - 14 May 2008 08:09 AM

My code may not be totally efficient on time - I was more concerned with making it work and tried to set the timings to the center of the spec timings so it might be possible to squeeze some more time out.  There are also some other efficiencies to be had.  For example, the convert T command can be sent to all devices at once.  By far the longest part of getting a temperature is the delay that the sensor needs to convert the temperature to a digital value and store it in its on board register.  This takes on the order of 1/2s.  Not doing them together would probably take a huge chunk of your 20 s interval.

Another possibility is to put each device on a separate I/O.  This way you wouldn’t have to send the ROM code to get the temperatures.  The ROM codes are 64 bits, so this would cut the time significantly.

Thanks for your work on this, though it means I can’t slack off too much longer.