AVR based Econet Clock

[KenLowe]

Hi folks,

I'd like to integrate a simple Econet clock (and termination) into some of my Econet bridge board designs:

viewtopic.php?p=346961#p346961
viewtopic.php?p=357891#p357891

and have been looking at the clock designed by Simon Inns:

https://www.waitingforfriday.com/?p=19

I'm aware that there are some differing opinions about using the AVR to drive the network clock directly, so was considering routing the positive (non-inverted) AVR output via a dedicated AM26LS30 differential line driver. That means that I wouldn't need to use the negative (inverted) AVR output.

Also, I note from the AVR source code comments that the Econet clock is being derived from an internal 8Mhz clock, and that it may not be the most accurate:

Code: Select all

// Internal clock @ 8MHz - This code is using the internal oscillator
// so don't expect the clock speed to be too accurate.  In my tests the
// output was within about 10 KHz of the expected value - close enough
// for this application.

Given that I could free up a spare pin on the AVR, and because I already have an external 8MHz clock on the Econet bridge board, I could wire this into the AVR and use that instead. Would there be any benefit in me doing that?

I've had a quick look through the AVR code, but I'm not yet familiar with AVR coding, so I'm not sure if the above changes would be straight forward. Is there anyone with AVR knowledge who could advise?

TIA.

[IanJeffray]

An external clock source can only be applied to pin2 of the ATtiny45. It's selected by the fuses.
Simon's currently using pin 2 (PB3) for the Econet CLK+ out but that could be tweaked I guess... skip the in-place programming / switch selection and shift the clock outputs to PB0/PB1 perhaps. I'm not convinced that the switch options are really worth much?
In AtmelStudio (Microchip Studio - ugh!) in the programming selection, the clock source would be selected as shown:

I'm happy to help with this project - should be able to hack something up on a breadboard and prove the code. (I have some spare ATTiny45-20 to hand here)

Whether or not all this is worthwhile though, I'm not sure. I've got a Simon Inns clock here, and a "Simon Inns Clock" built on to an IanS Econet podule... I can take some measurements of how accurate / drifty the outputs are if that'd help?

[IanJeffray]

I'm aware that there are some differing opinions about using the AVR to drive the network clock directly, so was considering routing the positive (non-inverted) AVR output via a dedicated AM26LS30 differential line driver.

It's interesting to read what Simon wrote on that subject...

The design does not need a differential line driver since the AVR can generate both the positive and negative clock signals using it’s on-board PWM module. This has the advantage of both simplifying the circuit as well as improving the signal (since a line driver is essentially an opamp it does not drive the output signal rail-to-rail (i.e. from 0V to 5V) – however the AVR’s PWM can. This drives the line with more mW of signal than possible with a line driver which should improve the clock’s performance in longer/larger networks)."

(my emboldening) - so what are the opinions that state that this isn't a preferable plan? (and fewer components...)

[IanJeffray]

I've got a Simon Inns clock here, and a "Simon Inns Clock" built on to an IanS Econet podule... I can take some measurements of how accurate / drifty the outputs are if that'd help?

A quick infinite-persistance capture with "temperature" palette for 5 minutes shows this:

That looks superbly stable to me. The precise clock speed ought not to be a concern surely - since we're the clock running the show here.

[KenLowe]

so what are the opinions that state that this isn't a preferable plan?

There's a bit of discussion about it in this thread:

viewtopic.php?f=3&t=22359

It is also running the ATtiny chip out-of-spec (assuming you do in fact terminate the network), so not ideal for longevity.

And here:

viewtopic.php?p=316172#p316172

Every time I see one of these "circuits" with an MCU's bare GPIO pins used as a differential "line driver" I have to go away and scream! (In the day job that would be a taken-outside-and-shot offence, so some of that is conditioning...)

To put this in perspective, you are shorting two opposing voltages together with 50 Ohms (two terminators in parallel). Those two voltages are your supply rails (say 0 and 3.3V) less the voltage drop through the resistance through some not-very-big FETs that are the output stage of the pin. Estimating the On-resistance of the pins is tricky, not least as Broadcom are so shy about sharing datasheets (anybody'd think they don't want you to buy their parts, but I digress). But at the max current it's probably dropping about 0.5V through the pin (if that's 16mA - probably about right, certainly in the typical range for a micro - then that gives a FET around 30 Ohms.)

So we have:

Code: Select all

3.3V----[30 Ohms]----o----[50 Ohms]----o----[30 Ohms]----0V

Ohm's law says you should be passing 30mA. Which means you are dissipating about 30mW in each pin (a 60mW hotspot if you picked adjacent pins!). That doesn't sound a lot until you realise just how small those FETs are (you don't put whoppers on a micro: they'd eat too much die space)... and the CPU on a Pi is in a BGA, so you haven't even got a leadframe (i.e. the legs) to use as a mini-heatsink. (the ATmega/ATtiny versions score slightly better here...)

So the odds are you'll be running the poor thing close to it's death zone. And that's if all goes well. (Oh, and there are also things like "ground bounce" - passing lots of current through a chip's ground pin raises the on-chip ground rail a bit above true ground, reducing your noise immunity and/or introducing unexpected signals.... don't forget the Pi's CPU core logic is probably only running on a 1.0-1.5V supply!)

Now consider the following:

• If the line accidentally gets shorted, you have no protection: your whole supply voltage is being shorted through the pins. Game over.
• If something else drives the line when the Pi isn't powered, then it'll do it's best to power the Pi through the protection diodes on the power pins. That won't end well either.
• If you have a longish length of cable and don't get the terminators right, the reflections can easily reach double (and/or minus) the voltage you put in. Ouch.
• If something else (e.g. static) gets into the cable...
• If something plugged into the cable elsewhere has a different ground voltage, by more than 3.3V (surprisingly easy to achieve) then it will end very badly, as there is no scope for the common-mode voltage to get outside the supply rails (the protection diodes turn on again...)
• ... and so on. If it's bad, and you have "long"/"external" (as in outside-the-equipment-box) cabling then it will happen. Sooner or later.

Now, the thing is that the line driver chips are not only designed and specified to drive continuously into the 50 Ohm terminated line (a quick check of the old 75159 datasheet shows a typical operating current of 40mA... probably more than most micros' Absolute Maximum. The 26LS3x are similar, some of the modern ones are nearly double) but also to deal with all of the above fault conditions (the 422/485 standards specify most of these). Some vastly exceed it (Maxim, TI, and Analog Devices - to mention a few - have an extensive portfolio of 422/485 drivers which includes ICs with 15kV static protection, 2+kV electrical isolation, high drive currents, full short circuit protection, and more... mostly from a 3.3V supply)

There's one big clue that all is not well here: to meet the 485 drive levels you only need to run your driver from 3.3V. There are plenty that do and none (well, apart from the internal isolation ones) have any sort of step-up supply (unlike the 232 drivers which do). So if you aren't managing to power the passive terminators then your drive voltages must be collapsing: the Pi's GPIO pin FETs are not coping.

So do yourselves, and your kit a favour and stick a driver (or transceiver) in and then you can relax. There are hundreds to chose from - you can trade off price vs paranoia as you wish. There really isn't any excuse not to do it properly!

Oh, and if you want to risk the death of your own kit, so be it, but making such for sale/build by the unwary is not really acceptable.


PS: just seen sweh's: The "40mA" spec for the ATmegs328 on the Arduino Nano is the "Absolute Maximum" (as the adjacent note says "beyond [this] may cause permanent damage to the device" i.e. this is the red line: there is no margin left for error ). Down the page a bit, they're only rated to operate at 20mA at 5V/10mA at 3.3V. And that's a nice 'scope trace of the pin voltages exceeding the Abs Max limit of 0.5V beyond the rails, too ... You're on borrowed time.

[KenLowe]

Hmm. Thinking about this a bit further, could we use the existing Bridge Pi in place of the ATTiny45, and pass the Pi output through a differential line driver? If necessary, there's already an 8MHz clock signal available on the bridge board that could be wired into the Pi, if that would help in any way...

Edit: Also, what's the general view on using different circuits on the same 26LS31 line driver for driving both the data and clock?
Edit2: Just realised that I can't use another circuit on the same 26LS31, because they share a common enable

[arg]

It's interesting to read what Simon wrote on that subject...

The design does not need a differential line driver since the AVR can generate both the positive and negative clock signals using it’s on-board PWM module. This has the advantage of both simplifying the circuit as well as improving the signal (since a line driver is essentially an opamp it does not drive the output signal rail-to-rail (i.e. from 0V to 5V) – however the AVR’s PWM can. This drives the line with more mW of signal than possible with a line driver which should improve the clock’s performance in longer/larger networks)."

(my emboldening) - so what are the opinions that state that this isn't a preferable plan? (and fewer components...)

That quote is essentially total bollocks.

A line driver is not an opamp, and doesn't care whether or not it drive the output rail-to-rail - what they care about is delivering a given differential voltage into the line impedance. For a driver powered from 5V, the desired swing is significantly less than rail-to-rail. And the AVR can't drive rail-to-rail into 50 ohms anyhow: 5V into a 50 ohm load would be 100mA, which the AVR isn't rated for, but even at the maximum 20mA that it is rated for the datasheet says that it only gets within 0.5V of the rail. There is no problem actually seen on long Econets where "more mW" would be any kind of solution, and the AVR would not be capable of delivering it if there was.

Just don't do it.

[IanJeffray]

Hmm. Thinking about this a bit further, could we use the existing Bridge Pi in place of the ATTiny45, and pass the Pi output through a differential line driver? If necessary, there's already an 8MHz clock signal available on the bridge board that could be wired into the Pi, if that would help in any way...

The ATTiny isn't generating the clock with code - it's using the hardware PWM to do this (the code just configures the PWM) - a Pi isn't going to have a hope of doing the same in code with any level of reliability/precision/etc - whether or not there's a PWM block that could be set up in the same manner though, I don't know.

Edit: Also, what's the general view on using different circuits on the same 26LS31 line driver for driving both the data and clock?

IanS's Econet podule does that with the LS30.

[arg]

Hmm. Thinking about this a bit further, could we use the existing Bridge Pi in place of the ATTiny45, and pass the Pi output through a differential line driver? If necessary, there's already an 8MHz clock signal available on the bridge board that could be wired into the Pi, if that would help in any way...

Edit: Also, what's the general view on using different circuits on the same 26LS31 line driver for driving both the data and clock?

There is no point feeding the 8MHz back into the Pi as it already has plenty of accurate high speed clocks. However, the Pi does have a PWM output, which there was previous discussion of using to generate the 8MHz to avoid the need for the oscillator on your board - but at the time Chris couldn't get it to work (though I'm not sure he tried that hard). Using that Pi PWM output as the clock is closer to what the Pi PWM is designed to do, so having another go at that is probably a better idea. One of the issues with the Pi PWM was that the APIs provided in modern Pi OS ignore the hardware PWM because it is single-channel and/or used for audio and instead offer a multi-channel PWM driven by DMA of the GPIO hardware rather than dedicated PWM hardware. For the Econet clock, the DMA-style PWM would be just about adequate, though using the real PWM would be better.

Using multiple channels in the 26LS31 is unfortunately impossible as there's only one enable (well, there's two enable pins but they both enable/disable all four drivers together). So there's no way to get one driver permanently enabled for the clock with the other enabled only when required for Tx.

I've recently built a "new generation" Econet board (ie. using modern parts for everything, somewhat constrained by parts that are actually available to buy in 2022!). On that, I'm using 65HVD75 (powered from 3V3) as the line driver/receiver, and a novel current-based collision detect circuit. I powered it up for the first time last night and it successfully communicates on the Econet, but I haven't yet had time to characterise it properly and see if the voltage levels actually match traditional Econet, whether the CD works at all, etc. Since I'm using the same part for the clock receiver, that gets me the ability to drive a clock "for free".

Note that neither my clock nor your proposed 26LS31 will work with SJ-style line-powered terminators; BITD I would have regarded that as a show-stopper, but I am considering these on-board clocks/terminators as suitable for driving table-top scale networks (which must be the vast majority nowadays), and would suggest that people wanting a proper infrastructure network still use the traditional separate clock/terminator set. For table-top networks, you might as well have the clock and termination in the same unit.

[KenLowe]

There is no point feeding the 8MHz back into the Pi as it already has plenty of accurate high speed clocks. However, the Pi does have a PWM output, which there was previous discussion of using to generate the 8MHz to avoid the need for the oscillator on your board - but at the time Chris couldn't get it to work (though I'm not sure he tried that hard). Using that Pi PWM output as the clock is closer to what the Pi PWM is designed to do, so having another go at that is probably a better idea. One of the issues with the Pi PWM was that the APIs provided in modern Pi OS ignore the hardware PWM because it is single-channel and/or used for audio and instead offer a multi-channel PWM driven by DMA of the GPIO hardware rather than dedicated PWM hardware. For the Econet clock, the DMA-style PWM would be just about adequate, though using the real PWM would be better.

I was just having a quick chat with Chris offline about this, and I'll certainly explore that a bit further with him.

Using multiple channels in the 26LS31 is unfortunately impossible as there's only one enable (well, there's two enable pins but they both enable/disable all four drivers together). So there's no way to get one driver permanently enabled for the clock with the other enabled only when required for Tx.

Yes, I figured out that I couldn't do what I was suggesting, and edited my post just as you were posting this. I could move back to the 26LS30 which would give me two independent channels. However, the reason I selected the 26LS31 is because JLC don't offer the 26LS30; only the 26LS31. If I did go with the 26LS30 it would mean that I would have to source and hand solder that part. Not a major issue, but I would prefer to have all these SMD parts machine soldered by JLC.

I've recently built a "new generation" Econet board (ie. using modern parts for everything, somewhat constrained by parts that are actually available to buy in 2022!). On that, I'm using 65HVD75 (powered from 3V3) as the line driver/receiver, and a novel current-based collision detect circuit. I powered it up for the first time last night and it successfully communicates on the Econet, but I haven't yet had time to characterise it properly and see if the voltage levels actually match traditional Econet, whether the CD works at all, etc. Since I'm using the same part for the clock receiver, that gets me the ability to drive a clock "for free".

I was looking at the some 3V3 devices earlier, which I thought might be appropriate and JLC had in stock at a reasonable price, but I can't find them any more!

[arg]

I was looking at the some 3V3 devices earlier, which I thought might be appropriate and JLC had in stock at a reasonable price, but I can't find them any more!

One of the reasons for selecting the 65HVD75 was that it was in stock, both on my shelf and at JLC. It's not cheap, but not extortionate either.

Actually, while I had my boards built with the pukka TI part (JLC C57928), I now notice that JLC also stock a knock-off version at a third the price (C444387).

[KenLowe]

I was looking at the some 3V3 devices earlier, which I thought might be appropriate and JLC had in stock at a reasonable price, but I can't find them any more!

One of the reasons for selecting the 65HVD75 was that it was in stock, both on my shelf and at JLC. It's not cheap, but not extortionate either.

Actually, while I had my boards built with the pukka TI part (JLC C57928), I now notice that JLC also stock a knock-off version at a third the price (C444387).

Do you think the MC3487 would be a suitable alternative? It has two pairs of differential drivers. One pair could be used to drive the two legs of my Econet clock, and one driver from the other pair could be used for the data. I think the enable logic is opposite from the 26LS30/31, but that should be easily dealt with. The other bonus is that it's in stock at JLC, and doesn't cost the earth: C7309

https://www.ti.com/cn/lit/ds/symlink/mc ... 2616415590

[arg]

Do you think the MC3487 would be a suitable alternative? It has two pairs of differential drivers. One pair could be used to drive the two legs of my Econet clock, and one driver from the other pair could be used for the data. I think the enable logic is opposite from the 26LS30/31, but that should be easily dealt with. The other bonus is that it's in stock at JLC, and doesn't cost the earth: C7309

Yes, looks like it would do the job and is a reasonable companion to the rest of the 'classic' circuit. The enable is the same way up as the original 75159, though if you've got the LS123 chatter disconnect circuit then you have both polarities available anyhow.

First results on the 65HVD75 suggest that the device itself should be satisfactory, but my collision detect circuit doesn't quite work as currently designed. Still, all this 3V stuff makes more sense if you are replacing the 6845 as well, otherwise the classic circuit is actually not much bigger.

Terminators have also been causing me some head scratching - I must have done about half a dozen designs (and built half of them), with various different trade-offs, though it's tempting to go for dip switches rather than software control, whereupon it becomes easy.

[KenLowe]

Do you think the MC3487 would be a suitable alternative? It has two pairs of differential drivers. One pair could be used to drive the two legs of my Econet clock, and one driver from the other pair could be used for the data. I think the enable logic is opposite from the 26LS30/31, but that should be easily dealt with. The other bonus is that it's in stock at JLC, and doesn't cost the earth: C7309

Yes, looks like it would do the job and is a reasonable companion to the rest of the 'classic' circuit. The enable is the same way up as the original 75159, though if you've got the LS123 chatter disconnect circuit then you have both polarities available anyhow.

Thanks for confirming.

Following some discussion with Chris, we're going to try and get the Pi to spit out both the 8MHz clock for the ADLC clock circuit, and the lower frequency clock for the Econet network. I've updated the schematic to include the necessary changes. In summary, the changes are as follows:

• The original 26LS31 data bus driver has been swapped out for a MC3487 which has two pairs of independent drivers as described above.
• One pair of drivers will be used to drive the two legs of my Econet clock (on the larger bridge board - the smaller bridge board only has a single leg), and one driver from the other pair will be used for the data.
• ADLC clock circuit will be driven from either a dedicated 8MHz clock (which I hope to drop at some point) or from Pi generated 8MHz clock (on GPIO7).
• Econet network clock will be generated from Pi (on GPIO18). It's wired through one of the MC3487 line driver, and can be disabled via jumper.
• Data and clock termination has been added, and can be selected / deselected via jumpers (1.27mm).

Here's a copy of the schematic showing the MC3487 in place of the 26LS31, and with the additional termination. Can someone check that I'm using the correct termination here?

The design of the termination is that with the jumpers removed everything is disabled. When the board is being used in Econet module mode, I won't even install the header pins. I'm now back to using the non inverted output from the LS123 as was suggested that I need to do. For the Econet clock circuit, I'm using a simple pull down to disable the driver via the enable input.

Econet Module with onboard Termination

[arg]

That does look like a reasonable arrangement for the single socket device.

I'm not sure how you are going to make your dual-socket drive the two clocks separately while still being able to have the clock turned off and pass-through between the two sockets. I think I would just give up and wire it exactly as for the single socket unit: you aren't offsetting the power to the driver (and can't because it's shared with the data), so it can't be used with remote SJ-type terminators, so there is less merit in driving the two outputs separately. It's also less straightforward for the user, as they now need to terminate both outputs (or just not use one of them). Altogether I think the dual outputs just aren't worth it, despite that second driver sitting there crying out to be used.

[KenLowe]

There is no point feeding the 8MHz back into the Pi as it already has plenty of accurate high speed clocks. However, the Pi does have a PWM output, which there was previous discussion of using to generate the 8MHz to avoid the need for the oscillator on your board - but at the time Chris couldn't get it to work (though I'm not sure he tried that hard). Using that Pi PWM output as the clock is closer to what the Pi PWM is designed to do, so having another go at that is probably a better idea. One of the issues with the Pi PWM was that the APIs provided in modern Pi OS ignore the hardware PWM because it is single-channel and/or used for audio and instead offer a multi-channel PWM driven by DMA of the GPIO hardware rather than dedicated PWM hardware. For the Econet clock, the DMA-style PWM would be just about adequate, though using the real PWM would be better.

I've had a little play around with the Pi clocks this evening, and had some success using the pigpio library. After downloading and installing the library and then starting the pigpio daemon (instructions on the pigpio site), I was able to run a small python script to set up GPIO18 with a 200kHz clock - 5uS period, 1uS mark:

pi@raspberrypi:~ $vi econet_clk.py

Code: Select all

import pigpio

econet_clk = pigpio.pi()
econet_clk.hardware_PWM(18, 200000, 200000) # 200kHz 20% dutycycle

pi@raspberrypi:~ $ python econet_clk.py
pi@raspberrypi:~ $

and this is what I see when I attach my scope to pin 12 (GPIO18) on the GPIO header:

Econet 200kHz Clock from Raspberry Pi

I then had a look at the 8MHz clock, and was able to get it running on pin 7 (GPIO4) fairly easily with the following command:

pi@raspberrypi:~ $ pigs hc 4 8000000
pi@raspberrypi:~ $

and this is what I see when I attach my scope to pin 7 (GPIO4) on the GPIO header:

ADLC 8MHz Clock from Raspberry Pi

Bridge software was running (on a Pi 4) throughout all these tests without any issues.

Next up I'll need to put the Econet clock through a suitable differential line driver, and put the ADLC clock onto the bridge board in place of the hardware clock and see how it all performs.

[arg]

I then had a look at the 8MHz clock, and was able to get it running on pin 7 (GPIO4) fairly easily with the following command:

pi@raspberrypi:~ $ pigs hc 4 8000000

Yes, that looks exactly what you want, using the hardware PWM for the Econet clock and the direct clock outputs (that I had forgotten about!) for the 8MHz.

So you should have reliable, well-formed clocks with no software overhead.

[KenLowe]

Here's the 200kHz econet clock wired out from the Pi through a temporary 26LS30:

Econet clock running at 5uS period / 1uS mark

Econet clock running at 5uS period / 1uS mark

Termination is as follows:

Clock - 100R between C+ & C-
Data - 1K0 between +5v & D+, 220R between D+ & D-, 1K0 between D- & Gnd.

Working perfectly with no further termination on my network.

[IanJeffray]

Hecking slow edges though?

[KenLowe]

Hecking slow edges though?

It looks like it's actually faster than the hardware clock:



Also, if you look at what's coming directly out of the Pi a couple of posts up, it would appear to be the line driver that's slowing things down a bit.

[dp11]

Hecking slow edges though?

Exactly what you want when driving long multi drop cables. 5pin din connectors aren't exactly known for their impedance.

[KenLowe]

Do you think the MC3487 would be a suitable alternative? It has two pairs of differential drivers. One pair could be used to drive the two legs of my Econet clock, and one driver from the other pair could be used for the data. I think the enable logic is opposite from the 26LS30/31, but that should be easily dealt with. The other bonus is that it's in stock at JLC, and doesn't cost the earth: C7309

Yes, looks like it would do the job and is a reasonable companion to the rest of the 'classic' circuit. The enable is the same way up as the original 75159, though if you've got the LS123 chatter disconnect circuit then you have both polarities available anyhow.

I received a test MC3487 today and wired that into my breadboard circuit, in place of the 26LS30, and it's working nicely.