SmartFusion2 SoC

It is still used very widely. Embedded web servers are fine for your SOHO router but you wouldn't want to configure thousands of them in that way.

What's supplanted it are things like XML and JSON. As the Internet protocol suite has moved from being a commons to being a showcase for this company or that company's pet project, it's become ... quieter.

I brought it up only to illustrate some design choices made in its development.

Yep. So we're back to duplicating over TCP what you have to do anyway for UDP.

Exactly.

Google offers a thing called QUIC that supposedly addresses this.

Right, stuff tends to have XML or JSON API's now. Think of OpenStack etc.

You may or may not have the opportunity ( and it's old and busted ) , but I recommend understanding SNMP at a fairly deep level because all the issues with transactions at a distance are included in it.

Because when you provision a node, it's transactions as-if you were posting to a general ledger. It's all one thing.

For example, if you post XML to a node to configure it, what happens when *one* element is out of sorts? You should roll back the entire thing as if it never happened.

It's funny, but a lot of the instabilities I've run into on projects were exactly this issue. I'd done work related to financial transactions for a short stint before that.

Every time I have to reboot my home router because the firmware people didn't understand this, I grind my teeth a little :)

No, it is not /all/ behind you - just most of it. ARP caches are regularly refreshed, with re-checks of the IP to MAC pairings. And unless you are alone on the network, and you have no other connections or traffic from the nodes you control, there is always other packets and broadcasts going on. Small embedded systems don't usually produce much chatter, but if you've got PC's there, the noise they make adds up.

All I am saying is that there /is/ non-deterministic delays on the network, even with UDP. It is lower than with TCP/IP, and you can take steps to greatly reduce it - but don't make the mistake of suggesting that you can put two nodes on a network and get real-time-ish behaviour as long as you use UDP. On most networks, the difference in throughput, latency, and maximum timing jitter (the key metric for "real time") is negligible between UDP and TCP/IP.

It is not /that/ hard. An Ethernet packet is not harder to make or use than any other sort of communication packet - you've got a header, a source and destination MAC address, your payload, and a CRC (usually filled in by the lower layers, or even the Ethernet MAC hardware). You can send and receive them on most systems.

Raw Ethernet packets might not be a good choice for many applications, but there is no doubt that they give you the lowest overhead and most predictable behaviour on an Ethernet link. It is used, for example, for ATA over Ethernet to get the minimal latency and maximal throughput for disk access.

In general. That's why it's less of a concern for embedded systems. I at least hope that actual deployment configurations are controlled so it should be relatively simple to measure this and control that as well.

Even then, it doesn't add up to much, and if you have a true learning bridge it will be minimal. Of course there are actual broadcast messages from Windows, but you might be able to turn those off.

It's also worth understanding the O/S on the PeeCees enough to keep this to a minimum.

Of course!

Agreed. But it's also true that an awful lot in life works fine win the 10 msec cycle range. For displays, this may be as slow as 500 msec.

For most cases, yes. Indeed, they're nearly identical except for a handful of pathological cases.

In general, the world doesn't want you doing that.

The deployment configuration for embedded systems vary enormously. Some have careful, controlled environments - others get mixed with everything else on a network. In many cases you might /think/ the customer will be careful in their network setup, but despite all your specifications and documentation, they just plug everything together and assume it will work. Remember, the customer is always right - even when they are wrong!

There are always more broadcasts than you would expect. And whenever you have a PC, there is (almost) always someone who installs more software without due consideration.

Often these broadcasts and other traffic are not a problem. But when you use the magic phrase "real-time", even if it is "real-time-ish", you have to think worst-case.

Agreed.

Ethernet networks of various sorts are often perfectly good for control systems, whether you use UDP, TCP/IP, raw Ethernet packets, or anything else. All I am saying is that one must be careful about trying to specify or guarantee some sort of real-time behaviour - using UDP is not sufficient, and rarely makes a big difference.

I'm not paranoid - I /know/ the whole world is against me...

Yes, there are complications in using raw Ethernet, such as requiring extra libraries on Windows or root privileges in Linux, to say nothing of having to battle network administrators! But on a closed network, they are not hard to use.

That is a big problem for whoever is deploying them, then.

No, the customer is not always right. A customer who can't identify and act in their own self-interest isn't a customer any more, they're a problem.

It think you'll find the world to be moving more that way.

Again - if you do not control configurations, you will suffer. That is only my problem to the extent I can bill you to straighten it out or otherwise unsnarl it if I have more of a retainer relationship.

Yeah, it's a slippery word. But we live in an era where the fastest bus is cheap and plentiful, and where a node is is less of an issue than it's ever been.

So I at least manage that with instrumentation in the networking code. I at very least keep counters and may provide some sort of log to document such failures.

I do that for my *OWN* testing. Sometimes it gets turned off for deployment, sometimes it doesn't.

You may have to use ... inappropriate privilege levels, you'll have more liability from one-off code for different platforms, you run the risk of becoming tied to this network box or that network box...

But if you have a ring of PIC32 and that's all it'll ever be, it's fine. Just remember that UDP is the next move up the stack, and the overhead isn't that much.

Right.

No, that depends entirely on the embedded system in question. For some systems, there should be tight control. But some embedded systems are /supposed/ to be installed anywhere. If you are making an IoT device, as is the current fad, then you have to cope with any sort of network setup and network traffic that the customer has. When you make your internet-connected fridge that talks to an internet-connected freezer and automatically orders milk and ice-cream every second day, then you don't get to dictate what the customer connects to their network.

Of course, such a system is far from real-time. I'll leave it to your imagination to think of something that might have critical timing, and might also legitimately have mixes of network equipment.

My statement was (I thought) obviously a little tongue-in-cheek. But there is some truth in the matter too.

If you make a system with several cards that communicate over Ethernet, perhaps controlled by a PC, and it has trouble when the customer connects something else to the network - then /you/ have a problem. Even if you have clearly specified that nothing else shall be connected, if the customer has problems due to an unreasonable (in his eyes) restriction, then /you/ are seen as being inflexible and awkward. A supplier who points to the wording in the contract and refuses to help here is unlikely to get sued - but also unlikely to get repeat custom.

I think it is moving the other way.

I have worked in embedded systems design for over twenty years, and I have yet to find a customer who had a /complete/ specification at the outset of the project, and who did not want to change at least a little part of it along the way, or after the development was complete.

Of course sometimes the job of the supplier is to tell the customer when he is wrong - but you try to help out in the best way possible. (Billing the customer as appropriate, of course.)