Uilter Witte

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

8 years, 9 months ago.

Compatibility with others Platforms - DS1820

Hello,

I'm testing this hello_world example of DS1820 with 3 Platforms: - Nucleo-F411RE, from ST; - Nucleo-L152RE, from ST; - FRDM-K64F, from Frescale; - EFM32 USB-enabled Happy Gecko, from Silicon Labs; - EFM32 Zero Gecko, from Silicon Labs; - EFM32 Wonder Gecko, from Silicon Labs;

Since I started test this sensor, I did not have any problem with Freescale or ST Platforms, but when I use Silicon Labs boards nothing works.

I debug the signal with a scope, and I noted that the timer of signal if very different.

Below is the wave form of ST or Freescale board /media/uploads/Uilter/f0003tek.bmp

Below is the wave form of SiliconLabs board. /media/uploads/Uilter/f0002tek.bmp

[update-1]

I wrote an simple program, to test the function "wait_us()", toggling a GPIO each 100us. I did that, because DS1820 lib use this functions to send each bit to the sensor. Again I used the scope to get the wave form.

This is wave form generate by ST or Frescale Platforms: /media/uploads/Uilter/f0008tek.bmp

This is the wave form of silicon labs platforms: /media/uploads/Uilter/f0005tek.bmp

Anyone have its problem with SiliconLabs Platforms?

Thank you!!

[update-2] - Difference between using WonderGecko and NUCLEO-F411RE with DS1820 lib The yellow wave is WonderGecko The blue wave is NUCLEO-F411RE /media/uploads/Uilter/printscope.bmp

Question relating to:

Last updated: 13 Jan 2017
DS1820 Hello World

Hi. Strange waveform for your toggling indeed. Is that the result on other GPIO pins as well ? Which GPIO pin was used for this waveform test on the EFM32 Wonder Gecko ? Perhaps that pin is in use by another component on the development board ? Also, for the DS1820, are you using a pull-up resistor ? On this note, are the EFM32 Wonder Gecko port pins 5 volt tolerant ? The DS1820 seems to hint you will be fine if using 3V3 for Vcc. Please consider to remove the DS1820 from the GPIO pin and then review the results of your toggle test and be sure it is matching the ST / Freescale board results before proceeding.

posted by Sanjiv Bhatia 30 Jan 2016

First of all: Good to check the wait_us one, and that already shows what I was guessing towards: Broken mbed implementation. Just to make sure, you are using the most recent mbed lib? (right mouse button, update, on the lib in your program). (For example on the NRF51822 I am pretty sure the lib won't work because of their timer implementation which does not give us resolution, but a quick check on the SiliconLabs code should give microsecond resolution. I'll see if I can check some stuff.

Edit: Initial tests: Just toggling a GPIO as fast as possible gives 3us delay. Toggling it with a wait_us(1) gives over 300us delay. (I am using a logic analyzer, so can't observe the waveforms, and I don't think I have a DS1820 left, so just focussing on toggling a bit now).

posted by Erik - 30 Jan 2016

Hello Erik and Sanjiv, thank for your reply!

Yes, it is the most recent mbed lib.

SiliconLabs - HappyGecko The first test was made in PE13, now I change for PB11. The time that I get is 300us.

SiliconLabs - WonderGecko - better than happyGecko I was tested in PD3 pin, the time that I get is 110us, this delay of 10us it's not good.

To connect the DS1820, I'm using a 4k7 pull-up resistor. I power the sensor with 3v3.

With and without the sensor the time is the same, don't match with wait_us() function.

Thanks!

posted by Uilter Witte 30 Jan 2016

Hi Erik Olieman, Thanks for your library. I have a problem with nRF51822 and DS18B20. I use DB1820_HelloWorld example but the results is not good. I only receive "No unassigned DS1820 found!" My example use Keil uVision 5, TARGET_NRF51822, Softdevice: S130 1.0.0

But when I use the follow example https://developer.mbed.org/users/gkroussos/code/BLE_Temperature/

With this example, the result is good. it use softdevice s110 6.0.0

I do not understand this problem and I hope that the example can work fine with softdevice s130.

Thank you very much

posted by VBLUno51 BLE 08 Apr 2017

1 Answer

Erik -
8 years, 9 months ago.

I looked what happened when I read us_ticker_read() as fast as possible (write to internal buffer, after that write to serial). That should give 0-1us steps per time, but it resulted in hunderds of microsecond steps.

So back to the source code: https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/hal/TARGET_Silicon_Labs/TARGET_EFM32/us_ticker.c

At least one problem is the us_ticker_read code at line 161: It does a 64-bit integer division. M0s do not have integer division support, and a quick check on my LPC11u24 results in that that divisions already takes 100+ us. (Where in my code it might have optimized some things). My Wonder Gecko has 5-6 us delay when reading us_ticker as fast as possible, and toggling a pin with 1us delay results in 13.5us delay.

In general you really should avoid integer divisions on an M0 in stuff which needs to happen fast. 64-bit integer divisions are even worse. So this rules out the Zero and Happy Geckos, they will never run the DS1820 code which relies on the mbed timer fnuctions. I guess for the Wonder Gecko it is just on the edge, and if it does not work for you, probably at the wrong side of the edge. The waveforms you posted are for the Zero/Happy Gecko? You can try seeing what it is like for the Wonder Gecko.

Accepted Answer

Erik,

This make sense, because Wonder board it's Cortex-M4 and have this features of division. But toggling a GPIO in 100 us in Wonder Board result in 110us. For DS1820 it's enough to don't work. I will edit my post and paste a Image of scope that you can see the difference. The image is above [update-2]

Thank you very much.

posted by Uilter Witte 30 Jan 2016

Indeed, Wonder Gecko is alot better than Zero Gecko, but just a bit too much delay. If you really want to make something with one of the Gecko's there are alternatives you can use, but in general my opinion about stuff like this is that I won't change the library because specific hardware has bad mbed implementation.

posted by Erik - 30 Jan 2016

I agree with you Erik, the problem was not in your lib, is the mbed API. If all libs has to be implement with particulars hardware, the mbed platform will lose the purpose. I saw another issue with compatibility, but I think is going improve in future. Thank you very much!

posted by Uilter Witte 30 Jan 2016