One-wire EEPROMs--any wisdom?

Hi, all,

I have a good customer who produces fire detection and control equipment. I'm doing a new product line for them that uses low cost analogue sensor boards connected via Displayport cables with a concentrator unit that has the ADC, control, and communications functions for up to 6 sensors.

Displayport cables have a lot of bang for the buck, but they don't have quite enough lanes for my purposes, so I'm trying to save pins.

Because there are a few different types of sensor boards, I need the concentrator to be able to identify what's connected to each DP position. One natural way of doing this is to put an EEPROM on each sensor board, and that lets me put version number and a bit of calibration data and stuff there as well.

I only have one wire available, though, so the Microchip 11A020T 256x8 looks attractive.

Before I design the thing in, does anybody here have relevant experience to share? What's the best way to talk to it? I'm okay going pretty slowly (say 10 kHz clock rate).

Thanks

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs
Loading thread data ...

I played with a Dallsas part once (an RTC), real sensitive to timing. Had to disable interrupts while bit banging. It worked well tho. You might want to peruse the old one-wire button app notes from Dallas.

Cheers

Reply to
Martin Riddle

I've used the Dallas 1k serial unit in many Arduino (AVR) projects. Like Ma rtin mentioned you can't read a few bits here and there. You must read all the bits you need in one single access un-interrupted. Check out the htt p://playground.arduino.cc/Learning/OneWire page for sources of example cod e.

Reply to
alan.yeager.2013

Phil Hobbs wrote on 6/29/2017 9:52 AM:

The nice thing about the Dallas devices is that they have a unique serial number in ROM. So you automatically get a serial number for your device. Then you can program the info you need without worrying about producing unique serial numbers to program in. Instead you read them out when you test the board and can add that to a label if you need to read it manually.

--

Rick C
Reply to
rickman

We use the Dallas/Maxim 1-wire EEPROMs to do a very similar job to what you are describing. For some reason they don't suffer from the same supply problems as other Maxim parts, 10+ years so far and no trouble with availability. They get used in a lot of POS terminals, that probably helps.

Our first generation of product bit-banged the protocol using a PIC16 series MCU which wasn't doing much else. We just moved over to STM32 for all our new designs, the micro now has to do lots of floating-point calcs, run an Ethernet stack, make the tea etc and nobody could work out whether it could be guaranteed meet the 1-wire timing specs. There was an FPGA on the board as well so we just used that.

We had lots of problems with transient interference initially (product had to pass IEC 61000-4-4). The EEPROM was out on the end of a few inches of unshielded wiring, and there is no error checking in the 1- wire protocol. We RC filtered the interface as much as we dared, and did multiple reads with majority voting. The write operation is done in a much more benign environment, I'm not sure how we would have managed that otherwise. If your application is well shielded (which it sounds like it is if you're using Displayport cabling) you should be fine.

HTH

Reply to
RBlack

Not an UNI/O part, but I've had success using this eight channel 1-wire part as a bus master: One of its advantages is that it takes care of the details of the timing, relieving your software of that burden.

In my application I had only one slave per bus, so I can't comment on the fanout limitations one meets in practice.

Allan

Reply to
Allan Herriman

Check out the Dallas (Maxim) app notes such as AN148 (their site is down right now).

formatting link

Probably you'll be okay with reasonable cable lengths. IIRC the software took a bit longer than I expected to implement the full protocol from the datasheet.

One issue with repurposing consumer products is that they are gone faster than you might think. Like those special 80-conductor/40 pin things I used for video signals seemingly not that long ago..

--sp

--
Best regards,  
Spehro Pefhany
Reply to
Spehro Pefhany

You have an a-d on the concentrator, so could you use a discreet preset voltage level at each board to identify it ?...

Chris

Reply to
Chris

...a bit more, if that level covered a small window, it might be enough to define the calibration as well. Look, no eeprom...

Chris

Reply to
Chris

That's something I've thought of too. Since it would have to be separate from the other analogue signals, it would still take up a wire. It would be much simpler to deal with, because I could filter it heavily to get rid of any schmutz.

The EEPROM is a bit more future-proof (assuming they remain available) because a new type of sensor could contain enough information (photodetector sizes, transimpedance gains, offsets, bandwidths, pin configuration and so on) to enable an old-model concentrator to deal with it correctly.

A lot of these things get installed in rickety wooden buildings in places like Bangladesh, with iffy power and even iffier grounding, and still need a long service life.

Fun.

Thanks

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

Interesting part, thanks. Hmm...bit of a Faustian bargain...a quiet life if I just agree to trust Maxim.....hmmm. ;)

The EEPROM's minimum clock rate is 10 kHz, and its output is encoded as pulse width, so I'd need to check and/or update every 25 us or so to make sure I don't miss anything.

I have a 200 ks/s ADC to look after anyway, so I can probably add the UNI/O bit banging code to the SPI interrupt handler. I'm using an LPC176x processor, which like other Cortex Ms has deterministic 12-cycle interrupt latency. Thus as long as I do the bit banging before any conditional branches in the handler, I should maintain jitter-free timing. SPI will be the second-highest interrupt priority, right after the one that activates the fire control system. If that one hits, I don't care about having to restart everything else afterwards.

The issue as usual will be to avoid starving mainline code and lower-priority interrupts. We'll try coding up just the handler and see how many cycles it takes--if it's 50 or so, that's only a 10% burden on the CPU, which should be pretty manageable.

I also need to read up on the DMA controller, to see if it's possible to space out the individual DMA transfers a bit without slowing down the SPI clock. That way I could let the DMA controller run the ADC and have more time to deal with switching the mux, running chip select, and bit banging.

A third possibility is to unload the EEPROM task to something like an ATtiny.

I don't do enough embedded work to get super good at it, so I've standardized on LPC17s and AVRs, which aren't the cheapest but are very well supported and work very well for many tasks. (Customers building stuff that needs lots of bells and whistles generally have their own embedded guy.)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

When I read the words, "fire control system" in the same context with "interrupt", the first thought that crossed my mind was, why use an MCU rather than an FPGA? I assume your system requires memory resources that would not fit in a low cost FPGA?

I learned embedded coding long before I learned HDL programming. But once I had designed an entire system in an FPGA without an MCU, I realized how much simpler it can be when designing real time systems. The rules of using priority levels in interrupts are not so simple.

--

Rick C
Reply to
rickman

You could use that extra wire to switch in a SPI device on existing pins. That way you can avoid the 1-wire mess and still have use of the rest of the wires for normal operation.

And not be reliant on Maxim.

Cheers

Reply to
Martin Riddle

An eeprom is the textbook solution, but just adds complexity and cost, not to mention running digital fast edges across shaky wiring. Not only that, but you need to write the code to drive it as well.

An analog solution needs only a pair of resistors, running from say, the 5 volt incoming rail, whatever. That doesn't even need to be that stable if you measure it first as part of the sequence reading the divider voltages. You already have the code to drive the a-d...

Chris

Reply to
Chris

I2C is really a nice interface when you need flexibility and things like cables and/or isolation. I2C EEPROMs are almost free- 2 or 3 cents for a 24C01, and multiple-sourced. You can stick a port expander or an ADC or whatever on the same bus.

--sp

--
Best regards,  
Spehro Pefhany
Reply to
Spehro Pefhany

I'll have a squint at it, thanks..

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

It'll be Bit-Banging From Hell. Be sure and chamber test it to exhaustion. I'd CRC32 everything over that wire, too.

--
Les Cargill
Reply to
Les Cargill

Did you consider the other signals, power and GND, to multiplex communication into those nodes?

On Power, you can add a rectifier/cap as local decoupling of the E2PROM, and then draw the communication signal before the diode. On the transmitter side, you need to be able to turn off the power node.

Cheers

Klaus

Reply to
klaus.kragelund

...

...

There has been a lot of discussion on how to meet the timing requirements of the devices especially with regard to interrupts and other software running on the processor - is that relevant?

I've only used these devices to stored identification and capabilities information which is usually needed before other software can operate anyway so it has been acceptable to disable interrupts or other time critical software.

Even when setting configuration that requires a write to the one-wire device It has been acceptable to have a requirement that the rest of the software is paused.

Do your use cases allow this?

I will admit I prefer I2C for this type of application especially as suitable devices are multi-sourced.

The HDMI standard defines I2C for the identification and capability mechanism and they allow it over a few meters of cables.

kevin

Reply to
kevin93

one wire says the lowest clock speed is 15.? kHz, so you might have trouble going at 10k

--
Using Opera's mail client: http://www.opera.com/mail/
Reply to
David Eather

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.