PaulStoffregen / OneWire

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

Add support for internal pull-up resistor #30

Open jmhunter opened 7 years ago

jmhunter commented 7 years ago

Add the ability to use internal pull-up resistor for device search. Greatly reduces required components for the simple use case of detecting the presence of a DS1990 or similar unit

PaulStoffregen commented 7 years ago

Have this code been tested on any non-AVR chips?

StephanFink commented 7 years ago

I have tried it on a chipKit MAX32 Controller with a PIC chip and didn't manage it to work. But it would be great to see that function in your library. I have used that page to change your library and the embedded one in chipKits mpide: https://github.com/PaulStoffregen/OneWire/pull/30/commits/d8cbd4726dee9eb70d7a01a6e869ef9bc1044ddd

PaulStoffregen commented 7 years ago

Any tried on any other non-AVR boards? (I'm pretty sure it will not work on any of them)

jmhunter commented 7 years ago

If it only works on AVR boards (sorry, I only have Arduino here to test with), would it be an idea to update this to have some kind of #ifdef that limits its use to AVR?

orgua commented 6 years ago

it will work on some controllers like AVR, but won't do harm on the others. the changes could be more minimal though. the digitalWrite() in constructor shouldn't be needed

PaulStoffregen commented 6 years ago

but won't do harm on the others

Which others have you tested?

This code uses the AVR quirk where writing to the output register affects the input pullups. I do not intend to merge it as-is.

orgua commented 6 years ago

-> I tested this code without the preprocessor-guards with atmega328p, teensy3.2 and the esp8266, works as expected on atmega. won't do harm on the others. but you are right. i wouldn't merge this either without some cleanup.

what do you expect to happen on other architectures? we are using macros that rely on low level register access. there is no controller in your list that magically changes the pin-direction after the pin is set to input and the output-registers are written afterwards. here is a list of gpio-behaviors (compiled from the datasheets) for proving my point:

(AVR)

ReferenceDataSheet atmega328p

(MK20DX128) || (MK20DX256) || (MK66FX1M0) || (MK64FX512)

K20 / Cortex M4 Reference Manual page 239FF - Port control : Individual pull control registers with pullup, pulldown and pull-disable support page 1597FF - GPIO

MK64 / Cortex M4 Reference Manual page 1757ff -> same design as K20

K66 / Cortex M4 Reference Manual page 2185ff -> same design as K20

(MKL26Z64)

KL2x Cortex M0 Reference Manual page 844ff -> same design as K20

(SAM3X8E) || (SAM3A8C) || (SAM3A4C)

SAM3X \ SAM3A Cortex M3 Datasheet page 618ff PIO

(PIC32MX)

PIC32MX MIPS32 datasheet page 307ff io ports

(ARDUINO_ARCH_ESP8266)

ESP8266 Datasheet page 17: Each GPIO can be configured with internal pull-up

ESP8266 Technical Reference page 14ff GPIO

(SAMD21G18A)

SAMD21 Cortex M0+ Datasheet page 339ff PORT IO PIN CONTROLLER

DIR INEN PULLEN OUT Configuration 0 0 0 X Reset or analog I/O: all digital disabled 0 0 1 0 Pull-down; input disabled 0 0 1 1 Pull-up; input disabled 0 1 0 X Input 0 1 1 0 Input with pull-down 0 1 1 1 Input with pull-up 1 0 X X Output; input disabled 1 1 X X Output; input enabled

(RBL_NRF51822)

nRF51 Reference Manual page 56ff: config registers for direction, drive strengh, pull-up and down resistors, pin sensing

(arc) / Arduino101/Genuino101 specifics /

Intel Curie Module (Quark SE C1000) Datasheet page 54: Separate data register bit and data direction control bit for each GPIO

Quark SE C1000 page 410 GPIO

else