Hi to everybody! I should implement a function on my uC (Freescale MAC7121) that will receive and/or send data with length > 8 bytes: is it possible?
I read on the datasheet that the message buffer is max 8 bytes, but I need to send and to receive more data.
Thanks, Marco
--------------------------------------- Posted through
Marco T. schrieb:
By protocol specification, a CAN message can have a maximum of eight data bytes.
If you need to transfer more than eight bytes, you must do it in smaller chunks.
Tilmann
Den torsdag den 19. november 2015 kl. 13.38.19 UTC+1 skrev Tilmann Reh:
yep, 8 by definition
-Lasse
CAN itself will only send up to eight bytes. Generally one uses some other protocol that's built on top of CAN, but that's specific to CAN underneath and whatever you need on top. Also generally, any such protocol will have a way of breaking a long message into smaller chunks for transmission, and reliably reassembling them at the receiving end.
There's a number of established protocols, each designed for a specific use. Depending on your needs you can use one of those outright, build your own protocol inspired by one of those, or just build a protocol from scratch.
I suggest a web search on "CAN protocols", or a good book. The two protocols that I (vaguely) remember are CanOpen and a SAE protocol that's specific to car applications. I don't remember enough, nor do I know enough about what you're doing, to recommend a specific protocol.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
The CAN specification specifies up to 64 bits (8 bytes) of payload and an 11 or 29 bit identifier. In principle, you could transfer one resp. three additional bytes in the identifier, but then you could have only
8 resp. 32 different identifier in the whole bus.So you might be able to transfer up to 11 bytes in a single message using the long identifier format.
However, this would make it very hard to use any normal CAN devices on the bus and it might also be hard to set the message filters on the receivers (depending on processor type).
I wonder when (whether) CAN FD will be supported widely.
Oliver
I'd kind of like to see CAN expire in general. There are different versions of an Ethernet PHY that can replace it. For other domains, there's PROFIBUS, which is weird but at least supports variable length PDUs.
-- Les Cargill
I am not familiar with CAN but I would like to see a standardized Ethernet connector for coaxial cable plus power pins (12V?). Have been dreaming of that for may be 25 years. Apparently there has been no interest. Nowadays as we have more RAM for buffer memory and they promote that IoT thing the necessity has eventually become obvious - hopefully...
Dimiter
------------------------------------------------------ Dimiter Popoff, TGI
------------------------------------------------------
What's wrong with PoE? You can run it over round cables with 4-conductor M12 connectors*. Works a treat.
IoT looks a lot like hype to me.
-- Les Cargill
CAN is ideal when you have a lot of small nodes with a few, say 16 binary or a few analog I/Os in a node. For other protocols you probably would have to use a concentrator/gateway and hardwire the nodes to the concentrator before going to some bus structure. With CAN it is economical to connect the small nodes to the buss directly.
This works great with a small network (less than 10 m), but things get hairy at 250 m or even at 1000 m with very low data rates due to the signal propagation delay.
The problem with Ethernet protocols is the requirement of at least 64 bytes total, so for most small I/O nodes, they do not even fill that minimum size frame.
One exception is EtherCAT ttps://en.wikipedia.org/wiki/EtherCAT in which the master sends out a big Ethernet frame, which then passes through each slave. Each slave picks the bytes it is interested in. It can also reuse a slot in the frame and insert input data into a free slot and finally the frame is passed back to the master, extracting all input data inserted into the frame during the pass through each slave. Of course, this requires specialized hardware in each node. The delay is only a few Ethernet bit times in each slave.
Think about a local train, in which passengers are leaving at each station and others will enter at each station.
At least Profibus DP is just glorified multidrop Modbus RTU on RS-485. with all the same issues with small nodes as with all request/response protocols.
Profibus is horrendous. It is complicated to implement, poorly documented, "open" in the worst sense of the word (meaning "anyone can pay lots of money to join a closed group that promises not to tell the rest of the world how bad the specification is). I had the "pleasure" of working with it many years ago, using a dedicated ASIC - the best available on the market at the time. The documentation was barely comprehensible - it had been translated from German to English by someone who clearly knew nothing about Profibus or electronics in general, and was barely competent in English. One critical chapter - containing the details of the register setup - was translated simply as "original German unclear".
Profibus may not be the worst choice of fieldbus protocol - but it is one that I would not recommend in normal circumstances.
CAN is a great choice when you want simple, clear and short telegrams between nodes. Now that it is common in microcontrollers, it is cheap and easy to implement. But that is only if /you/ have full control - if it is a closed network. It quickly gets horrible if you need to support DeviceNet, CANOpen, CAN Kingdom, or these other "high level" protocols on top of CAN. Instead of clear and simple sub-millisecond communication, you've got layers of negotiation about nodes and telegrams, complex device description documents, certifications, pretend "open" standards, and you have lost all hope of reliable timing.
Implementing your own scheme for larger telegrams over CAN is not hard when you have a specific task (typically everything in the system is short telegrams, except for firmware upgrades).
If you need something with higher bandwidth, jump straight to Ethernet. You can use standard networking and TCP/IP for ease of development (Modbus over TCP/IP handles pretty much everything you need for a typical fieldbus application, and you can add other protocols such as TFTP for larger transfers). Or you can use direct Ethernet frames for maximal efficiency.
The trouble with PoE is that it is vastly over-engineered, resulting in complicated and expensive parts. If you have full control of devices on each end, you can just pass 12V or 24V DC over a pair of lines on the cable. The easiest is to use one of the spare pairs (for 100 MBit), but even for 1000 MBit all you need are a few diodes to inject the DC into the data line.
But if you need /real/ PoE compatibility, that means a large clumpy module to handle the DC-DC conversion, and the negotiation protocol between the switch and the device to agree on voltages, current limits, etc. You also have to handle at least two standards, "mode A" and "mode B", for which lines will carry the power - and make sure your switch and your device agree. And then ever PoE switch manufacturer has a dozen variations, extensions and pseudo-standards of their own.
PoE could have been so cheap and simple that we would use it everywhere. Instead, it is far too complicated and expensive for the majority of uses.
That's a pretty bad idea, IMO. I'd only spec power-over-a-comm-connection if it's fully standard and very COTS.
I somehow did not find this that onerous, but we were not powering the target with PoE, just auxiliary equipment - switches and radios. This used Alt-A cabling.
We didn't use it in the end because we could/would not come up with the appropriate voltages. But in basic test, It Just Ran ( over RJ45 connectors ).
-- Les Cargill
It is, but in the end something has to aggregate all that. Once you get to 30-40 end nodes, it gets messy. And people's CAN implementations use a variety of endianness and representation of values.
Yep.
This turns out not to be a problem so long as you can maintain at least
10MBit. @ 100 MBit life is pretty good.
I find that latency and jitter aren't quite the worst thing in the world. And the critical detail is that bandwidth reduces those.
Many CAN nodes use a 10msec poll rate; well, just about anything with a Linux scale O/S and a select() loop will be well ahead of
10 msec in latency. In one case, I didn't even have to spend much time turning services off to get that.Yep. Better bit rate, though. I find in controls people a lack of understanding that bandwidth helps.
-- Les Cargill
It is indeed. It's a configuration management nightmare.
Heh.
I would agree.
Mmmmmm.... okay. I would gently disagree. Compared to some older full-function CAN controllers* the micro solutions are pretty bare. They're fine if your node fanout is small enough.
*the sort where a "send" operation takes one write to start, so you can put that on a low-latency timer loop, with the contents assembled in a more relaxed manner.Absolutely.
I could not agree more.
Not a big fan of MODBUS over TCP. It's okay.
I find that really basic ASCII protocols over UDP or TCP work just fine. At about 100 individual elements/registers, it starts to show real advantages over MODBUS.
My measurements of trying to go directly to Ethernet instead of using UDP or TCP don't support that choice.
-- Les Cargill
Run Modbus RTU or Modbus/TCP frames in UDP frames.
The raw Ethernet or UDP is nearly as efficient, Of course, you would have to implement the ARP protocol, but this helps configuration somewhat.
No need to implement the TCP stack.
Of course if you insist of using ASCII, there is also Modbus ASCII, the frame fits nicely into an Ethernet or UDP frame :-)
Some old Siemens Ethernet protocols used raw MAC addresses and there were always problems getting it to work in a real world environment with multiple vendors.
UDP+ARP simplifies life.
The two standards bit does get a bit silly, but the problem with standardizing power distribution is that you immediately run into the question of how much power is available to the device. If you have a bus-like configuration, it gets worse because you now have to deal with unknown numbers of devices drawing unknown amounts of power. A good chunk of the power related complexity in USB and PoE is the management of that.
Now you could leave it strictly up to whoever's plugging things together, and require something like a "ringer equivalence number*" to be printed on each device, then the integrator just needs to total up the "RENs" and compare that to the REN output of the bus-hosting device. OTOH, that certainly would not be acceptable for any consumer(-ish) device today.
*And for those of you too young** to know what a REN is... Old POTS telephones used a higher voltage/current signal to drive the mechanical ringer than was used to drive the speaker and microphone circuits. Basically in "talk" mode, there was just not enough current on the line to move the mechanical ringer. Obviously if you had multiple phones, you needed more current to make them all ring at once. So a standard was established that a Bell 500 phone had a REN of 1.0, and a standard phone line would drive a load of 5.0 REN. So you could have five phones with "standard" load ringers on a line and have them ring reliably. A few phones had higher RENs, and many modern electronic phones have much lower RENs, but the idea was that the total of the RENs for all the phones on the line has to be no more than 5.0. REN boosters were available (actually still are) for situations where you needed more oomph. Sometimes called RAL outside the US. **And... Damn kids, get off my lawn!
It is not about the cable being round, it is about the cabling length. With a coaxial cable it can be nodes_count times shorter, just a single cable running through all the nodes. And no switch necessary.
Then the 70V is somewhat too high, one cannot just use a trivial stepdown convertor as with say 12V for smallish things. I had designed PoE in our netMCA as an option on the board, well, was never used. Nobody had any thoughts on having a wall adapter, in fact need for a PoE capable router would have been more of a barrier in user perception.
Which is what it is of course. But this does not mean devices will not be connected over the net, our netMCA is one of those "things" quite some years before they coined the phrase. It will take just some more RAM on the MCUs, a few MB, and tcp/ip stacks will be practical even at higher speeds/transfer rates.
Dimiter
------------------------------------------------------ Dimiter Popoff, TGI
------------------------------------------------------
The 10Base5 with vampire taps and RG-8 like coaxial cable was nice, why not implement your own PoE ? The RG-8/213 like coaxial cable can withstand several hundred volts and several amps :-)
The nice thing about Ethernet is that it requires galvanic isolation between nodes. Using some simple non-isolated stepdown converters from
12 V would ruin the isolation on the network. 70 V pretty much forces using proper isolated converter.
I would if I felt I had the muscle to enforce a standard :). It does not have to be 10base5, 10base2 (not sure, the 5mm coax cable thing) is plenty I think. I am not thinking hundreds of meters, rather a few meters to may be tens of meters. Then may be today we can do somewhat more than 10 Mbps over the coax cable, say 50 would be very nice. Using a
Obviously I agree with this. May be just 70V, isolated, would be much better. It is no rocket science to step that down in an isolated way nowadays.
It will take a while until we see MCU-s with an on chip PHY similar to the DP8392...
Dimiter
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.