PaulStoffregen / OneWire

Library for Dallas/Maxim 1-Wire Chips
http://www.pjrc.com/teensy/td_libs_OneWire.html
579 stars 382 forks source link

Support for RedBearLab nRF51822 #3

Open almsta opened 8 years ago

almsta commented 8 years ago

Hello!

I'm using the RedBearLab nRF51822 (http://redbearlab.com/redbearlab-nrf51822/) board and want to use the DS1820 sensor.

It seems that this board is currently not supported. Is it possible to support this board? Thanks in advance!

PaulStoffregen commented 8 years ago

Well, it all depends on what you mean by "possible".

It's almost certainly possible for someone familiar with this RedBearLab product to add the necessary pin control stuff near the top of OneWire.h. If they do so (with #ifdef changes only in the intended location), and submit a pull request, I'll almost certainly merge it to this official OneWire repository.

However, if the word "possible" includes a notion that I would personally do this work, on an unpaid volunteer basis, on a RedBearLab product which I do not support, nor do I even have have in my collection of hardware.... well, that's much less "possible".

almsta commented 8 years ago

With "possible" I mean technically possible :)

I already asked in the official forum for help, but sadly no one has replied. Maybe it is possible for me to add the support.

Is there a more detailed documentation about the pin control stuff (which one do I need and what for)?

PaulStoffregen commented 8 years ago

The comments and existing defs at the top of OneWire.h are the only documentation.

almsta commented 8 years ago

Ok, thank you! Since I'm pretty new to that stuff is hard for me to figure out what to do.

I try to get in touch with the RedBearLab guys - hopefully they can help me.

almsta commented 8 years ago

With the help of the Nordic Developer Zone I came up with the following version (see original question here):

#elif defined(RBL_NRF51822)

#define PIN_TO_BASEREG(pin)             (0)
#define PIN_TO_BITMASK(pin)             (pin)
#define IO_REG_TYPE uint32_t
#define IO_REG_ASM
#define DIRECT_READ(base, pin)          nrf_gpio_pin_read(pin)
#define DIRECT_WRITE_LOW(base, pin)     nrf_gpio_pin_clear(pin)
#define DIRECT_WRITE_HIGH(base, pin)    nrf_gpio_pin_set(pin)
#define DIRECT_MODE_INPUT(base, pin)    nrf_gpio_cfg_input(pin, NRF_GPIO_PIN_NOPULL)
#define DIRECT_MODE_OUTPUT(base, pin)   nrf_gpio_cfg_output(pin)

Documentation available here

If I'm starting the "DS18x20_Temperature" example, no addresses can be found. Still not clear if this is correct especially with this:

#define PIN_TO_BASEREG(pin)             (0)
#define PIN_TO_BITMASK(pin)             (pin)
#define IO_REG_TYPE uint32_t
#define IO_REG_ASM

I'm using a DS18S20+? Maybe it has to do with that? Could you explain what PIN_TO_BASEREG, PIN_TO_BITMASK are used for? Currently I used it the same as for the fallback mode. Thank you!

PaulStoffregen commented 8 years ago

PIN_TO_BASEREG and PIN_TO_BITMASK provide an opportunity to translate Arduino pin numbers to something else. See the defs for all the other boards for examples.

If your functions take a pin number, then you can choose to define these as macros that merely pass the pin number. Or you can write them to translate in any way you want (within the C preprocessor's capabilities, of course).

Let me know when/if it's confirmed working? I'd prefer to wait on merging this to the OneWire code until it's been confirmed working on at least one board.

If you have any questions about what it should do when working properly, simply run it on any of the supported boards. Arduino and the others are very affordable and readily available, so use those for testing if necessary.

PaulStoffregen commented 8 years ago

I've merged this, even though it's unconfirmed. At least it won't mess up any other chips.

https://github.com/PaulStoffregen/OneWire/commit/ef5e5c64cbfd445cff18f1dd1e97ed9b2759c68d

If it needs more work, feel free to reopen this issue... of even better, submit a pull request with whatever fix is needed.

mrvanes commented 7 years ago

I'd like to pick where this was left. I have a BLE Nano (the little brother of the RBL_NRF51822) and can't get OneWire to work with my DS18B20. I connect Vdd to the 3.3Vdd of the Nano and have 4k7 pullup on DQ. I've connected DQ to pin 7, but get no results using the DallasTemperature lib. I've added BLE_NANO to the macro definition, copying what was there for the RBL_NRF51822. I've checked that the following code makes a LED blink on pin 7:

#define ONE_WIRE_BUS 7

setup:

nrf_gpio_cfg_output(ONE_WIRE_BUS);

loop:

nrf_gpio_pin_set(ONE_WIRE_BUS);
delay(250);
nrf_gpio_pin_clear(ONE_WIRE_BUS);
delay(250);

Where to start debugging this? Could it be that nrfgpio* functions timing is too sloppy (not "direct" enough) for OneWire, just like digitalWrite? How to proceed best if that's the case?

PaulStoffregen commented 7 years ago

Any serious effort requires an oscilloscope or logic analyzer to verify the signals have correct timing.

mrvanes commented 7 years ago

Fixed it! These are my BLE_NANO defiitions:

#elif defined(BLE_NANO)
#include <nRF51822_API.h>
#define PIN_TO_BASEREG(pin)             (0)
#define PIN_TO_BITMASK(pin)             (pin)
#define IO_REG_TYPE uint32_t
#define IO_REG_ASM
#define DIRECT_READ(base, pin)          nrf_gpio_pin_read(pin)
#define DIRECT_WRITE_LOW(base, pin)     nrf_gpio_pin_clear(pin)
#define DIRECT_WRITE_HIGH(base, pin)    nrf_gpio_pin_set(pin)
#define DIRECT_MODE_INPUT(base, pin)    nrf_gpio_cfg_input(pin, NRF_GPIO_PIN_NOPULL);
#define DIRECT_MODE_OUTPUT(base, pin)   nrf_gpio_cfg_output(pin)
#define DELAY(us)                       nrf_delay_us(us)

It turns out there is an NRF specific nrf_delay_us function that's (more) accurate than delayMicroseconds() so I created another macro for that and replaced all delayMicroseconds with DELAY in OneWire.c.

PaulStoffregen commented 7 years ago

Looks like the file name you included didn't appear in this message.

PaulStoffregen commented 7 years ago

when you post code in a message here, add 4 spaces the beginning of each line

// so it will appear
// as code, like this
jikelmon commented 7 years ago

I can confirm that mrvanes' changes do work on my RedBearLab nRF51822 (RBL_NRF51822) and BLENano (BLE_NANO) as well by using the nRF pinout instead of the on-pcb-printed pins. Actually there seems to be a real timing problem when using "delayMicroseconds(...)" instead of "nrf_delay_us(...)". Thank you very much!