Dangerous Prototypes

In development => Project development, ideas, and suggestions => Topic started by: nickjohnson on October 08, 2013, 01:22:46 pm

Title: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 08, 2013, 01:22:46 pm
I'm working on an idea that I've been pondering over for a while: a simple, low cost option for networking low power microcontrollers for hobbyist projects, art installations, interactive exhibits, hackspaces, etc etc. There are a few options around, but nobody's specified something to build an ecosystem around; radio is widely varied and problematic in many installations, and Ethernet is too expensive and high-overhead for small embedded projects.

Rather than reinvent the wheel, the plan is to use existing standards to specify a stack - physical, electrical, protocol and API - that multiple makers can produce compatible products for. Goals are:

 - Low cost and low overhead
 - Reuse existing standards and implementations as much as possible
 - Reuse existing cabling and infrastructure as much as possible
 - Support varied devices (architecture, capabilities etc)
 - Support cable lengths from a couple of meters up to entire building installations
 - Easy to use for people with limited electronics and wiring experience - plug, program, and play.

With that in mind, the current protocol stack looks like this:

 - UTP cables with RJ45 connectors, allowing reuse of standard Ethernet cables and wiring installations
 - Power carried over a spare pair at 9-24V DC
 - CAN bus physical and transport level protocol
 - CANopen application level protocol
 - Standardized, simplified APIs for carrying out common messaging and automation tasks (still to be defined)

I'd really like this to become a community project, with multiple people directing the evolution and standardization of the stack, and designing boards around it.

Tentatively planned initial implementations include:

 - A Raspberry Pi expansion board
 - An Arduino shield
 - A power injector (DC barrel jack -> RJ45)
 - An Arduino clone with onboard uCAN
 - A development board based on the LPC11C24 (built in CAN transceiver, so cheap and simple)
 - A CAN bus hub

I'd love to hear feedback and opinions on the project, especially if you're interested in pitching in to the standardization and design effort yourself.
Title: RPi expansion
Post by: nickjohnson on October 08, 2013, 01:25:02 pm
Here's one of the first PCBs: a Raspberry Pi expansion board.

(http://https://raw.github.com/arachnidlabs/uCAN/master/rpi/rpi-layout-top.png)

(http://https://raw.github.com/arachnidlabs/uCAN/master/rpi/rpi-schematic.png)

The board uses the MCP2515 CAN interface and MCP2551 transceiver. There's a linux kernel module for the 2515, so support is fairly straightforward, and it can be brought up as a network interface.

The board also includes a 5V 1A switching converter, which powers the RPi from the CAN bus.
Title: Arduino shield
Post by: nickjohnson on October 08, 2013, 01:26:57 pm
Another of the initial designs: An Arduino uCAN shield.

(http://https://raw.github.com/arachnidlabs/uCAN/master/shield/shield-layout-top.png) (http://https://raw.github.com/arachnidlabs/uCAN/master/shield/shield-layout-top.png)

(http://https://raw.github.com/arachnidlabs/uCAN/master/shield/shield-schematic.png) (http://https://raw.github.com/arachnidlabs/uCAN/master/shield/shield-schematic.png)

As with the RPi shield, the MCP2515 and MCP2551 are used, along with a 5V 1A switching regulator to supply the Arduino and any attached shields with power.

This board should function at 5v and 3.3v (autoselected where an IOREF pin is available), on a Duemilanove, Uno, Uno R3, Due and Leonardo, and clones.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 08, 2013, 05:32:17 pm
I think it´s perfect! I´m going to develop something similar in ST ARM ucontrollers to connect several greenhouses and use LIN to connect to sensors and I´d think that nobody´s it´s interested in do something like this. I can collaborate in this great idea if you like!

Thanks
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Destate9 on October 09, 2013, 05:50:05 pm
The Ohio State University Formula Car Team used MCP2551 CAN transceivers all last year, and we've had a lot problems with them.  I know you're probably not going to use these in an automotive setting like we did, but we found they are extremely sensitive to small transients.  We probably went through 20 chips last year, spent many hours on the phone with Microchip, and reached the conclusion that they are just very sensitive ICs.  Microchip, however said that they were coming out with a new IC mid-2013 to replace the MCP2551, the MCP2561/2.  I HIGHLY recommend you get yourself a MCP2562 instead of the MCP2551, because a good chunk of my life for the past year has been wasted due to grief from the sensitive MCP2551.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 09, 2013, 05:57:21 pm
[quote author="Destate9"]The Ohio State University Formula Car Team used MCP2551 CAN transceivers all last year, and we've had a lot problems with them.  I know you're probably not going to use these in an automotive setting like we did, but we found they are extremely sensitive to small transients.  We probably went through 20 chips last year, spent many hours on the phone with Microchip, and reached the conclusion that they are just very sensitive ICs.  Microchip, however said that they were coming out with a new IC mid-2013 to replace the MCP2551, the MCP2561/2.  I HIGHLY recommend you get yourself a MCP2562 instead of the MCP2551, because a good chunk of my life for the past year has been wasted due to grief from the sensitive MCP2551.[/quote]

Excellent point, and thanks for the feedback! Someone at Microchip already pointed this out, and I've modified the designs to use the MCP2562 - which even has a level shifter built in, so let me ditch the resistor divider.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 09, 2013, 07:39:54 pm
I heard about Microchip CAN problems but nobody told exactly ""when"" until now. I use TJA1051T and SN65HVD233 without problems. Most of transceivers that I see have the same pinout or are very close to NXP parts.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Niklas on October 09, 2013, 10:11:14 pm
I have used the MCP2551 in various automotive test tools since it was released about 10 years ago. So far only one circuit out of 200 has been replaced, which is acceptable as most of the cars the units are used in are early prototypes. However, there is one big difference between my schematics and the one posted for this shield and that is the filtering section.

Low capacitance transient suppressors were not available back in 2004 so I used anti-parallelled diodes, BAV199, in series with varistors (11 Vrms SIOV in 0603 package). One diode+varistor combination each on CANL and CANH to GND. The SIOVs seems to be discontinued now but they can be replaced with some low capacitance TVS.

Between the over voltage filter and the MCP2551 a common mode choke and Y-capacitors (22pF, >= 100 V, C0G/NP0) are fitted. One cap one each side of the choke and down to GND, configured just like a standard line filter for 115V or 230 V mains. The choke is made for CAN bus filtering and must be able to handle some current, 200-300 mA or so. Try not to use vias between the connectors and the CAN tranceiver. If you must, then use at least two to handle the current.

Bus termination was often done with a 120 ohms resistor between CANL and CANH, just as in the posted schematics. In many newer designs you will find two resistors in series with a capacitor decoupling from the midpoint down to GND. Sometimes you can not use 120 ohms when the unit is placed on a stub and not on the end. 2x1k in 1206 packages and 4.7 nF was on a board I checked some time ago. The higher resistance will not affect the main termination resistance much but still give some effect. The capacitor will drain high frequency noise.

Edit: I tried to add a few links to app notes about filtering but that failed as I am a new user. Google "can bus common mode filter" (TI slla271.pdf and Microchip en528477.pdf) and "can bus common mode filter nxp" (AH1014, section 8 about EMC)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 09, 2013, 10:53:24 pm
Yes, I not check the diagrams because I only interested in the software because I have the hardware developed. I use a similar circuit that you describe but instead of antiparallel diodes I use PESD1CAN and no choke, maybe would be good that I add it in next board!. THANKS
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: banjaxed on October 09, 2013, 11:37:36 pm
My 2c:

* What baud rate will be used, and does CANopen allow for automatic baud rate identification?
I'm familiar with CAN, but not CANopen. In the past, with other application layers, I have found that the fact that CAN frames are limited to 8 bytes of data means that your net throughput will be very low, even at 500kb/s. It all depends on what type of data you want to send, but worth bearing in mind.

* Termination is critical. I'm guessing from your schematic that you intend for the user to add a jumper to the two nodes on the end of the 'bus', and remove the jumpers on all the nodes that are on 'stubs'? My experience was with J1939, not CANopen. In J1939, there are several possible physical layers, but they all trade-off baud-rate, bus length, stub length, and maximum number of nodes.

* I've never heard of "sensitive" CAN transceivers. Quite the opposite. A well-designed CAN physical layer should be practically bullet-proof.

* Have you looked at SocketCAN?

In summary, for applications requiring a rock-solid but slow network with a little manual intervention required, I think CAN is a great choice.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Niklas on October 10, 2013, 12:28:38 am
The PESD1CAN is probably a good choice as a replacement for the antiparallel diodes in series with varistors. Common mode chokes are found in a majority of the ECUs in cars. In small volumes, their price might scare of many hobbyists but for robust applications they are a must. You can also add a buffering cap with a couple of uFs close to the transceiver in the next revision of the board.

Other important things are:
- A stable crystal oscillator to get the bit timing correct
- Proper setup in the CAN controller of the different bit timing parts
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 10, 2013, 02:34:27 am
Niklas, yes I have no problem because I use out of an automotive environment, in a relative noissless space, but I follow your recommendation for a better PCB. Thanks!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Niklas on October 10, 2013, 10:52:38 am
Some screenshots from a prototype ECM as a reference. The transceiver is not the MCP2551 but a 3V pin compatible part from TI. The termination resistors were changed to 1k instead of 60 ohms.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 10, 2013, 10:59:07 am
Thanks for all the feedback! I've changed the termination to split termination enabled or disabled with an SMT switch, and thickened up the power traces on both boards. I'll look into using a TVS as well - improving robustness never hurts.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 10, 2013, 11:01:38 am
[quote author="banjaxed"]My 2c:

* What baud rate will be used, and does CANopen allow for automatic baud rate identification?
I'm familiar with CAN, but not CANopen. In the past, with other application layers, I have found that the fact that CAN frames are limited to 8 bytes of data means that your net throughput will be very low, even at 500kb/s. It all depends on what type of data you want to send, but worth bearing in mind.[/quote]

This is a good point. CAN is indeed limited to 8 bytes. I'm not that familiar with CANOpen yet; it simply seemed like a reasonable higher-level protocol choice, as I'm not keen to reinvent the wheel. I do know that it doesn't specify lower level details, so no autobaud - a default baud rate will need to be specified as part of the stack.

Quote
* Termination is critical. I'm guessing from your schematic that you intend for the user to add a jumper to the two nodes on the end of the 'bus', and remove the jumpers on all the nodes that are on 'stubs'? My experience was with J1939, not CANopen. In J1939, there are several possible physical layers, but they all trade-off baud-rate, bus length, stub length, and maximum number of nodes.

That's the plan, yes. I've just switched to split termination with a switch, but people will still have to daisy chain and set termination where appropriate.

Quote
* Have you looked at SocketCAN?

In summary, for applications requiring a rock-solid but slow network with a little manual intervention required, I think CAN is a great choice.

I have, and that's the plan for the RPi shield.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: EasyRider on October 10, 2013, 03:14:26 pm
At work, we've used CAN in building- (and sometimes short inter-building-) sized runs / networks of up to a hundred nodes or so, using the same MCP2551 chip, for about a decade now. While our experience is still severely limited due to very modest volumes (still a lot larger than an average hobbyst might see though), I can confirm having occasional issues with the transceivers burning out for unknown reasons (worse, subsequently shunting the bus). Due to rarity of such events we never could pinpoint the cause, nor reproduce the results (event though at some point we were purposefully jamming a long cable run with anything we could think of, including arc welding right next to it - we didn't have any Tesla coils to test, sorry). Admittedly, the line is a simple twisted pair and the termination a simple 120R resistor at each end. Recently we tried protecting the transceivers with modern low-capacitance TVSs, but one of the new devices also failed the same way soon after, on a short intra-cabinet network no less; so we're really out of ideas and not particularly a fan of the 2551. Hopefully the new 2561/2 will be better.

Other than that, the arrangement worked beautifully all along - because of the run length we only use 125K baud though (still quite sufficient with our rather sparse traffic). I have to say though that while at the time we did look into the existing CAN frameworks, we found all of them a massive overkill for passing around various sensor / actuator data in a homogenous network of MCUs with quite limited resources, so we just went with our own arbitrary low-level CAN ID-based addressing system instead...
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 10, 2013, 03:21:40 pm
[quote author="EasyRider"]At work, we've used CAN in building- (and sometimes short inter-building-) sized runs / networks of up to a hundred nodes or so, using the same MCP2551 chip, for about a decade now. While our experience is still severely limited due to very modest volumes (still a lot larger than an average hobbyst might see though), I can confirm having occasional issues with the transceivers burning out for unknown reasons (worse, subsequently shunting the bus). Due to rarity of such events we never could pinpoint the cause, nor reproduce the results (event though at some point we were purposefully jamming a long cable run with anything we could think of, including arc welding right next to it - we didn't have any Tesla coils to test, sorry). Admittedly, the line is a simple twisted pair and the termination a simple 120R resistor at each end. Recently we tried protecting the transceivers with modern low-capacitance TVSs, but one of the new devices also failed the same way soon after, on a short intra-cabinet network no less; so we're really out of ideas and not particularly a fan of the 2551. Hopefully the new 2561/2 will be better.[/quote]

Thanks for the real-world feedback on something very close to the sort of deployment I'm considering.

Quote
Other than that, the arrangement worked beautifully all along - because of the run length we only use 125K baud though (still quite sufficient with our rather sparse traffic). I have to say though that while at the time we did look into the existing CAN frameworks, we found all of them a massive overkill for passing around various sensor / actuator data in a homogenous network of MCUs with quite limited resources, so we just went with our own arbitrary low-level CAN ID-based addressing system instead...

This is something I've yet to address - feedback would be appreciated. I really want to offer simple and consistent APIs across all platforms, and using a system people are already familiar with would be ideal. I tentatively selected CANOpen as a candidate because it's baked right in to some NXP chips, but I'm entirely flexible on this.

I suspect ideal basic functionality would be:
 - Short datagrams (like UDP)
 - Streams (like TCP)
 - RPC-type invocations
 - Some way to discover if a given address is present (enabling eventual implementation of a switch)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 10, 2013, 10:09:49 pm
I've updated the designs with the PESD1CAN TVS, as well as silkscreen improvements.

Here's the power injector PCB; very simple:

(http://https://github.com/arachnidlabs/uCAN/blob/master/injector/injector-layout-top.png?raw=true) (http://https://github.com/arachnidlabs/uCAN/blob/master/injector/injector-layout-top.png)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: EasyRider on October 11, 2013, 03:41:17 pm
[quote author="nickjohnson"][quote author="EasyRider"]Other than that, the arrangement worked beautifully all along - because of the run length we only use 125K baud though (still quite sufficient with our rather sparse traffic). I have to say though that while at the time we did look into the existing CAN frameworks, we found all of them a massive overkill for passing around various sensor / actuator data in a homogenous network of MCUs with quite limited resources, so we just went with our own arbitrary low-level CAN ID-based addressing system instead...[/quote]

This is something I've yet to address - feedback would be appreciated. I really want to offer simple and consistent APIs across all platforms, and using a system people are already familiar with would be ideal. I tentatively selected CANOpen as a candidate because it's baked right in to some NXP chips, but I'm entirely flexible on this.

I suspect ideal basic functionality would be:
 - Short datagrams (like UDP)
 - Streams (like TCP)
 - RPC-type invocations
 - Some way to discover if a given address is present (enabling eventual implementation of a switch)[/quote]

Unfortunately I can't much comment on specific aspects of CANOpen considering we never used it ourselves. I'm sure in an open,  varied environment the widely known and used CANOpen would make a lot more sense than in our closed, rigidly-defined environment.

However, I can outline what we had - we simply took the CAN ID and divided it up into a few fields like priority, type (get/set/reply), address (a unique one per device), and "variable number" (defining what specific data in what specific format the following data bytes were supposed to mean). No messages longer than 8 bytes (yet we do firmware update over this - only in tiny chunks, each including the address they're supposed to be written to), no layer for guaranteed delivery (if you didn't get a reply, you knew what happened) etc.

A few universally present "variables" provided switching to/from bootloader, "ping" functionality (including unrequested periodic ping "replies" if desired, as a heartbeat), error counter stats, address assignment (based on an internal unique ID), node identification (command to flash the mandatory bicolor LED in a specific manner) and so on. Every single "variable" message was rigorously checked individually for presence and range of all its elements, etc - any invalid messages were promptly rejected by nodes. Discovery, if desired, was possible by pinging the broadcast address (a specific one all nodes were listening to) then querying all responding nodes about their "class", a single variable which defined unequivocally what the node was/did and which specific "variables" it was supposed to support - that's about it, really; we never needed more.

I'll try to respond to any specific question about CAN as best as I can, but unfortunately I can't tell you much about common protocols currently in use...
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 13, 2013, 08:23:02 pm
One thing to consider is cost for micro-controller applications both financial and even power consumption. CAN tends to add quite a lot of cost compared to say RS485/422 which can be implemented very economically. Also many modern micro-controllers have hardware 9 bit uart support for these standards making development easier and in many cases allowing power down (using wakeups/interrupts). Also RS485/422 can normally work across larger distances than CAN which can be important in some cases. Just some points worth considering.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 13, 2013, 08:35:44 pm
[quote author="Folknology"]One thing to consider is cost for micro-controller applications both financial and even power consumption. CAN tends to add quite a lot of cost compared to say RS485/422 which can be implemented very economically. Also many modern micro-controllers have hardware 9 bit uart support for these standards making development easier and in many cases allowing power down (using wakeups/interrupts). Also RS485/422 can normally work across larger distances than CAN which can be important in some cases. Just some points worth considering.

regards
Al[/quote]

I've found the reverse - MCP2515 + MCP2562 only costs $2-$3, and some microcontrollers have CAN support built-in. RS-485 transceivers aren't any cheaper, and no microcontrollers have them built in to the best of my knowledge.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 13, 2013, 08:44:14 pm
RS485/422 chips like ISL83490IBZ can be had for about $0.60 and can be used with $0.50 µCs which lowers the entry barrier somewhat

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 13, 2013, 09:05:01 pm
[quote author="Folknology"]RS485/422 chips like ISL83490IBZ can be had for about $0.60 and can be used with $0.50 µCs which lowers the entry barrier somewhat

regards
Al[/quote]

Fair point; somewhat academic now, as I've already started down the CAN bus route. :)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 13, 2013, 09:11:59 pm
No probs just thought I would flag it up as it is something we discovered building various networks. I am not knocking CAN BTW it has its own advantages just not cost/overhead/power (at top of your initial list) :-)

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 14, 2013, 06:52:48 am
I not sure that RS485 can comunicate across larger distances than CAN.

CAN it´s a semi complete protocol involving more layers than RS485 and it´s not necessary to create or specify a protocol to arbitry errors and bounces that ever reduce bandwith or reduce the range with electrical restrictions.

At reasonably speeds for a microcontroller that need to comunicate some bytes of data CAN permit 2KM internode. Off course nobody that needs to send multimedia content think in use CAN, it´s only for sensor an actuator data. I see RS485 with 500 meters between master an slave, I hear of a node 1 Km away working and think that it´s possible to implement something similar to 2Km but I´m sure than no better than CAN.

Modern vehicles uses CAN (or their realtime cousin) for life save communication, even modern Airbus uses a modified CAN. In industrial applications CAN is displacing other well know and probed protocols like smbus or profibus and I believe that is replacing this old protocols (some based in RS485). In all the cases it´s necessary a confident network with simplified wired.

Cost point it´s relevant but not to me. I´m not going to produce thousands or millions of devices, at better situations perhaps a hundred and one plus dollar it´s not a matter. Just for this point I migrate all of my projects from 8 bits to 32 bits. I add perhaps 0.5-2 dollars per board but I have a freedom and power that it´s impossible in 8 bits. All of the microcontrollers that I use in the last three years have almost one CAN port and in the case that I need a reduced or cheap but realiable communication I use LIN for long wires or directly I2C for "short" wires. Even more, I´m not sure that a proper RS485 transceiver cost less than a CAN transceiver.

But, I read long time ago that exit a CAN protocol mounted over a electrical RS485 network, perhaps it´s a good option to somebody that not like CAN, but like to use this development.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 14, 2013, 11:10:28 am
I really like CAN's built in arbitration and guaranteed response times as this has to be cooked up oneself with RS485 (It's up to you what you do on top), But I don't see how you are going to run UDP and TCP like sockets/streams given CAN's 8 byte restrictions and packet expectations, I would have thought that RS485 with your own stack would be far less restrictive for these type of goals. When you go down the CAN route you tend to follow the standard CAN abstracts such as CanOpen etc which have a rather different representation/operation to those you have indicated a preference for (UDP/Sockets/Streams). Often you can layer networks by joining smaller CAN segments using RS485 or Ethernet, this enables one too build bigger networks but still benefit from the arbitration and response times on the local segments. however if you want UDP all of the way through then RS485 segments and ethernet/TCP/IP bridging might be a better route. I guess it depends on how important UDP/Sockets/Streams are to your requirements or if your happy going down the CAN abstracts route, to me you seem to be indicating you have started down the hardware design route with CAN and will continue to do so, therefore it's as you say academic.

Either way I will be interested to see how it all pans out as it's an interesting coms project.

P.S. just for reference here is an RS485 uLan (http://http://ulan.sourceforge.net/index.php?page=3) example which you might find interesting ideas wise if you do choose to roll your own.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 14, 2013, 11:28:13 am
[quote author="Folknology"]I really like CAN's built in arbitration and guaranteed response times as this has to be cooked up oneself with RS485 (It's up to you what you do on top), But I don't see how you are going to run UDP and TCP like sockets/streams given CAN's 8 byte restrictions and packet expectations, I would have thought that RS485 with your own stack would be far less restrictive for these type of goals.[/quote]

This doesn't seem too difficult. Datagrams are what you already have, albeit with a limit of 8 bytes of payload; streams can be accomplished with a recipient and port identifier in the address field; there's probably no need for TCP's 3-way handshake.

Quote
When you go down the CAN route you tend to follow the standard CAN abstracts such as CanOpen etc which have a rather different representation/operation to those you have indicated a preference for (UDP/Sockets/Streams). Often you can layer networks by joining smaller CAN segments using RS485 or Ethernet, this enables one too build bigger networks but still benefit from the arbitration and response times on the local segments. however if you want UDP all of the way through then RS485 segments and ethernet/TCP/IP bridging might be a better route. I guess it depends on how important UDP/Sockets/Streams are to your requirements or if your happy going down the CAN abstracts route, to me you seem to be indicating you have started down the hardware design route with CAN and will continue to do so, therefore it's as you say academic.

I'm not actually suggesting UDP - I was using it as an example of a datagram protocol.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 14, 2013, 12:29:31 pm
I would just add that datagrams by their very nature are designed and optimised to make maximum network data transfers, by having a a large data to frame ratio, normally via arbitrary length 'grams', they also do not guarantee reception or delivery, they are shaped for data density rather than integrity. This is almost the reciprocal of the CAN 'message' or 'dataframe' which was designed to prioritise data integrity and deterministic operation. If one expects the majority of the network traffic to be shaped like datagrams as opposed to deterministic dataframes you might find that your network does not match your design expectations. Basically CAN networks do have a shape and one needs to go with the flow of that shape, if you wanted something different, you would be better rolling your own, or building on something that already met the requirements.

Remember if you let the network choose you rather than the other way around the network will win out in the long run, a good requirements discussion may be a better place to start than a single network standard unless you want your network to determine your requirements.

Whatever you choose will be your legacy, choose carefully...

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 14, 2013, 12:52:36 pm
[quote author="Folknology"]I would just add that datagrams by their very nature are designed and optimised to make maximum network data transfers, by having a a large data to frame ratio, normally via arbitrary length 'grams', they also do not guarantee reception or delivery, they are shaped for data density rather than integrity. This is almost the reciprocal of the CAN 'message' or 'dataframe' which was designed to prioritise data integrity and deterministic operation. If one expects the majority of the network traffic to be shaped like datagrams as opposed to deterministic dataframes you might find that your network does not match your design expectations. Basically CAN networks do have a shape and one needs to go with the flow of that shape, if you wanted something different, you would be better rolling your own, or building on something that already met the requirements.

Remember if you let the network choose you rather than the other way around the network will win out in the long run, a good requirements discussion may be a better place to start than a single network standard unless you want your network to determine your requirements.

Whatever you choose will be your legacy, choose carefully...

regards
Al[/quote]

I think this is a disagreement of nomenclature more than anything else. UDP datagrams have the properties you describe, but I don't think that's a fundamental property of anything called a datagram.

My intention was simply to provide for low-overhead packet-based data transmission between nodes as a convenient option.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 14, 2013, 01:33:26 pm
Quote
I think this is a disagreement of nomenclature more than anything else. UDP datagrams have the properties you describe, but I don't think that's a fundamental property of anything called a datagram.

Well all of the datagrams I am familiar with UDP (IP), DDP (Appletalk), IDP (XNS) as wells as RS485 datagram implementations all exhibit features of high data to frame ratios and non guaranteed reliability as opposed to integrity and determinism.

Quote
My intention was simply to provide for low-overhead packet-based data transmission between nodes as a convenient option.
Does CAN provide the best solution to this requirement for you?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 14, 2013, 01:40:45 pm
[quote author="Folknology"]
Quote
I think this is a disagreement of nomenclature more than anything else. UDP datagrams have the properties you describe, but I don't think that's a fundamental property of anything called a datagram.

Well all of the datagrams I am familiar with UDP (IP), DDP (Appletalk), IDP (XNS) as wells as RS485 datagram implementations all exhibit features of high data to frame ratios and non guaranteed reliability as opposed to integrity and determinism.

Quote
My intention was simply to provide for low-overhead packet-based data transmission between nodes as a convenient option.
Does CAN provide the best solution to this requirement for you?

regards
Al[/quote]

My desire is simply to offer basic, familiar abstractions to people using the system. Obviously, thus far the software layer is ill-defined, but obvious abstractions seem to be:

 - Datagram based point-to-point or broadcast messaging
 - Stream based point-to-point messaging
 - RPCs

All of these seem tractable over CAN.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 14, 2013, 01:59:58 pm
I agree all of these are tractable over CAN but should also just point out some likely speedbumps :

1) Datagrams - I have already covered the impedance mismatch between datagrams and CAN's dataframes, I would go with native messages instead on a CAN network, it excells at this.
2) Stream based point to point messaging - will likely prove difficult and very inefficient over CAN, due to frame overheads, you also have to be careful you don't end up flooding the network and impeding the single frame messages when imposing these network costs (scaling problems).
3) RPCs - Your remote procedure calls will either suffer severely limited argument passing or impose multi-packet inefficiencies on the transport significantly reducing RPC response times (with your own design these could be better matched and optimised)

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 14, 2013, 02:34:56 pm
If you still really want to go with CAN take a long look at CanOpen which provides an excellent set of abstractions and good impedance match with the underlying CANBus, it's been developed over a long period and has been heavily tested and deployed, it also has a great deal of community support. If you like what you see go with it, if you don't take a look at other CANBus abstraction layers, however I think it is unlikely you will find the 'familiar abstractions' you appear to desire most. If those 'familiar abstractions' are a priority then you may benefit from revisiting your requirements and tackle the network choice with those as the basis for the requirements, there are plenty of choices out there and you could even think up your own if that's your thing.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 14, 2013, 04:21:11 pm
[quote author="Folknology"]If you still really want to go with CAN take a long look at CanOpen which provides an excellent set of abstractions and good impedance match with the underlying CANBus, it's been developed over a long period and has been heavily tested and deployed, it also has a great deal of community support. If you like what you see go with it, if you don't take a look at other CANBus abstraction layers, however I think it is unlikely you will find the 'familiar abstractions' you appear to desire most. If those 'familiar abstractions' are a priority then you may benefit from revisiting your requirements and tackle the network choice with those as the basis for the requirements, there are plenty of choices out there and you could even think up your own if that's your thing.

regards
Al[/quote]

I believe CAN to be the best match to the requirements of this sort of bus, though RS485 would work similarly well. My issue with the software layer is that I want this to be really easy for hobbyists to use - and that means abstracting away as much of the complexity of protocols like CANopen as possible. If you've got suggestions for useful abstractions and message types, I'm all ears!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 14, 2013, 05:06:14 pm
Well typical message based abstractions are things like 'Producer and consumer' which is employed by CANOpen and patterns like 'Publish and Subscribe' i.e. simple mailbox type abstractions. These can provide easy to understand clean abstractions from the lower level protocols. however with CANBus you still have message size issues that can't just be papered over.

One approach that handles both small fast messages and larger data transfers is to use two stages, a notification (getting basic header info) stage followed by a query stage (to access the larger data parts)

P.S. Don't forget when employing CANBus (and to a larger extent CANOpen and it's competitors) you are also signing up to some fairly predefined OSI layering some of which you cannot escape.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 14, 2013, 05:54:38 pm
BTW whatever you do with with CANBus you will need to get your head around it's oddities, I found this    CAN System Engineering (http://http://www.amazon.co.uk/dp/0387949399): From Theory to Practical Applications by Wolfhard Lawrenz online Goog book link (http://http://books.google.co.uk/books?id=omKP1rROt08C&lpg=PP1&pg=PA3#v=onepage&q&f=false)
 rather useful as it went to lengths in order to explain the background why CAN was designed and later successfully emerged. Without this it can be seen as quite a puzzling network protocol bound to a specific transmission layer. I am not really familiar with more modern treatments of CANBus book wise, perhaps some others might be able to help in that regard.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 15, 2013, 07:25:48 am
Dear Folknology, I partially agree with you but the part that I not agree it´s really big.

I think that if we are trying to establish a "poor man ethernet" to send images, audio, content of a sdhc memory or something bigger than, for example, 256 bytes, then probably CAN protocol is the worst option. But RS485 too! For some reason millons of devices uses "expensive" ethernet with buffers and horsepower demanding processors and not a simple twisted pair with RS485 isn´t it?

But if we need a standard network protocol and physical media to communicate between different relative low power microcontroller, negotiating a very reasonable amount of data (90% of time less than 256 bytes, 99.9% of time a few bytes) then use a sub protocol of CAN would be a clever option, and not use RS485.

Why? Can was designed to fill a specific hole where Ethernet networks or some protocol mounted on RS485 not cover very well. It´s around this hole that we are talking. 

The most important thing than I think that wee need to remember is that we dealing with microcontrollers with a limited amount of memory and it´s really an exception transmit a ""long"" message. Most of the 8 bit ucontrollers (that implement for years a full CAN network) has less total data memory than the data inside an ethernet packet.

RS485 has a long run in industry but the same industry recognizes a lot of failures or partial success histories when they try to use it in several scenarios. RS485 it´s only the first OSI layer and then barely specifies electrical signaling and a few and very rude and imprecise procedure (not protocol) to address packets of data, data collisions, manage failures, handshaking of a busy network, etc

If we decide to use CAN it´s for not reinvented the wheel.

The electric specification of CAN and RS485 can be compared but It´s not the point. I think the important here it´s not only the electrical wiring and noise immunity of CAN. The protocol behind the wires it´s a big piece of clever design from people that know that they doing. Perfectible? Yes, allways, but it works between the walls that was imposed.

I need when I connect some actors or nodes (sensors, actuators, text displays, keyboards, controllers, etc) to a network :
 
* Ensuring data consistency over all nodes.
* Addressing messages between nodes.
* Avoiding data collisions.
* Detect failures in the messages.
* Automatic repetition of corrupted data.

To obtain that ALL protocols establish rules, some more stricter than others. CAN specifies the structure of the message, with identifier, data and control bytes. To rule them in small ucontrollers they need to balance max message length among other restrictions.

When I use a ucontroler that have a "CAN device" all of the previous point are managed transparent to me. A piece of technology added to my ucontroller dealing with these issues and bring me the possibility that my software only deal with the real problems and not uses 80% of the time to fix problems in the electrical unstable and noisy neighborhood.

If I need to send a message to other node I put in a buffer and not worry how I send. Obtain a result for success or failure and continue with other task. Which magic it´s behind the wiring are absolutely not my problem. In RS485 we need to specify, program and test in real world all these tasks. This would be an interesting academic work, or perhaps in some simplified cases when we need to reduce costs in millions of units  justify, but, almost in my case, I like to use a proven solution and implements the less code necessary to solve the situation. Not for reduce efforts, indeed less code, less future bugs to correct.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 15, 2013, 09:50:39 am
Dear Tarloth I agree CANBus is excellent, as I have said I am no knocking it, love it for the way that it is as reliable message based system as it was designed. However what Nick is proposing is using more 'familiar abstractions' :

- Datagram based point-to-point or broadcast messaging
- Stream based point-to-point messaging
- RPCs

These do not sit well with CANBus's original design and flow, if you go with CANBus you have to go with it's way, with it's network abstractions.

I will also address some of your points:

[quote author="Tarloth"]Dear Folknology, I partially agree with you but the part that I not agree it´s really big.

I think that if we are trying to establish a "poor man ethernet" to send images, audio, content of a sdhc memory or something bigger than, for example, 256 bytes, then probably CAN protocol is the worst option. But RS485 too! For some reason millons of devices uses "expensive" ethernet with buffers and horsepower demanding processors and not a simple twisted pair with RS485 isn´t it?

But if we need a standard network protocol and physical media to communicate between different relative low power microcontroller, negotiating a very reasonable amount of data (90% of time less than 256 bytes, 99.9% of time a few bytes) then use a sub protocol of CAN would be a clever option, and not use RS485.

Why? Can was designed to fill a specific hole where Ethernet networks or some protocol mounted on RS485 not cover very well. It´s around this hole that we are talking. 
[/quote]

First of all CANBus was not 'designed to fill a specific hole where Ethernet networks or some protocol mounted on RS485 not cover very well' it had very specific abstractions and applications in mind, I think you are super imposing your own view of CAN This might  help (http://http://books.google.co.uk/books?id=omKP1rROt08C&lpg=PP1&pg=PA3#v=onepage&q&f=false) explain the history of it's design better.

If we take your 256 byte example and try to transmit this over CANBus we would need 4 frames, for CANbus 2.0b we would in fact transmit more frame than data!! Remember that the max dataframe payload is 8 bytes for CANBus. so for sending messages of less than 8 bytes it is optimised, however expecting to use Datagrams, Streams and RPCs over a frame designed like this would be a mismatch of network packet design.

[quote author="Tarloth"]

The most important thing than I think that wee need to remember is that we dealing with microcontrollers with a limited amount of memory and it´s really an exception transmit a ""long"" message. Most of the 8 bit ucontrollers (that implement for years a full CAN network) has less total data memory than the data inside an ethernet packet.

RS485 has a long run in industry but the same industry recognizes a lot of failures or partial success histories when they try to use it in several scenarios. RS485 it´s only the first OSI layer and then barely specifies electrical signaling and a few and very rude and imprecise procedure (not protocol) to address packets of data, data collisions, manage failures, handshaking of a busy network, etc

[/quote]

RS485 continues to grow in application, just because CANBus was created (back in the 90s) it was not meant to replace RS485 they are different animals, as you point out RS485 is only OS1 and CANBus is OS1+2 so its like comparing apples and oranges. I can assure you that RS485 continues to grow and it has a plethora of different layers above it unlike CANBus's fixed OS2.

[quote author="Tarloth"]

If we decide to use CAN it´s for not reinvented the wheel.

[/quote]

But is it the right kind of wheel that fits Nick's 'familiar abstracts'? Or are we trying to build a bicycle on top of skateboard wheels!

[quote author="Tarloth"]

The electric specification of CAN and RS485 can be compared but It´s not the point. I think the important here it´s not only the electrical wiring and noise immunity of CAN. The protocol behind the wires it´s a big piece of clever design from people that know that they doing. Perfectible? Yes, allways, but it works between the walls that was imposed.

[/quote]

Of course thats because it is designed as OS layer 1 (RS485 also has good common mode rejection), that is the point, you get to choose what sits above it.

[quote author="Tarloth"]
I need when I connect some actors or nodes (sensors, actuators, text displays, keyboards, controllers, etc) to a network :
 
* Ensuring data consistency over all nodes.
* Addressing messages between nodes.
* Avoiding data collisions.
* Detect failures in the messages.
* Automatic repetition of corrupted data.

To obtain that ALL protocols establish rules, some more stricter than others. CAN specifies the structure of the message, with identifier, data and control bytes. To rule them in small ucontrollers they need to balance max message length among other restrictions.

When I use a ucontroler that have a "CAN device" all of the previous point are managed transparent to me. A piece of technology added to my ucontroller dealing with these issues and bring me the possibility that my software only deal with the real problems and not uses 80% of the time to fix problems in the electrical unstable and noisy neighborhood.

If I need to send a message to other node I put in a buffer and not worry how I send. Obtain a result for success or failure and continue with other task. Which magic it´s behind the wiring are absolutely not my problem. In RS485 we need to specify, program and test in real world all these tasks. This would be an interesting academic work, or perhaps in some simplified cases when we need to reduce costs in millions of units  justify, but, almost in my case, I like to use a proven solution and implements the less code necessary to solve the situation. Not for reduce efforts, indeed less code, less future bugs to correct.[/quote]

So what are you proposing to use above the OS1/2 layers that provides the magic that means we do not have to write software, is it CANOpen or one of the other competitors?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 15, 2013, 10:13:19 am
Quote
[quote author="Folknology"]Dear Tarloth I agree CANBus is excellent, as I have said I am no knocking it, love it for the way that it is as reliable message based system as it was designed. However what Nick is proposing is using more 'familiar abstractions' :

- Datagram based point-to-point or broadcast messaging
- Stream based point-to-point messaging
- RPCs

These do not sit well with CANBus's original design and flow, if you go with CANBus you have to go with it's way, with it's network abstractions.
[/quote]

I'm still not sure I agree with this. There's nothing fundamental about any of those abstractions that requires long messages, and CAN itself doesn't specify anything above sending a packet with a single address field and up to 8 bytes of data. I think you could implement any of those abstractions on top of it with relatively little overhead - but this is something that will need exploring.

CANopen is still a candidate for layer 2 - but 'raw' CANopen doesn't provide a particularly straightforward abstraction, and I think that will be critical for adoption.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 15, 2013, 10:21:32 am
Sorry Nick, quick correction so we don't get mixed up on the layers :

[quote author="nickjohnson"]
CANopen is still a candidate for layer 2 - but 'raw' CANopen doesn't provide a particularly straightforward abstraction, and I think that will be critical for adoption.[/quote]

CANOpen is a layer3-7, CANBus itself is Layer 1+2

[quote author="nickjohnson"]I'm still not sure I agree with this. There's nothing fundamental about any of those abstractions that requires long messages, and CAN itself doesn't specify anything above sending a packet with a single address field and up to 8 bytes of data. I think you could implement any of those abstractions on top of it with relatively little overhead - but this is something that will need exploring.[/quote]

BTW way there are some basic network design rules about balancing the size of data to frames and we clearly seem to be breaking them with these 'familiar' types of expectations, datagrams are designed with variable length payloads for very good reason

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 15, 2013, 10:48:04 am
Fundamentaly I believe CANBus has a layer 2 design that is optimised for the transmission of small (<=8 byte) fast deterministic messags delivery with integrity (Incl simplistic acknowledgement/error detect). After all it's primary design goals was to enable sensors to send small signal values to controllers which then send commands to actuators, this is CANBus meat and veg. The layer 2 design is optimised exactly for this type of operation.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 15, 2013, 11:00:27 am
An analogy might be helpfull here:
A modern network with familiar abstractions (like RS485/Ethernet running UDP/TCP/IP or some other modern design) is like a road network, it supports different types of vehicles; Motorcycles, cars and trucks, this enables us to convey people and goods using the appropriate class of vehicle. CANBus however is like a courier network that only supports Motorcycles, thus if I need to deliver a crate of bricks I will require the Motorcycle to perform many trips to make the delivery(very inefficient compared to a truck). basically OSI layer II is where one often designs the basic vehicle specifications, for a modern network its good to support different types rather than just a single narrow class to avoid the multiple journey scenario and provide a more flexible efficient network.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 15, 2013, 11:34:23 am
[quote author="Folknology"]Sorry Nick, quick correction so we don't get mixed up on the layers :

[quote author="nickjohnson"]
CANopen is still a candidate for layer 2 - but 'raw' CANopen doesn't provide a particularly straightforward abstraction, and I think that will be critical for adoption.[/quote]

CANOpen is a layer3-7, CANBus itself is Layer 1+2[/quote]

I blame early morning posting, sorry - though I don't think CANOpen can be reasonably described as providing layers 5 through 7.

Quote
[quote author="nickjohnson"]I'm still not sure I agree with this. There's nothing fundamental about any of those abstractions that requires long messages, and CAN itself doesn't specify anything above sending a packet with a single address field and up to 8 bytes of data. I think you could implement any of those abstractions on top of it with relatively little overhead - but this is something that will need exploring.

BTW way there are some basic network design rules about balancing the size of data to frames and we clearly seem to be breaking them with these 'familiar' types of expectations, datagrams are designed with variable length payloads for very good reason[/quote]

0-8 bytes is variable length. There's nothing about those abstractions that says they have to be used with large amounts of data.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 15, 2013, 11:53:43 am
[quote author="nickjohnson"][quote author="Folknology"]Sorry Nick, quick correction so we don't get mixed up on the layers :

[quote author="nickjohnson"]
CANopen is still a candidate for layer 2 - but 'raw' CANopen doesn't provide a particularly straightforward abstraction, and I think that will be critical for adoption.[/quote]

CANOpen is a layer3-7, CANBus itself is Layer 1+2[/quote]

I blame early morning posting, sorry - though I don't think CANOpen can be reasonably described as providing layers 5 through 7.

Quote
[quote author="nickjohnson"]I'm still not sure I agree with this. There's nothing fundamental about any of those abstractions that requires long messages, and CAN itself doesn't specify anything above sending a packet with a single address field and up to 8 bytes of data. I think you could implement any of those abstractions on top of it with relatively little overhead - but this is something that will need exploring.

BTW way there are some basic network design rules about balancing the size of data to frames and we clearly seem to be breaking them with these 'familiar' types of expectations, datagrams are designed with variable length payloads for very good reason[/quote]

0-8 bytes is variable length. There's nothing about those abstractions that says they have to be used with large amounts of data.[/quote]


Agreed about the upper layers for CANOpen, I have now increased my caffeine intake in order to correct this mistake ;-)

As for the '0-8 Bytes is variable length' I agree it is, except in this case our desired familiar abstraction payloads do not fit the narrow layer II design of CANBus and its restrictions, hence my analogy above.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 15, 2013, 12:13:49 pm
To perhaps place the analogy more squarely back into networking consider this:

Ethernet has very generous frames which accommodate many classes of vehicles, it was purposely designed thus for modern networking requirements. This could be considered along with UDP/TCP/IP as being the 4 lane motorway (Freeway for our US folks)

CANBus however locks its layer 1 and 2 together in order to achieve a very efficient but rather narrow design abstraction of realtime messaging and control. In doing so it effectively creates the equivalent of a single track restricted entirely to motorcycles.

RS485/422 just provides layer 1 you can add whatever you wish above this layer designed to meet your modern familiar requirements. Although you are unlikely to create a Motorway you could create a single track capable of carrying motorcycles, cars or trucks (half duplex) or even a trunk road (full duplex).

All I am suggesting is that the latter may better represent the requirements than the former and as such should be suitably considered against the requirements..

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 15, 2013, 03:06:00 pm
Folknology, I don´t like the analogies because depends in the interpretations, BUT, I can comment in terms of the last one.

Quote
Ethernet has very generous frames which accommodate many classes of vehicles, it was purposely designed thus for modern networking requirements. This could be considered along with UDP/TCP/IP as being the 4 lane motorway (Freeway for our US folks)

Yes, I agree totally, BUT, Ethernet do something more, establish the general and specific characteristics of the vehicles that move in the freeway and the specifies that you can move cars, van or trucks (not airbus, not skateboards) and define exactly how can I move this "vehicles" and the exact form of this vehicles. Ethernet off course not specify how many peoples voyage in each vehicle or which kind of products transport in the truck, but the MINIMUM vehicle it´s defined. In ethernet I can´t drive a skateboard (it´s a freeway :-) ) , exist a minimum amount of data and frames in the package.

From this point of view it´s by far less restricting than CAN, but permits transit collapse and collision storming that convert it in an impossible real time network.

Quote
CANBus however locks its layer 1 and 2 together in order to achieve a very efficient but rather narrow design abstraction of realtime messaging and control. In doing so it effectively creates the equivalent of a single track restricted entirely to motorcycles.

Exact, defines the first two levels but not the rest of all levels, please, remember this point until end of post. With the same analogy with freeway you say that CAN it´s a single track only for motorcycles and I AGREE TOTALLY!

But this is the beauty of it, an EXCLUSIVE single track ensure us the time that motorcycle arrive!.

Our ucontrollers can made easy motorcycles, not trucks. CAN it´s a very severe policeman that ensures that bottleneck are impossible, for this track is mandatory that all motorcycles be the exact model and voyage to an exact velocity. All the single railroad work as a charm even when in the freeway (in somewhere) all the transit it´s slowed by a bottleneck. And this is important when you need to send something urgent.

Off course, CAN say nothing about each motorcycle can transport. We can´t transport a truck, but in extremis we can divide the total load in many motorcycles, but this is really really inefficient. If we need to do this one time every 10.000 motorcycles it´s not a real problem, inefficient but possible. If all transit it´s of motorcycles carrying a piece of a truck load then we choose really bad our road and vehicle. 

Quote
RS485/422 just provides layer 1 you can add whatever you wish above this layer designed to meet your modern familiar requirements. Although you are unlikely to create a Motorway you could create a single track capable of carrying motorcycles, cars or trucks (half duplex) or even a trunk road (full duplex).

The key here it´s that in THEORY you can create a freeway but you need to construct it from scratch. You have only the empty space, you need to make asphalt, defines signalization , types of animals that run in this new freeway and deals with the real life when all of this is moving.

Because nothing it´s standard you need to code all of this aspects, and if you produce an deficient code the new freeway stop working, smash vehicles, or worse lost it in the road.

When you begin to model the freeway you need to take notice that the real power of your building machines (small than a power full uprocessor) and the efficiency of your policeman in the road to control traffic, perhaps for the ucontrollers that we use, ends with a single truck with bicycles and skateboards instead motorcycles. 

One problem with this solution it´s that you penalize your ucontrollers all the time in construct the freeway, the vehicles and drive then. In Ethernet, CAN or other well defined protocol, a specialized stack do this task for us and only we pay attention for drive the vehicles.

This is the only that I say. Construct from scratch it´s a good thing when the road it´s very very restricted and then only need a thin path and perhaps a skateboard going in only one direction at time and start in only one point. Off course is the path is a ramp a skateboard can travel fastest than a motorcycle or a truck, but only in very specific scenarios this happens.

When I say that CAN cover a specific hole I refer exactly at the link that you send. In this link we can read (page 4):

Quote
The original intention was to specify only ONE unique interface for SIMPLIFYING MODULAR SYSTEM DESIGN . ... As an example, the requirement for time efficient communication of long records is contradictory to the requirement for short response times for the communication of so-called event related information in real time critical application.

....

Although different protocols are applied, system designers might require a more generic communication interface. Such an interface would allow a simpler system design, greater independence of the underlying would allow a simpler system design, greater independence of the underlying realizations, enhanced re-usability of existing solutions, reduced complexity to be handled by designers, reduced system development time and enhanced reliability and quality of the solution.


And this is the key point. When designers works on CAN, Ethernet and RS485 exist (with a lot of others options) but the first was horse power demanding at this time, a lot of wirings and not predictable the traffic. RS485 was simpler but when they defines the protocol push mandatory restrictions to the electrical wiring and then defines a new electrical spec.

The final goal was develop a silicon that can manage the entire requirements and free all this issues from ucontroller.

If we need to interconnect modular devices that transport a moderate amount of data we can use CAN and enjoy the works and efforts of other people that knows they do. I love hardware message filtering, it´s incredible have this option in a very small processor.

CAN not push us to all levels of OSI if we not need to interconnect with other system. We can use the level 1+2 or even replace the level 1 by other wiring and maintain level 2 and simplify our live.

I think that this is the valuable initiative from Nick. We can define the rest of OSI levels and develop a tailored dialogue relying in CAN. Yes, we would be restricted by road and type of vehicle, but we are free to define the rest.

The point that I agree with you is if Nick (or other) plan to transport an image of 8 Mbyte all the time (for example a remote graphic display) or move a wave file to a remote speaker or something like that in CAN, then we use the wrong road in the worst option. This need to be specify prior continues arguing. WHAT KIND OF DATA AND LENGTH would be transported.

If Nick like to stream exceptionally (in terms of one case in thousand of other messages)  an amount of data that can be manage with 30 or 50 messages, or speak between a very remote (from control point of view) LCD text display and a small keyboard, connect some actuator, control a motor and read a sensor then CAN it´s the way.

Agree with you that it´s mandatory defines what kind of use we would do to the road, without knowing that it´s useless the arguing to one or other solution.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 15, 2013, 03:47:49 pm
I hear where your coming from Tarloth

Couple of small points however

When talking about ethernet your say :
Quote
From this point of view it´s by far less restricting than CAN, but permits transit collapse and collision storming that convert it in an impossible real time network.
However EtherCat operates exceptionally well in doing just this.

More recently we are also seeing new forms of CAN over ethernet being adopted by many Auto manufacturers and even industry applications, this appears to contradict your point. As does anything built on the following standards IEEE 802.1AS, IEEE 802.1Qat, IEEE 802.1Qav and IEEE 802.1BA

Quote
The key here it´s that in THEORY you can create a freeway but you need to construct it from scratch. You have only the empty space, you need to make asphalt, defines signalization , types of animals that run in this new freeway and deals with the real life when all of this is moving.
This isn't strictly true as there are already higher stacks out there covering different layers so you would not HAVE to write the entire stack from scratch unless you actually preferred that.
 
You also keep repeating CANBus's benefits, this is pointless as it's benefits are baked in and clearly apparent, the issue here is not those benefits but rather the layering of more familiar abstract like Datagrams,Stream and RPC on top of them which results is traffic jams full of motorcycles.

But I totally agree with you that in order to judge the best solutions what we need is some specific requirements from nick that spell out the type/class and distribution of expected network traffic. Else we will continue chasing rainbows.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 15, 2013, 04:42:41 pm
Folknology:

Quote
However EtherCat operates exceptionally well in doing just this.

More recently we are also seeing new forms of CAN over ethernet being adopted by many Auto manufacturers and even industry applications, this appears to contradict your point. As does anything built on the following standards IEEE 802.1AS, IEEE 802.1Qat, IEEE 802.1Qav and IEEE 802.1BA

All of this specifications that you point are NEWEST than CAN and alters the ethernet protocol at time of CAN development.

Always you can develop a restricted protocol or modify a protocol to optimize something, but it´s not that I argue here. Ethernet as general protocol at times of CAN was not real time and at this time you need to change the protocols and use special switches to ensures real time.

Quote
This isn't strictly true as there are already higher stacks out there covering different layers so you would not HAVE to write the entire stack from scratch unless you actually preferred that.

Off course!!! I use many of them and works great! If you have in mind some that is as easy and cheap to implement like CAN please put as an option to Nick!

All of the variants that I use in RS485 with same or better characteristics than CAN it´s or a heavy load to a small microcontroller that pass most of his time arbitrating the network or need special hardware many times expensive than CAN.

And it´s pointless arguing about this. If you prefer use a software stack and pay the load at node it´s your option. If  I think in a extensive network of nodes TODAY (not the same 6 years ago) I think in CAN because eventually all the ucontrollers that I use have almost one CAN port (for very light sensors I use LIN).

For example, I need sensors and actuators that have programmed a hardware filter in the CAN Stack and generates a hardware interruption when a message with correct description arrives. Rest of time the sensor or actuator would be sleeping or controls something else without disturbing by the general traffic in the network that not affect it.

Can you do this with any flavor of RS485 or Ethernet at less cost and effort than CAN do? I do something similar using long distance I2C but not convince me and it´s expensive than CAN in the final costs. Maybe in the future would be an option.

And quote myself, I usually not need packages greater than 8 bytes, exceptionally need 200 bytes or something similar to talk to a LCD text and do this very exceptionally because most of messages are codified and data it´s send in raw format, not text line.

Other functions of my network are do via one ethernet client at a very precise point. CAN it´s not magic and some task would be done with more appropriate solutions.

Wait for a Nick answer specifically defining what length of data he likes to manage habitually in his network. If he likes to move a large amount of data I simply relies in Ethernet and not lost more time in work with CAN.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 15, 2013, 04:55:14 pm
Quote
Always you can develop a restricted protocol or modify a protocol to optimize something, but it´s not that I argue here. Ethernet as general protocol at times of CAN was not real time and at this time you need to change the protocols and use special switches to ensures real time.

This isn't a restricted protocol it's actually part of the Ethernet standard, it is primarily using the Ethernet frame type in the header for it's designed purpose. That is what allows these realtime standards and along with transporting other standards like CAN or anything else for that matter across the same cat5/6 cable. In many cases you don''t even have to have a switch!

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 15, 2013, 04:59:27 pm
Quote
Wait for a Nick answer specifically defining what length of data he likes to manage habitually in his network. If he likes to move a large amount of data I simply relies in Ethernet and not lost more time in work with CAN.

The specific use-case that spawned all this is access control to lockers in a hackspace. Messages are short and infrequent, so CAN is well suited.

However, the goal is to make this a useful platform for a lot of microcontroller networking use-cases, so I'm interested in hearing other peoples' specific use-cases too.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 15, 2013, 05:16:12 pm
However using ethernet/CAT5/6 infrastructure does have some issues :
1) Like CAN or RS485 it needs a transceiver these can be had very cheaply now similar to say to an MCP series CAN TX/Rx
2) It does need a Media Independent Interface which is more expensive pin wise, even the RMII requires a duplex set of RX/TX pairs along with flow control, taking it to 8 pins,although pins these days are pretty cheap!
3) Not sure how many µC will be fast enough to cope with MII like interfacing

Still its another one on the list to consider I guess we shouldn't just ignore it.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 15, 2013, 06:06:33 pm
Quote
The specific use-case that spawned all this is access control to lockers in a hackspace. Messages are short and infrequent, so CAN is well suited.

Perfect!

Quote
However, the goal is to make this a useful platform for a lot of microcontroller networking use-cases, so I'm interested in hearing other peoples' specific use-cases too.

I´m working to control all the issues in a group of greenhouses in Patagonia. In each greenhouse I need to control ventilation, heated, sun shielding and moist control and irrigation.

For do this I need to read humidity, light radiation, temperature and wind velocity in each greenhouse in different greenhouse zones.  In function of this reading I need to open vents, move shades, irrigators, etc.

At same time each greenhouse controller needs to take account  of the single weather station in the facility and the information that arrives through web with weather tendencies. For example, if the greenhouse it´s warmer than we specify, BUT, it´s expected a pronounced temperature drop this night, then controller not open the vents and stock heat or open less than is usual.

To complete this we have a hydroelectric generator  and to control it I use the prevision budget of energy for the next hour and modify the heated cycle in each greenhouse to avoid spikes in demand and distribute more rationally the use of available energy.

A you see the problem here it´s the algorithm in each controller and I not like any problem with data transmission. I need that some data was multipoint delivery without effort and need that all controllers can hear certain data. I not like to mess up with collisions, data corruption or noise (in the reasonable way, always noise it´s a problem).
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 15, 2013, 06:51:14 pm
Hey Tarloth that's so cool although I am working on a number of projects that could benefit here, my current design is controlling some very similar things to yourself:

1) Small irrigation pumps/valves and some larger well type pumps also.
2) Solar power generation, optimisation, storage and management
3) Power distribution along with communication.
4) High efficiency lighting control
5) Simple actuators and sensors
6) Environmental measurement etc..

Some of this can be over large distances with very small power envelopes all in rural third world settings with third world budgets. One of our biggest issues is cost per node which we have to get down towards about £1 ($1.5) µC + comms, which is why RS485 has worked well for us to date, CANBus just couldn't reach that far down, we also had issues with distance, although we are considering partitioning/segmenting.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 15, 2013, 11:53:21 pm
Wonderfull! If you have a page with the designs please send me the link to read more.

I use a lot years ago a 8051 derivative that have CAN embedded and really not worry about cost because was included in the controlled that I use. Then start to try the protocol and I try it in noise environment.

Few years ago I change all to ARM cortex (for a lot of reasons) and still have almost an unused CAN stack """for free""". Since we need to produce one hundred devices as a max quantity we really no have concerns about price, but even I pay for have less problems for the CAN translator that cost less than a dollar. If we need to make thousands of units cost are a concern, but in low quantities it´s more important low maintenance and rapid development. Initially I design the smallest sensor using other platform, but the simplicity of use the same tools with all the devices and can upgrade firmware remotely by CAN make that all devices are of the same family but with different memory capacity and less devices or clock. At end, even the LIN network it´s cuestioned to be transformed to the CAN using a better micro controller but unifying wires.

We are working with a Biotechnology Cooperative that make plants in a third world country, they need to develop his own design for lower costs and not depends in the variability of sellers stock. When all the project it´s ended, would be published as OpenSource development to reinforce that other greenhouse unifies the same technology.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 16, 2013, 11:37:55 am
Thanks Tarloth

[quote author="Tarloth"]Wonderfull! If you have a page with the designs please send me the link to read more.[/quote]

At the moment the stack and its components (real mixture of boards etc..) is not in a state I would feel happy publishing, I am working on a new S/HDK to make it easier to modularise the design which I will publish soon, this will be more approachable and I will need to document it along with everything else (Opensource in due course when presentable!)

[quote author="Tarloth"]
I use a lot years ago a 8051 derivative that have CAN embedded and really not worry about cost because was included in the controlled that I use. Then start to try the protocol and I try it in noise environment.

Few years ago I change all to ARM cortex (for a lot of reasons) and still have almost an unused CAN stack """for free""". Since we need to produce one hundred devices as a max quantity we really no have concerns about price, but even I pay for have less problems for the CAN translator that cost less than a dollar. If we need to make thousands of units cost are a concern, but in low quantities it´s more important low maintenance and rapid development. Initially I design the smallest sensor using other platform, but the simplicity of use the same tools with all the devices and can upgrade firmware remotely by CAN make that all devices are of the same family but with different memory capacity and less devices or clock. At end, even the LIN network it´s cuestioned to be transformed to the CAN using a better micro controller but unifying wires.
[/quote]

I would love to use CAN and in particular integrated solutions like the LPC11C24 with integrated transceivers and have had fun playing with them a while back, but I cannot see anyway to get the price down even with high volumes. I am also not that keen on using CANOpen which is in the ROM but one can bypass that. But at $3-4 it is out of our budget to use on all sensor/actuator nodes, most of the node µC are currently < $0.8 and we get real good deals on 485 transceivers. However if we segment and partition our networks we may be able to consider the CAN route on some segments with an economical source of good value CAN transceivers. Do you have any experience with these NXP TJA1050 (http://http://www.nxp.com/products/interface_and_connectivity/transceivers/can_transceivers/series/TJA1050.html) we can get good deals on these in volume and it would enable us to consider the is route I would appreciate your opinion (Tarloth) and thoughts.

[quote author="Tarloth"]
We are working with a Biotechnology Cooperative that make plants in a third world country, they need to develop his own design for lower costs and not depends in the variability of sellers stock. When all the project it´s ended, would be published as OpenSource development to reinforce that other greenhouse unifies the same technology.[/quote]

This is very interesting could consider sharing technology and experience with you here.


P.S. If we could go the CANBus route we would also have to make the stack rather small as most of the µC have rather low memory/code space, so we would need KISS i.e. fairly close above CANBus layer II.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 16, 2013, 02:02:38 pm
[quote author="Folknology"]P.S. If we could go the CANBus route we would also have to make the stack rather small as most of the µC have rather low memory/code space, so we would need KISS i.e. fairly close above CANBus layer II.[/quote]

I'd argue that this is one of the advantages of CAN - interface chips like the MCP2515 handle a lot more of the protocol than a simple RS485 transceiver, which reduces the footprint needed on the MCU a lot.

What are your objections to openCAN? What would you like to see in a wire protocol?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 16, 2013, 02:28:17 pm
Hi Nick

Quote
What are your objections to openCAN? What would you like to see in a wire protocol?

I am going to think about this a little more in order to better answer that question, initially for my purposes I am worried that CANOpen may be a little overkill given the relatively simple requirements we already operate on using RS485. Clearly the scope of uCan would however be greater. In the project I mention we might not require uCan on all segments, we may get away with something much simpler on the economically challenging segments in order to keep those costs down, right now I am going through the possible permutations and trying to figure out what would work best and where.

*Update I would also like to better understand what the minimum requirements on the µC would be if we went the CANOpen route?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 16, 2013, 02:59:29 pm
On the plus side for CANOpen It's only fair that should also point out:

1) NXP's LPC Cortex M0 range with CANBus support, includes CANOpen in ROM which lowers some of the overhead on those particular devices, it also makes dev on that platform simpler out of the box. BTW we also use LPC range already ;-)
2) CANOpen provides a rich feature set meaning we would not need to reinvent the wheel
3) CANOpen has been debugged and tested in a wide variety of settings and thus has good support.
4) We could just concentrate on the layers above this for uCan which gets us moving quickly

These make it very tempting, especially (4) ;-)

I would love to see other's opinions/feelings on CANOpen

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 16, 2013, 05:08:56 pm
Folknology:

I currently using TJA1051 and for our test in the ""noise"" of a greenhouse here in Buenos Aires it´s near perfect. We have LOT of ESD and "heavy" spikes when  discharging it to ground, EMC from motor´s induced in near low voltage wires and EMC from solenoids.  Never notice a problem.

I use the standard ARM CAN library in CMSIS and maping a basic message mailbox (until now, because I interested in this idea). I haven´t a final version of the entire network management because I´m working in greenhouse control algorithms and interchange only few necessary data between 2 nodes. I use as code base some of the examples for ST. Nothing else and works : -)

Perhaps we can colaborate in make a CAN network monitor, it´s a good tool and add experience in CAN Bus.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 16, 2013, 05:43:45 pm
BTW Nick whilst your designing the RPi uCan board please add on a low cost RTC chip (+32K crystal) supported by linux please as this is always really handy to have and is a trivial addition to your board layout.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 16, 2013, 05:47:22 pm
[quote author="Folknology"]BTW Nick whilst your designing the RPi uCan board please add on a low cost RTC chip (+32K crystal) supported by linux please as this is always really handy to have and is a trivial addition to your board layout.[/quote]

I've already sent it off for fab, but I'll consider it for V2. Finding room on the board could be somewhat problematic, though.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 16, 2013, 06:19:16 pm
This one PCF8523TK/1,118 is tiny if you need to squeeze it in, however you still need the crystal ;-)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 16, 2013, 07:16:54 pm
OK I am now working on an LPC11C board that can be used for development around uLan. I am also looking at adding it to the H/SDLK over the next few days so we can also integrate it with our Comms controllers.

One of things I would like to do however is use the rest of the pins on the RJ45 for power, this will mean we have 3 ground pins and 3 power pins, this is essential for us as most nodes are powered by the bus and in order to minimise expensive power losses in the cables we need as many of the cores in the cat5/6 to carry power as possible.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 16, 2013, 07:20:27 pm
[quote author="Folknology"]OK I am now working on an LPC11C board that can be used for development around uLan. I am also looking at adding it to the H/SDLK over the next few days so we can also integrate it with our Comms controllers.[/quote]

Awesome!

Quote
One of things I would like to do however is use the rest of the pins on the RJ45 for power, this will mean we have 3 ground pins and 3 power pins, this is essential for us as most nodes are powered by the bus and in order to minimise expensive power losses in the cables we need as many of the cores in the cat5/6 to carry power as possible.

How much power do you need to carry? Depending on how much it is, increasing the voltage to 48V might be a better option. I've been trying to stick to the standard pinout for CAN over RJ45 if I can.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 16, 2013, 07:59:47 pm
We already run up to 40V max, nominally we use 36V or 18v depending on which segment. As for the other pins I suggest we tie shield to ground and I will put V+ on the 2 reserved pins as these are unlikely to be used AFAIK they have been there for years without use.

P.S. Because of the new network structure in play at the moment we may end up limiting the uCan segments to 18V and only use 36V between segments to avoid higher losses, but that isn't yet finalised and is still in play. The other possibility with the reserved pins, if someone objects, is perhaps the use of solder bridges to disable power on these pins, although this is inconvenient from a layout perspective.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 16, 2013, 11:46:33 pm
At initial planning we use RJ45 but the cost escalate high for the long distances. Even inside the greenhouse the wiring run in long distance.

Instead of this we are planning to use thicker central wire at top of greenhouse and divide near the devices with 2 pair RJ11 to devices with low current budget.

At this point we are very interested in check how long can be the stub if we use linear bus. Optimally the stubs must be less than 50 cm but in laboratory we can made a central network with 3 stubs of 10 meters and not suffer to much data stress or loss packet but the max velocity not exceed 125 Kb.

If we can go with a central line and relatively long stubs the wiring is less expensive.

Simplest solenoids (less than 6watt) , controllers and sensors use low current and can be connected to low current wires in RJ11. Motors and actuators would be connected to AC main or to the thicker wires, not to the "low current wires".

One option it´s use RJ45 connector in the PCB, send the data lines at center and put power at sides. If you need low current uses a Rj11 connected at center of Rj45 (2 data and 2 power wires) or uses a full RJ45 with 4 pair and obtain 1 pair to data and 3 pair for power. Same connector but two options, and PCB RJ45 cost is very similar or equal to RJ11. 

We are working with 24 volts but allow 20 to 36 volt, essentially all the devices uses switching DC-DC power supply to adjust to 12, 5 or 3.3 volt in each case.

In the real world the cost of sensor and controllers is the less expensive. Wires, IP67 Boxes, connectors and power supplies cost 10 times the cost of Controller PCB, Sensors, and 4 relay in each greenhouse!

Almost in Argentina, display, knobs, connectors and box used to be more expensive than the electronic inside. It´s by far less expensive program a interface WEB-CAN and control all the network from a cheap chinese android tablet than construct display panels, keyboards and indicators.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 17, 2013, 10:33:29 am
Quote
[quote author="Tarloth"]At initial planning we use RJ45 but the cost escalate high for the long distances. Even inside the greenhouse the wiring run in long distance.

Instead of this we are planning to use thicker central wire at top of greenhouse and divide near the devices with 2 pair RJ11 to devices with low current budget.

I'm not sure I follow - RJ45 sockets and CAT5 is pretty cheap. You can probably even use lower grade CAT cable for CAN, too.

Quote
At this point we are very interested in check how long can be the stub if we use linear bus. Optimally the stubs must be less than 50 cm but in laboratory we can made a central network with 3 stubs of 10 meters and not suffer to much data stress or loss packet but the max velocity not exceed 125 Kb.

If we can go with a central line and relatively long stubs the wiring is less expensive.

I'm also planning on building a CAN hub / multi-repeater, which would help with this sort of star configuration.

Quote
One option it´s use RJ45 connector in the PCB, send the data lines at center and put power at sides. If you need low current uses a Rj11 connected at center of Rj45 (2 data and 2 power wires) or uses a full RJ45 with 4 pair and obtain 1 pair to data and 3 pair for power. Same connector but two options, and PCB RJ45 cost is very similar or equal to RJ11. 
[/quote]

I would very much prefer to keep a pinout that's compatible with the standard set, though.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 17, 2013, 10:33:52 am
Another option for application layer protocol would appear to be devicenet (http://http://www.rtaautomation.com/devicenet/).
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 17, 2013, 03:26:44 pm
Not, not in star, Lineal bus with long stubs, It´s not possible to use Star topology in can without an active transceiver in each "port".

Here CAT5 lowest grade cost .5 dollars meter, 2 pair phone cable less than .1 dollars meter and thick cable for power cost the same approx for 2 wires.

In a greenhouse if I use strictly linear bus topology I use at least 200 meters of cat5 cable. Controller and sensors with PCB but without  enclosure and connectors cost less than 60 dollars!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 20, 2013, 07:54:25 pm
On the CANBus analyser question I have always hoped that a RPi based board might make this possible.

However it's beyond my skillset (linux kernel dev et al) however there is a good thread in the Pi forums about implementing the MCP2551 on RPi here :
http://www.raspberrypi.org/phpBB3/viewt ... =44&t=7027 (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=7027)

Both interupt selection and driver choice with the SPI low latency work is crucial here.

Well worth a read if your going in that direction, they have clearly made progress and improvements to prevent loss of packets, however there is still some way to go in real world especially when one might be using USB and or Ethernet on the RPi as well as CAN!

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 20, 2013, 08:27:17 pm
[quote author="Folknology"]On the CANBus analyser question I have always hoped that a RPi based board might make this possible.

However it's beyond my skillset (linux kernel dev et al) however there is a good thread in the Pi forums about implementing the MCP2551 on RPi here :
http://www.raspberrypi.org/phpBB3/viewt ... =44&t=7027 (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=7027)

Both interupt selection and driver choice with the SPI low latency work is crucial here.

Well worth a read if your going in that direction, they have clearly made progress and improvements to prevent loss of packets, however there is still some way to go in real world especially when one might be using USB and or Ethernet on the RPi as well as CAN!

regards
Al[/quote]

I don't believe this should be problematic with the shield I've already designed and the linux kernel CAN support - you can simply load the module and open a CAN socket to listen to all messages.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 20, 2013, 08:56:25 pm
Quote
I don't believe this should be problematic with the shield I've already designed and the linux kernel CAN support - you can simply load the module and open a CAN socket to listen to all messages.

I am hoping it will get to this, at the moment they seem to be advising the use of a non-standard (patched (http://http://elinux.org/RPi_CANBus)) SPI driver, as well as their latest CAN driver support. By all accounts the SPI drivers are generating 3-6 times as many interrupts as the CAN driver itself leading to packet loss above 100Kb/sec (without other RPi USB/Eth usage). There was even talk about building a bespoke CAN/SPI driver but that would be problematic support wise. Clearly these guys have their finger on the pulse and are finding their way around both the CAN,SPI and Broadcom driver stack, trying to make them sing nicely together.

Here is to hoping it all gets built into the standard Raspian distro at some point in the future, will defo have a play with your board Nick when you add the RTC in (handy for logging and analysis).

P.S. I might also take a look at the beaglebone/black CAN stack as well as this will likely prove more reliable in the near term

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 20, 2013, 09:13:58 pm
[quote author="Folknology"]I am hoping it will get to this, at the moment they seem to be advising the use of a non-standard (patched (http://http://elinux.org/RPi_CANBus)) SPI driver, as well as their latest CAN driver support. By all accounts the SPI drivers are generating 3-6 times as many interrupts as the CAN driver itself leading to packet loss above 100Kb/sec (without other RPi USB/Eth usage). There was even talk about building a bespoke CAN/SPI driver but that would be problematic support wise. Clearly these guys have their finger on the pulse and are finding their way around both the CAN,SPI and Broadcom driver stack, trying to make them sing nicely together. [/quote]

This seems like a very odd approach, given the Linux kernel already has a module for socket CAN built in - no need to use SPI or do the CAN in userspace at all. Here's an expansion board that even supplies a kernel with it linked in: http://www.skpang.co.uk/catalog/pican-c ... -1196.html (http://www.skpang.co.uk/catalog/pican-canbus-board-for-raspberry-pi-p-1196.html)

Quote
P.S. I might also take a look at the beaglebone/black CAN stack as well as this will likely prove more reliable in the near term

regards
Al

I'd love to see a beaglebone cape for uCAN!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 20, 2013, 09:17:21 pm
BTW I don't think that kernel linked in actually works, its's mentioned in that thread.

uCan cape would be dead simple, just a couple of TJA1050/51s and some RJ45 connectors as CAN is baked in!

*Update - found one already : http://beagleboardtoys.info/index.php?t ... one_CANBus (http://beagleboardtoys.info/index.php?title=BeagleBone_CANBus)
(not cheap however)

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 20, 2013, 09:22:13 pm
[quote author="Folknology"]BTW I don't think that kernel linked in actually works, its's mentioned in that thread.[/quote]

Ah. Regardless, though, the best option would seem to be to use the kernel's support for the MCP2515, rather than trying to implement it in userspace!

Quote
uCan cape would be dead simple, just a couple of TJA1050/51s and some RJ45 connectors as CAN is baked in!

Oh, awesome! It'd need a switching regulator too, ideally. If you don't design one, I will. ;)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 20, 2013, 09:26:49 pm
Quote
Oh, awesome! It'd need a switching regulator too, ideally. If you don't design one, I will. ;)

Not really my thing, I will stick to what I know, kernel driver dev isn't my area and supporting that is way beyond my bandwidth ;-)

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 20, 2013, 09:34:18 pm
[quote author="Folknology"]
Quote
Oh, awesome! It'd need a switching regulator too, ideally. If you don't design one, I will. ;)

Not really my thing, I will stick to what I know, kernel driver dev isn't my area and supporting that is way beyond my bandwidth ;-)
[/quote]

Well, no dev ought to be required. On the RPi it'll take a bit of tweaking but should only require configuration. On the Beaglebone Black it's even simpler: http://www.embedded-things.com/bbb/enab ... one-black/ (http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/)

I just ordered a Beaglebone Black off Farnell, though.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 20, 2013, 09:59:19 pm
Well a Beaglebone Black uLan cape would be nice in the collection if you fancy building one. Right now I'm concentrating on LPC11cxx and Xmos based uLan, that will keep me busy for a while!

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 20, 2013, 10:25:19 pm
[quote author="Folknology"]Well a Beaglebone Black uLan cape would be nice in the collection if you fancy building one. Right now I'm concentrating on LPC11cxx and Xmos based uLan, that will keep me busy for a while![/quote]

Awesome! What form factor are you going to use?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 20, 2013, 11:37:59 pm
for which?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 21, 2013, 08:45:18 am
[quote author="Folknology"]for which?[/quote]

For the LPC11Cxx and XMOS based expansion boards.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 21, 2013, 09:10:15 am
Well for the Xmos it will be part of an OEC 80x90mm board, with powering and  segmenting (more on this shortly I'm just finishing the layout) but I may also do a slice board in addition after. I haven't quite decided on final form factor for the LPC11c board, but again I will have some specific goals for it beyond just uLan maybe have some led controllers and PWMs, possibly a few switches.

Anything specific folks here want to see on the LPC11C board?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 21, 2013, 06:10:12 pm
At hardware level I probably run CAN Analizer from a ST microcontroller connectivity line and establish a bridge between CAN and USB or Ethernet (via web service for use with any client). I not see the advantage of using a complex operative system or a powerfull board like RPi. CAN run in processors of low power, at max protocol speed we are in less than 200KByte second. Almost all the ARM Cortex that I use permit DMA between stack buffers or format  text around the CAN stack and redirect it at more high rates than 200Kbyte.

But let´s go with the solution that you are more comfortable and I adapt the C code to my hardware implementation, its the beauty of open solution :-).
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 21, 2013, 06:24:01 pm
[quote author="Tarloth"]At hardware level I probably run CAN Analizer from a ST microcontroller connectivity line and establish a bridge between CAN and USB or Ethernet (via web service for use with any client). I not see the advantage of using a complex operative system or a powerfull board like RPi. CAN run in processors of low power, at max protocol speed we are in less than 200KByte second. Almost all the ARM Cortex that I use permit DMA between stack buffers or format  text around the CAN stack and redirect it at more high rates than 200Kbyte. [/quote]

Well, just because it's really easy to write and use an analyzer/dumper for a full OS like Linux. I don't know what existing analysis tools are out there, though.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 21, 2013, 06:24:20 pm
[quote author="Tarloth"]At hardware level I probably run CAN Analizer from a ST microcontroller connectivity line and establish a bridge between CAN and USB or Ethernet (via web service for use with any client). I not see the advantage of using a complex operative system or a powerfull board like RPi. CAN run in processors of low power, at max protocol speed we are in less than 200KByte second. Almost all the ARM Cortex that I use permit DMA between stack buffers or format  text around the CAN stack and redirect it at more high rates than 200Kbyte. [/quote]

I concur and will be doing this with my Xmos adaptations over the longer term, however sometimes it is useful to short cut this using linux command line tools for doing dirty simulation and testing as it's easy to knock up a set of exercise frames as well as cheap (if not completely reliable) logging.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 21, 2013, 08:31:43 pm
Yes, I can agree with both in other cases when the final product isn´t an analyzer or a measure instrument.

In the practice sometimes Linux (or windows, not apologies here!) it´s a swamp. In the chain of tools sometimes fail the driver, sometimes crash the operative system, sometimes an angel cry and all work ends in the trash bin. Even I don´t know if in the next year when I need other "CAN Analyzer" (because I lost mine board or toast it for sure!) I can buy an exact  RPi ver. B or a BeagleBoard like this design uses and then begin´s with hardware tweaking and software adaptations.

I not say to do the graphic client in an LCD or something similar in the Cortex ucontroller (it´s possible but I need to start from scratch and is silly) but use the ucontroller as a smart interface (perhaps with a SD memory card) and read the commands from something (Rpi, Beagle, tablet, PC, Phone, etc.) connected to an ethernet port as a file or a data stream ( a lot of well know tools do this) or format  the output as HTML code and show it in a web side that act as fast front end. Then if I prefer use it from a tablet or smartphone in the field or from a desktop PC in the laboratory and all works ok. I can use the OS to implement a client, but it only interpret a result in a standard port, not implements a bitbanging CAN library or a specialized hardware. Sorry, I fall in this trap a lot of times in my life and prefer not fall again.

Recently I have a similar situation with OLS from this site. The FPGA Code its a Jewell of Work! It´s left behind a lot of other LA and with some signal conditioning works even better than my old HP Logic Analyzer, but, the interface between core and PC was done with a "slow" USART port with a "slow" controller and for completeness uses JAVA for the client with not very reliable serial drivers. Work? YES, OFF COURSE! It´s a wonder full piece of technology; but Murphy Laws are mandatory and Java client hang up in my worst day, losing the entire data and in some times trying lot of time to communicate. I need to go with my big notebook to a site when a small tablet do his best work.

For justice 90% of time it works like a charm, but in a reliable tool we need almost 99.5% of time. Even when work OK took a "lot of time" download long captures to the client. Somebody says that this LA it´s a toy, but I thing that somebody do a excellent work in the Core and somebody do an excellent work in the client and OLS can be a lot more than a toy. I recommend it for all my friends and we are almost happy but some disappointing. If the people at design time spend 5 more dollars (10% + of final cost) they can use a powerfull processor plenty of memory and power to manage alternatives at the original SUMP protocol and now somebody can try a different approach in the same board. Can I build my own OLS? Yes, off course in the near future but today I continues using my HP in the field.

For all of this prefer a "smart" box that I can use as CAN logger and use something else to read the data an configure the logger.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 21, 2013, 08:57:34 pm
Yes, I wasn't suggesting using an RPi in a dedicated CAN logger - I think it would make more sense to have a USB <-> CAN interface. Though I still think it makes more sense to expose it as a CAN network interface on the target PC (where supported - such as in Linux) and allow the use of userspace programs to do the actual analysis, rather than expect that to be done on the device.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 22, 2013, 06:53:14 am
Just wanted to comment and say I think this is a great idea.  It's also the same idea I have been thinking about for a while, which contributed to me finally creating a forum account here.  :-)

Nick, you said you wanted to stick to existing standards / standard pinout.  Do you have anything CAN based in mind that you want to be compatible with? (and is it something that a hobbyist / artist / etc is likely to have or be able to afford?)

I've felt that for the sorts of uses you mention, and I've thought about, it would make sense to have something that is compatible with standard Ethernet cabling instead - that is, picking the CAN pair so that it is possible to run 100Mbit Ethernet in parallel on the same cable.  (Maybe even PoE.)  It's not such a big deal for hackerspaces to run an extra cable, but I can think of a couple of places where running on an already installed Cat 5 would come in useful.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 22, 2013, 08:25:52 am
Quote
Nick, you said you wanted to stick to existing standards / standard pinout.  Do you have anything CAN based in mind that you want to be compatible with? (and is it something that a hobbyist / artist / etc is likely to have or be able to afford?)

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've felt that for the sorts of uses you mention, and I've thought about, it would make sense to have something that is compatible with standard Ethernet cabling instead - that is, picking the CAN pair so that it is possible to run 100Mbit Ethernet in parallel on the same cable.  (Maybe even PoE.)  It's not such a big deal for hackerspaces to run an extra cable, but I can think of a couple of places where running on an already installed Cat 5 would come in useful.

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?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 22, 2013, 05:07:04 pm
Hi and welcome Magetoo

Unfortunately POE (and for that matter Ethernet RJ45) and CAN RJ45 based pinouts are incompatible from a power POV and could result in shorting, one must be very careful not to mix these, I normally use different shell types, colour coding and or warnings when the two are mixed on a given board/product as it is all too easy to mix them up for the end user.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 22, 2013, 06:50:56 pm
[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.)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 22, 2013, 07:21:18 pm
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 23, 2013, 10:22:03 am
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: EasyRider on October 23, 2013, 01:52:54 pm
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/ (http://vscp.org/)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 23, 2013, 02:56:07 pm
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!. :-)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 23, 2013, 04:31:05 pm
[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/ (http://vscp.org/)[/quote]

Cool I love I love candy, unicorns and rainbows, will take a look ;-)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 23, 2013, 05:29:13 pm
[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?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 23, 2013, 05:37:05 pm
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.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 23, 2013, 05:41:36 pm
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 23, 2013, 08:26:20 pm
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 23, 2013, 08:55:30 pm
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.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 23, 2013, 09:18:16 pm
[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).
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 23, 2013, 09:51:38 pm
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 24, 2013, 12:01:31 am
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 (http://www.ems-wuensche.com/about-can/can-repeater-example.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.microchip.com/forums/download.axd?file=0;587934)

http://www.onsemi.com/pub_link/Collater ... 2700-D.PDF (http://www.onsemi.com/pub_link/Collateral/AMIS-42700-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 (http://www.ems-wuensche.com/about-can/can-gateway-vs-repeater.html), but perhaps KISS apply!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 24, 2013, 12:53:49 am
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 24, 2013, 10:43:34 am
[quote author="Folknology"]
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.[/quote]

Can you be more specific? What makes a cabling system unfriendly to CAN? What would it break?

Quote
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.

You can use two drops (or a single drop with a splitter, as suggested previously) to achieve a multidrop instead of a star layout. Also, a CAN hub/multirepeater is on my todo list. :)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 24, 2013, 10:51:49 am
[quote author="Tarloth"]
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 (http://www.ems-wuensche.com/about-can/can-repeater-example.html)[/quote]

I've heard this suggested, but having two repeaters between each unit imposes a double delay on the bus. The best doc I'd seen so far was this, proposing an architecture for a can bus hub: http://cia.ticktoo.com/assets/files/ttm ... 3f19c4.pdf (http://cia.ticktoo.com/assets/files/ttmedia/raw/d4ac6e95b8b7bc39cbcc9ac53f3f19c4.pdf)

Quote
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.microchip.com/forums/download.axd?file=0;587934)

http://www.onsemi.com/pub_link/Collater ... 2700-D.PDF (http://www.onsemi.com/pub_link/Collateral/AMIS-42700-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 (http://www.ems-wuensche.com/about-can/can-gateway-vs-repeater.html), but perhaps KISS apply!

That on semiconductor chip is incredibly cool. I'd been planning to use a PSoC to do glue logic for a CAN hub; the AMIS-42700 might work out a little more costly, but also way simpler!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: EasyRider on October 24, 2013, 11:06:24 am
[quote author="Tarloth"]
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.
[...]
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.microchip.com/forums/download.axd?file=0;587934)

http://www.onsemi.com/pub_link/Collater ... 2700-D.PDF (http://www.onsemi.com/pub_link/Collateral/AMIS-42700-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 (http://www.ems-wuensche.com/about-can/can-gateway-vs-repeater.html), but perhaps KISS apply![/quote]
I have to admit we also use repeaters on our networks - "dumb" ones (signals are instantly duplicated rather than messages retransmitted); yet even those can't be too dumb - the first forum example shouldn't work, and the reason is a small paragraph in the datasheet from the second link:

Quote
The logic unit described in Table 3 constantly ensures that dominant symbols on one bus line are transmitted to the other bus line without imposing any priority on either of the lines. This feature would lead to an “interlock” state with permanent dominant signal transmitted to both bus lines, if no extra measure is taken. Therefore a feedback suppression is included inside the logic unit of the transceiver. This block masks−out reception on that bus line, on which a dominant is actively transmitted. The reception becomes active again only with certain delay after the dominant transmission on this line is finished.
We use a modest CPLD with a bunch of regular MCP2551s attached to it to implement that exact "mask-out" and "delay", coupled with a "backbone" style star structure - ie. there's only one segment all the others are attached to, making sure no two segments are more than two repeaters apart (these things incur delays - obviously). It works just fine, but since it's a proprietary thing we did, I can't go into too much detail unfortunately.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 24, 2013, 11:06:59 am
This appnote from On demonstrates why simply cross-connecting two transceivers won't work - as well as how to implement feedback supression logic: http://www.onsemi.com/pub_link/Collateral/AND8358-D.PDF (http://www.onsemi.com/pub_link/Collateral/AND8358-D.PDF)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 24, 2013, 11:08:23 am
[quote author="EasyRider"]
Quote
The logic unit described in Table 3 constantly ensures that dominant symbols on one bus line are transmitted to the other bus line without imposing any priority on either of the lines. This feature would lead to an “interlock” state with permanent dominant signal transmitted to both bus lines, if no extra measure is taken. Therefore a feedback suppression is included inside the logic unit of the transceiver. This block masks−out reception on that bus line, on which a dominant is actively transmitted. The reception becomes active again only with certain delay after the dominant transmission on this line is finished.
We use a modest CPLD with a bunch of regular MCP2551s attached to it to implement that exact "mask-out" and "delay", coupled with a "backbone" style star structure - ie. there's only one segment all the others are attached to, making sure no two segments are more than two repeaters apart (these things incur delays - obviously). It works just fine, but since it's a proprietary thing we did, I can't go into too much detail unfortunately.[/quote]

This is exactly what I'd planned on doing, per the paper I posted earlier! A PSoC was just an easy way to integrate the CPLD and supervisory control logic. The On part looks like it's a better and easier option, though.

Edit: I've been looking at VSCP in more detail. I like several things about it:

 - The register model for providing and accessing individual node data
 - The broadcast event model for sending out information from nodes and subscribing to it
 - The decision matrix system for reacting to incoming events (though it's optional)
 - The presence of a GUID for each node
 - The 'nickname' / address discovery process

But it's also way more complicated than the name implies: it defines a vast number of message types, and each one has its own set of parameters. Coding all this into a coherent API would be just about impossible.

I'm wondering if instead we can find or devise a simpler protocol along similar lines. For instance, instead of a thousand different message types, we can define just a few, and each event can specify which message type it uses. There's a lot of overlap in message content in VSCP, but no attempt to combine them into coherent message types.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 24, 2013, 11:35:56 am
Quote
Can you be more specific? What makes a cabling system unfriendly to CAN? What would it break?

Well when wired to these standards there are no spares as such, because the wiring is designed to work with Ethernet 10/100 and 1Gb transceivers. In other words all pairs are accounted for to support those Gigabit network cards when they are plugged in (even if they have only 100Bt switches. Thus your CAN power and and signals will be connecting to the magnetics and either power or signal/power gets shorted through the secondary coils.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 24, 2013, 11:38:06 am
I have also been investigating building efficient low power mixed networks switches, as we currently have to integrate these segment by segment.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 24, 2013, 11:57:30 am
[quote author="Folknology"]Well when wired to these standards there are no spares as such, because the wiring is designed to work with Ethernet 10/100 and 1Gb transceivers. In other words all pairs are accounted for to support those Gigabit network cards when they are plugged in (even if they have only 100Bt switches. Thus your CAN power and and signals will be connecting to the magnetics and either power or signal/power gets shorted through the secondary coils.[/quote]

That only matters if the wire is terminated at one end with an Ethernet switch. Building wiring terminates with a patch panel, though, and there's no obligation to plug it into a switch - you can just as easily plug it into another wire, or into anything else.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 24, 2013, 02:17:29 pm
Quote
I'm wondering if instead we can find or devise a simpler protocol along similar lines. For instance, instead of a thousand different message types, we can define just a few, and each event can specify which message type it uses. There's a lot of overlap in message content in VSCP, but no attempt to combine them into coherent message types.

I agree! I think that VCSP can be use as start point and use the better for us. Indeed I not see that the message collection of VSCP was too complex to implement, but the better way it´s agree here our needs.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 24, 2013, 03:05:53 pm
About the interlock or deadlock of the first link it´s true. When I see this and the user in the forum (and others) said that works I think that would be to good to be true. Perhaps at low speed or with a fault tolerant schema it works, but I put the second link because this silicon has the logic to act as repeater without uController.

I search a bit more and this Application note http://www.onsemi.com/pub_link/Collateral/AND8358-D.PDF (http://www.onsemi.com/pub_link/Collateral/AND8358-D.PDF) explain about the feedback suppression logic  and shown a simplified circuit that may be work. Off course FBS block is the key to avoid interlocking but perhaps with some digging we can develop something. Onsemi circuit cost aprox $4 and I think that it´s OK in cost if permit to me simplified a wiring schema were not only the wire cost itself would be relevant but installation it´s more expensive.

An example CAN-HUB with discrete circuit can be seen in http://www.oschmid.ch/mt/can-hub/can-hub.php (http://www.oschmid.ch/mt/can-hub/can-hub.php) and http://www.oschmid.ch/mt/can-hub4/can-hub4.php (http://www.oschmid.ch/mt/can-hub4/can-hub4.php) and the better one :-)

http://www.oschmid.ch/mt/can-hub5/can-hub5.php (http://www.oschmid.ch/mt/can-hub5/can-hub5.php)


Maybe it works, I need to build one of this and test with an oscilloscope, one more brick to the wall :-)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 24, 2013, 03:49:53 pm
I think using the On Semi chip is going to be the best option for building a hub. This appnote shows what I think is the best way to do it: http://www.onsemi.com/pub_link/Collateral/AND8361-D.PDF (http://www.onsemi.com/pub_link/Collateral/AND8361-D.PDF)

Only problem - an 8 port hub with two uplink/downlink ports requires 6 x 5-input AND gates - not something readily available in 7400 series! A ridiculously simple CPLD may be required for glue logic.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 24, 2013, 04:42:43 pm
Or cascade two 3 AND gates or four 2 AND, one 7408 Works as a 5 input AND. If relative delay it´s a problem use more gates and solve the problem.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 24, 2013, 05:01:35 pm
[quote author="Tarloth"]Or cascade two 3 AND gates or four 2 AND, one 7408 Works as a 5 input AND.[/quote]

The total required for discrete logic is 6 AND gates; doing it with cascading would require even more ICs than just using 8-AND gates, and introduce extra delay.

I think with some creative reuse of the RxO and TxO lines on the On Semi chip, it could be reduced down to 4 x 3-AND gates, though, which only requires two ICs.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 24, 2013, 06:06:07 pm
If we worked at a slightly higher level than just CAN, switches could be intelligent and filter/segment packets automagically so packets only get repeated to segments that require it. Although this would of  course require a scheme (above CAN layer II) where the switch also understand and participate in simple subscribe/publish mechanics.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 24, 2013, 06:11:50 pm
[quote author="Folknology"]If we worked at a slightly higher level than just CAN, switches could be intelligent and filter/segment can packets automagically so packets only get repeated to segments that require it. Although this would of  course require a scheme (above CAN layer II) where the switch also understand and participate in simple subscribe/publish mechanics.[/quote]

I've considered doing that, too. It would have other advantages, such as reducing the restrictions on bus length, even if you just repeat all messages to all segments. It's a lot more complicated, though.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 24, 2013, 06:17:36 pm
Quote
That only matters if the wire is terminated at one end with an Ethernet switch. Building wiring terminates with a patch panel, though, and there's no obligation to plug it into a switch - you can just as easily plug it into another wire, or into anything else.

Actually I was thinking more the other end, user have a nasty habit of just plugging their PCs/laptops into vacant RJ45 sockets expecting them to just work, many are now Gbit interfaces.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 24, 2013, 06:21:51 pm
[quote author="Folknology"]
Quote
That only matters if the wire is terminated at one end with an Ethernet switch. Building wiring terminates with a patch panel, though, and there's no obligation to plug it into a switch - you can just as easily plug it into another wire, or into anything else.

Actually I was thinking more the other end, user have a nasty habit of just plugging their PCs/laptops into vacant RJ45 sockets expecting them to just work, many are now Gbit interfaces.

regards
Al[/quote]

Well, then the obvious solution would be to not have any CAN bus plugged in there when it's not in use - which would be a bad idea for termination reasons anyway. :)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 24, 2013, 06:27:55 pm
Quote
I've considered doing that, too. It would have other advantages, such as reducing the restrictions on bus length, even if you just repeat all messages to all segments. It's a lot more complicated, though.

Well the complexity will be more than just a few logic gates clearly and I have some ideas about getting the cost of that down given a simple enough Publish/subscribe events scheme. Compared to a simple CAN network or even one with simple repeaters it is more scalable. With just CAN or CAN + Repeaters the traffic adds up and congests making prioritisation and arbitration less and less effective. Although repeaters buy you greater length they also introduce other problems like delays or deadlocks. With an intelligent approach you effectively have more tools in the box to shape you network. That's what makes a smart approach more attractive to me personally.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 24, 2013, 06:36:54 pm
[quote author="Folknology"]Well the complexity will be more than just a few logic gates clearly and I have some ideas about getting the cost of that down given a simple enough Publish/subscribe events scheme. Compared to a simple CAN network or even one with simple repeaters it is more scalable. With just CAN or CAN + Repeaters the traffic adds up and congests making prioritisation and arbitration less and less effective. Although repeaters buy you greater length they also introduce other problems like delays or deadlocks. With an intelligent approach you effectively have more tools in the box to shape you network. That's what makes a smart approach more attractive to me personally.[/quote]

It's definitely worth consideration - but it requires you to discard the super simple broadcast event system that things like VSCP use, which has a lot of attractive advantages. It also introduces issues with routing and discovery that could complicate the protocol a lot!

Do you have a rough sketch for how you'd like such a system to work?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 24, 2013, 06:44:04 pm
[quote author="nickjohnson"]Do you have a rough sketch for how you'd like such a system to work?[/quote]

Not really as such it's mostly in my head, one of the key requirements however would be a distributed publish and subscribe registry. This could exist on switches and or individual µC (segment master nodes).

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 24, 2013, 07:59:44 pm
I think that when we have a first network working we can see some points that underestimated and other that not.

At this point it´s possible that and intelligent switch would be a very clever solution and his cost wouldn´t a problem. In my particular case with an intelligent repeater I can replace a hub or a switch because I have a lot of traffic that it´s only interesting to a stub or sub net of nodes and can be filter to the primary bus. With a ucontroller with two can ports I can use the filters in the stack to determine message forwarding. This is clean, simple and relatively cheap in cost and software. But I not know that this is appropriate in general.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 25, 2013, 03:17:38 am
[quote author="nickjohnson"][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]
As long as one is making own hardware in the form of nodes, and putting RJ45 connectors on those, building one's own splitters doesn't seem too much of a step.  Especially if there's going to be some custom PoE-like adapter involved anyway.

Quote
[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.)
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]
PoE can use a (non-obvious?) scheme where each pair is also one conductor for the power side.  With two pairs, you have power and ground, while differential signalling on those pairs is also simultaneously used for data.  That's what I had in mind.  That might mean running the CAN network without a ground, the implications of which I'm not sure about.  But I don't see why it wouldn't work - how complicated it will be to build, and how much of the Ethernet design one can reuse is the question.


Regarding repeaters and topologies and such; interesting stuff.  Nothing to add except I hope it's still going to be simple and cheap.  :-)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 25, 2013, 08:18:04 am
[quote author="magetoo"][quote author="nickjohnson"][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]
As long as one is making own hardware in the form of nodes, and putting RJ45 connectors on those, building one's own splitters doesn't seem too much of a step.  Especially if there's going to be some custom PoE-like adapter involved anyway.[/quote]

Using ethernet pairs would allow running both Ethernet and CAN on the same wires, though, with a standard splitter at both ends.

Quote
Quote
[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.)
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 -!
PoE can use a (non-obvious?) scheme where each pair is also one conductor for the power side.  With two pairs, you have power and ground, while differential signalling on those pairs is also simultaneously used for data.  That's what I had in mind.  That might mean running the CAN network without a ground, the implications of which I'm not sure about.  But I don't see why it wouldn't work - how complicated it will be to build, and how much of the Ethernet design one can reuse is the question.[/quote]

CAN doesn't actually use differential signalling (or transformer isolation); it uses a pair with an impedance of 60 ohms and relies on current flow through the terminator to establish a reliable signal. I don't think there's a way you can piggyback power on that.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 26, 2013, 06:11:40 am
[quote author="nickjohnson"]Using ethernet pairs would allow running both Ethernet and CAN on the same wires, though, with a standard splitter at both ends.[/quote]
We're in agreement there.  But I don't believe that will save much (work, money) in practice, perhaps we're coming at this from different perspectives.

Quote
CAN doesn't actually use differential signalling (or transformer isolation); it uses a pair with an impedance of 60 ohms and relies on current flow through the terminator to establish a reliable signal. I don't think there's a way you can piggyback power on that.
I'm trying to see what you're getting at, but I'm kind of lost.  Are you saying that the nodes sense the current that is going through the bus, not the voltage?  Would be grateful if you would explain where exactly things would fail.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 26, 2013, 07:32:59 pm
[quote author="magetoo"][quote author="nickjohnson"]Using ethernet pairs would allow running both Ethernet and CAN on the same wires, though, with a standard splitter at both ends.[/quote]
We're in agreement there.  But I don't believe that will save much (work, money) in practice, perhaps we're coming at this from different perspectives.

Quote
CAN doesn't actually use differential signalling (or transformer isolation); it uses a pair with an impedance of 60 ohms and relies on current flow through the terminator to establish a reliable signal. I don't think there's a way you can piggyback power on that.
I'm trying to see what you're getting at, but I'm kind of lost.  Are you saying that the nodes sense the current that is going through the bus, not the voltage?  Would be grateful if you would explain where exactly things would fail.[/quote]

The nodes sense the voltage on the CANH and CANL lines, relative to each other and ground - they're still ground referenced, so not truly differential.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 26, 2013, 10:54:41 pm
Here's a design for a basic CAN BUS hub using the AMIS-42700:

(http://https://raw.github.com/arachnidlabs/uCAN/master/hub/hub%20schematic.png) (http://https://raw.github.com/arachnidlabs/uCAN/master/hub/hub%20schematic.png)

PCB layout here: http://gerblook.org/pcb/yCrpjNxd78duAt7DFdCnuM (http://gerblook.org/pcb/yCrpjNxd78duAt7DFdCnuM)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 27, 2013, 01:31:53 am
[quote author="nickjohnson"]The nodes sense the voltage on the CANH and CANL lines, relative to each other and ground - they're still ground referenced, so not truly differential.[/quote]
As I have understood things, in a (Hi-speed) CAN network, nodes can fall back to comparing with ground in the event that one of the CANx lines is faulty, but the whole thing works just fine without it, and is designed to operate primarily by sensing a differential on the CANx lines.  That's how you get the noise immunity after all.

For the things I have in mind (indoors, non-critical), I don't really see the need for the level of fault tolerance that would come with having a signal ground line there as backup.  And if one of the CANx lines is gone, the other probably is too..
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 27, 2013, 10:12:42 am
[quote author="magetoo"][quote author="nickjohnson"]The nodes sense the voltage on the CANH and CANL lines, relative to each other and ground - they're still ground referenced, so not truly differential.[/quote]
As I have understood things, in a (Hi-speed) CAN network, nodes can fall back to comparing with ground in the event that one of the CANx lines is faulty, but the whole thing works just fine without it, and is designed to operate primarily by sensing a differential on the CANx lines.  That's how you get the noise immunity after all.

For the things I have in mind (indoors, non-critical), I don't really see the need for the level of fault tolerance that would come with having a signal ground line there as backup.  And if one of the CANx lines is gone, the other probably is too..[/quote]

You're probably right, but I'm still not sure how you'd provide power over CAN. The drivers typically drive the CAN lines between their ground and +5v rails; how would you transport power over the same lines with standard CAN interfaces?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 27, 2013, 01:43:54 pm
I think that magetoo propouse use the other pair of the RJ-45 to power device, not the same wires. A friend need to use one RJ45 for ethernet, 12 volt and CAN and all work OK for three years. It´s dirty, but works.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 27, 2013, 03:41:13 pm
Here's a design for a uCAN cape for Beaglebone Black:

(http://https://raw.github.com/arachnidlabs/uCAN/master/cape/uCAN%20Cape%20Schematic.png) (http://https://raw.github.com/arachnidlabs/uCAN/master/cape/uCAN%20Cape%20Schematic.png)

And the layout: http://http://gerblook.org/pcb/oCqzieHDg9eYeM4S7WABhU
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 27, 2013, 03:46:51 pm
Also, the first PCBs came in a few days ago. I've put together an Arduino shield and a power injector so far:

(http://https://lh3.googleusercontent.com/-dAkSdCOU8JM/Um0mR42Yu-I/AAAAAAAAEv4/9Xx9_nJQu40/s506-p/IMG_20131026_101028.jpg)

(http://https://lh6.googleusercontent.com/-ayZnkmbLnT8/Um0mR-5CC3I/AAAAAAAAEv4/J03rWbt5l5k/w504-h506-p/IMG_20131026_101035.jpg)

Powering the board works fine, but I haven't had a chance yet to test communications, since I'm missing a header I need for both Arduino and RPi boards.

I'm going to be putting together a few of these and sending out sets - power injector, Arduino shield, and either RPi or Beaglebone board, to interested people in the next week or so. Please post here if you're keen, along with what you'd like to do with it.

Bear in mind that this is still very early - we haven't even started to define a concrete software stack or APIs yet - so this is strictly hackers-only. Priority will be given to anyone who expresses interest in working on the software stack (in the open, of course)!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 27, 2013, 08:44:38 pm
I've also just finished reviewing all the CAN-based protocols I could find, and the results are a bit depressing. CANOpen isn't - you have to fill out a copyright agreement to even see the specs. None of the alternatives are any better, except VSCP, which is at least an open specification - but as previously detailed, is really pretty complicated.

I'm thinking that designing our own may still be the best option. One decision that will have to be made as a result is how far up the OSI stack we want to go: do we define purely up to the transport layer, and let applications define the rest themselves? Or do we take the approach most other CAN based protocols have, and attempt to define everything?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 28, 2013, 03:13:00 am
[quote author="nickjohnson"]I'm thinking that designing our own may still be the best option. One decision that will have to be made as a result is how far up the OSI stack we want to go: do we define purely up to the transport layer, and let applications define the rest themselves? Or do we take the approach most other CAN based protocols have, and attempt to define everything?[/quote]
Well, if the existing alternatives are big and complicated, and they're no good, then it seems like a good first step that a new one should be as small and simple as possible, right?  Also, "hobbyist projects, art installations, interactive exhibits, hackspaces, etc" doesn't sound like things that are going to be compatible with big standards documents or much protocol overhead.

Throwing out some ideas: I guess one would at least want to agree on some broad priority levels if different hardware is to work together (say, time critical, important, not important, bulk).  A few reserved IDs in each class, maybe a small multicast range for routed networks ("fire alarm", "shutdown", or "all lights off").  Perhaps some way to extend the adressing space ("id 0xfoo means that the sub-id is in the first data byte") if you have many nodes of the same type, and one might want a standard way to send and reassemble long data packets...

It can't be something that requires a lot of code though, anything fancy has to be optional IMHO.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 28, 2013, 04:26:59 am
Some thoughts on the whole power thing.

Assumptions: For the places this is likely to be going (homes, hackerspaces, events, etc), I'm assuming that there's a good chance there will be some Ethernet cabling already in place, and equipment using it.  I'm also assuming there's unlikely there will be any CAN-on-Cat5 equipment. (based only on how I've never heard of it before this thread, but YMMV...)

Given those assumptions, it seems that there would be some benefit to sticking to the standard CAN on RJ45 pinout, but not necessarily a huge one.  It also seems that being able to run alongside regular Ethernet (although at 100Mbit only) could potentially be useful, and that being able to at least coexist with Power over Ethernet would be important.


With the proposed / standard pinout, bad stuff might happen if, for example, there is a misunderstanding and someone plugs in a regular consumer PoE adapter, since it would short out the uCAN power lines.  I think accidentally plugging in the powered uCAN cable instead of the network cable into ones laptop (and this will happen) might also have some expensive side effects.

So, for interoperability, I suggest either doing what PoE mode A is doing and transporting data over the same pairs as power (cool!), or doing what PoE mode B is doing and using the same spare pairs in the same way (boring, and limits using existing cabling - but would allow using regular consumer PoE equipment), or dropping the power bit entirely.


I've been arguing for the first option, I'm hoping that we could duplicate what is done with Ethernet and don't really see the need for physical compatibility with other Hi-speed CAN networks, but I'm not sure how this would work on a bus with many nodes.

Not sure how power would work on a bus with many nodes either, for that matter.  Is it going to be used beyond just point-to-point connections, like most PoE things seem to be?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 09:32:43 am
[quote author="magetoo"]Some thoughts on the whole power thing.

Assumptions: For the places this is likely to be going (homes, hackerspaces, events, etc), I'm assuming that there's a good chance there will be some Ethernet cabling already in place, and equipment using it.  I'm also assuming there's unlikely there will be any CAN-on-Cat5 equipment. (based only on how I've never heard of it before this thread, but YMMV...)

Given those assumptions, it seems that there would be some benefit to sticking to the standard CAN on RJ45 pinout, but not necessarily a huge one.  It also seems that being able to run alongside regular Ethernet (although at 100Mbit only) could potentially be useful, and that being able to at least coexist with Power over Ethernet would be important.


With the proposed / standard pinout, bad stuff might happen if, for example, there is a misunderstanding and someone plugs in a regular consumer PoE adapter, since it would short out the uCAN power lines.  I think accidentally plugging in the powered uCAN cable instead of the network cable into ones laptop (and this will happen) might also have some expensive side effects.

So, for interoperability, I suggest either doing what PoE mode A is doing and transporting data over the same pairs as power (cool!), or doing what PoE mode B is doing and using the same spare pairs in the same way (boring, and limits using existing cabling - but would allow using regular consumer PoE equipment), or dropping the power bit entirely.[/quote]

Well argued. Annoying to have to break my existing prototypes, but probably justified. I don't think dropping power full stop is an option, though, so I'll look into PoE mode B, and ways to avoid Ethernet conflicts.

Quote
I've been arguing for the first option, I'm hoping that we could duplicate what is done with Ethernet and don't really see the need for physical compatibility with other Hi-speed CAN networks, but I'm not sure how this would work on a bus with many nodes.

I'm still open to this - I just don't see how you can carry power on CAN pairs.

Quote
Not sure how power would work on a bus with many nodes either, for that matter.  Is it going to be used beyond just point-to-point connections, like most PoE things seem to be?

For multiple low-current devices, 0.5A - 1A @ 24V ought to be sufficient. For higher powered stuff, there's the CAN HUB.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 11:04:51 am
Okay, so switching to a PoE-compatible pinout it is. Here's what I'm proposing:

Pin 1: CAN_H (unchanged)
Pin 2: CAN_L (unchanged)
Pin 3: Unused (was GND)
Pins 4&5: DC+
Pin 6: Unused (unchanged)
Pins 7&8: DC- (was DC+ and DC-)

I'm undecided if I should throw out my already-manufactured PCBs and get a new set, or continue using the old pinout for now, and only switch over when making a second round of prototypes or a production run.

Regarding the protocol, for simplicity I'm thinking that sticking with the OSI model works best. Here's a brief thought:

Using 29 bit extended IDs only, the ID field is broken up into subfields:

High priority: 1 bit
Protocol ID: 4 bits
Sender node ID: 8 bits
Protocol-specific: 16 bits

The high priority bit is set only on urgent messages, and overrides the normal protocol based priority scheme. Protocol IDs specify the format of the message and of the 16 bit protocol-specific part of the CAN address. A sender node ID is 8 bits, with 255 being reserved for 'no ID'.

Suggested sub-protocols:

Protocol 0: DHCP/ICMP(-esque): Allows assignment of a node ID using a similar scheme to VSCP, with either a centralised allocator managing IDs, or discovery probing. Also handles basic network management issues like ping/pong. This is the only mandatory protocol.

UDP(-esque): 8-byte datagrams. The protocol specific field is divided up into recipient ID (255=broadcast) and port number

Register access: Read and write an array of registers on a host. The protocol specific field is divided up into recipient ID and command fields. A standard set of registers are defined for things such as manufacturer and device info, with the remainder being user-defined.

Event broadcast: For sending event based information to all recipients. Protocol specific field denotes event class, which defines data format, and event type.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 28, 2013, 01:21:14 pm
I´m reading VCSP now, but I have a lot of work at this days. We are going to analyse the option of use VCSP as is?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 01:28:59 pm
[quote author="Tarloth"]I´m reading VCSP now, but I have a lot of work at this days. We are going to analyse the option of use VCSP as is?[/quote]

I read through it and concluded it was too complicated: the minimum requirement set is too large, and the event protocol is poorly organised, with little provision for a simple API with message reuse.

I'm open to second opinions, though!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 01:41:52 pm
[quote author="magetoo"]
.....Perhaps some way to extend the adressing space ("id 0xfoo means that the sub-id is in the first data byte") if you have many nodes of the same type, and one might want a standard way to send and reassemble long data packets...[/quote]

Don't forget the DLC field is 4bits (0-15) and the frame payload has a max byte width of only 8, that could leave room to indicate extra frames coming. For example the second range beyond 8 could indicate number of full (8 byte) frames to follow

However we should be careful about encouraging too much data on the network, such frames would need to be transmitted at a low priority

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 01:49:20 pm
[quote author="nickjohnson"]
Using 29 bit extended IDs only, the ID field is broken up into subfields:

High priority: 1 bit
Protocol ID: 4 bits
Sender node ID: 8 bits
Protocol-specific: 16 bits

The high priority bit is set only on urgent messages, and overrides the normal protocol based priority scheme. Protocol IDs specify the format of the message and of the 16 bit protocol-specific part of the CAN address. A sender node ID is 8 bits, with 255 being reserved for 'no ID'.
[/quote]

CANBus uses a 'Hard' prioritisation arbitration scheme involving the first 11bits so those will always control priority, I don't think those can be changed? You can however mess with the extended 18bits AFAIK.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 01:55:25 pm
[quote author="Folknology"][quote author="magetoo"]
.....Perhaps some way to extend the adressing space ("id 0xfoo means that the sub-id is in the first data byte") if you have many nodes of the same type, and one might want a standard way to send and reassemble long data packets...[/quote]

Don't forget the DLC field is 4bits (0-15) and the frame payload has a max byte width of only 8, that could leave room to indicate extra frames coming. For example the second range beyond 8 could indicate number of full (8 byte) frames to follow

However we should be careful about encouraging too much data on the network, such frames would need to be transmitted at a low priority[/quote]

I just checked, and MCP2515 permits sending DLCs >8; it's unclear, however, if it will faithfully report received codes >8 or not. Using the field like this may not be a good idea.

Quote
CANBus uses a 'Hard' prioritisation arbitration scheme involving the first 11bits so those will always control priority, I don't think those can be changed?

Extended frames use a 29 bit ID, all of which can be used for arbitration. What I was proposing above is one way to subdivide this field for the protocol. On further discussion, though, I think putting the protocol specific part of the ID earlier makes more sense:

Priority:1
Protocol:4
Protodata:16
Sender:8
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 02:06:53 pm
The 29 bits don't come in a continuous stream they have SRR+IDE bits in between the 11 and 18 bits.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 02:29:05 pm
[quote author="Folknology"]The 29 bits don't come in a continuous stream they have SRR+IDE bits in between the 11 and 18 bits.[/quote]

They do, but this doesn't matter - if the only CAN messages on the bus have extended IDs, those bits will always be recessive, and so will never affect arbitration.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Tarloth on October 28, 2013, 02:49:51 pm
Quote
I read through it and concluded it was too complicated: the minimum requirement set is too large, and the event protocol is poorly organised, with little provision for a simple API with message reuse.

I'm open to second opinions, though!

Actually I respect  the work of others and think that in general they took some decision in base to constraints. I´m not read the entire protocol and see that it´s not wide extending but I haven´t any reason to think that we can do something better working from the scratch if we not discuss first EXACTLY what are the use and boundary of our sub-protocol.

You propose a series of datagrams species, but what is the scenario? Which are the limits to our design? Which is the general philosophy? What are the physical problems that we need to solve in practice? Connectors, wiring and pin out is only a small part of real word problematic.

To this point, reading the previous post I think that we are plan to working in a multi-master, long wire (more than 20 meters), event based protocol that must minimize the controller software footprint (please, correct me if this is not accurate).

In resume, the same that I ask from the beginning, exactly what kind of data we are moving in this protocol and which are their clear limits? It´s impossible to plan a protocol that works in every scenario with every data type and serves all the purposes. I think that I share in thick line the objectives with folknology, but what about the others?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 02:53:00 pm
[quote author="nickjohnson"]
They do, but this doesn't matter - if the only CAN messages on the bus have extended IDs, those bits will always be recessive, and so will never affect arbitration.[/quote]
Does all of this mean no RTRs?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 03:00:33 pm
[quote author="Tarloth"]
Quote
I read through it and concluded it was too complicated: the minimum requirement set is too large, and the event protocol is poorly organised, with little provision for a simple API with message reuse.

I'm open to second opinions, though!

Actually I respect  the work of others and think that in general they took some decision in base to constraints. I´m not read the entire protocol and see that it´s not wide extending but I haven´t any reason to think that we can do something better working from the scratch if we not discuss first EXACTLY what are the use and boundary of our sub-protocol.[/quote]

I don't disagree that they took reasonable decisions - I'm just saying that I think there's some stuff it does wrong, such as defining hundreds of messages without any common datatypes, and that there are other things that are ill suited to uCAN's goals.

Quote
You propose a series of datagrams species, but what is the scenario? Which are the limits to our design? Which is the general philosophy? What are the physical problems that we need to solve in practice? Connectors, wiring and pin out is only a small part of real word problematic.

To this point, reading the previous post I think that we are plan to working in a multi-master, long wire (more than 20 meters), event based protocol that must minimize the controller software footprint (please, correct me if this is not accurate).

Yes, that seems accurate.

Quote
In resume, the same that I ask from the beginning, exactly what kind of data we are moving in this protocol and which are their clear limits? It´s impossible to plan a protocol that works in every scenario with every data type and serves all the purposes. I think that I share in thick line the objectives with folknology, but what about the others?

It's difficult to be specific when it's designed for a fairly general purpose - low power, low speed, and low cost networking for microcontrollers. Non-goals are handling of bulk data and large switched or routed networks. Goals are low overhead, simplicity of implementation, and general purpose applicability. At least as I see it.

The protocols I roughly outlined were intended to serve those purposes. Protocols like the event broadcast one provide for common needs expressed in other protocols like VSCP and CANopen for broadcasting events to multiple receivers. Likewise for register access, another protocol shared by VSCP and CANopen, and useful as a simple interface for devices (see the prevalence of this model with I2C for instance). A datagram protocol makes it possible for users that want to do something not provided for by either of those abstractions to do so simply.

Quote
Does all of this mean no RTRs?

I don't think RTRs are necessary - but this system doesn't preclude them.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 03:48:11 pm
OK please forgive me, I am not familiar with MCP2515 operation (I normally use bit bang type transceivers), does this mean you can dynamically disable its priority arbitration?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 04:37:00 pm
[quote author="Folknology"]OK please forgive me, I am not familiar with MCP2515 operation (I normally use bit bang type transceivers), does this mean you can dynamically disable its priority arbitration?[/quote]

No, arbitration is built into the CAN physical level protocol. I'm not sure I understand the issue; if all nodes send CAN packets with extended identifiers, arbitration will be resolved identically to if the 29 bit ID were contiguous.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 04:55:20 pm
I am a little rusty, it's been a while since I last did any CAN work. But I recall when one is writing a state machine for bit banging through a CAN transceiver, one would check each bit returned through the receiver loopback during the 11 (actually 12) bit arbitration. When you see a bit returned (during the arbitration bits) that isn't what you sent, you cease transmission as it meant you lost the bus arbitration (you had a lower priority than someone else on the bus). The winner of course just carries on with their transmission and no time is lost (the magic of CAN!). Now if you wish to use a non standard prioritisation scheme you can do this by changing your bit bang state machine, however with an SPI based CAN transceiver I would imagine it has a hardware state machine for this, in which case how do you adapt it?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 05:30:03 pm
[quote author="Folknology"]I am a little rusty, it's been a while since I last did any CAN work. But I recall when one is writing a state machine for bit banging through a CAN transceiver, one would check each bit returned through the receiver loopback during the 11 (actually 12) bit arbitration. When you see a bit returned (during the arbitration bits) that isn't what you sent, you cease transmission as it meant you lost the bus arbitration (you had a lower priority than someone else on the bus). The winner of course just carries on with their transmission and no time is lost (the magic of CAN!). Now if you wish to use a non standard prioritisation scheme you can do this by changing your bit bang state machine, however with an SPI based CAN transceiver I would imagine it has a hardware state machine for this, in which case how do you adapt it?[/quote]

We're not using a non standard arbitration scheme, we're using the CAN address field (which is what's used for arbitration) to convey this data. This is the same approach more or less all CAN based protocols take.

Arbitration isn't only over the 11 bit address field, it's over the entire message header, so extended messages will be arbitrated correctly. Messages with standard identifiers always win out over messages with extended identifiers (with the same 11-bit prefix), but since all messages on the network will be extended ones, this does not matter.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 06:25:42 pm
Ok can I clarify some of what you are suggesting, just to make sure I get it:

1) There is no backward compatibility with standard CAN packets, devices or tools. Basically only uCAN devices can play on this network?
2) Message prioritisation can be effected by things like protocol data, not just the priority?
3) RTR like frames are not supported?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 06:36:22 pm
[quote author="Folknology"]1) There is no backward compatibility with standard CAN packets, devices or tools. Basically only uCAN devices can play on this network?[/quote]

Any CAN device can connect, but if it doesn't understand uCAN it's not going to be very useful. Any CAN analyzer would work fine. This is standard CAN with a protocol layered on top of it, exactly like VSCP or CANopen.

Quote
2) Message prioritisation can be effected by things like protocol data, not just the priority?

Any subfield of the CAN message ID can affect prioritisation.

Quote
3) RTR like frames are not supported?

I don't see any need for them in this protocol, but nothing prohibits them from being used.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 07:05:27 pm
So we are moving toward a message addressed protocol rather than context addressed one. We will also limit ourselves to 254 devices on a given network?

And that certain sending nodes will win the bus more frequently for given protocols (address bias)?

I have always wanted a fast RTR, going to 29 bits slows this somewhat, however if we could implement realtime databyte fill in, we could have super responsive short request as well as messages.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 07:38:10 pm
[quote author="Folknology"]So we are moving toward a message addressed protocol rather than context addressed one. We will also limit ourselves to 254 devices on a given network?[/quote]

Higher level protocols can be defined as unicast or multicast, as they wish. I anticipate there'd be both sorts in common use, with the 'event notification' type used by most existing protocols being quite common.

Given a CAN bus run is limited to about 500 meters at 125kbaud, there doesn't seem much point in addressing more than 256 devices. In fact, it may be justified to reduce the address space to 7 bits.

On further discussion on IRC, we're wondering if it doesn't make sense to allow more bits for priority, and to specify a single header format for unicast protocols, so a node can listen to messages addressed to it with a single mask/filter, regardless of the protocol. The header would thus be divided up something like this:

priority:2
protocol:4
unicast:1
protocol_fields:14
sender_address:8

There being a separate list of protocols for multicast and unicast, and unicast protocols (where unicast is 0) always setting the last 8 bits of protocol_fields to the recipient address.

Quote
And that certain sending nodes will win the bus more frequently for given protocols (address bias)?

Lower numbered nodes will win, but only if all else is equal - priority, protocol, protocol fields, and recipient address (where applicable). At this point this is more a tiebreaker than something that will have a substantial impact on traffic.

Quote
I have always wanted a fast RTR, going to 29 bits slows this somewhat, however if we could implement realtime databyte fill in, we could have super responsive short request as well as messages.

On a max size packet, the difference between an 11 and 29 bit identifier isn't huge, and it allows for much more flexible addressing and masking. I think it makes sense to use the longer identifiers exclusively.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 07:47:31 pm
How would this scheme implement register based data?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 07:59:18 pm
[quote author="Folknology"]How would this scheme implement register based data?[/quote]

That would be one of the unicast protocols; it would likely use the remaining address subfields to specify operation type (read or write), and specify the address and data inside the message. I think it would make sense to reserve some of the registers for common information such as manufacturer and device info, and leave the remainder open for device specific data.

I also think the protocol should be optional - network management should be the only required protocol - but I expect most devices would implement it anyway.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 08:32:04 pm
I've started on some basic documentation of everything so far, to be found here: https://github.com/arachnidlabs/uCAN/wi ... ocol-Stack (https://github.com/arachnidlabs/uCAN/wiki/Protocol-Stack) . Pull requests are welcome!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 09:54:22 pm
Can we increase the maximum current to 4A
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 10:32:50 pm
We might also want to reserve a gateway address
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 28, 2013, 11:02:29 pm
[quote author="Folknology"]Can we increase the maximum current to 4A[/quote]

That's more down to the wiring than anything else. The Power Over Ethernet spec only provides for 600mA per mode; CAT5 cable is actually rated to 0.577A per conductor, so with two pairs anything up to 1.15A @ 24V (=27.6W) would be permissible. Anything higher will need an external supply.

The hub, of course, will be able to supply that much current per port, not just in total.

Edit: Of course, 1.15A @ 24V works out to 4.4A @ 5V with 80% converter efficiency. We can double that if we permit up to 48V, but I'm concerned with the increase in cost that requiring that would impose on implementers.

Quote
We might also want to reserve a gateway address

That really only works if we have routable addresses; presently we have only hardware addresses.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 28, 2013, 11:35:11 pm
Yeah CAT 5 POE current limits are based on worse case 26 AWG wiring and distances as well as cablestacking/bundling accumulative heating effects. In our applications we don't suffer from any of those stacking/bundling issues, in addition we go up to 22AWG which exhibits about 4-5 times improvements on cable losses and proportional heating effects. Unlike Ethernet we don't have the same cabling requirements with uCAN (we could actually run over CAT 3) so I don't think we should be specifying any cabling  maximums. Rather leave that for the network engineer to calculate based on their cabling,loads and distances etc... then we can make this as applicable to the widest possible audience.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 04:05:24 am
[quote author="nickjohnson"]On further discussion on IRC, we're wondering if it doesn't make sense to allow more bits for priority, and to specify a single header format for unicast protocols, so a node can listen to messages addressed to it with a single mask/filter, regardless of the protocol. The header would thus be divided up something like this:

priority:2
protocol:4
unicast:1
protocol_fields:14
sender_address:8

There being a separate list of protocols for multicast and unicast, and unicast protocols (where unicast is 0) always setting the last 8 bits of protocol_fields to the recipient address.[/quote]

To better make use of the filtering available in chips, I'd suggest a slight modification.

priority:2
type:1  (control or datagram)
address: 8

For broadcast and network management, you can allocate some addresses (e.g. 0x00 or 0xFF for broadcast, 0xFE for YARP). The control and datagram may use different formats for the extended bits. For example

Control message (address is the target)
sender address: 8
control command: 8
command flags: 2

Datagram message (address is the source)
datagram protocol: 3 (is 8 plenty?)
protocol specific: 15

This way a device only has to listen to the first 11 bits to know if it needs to process the message. Control messages are used to initiate datagrams, the device then updates its filters and prepares appropriate buffers (or aborts the datagram with a control message if it can't).

This also allows more flexible use of the base frame format (MACs can match on the IDE and RTR bits as part of the first 11 bits). You can send a base frame RTR if there is a need for RTRs. Or use a base frame datagram type to represent an event protocol.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 08:25:56 am
[quote author="bharrisau"]To better make use of the filtering available in chips, I'd suggest a slight modification.

priority:2
type:1  (control or datagram)
address: 8

For broadcast and network management, you can allocate some addresses (e.g. 0x00 or 0xFF for broadcast, 0xFE for YARP). The control and datagram may use different formats for the extended bits. For example

Control message (address is the target)
sender address: 8
control command: 8
command flags: 2

Datagram message (address is the source)
datagram protocol: 3 (is 8 plenty?)
protocol specific: 15

This way a device only has to listen to the first 11 bits to know if it needs to process the message. Control messages are used to initiate datagrams, the device then updates its filters and prepares appropriate buffers (or aborts the datagram with a control message if it can't).[/quote]

CAN is typically implemented in hardware; we aren't really given the option to stop listening, and there's no CPU overhead in any case to process the entire message. I don't think there's any real benefit to dividing things up specifically into the first 11 bits.

I'm not sure I follow what you mean by "Control messages are used to initiate datagrams" - are you saying every datagram would have to be preceded by a control message? To what end?

Also, this scheme, reusing address for both dest and source, would appear to have a couple of issues: There's no way to address a datagram to a specific target, and you can't set a single filter for all messages addressed to you (assuming datagrams put the destination in their protocol-specific field).
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 09:09:37 am
(That's a lot of posts in a short time, or is it just me?)

This already is starting to look a bit top heavy to me, so I'll sketch out my ideas a bit.  It's easier to add more stuff, so I guess I'll argue for minimalism here instead (or "be the Luddite")..


I see the need for four priority classes; they would be something like:

0 : Time critical - for real-time control for our maglev trains and particle accelerators and such.

1 : Important - for things that really should be delivered, but doesn't have real-time constraints.  Door locks, lights?

2: Nonimportant - for things that may be dropped or resent, say outdoor temperature readings, etc.  If we want to allocate IDs/addresses centrally, a DHCP-like mechanism could go here too.

3: Bulk - someone is going to want to try streaming music to all their rooms over this thing eventually; might as well have a low-priority class for that.  Also firmware updates, blocks of settings ("SysEx dumps") and that sort of thing.

That's two bits - obviously the top two.


Eight bits for message ID, which are all left as "user defined" at this point, but should have a few reserved ones in the 0xFn range - I'm thinking maybe using one for all "network stuff", and a couple left open for the future.

One bit, at the bottom, for routed / not routed, so that semi-dumb interconnection nodes can choose whether to forward messages on to other segments.  Or maybe that's a fully dumb idea, and it could be more useful as a version bit or something else.  Maybe a one means that the eight-bit ID is an address, and the data bytes are part of a higher layer?

That's eleven bits, and honestly I think that is enough at this layer.


I don't see the need for duplicating IP, with all those sender/receiver addresses and multiple protocols, what are the scenarios for when this becomes important?  And are those scenarios the ones where one could easily add an Ethernet shield to ones Arduino project and run IP instead?

The only really obvious things I can come up with are fairly centralized - the central Raspberry Pi board talking to sensors, the door locks being remotely controlled, the LED lighting being synced to the music, and that sort of thing.  It seems to me that there's a lot that could go into the data bytes instead, if necessary.

I haven't read up on any of the other protocol stacks, do they use more bits to do anything useful?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 09:22:40 am
[quote author="magetoo"](That's a lot of posts in a short time, or is it just me?)

This already is starting to look a bit top heavy to me, so I'll sketch out my ideas a bit.  It's easier to add more stuff, so I guess I'll argue for minimalism here instead (or "be the Luddite")..


I see the need for four priority classes; they would be something like:

0 : Time critical - for real-time control for our maglev trains and particle accelerators and such.

1 : Important - for things that really should be delivered, but doesn't have real-time constraints.  Door locks, lights?

2: Nonimportant - for things that may be dropped or resent, say outdoor temperature readings, etc.  If we want to allocate IDs/addresses centrally, a DHCP-like mechanism could go here too.

3: Bulk - someone is going to want to try streaming music to all their rooms over this thing eventually; might as well have a low-priority class for that.  Also firmware updates, blocks of settings ("SysEx dumps") and that sort of thing.

That's two bits - obviously the top two.[/quote]

That's pretty much exactly the scheme I documented on the wiki; I'm glad to see I'm not crazy. :)


Quote
Eight bits for message ID, which are all left as "user defined" at this point, but should have a few reserved ones in the 0xFn range - I'm thinking maybe using one for all "network stuff", and a couple left open for the future.

What is the message ID used to denote, exactly? Judging by the reserved IDs, it sounds like a protocol identifier, but from what you say later that doesn't appear to be the case.

Quote
One bit, at the bottom, for routed / not routed, so that semi-dumb interconnection nodes can choose whether to forward messages on to other segments.  Or maybe that's a fully dumb idea, and it could be more useful as a version bit or something else.  Maybe a one means that the eight-bit ID is an address, and the data bytes are part of a higher layer?

I'd like to support routing, but I think it needs a lot more consideration. CAN's realtime nature allows a lot of assumptions that a routed network doesn't have - for instance, that if a message is sent without collision, all nodes had an opportunity to see it.

Quote
That's eleven bits, and honestly I think that is enough at this layer.


I don't see the need for duplicating IP, with all those sender/receiver addresses and multiple protocols, what are the scenarios for when this becomes important?  And are those scenarios the ones where one could easily add an Ethernet shield to ones Arduino project and run IP instead?

Fair point, but I think the protocols I've proposed aren't particularly complicated. They're specifically proposed to address the most common capabilities of CAN-based protocols, plus arbitrary datagrams for those who would prefer a more UDP-esque abstraction.

Also, I'm fairly sure we have to include the sender address in the header, because CAN defines it as an error if there are still two or more transmitters at the end of arbitration. Having a sender address provides a tie-breaker to ensure that never happens. So with an 8 bit sender address and an 8 bit recipient address, we're already over 11 bits, at least for unicast messages.

Quote
The only really obvious things I can come up with are fairly centralized - the central Raspberry Pi board talking to sensors, the door locks being remotely controlled, the LED lighting being synced to the music, and that sort of thing.  It seems to me that there's a lot that could go into the data bytes instead, if necessary.

Bear in mind we have only 8 bytes to work with. :)

Quote
I haven't read up on any of the other protocol stacks, do they use more bits to do anything useful?

They pretty much all offer two things: a register abstraction for configuring and discovering nodes, which is unicast, and an event system of some kind for sending notifications of statuses and status changes, which is broadcast. I've tried to replicate both of those with higher level protocols with as little overhead as possible.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 09:23:29 am
nickjohnson:

Sorry, my terminology was poor. It isn't that we stop listening after 11 bits, its that you use a 16bit filter for the address. I was looking at a MAC and it offers 16bit or 32bit filters and you can set more short filter than long.

If the idea of datagrams is to send payloads greater than 8 bytes, doesn't there need to be some initial handshake to make sure the receiver has time to make room? These devices only have room to buffer a limited number of messages, or were you dealing with that another way?

Keeping your unicast flag you could get the desination address (if applicable) into the first 11bits by doing the following

Unicast packet (unicast = 0)
priority:2
unicast:1
dest_address:8
sender_address:8
protocol:4
protocol_field:6

Other packet (unicast = 1)
priority:2
unicast:1
protocol_field1:8 (multicast address?)
sender_address:8
protocol:4
protocol_field2:6

The device can then set filters for [unicast=0 + address], [unicast=1 + broadcast address].

Maybe I got the unicast dominant/recessive backwards to what you were planning.

magetoo:
Agreed with avoiding a full TCP/IP stack. The project I'm starting to work on needs simple event notification (Button was pushed), and a unicast/multicast bulk data transport. I'd prefer it to be peer-perr instead of master/slave though, so that really necessitates individual addresses for each device.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 09:56:46 am
[quote author="bharrisau"]nickjohnson:

Sorry, my terminology was poor. It isn't that we stop listening after 11 bits, its that you use a 16bit filter for the address. I was looking at a MAC and it offers 16bit or 32bit filters and you can set more short filter than long.[/quote]

Which MAC were you looking at? That would definitely be useful to cater to if it's a commonly used device.

The MCP2515 has a fixed number of filters; on a standard frame the filters apply to the 11 bit address and the first two bytes of the message body, while on an extended frame they apply to the entire address.

Quote
If the idea of datagrams is to send payloads greater than 8 bytes, doesn't there need to be some initial handshake to make sure the receiver has time to make room? These devices only have room to buffer a limited number of messages, or were you dealing with that another way?

The datagram format I was intending to specify so far is limited to 8 bytes - but ideally you want all of those for user-defined payload. Longer connections could be defined as another protocol, but they'd be somewhat more complicated, obviously.

Quote
Keeping your unicast flag you could get the desination address (if applicable) into the first 11bits by doing the following

Unicast packet (unicast = 0)
priority:2
unicast:1
dest_address:8
sender_address:8
protocol:4
protocol_field:6

Other packet (unicast = 1)
priority:2
unicast:1
protocol_field1:8 (multicast address?)
sender_address:8
protocol:4
protocol_field2:6

The device can then set filters for [unicast=0 + address], [unicast=1 + broadcast address].

That makes sense - though I'd put the sender address last, and the protocol field 2 at the beginning of the extended identifier, so it forms one virtual field.

Doing things this way more or less eliminates protocol-based priority, but that's probably acceptable if it improves usefulness with common MACs.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 09:58:46 am
[quote author="nickjohnson"]
Quote
Keeping your unicast flag you could get the desination address (if applicable) into the first 11bits by doing the following

Unicast packet (unicast = 0)
priority:2
unicast:1
dest_address:8
sender_address:8
protocol:4
protocol_field:6

Other packet (unicast = 1)
priority:2
unicast:1
protocol_field1:8 (multicast address?)
sender_address:8
protocol:4
protocol_field2:6

The device can then set filters for [unicast=0 + address], [unicast=1 + broadcast address].

That makes sense - though I'd put the sender address last, and the protocol field 2 at the beginning of the extended identifier, so it forms one virtual field.

Doing things this way more or less eliminates protocol-based priority, but that's probably acceptable if it improves usefulness with common MACs.[/quote]

Actually, this doesn't let you use 11-bit masks and filters that often. Besides matching on unicast packets addressed to the node, the other common case is going to be matching on a specific protocol that the receiving node cares about, which will always require a match on the full 29-bit identifier. Is there a way we can restructure things to permit that too?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 10:25:39 am
[quote author="nickjohnson"]Actually, this doesn't let you use 11-bit masks and filters that often. Besides matching on unicast packets addressed to the node, the other common case is going to be matching on a specific protocol that the receiving node cares about, which will always require a match on the full 29-bit identifier. Is there a way we can restructure things to permit that too?[/quote]

I was looking at the Kinetis K10 ARM microcontroller series. It doesn't have any matching on the payload, it has 3 options: first 8 bits of identifier, 11bits of ID + RTR + IDE, 11+18 bits of ID + RTR + IDE.

I was only thinking the sender address first to end arbitration ASAP, but the difference in 10 bits probably isn't going to make a difference.

Maybe it is worth doing some use cases to sort out requirements? I'd not thought of matching on protocol in my use cases, though the more you talk about the limitations of different ways of doing things the more I see them. It sounds like you have two types of matching in mind, one on address and one on topic. If you wanted to go that way, could you think of the unicast flag as instead indicating between an address or a topic (broadcast just has a reserved address). The topic packet then looks like

priority:2
topic:1
topic_protocol:3
protocol_field:5
protocol_field2:10
sender_address:8

That gives 8 topic types, and 32 things to match on for that. For example you could have topic code 0 for events. Then an event code each for button push, level alarm, battery low. Maybe a topic code for status updates, then types for temperature, etc.

I'm not at all suggesting you haven't already thought of this, it is just that I'm still catching up to where you are. Maybe it isn't so important to be able to filter on the first 11bits, but it would be nice if it worked out that way.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 10:38:52 am
[quote author="nickjohnson"]
Quote
Eight bits for message ID, which are all left as "user defined" at this point, but should have a few reserved ones in the 0xFn range - I'm thinking maybe using one for all "network stuff", and a couple left open for the future.
What is the message ID used to denote, exactly? Judging by the reserved IDs, it sounds like a protocol identifier, but from what you say later that doesn't appear to be the case.[/quote]
Well, "user defined" - it denotes nothing.  The idea is that the person who builds the network knows better than we do what their network needs.  Let's do as little as possible so that everyone can implement this.  We can carve IDs up further if and when it becomes necessary, maybe add layers on top.


Quote
I'd like to support routing, but I think it needs a lot more consideration. CAN's realtime nature allows a lot of assumptions that a routed network doesn't have - for instance, that if a message is sent without collision, all nodes had an opportunity to see it.
Right, poor choice of term.  I'm thinking more along the lines of a network with multiple segments, where not all messages are forwarded across all of them.  I think actual routing, involving making decisions based on receiver address, would be a bad idea.


Quote
Quote
I don't see the need for duplicating IP, with all those sender/receiver addresses and multiple protocols, what are the scenarios for when this becomes important?  And are those scenarios the ones where one could easily add an Ethernet shield to ones Arduino project and run IP instead?
Fair point, but I think the protocols I've proposed aren't particularly complicated. They're specifically proposed to address the most common capabilities of CAN-based protocols, plus arbitrary datagrams for those who would prefer a more UDP-esque abstraction.
I have to say that it looked complicated to me..


Quote
Also, I'm fairly sure we have to include the sender address in the header, because CAN defines it as an error if there are still two or more transmitters at the end of arbitration. Having a sender address provides a tie-breaker to ensure that never happens. So with an 8 bit sender address and an 8 bit recipient address, we're already over 11 bits, at least for unicast messages.
Well, "don't allocate the same ID to multiple nodes then" - I guess we're coming at this from very different angles, since I'm not thinking of addresses at all.

Maybe a way of explaining it would be that my way of thinking about this is more that IDs denote socket numbers or memory locations, not node addresses.

How about making addressing and node-to-node communication optional, and "level two implementations" can use the 29-bit format for extra addressing bits?  I really dislike the idea of having address allocation and node discovery being a mandatory part, if this is going to be for hobbyist use.


Quote
Quote
The only really obvious things I can come up with are fairly centralized - the central Raspberry Pi board talking to sensors, the door locks being remotely controlled, the LED lighting being synced to the music, and that sort of thing.  It seems to me that there's a lot that could go into the data bytes instead, if necessary.
Bear in mind we have only 8 bytes to work with. :)
I don't see anything unreasonable in that at all.  That's three different things (that could potentially run in parallel) though, not some central-everything setup I had in mind, if that makes any difference.



[quote author="bharrisau"]Agreed with avoiding a full TCP/IP stack. The project I'm starting to work on needs simple event notification (Button was pushed), and a unicast/multicast bulk data transport. I'd prefer it to be peer-perr instead of master/slave though, so that really necessitates individual addresses for each device.[/quote]
I'm just not sure it really makes sense to think in terms of devices having addresses in the case of CAN.  You can use that abstraction, but to me it always seemed more like reading and writing to memory addresses.  (Multiple nodes on the bus means multiprocessing, and shared memory.)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 10:52:53 am
Probably needs a good case study to work out which absractions are the easiest to work with. For example, how do the proposed ideas handle the hackerspace RFID entry possible use case?

You have 4 devices:
RFID reader (sends token# to server)
Door lock (unlocks when server says to, or exit button pushed)
Logging/authority server
Exit button

The RFID reader can send an event and have the token# as the payload. The server is listening for them, and sends a unicast message to the door lock to open it. Does the exit button send an event or a unicast to the door? I think the ability to plug and play like that would be nice, is it easy to do that in a addressless system?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 10:53:05 am
What are the benefits of an address based solution over a nodeid one, what are the real world use cases that require addressing, I'm trying to imagine such a scenario, does anyone have some good examples?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 10:55:54 am
[quote author="bharrisau"][quote author="nickjohnson"]Actually, this doesn't let you use 11-bit masks and filters that often. Besides matching on unicast packets addressed to the node, the other common case is going to be matching on a specific protocol that the receiving node cares about, which will always require a match on the full 29-bit identifier. Is there a way we can restructure things to permit that too?[/quote]

I was looking at the Kinetis K10 ARM microcontroller series. It doesn't have any matching on the payload, it has 3 options: first 8 bits of identifier, 11bits of ID + RTR + IDE, 11+18 bits of ID + RTR + IDE.[/quote]

The LPC series CAN controllers have one mask/filter per 'message object' regardless. I wonder how common this pattern of supporting a greater number of shorter masks is in hardware?

Quote
I was only thinking the sender address first to end arbitration ASAP, but the difference in 10 bits probably isn't going to make a difference.

Nodes aren't even aware they're in arbitration until one of them attempts to send a recessive while the other sends a dominant, so this shouldn't be an issue.

Quote
Maybe it is worth doing some use cases to sort out requirements? I'd not thought of matching on protocol in my use cases, though the more you talk about the limitations of different ways of doing things the more I see them. It sounds like you have two types of matching in mind, one on address and one on topic.

That's right, if by topic you mean protocol. The way I see it, a node supports some subset of valid protocols. The node wants to listen to all messages addressed to it on unicast protocols it supports, and all messages full stop on broadcast protocols it supports. Providing an easy way to filter for all messages addressed to it regardless of protocol seems like a good way to reduce the number of masks and filters required, because it'll be rare for a node to get messages addressed to it in a protocol it doesn't understand.

I agree that some good use cases would really help here.

Quote
If you wanted to go that way, could you think of the unicast flag as instead indicating between an address or a topic (broadcast just has a reserved address). The topic packet then looks like

priority:2
topic:1
topic_protocol:3
protocol_field:5
protocol_field2:10
sender_address:8

That gives 8 topic types, and 32 things to match on for that. For example you could have topic code 0 for events. Then an event code each for button push, level alarm, battery low. Maybe a topic code for status updates, then types for temperature, etc.

I'm not at all suggesting you haven't already thought of this, it is just that I'm still catching up to where you are. Maybe it isn't so important to be able to filter on the first 11bits, but it would be nice if it worked out that way.

Putting the protocol bits in a different place in the message for unicast and broadcast messages seems less than ideal - but it might be the only practical option.

[quote author="Foklnology"]What are the benefits of an address based solution over a nodeid one, what are the real world use cases that require addressing, I'm trying to imagine such a scenario, does anyone have some good examples?[/quote]

What's the difference between a node ID and an address?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 10:58:22 am
[quote author="bharrisau"]Probably needs a good case study to work out which absractions are the easiest to work with. For example, how do the proposed ideas handle the hackerspace RFID entry possible use case?

You have 4 devices:
RFID reader (sends token# to server)
Door lock (unlocks when server says to, or exit button pushed)
Logging/authority server
Exit button[/quote]

This case seems fairly straightforward based on the classic CAN event style protocol. The RFID reader sends out a broadcast event in response to a card swipe, specifying zone, subzone, and card ID. The server listens for such messages, processes them, and if they're authorized, emits another broadcast event, specifying the same zone and subzone, and an 'open door' action. Likewise, the exit button does this when pressed. The door lock listens for these events in its zone and opens when commanded.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 11:04:56 am
[quote author="nickjohnson"]What's the difference between a node ID and an address?[/quote]

Well a node id is just a unique identifier whereas an address suggest ability to be routed too or sent too from another.

One is just about uniqueness (which may even be temporary/dynamically allocated) the other is about node based routing

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 11:15:55 am
Sounds like we are all talking about the same thing. The 'address' is link local, so can't be routed.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 11:37:25 am
[quote author="Folknology"][quote author="nickjohnson"]What's the difference between a node ID and an address?[/quote]

Well a node id is just a unique identifier whereas an address suggest ability to be routed too or sent too from another.

One is just about uniqueness (which may even be temporary/dynamically allocated) the other is about node based routing
[/quote]

I'm not attempting to specify an form of routing. Addresses as I've discussed them are physical addresses, akin to an ethernet MAC address. They're not valid outside the local segment. Being able to address a message to a specific node is definitely required even in other CAN protocols - for register access, for instance.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 11:46:22 am
[quote author="Folknology"][quote author="nickjohnson"]What's the difference between a node ID and an address?[/quote]
Well a node id is just a unique identifier whereas an address suggest ability to be routed too or sent too from another.

One is just about uniqueness (which may even be temporary/dynamically allocated) the other is about node based routing
[/quote]
An ID doesn't have to be a node ID either, it can be a function ID (all RGB lights in the network listen to the 0x23 ID for setting colour, and the 0x34 ID for dimming).  It doesn't necessarily map one-to-one with the physical nodes.

Edit: Which is why talking about addresses seems wrong to me.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 11:48:02 am
IPv6 over CAN!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 11:50:20 am
[quote author="magetoo"]An ID doesn't have to be a node ID either, it can be a function ID (all RGB lights in the network listen to the 0x23 ID for setting colour, and the 0x34 ID for dimming).  It doesn't necessarily map one-to-one with the physical nodes.[/quote]

Sounds like that maps pretty well to how nickjohnson wants to filter on protocol + flags. e.g. protocol 'action' flag 'dim'.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 11:57:37 am
[quote author="bharrisau"]IPv6 over CAN![/quote]
I've actually thought about that, just now.  :-)

Sending the address in each message is obviously out of the question.  What I think I'd do is use a small range of IDs to represent "sockets" that a central router would forward onto IP for all the nodes that need it.  It would look more like parts of a program talking to each other and to the TCP/IP stack, which just happens to be physically in another place.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 12:06:09 pm
[quote author="bharrisau"][quote author="magetoo"]An ID doesn't have to be a node ID either, it can be a function ID (all RGB lights in the network listen to the 0x23 ID for setting colour, and the 0x34 ID for dimming).  It doesn't necessarily map one-to-one with the physical nodes.[/quote]

Sounds like that maps pretty well to how nickjohnson wants to filter on protocol + flags. e.g. protocol 'action' flag 'dim'.[/quote]

That's pretty much it, yes. The protocol I've proposed for this is 'event', which supports both event type and subtype. Event type specifies the message format (eg, event type 'measurement' would have a zone, subzone, and measurement value). Since type and subtype are in the header, you can filter just for event types you care about. This is exactly the scheme VSCP uses.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 12:14:53 pm
We have enough trouble doing IPv6 over 802.15.4 (with 80-100 bytes of payload per packet). It is do-able, but probably be easiest to just send a multi-part packet to a gateway node.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 12:15:55 pm
[quote author="bharrisau"]Sounds like that maps pretty well to how nickjohnson wants to filter on protocol + flags. e.g. protocol 'action' flag 'dim'.[/quote]
Yeah.. except I guess one layer higher, building on top of nick's protocol.  I don't see what that really adds for the sort of things I want to do though.

What's the hurry is in nailing everything down at the start?  Seems better to start small, and add in things, like subdivisons of the IDs, or layers higher up in the stack later, when networks have been built and we see what sort of trouble people run into.

Sorry if I repeat myself.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 12:23:35 pm
[quote author="bharrisau"]We have enough trouble doing IPv6 over 802.15.4 (with 80-100 bytes of payload per packet). It is do-able, but probably be easiest to just send a multi-part packet to a gateway node.[/quote]
Yeah, it wouldn't be much useful in practice.  Fun to think about though.  :-)

Things like what I suggested, talking to a smart gateway over a dumb protocol, come up from time to time in the retrocomputing world.  The Internet as your floppy drive, and that sort of thing.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 12:24:25 pm
[quote author="magetoo"][quote author="bharrisau"]Sounds like that maps pretty well to how nickjohnson wants to filter on protocol + flags. e.g. protocol 'action' flag 'dim'.[/quote]
Yeah.. except I guess one layer higher, building on top of nick's protocol.  I don't see what that really adds for the sort of things I want to do though.

What's the hurry is in nailing everything down at the start?  Seems better to start small, and add in things, like subdivisons of the IDs, or layers higher up in the stack later, when networks have been built and we see what sort of trouble people run into.

Sorry if I repeat myself.[/quote]

I've deliberately left the network layer protocols vague so far for just this reason. I think we need to define at least a format for the CAN address field, and standards on how that's interpreted, before we can sensibly build anything based on uCAN, though.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 12:27:53 pm
Sorry to interrupt the network/protocol flow here but I really need to get some PCBs out, is it possible to decide what the pinouts should be, can we make a decision on this? Also do we need to support other connectors AKA VSCP (http://http://vscp.org/vscpspec/vscp_spec_latest.xhtml) section 2.1.2 which cleverly supports RJ-XX type connectors.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 12:33:24 pm
[quote author="Folknology"]Sorry to interrupt the network/protocol flow here but I really need to get some PCBs out, is it possible to decide what the pinouts should be, can we make a decision on this? Also do we need to support other connectors AKA VSCP which cleverly supports RJ-XX type connectors.[/quote]

I think we've settled on the 'PoE' pinout documented here (http://https://github.com/arachnidlabs/uCAN/wiki/Physical%20layer) - at least, I've not heard anyone object to it. Note that pinout leaves two pins, 3 and 6, unused; for compatibility purposes it probably makes sense to forward those pins unmodified between jacks.

Edit: Would it make sense to duplicate CAN_L and CAN_H on pins 3 and 6? This would mean that a crossover cable would not effect the operation of the CAN pairs, and a device could optionally include a rectifier to handle the reversed polarity of the power supply.

VSCP suffers from the same issue as the original 'standard' CAN pinout, in that plugging it into a magjack will cause a short on the power pins - in this case, between pins 3 and 6.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 12:42:21 pm
[quote author="nickjohnson"][quote author="Folknology"]Sorry to interrupt the network/protocol flow here but I really need to get some PCBs out, is it possible to decide what the pinouts should be, can we make a decision on this? Also do we need to support other connectors AKA VSCP which cleverly supports RJ-XX type connectors.[/quote]

I think we've settled on the 'PoE' pinout documented here (http://https://github.com/arachnidlabs/uCAN/wiki/Physical%20layer) - at least, I've not heard anyone object to it. Note that pinout leaves two pins, 3 and 6, unused; for compatibility purposes it probably makes sense to forward those pins unmodified between jacks.

VSCP suffers from the same issue as the original 'standard' CAN pinout, in that plugging it into a magjack will cause a short on the power pins - in this case, between pins 3 and 6.[/quote]

So does that mean we are doing it for safety or for some other reason?

Although VSCP does have the issue with magjacks it does allow more flexible cable choices which might be more important to some folks, it means there are less limitations/choices with cabling, telephone cables for example exists in many residential buildings.

We could support multiple cabling scenarios, should we be open and flexible?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 12:46:42 pm
[quote author="nickjohnson"]Edit: Would it make sense to duplicate CAN_L and CAN_H on pins 3 and 6? This would mean that a crossover cable would not effect the operation of the CAN pairs, and a device could optionally include a rectifier to handle the reversed polarity of the power supply.[/quote]

I'm not sure how the termination/transmission characteristics would work with that. Just require it to be a patch cable. The power isn't swapped on a crossover cable.

[quote author="Folknology"]Although VSCP does have the issue with magjacks it does allow more flexible cable choices which might be more important to some folks, it means there are less limitations/choices with cabling, telephone cables for example exists in many residential buildings.

We could support multiple cabling scenarios, should we be open and flexible?[/quote]

Only the pinout for 8P8C is defined at the moment. Telephones would be 6P4C, and you may want to specify a standard for that. I'd suggest pos 2 +ve, pos 3 CAN_H, pos 4 CAN_L, pos5 GND (someone may want to swap 3 and 4).
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 01:22:10 pm
Unfortunately that means we won't be able to overlay RJ-XX type connectors on PCBs of course, but this may be less important that RJ45 safety

I also still think you should remove current maximums from the specifications and leave this to deployment discretion.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 01:25:13 pm
[quote author="nickjohnson"]I think we need to define at least a format for the CAN address field, and standards on how that's interpreted, before we can sensibly build anything based on uCAN, though.[/quote]
Why?  Serious question, I'd like to hear what you think.

(Besides putting aside the topmost few bits for priority classes.)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 01:38:42 pm
[quote author="Folknology"]So does that mean we are doing it for safety or for some other reason?[/quote]

Yes; I think it's wise to have a pinout that doesn't cause equipment destruction if you plug a CAN device into an ethernet port, or vice-versa.

Quote
Although VSCP does have the issue with magjacks it does allow more flexible cable choices which might be more important to some folks, it means there are less limitations/choices with cabling, telephone cables for example exists in many residential buildings.

We could support multiple cabling scenarios, should we be open and flexible?

I think that's a bad idea - it'll create confusion and incompatibility between devices. The pinout could be rejiggered to support 6p6c jacks without introducing issues with magjacks, but I don't think there's that much gain to be had there, really.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 01:39:14 pm
[quote author="magetoo"][quote author="nickjohnson"]I think we need to define at least a format for the CAN address field, and standards on how that's interpreted, before we can sensibly build anything based on uCAN, though.[/quote]
Why?  Serious question, I'd like to hear what you think.

(Besides putting aside the topmost few bits for priority classes.)[/quote]

Because if we don't, we'll have a bunch of mutually incompatible devices that all claim to be uCAN, but can't communicate with each other.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 01:41:21 pm
[quote author="nickjohnson"]I think we've settled on the 'PoE' pinout documented here (http://https://github.com/arachnidlabs/uCAN/wiki/Physical%20layer) - at least, I've not heard anyone object to it. Note that pinout leaves two pins, 3 and 6, unused; for compatibility purposes it probably makes sense to forward those pins unmodified between jacks.[/quote]
Sounds good.  I still want to play with my "everything in one" idea, but don't mind that it's going to be a niche case.

Quote
Edit: Would it make sense to duplicate CAN_L and CAN_H on pins 3 and 6? This would mean that a crossover cable would not effect the operation of the CAN pairs, and a device could optionally include a rectifier to handle the reversed polarity of the power supply.
It makes sense, but on the other hand switching to a straight cable isn't a huge deal either.  That last pair could be useful for someone.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 01:45:49 pm
[quote author="magetoo"]
Quote
Edit: Would it make sense to duplicate CAN_L and CAN_H on pins 3 and 6? This would mean that a crossover cable would not effect the operation of the CAN pairs, and a device could optionally include a rectifier to handle the reversed polarity of the power supply.
It makes sense, but on the other hand switching to a straight cable isn't a huge deal either.  That last pair could be useful for someone.[/quote]

I just had a long chat on IRC with someone who knows a lot more about balanced transmission lines than me. The upshot is that this is possible, but since you're effectively paralleling two 100 ohm transmission lines, you now have a 50 ohm transmission line, with the result that it's more unbalanced than it was before (CAN expects 120 ohm impedance). This would reduce the total cable length you could use at a given frequency, and I don't think that's a tradeoff we want - simply having things not work if you use a crossover cable seems a safer solution.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 02:04:03 pm
[quote author="magetoo"][quote author="nickjohnson"]I think we've settled on the 'PoE' pinout documented here (http://https://github.com/arachnidlabs/uCAN/wiki/Physical%20layer) - at least, I've not heard anyone object to it. Note that pinout leaves two pins, 3 and 6, unused; for compatibility purposes it probably makes sense to forward those pins unmodified between jacks.[/quote]
Sounds good.  I still want to play with my "everything in one" idea, but don't mind that it's going to be a niche case.[/quote]

If your 'everything in one' is putting the power over the can lines, you are going to have a hard time. It only works for ethernet because it is DC balanced. CAN isn't, so it wont work the standard way. You could raise the common mode voltage of CAN_H and CAN_L to 24V, and change the dominant state to be -2.5V on CAN_L and +2.5V on CAN_H, but I don't know if any PHYs support that.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 02:07:14 pm
[quote author="nickjohnson"][quote author="magetoo"]
Why?[/quote]
Because if we don't, we'll have a bunch of mutually incompatible devices that all claim to be uCAN, but can't communicate with each other.[/quote]
Could you elaborate?  I'd really like to know how you think about it, and I'm afraid if I bring up specifics you'll just shoot off another quick single paragraph answer, so I'll keep it vague.

Edit: Ok, on re-reading maybe that's a dumb way to put it.  I mean something like: if you have a clear idea who will use uCAN, and how, could you tell me why just leaving things up to the "implementer" isn't good enough?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 02:26:19 pm
[quote author="bharrisau"][quote author="magetoo"]I still want to play with my "everything in one" idea, but don't mind that it's going to be a niche case.[/quote]
If your 'everything in one' is putting the power over the can lines, you are going to have a hard time. It only works for ethernet because it is DC balanced. CAN isn't, so it wont work the standard way.  You could raise the common mode voltage of CAN_H and CAN_L to 24V, and change the dominant state to be -2.5V on CAN_L and +2.5V on CAN_H, but I don't know if any PHYs support that.[/quote]
It's going to mess with things enough that you could effectively call it a new physical layer.  CAN has several already, so that's no big deal.  Is there any reason one couldn't just copy what Ethernet does in that regard?

Doesn't seem very useful, the more I think about it, but it's still interesting as a problem.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 02:35:01 pm
[quote author="magetoo"][quote author="nickjohnson"][quote author="magetoo"]
Why?[/quote]
Because if we don't, we'll have a bunch of mutually incompatible devices that all claim to be uCAN, but can't communicate with each other.[/quote]
Could you elaborate?  I'd really like to know how you think about it, and I'm afraid if I bring up specifics you'll just shoot off another quick single paragraph answer, so I'll keep it vague.[/quote]

Well, I'm not sure I understand what you'd do with uCAN if it _didn't_ specify basics like protocol headers and addressing. The way I see it, a stack is only useful for inter-compatibility if the nodes involved agree on how to communicate. We could stop defining things at the CAN layer - which is more or less where we're up to if we take the electrical and physical specs as written - but I think it's far more useful to be able to at least understand the metadata of messages.

I do still very much expect things to change - what we're defining, especially in software, is still very preliminary - but we can all get more benefit out of experimentation if we're experimenting with the same basic protocol, rather than inventing a set of disjoint ones.

One example: If we standardise how nodes are addressed and how those addresses are assigned, then nodes from different people can easily coexist on the same network, even if they don't know how to talk to each other. If we define the format of the CAN message ID field, one node can't send out a message that's understood as something totally different by the receiver.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 02:44:48 pm
BTW a quick perusal of the LPC11Cxx series indicates both 11 bit and 29 bit masking is supported for filtering purposes etc.. It uses two mask identity registers 15:0 (1) and 28:16 (2) for each message interface.

Oh and it passes the full DLC up so that can be used for multi frame transfers.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: magetoo on October 29, 2013, 03:10:54 pm
Thanks for the reply, nick.  I'll follow up when I've pondered things a bit more.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 03:51:12 pm
The DLC could be used as a multi-frame decremental indicator for multi-frame transfers:

Current frame = DLC > 8 ? DLC - 8 : 0 //(multi frame transfers of 16 bytes to 56 bytes)

It also has the advantage of indicating required buffer size ahead of transmission on the first frame.

The MCP2515 (REGISTER 3-7) states 'It is possible to set the DLC to a value greater than eight, however only eight bytes are transmitted'

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 04:43:02 pm
[quote author="Folknology"]The DLC could be used as a multi-frame decremental indicator for multi-frame transfers:

Current frame = DLC > 8 ? DLC - 8 : 0 //(multi frame transfers of 16 bytes to 56 bytes)

It also has the advantage of indicating required buffer size ahead of transmission on the first frame.

The MCP2515 (REGISTER 3-7) states 'It is possible to set the DLC to a value greater than eight, however only eight bytes are transmitted'[/quote]

It might be a viable idea, but I worry that not all implementations will correctly handle or preserve DLCs >8. At any rate, I think it's something worth experimenting with, and only formalising in a spec if it turns out to be useful and practical.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 05:08:29 pm
[quote author="nickjohnson"] I think it's something worth experimenting with, and only formalising in a spec if it turns out to be useful and practical.[/quote]

I think this applies to all parts of the specification.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 05:12:53 pm
[quote author="Folknology"][quote author="nickjohnson"] I think it's something worth experimenting with, and only formalising in a spec if it turns out to be useful and practical.[/quote]

I think this applies to all parts of the specification.[/quote]

Some more than others! There's definitely a minimum set of features and requirements we need in order to actually be experimenting on the same thing.

Can I take it as read that everyone's happy with the current proposal for RJ45 pinout?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 05:45:27 pm
[quote author="nickjohnson"]Some more than others! There's definitely a minimum set of features and requirements we need in order to actually be experimenting on the same thing.[/quote]I think we should specify the absolute minimum to begin with and work are way up based on :
[quote author="nickjohnson"]I think it's something worth experimenting with, and only formalising in a spec if it turns out to be useful and practical.[/quote]This is a good approach to specification and avoids over design and premature complexity

[quote author="nickjohnson"]
Can I take it as read that everyone's happy with the current proposal for RJ45 pinout?[/quote]
It's ok with me, just updated my designs.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 05:58:32 pm
Can we please remove this:
Quote
Cabling limitations mean that no more than approximately 1 amp should be supplied over the two pairs used for power; this means that at 24 volts, a little under 24 watts (after line losses) is available to all uCAN devices on a connection. The use of a CAN hub, which can provide power separately to each connection, can increase this to a per-branch limit rather than a network-wide limit.

If a uCAN device requires more power than is available, it can take its power from an external supply.
from the spec, I do not think this should be part of it, this kind of detail and assumption is way above the minimums spec's pay grade ;-)

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 06:01:24 pm
[quote author="Folknology"][quote author="nickjohnson"]Some more than others! There's definitely a minimum set of features and requirements we need in order to actually be experimenting on the same thing.[/quote]I think we should specify the absolute minimum to begin with and work are way up based on :[/quote]

I think we agree on that. We just disagree exactly what the absolute minimum is. :)

Probably a happy resolution for everyone is to say that you should feel free to deviate from the spec as it stands, as long as you report back your findings. :)

Quote
from the spec, I do not think this should be part of it, this kind of detail and assumption is way above the minimums spec's pay grade ;-)

I'll change it to a recommendation or a note rather than a requirement.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 06:09:44 pm
[quote author="nickjohnson"][quote author="Folknology"][quote author="nickjohnson"]Some more than others! There's definitely a minimum set of features and requirements we need in order to actually be experimenting on the same thing.[/quote]I think we should specify the absolute minimum to begin with and work are way up based on :[/quote]

I think we agree on that. We just disagree exactly what the absolute minimum is. :)

Probably a happy resolution for everyone is to say that you should feel free to deviate from the spec as it stands, as long as you report back your findings. :)
[/quote]

I am afraid I disagree with this approach generally, minimum specs reduce complexity

[quote author="nickjohnson"]
Quote
from the spec, I do not think this should be part of it, this kind of detail and assumption is way above the minimums spec's pay grade ;-)

I'll change it to a recommendation or a note rather than a requirement.[/quote]

The trouble is such recommendation appears to be based on a specific wiring case (and borrowed from another very different spec Ethernet), the recommendation therefore is application specific rather than general, hence my objection

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 06:19:04 pm
[quote author="Folknology"][quote author="nickjohnson"]

I think we agree on that. We just disagree exactly what the absolute minimum is. :)

Probably a happy resolution for everyone is to say that you should feel free to deviate from the spec as it stands, as long as you report back your findings. :)
[/quote]

I am afraid I disagree with this approach generally, minimum specs reduce complexity[/quote]

I agree - I just think that at an absolute minimum you need to specify how to interpret link layer packets before you've got something useful to experiment with. Otherwise, it's not a protocol built on CAN - it's just CAN.

Quote
[quote author="nickjohnson"]
Quote
from the spec, I do not think this should be part of it, this kind of detail and assumption is way above the minimums spec's pay grade ;-)

I'll change it to a recommendation or a note rather than a requirement.

The trouble is such recommendation appears to be based on a specific wiring case (and borrowed from another very different spec Ethernet), the recommendation therefore is application specific rather than general, hence my objection[/quote]

What specific wiring case are you thinking of? This applies to anything that uses UTP, as far as I'm aware, which is what I thought we'd agreed on for uCAN cabling.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 06:38:43 pm
[quote author="nickjohnson"]
What specific wiring case are you thinking of? This applies to anything that uses UTP, as far as I'm aware, which is what I thought we'd agreed on for uCAN cabling.[/quote]

If you apply this criteria ,80-90% of the network designs on my current projects will not be compatible with uCAN, is that really what you are trying to achieve, I would have thought your would prefer to be inclusive rather than exclusive?

BTW UTP comes in many forms

PS I am not saying this in a throw my toys out the windows manner, rather that I really would like these projects to be compatible with the uCAN specification :-)

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 07:09:07 pm
Here is another idea, if you feel you must place a cable power limitation on uCan devices why not use:
Quote
When running uCAN over an existing cabling infrastructure or following an existing standard like Ethernet please make sure you confine your power envelopes to their specifications

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 07:23:28 pm
[quote author="Folknology"][quote author="nickjohnson"]
What specific wiring case are you thinking of? This applies to anything that uses UTP, as far as I'm aware, which is what I thought we'd agreed on for uCAN cabling.[/quote]

If you apply this criteria ,80-90% of the network designs on my current projects will not be compatible with uCAN, is that really what you are trying to achieve, I would have thought your would prefer to be inclusive rather than exclusive?

BTW UTP comes in many forms[/quote]

What are your specific requirements? If the cabling can't handle it, no amount of spec writing will change that. :)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 07:33:41 pm
Hi Nick take a look at the AWG specifications for current carrying copper conductors if you are really curious but I would suggest this entire conversation is beyond the scope of this thread as there are many variables to consider. I merely suggest that you leave such things out of the standard to be as inclusive as possible with uCan. If however you do feel that this is very important to the standard then please go ahead and I will gently bow out at this point.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 07:56:39 pm
[quote author="Folknology"]Hi Nick take a look at the AWG specifications for current carrying copper conductors if you are really curious but I would suggest this entire conversation is beyond the scope of this thread as there are many variables to consider. I merely suggest that you leave such things out of the standard to be as inclusive as possible with uCan. If however you do feel that this is very important to the standard then please go ahead and I will gently bow out at this point.[/quote]

Sure. I'll amend it as you suggest, to encourage caution in current handling.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 09:05:18 pm
Cool Thanks Nick this will I believe help uCan moving forward and be more inclusive, it certainly helps us.

BTW I have just posted the Slice version for uCan (http://http://solderpad.com/folknology/ucan-slice/)

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 29, 2013, 09:39:54 pm
Nice! What ICs are you using? And do you have a layout yet?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 10:04:22 pm
Hi Nick this design is for the Xmos range of XS1 devices which we use in our communication controllers and segment bridges. Several of their dev kits (http://https://www.xmos.com/en/support/documentation/xkits?subcategory=sliceKIT&product=15825&component=16091&page=1) that we use for testing have slice expansion sockets, this design is for those systems. If you follow the link it will take you to the uCan slice repository (http://http://solderpad.com/folknology/ucan-slice/).

PS that schematic is a little out of date as shows a generic PCA82C250 transceiver, I am actually using an Onsemi mixed 3v3/5v transceiver in this design you can see that (along with layout files) in the more up to date repository which I just updated.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 10:12:18 pm
In fact I eventually may be able to combine the uCan slice (http://http://solderpad.com/folknology/ucan-slice/) with their new StartKit (http://http://www.xmos.com/startkit/what) to build a simple lost cost uCan field analyser, depending on time constraints.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 29, 2013, 11:29:15 pm
Updated uCan slice adaptor schematic and layout pics for those that can't be bothered with the repo ;-)

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 29, 2013, 11:48:42 pm
I know VSCP has already been considered, but can it be as simple as just defining the class codes from 0x100 (256) to 0x1DF (479) as being unicast addresses? VSCP needs each talking node to have an 8bit address anyway, the unicast address is then [0x100 | address]. Address >= 224 are reserved.

VSCP packet format
priority: 3
hard-code id: 1
class: 9 (last 2 bits are in the extended identifier)
type: 8
sender: 8

Doing it this way you could just implement the VSCP spec and be compatible with VSCP devices (except for the different wiring spec).

For the bulk multi-frame transfer, there should be enough bits in the extended identifier without worrying about the DLC code. You only need 5 bits for a pretty simple control protocol with 1kB max payload size. If you have a 3 bit protocol selector (who needs more than 8 unicast protocols), that fits into the 8 bits available from VSCP.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 08:16:08 am
[quote author="bharrisau"]I know VSCP has already been considered, but can it be as simple as just defining the class codes from 0x100 (256) to 0x1DF (479) as being unicast addresses? VSCP needs each talking node to have an 8bit address anyway, the unicast address is then [0x100 | address]. Address >= 224 are reserved.

VSCP packet format
priority: 3
hard-code id: 1
class: 9 (last 2 bits are in the extended identifier)
type: 8
sender: 8

Doing it this way you could just implement the VSCP spec and be compatible with VSCP devices (except for the different wiring spec).[/quote]

This is a nice idea, but VSCP already defines a set of sub-protocols that include unicode addressing in the first byte of the message, such as for register access. This also wouldn't solve the issue that VSCP's minimum required set of features is quite large, and that its event system is overcomplicated to implement an API for.

Quote
For the bulk multi-frame transfer, there should be enough bits in the extended identifier without worrying about the DLC code. You only need 5 bits for a pretty simple control protocol with 1kB max payload size. If you have a 3 bit protocol selector (who needs more than 8 unicast protocols), that fits into the 8 bits available from VSCP.

I concur.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 30, 2013, 09:59:26 am
[quote author="nickjohnson"]
This is a nice idea, but VSCP already defines a set of sub-protocols that include unicode addressing in the first byte of the message, such as for register access. This also wouldn't solve the issue that VSCP's minimum required set of features is quite large, and that its event system is overcomplicated to implement an API for.
[/quote]

All right, so take the best parts it is. Sounds like you are still planning to map some of the VSCP class types over to uCAN (makes sense), though I'd suggest favouring more bits for class and type (to use VSCP terminology) over getting all the parameters in the id field. Flexibility over processing efficiency. That being said, VSCP probably has too many bits available so using a few for additional filtering may be a net improvement.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 10:11:27 am
A modest proposal for the unused pins on the RJ45: Upstream ports should connect pin 3 to GND. Downstream ports should connect pin 6 to GND. This can be used for devices to detect if another device is attached to each port for automatic termination, or for smart hubs/switches. One downside is that this only works if you attach an 'upstream' to a 'downstream', while previously both ports on a device were identical.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 10:12:44 am
[quote author="bharrisau"][quote author="nickjohnson"]
This is a nice idea, but VSCP already defines a set of sub-protocols that include unicode addressing in the first byte of the message, such as for register access. This also wouldn't solve the issue that VSCP's minimum required set of features is quite large, and that its event system is overcomplicated to implement an API for.
[/quote]

All right, so take the best parts it is. Sounds like you are still planning to map some of the VSCP class types over to uCAN (makes sense), though I'd suggest favouring more bits for class and type (to use VSCP terminology) over getting all the parameters in the id field. Flexibility over processing efficiency. That being said, VSCP probably has too many bits available so using a few for additional filtering may be a net improvement.[/quote]

My initial thought was to use 7 bits for class and 7 bits for type from the protocol-specific field of the header. I think it'd be useful to borrow a lot from VSCP, but I also think that all the messages of a given class need to have the same data structure - something VSCP does not offer.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 30, 2013, 10:36:05 am
[quote author="nickjohnson"]A modest proposal for the unused pins on the RJ45: Upstream ports should connect pin 3 to GND. Downstream ports should connect pin 6 to GND. This can be used for devices to detect if another device is attached to each port for automatic termination, or for smart hubs/switches. One downside is that this only works if you attach an 'upstream' to a 'downstream', while previously both ports on a device were identical.[/quote]

Keep both ports identical. If you wanted device detection on hubs you could specify a minimum current draw on the power lines and use that as the indication (similar to PoE). You wouldn't want the same though, otherwise someone plugging into PoE might receive 48V.

Quote
My initial thought was to use 7 bits for class and 7 bits for type from the protocol-specific field of the header. I think it'd be useful to borrow a lot from VSCP, but I also think that all the messages of a given class need to have the same data structure - something VSCP does not offer.

All messages of a given class should definately have the same structure in the header. Having it in the payload might not make sense in all cases, but that might be an indication that it doesn't fit into that particular class.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 10:41:18 am
[quote author="bharrisau"][quote author="nickjohnson"]A modest proposal for the unused pins on the RJ45: Upstream ports should connect pin 3 to GND. Downstream ports should connect pin 6 to GND. This can be used for devices to detect if another device is attached to each port for automatic termination, or for smart hubs/switches. One downside is that this only works if you attach an 'upstream' to a 'downstream', while previously both ports on a device were identical.[/quote]

Keep both ports identical. If you wanted device detection on hubs you could specify a minimum current draw on the power lines and use that as the indication (similar to PoE). You wouldn't want the same though, otherwise someone plugging into PoE might receive 48V.[/quote]

Fair. It'd be nice to be able to autodetect downstream/upstream devices so termination can be enabled or disabled automatically, though.

Quote
Quote
My initial thought was to use 7 bits for class and 7 bits for type from the protocol-specific field of the header. I think it'd be useful to borrow a lot from VSCP, but I also think that all the messages of a given class need to have the same data structure - something VSCP does not offer.

All messages of a given class should definately have the same structure in the header. Having it in the payload might not make sense in all cases, but that might be an indication that it doesn't fit into that particular class.

I think the data format ought to be the same too, because it provides for straightforward APIs: one struct for each class. VSCP doesn't currently permit this - you have to handle every individual class/type pair individually.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 30, 2013, 10:49:48 am
I suppose the next step is to map stuff across and see how well it all fits in. That will sort out if those bit numbers are sufficient or need to be shifted a little (class: 8, type: 6, subtype/location: 4 follows a nice progression ;)  )

Maybe open a wiki page for it?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 11:03:59 am
[quote author="nickjohnson"][quote author="bharrisau"][quote author="nickjohnson"]A modest proposal for the unused pins on the RJ45: Upstream ports should connect pin 3 to GND. Downstream ports should connect pin 6 to GND. This can be used for devices to detect if another device is attached to each port for automatic termination, or for smart hubs/switches. One downside is that this only works if you attach an 'upstream' to a 'downstream', while previously both ports on a device were identical.[/quote]

Keep both ports identical. If you wanted device detection on hubs you could specify a minimum current draw on the power lines and use that as the indication (similar to PoE). You wouldn't want the same though, otherwise someone plugging into PoE might receive 48V.[/quote]

Fair. It'd be nice to be able to autodetect downstream/upstream devices so termination can be enabled or disabled automatically, though.
[/quote]

I would advise against the minimum current draw as often energy consumption needs to be kept to a minimum, and nodes can actually sleep. Using up/down spare pin detection is an interesting idea however, I think we would need pull ups though to make this work? I am a bit confused about seperate up and down pins though, how does a device know its up or downstream, could we just use a single pin? Assuming the switch/or active terminator doesn't connect the pin through it could then determine termination requirement.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 11:04:44 am
[quote author="bharrisau"]I suppose the next step is to map stuff across and see how well it all fits in. That will sort out if those bit numbers are sufficient or need to be shifted a little (class: 8, type: 6, subtype/location: 4 follows a nice progression ;)  )

Maybe open a wiki page for it?[/quote]

Pull requests are welcome! I'm going to focus on firming up the lower level protocol details, and the network management protocol first.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 11:06:26 am
[quote author="Folknology"][quote author="nickjohnson"][quote author="bharrisau"]

Keep both ports identical. If you wanted device detection on hubs you could specify a minimum current draw on the power lines and use that as the indication (similar to PoE). You wouldn't want the same though, otherwise someone plugging into PoE might receive 48V.[/quote]

Fair. It'd be nice to be able to autodetect downstream/upstream devices so termination can be enabled or disabled automatically, though.
[/quote]

I would advise against the minimum current draw as often energy consumption needs to be kept to a minimum, and nodes can actually sleep. Using up/down spare pin detection is an interesting idea however, I think we would need pull ups though to make this work?[/quote]

Correct. Devices wanting to do detection would use a pullup on the relevant pin and check the voltage. I was going to suggest tying these pins to +5V instead, but some really simple devices like the power injector PCB may not have +5V available.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 11:16:59 am
[quote author="nickjohnson"]
Correct. Devices wanting to do detection would use a pullup on the relevant pin and check the voltage. I was going to suggest tying these pins to +5V instead, but some really simple devices like the power injector PCB may not have +5V available.[/quote]

Also see the points I added above about using single rather than 2 pins.

I have often pondered over keeping 1 pin for a 5V supply to make it easier to make network peripherals with smaller BOMs, clearly over larger networks this doesn't make sense because of the voltage drop, but when its used to supply low powered µC the voltage drop is relatively small on dedicated 5v segments. Maybe one of the pins could be used to optionally provide 5V?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 11:23:53 am
To get a more failsafe detection, one can detect termination directly rather than the devices themselves. All we do is we specify that we use split termination 2 x 60r + 10nf cap and connect the junction of the termination and cap to pin 3 directly.We can then detect the expected voltage on pin 3.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 11:30:20 am
[quote author="Folknology"][quote author="nickjohnson"]
Correct. Devices wanting to do detection would use a pullup on the relevant pin and check the voltage. I was going to suggest tying these pins to +5V instead, but some really simple devices like the power injector PCB may not have +5V available.[/quote]

Also see the points I added above about using single rather than 2 pins.[/quote]

I don't think a single pin is possible. With only one pin, which device connects it to ground and which has the pullup and detection circuitry? If we want to detect connection in both directions, we need separate pins for each direction.

Devices don't have to know whether they're upstream or downstream: simply define one port as upstream and the other as downstream. Upstream ports tie 3 low and sense on 6, and vice-versa for downstream ports. As long as you connect upstream to downstream, this will work fine.

Quote
I have often pondered over keeping 1 pin for a 5V supply to make it easier to make network peripherals with smaller BOMs, clearly over larger networks this doesn't make sense because of the voltage drop, but when its used to supply low powered µC the voltage drop is relatively small on dedicated 5v segments. Maybe one of the pins could be used to optionally provide 5V?

I'm cautious about adding many optional features because they result in either devices that do not work at all, or increase complexity for devices to support all the optional features. A low complexity device could use a linear regulator in place of the switching regulator, though.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 11:37:23 am
[quote author="nickjohnson"][quote author="Folknology"][quote author="nickjohnson"]
Correct. Devices wanting to do detection would use a pullup on the relevant pin and check the voltage. I was going to suggest tying these pins to +5V instead, but some really simple devices like the power injector PCB may not have +5V available.[/quote]

Also see the points I added above about using single rather than 2 pins.[/quote]

I don't think a single pin is possible. With only one pin, which device connects it to ground and which has the pullup and detection circuitry? If we want to detect connection in both directions, we need separate pins for each direction.

Devices don't have to know whether they're upstream or downstream: simply define one port as upstream and the other as downstream. Upstream ports tie 3 low and sense on 6, and vice-versa for downstream ports. As long as you connect upstream to downstream, this will work fine.[/quote]

This means devices need to know if they are upstream or downstream, or they need to be configured as such, installers have nasty habits like getting these mixed up. Also you are only detecting devices and not actually termination which has all sorts of other issues. Take a look at my termination suggestion that fixes this.

[quote author="nickjohnson"]
Quote
I have often pondered over keeping 1 pin for a 5V supply to make it easier to make network peripherals with smaller BOMs, clearly over larger networks this doesn't make sense because of the voltage drop, but when its used to supply low powered µC the voltage drop is relatively small on dedicated 5v segments. Maybe one of the pins could be used to optionally provide 5V?

I'm cautious about adding many optional features because they result in either devices that do not work at all, or increase complexity for devices to support all the optional features. A low complexity device could use a linear regulator in place of the switching regulator, though.[/quote]

Actually this optional feature reduces complexity for simple devices and adds little for a switch/hub which will likely have a low voltage onboard already, it shouldn't be dismissed as it has some merit as well as lowering the cost per node particularly for low powered sensors. Remember our mainline CAN voltages are rather high for using linear regs  dropping it to 3v3 which result in heat, waste and earlier failure.

In fact you could make 5v on pin 6 mandatory and just not use it on larger networks.

Update in fact make it 4.5-5V and make sure you Schottky diode pin 6 from the local 5v so than any device on the chain can add to it locally.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 11:45:02 am
[quote author="Folknology"][quote author="nickjohnson"][quote author="Folknology"]

Also see the points I added above about using single rather than 2 pins.[/quote]

I don't think a single pin is possible. With only one pin, which device connects it to ground and which has the pullup and detection circuitry? If we want to detect connection in both directions, we need separate pins for each direction.

Devices don't have to know whether they're upstream or downstream: simply define one port as upstream and the other as downstream. Upstream ports tie 3 low and sense on 6, and vice-versa for downstream ports. As long as you connect upstream to downstream, this will work fine.[/quote]

This means devices need to know if they are upstream or downstream, or they need to be configured as such, installers have nasty habits like getting these mixed up. Also you are only detecting devices and not actually termination which has all sorts of other issues. Take a look at my termination suggestion that fixes this.[/quote]

No, devices don't need any configuration; the only requirement is that upstream ports are plugged into downstream ports, and vice versa. Each port can then detect if there's something on the other end.

I don't understand how your termination suggestion is intended to work. It seems like it would only be usable if every device installed a terminator, and I'm not sure exactly what it would detect. Can you elaborate?

Quote
[quote author="nickjohnson"]
Quote
I have often pondered over keeping 1 pin for a 5V supply to make it easier to make network peripherals with smaller BOMs, clearly over larger networks this doesn't make sense because of the voltage drop, but when its used to supply low powered µC the voltage drop is relatively small on dedicated 5v segments. Maybe one of the pins could be used to optionally provide 5V?

I'm cautious about adding many optional features because they result in either devices that do not work at all, or increase complexity for devices to support all the optional features. A low complexity device could use a linear regulator in place of the switching regulator, though.

Actually this optional feature reduces complexity for devices and adds little for a switch which will likely have a low voltage onboard already, it shouldn't be dismissed as it has some merit as well as lowering the cost per node particularly for low powered sensors.[/quote]

It adds complexity for devices that want to supply power, though, such as the ultra-simple power injector, which just requires a couple of jacks and a terminator. Also, voltage drop even over short runs will ensure that receiving devices won't be able to drive the CAN bus to its full 5v; there's a reason USB uses 5v power but 3.3v signalling.

What's wrong with using a linear regulator if you want a low complexity solution?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 12:02:26 pm
You can use 3v3 CAN transceivers they are more energy efficient anyhow, the TI ones are very good for this.

I have covered using linear regs above it's a really bad idea to use them to drop down to 3v3 from 12 or god forbid 24 volts, we should not be encouraging new designs to engage in this sort of practice.

In order to decide whether or not we need to terminate we need to establish if correct termination is already in place both upstream and downstream, only then can we act. Detecting a device does not detect termination. the termination scheme I propose allows us to detect termination in either direction from the switch (normally at the centre), it can also flag un-terminated networks and adds no real complexity just the use of pin3.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 12:13:08 pm
[quote author="Folknology"]You can use 3v3 CAN transceivers they are more energy efficient anyhow, the TI ones are very good for this.[/quote]

Thus far uCAN has assumed 5v CAN, since that's the usual standard. Is there a convincing reason to switch?

Quote
I have covered using linear regs above it's a really bad idea to use them to drop down to 3v3 from 12 or god forbid 24 volts, we should not be encouraging new designs to engage in this sort of practice.

That depends on the amount of current being used. You did ask for simple. :)

Quote
In order to decide whether or not we need to terminate we need to establish if correct termination is already in place both upstream and downstream, only then can we act. detecting a device does not detect termination. the termination scheme I propose allows us to detect termination in either direction from the switch (normally at the centre), it can also flag un-terminated networks and adds no real complexity just the use of pin3.

If there are devices on both ends, you don't terminate; otherwise, you do. That's all that's needed to turn device detection into automatic termination.

You're going to need to explain the proposed scheme in more detail; I don't understand how it's supposed to work.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 12:55:05 pm
[quote author="nickjohnson"][quote author="Folknology"]You can use 3v3 CAN transceivers they are more energy efficient anyhow, the TI ones are very good for this.[/quote]

Thus far uCAN has assumed 5v CAN, since that's the usual standard. Is there a convincing reason to switch?

[/quote]

I think you are misunderstanding, 3v3 CAN transceivers, still operate the CANH/CANL signals at the standard voltages, they are compatible with the CAN standards

[quote author="nickjohnson"]
Quote
I have covered using linear regs above it's a really bad idea to use them to drop down to 3v3 from 12 or god forbid 24 volts, we should not be encouraging new designs to engage in this sort of practice.

That depends on the amount of current being used. You did ask for simple. :)

[/quote]

Well yes but with these kinds of voltage drops it doesn't require much current. One of the differences uCan can make is the ease with which a basic network devices can be designed (minimum BOM + cost) with the simple 5V addition.

[quote author="nickjohnson"]

Quote
In order to decide whether or not we need to terminate we need to establish if correct termination is already in place both upstream and downstream, only then can we act. detecting a device does not detect termination. the termination scheme I propose allows us to detect termination in either direction from the switch (normally at the centre), it can also flag un-terminated networks and adds no real complexity just the use of pin3.

If there are devices on both ends, you don't terminate; otherwise, you do. That's all that's needed to turn device detection into automatic termination.

You're going to need to explain the proposed scheme in more detail; I don't understand how it's supposed to work.[/quote]
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 01:01:08 pm
[quote author="Folknology"][quote author="nickjohnson"][quote author="Folknology"]You can use 3v3 CAN transceivers they are more energy efficient anyhow, the TI ones are very good for this.[/quote]

Thus far uCAN has assumed 5v CAN, since that's the usual standard. Is there a convincing reason to switch?

[/quote]

I think you are misunderstanding, 3v3 CAN transceivers, still operate the CANH/CANL signals at the standard voltages, they are compatible with the CAN standards[/quote]

Well, then they will still require a 5v rail - and if that rail has been attenuated by the cable, they won't be able to drive it as hard as if they had a proper 5v rail.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 01:07:31 pm
On many networks terminators already exist as part of that fixed network infrastructure (rather than relying on devices), in this case your device could be attached  to it and have devices downstream but not upstream, in this case your device would incorrectly add yet another extra terminator into the network that isn't at the end of the network.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 01:08:51 pm
[quote author="nickjohnson"]
....

Well, then they will still require a 5v rail - and if that rail has been attenuated by the cable, they won't be able to drive it as hard as if they had a proper 5v rail.[/quote]

Why would they require a 5v rail?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 01:17:15 pm
Here are some 3v3 CAN examples (http://http://www.ti.com/lsds/ti/interface/can-products.page#p305=3%20to%203.6;3%20to%205.5;3.3&p1690=No) from TI and they are more than capable of driving the networks, suggesting otherwise is nonsense and unfounded.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 01:22:09 pm
[quote author="Folknology"][quote author="nickjohnson"]
....

Well, then they will still require a 5v rail - and if that rail has been attenuated by the cable, they won't be able to drive it as hard as if they had a proper 5v rail.[/quote]

Why would they require a 5v rail?[/quote]

For those following along at home, this app note from TI explains the operation of their 3.3v transceivers, and how they interact with 5v networks: http://www.ti.com/lit/an/slla337/slla337.pdf (http://www.ti.com/lit/an/slla337/slla337.pdf)

I still think having 'optional' 5v on a pin is a bad idea. It adds complexity to all involved devices for a thus-far poorly defined use case. It's also going to be difficult for a 5v device to know how much current it can safely draw, or where that's coming from, and difficult for a network builder to know where there might be issues with the wires carrying too much current.

[quote author="Folknology"]On many networks terminators already exist as part of that fixed network infrastructure (rather than relying on devices), in this case your device could be attached  to it and have devices downstream but not upstream, in this case your device would incorrectly add yet another extra terminator into the network that isn't at the end of the network. [/quote]

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?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 01:31:07 pm
[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).

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 02:12:08 pm
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 30, 2013, 02:36:13 pm
[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]

I'm not sure I understand. How do you disable those 60ohm resistors? CAN_H and CAN_L are passed through from upstream to downstream, the device can't interrogate them seperately.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 02:43:10 pm
[quote author="bharrisau"][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]

I'm not sure I understand. How do you disable those 60ohm resistors? CAN_H and CAN_L are passed through from upstream to downstream, the device can't interrogate them seperately.[/quote]

This is down to the device itself, which doesn't connect upstream and downstream pin 3s until it completes its terminator detect sequence
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 30, 2013, 02:49:28 pm
What are pins 1 and 2 connected to?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 03:05:49 pm
[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?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 03:23:47 pm
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 03:46:13 pm
[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.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 03:53:51 pm
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 04:07:43 pm
[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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 04:49:54 pm
[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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 05:25:43 pm
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 05:27:00 pm
[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.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 05:28:14 pm
[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?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 05:46:33 pm
[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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 05:55:59 pm
[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).
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 06:05:12 pm
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 06:09:19 pm
[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.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 06:20:28 pm
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
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 06:22:55 pm
[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!)
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 08:12:47 pm
[quote author="nickjohnson"][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!)[/quote]


Most likely pin3 +Vaux and 6 GND, for low powered segments +Vaux could be +5v and for higher power then +CAN supply, both of these would fit well enough with current wiring.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on October 30, 2013, 08:24:12 pm
[quote author="Folknology"][quote author="nickjohnson"][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!)[/quote]


Most likely pin3 +Vaux and 6 GND, for low powered segments +Vaux could be +5v and for higher power then +CAN supply, both of these would fit well enough with current wiring.[/quote]

I'd strongly suggest using both 3 and 6 for an additional supply, and using the existing ground wires. Otherwise you're back to shorting out magjacks if accidentally plugged into one.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 30, 2013, 09:08:15 pm
Yeah you may be right, it would be safer

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 31, 2013, 02:31:22 am
[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]

How do you disable the termination on this design?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 31, 2013, 08:43:01 am
Well one would add bidirectional switches on the termination resistors and drive them with a wired OR (2 diodes) and a FET probably (Not shown on the circuit). However we are questioning the idea about active termination, as it adds a burden on the spec. I am likely not to use it at all and will probably revert to manual termination.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on October 31, 2013, 11:18:46 am
Ok. I thought your schematic was final, and I didn't see any switches to remove the 60ohm resistors.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on October 31, 2013, 11:33:44 am
Just to clarify, here is my final version, it uses manual termination via a plug in terminator on the 4 pin header (or line termination). The 4 pin header is also useful for testing both signal and lazy connections to bench based can devices.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: EasyRider on November 01, 2013, 02:13:11 pm
My notifications seem to be acting up, missed a lot of the conversation. I'm not arguing in favor of any particular way to do things, I'd just like to offer some datapoints about how we went about some of the stuff mentioned;

- Power: we used both "RJ45" (8P8C) and "RJ9" (4P4C) connectorts: devices used the 4-wire RJ9 (CanH, CanL, Gnd, 24V) only, "hubs" used RJ45 (CanH, CanL, 3xGnd, 3x24V) as backbone, RJ9 as "branches" for devices. Power on each RJ9 branch is limited to 0.4A by a PTC resettable fuse. Hubs have their own DC inputs - if it's energized, an intenal relay routes that to supply 24V to devices and the downstream backbone. If it isn't, the power incoming from the upstream backbone passes through.

- Termination: both device ports are equivalent (connected 1:1 in parallel), a simple jumper connects a 120 Ohm terminator between CanH and CanL if fitted. Obviously, we remove it from everywhere except the end of the line. We may move on to resistors crimped directly into RJ9 plugs to phase them out.

- Addressing: using 8 bits as address, we have a convention that 1-127 are unicast / individual addresses, 128 is broadcast (all devices have one of their filters set to listen to that), and 129-255 are "group addresses" - any device can be configured to listen to several of those (depending on how many filters are left available after the one for the unicast address and the other for the broadcast one), ie. a device can be set up as "member" of group, say, 130, 151 and 200 - sending any command to any of those is executed _and_ replied to by all group members simultaneously. CAN arbitration sorts out the ensuing storm of replies. Zero is reserved as the address all unconfigured devices come with, although our network doesn't really care specifically.

- Bulk data: I'm sure there will be valid uses for that, but I wouldn't expect streaming audio to be one of them. Believe it or not we actually tried that at one point, and at 125Kbaud the band was _just barely_ enough to carry a _mono_ stream of GSM-codec-encoded voice stream. To put it differently - we deride 128kbps mp3s today, but 125kbaud won't even get anywhere near that in actual data throughput...
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on November 03, 2013, 10:06:06 am
The maximum throughput of the CAN bus is <49% of the bitrate (50% overhead plus interframe spacing). So at 1 Mbps you could more than likely manage a 128kbps stream depending on the priority and contention.

Edit: CAN FD has a max effective bitrate of about 4Mbps, if you had something like the XMOS chips you could do a high speed hub<->hub connection.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on November 03, 2013, 12:05:09 pm
I have had a long hard think about using those spare pins for power, I think the best thing we can do that is safe for Ethernet and means we get some kind of benefit is to connect both pins 3 and 6 to ground. This has a few advantages:

1) It should be safe for Ethernet as the there is no potential difference across magnetics
2) It helps on the power side by reducing line losses on the return path
3) It helps reduce noise picked up on those lines
4) It doesn't add any galvanic interference
5) It makes routing of these pins simpler on PCBs
6) It reduces ground resistance

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: EasyRider on November 03, 2013, 12:12:22 pm
[quote author="bharrisau"]The maximum throughput of the CAN bus is <49% of the bitrate (50% overhead plus interframe spacing). So at 1 Mbps you could more than likely manage a 128kbps stream depending on the priority and contention.[/quote]
Ah, sure, I was just assuming we're talking about the 125Kbaud speed that has been talked about earlier, which gives you some range. Faster speeds reduce maximum cable length rather quickly "building size" (VSCP quotes ~25m for 1Mbaud - less of a problem for short-ish "hub-connected" segments, of course).
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on November 03, 2013, 12:30:48 pm
[quote author="Folknology"]I have had a long hard think about using those spare pins for power, I think the best thing we can do that is safe for Ethernet and means we get some kind of benefit is to connect both pins 3 and 6 to ground. This has a few advantages:

1) It should be safe for Ethernet as the there is no potential difference across magnetics
2) It helps on the power side by reducing line losses on the return path
3) It helps reduce noise picked up on those lines
4) It doesn't add any galvanic interference
5) It makes routing of these pins simpler on PCBs
6) It reduces ground resistance

regards
Al[/quote]

None of those points are especailly compelling. Keep them reserved for now, a good use for them may present itself once the rest has been sorted out and products are actually using the pins.

I've just summaried the VSCP events. 6-bits for the uCAN subtype (VSCP type) is enough to support all the currently defined VSCP classes.
There are 34 currently defined VSCP classes, 7-bits for the uCAN type field allows ~41% of the VSCP classes to keep their original number. And the 7-bit means 73% of the address space is available.

From that, I think the best use of the 18bits in the ID field would be 7 bits for the type, 6 bits for the subtype and 5 bits for the zone/topic (defined by the type). That alows for 32 zones - I haven't used zones before in anything, but I think for the target audience 32 should be heaps.

I know this is only a tiny change from your 7-7-4, but the 7 for subtype will probably go to waste (based on the work VSCP has done), and 16 feels a lot smaller than 32.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on November 03, 2013, 01:08:38 pm
[quote author="bharrisau"][quote author="Folknology"]I have had a long hard think about using those spare pins for power, I think the best thing we can do that is safe for Ethernet and means we get some kind of benefit is to connect both pins 3 and 6 to ground. This has a few advantages:

1) It should be safe for Ethernet as the there is no potential difference across magnetics
2) It helps on the power side by reducing line losses on the return path
3) It helps reduce noise picked up on those lines
4) It doesn't add any galvanic interference
5) It makes routing of these pins simpler on PCBs
6) It reduces ground resistance

regards
Al[/quote]
None of those points are especailly compelling. Keep them reserved for now, a good use for them may present itself once the rest has been sorted out and products are actually using the pins.
[/quote]

Well (1) is a given as we need that for safety, (2) is extremely important for efficiency for network powered devices (the bulk) this provides about 25% reduction.(3,4) Its always good to improve SNR by reducing noise and interference, (5) makes the layout more approachable for designers, (6) this is always a good idea.

Any alternative requires treating the two pins as one because we cannot have any potential difference (1), thus it's really just 1 pin. In order to make best use of that copper i.e. by using both cores then power is the obvious application, it has to be at the same potential, thus ground is therefore the safest and most efficient choice. It benefits all devices on the network. Also remember CAN has had spare/reserved pins for over a decade, guess what they never got used, they just got wasted!! I say put that expensive copper to use, there is no advantage to leaving them fallow.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on November 03, 2013, 01:15:20 pm
Quote
Any alternative requires treating the two pins as one because we cannot have any potential difference (1), thus it's really just 1 pin. In order to make best use of that copper i.e. by using both pins then power is the obvious application, it has to be at the same potential, thus ground is therefore the safest and most efficient choice. It benefits all devices on the network. Also remember CAN has had spare/reserved pins for decades, guess what they never got used, they just got wasted!! I say put that expensive copper to use, there is no advantage to leaving them fallow.

Not quite true - they can't be used for anything with a persistent DC level and a low impedance. That doesn't rule out using them as separate signal conductors; it just makes them poorly suited to carrying different power rails.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on November 03, 2013, 01:33:29 pm
[quote author="nickjohnson"]
Quote
Any alternative requires treating the two pins as one because we cannot have any potential difference (1), thus it's really just 1 pin. In order to make best use of that copper i.e. by using both pins then power is the obvious application, it has to be at the same potential, thus ground is therefore the safest and most efficient choice. It benefits all devices on the network. Also remember CAN has had spare/reserved pins for decades, guess what they never got used, they just got wasted!! I say put that expensive copper to use, there is no advantage to leaving them fallow.

Not quite true - they can't be used for anything with a persistent DC level and a low impedance. That doesn't rule out using them as separate signal conductors; it just makes them poorly suited to carrying different power rails.[/quote]

I stand corrected, however the benefits I believe out way the disadvantages.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on November 03, 2013, 04:08:37 pm
There is an alternative use for these two pins that I thought about a while back, that is to carry an RS485 pair. This optional auxilary  pair could cater better for the streaming type of coms that nick has indicated he would like to see. This would leave the CAN bus for the short realtime packets supported by all uCAN devices. If the higher throughput streaming/UDP like features were required by the device it would use the extra RS485 pair, getting the best of both worlds.

BTW When using a switched based uCan topology you could move quite a lot of data over the aux channel, you could easily tackle audio for example.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on November 04, 2013, 01:50:07 pm
It would also be nice to be able to increase the voltage limit to 36V, again this enables great power to be transmitted over uCan and with smaller losses.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on November 04, 2013, 01:57:46 pm
I'm of two minds about higher voltage limits. Being able to safely transmit more power is a good thing, but the higher the voltage, the harder it is to find parts that convert it down. I've redesigned my boards with the LM22675, which goes up to 42V, so only minor changes to the passives would be required to support 36V. What are other people planning to use?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on November 04, 2013, 02:58:19 pm
[quote author="nickjohnson"]I'm of two minds about higher voltage limits. Being able to safely transmit more power is a good thing, but the higher the voltage, the harder it is to find parts that convert it down. I've redesigned my boards with the LM22675, which goes up to 42V, so only minor changes to the passives would be required to support 36V. What are other people planning to use?[/quote]

One of the reasons we centred on 36V was the availability of switchers, Mouser lists well over 1,500 switchers that are capable of operating at this input voltage. (I think this was because 36V was proposed as a new Auto standard to replace 12V for non-drive subsystems, to provide more power and reduce internal losses)

They can also be cheap like MC34063EBD-TR which can be had for less than $0.20 in volume

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on November 05, 2013, 10:58:01 am
Sounds good.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on November 05, 2013, 11:23:22 am
Agreed, I'm convinced. Let's make a max of 36v official.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: sam512bb on November 05, 2013, 03:20:49 pm
[quote author="nickjohnson"]Agreed, I'm convinced. Let's make a max of 36v official.[/quote]

Good day All,

Just a heads up, but I think anything over 30V would be considered Class 1 device/wiring... which means the wiring, device enclosure, etc is considered a shock and fire hazard and so would require all of the nuances (approvals, wire sizes, wire markings, ratings, etc) associated with line voltage (i.e. 120VAC, etc) equipment. 

http://ecmweb.com/content/understanding ... ifications (http://ecmweb.com/content/understanding-nec-circuit-classifications)

Class 2 is a lot more flexible, but does have a voltage and VA limit (100VA).

Cheers,

Sam
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on November 05, 2013, 03:24:22 pm
[quote author="sam512bb"][quote author="nickjohnson"]Agreed, I'm convinced. Let's make a max of 36v official.[/quote]

Good day All,

Just a heads up, but I think anything over 30V would be considered Class 1 device/wiring... which means the wiring, device enclosure, etc is considered a shock and fire hazard and so would require all of the nuances (approvals, wire sizes, wire markings, ratings, etc) associated with line voltage (i.e. 120VAC, etc) equipment. 

http://ecmweb.com/content/understanding ... ifications (http://ecmweb.com/content/understanding-nec-circuit-classifications)

Class 2 is a lot more flexible, but does have a voltage and VA limit (100VA).
[/quote]

Fair point. This is up to the user, though - if this is a concern, they can reduce the voltage to 24V, or jump through the necessary hoops to use approved wiring.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on November 05, 2013, 03:50:35 pm
[quote author="sam512bb"][quote author="nickjohnson"]Agreed, I'm convinced. Let's make a max of 36v official.[/quote]

Good day All,

Just a heads up, but I think anything over 30V would be considered Class 1 device/wiring... which means the wiring, device enclosure, etc is considered a shock and fire hazard and so would require all of the nuances (approvals, wire sizes, wire markings, ratings, etc) associated with line voltage (i.e. 120VAC, etc) equipment. 

http://ecmweb.com/content/understanding ... ifications (http://ecmweb.com/content/understanding-nec-circuit-classifications)

Class 2 is a lot more flexible, but does have a voltage and VA limit (100VA).

Cheers,

Sam[/quote]

Wow is it me or are NEC standards difficult to understand, more here http://ecmweb.com/code-basics/classifyi ... 3-circuits (http://ecmweb.com/code-basics/classifying-and-using-class-1-2-and-3-circuits)

Still not completely convinced I understand what is classed as what..

Especially as it relates to things one might place on uCan, as their definition of signalling is different to ours I think

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: sam512bb on November 05, 2013, 04:07:52 pm
[quote author="nickjohnson"]

Fair point. This is up to the user, though - if this is a concern, they can reduce the voltage to 24V, or jump through the necessary hoops to use approved wiring.[/quote]

Good day Nick,

Agreed.  However, some users may not be aware of these issues and simply forge ahead without any regard and may get themselves into something serious.  Perhaps a cautionary notice on the designs may be a good idea?

Cheers,

Sam
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on November 05, 2013, 04:13:44 pm
[quote author="sam512bb"][quote author="nickjohnson"]

Fair point. This is up to the user, though - if this is a concern, they can reduce the voltage to 24V, or jump through the necessary hoops to use approved wiring.[/quote]

Good day Nick,

Agreed.  However, some users may not be aware of these issues and simply forge ahead without any regard and may get themselves into something serious.  Perhaps a cautionary notice on the designs may be a good idea?

Cheers,

Sam[/quote]

Yup, will do.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: sam512bb on November 05, 2013, 04:14:35 pm
[quote author="Folknology"]

Wow is it me or are NEC standards difficult to understand, more here http://ecmweb.com/code-basics/classifyi ... 3-circuits (http://ecmweb.com/code-basics/classifying-and-using-class-1-2-and-3-circuits)

Still not completely convinced I understand what is classed as what..

Especially as it relates to things one might place on uCan, as their definition of signalling is different to ours I think

regards
Al[/quote]

Good day Al,

I think these and other standards are meant to be confusing ... and quite tedious to read too :) ...  Sadly, most of these technical documents include "legal-ese" which tends to be wordy and, at times, somewhat ambiguous and subject to the interpretation of the Inspector and/or Governing Body.  I cannot speak towards the NEC, but in Canada we have another document that simplifies the Canadian NEC equivalent (the CEC) which most people use for conventional wiring.  That being said, one must still refer to the formal document for the details... alas...

Cheers,

Sam
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: bharrisau on November 05, 2013, 10:46:18 pm
Looks like a 36V power supply can still be Class-2 if its maximum current is appropriately limited http://www.nfpa.org/Assets/files/AboutT ... PDraft.pdf (http://www.nfpa.org/Assets/files/AboutTheCodes/70/70-A2013-ROPDraft.pdf)

The table is on page 70-779. Class-2 DC 32V supply with OCP can be rated for up to 3.125A (100VA). Above 60V things get limitied to 5mA.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on November 18, 2013, 08:24:55 pm
First working uCAN hardware!

(http://https://lh4.googleusercontent.com/-FkAGd5Ac9RY/UoppZ2qyrzI/AAAAAAAAE34/jdMOy9Q3Yfc/w852-h640/IMG_20131118_191554.jpg)

It's not much to look at, but it is fully functional! A power injector with a 12v wall wart, a Raspberry Pi with uCAN expansion board, and an Arduino Uno with uCAN shield, connected together into the first fully functional uCAN network - at hardware level, at least. :)

A simple Arduino program sends incrementing 4 byte packets at 100 kilobits:

Code: [Select]
#include <mcp_can.h>
#include <SPI.h>

void setup()
{
  Serial.begin(115200);
  if(CAN.begin(CAN_100KBPS) ==CAN_OK) Serial.print("can init ok!!rn");
  else Serial.print("Can init fail!!rn");
}

uint32_t counter;
void loop()
{
  CAN.sendMsgBuf(0x00, 0, 4, (unsigned char*)&counter); 
  counter += 1;
  delay(1000);
}

While candump on the RPi picks them up:

Code: [Select]
pi@raspberrypi ~ $ candump can0
  can0  000  [4]  D9 01 00 00
  can0  000  [4]  DA 01 00 00
  can0  000  [4]  DB 01 00 00
  can0  000  [4]  DC 01 00 00
  can0  000  [4]  DD 01 00 00
  can0  000  [4]  DE 01 00 00
  can0  000  [4]  DF 01 00 00
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Sjaak on November 18, 2013, 11:21:15 pm
For the init function: "CAN't init" ?

I'm sorry... bad joke :D
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on November 19, 2013, 10:44:45 am
Hey congrats Nick, big achievement, that should feel good

Next is uCan formatted package?

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on November 19, 2013, 10:56:01 am
[quote author="Folknology"]Hey congrats Nick, big achievement, that should feel good

Next is uCan formatted package?[/quote]

Yup! I'm working on the protocol spec for YARP (the discovery sub-protocol) and a basic API right now.

As a reminder, I have Arduino, Raspberry Pi, and BeagleBone Black PCBs - fully populated - I can send to anyone who's interested in experimenting and contributing to the protocol.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on November 19, 2013, 08:10:57 pm
I've written up a preliminary spec for YARP, the address/network management protocol here (http://https://github.com/arachnidlabs/uCAN/wiki/Network-layer#0---yarp---network-management). I've tried to keep it as simple as possible; there are only two message types, 'query', which is used to determine the hardware ID for a node and vice-versa, and 'assignment', which is used to reassign addresses.

I've also written up more detail on the node IDs and hardware addresses here (http://https://github.com/arachnidlabs/uCAN/wiki/Data-link-layer#addressing).

Feedback appreciated!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on November 19, 2013, 10:04:44 pm
I've also defined the beginnings of a simple portable API, here (http://https://github.com/arachnidlabs/uCAN/wiki/API).
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: sam512bb on November 20, 2013, 04:08:51 am
Good day All,

Just a heads up... the November 2013 edition of Elektor Magazine has an article about making a CAN Bus tester/snooper.

Cheers,

Sam
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on November 21, 2013, 12:52:35 pm
I've started work on an Arduino uCAN library, with CAN functionality provided by the Seeedstudio CAN library. Source can be found here (http://https://github.com/arachnidlabs/uCAN_Arduino). So far, it implements YARP only, with the exception of dynamic address assignment.

Here it is in action:

Code: [Select]
pi@raspberrypi ~/sketchbook/libraries/uCAN_Arduino $ cansend can0 18201000#
  can0  18201000  [0]
  can0  18380010  [6]  00 A7 38 00 00 01

0x18201000 is 'High priority YARP query from node ID 0x00 to node ID 0x10', while 0x18380010 is 'High priority YARP query response from node ID 0x10 to node ID 0x00'.

Note this isn't quite up to spec: YARP query responses should always be sent to the broadcast address, a bug I'll fix shortly.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on December 02, 2013, 08:28:13 pm
I've now got working Arduino and Python libraries, with RAP and YARP support. I can read and write registers on one, from the other.

I'm currently working on porting the Arduino library to ISO-standard C in a platform-independent manner, so each platform only needs to define send, receive and init routines. My current first target is the NXP LPC11C24, since it's got an onboard CAN PHY.

Regarding protocol decisions, I'm wondering about ways to assign unique IDs for the 48 bit identifier. Requiring people to issue unique IDs for each device is all very well in theory, but I suspect many people won't program a unique one into EEPROM, and will use code unmodified with a sample ID encoded.

One option to combat this would be using a unique ID chip. Microchip have a range of single-wire and I2C ones for under $0.50 in quantity. It adds to the complexity of the board overall, though.

Thoughts?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: EasyRider on December 04, 2013, 09:43:51 am
[quote author="nickjohnson"]Regarding protocol decisions, I'm wondering about ways to assign unique IDs for the 48 bit identifier. Requiring people to issue unique IDs for each device is all very well in theory, but I suspect many people won't program a unique one into EEPROM, and will use code unmodified with a sample ID encoded.[/quote]
We just used the ID locations of the PIC (not the EEPROM) to store a unique ID - this had the advantage that those were prominently visible and accessible fields in our / most programmers, even allowing automatic serialization - and the code itself in the hex file was set up neutrally (no ID included / blank); it checked for a non-blank ID first thing at boot, stopping and blinking the red LED if it didn't find one. Of course, we never meant this to be particularly cross-platform or anything...
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on December 04, 2013, 10:25:12 am
[quote author="EasyRider"][quote author="nickjohnson"]Regarding protocol decisions, I'm wondering about ways to assign unique IDs for the 48 bit identifier. Requiring people to issue unique IDs for each device is all very well in theory, but I suspect many people won't program a unique one into EEPROM, and will use code unmodified with a sample ID encoded.[/quote]
We just used the ID locations of the PIC (not the EEPROM) to store a unique ID - this had the advantage that those were prominently visible and accessible fields in our / most programmers, even allowing automatic serialization - and the code itself in the hex file was set up neutrally (no ID included / blank); it checked for a non-blank ID first thing at boot, stopping and blinking the red LED if it didn't find one. Of course, we never meant this to be particularly cross-platform or anything...[/quote]

Do these come pre-filled with a unique ID, or did you have to generate them? My concern is that if we expect people to write a unique ID for each device into EEPROM or some device-specific storage themselves, most people won't, and we'll get lots of devices with duplicate IDs.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: EasyRider on December 04, 2013, 11:43:10 am
[quote author="nickjohnson"]Do these come pre-filled with a unique ID, or did you have to generate them? My concern is that if we expect people to write a unique ID for each device into EEPROM or some device-specific storage themselves, most people won't, and we'll get lots of devices with duplicate IDs.[/quote]
The ID locations are normally blank out of factory. It was up to us to serialize a suitable ID into them at program time, the code's job was just to catch and visibly identify any device we might have failed to load with an ID. Of course, keeping the IDs unique was our job - admittedly, this worked for us since we didn't need to rely on anyone else having to do that part... :)

The standalone ID chips you mentioned would of course solve this, as long as you plan including them everywhere. Unfortunately, I can't really see any middle ground - you either rely on the user to do the right thing or need to add some extra hardware.

There might be ways around that via dedicated procedures - you'd either need the user to perform some special "init" actions to generate / assign a unique ID to each device manually, or the protocol would have to be smart enough to register any number of identical clones and provide them with unique IDs on-the-fly. All of which have their disadvantages, of course.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on December 04, 2013, 11:56:25 am
[quote author="EasyRider"]The standalone ID chips you mentioned would of course solve this, as long as you plan including them everywhere. Unfortunately, I can't really see any middle ground - you either rely on the user to do the right thing or need to add some extra hardware.[/quote]

One possible middle ground is to subdivide the ID space. All IDs with a certain prefix have suffixes that are generated by a specific ID chip; then it's up to manufacturers to decide if they want to use those or not.

Quote
There might be ways around that via dedicated procedures - you'd either need the user to perform some special "init" actions to generate / assign a unique ID to each device manually, or the protocol would have to be smart enough to register any number of identical clones and provide them with unique IDs on-the-fly. All of which have their disadvantages, of course.

I'd really rather not complicate the protocol by making it try and identify and renumber identical devices!
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on December 06, 2013, 01:51:43 pm
I would be against making the BOM larger by actually requiring an id chip, but at the same time realise unique IDs are required. Adding a unique id is fairly simple and can be either hardcoded (for testing) or EEprom/flashed for production, some chips do come with IDs but this certainly isn't universal. What would be nice is a simple agreed method of generating and allocating ids to folks.

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on December 09, 2013, 09:02:20 am
I've been looking at various ID allocation schemes, and decided on expanding the hardware ID to 56 bits from 48 - that's the largest we can fit in a response along with a node ID - which means the ID space can be partitioned out to different types of allocation scheme. I've detailed some initial ones here (http://https://github.com/arachnidlabs/uCAN/wiki/Data-link-layer#hardware-addresses). I hope nobody thinks this overcomplicates things; it's important to realise that a device creator just has to pick whichever scheme is most convenient to them. My goal here is to reduce the chance of accidental collisions as much as possible.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Sjaak on December 09, 2013, 02:23:52 pm
I recently bought an TL866 programmer on ebay. This software has an automatical serial number generator and does support some uC PICs.

Random link to the tl866 programmer here: http://www.ebay.com/itm/USB-MiniPro-TL8 ... 337a236a5b (http://www.ebay.com/itm/USB-MiniPro-TL866CS-Universal-BIOS-Programmer-EEPROM-FLASH-8051-AVR-GAL-PIC-SPI-/221092473435?pt=LH_DefaultDomain_0&hash=item337a236a5b)

Just a side note.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on December 09, 2013, 02:27:04 pm
[quote author="Sjaak"]I recently bought an TL866 programmer on ebay. This software has an automatical serial number generator and does support some uC PICs.

Random link to the tl866 programmer here: http://www.ebay.com/itm/USB-MiniPro-TL8 ... 337a236a5b (http://www.ebay.com/itm/USB-MiniPro-TL866CS-Universal-BIOS-Programmer-EEPROM-FLASH-8051-AVR-GAL-PIC-SPI-/221092473435?pt=LH_DefaultDomain_0&hash=item337a236a5b)

Just a side note.[/quote]

Very nice! Assuming the serial number length is flexible, that will work well with the PEN-based numbering scheme.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: neslekkim on December 09, 2013, 03:08:31 pm
the microcontroller you linked to in your first post have an unique id:

"Unique device serial number for identification"

http://www.nxp.com/products/microcontro ... FBD48.html (http://www.nxp.com/products/microcontrollers/cortex_m0_m0/LPC11C24FBD48.html)

Or is it an id chip on that board?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on December 09, 2013, 03:16:16 pm
[quote author="neslekkim"]the microcontroller you linked to in your first post have an unique id:

"Unique device serial number for identification"

http://www.nxp.com/products/microcontro ... FBD48.html (http://www.nxp.com/products/microcontrollers/cortex_m0_m0/LPC11C24FBD48.html)

Or is it an id chip on that board?[/quote]

Indeed it does. I'm working with it at the moment as I expand the uCAN libraries. The onboard ID is 128 bits, though, which means that it has to use the 1/1 scheme: hashing the ID into 55 bits and hoping* they don't collide.

* It's a pretty good hope, to be fair. With a maximum of 255 nodes, there are 255 * 254 = 64,770 possible collisions; dividing 2^55 by that gives us a chance of 1 in 560,000,000,000 that any fully populated uCAN network will suffer from a hash collision.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Sjaak on December 09, 2013, 03:46:21 pm
[quote author="nickjohnson"][quote author="Sjaak"]I recently bought an TL866 programmer on ebay. This software has an automatical serial number generator and does support some uC PICs.

Random link to the tl866 programmer here: http://www.ebay.com/itm/USB-MiniPro-TL8 ... 337a236a5b (http://www.ebay.com/itm/USB-MiniPro-TL866CS-Universal-BIOS-Programmer-EEPROM-FLASH-8051-AVR-GAL-PIC-SPI-/221092473435?pt=LH_DefaultDomain_0&hash=item337a236a5b)

Just a side note.[/quote]

Very nice! Assuming the serial number length is flexible, that will work well with the PEN-based numbering scheme.[/quote]

You can use the ID location or a position in memory. From the top of my head you can choose between various date-time formats, random number and sequential.

Edit: You can also provide a custom .dll which provide a custom serial function.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on December 10, 2013, 11:28:28 am
*Update - Things ticking along here, just received some boards back ready to assemble and play with. The top ones are uCan slices and the the lower ones are open energy controller SDK/eval board which will also sport uCan ports. Both of these are Xmos focused and will allow me to start developing the stack for that platform. I am still waiting for components to populate though so its's going to be a while before I have anything to show.

[attachment=0]

Regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on December 10, 2013, 11:36:47 am
[quote author="Folknology"]*Update - Things ticking along here, just received some boards back ready to assemble and play with. The top ones are uCan slices and the the lower ones are open energy controller SDK/eval board which will also sport uCan ports. Both of these are Xmos focused and will allow me to start developing the stack for that platform. I am still waiting for components to populate though so its's going to be a while before I have anything to show.[/quote]

Nice! It's really awesome to see some new uCAN designs!

Would you find it useful to have some other uCAN hardware to connect and test with?
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on December 10, 2013, 12:23:20 pm
[quote author="nickjohnson"][quote author="Folknology"]*Update - Things ticking along here, just received some boards back ready to assemble and play with. The top ones are uCan slices and the the lower ones are open energy controller SDK/eval board which will also sport uCan ports. Both of these are Xmos focused and will allow me to start developing the stack for that platform. I am still waiting for components to populate though so its's going to be a while before I have anything to show.[/quote]

Nice! It's really awesome to see some new uCAN designs!

Would you find it useful to have some other uCAN hardware to connect and test with?[/quote]

Hi Nick thanks and yes some hardware to test it against/with would be rather handy. In fact I was thinking about this the other day what we need is a reference platform against which all other uCan devices can be tested. The most logical solution to me is a Raspbery Pi based uCan implementation (like yours for example) having Linux would really help with building tests suites/rigs/mocks etc.. If we go this route the RPi version should also be the version with the most up to date and stable stack (/me hopes this isn't contradictory).

I certainly have a few RPi's around here would just need one of your uCan boards, of course you are also welcome to any of my boards in return. I also extend this to others on the forum that would like to work on the Xmos side of the stack I have several uCan slice boards I can spare for those interested (you would need an Xmos startkit (http://http://www.xmos.com/startkit) or Slicekit (http://https://www.xmos.com/products/xkits/slicekit) to use it obviously).

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on December 10, 2013, 12:31:16 pm
[quote author="Folknology"][quote author="nickjohnson"][quote author="Folknology"]*Update - Things ticking along here, just received some boards back ready to assemble and play with. The top ones are uCan slices and the the lower ones are open energy controller SDK/eval board which will also sport uCan ports. Both of these are Xmos focused and will allow me to start developing the stack for that platform. I am still waiting for components to populate though so its's going to be a while before I have anything to show.[/quote]

Nice! It's really awesome to see some new uCAN designs!

Would you find it useful to have some other uCAN hardware to connect and test with?[/quote]

Hi Nick thanks and yes some hardware to test it against/with would be rather handy. In fact I was thinking about this the other day what we need is a reference platform against which all other uCan devices can be tested. The most logical solution to me is a Raspbery Pi based uCan implementation (like yours for example) having Linux would really help with building tests suites/rigs/mocks etc.. If we go this route the RPi version should also be the version with the most up to date and stable stack (/me hopes this isn't contradictory).[/quote]

I agree on a reference platform, but I think a Beaglebone Black would be a better choice, since it's got built in CAN, while getting CAN working on an RPi is a bit of an exercise in frustration, currently. Or possible an Arduino, for simplicity's sake? It really depends what people intend to do with the platform.

For what it's worth, my Python implementation of uCAN (for use on any linux platform) is fully unit tested and is well suited to being a reference implementation. The C port is a little more rough-and-ready.

Quote
I certainly have a few RPi's around here would just need one of your uCan boards, of course you are also welcome to any of my boards in return. I also extend this to others on the forum that would like to work on the Xmos side of the stack I have several uCan slice boards I can spare for those interested (you would need an Xmos startkit (http://http://www.xmos.com/startkit) or Slicekit (http://https://www.xmos.com/products/xkits/slicekit) to use it obviously).

Unfortunately, I don't have any XMOS boards to develop with, but thanks for the offer! Email me your address at nick@arachnidlabs.com and I'll get some hardware sent out ASAP.

In other news, I'm about to start working on fleshing out the events protocol. Suggestions for an event taxonomy are welcome, as are clever names for the protocol.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on December 10, 2013, 12:42:31 pm
I don't mind going the BeagleBone Black route if you think it's superior, I've been looking for an excuse to buy one to supersede my older beaglebone! I am happy with BBB being the reference implementation BTW, I would much prefer it to Arduino..

P.S. Python would make for a simple and accessible test harness IMHO

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on December 18, 2013, 12:32:11 pm
[quote author="Folknology"]*Update - Things ticking along here, just received some boards back ready to assemble and play with. The top ones are uCan slices and the the lower ones are open energy controller SDK/eval board which will also sport uCan ports. Both of these are Xmos focused and will allow me to start developing the stack for that platform. I am still waiting for components to populate though so its's going to be a while before I have anything to show.

[attachment=0]

Regards
Al[/quote]

I just got sent an Xmos for Xmas, so I'd love to get my hands on an Xmos slice.

Just a reminder, please do send me your address details (and desired test boards) to nick@arachnidlabs.com so I can send something to you.
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Folknology on December 29, 2013, 11:21:39 pm
Thanks for the gentle reminder, I have been rather busy up to Xmas and as a result haven't even started on the board assembly (plus waiting for the drivers to arrive). I will fit this in over the next few months however and get cracking on the Xmos uCan code base, good news on winning a StartKit BTW, I have put a uLan slice aside for you, we should get together in London sometime in the new year.

P.S. There seems to be a BBB drought currently..

regards
Al
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: Dro on July 23, 2014, 10:05:22 pm
Hey Guys,

Not sure if there has been any progress regarding uCAN but I am currently looking for a Higher level application for a home automation project that I have started. I considered using both CANopen and VCSP and looks like I felt the same way you guys feel.

I did find the following CANopen library that was originally created for PIC and accordingly to the author it should be fairly easy to port to other uCs. I am not sure if anybody wants to take a stab at it.

http://sourceforge.net/projects/canopennode/ (http://sourceforge.net/projects/canopennode/)

Let me know if this project is still going so I can see if I can use it for CAN home automation. My board is based on ATMega328p running Arduino bootloader + MCP 25625.

Thanks,

Dro
Title: Re: uCAN: A protocol stack for microcontroller networking
Post by: nickjohnson on July 23, 2014, 11:10:10 pm
[quote author="Dro"]Hey Guys,

Not sure if there has been any progress regarding uCAN but I am currently looking for a Higher level application for a home automation project that I have started. I considered using both CANopen and VCSP and looks like I felt the same way you guys feel.

I did find the following CANopen library that was originally created for PIC and accordingly to the author it should be fairly easy to port to other uCs. I am not sure if anybody wants to take a stab at it.

http://sourceforge.net/projects/canopennode/ (http://sourceforge.net/projects/canopennode/)

Let me know if this project is still going so I can see if I can use it for CAN home automation. My board is based on ATMega328p running Arduino bootloader + MCP 25625.

Thanks,

Dro[/quote]

It's been more or less on hold for me for a while since I've had other things to work on like my kickstarter, but I certainly intend to pick it up again soon.