1 Wire Component Request - of sorts!

For questions and comments on programming in general. And for any items that don't fit into the forums below.

Moderators: Benj, Mods

Post Reply
Docara
Posts: 315
Joined: Sun Jun 23, 2013 1:29 pm
Has thanked: 28 times
Been thanked: 61 times
Contact:

1 Wire Component Request - of sorts!

Post by Docara »

Hi,

I've been struggling trying to develop a 1wire search routine for multiple devices for a while now and I have to give in and have to ask for some help, not only with a search routine but also the CRC calculation.

Would it be possible to have a component based on the DS2480B Line Driver which not only enables 1wire devices to be used upto 200m but incorporates a large portion of the Search Algorithm on die. The DS2482 also as this functionality and is a bridge based on I2C whereas the 2480B is a serial bridge device.

The reasons I said "as sorts" is that having this is a 'building block' component it will open the door to all the other 1wire devices over long distance which HAS too be useful to Flowcode Users.

What would be fantastic is to have a macro that presents us with ROM IDs and the calculated CRC so that we can store these values and therefore read and write to specific devices at will.

Thanks
Matt

Docara
Posts: 315
Joined: Sun Jun 23, 2013 1:29 pm
Has thanked: 28 times
Been thanked: 61 times
Contact:

Re: 1 Wire Component Request - of sorts!

Post by Docara »

Been quite a while since I posted - any thoughts Ben

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: 1 Wire Component Request - of sorts!

Post by Benj »

Hi Matt,

Right just getting around to looking into this for you. It's taking me longer because its all via PM and via Leigh. The PM was missing links so not sure if this is due to the PM forwarding from Leigh or if they were missed originally.

You asked about implementing a search algorithm similar to that shown here.
https://www.maximintegrated.com/en/app- ... mvp/id/187

Does the ScanBus function not already do this for you? The GetDeviceCount should then report how many devices are present, currently I think this is capped to 8 devices to save on RAM requirements.

I have thought about moving the core 1-Wire comms into a CAL C layer to try and make the code a bit neater and then having specific component sat on top of the CAL like we do for I2C and SPI. It's been a long time since I last looked at 1-wire so i'm currently a bit hazy with how it works.

Looking again at your posts here you mention an I2C based device with an inbuilt search function. would the macros be for this?

Might be easier if we start again so were not getting wires crossed :D

Docara
Posts: 315
Joined: Sun Jun 23, 2013 1:29 pm
Has thanked: 28 times
Been thanked: 61 times
Contact:

Re: 1 Wire Component Request - of sorts!

Post by Docara »

Hi Ben,

I can't thank you enough for looking into this - I was beginning to think I'd Really P****d you guys off!!

OK a brief recap - I would like to use around 14 1-wire devices over a 20-30m bus length. The problem with 1-wire systems is long cable length, reliable timings and number of devices on the bus. These problems aren't dealt with anywhere else.
Search YouTube for "1-wire Search Algorithm" there are two hits one is in Vietnamese!! Try as I might I just can't sort out implementing a Search Algorithm or the inclusion of the CRC.
The Arduino's 1-wire library, which is derived from the original Dallas Library, is the best thing there is for these devices in the public domain - but they don't deal with the inherent limitations of the bus and are generally flaky.

I genuinely think Matrix could benefit from this if implemented and used in a marketing campaign.

Anyway, have a look at the Serial to DS2480B Line Driver and see what you think https://datasheets.maximintegrated.com/ ... S2480B.pdf

Description
The DS2480B is a serial port to 1-Wire® interface chip that supports standard and overdrive speeds. It connects directly to UARTs and 5V RS-232 systems. Internal timers relieve the host of the burden of generating the time-critical 1-Wire communication waveforms. In contrast to the DS9097(E) where a full character must be sent by the host for each 1-Wire time slot, the DS2480B can translate each character into eight 1-Wire time slots, thereby increasing the data throughput significantly. In addition, the DS2480B can be set to communicate at four different data rates, including 115.2kbps, 57.6kbps, and 19.2kbps, with 9.6kbps being the power-on default. Command codes received from the host's crystal controlled UART serve as a reference to continuously calibrate the on-chip timing generator. The DS2480B uses a unique protocol that merges data and control information without requiring control pins. This approach maintains compatibility to off-the-shelf serial to wireless converters, allowing easy realization of 1-Wire media jumpers. The various control functions of the DS2480B are optimized for 1-Wire networks and support the special needs of all current 1-Wire devices including EPROM-based add-only memories, EEPROM devices, and 1-Wire thermometers. See Application Note 192: Using the DS2480B Serial 1-Wire Driver for detailed software examples.


The problem for us, generally, is not with using the (any) device's data but reliably finding (multiple) devices on the bus and then communicating with them, and herein lies the problem - the search and identification of devices and dealing with the CRC once found is nigh-on impossible . Even if there is only one device connected on a long bus (>1-2m) you could still have problems unless you sort out the line characteristics - once again we come back to DS2480B line driver

Now, I reckon if you could sort out a sub-component 'building block' for FC based around the DS2480B, you could, in theory, do away with having to maintain an FC component per device for every 1-wire device Matrix chooses to include in FC. Apart from an on-chip CRC, the DS2480B pretty much handles all the work for you transparently and pretty much eliminates the problems mentioned above and virtually eliminates any processor overhead. You just need to work out how to present us with 8bytes of the devices data and an easy way for us to supply a device with 8bytes of data.

As an example I am interested in installing 14 devices - 3x temp sensors, 1x ambient temp Sensor, 1x 8way bidirectional switch, 1x RTCC and possibly a 1-wire EEPROM or 1K memory. All of which would be easily implemented in FC without a dedicated component if I could just find and talk to them but I can't you see my point?

Matt

Post Reply