Skip to main content ↑ ↓
Topic: uCAN: A protocol stack for microcontroller networking (Read 142341 times) previous topic - next topic

Re: uCAN: A protocol stack for microcontroller networking

Reply #255 –
[quote author="Folknology"][quote author="nickjohnson"]
To the best of my knowledge, out pinout isn't compatible with any existing CAN based networks. What existing fixed termination would we be dealing with?[/quote]

An existing network is one which has been built and your device is added to it, that does not mean the network has been built in our past, merely it separates the network installation from the application of your device upon it, unless you (and everyone else) anticipates only adding devices onto your own networks you have installed.

It is also beneficial if we can adapt our devices to other existing network infrastructures (as has been commented on with earlier parts of the thread and is also partly the reason for choosing the new RJ45 pinout if I recall)

Often linear networks (especially those being installed using structured cabling) will be laid to fixed spans and have fixed end terminators along with fixed drop points that accept any compatible devices added over long periods of time (network installation is often decoupled from network use).[/quote]

I'm sorry, I really don't follow. We're not likely to be compatible with any existing specs out there besides the wiring; existing termination schemes are no use to us regardless. Anything built with uCAN in mind can include the connection signalling scheme I proposed. In what situation would you be connecting a terminator to a uCAN network, but that terminator is incapable of signalling its presence by tying a single wire to GND?

[quote author="Folknology"]Please Excuse my bad drawing of a terminator:
Code: [Select]
1--[ 60 ]--
3--[ 1k ]--<>--||--GND 7,8
2--[ 60 ]--/
Placed at each end of network.

Within the network pin 3 can then be interrogated upstream and downstream to detect termination

regards
Al[/quote]

When CAN is in a recessive state (which is most of the time), the middle of the split terminator trends only very weakly to VCC/2. How will you detect that without disrupting things? I'm also not entirely certain this is a safe idea - all the cabling attached to the middle of the split termination will introduce stray capacitance, altering the elbow of the LPF created by the resistors and capacitors. It may also have other transmission line characteristics I'm not familiar with.

Are you expecting pin 3 to be passed through on each connector? If so, how will a device know if the termination is on one end or both ends? If it's not passed through by non-terminating devices, how will a device not connected directly to a terminator determine if correct termination is present?

Re: uCAN: A protocol stack for microcontroller networking

Reply #256 –
No probs not compatible spells it out clearly enough for me, everyone goes with the uCan spec.

Can you show an example circuit of how you imagine it could be supported on each device please.

I presume this also indicates uCan won't support drop cable schemes, daisy chain and switch only.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #257 –
[quote author="Folknology"]No probs not compatible spells it out clearly enough for me, everyone goes with the uCan spec.

Can you show an example circuit of how you imagine it could be supported on each device please.[/quote]

I don't have time to draw up a schematic right this minute - I'll do so later. In a nutshell, one port has pin 3 grounded and pin 6 pulled up; the other has pin 6 grounded and pin 3 pulled up. A device can use the logic level of the pulled up pin to detect if a device is attached at the other end of the cable, and act accordingly.

Quote
I presume this also indicates uCan won't support drop cable schemes, daisy chain and switch only.

CAN in general doesn't support long stubs gracefully due to echoes. Using these pins doesn't _require_ automatic termination, though - so if you wanted to cable in an (arguably) unwise fashion, you could simply terminate things manually where appropriate.

Re: uCAN: A protocol stack for microcontroller networking

Reply #258 –
Daisy chaining is nice and simple but sacrifices hot plug and exhibits single point of failure, that's where drop cables can be superior.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #259 –
[quote author="nickjohnson"][quote author="Folknology"]No probs not compatible spells it out clearly enough for me, everyone goes with the uCan spec.

Can you show an example circuit of how you imagine it could be supported on each device please.[/quote]

I don't have time to draw up a schematic right this minute - I'll do so later. In a nutshell, one port has pin 3 grounded and pin 6 pulled up; the other has pin 6 grounded and pin 3 pulled up. A device can use the logic level of the pulled up pin to detect if a device is attached at the other end of the cable, and act accordingly.
[/quote]

When you say pulled up is that to the CAN supply 12-24v being the only one guaranteed to be there by the standard?

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #260 –
[quote author="nickjohnson"]..

CAN in general doesn't support long stubs gracefully due to echoes. Using these pins doesn't _require_ automatic termination, though - so if you wanted to cable in an (arguably) unwise fashion, you could simply terminate things manually where appropriate.[/quote]

Yup drops should be kept to minimum length (they are often very stubby in practice anyhow), also I believe weak termination (tens of k) is sometimes added to reduce the amplitude of longer stub reflections.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #261 –
OK updated my design and for the upstream socket I have tied pin 6 to the uCan supply and pin 3 to ground. On the downstream connector I have tied pin 3 to uCan supply and pin 6 to ground.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #262 –
[quote author="Folknology"][quote author="nickjohnson"][quote author="Folknology"]No probs not compatible spells it out clearly enough for me, everyone goes with the uCan spec.

Can you show an example circuit of how you imagine it could be supported on each device please.[/quote]

I don't have time to draw up a schematic right this minute - I'll do so later. In a nutshell, one port has pin 3 grounded and pin 6 pulled up; the other has pin 6 grounded and pin 3 pulled up. A device can use the logic level of the pulled up pin to detect if a device is attached at the other end of the cable, and act accordingly.
[/quote]

When you say pulled up is that to the CAN supply 12-24v being the only one guaranteed to be there by the standard?[/quote]

The pullup is optional, and only a device that wants to detect whether anything is attached needs to use it. They can pull it up to any voltage they want, just so they can detect an attached device.

Re: uCAN: A protocol stack for microcontroller networking

Reply #263 –
[quote author="Folknology"]OK updated my design and for the upstream socket I have tied pin 6 to the uCan supply and pin 3 to ground. On the downstream connector I have tied pin 3 to uCan supply and pin 6 to ground.

regards
Al[/quote]

Looks good. If you're not doing detection, there's no reason to use the pullups, though - perhaps attach them to spare MCU pins so users can add detection if they want it?

Re: uCAN: A protocol stack for microcontroller networking

Reply #264 –
[quote author="nickjohnson"][quote author="Folknology"]OK updated my design and for the upstream socket I have tied pin 6 to the uCan supply and pin 3 to ground. On the downstream connector I have tied pin 3 to uCan supply and pin 6 to ground.

regards
Al[/quote]

Looks good. If you're not doing detection, there's no reason to use the pullups, though - perhaps attach them to spare MCU pins so users can add detection if they want it?[/quote]

Well I am still playing about with how to handle the detection, i.e. hardwire or pass to µc.

BTW surely every device has to be able to actively terminate given that you don't know in advance where each device is on the network, that is uCan actually mandates it unless you manually terminate?

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #265 –
[quote author="Folknology"][quote author="nickjohnson"][quote author="Folknology"]OK updated my design and for the upstream socket I have tied pin 6 to the uCan supply and pin 3 to ground. On the downstream connector I have tied pin 3 to uCan supply and pin 6 to ground.

regards
Al[/quote]

Looks good. If you're not doing detection, there's no reason to use the pullups, though - perhaps attach them to spare MCU pins so users can add detection if they want it?[/quote]

Well I am still playing about with how to handle the detection, i.e. hardwire or pass to µc.

BTW surely every device has to be able to actively terminate given that you don't know in advance where each device is on the network, that is uCan actually mandates it unless you manually terminate?[/quote]

So far I've specified that every device must be capable of terminating if the user wants to - what do you think? So far the devices I've built have a DPDT switch that you can use to enable or disable termination. An easy alternative is to have a PCB or cable that you plug in to terminate a line. And of course autodetection opens the possibility of automatic termination (though that should by no means be mandatory).

Re: uCAN: A protocol stack for microcontroller networking

Reply #266 –
I have always used plugin terminators (or the network has them), active termination does add to complexity, BOM and costs. or you could just leave it out of the specification entirely and just state that uCan requires termination at each end of the network?

However if you wish to support active termination you need to make sure that the pinout documentation for upstream (pin3) and downstream (pin6) require grounding.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #267 –
[quote author="Folknology"]I have always used plugin terminators (or the network has them), active termination does add to complexity, BOM and costs. or you could just leave it out of the specification entirely and just state that uCan requires termination at each end of the network?[/quote]

Either way, active termination will be optional; being able to detect devices on either side enables it, but doesn't require it.

Supporting onboard termination that can be manually enabled with a jumper or switch still seems like the best option, as I'm not aware of any good solutions for offboard termination - fitting a split termination network into an RJ45 would be tricky, and using a PCB would require a cable just for the terminator.

On the other hand, it may be wiser as you say to suggest but not require a specific termination strategy.

Re: uCAN: A protocol stack for microcontroller networking

Reply #268 –
Also by designating those pins for upstream downstream detection in the standard also rules out there use for other possibilities.

(In our case we may use them for power in certain situations)

Those pins could be defined as pass through network specific for example

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #269 –
[quote author="Folknology"]Also by designating those pins for upstream downstream detection in the standard also rules out there use for other possibilities.

(In our case we may use them for power in certain situations)[/quote]

5v power, or more cores for 12-24V power? To avoid issues with galvanic coupling, if one pin of a pair is going to be used for power, the other one should be too (and for the same rail!)