Need help in interfacing of DS 1820 with 8051

The datasheet for the DS1820 tells what interface it has. It will tell what size of pull-up you need and the timing for the protocol.

The datasheet for your display will give the needed information how it should interface to the processor.

Google will find you sample code for the Dallas one-wire interface. Most probably, you will be able to find sample code for your display too.

Integrate and add a bit of glue code in between, that picks up the temperature values and formats them into a string and displays that string.

How much have you done already?

You don't even need google: just go straight to the Manufacturer's website - where you got the datasheet - and the code is right there, under your very nose, ready to use!

The manufacturers code may be a good starting point.

But Google may be able to help with a link that has code ported for the relevant processor - including timer initializations etc.

Do they teach people how to read data sheets in school anymore?

ND

The manufacturers code may be a good starting point.
not as good as the datasheet, I have seen much 'untested' "manufacturers code"

But Google may be able to help with a link that has code ported for the relevant processor .... and is probably faulty.
THEN we are AGAIN where someone who does not have the foggiest idea about what the code does can not find out what is wrong.

I STRONGLY TOTALLY ABSOLUTELY advocate against using "sample code" till you (have the ability to) code it yourself. Then, if you have a problem, you can understand the "sample code" and there may be a hint as to what you, yourself, missed.

Erik

In this particular case, the manufacturer (Maxim) is not just providing "sample" code - but gives you a complete protocol implementation (apart from the target-specific timer).

Yes, of course, you do have to spend some time reading the documentation - including the Datasheets - but it does work pretty much out-of-the-box

Do they teach people how to do basic research anymore?

Do they teach people anymore?

I think there's some teaching going on but, apparently, not much learning...

:-(

what are you all complaining about, he?! this time you were not requested to deliver detailed schematics...
:-) :-) :-)

"not as good as the datasheet, I have seen much 'untested' 'manufacturers code'"

The manufacturers "official" code is probably written by some application engineer somewhere. Possibly quite bright, and possibly quite good with the hardware. But very seldom a good programmer.

Much of the "official" manfuacturers code is way worse than the code you can pick up using Google. I prefer to look at popular code before looking at "official" code.

I might do a quick scan through the code just to see if it shows any signs of big surprises - things I failed to pick up from the datasheet. But I'm normally extremely sceptical to using manufacturers code in release projects.

Coding from a datasheet means that I know the reason for every single source line. A lot of manufacturers code has strange lines that can't really be explained. Possibly left-overs from ports from other chip variants. Possibly left-overs from trying to get the code to work. Possibly absolutely vital lines. But I have no way of knowing.

If I code from the datasheet and it works, then there is a reasonable chance that I did a good job. If I find that the datasheet does not have enough information for me to implement the function, then it is time to rethink the chip choice.

In the end, downloading code is a question of trust. And a question of looking at the code and make educated assessments. And to check feedback and other relevant information. And the knowledge that I can understand and maintain the code take care of any problems. But I have had way better experience with non-official code than I have had with manufacturer-supplied releases. I'm not talking about Maxim (Dallas) now but in the general case.

Keil, ST and others provide their own flavor of firmware USB support for various chips. Now that is a big piece of software, quite heavy too (in terms of runtime cost, ROM etc.). Personally I prefer ST's implementation over Keil's, but since most people don't know all the details about the exact functioning of the USB protocol (indeed, a complex machine), they tend to trust anything that seems to work. At the same time, there are a couple of open source (hence: written by hobbyists) implementations out there, and I have to say - they don't look bad at all (but I haven't tried them yet).

Open source != written by hobbyists.

Some open source projects are hosted and run by commercial companies, or derived from commercial projects to promote a technology (or sneak away from the support costs).

A lot of open sources are written by professionals who also happens to burn for a course or feels that a cancelled project should not have to die in a quick "rm -rf".

And some open sources are written by (often very gifted) amateurs.

And then we have the students who feels that their hard efforts are true master pieces to be saved for the following generations to admire. If the download links are flashing and twirling, it may be a sign that the bandwidth should be saved for another download, another day :)

You're absolutely right, of course...I guess I was projecting my personal condition: My day job is embedded-related, but I am also a hobbyists at the same time...

Some open source projects are hosted and run by commercial companies, or derived from commercial projects to promote a technology (or sneak away from the support costs).
I know of many such cases for the PC (and a few other thingies) but NONE for the '51 (or for that matter, any small embedded)

Erik