Skip to main content


This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - Tarloth

Project development, ideas, and suggestions / Re: uCAN: A protocol stack for microcontroller networking

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.
Project development, ideas, and suggestions / Re: uCAN: A protocol stack for microcontroller networking
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.
Project development, ideas, and suggestions / Re: uCAN: A protocol stack for microcontroller networking
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.

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).
Project development, ideas, and suggestions / Re: uCAN: A protocol stack for microcontroller networking

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.

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.
Project development, ideas, and suggestions / Re: uCAN: A protocol stack for microcontroller networking
Folknology, I don´t like the analogies because depends in the interpretations, BUT, I can comment in terms of the last one.

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.

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. 

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):

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.
Project development, ideas, and suggestions / Re: uCAN: A protocol stack for microcontroller networking
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.
Project development, ideas, and suggestions / Re: uCAN: A protocol stack for microcontroller networking
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.
Open Bench Logic Sniffer / Re: Advanced Trigger Questions
I agree, I do the trigger translating manually to """basic""" blocks, but it´s helpfull to have some shortcuts as have in modern PRO LA. I agree that it´s much easier to implement at the client side through an assistant or something like it. Thanks for your answer