Hi there, I have a development board around the aduc832BS processor and use Keil uVision2 ver2.40 for software development. I tried to implement the 1wire routines for DS18B20 (which i conected at P3.4) but it seems that i have a timing problem.it all starts from the delay function.I use PLLCON=0x051(fcore=8.388608mhz) below is an example of timing delay for DS5000 (8051 compatible) microcontroller with an 11.059MHz clock. //Calling the routine takes about 24us,and //then each count takes another 16us. void delay(int useconds) { int s; for (s=0; s<useconds;s++); } I also know that ADuC832 Machine Cycle Time is nominally 12/Core_CLK. Could you tell me please how can i calculate the timings for the DELAY() (the Machine Cycles required for them) based on the aduc832. (ex. calling time for the delay() routine,calling time for each count in this routine). For the DS5000 the reset routine is: (Reset is 480us, so delay value is (480-24)/16 = 28.5 - we use 29.Presence checked another 70us later, so delay is (70-24)/16 = 2.875 - we use 3). unsigned char ow_reset(void) { unsigned char presence; DQ = 0; //pull DQ line low delay(29); // leave it low for 480us DQ = 1; // allow line to return high delay(3); // wait for presence presence = DQ; // get presence signal delay(25); // wait for end of timeslot return(presence); // presence signal returned } // 0=presence, 1 = no part Thank you in advance for helping me out.
've seen your point regarding the keil c++ delay routines. What i can't understand is why Maxim dallas has presented the routines for ds1820 written in C. here it is: http://pdfserv.maxim-ic.com/en/an/app162.pdf After all the Ds500 is pretty much the same as the ADUC832 proc(same 8051 architecture,16mhz clock). Here i found the aduc832 instruction set+osc periods: http://www.analog.com/UploadedFiles/REDESIGN_Quick_Reference_Guides/1015540832qref0.pdf I wonder,is really impossible to estimate the calling time for this delay() and for each count?How did the maxim_team manage to estimate for the ds5000 ? void delay(int useconds)//24us for calling { int s; for (s=0; s<useconds;s++);//16 for each count } Regards, Robert
"What i can't understand is why Maxim dallas has presented the routines for ds1820 written in C. here it is: http://pdfserv.maxim-ic.com/en/an/app162.pdf " You're right - it is very naughty of them to present that code like that! They haven't specified which Memory Model to use - and that will significantly affect the timings!! Also, they haven't specified a compiler nor version; as mentioned above, there is absolutely no guarantee whatsoever that different compilers - or even different versions of the same compiler - won't generate different code for this function. Thus, they are wrong to state specific timings without giving these necessary details! Aside from the above, the function is also misleading in naming its input parameter "useconds" as this kind of implies that a value of, say, 23 will give a delay of 23us - when clearly it doesn't(as their own examples show!!)
Wow! a datasheet or app note with an error in it. I'm stunned. ( After picking myself up off the ground and recovering my composure) Virtually every IC datasheet out there has some error or omission of pertinent information. The apps people probably wrote some code then used their scope to measure the delay and declared victory. The first question that comes to my mind is how much accuracy is really required by the peripheral? If those numbers are minimums can you get away with delay which is loosely controlled and therefore excessive but nevertheless adequate?
"The first question that comes to my mind is how much accuracy is really required by the peripheral?" The timing limits are described in the 1-Wire specs, and in the datasheet for each 1-Wire device. I haven't tried it, but I stronlgy suspect that switching from the Small to Large memory model (or vice-versa) would be enough to break the timings if the 'C' code from the app note were relied upon...