1_Wire display

I have no reason to use a brick-bat. If this is what you need to do, it's what you need.

The interface to this device is inherently parallel, either 4 or 8 bits. To get all the signals into a single byte you will need to use a 4 bit interface. This means you will need to set 4 data bits and toggle the E signal after setting the R/W and RS controls. Unless you want to read back data, there is no reason to control the R/W signal as the interface can be operated as write only.

The operation of the interface is limited by the instruction timing which is not at all fast. Your 1-wire interface will probably be a lot slower. I seem to recall it takes around 1-2 us to send one bit in the 1-wire protocol which means many us per bit written to the addressable switch. So writing the many bits to perform one bus cycle will almost certainly take more time than the instruction timing... except for the Clear Display and Return Home instructions which have ms level timing.

I didn't look at the app note, but if you cobble together the code to send nibbles to the LCD bus I'm sure you can find no limit to the code for the rest of the interface. Just be sure to write the reset command to the LCD three times to properly reset the bus. The hardware reset in the chip does not work properly and the only way to be sure of the state of the controller is to send the reset command three times in a row. By "reset" command I mean the Function Set command. It controls the width of the data bus and nothing you write prior to sending this instruction three times can be assured of being received.

I'll add two bits of experience:

1. the 1wire protocol is slow. Check the timings and see if you'll be able to update the display fast enough.

1. "Remote" and "1wire" don't play well. Mine is an extreme case (10 meters of 18 gauge furnace wire) but only one in 4 or so transactions actually succeed. Check capacitance and noise on that line. You might need to tweak the pull up resistor if you don't have active pullups on the driver.

You could just bit-bang it with strong driver relatively slowly and see if a hack like this works well enough over the required distance:

If you refresh the display every hundred ms or something and most of the "packets" are getting through OK then you don't really need to be constantly running CRC checks I don't think so long as the result looks acceptable.

Yeah it's dumb but there's also not too much to go wrong, there's a lot to go wrong with Maxim app notes!!!

A 1 wire interface of some type over a 4-20 current loop is a possibility.

Thanks for the suggestions.

We don't care that it's slow; if we update every 60 seconds or so, that's sufficient.

We have a slew of DS18B20's probes in use now. With CAT5 cable, no noise issues at all.

The DS2408 is supported by the Ethernet server.

Your conclusion doesn't necessarily follow (just because you have it "in use" doesn't mean its the "least parts"). Is cost an issue? Availability of alternate sources? Data integrity? Power consumption? Flexibility ("future safe-ty")?

Why not skip the display controller, too, and just have a single device (MCU) handle the comms *and* drive the display (glass)? (don't think of it as "code" but a "different VHDL dialect" :>)

This allows you to augment the capabilities on the display end in ways that the above solution simply can't address (without adding more components)

What if an "update" isn't received in N seconds? Do you just freeze the display with the last value displayed? What if N tends towards infinity -- do you ever alert the (remote) viewer (user) that he's looking at stale data?

What if updates are received but the data makes no sense? Do you try to display it? Or, do you discard it? How is this different (from the user's perspective) than an "update not received" condition? Can he take different remedial actions in each case?

What if you want to add attributes to the display (e.g., blink, inverse video, color, etc.)? Are you going to rely on a sufficiently fast update rate from the far end to make those happen in "real" time? (e.g., paint value, pause, paint blank, pause, paint value, pause...)

What if you want to change the display, itself (to one that is functionally identical but uses a different "controller")? As that will require changes to the "driving" end of the link, will the user know that the device *he* owns can only "talk" to a "model X" remote display? (i.e., one can virtualize the display interface if you have "smarts" on the remote end)

What if signal quality degrades and you need to renegotiate the timing of your protocol? Or, new noise sources become present? E.g., With smarts, you can (later) opt to frequency encode the data stream without having to change any hardware (no need to restrict yourself to just two frequencies!).

Etc.

Buy an LCD module that has an integrated RS232 interface? That = 1 wire.... EBAY.

On a sunny day (Tue, 30 Nov 2021 01:55:37 -0000 (UTC)) it happened David Lesher snipped-for-privacy@panix.com wrote in <so40ap$44a$ snipped-for-privacy@reader1.panix.com>:

scope_pic can also be used as a remote graphics display:

needs only 1 wire RS232 format. Only needs 1 PIC 18F14K22

is open source.

While throwing an MCU at the problem has some advantages, spreading a code base over two processors adds complication and makes debug and maintenance more difficult. Your suggested advantages would not seem to be of much value.

Thank you for all your responses.

a) This is not a high-production product; rather it's a 1 or 2 off custom device for use with an existing system.

b) That includes a working 1_Wire(tm) system. It uses multiple Embedded Data System OW-Servers that have 3 channels of 1_Wire devices, and supports multiple high-level TCP/IP protocols; no bit banging needed.

c) It works well with multiple devices on long (multiple 100's of ft) twisted pair cable runs. We've not seen any error issues so far.

d) The system is based around a custom NXP-based controller. It talks to the EDS's via TCP/IP. It talks to other industrial gear via RS-485.

We pondered driving the display via RS-485, but doubt that offers major advantages. There's no available RS-232 on the NXP, even if it would run over the cable run available.

Does the above inspire solutions not yet offered?

That's interesting. Usually, there are noise and ground issues on lengthy runs, esp if DC-coupled.

If you think it will work for you -- and is already in line with other "solutions" you've deployed -- then go for it!

I've taken to using ethernet over CAT5 for most of my interconnects, now. But, that's primarily because it affords me gobs of bandwidth (which also includes being able to push new firmware on-the-fly)

I had cobbled together a "data-over-power" solution to communicate with a repurposed Nest thermostat using the two unused conductors in the thermostat wiring harness but found it quickly ran out of bandwidth. Even encoding terse "commands" that could be executed by the MCU

*behind* the Nest (e.g., 0x07 = flash display, 0x08 = display character that follows, 0x09 set color to character that follows...) proved too slugish.

So, I replaced the thermostat cable with CAT5e and now I can control the Nest's display in real time (animations, etc. instead of just a static, numeric display). It's still a kludge as I don't have direct control over the Nest's hardware. But, foolish to try to redesign a product that is already so nicely packaged!

[IMO, the Nest is the ideal UI for a thermostat. But, *as* a thermostat, I found it sorely lacking!]

...

So we are NOW looking at using the DS28E18 or DS28E17 1-Wire to I2C chips as it seems there are a metric ****load of displays driven by same:

Both are 3.3v which require a bidir level shifter but that's perhaps doable.

"Quickswitch" is a brand name I believe, but there are multiple sources. Or you can roll your own with a FET on each of the clock and data lines. Tie the gate of a MOSFET to the 5 volt rail through a diode and you should get the right switching voltage to disable the channel for any input greater than about 3 volts. Or use one of the switch based logic interface parts. It essentially creates a bi-dir drive that is totem pole up to about 3 volts and is open drain above that. So you get the rapid rise in voltage through the full 3 volt range with no issues of over voltage on the 3.3 volt side.

I strongly recommend you avoid Aliexpress though. Find other sources. Aliexpress is not there for the buyers.

So, you're looking to use one-wire for the "long run" with the protocol converter located immediately adjacent to the display?

Again, make *sure* you will have a minimum RELIABLE data rate to drive the display content as you require. You can't correct what the user has already *seen*!

In my (Nest thermostat) case, I initially assumed I would just use the display as a traditional thermostat: display current temperature and temperature setpoint. And, as those don't change often, I *rationalized* that I could get by with a very low data rate (which I could *guarantee* to be error-free).

But, the appeal of that nice *round* fully graphic display just couldn't be ignored. And, even if I had created "codes" for specific animations, etc., it was always a kludge... I couldn't easily change how the display was used without off-line altering the code in the MCU that sat behind the Nest (cuz my comm-link to it was dog slow... way too slow to upload new firmware!).

Now, with the fat (100Mb) pipe to that MCU, I can push the entire firmware image into the MCU, executing out of RAM, every time I apply power. And, can tweek the Nest's display contents at better than a 60Hz update rate to show whatever I want.

All this without worrying about corruption on the comms link!

And, I can replace the Nest with a different UI device without having the rest of the system knowing that there has been a change in Presentation

[In your case, you may be able to get the bandwidth you need from the one-wire/I2C i/f in a *local* connection but may find yourself facing problems if the link bandwidth deteriorates "at distance"]

Good luck!