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

Re: uCAN: A protocol stack for microcontroller networking

Reply #90
[quote author="nickjohnson"]Good question! No, I don't have any particular devices in mind - I just think it makes sense to reuse existing standards wherever possible.[/quote]

I agree that's a good approach.  (I'd just argue that there aren't any existing standards in general use for the intended audience.)

Quote
[Ethernet]

That's a good point. I'm not sure if it's worth abandoning a standard pinout for, though. How easily available are appropriate splitters?

Well, there are splitters for running two 100Mbit Ethernet connections over one cable, but I don't know if using those would be a good idea.  Of course, if one wanted to go that route, we should do the exact opposite of what I said previously, and standardize on the two Ethernet pairs, so that there is cheap adapters available.  On the other hand, it wouldn't be that hard or expensive building your own either.

[quote author="Folknology"]Unfortunately POE (and for that matter Ethernet RJ45) and CAN RJ45 based pinouts are incompatible from a power POV and could result in shorting[/quote]

I don't know about the CAN RJ45 pinout you mention since I want to go with something custom, but according to Wikipedia, PoE can run on the same cable pairs Ethernet uses for signalling, simultaneously.  I don't see why we couldn't duplicate that.  (I was thinking straight up 48V without the complicated handshake though.)

Re: uCAN: A protocol stack for microcontroller networking

Reply #91
Quote
I don't know about the CAN RJ45 pinout you mention since I want to go with something custom, but according to Wikipedia, PoE can run on the same cable pairs Ethernet uses for signalling, simultaneously. I don't see why we couldn't duplicate that. (I was thinking straight up 48V without the complicated handshake though.)

We have done something like this with our RS485 full duplex segments where it is flexible enough to allow it (It doesn't state anything above the differential signalling), however CAN is much more specific in its layers, pinouts  and connectivity.

P.S. Even doing this we settled on Passive Mode B spares rather than simultaneous power/signalling as that gets costly in all dimensions

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #92
There is another alternative BTW, something which we are currently exploring (early days). Rather than use a splitter what we are looking at is bridging over Ethernet. Here we take the CAN packets and then place them into Ethernet frames using Ethernet AVB standards, this also allows us to do segmentation, aggregation and other useful things over existing network infrastructure and standards. This is more likely to work than trying to crow bar physical CANBus into an incompatible working Ethernet structure IMHO.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #93
Have you guys looked at VSCP [1]...? It's supposed to mean "very simple control protocol", and at a cursory glance it's all made of candy, rainbows and unicorns (simple CAN-based multi-carrier multi-uc firmware-updatable open-source protocol / firmware with multi-os tool support blah blah Raspberry Pi BeagleBone Black blah blah blah). I'm not particularly endorsing it (although it seems to be rather old I have just found it, so I really don't know all that much about it), I was just wondering if you were aware of it and whether it fitted your envisioned target use. I wouldn't expect it to carry files and somesuch over it though...

[1] - http://vscp.org/

Re: uCAN: A protocol stack for microcontroller networking

Reply #94
Hi, I remember to see this logo few years ago but actually not see nothing relevant. But that was long time ago.

I need to read the current specification, may be very sefull or becomes a start point to something else, but at first sight:

* I usually distrust about the same protocol in very different transport. Each transport has their advantages and his drawbacks. A lot of this was written at beginning of this post. It´s hard to believe that it´s efficient a transport protocol that works at same time in RS232 and ethernet. Off course, always it´s use full a bridge to transport the signal to a long distance or to a mobile device, because in rare certain circumstances port the same protocol in different transport it´s use full.  VCSP may have a point here.

*  I prefer allways to take advantage of a STACK hardware. I can do Ethernet bit banging but it´s a nonsense out of an academic campus. If VCSP uses CAN Stack and then work with all of this advantages (and drawbacks sadly) but, for example, port the same data stream to a RS485 network and use all the pros and cons, then would be a MARVELOUS SOLUTION!

In resume, if Folknology can implement their devices in RS485 network with all of the advantages that he write few days ago using VCSP as compatible data transport, and I can use CAN Stack with filtering, addressing and noise immunity to manage my sensors and we can put a ""silly bridge"" that translates from one electric wire to other to join both networks then I´m IN without doubt!. :-)

Re: uCAN: A protocol stack for microcontroller networking

Reply #95
[quote author="EasyRider"]Have you guys looked at VSCP [1]...? It's supposed to mean "very simple control protocol", and at a cursory glance it's all made of candy, rainbows and unicorns (simple CAN-based multi-carrier multi-uc firmware-updatable open-source protocol / firmware with multi-os tool support blah blah Raspberry Pi BeagleBone Black blah blah blah). I'm not particularly endorsing it (although it seems to be rather old I have just found it, so I really don't know all that much about it), I was just wondering if you were aware of it and whether it fitted your envisioned target use. I wouldn't expect it to carry files and somesuch over it though...

[1] - http://vscp.org/[/quote]

Cool I love I love candy, unicorns and rainbows, will take a look ;-)

Re: uCAN: A protocol stack for microcontroller networking

Reply #96
[quote author="Folknology"]Rather than use a splitter what we are looking at is bridging over Ethernet. Here we take the CAN packets and then place them into Ethernet frames using Ethernet AVB standards, this also allows us to do segmentation, aggregation and other useful things over existing network infrastructure and standards.[/quote]

Sounds cool.  The tradeoff, I assume, is that you'll need special hardware (like "routers") to do the bridging - are you using some off the shelf thing or building your own?

It does seem like a good way to bridge two or more physically separate CAN networks - once on Ethernet frames, it should be able to run over existing cables and switches - but not really something one would want to carry the CAN networks themselves.  Right?

 

Re: uCAN: A protocol stack for microcontroller networking

Reply #97
I think that if you need only a couple of CAN to Ethernet bridge it´s better buy something done, if you need more then it´s better make the entire solution. It´s cheaper and more control on changes and features.

Re: uCAN: A protocol stack for microcontroller networking

Reply #98
OK I have taken a quick look VSCP (this name also rings a bell with me from some time ago) it is very interesting indeed and represents a nice level of abstraction. I also like that it is event based along with publish and subscribe type abstractions which is pretty much the way I would have gone. Will continue to kick the tyres a little more and peruse under the bonnet.

Thanks for pointing it out EasyRider

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #99
Well a bit more VSCP tyre kicking, here are a few thoughts:

1) I like the abstractions, events and publish & subscribe
2) The node register feature is similar to many CAN based device layers, having them only 8 bit is a PITA however.
3) I like the Zone, subzone combination and it's one to many like controls and filters.
4) It handy that there is a TCP/IP version and class II devices but it makes me wonder if it has all gone to far.
5) There is an Ethernet frame version (I haven't looked at this yet)
6) There is an awful lot of code covering many languages and several platforms this is an advantage and disadvantage both.

Overall (although comprehensive) it looks like it is rather top-heavy, compared to our simple aims here.
Most of the lower level µC code is very old, difficult to read and poorly documented.
It appears to me that the project has become a somewhat attracted to 'IoT' magnetic hyperbole and the focus appears to be more at this level looking at the commits.

These are still just initial thoughts, I would love to know what everyone else thinks?

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #100
I´m read this morning part of the specification, seems to good to be true. I´m continue this night and not read the software section, but I think that eventually we need to "recode" the clients and perhaps reuse as is the PC side (if it´s necessary) because all have a PC and resources never are a bottleneck.  I can´t see any more but if it´s not the goal that we need it´s a very complete source of experience.

Re: uCAN: A protocol stack for microcontroller networking

Reply #101
[quote author="magetoo"]Well, there are splitters for running two 100Mbit Ethernet connections over one cable, but I don't know if using those would be a good idea.  Of course, if one wanted to go that route, we should do the exact opposite of what I said previously, and standardize on the two Ethernet pairs, so that there is cheap adapters available.  On the other hand, it wouldn't be that hard or expensive building your own either.[/quote]

That doesn't seem unreasonable, actually. Being able to reuse existing cabling is good.

[quote author="magetoo"]I don't know about the CAN RJ45 pinout you mention since I want to go with something custom, but according to Wikipedia, PoE can run on the same cable pairs Ethernet uses for signalling, simultaneously.  I don't see why we couldn't duplicate that.  (I was thinking straight up 48V without the complicated handshake though.)[/quote]

We can't really do that because of the way CAN works - there's no obvious way to piggyback power on the data pair, especially with it having 60 ohm termination between + and -!

[quote author="Folknology"]There is another alternative BTW, something which we are currently exploring (early days). Rather than use a splitter what we are looking at is bridging over Ethernet. Here we take the CAN packets and then place them into Ethernet frames using Ethernet AVB standards, this also allows us to do segmentation, aggregation and other useful things over existing network infrastructure and standards.[/quote]

This requires an ethernet PHY, though, and substantially increases the cost and complexity.

[quote author="Folknology"]This is more likely to work than trying to crow bar physical CANBus into an incompatible working Ethernet structure IMHO.[/quote]

It's important to realise that buildings aren't wired for ethernet - they're wired with RJ45 and CAT6, which terminates at a patch panel. You can patch whatever you want into it - typically, Ethernet and POTS.

[quote author="EasyRider"]Have you guys looked at VSCP [1]...? It's supposed to mean "very simple control protocol", and at a cursory glance it's all made of candy, rainbows and unicorns (simple CAN-based multi-carrier multi-uc firmware-updatable open-source protocol / firmware with multi-os tool support blah blah Raspberry Pi BeagleBone Black blah blah blah). I'm not particularly endorsing it (although it seems to be rather old I have just found it, so I really don't know all that much about it), I was just wondering if you were aware of it and whether it fitted your envisioned target use. I wouldn't expect it to carry files and somesuch over it though...[/quote]

I had looked at it before, but not in much detail. It seems like it might be usable for our purposes, but I'm a bit worried about the "kitchen sink" nature of all the sub-protocols defined. It'd be difficult to provide a simple API interface for users to work with unless the set of supported protocols was very limited (to, eg, register access).

Re: uCAN: A protocol stack for microcontroller networking

Reply #102
Quote
It's important to realise that buildings aren't wired for Ethernet - they're wired with RJ45 and CAT6, which terminates at a patch panel. You can patch whatever you want into it - typically, Ethernet and POTS.

Unfortunately buildings are wired too standards, in this case standards like T568A/B for carrying Ethernet over Cat5/6 these are not friendly to CAN, I have also yet to see a pinout/wiring that would work with these installed schemes without breaking something.

Also remember that these are based around star topologies rather than a linear bus and unless you are going to design and install new custom CAN/Ethernet switches (and splitting the sockets at user end) I cannot see how this could be cost effective or efficient, in short I am not sure what purpose this would serve.

regards
Al

Re: uCAN: A protocol stack for microcontroller networking

Reply #103
Quote
Also remember that these are based around star topologies rather than a linear bus

Exactly, a star topology on CAN needs an active CAN transceiver in each port as happens in ethernet switch. this can be cheap for some projects or very expensive, it depends of budget and scenario.

This problem it´s util for me, in other post I write about our test in stub length in linear bus. Maybe an active repeater can be explored?

http://www.ems-wuensche.com/about-can/c ... ample.html

And this two posible solutions that I found in forums. I confess that first option sound to good to be true and is simple to explore. I need to finish other project and then start t test a "naif repeater" like this :-)

http://www.microchip.com/forums/downloa ... e=0;587934

http://www.onsemi.com/pub_link/Collater ... 2700-D.PDF

In general I think that it´s necessary put an active node with a microcontroller repeating the signals from one network to other like this http://www.ems-wuensche.com/about-can/c ... eater.html, but perhaps KISS apply!

Re: uCAN: A protocol stack for microcontroller networking

Reply #104
Some interesting links there Tarloth thanks.

CAN is only a candidate on specific parts of our networks (the leaves normally), restricting them to manageable runs. We use mixed segments linked via full duplex interconnects (rather than repeaters), these can be on-board, inter-board or external 485/422 and Ethernet. In other words we try to design our networks intelligently using a mixture of topologies/technologies to meet particular requirements. At the same time we are always seeking to reduce the variety of network development by bridging or aggregating where possible, i.e. carrying data packets from one segment over another (normally higher bandwidth).

regards
Al