LPCXpresso IDE中的主题 OneWire bus master implementation

OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:41:53 GMT

Content originally posted in LPCWare by jharwood on Wed Jan 19 19:30:53 MST 2011
An application that I have in mind for the LPC1343 involves a few DS18S20 temperature sensors. A quick search for a OneWire bus master solution on LPC didn't return anything much, so I set about making one.

If anyone is interested, the attached zip file contains a couple of source files that can be added to a project that needs OneWire bus master functionality. Feedback of any kind would be most welcome.

Edit: A new improved version is now attached to post # 7 below.

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:41:54 GMT

Content originally posted in LPCWare by Ex-Zero on Wed Jan 19 22:04:04 MST 2011
If you are looking for faster and more accurate temperature sensors for battery powered applications, try TSiC306 from ZMD.

http://www.datasheetarchive.com/TSIC-306*-datasheet.html

Accuracy: +- 0.3°C
Signal read-out every 0.1s
Communication range > 10 meters

I've used it for a battery (coin cell) long-time temperature logger and was very impressed.

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:41:55 GMT

Content originally posted in LPCWare by jharwood on Thu Jan 20 18:55:09 MST 2011
Thanks Zero.

As it happens, the DS18S20s have been part of the infrastructure for a number of years (buried in epoxy). I just want to upgrade the micro controller to LPC.

There are also some 1-wire I/O expanders currently in operation, but I may ditch those and use GPIO.

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:41:56 GMT

Content originally posted in LPCWare by Ex-Zero on Fri Jan 21 12:03:10 MST 2011
...infrastructure...

...sounds interesting, perhaps you could help me to understand some hardware issues about DS18S20:

- is this “parasite power” mode a reliable solution with a longer cable length (>10m)?

- are cable lengths >20m possible with >10 DS18S20 (with reversed Schottky diode at the end)?

Perhaps you are familiar with this problems and could share your experience.

Thanks, Zero

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:41:56 GMT

Content originally posted in LPCWare by jharwood on Fri Jan 21 13:16:50 MST 2011
Hi Zero,
I believe the answers to both your questions are 'yes'. But you should check out:
http://pdfserv.maxim-ic.com/en/an/AN148.pdf Guidelines for Reliable Long Line 1-WireÂ® Networks

Note that the DS18B20 can also be parasitically powered and has configurable resolution.

My experience is only with a simple home project. It has about 25m of cat-5 cable ending up with a sensor on the roof. There are several short stubs for other devices along the way. The bus master driver is actually a DS2480B which is included on the original mcu board. My plan is to ditch the old mcu board and use a custom board with an LPC (most likely a 1768).

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:41:57 GMT

Content originally posted in LPCWare by Ex-Zero on Fri Jan 21 15:01:08 MST 2011
Hi James,
I've read several PDF's from Dallas/Maxim before, but I'm always a little bit suspicious. :)
So I'm grateful to hear about projects with long cable length.
Sooner or later I've to replace an old system (AT90CAN64 & DS1621) with LPC11C14 & LPC1768. Just ordered a few DS18S20's and so I can give your sample a try next week.

Thanks, Zero

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:41:58 GMT

Content originally posted in LPCWare by jharwood on Sat Jan 29 21:44:49 MST 2011
In my earlier version, I was bothered by having so many long-term blocking calls just to read one sensor.

So here is an improved version that uses a Protothread to allow the main app to keep on running freely with any number of sensors.

Please see the example-main.c in the attached zip file to get an idea of how to use it.

I am grateful to Adam Dunkels for providing the wonderfully elegant Protothread solution :)

[ATTACH]287[/ATTACH]

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:41:58 GMT

Content originally posted in LPCWare by Ex-Zero on Sun Jan 30 19:30:39 MST 2011
Just trying to get my brand-new DS18S20 running with your first onewire example.
Worked without problems (non-parasitic) after reading it's serial code and changing port pin. :):)

After changing to parasitic temp reading showed always 85 = default value. So reducing pull-up from 4.7k (at 3.3V) to 1k obviously solved the power problem of DS18S20.

Can you recommend a pull-up value (2-3 DS18S20, 5m wire) or do you recommend non-parasitic mode?

TIA,
Zero

Edit #1: 2x DS18S20 in parasitic mode (one of them at 50m LIYCY cable) are working also without problems with 1k pull-up.

Edit #2: 3x DS18S20 in parasitic mode (2 of them at 50m LIYCY cable) are working with improved version. Nice piece of work and easy to use, congratulation.

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:41:59 GMT

Content originally posted in LPCWare by jharwood on Mon Jan 31 10:05:23 MST 2011
Hi Zero,

That's great! I'm glad you got it working, and thanks for the compliments :)

I would definitely recommend a 1k pull up for most cases using parasitic power. Given the high quality of the cable you are using, you shouldn't have any problems. If you do see any problems, then adding an active strong pull up driven by an extra port pin would be the solution.

The choice of parasitic vs external power I think comes down to complexity. If you have the power available, and the extra conductor in the cable, then you can avoid any problems caused by parasitic power.

I bought 10 of the DS18S20-PAR sensors several years ago, so I'm kind of stuck with parasitic power for now :)

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:41:59 GMT

Content originally posted in LPCWare by mattes on Wed Feb 02 16:43:05 MST 2011
James,

could your code be used for the DS18B20 as well?

I ran it with a DS18B20 (external power mode),
but it never returns from inside ow_srch_first()
---------
#Addon
Did some more diggin'. It actually never comes back from the first call of
ow->find_devices() -> ow_srch_first() -> ow_srch_next() -> ow_write(SEARCHROM)

It hangs in the while loop (ow_write) waiting for 'WR_COMPLETE'.

I see the TIMER16_0_IRQHandler continously called but it never does anything.
LPC_TMR->IR is allways zero.

I am using a LPC1114. Is the timer interrupt handling compatible to the LPC1343?

mat

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:42:00 GMT

Content originally posted in LPCWare by jharwood on Thu Feb 03 15:21:57 MST 2011
Hi Mat,
I'm afraid that don't actually have any DS18B20s, nor an LPC1114 to test with :o

But looking at the data sheets, it [I]_should_[/I] work.

Try hooking up just one device to your selected port pin. Add a strongish pull up resistor to the pin, a 1k or 2k2 would be good.

Then try calling ow_reset() and check the presence flag. If that works, try calling the ow_read_rom() function and check that you get a sensible value.

Which version of the code are you using? I didn't actually test the search_rom functionality of the 'new improved' version :o .

Thanks for trying the code, I am interested to hear the results.

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:42:00 GMT

Content originally posted in LPCWare by mattes on Fri Feb 04 02:24:33 MST 2011
James,
I only have one DS18B20 connected. Everything is setup on a breadboard. I am using your first version published.

ow_reset() detects a sensor (presence=1). The next call made is ow_write( CMD_ROM, 1) which never returns.
It turns out that Timer16_0_IRQHandler is called over and over again. LPC_TMR->IR=0x07 (typically or 0x01). I added this case 0x07 to the case WRITE: for a quick test.
case 0x07:
    LPC_TMR->IR = 0x07;
    LPC_TMR->TCR = 0x02;
    ow_state = WR_COMPLETE;
    break;

Now at least it returns ow_write() returns.

looks like the WRITE cases 0x02 and 0x04 are never reached!

Could be a timing thing?
Is the LPC1114 too slow?,
no able to handle 2us interrupts ;-((
Timer set up properly. TIM->PR = 0x18

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:42:01 GMT

Content originally posted in LPCWare by jharwood on Fri Feb 04 12:42:55 MST 2011
Mat,

Hmm, that's odd. For the write bit case to end up with all three interrupt flags set at the same time, something must have held up the timer ISR for more than 60uS. I will certainly have to look into modifying the code so that it handles it more gracefully and reports an error.

What other things do you have going on in your application? Any longish periods with interrupts disabled? Or other ISRs that take a lengthy time to complete?

Are you sending messages to the debugging console via semi-hosting? This is something I have never done. It may be causing the system to run too slow, just a wild guess.

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:42:02 GMT

Content originally posted in LPCWare by Ex-Zero on Fri Feb 04 13:04:32 MST 2011

Quote: jharwood
Are you sending messages to the debugging console via semi-hosting? This is something I have never done. It may be causing the system to run too slow, just a wild guess.

Right, semi-hosting wasn't working for me with your example. Changing to real UART is working without problems (DS18S20).

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:42:02 GMT

Content originally posted in LPCWare by jharwood on Fri Feb 04 13:17:42 MST 2011

Quote: Zero
Right, semi-hosting wasn't working for me with your example. Changing to real UART is working without problems (DS18S20).

Thanks for confirming that Zero :)

I was using the USB CDC example and a virtual com port for my tests.

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:42:03 GMT

Content originally posted in LPCWare by mattes on Fri Feb 04 15:40:50 MST 2011

Quote: Zero
Right, semi-hosting wasn't working for me with your example. Changing to real UART is working without problems (DS18S20).

yes, semi-hosting is enable on my system too! I will try later and switch semi-hosting off. thanx for the hint.

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:42:03 GMT

Content originally posted in LPCWare by mattes on Sat Feb 05 13:59:36 MST 2011
disabled semihosting, but no change in behaviour.
I then switched to a different port (p2.6). Beware lpc1114 owners, port 2.4 and P2.5 has a R33 resistor inline.
Though that does not affect the timing of ow_write().

I finally removed the DS18B20 completely and still the same problem!
Just bit banging the port via the timer with MR0,1,2
already presents the problem:

Receiving the first interruptLPC_TMR->IR=0x01 (initiated by MR0) and then followed by next interupt where LPC_TMR->IR=0x07 (where 0x02 is expected)

Interestingly ow_reset() never presented that problem.

I then started playing with the timing parameter of ow_write(). Changing the last timing value made the difference:
LPC_TMR->MR2 = 64; (instead of 62)

Is seems the difference between MR1 and MR2 needs to be greater than 2 (=2 microsec).

Now all 3 interrupts are triggered as programmed, when
writing a single bit.

I can only guess at this point, maybe the Cortex M0 is not as quick as the M3 (1743)? Or this there still something else going?

But for now I can at least exercise ow_read_rom() and get some readings from the DS18B20.

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:42:04 GMT

Content originally posted in LPCWare by jharwood on Sat Feb 05 18:02:56 MST 2011
I'm glad that you were able to get it working. I guess the timing is just a little too tight while running on a 48Mhz machine, your findings certainly seem to indicate that. And I'm sure that turning on some compiler optimization would help.

Another idea just materialized: the ISR is repeatedly grabbing the current value of LPC_TMR->IR, so as it works its way through the switch statement the value could change on the fly. It would be better to make a local copy of the IR register at the top of the ISR and use that for the switch statements.

Thanks very much for your feedback.

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:42:05 GMT

Content originally posted in LPCWare by mattes on Sat Feb 05 22:44:30 MST 2011
For test I reduced the amount of code in the IRQ func. But it did not make any difference in the behaviour. No matter how little code it was. It is not much going to begin with
except maybe case 0x04.

Changing the timing difference of between MR1 and MR2 finally made a difference.

Interestingly case 0x01 allways occurs on the first interrupt from ow_write(). And than something breaks.

According to the data sheet of the DS18x20, Treq (= MR2-MR1) is only specs by a min. of 1microsec. So it should not hurt at all to make it 10microsec or so (instead of just 2)

Re: OneWire bus master implementation

lpcware — Thu, 16 Jun 2016 00:42:06 GMT

Content originally posted in LPCWare by mattes on Tue Feb 08 22:13:12 MST 2011
James,

I made a couple of changes to address the issues I was having with the LPC1114:
- extended all LPC_TMP->MR2 timing to avoid hang in Timer_IRQHandler()
- changed timing for ow_reset() to 550 ms. once in a while ow_reset() did not find the sensor signal. The previous timing was too short (too close to the spec'ed minimum in the data sheet 480ms)
- the improved timing seems to be more robust. Now the code runs even in debug mode with semi hosting enabled.

Attached 'onewire.c' is modded by me (based on your first version)