Complexity of USB stack vs. TCP/IP stack

[richardman]

What are people's thoughts on the complexity of writing a USB stack vs. TCP/IP stack? For USB, let's say the basic HID and CDC class are supported, and the TCP/IP is a full stack more heavy weight than uIP or LWiP. Layered implementations on top of a message passing OS.

[chickenHeadKnob]

Not sure what you are trying to compare is easily comparable. The main reason is that the traditional way to a full tcp/ip stack is to start from the BSD stack, and to use its structure and state machine. That starting point  for TCP/IP changes the design flow compared to usb where I don't think there exists such a universally accepted driver-exemplar.

[nctnico]

I think a USB stack is easier (but you might just as well fork LUFA). If you think about networking then you immediately enter the world of security and hacking. This would require some way to test a TCP/IP stack for buffer overflows, possible attack scenarios. Also you are likely to want to offer basic protocols like ARP, HTTP, DNS, DHCP, SMTP and each have their specific problem areas where it comes interoperability. Also a BSD style socket interface is easy to interface with.

Anyway, for one of my upcoming projects I'm planning on using a Wiznet chip partly because the whole network stuff will be outside my primary processing core.

[Howardlong]

In short, I'd do neither, each is pretty much a life's work before you've even blinked so much as an LED. Leverage someone else's blood, sweat and tears.

Even if you get as far as getting something to "work", how well does it interoperate with other parts of the network, whether USB or Eth etc.?

[Philfreeze]

In short, I'd do neither, each is pretty much a life's work before you've even blinked so much as an LED. Leverage someone else's blood, sweat and tears.

Even if you get as far as getting something to "work", how well does it interoperate with other parts of the network, whether USB or Eth etc.?

I don't know about the TCP/IP stack but I assume it is actually really hard but the USB stack is quite easy to implement.
It is just a bus with a bit more complex protocol but as long as you have some USB enabled hardware and you don't have to bit-bang it is quite easy.

As a project I implemented the USB stack (HID only) on a PIC MCU and it took me about a month (around 15-20 days) with testing but I wouldn't exactly say it is an exiting thing to do. It is fine if you want to learn how USB works (this is why I did it) but it really isn't an interesting project. You will just go through the USB protocol specifications and implement all the bit fields, structs, interrupts, timeouts etc. exactly as they are described in the pdf.

[Engineer_EE_FW_SW]

Edit: Now I understand your position based on your update.
Just try to port LWIP or some appropriately designed stack to your platform, if the OS works already and you have network drivers / APIs, it shouldn't be that hard.

USB device class implementations for HID or CDC are almost always 'low level, get it done' code.  They're often intended for high volume consumer electronics where spending money on an extra few kBytes of RAM/FLASH is a big deal to major MCU customers.  USB device class support for HID / CDC is like I2C or SPI or UART in that way -- everyone wants it to work, but nobody wants it to cost much in memory or other costly resources, so implementations aren't so much cross platform portable, layered, and elegant rather they're basic and functional and tend to be obscure and platform specific.

Also mostly no MCU vendor wants their own developed USB device class code to end up being ported and used on someone else's MCU family so cross platform portability isn't a concern except for 3rd party stack / OS vendors that offer solutions for different platforms.

[kolbep]

Just stick an ESP8266 Wifi Module on the board.
Then just a few AT Commands and you can read and write to the net, and even have it act as a server...

[ataradov]

USB is easier, just because you don't need to manage tables, expire records and maintain all sorts of timers.

[Howardlong]

In short, I'd do neither, each is pretty much a life's work before you've even blinked so much as an LED. Leverage someone else's blood, sweat and tears.

Even if you get as far as getting something to "work", how well does it interoperate with other parts of the network, whether USB or Eth etc.?

I don't know about the TCP/IP stack but I assume it is actually really hard but the USB stack is quite easy to implement.
It is just a bus with a bit more complex protocol but as long as you have some USB enabled hardware and you don't have to bit-bang it is quite easy.

As a project I implemented the USB stack (HID only) on a PIC MCU and it took me about a month (around 15-20 days) with testing but I wouldn't exactly say it is an exiting thing to do. It is fine if you want to learn how USB works (this is why I did it) but it really isn't an interesting project. You will just go through the USB protocol specifications and implement all the bit fields, structs, interrupts, timeouts etc. exactly as they are described in the pdf.

Did you hack at the register level or use existing bits of the stack? Plus getting it ratified/certified as kosher isn't trivial.

Either way, I agree, I have better things to do with my life!

Edit: although I highly admire your tenacity, of course.

[richardman]

Sorry, I should have given more context.

The context is now that we have the OS running, we are writing the stacks to go with our tools to sell to customers.  (By writing, I meant also potentially leveraging open source code, of course we will abide the licensing terms of whatever code we leverage, if any)

They will also go into hardware boards that we are making/selling as well.

Since we are flexible in the order of releases, just gauging which one we should tackle first. One nice thing about TCP/IP is that there are many example implementations and design notes available. Easier to see which features we should implement and why.

The USB stacks situation seems to be less "evolved". Not a whole lot of examples of layered stacks with ease of adding new device classes. most feel like simple "get it done" jobs. I could be wrong of course.

[ataradov]

In that case go with TCP, there is way more readily available stuff and porting existing stacks to new hardware is typically trivial.

[nctnico]

The USB stacks situation seems to be less "evolved". Not a whole lot of examples of layered stacks with ease of adding new device classes. most feel like simple "get it done" jobs. I could be wrong of course.

Did you look at LUFA / a.k.a. the USB host/device/OTG stack NXP offers with their controllers? I have used it in a few projects and even though the documentation is lacking (as usual) it seems like a well organised stack with a clear hardware interface and user interface. I don't think it will be difficult to port it to other architectures.

[richardman]

Did you look at LUFA / a.k.a. the USB host/device/OTG stack NXP offers with their controllers? I have used it in a few projects and even though the documentation is lacking (as usual) it seems like a well organised stack with a clear hardware interface and user interface. I don't think it will be difficult to port it to other architectures.

Yes, indeed, I am in communication with LUFA's author, Dean, on the subject. Leveraging LUFA is definitely a possibility.

[C]

which TCP/IP stack?

If you are creating a new OS these days leaving out v6 would not be a great idea.

[westfw]

A TCP/IP stack is very symetric, very general, and has few "critical" timing requirements.  It's pretty huge and has complications (like security.0
a "USB stack" is NOT symetric at all; it has a device side that is not too hard to implement, and a host side that pretty mind-boggling in the things its expected to perform.  usb hub management, for example.  Keeping track of all 256 (?) nodes that might be connected, and how to poll all of them adequately despite the many operating modes.
A USB device is much easier to write code for than a TCP device, and much of the hard work is done by hardware.
a USB host and a TCP host are probably "close", except the TCP host can cheat and implement a nice slow network interface that avoids inpunging on some of the issues that make USB host complex.

[nctnico]

You don't have to implement handling USB hubs in a USB host stack. After all a USB hub is nothing more than a device which multiplexes USB messages. OTOH it should be doable to implement it IF the USB stack has the ability to handle multiple interfaces. IIRC LUFA can deal with multiple host interfaces or is simple to modify so it could be a good starting point.

[LeonV]

I have written both before as a proof of concept, from scratch, in PICASM. It was fun. But i would not recommend it.

The USB client stack was a lot easier to get going than TCP/IP, but only because with TCP you need to implement things like ARP and DHCP.

I have looked into making a USB host on a PIC before, but i wasn't going to go there. IP is easier than making a USB host in that way.


But that is from a programming from scratch stand point, you will be using libraries.

If it was a product, i would implement TCP/IP.

Don't forget about security as well, There are a lot of devices that find their way onto the internet over time and are simply not secure.

Slapping an ESP8266 on things is such a simple solution, But i always hated WiFi in products, It always fails. Too susceptible to environmental factors. So so easy though!

And like  C said, IPv6 will become the norm before long, so its essential for consumer products.

[nctnico]

And like  C said, IPv6 will become the norm before long, so its essential for consumer products.

They have been saying that for over a decade now but I don't see it happen. The whole idea behind IPv6 is that every device gets it's own unique IP address on the internet. From a security perspective that is a nightmare so that is exactly what you don't want for any device and kind off eliminates the necessity of IPv6. If you look at the IP address of your phone or tablet you'll see it has an IPv4 address in a private range. The providers use NAT routers to allow internet access for the devices but hide them from the big bad outside world. It makes the life of an IoT device a whole lot simpler if it doesn't have to deal with flooding attacks, random messages, etc.

[richardman]

Thanks for all the great discussions and information.

Just an update: I am building LWiP currently. Starting with the latest 2.0 BETA. Most of the code builds now using our compiler. I hope to be able to test the simple functions on the 746 ST-Nucleo some time next week.

Then my idea is to port it to work with message passing protocols, may be dividing the layers into different servers, i.e. IP protocol server, UDP server, TCP server etc., and then add zero-copy buffering so to avoid buffer copying across the layers. The RTOS is preemptive round robin priority with interrupt able to wake up "hibernating" tasks. So in theory, a packet comes in from the ethernet interface would wake up the IP protocol server and so on.

Will see how things work out.

[C]

And like  C said, IPv6 will become the norm before long, so its essential for consumer products.

They have been saying that for over a decade now but I don't see it happen. The whole idea behind IPv6 is that every device gets it's own unique IP address on the internet. From a security perspective that is a nightmare so that is exactly what you don't want for any device and kind off eliminates the necessity of IPv6. If you look at the IP address of your phone or tablet you'll see it has an IPv4 address in a private range. The providers use NAT routers to allow internet access for the devices but hide them from the big bad outside world. It makes the life of an IoT device a whole lot simpler if it doesn't have to deal with flooding attacks, random messages, etc.

I would suggest you study up some on NAT

I would say that what you state as security is more a security fail.

You have X devices on internal network of which one or more uses a port to talk to INTERNET.
You had X times 2^16 possible ports.
NAT Reduces X to 1 in most cases.
The array of data that NAT needs to function requires two variables, one 2^32 and one 2^16 with and a port index of 2^16.
With NAT software able to pick the port this array can be reduced in size

A device talking to INTERNET adds entries to this array.

Your large number of possible source ports just became a small range active ports. 

In most cases an active NAT port will accept packets from any address & port from INTERNET side to this active port and forward it to the device.
Some software makes use of this.

You have device security as long as that device does not talk to the INTERNET for anything.
NAT does not prevent a device from talking, that is the firewalls job.

Even this simple NAT described breaks some IP protocols. Trying to improve security via NAT can break more IP protocols with little gain.

There are other versions of NAT that change some things, but the basics is more active ports in a smaller range and this smaller range makes it easer for the outside attacks.

[timb]

And like  C said, IPv6 will become the norm before long, so its essential for consumer products.

They have been saying that for over a decade now but I don't see it happen. The whole idea behind IPv6 is that every device gets it's own unique IP address on the internet. From a security perspective that is a nightmare so that is exactly what you don't want for any device and kind off eliminates the necessity of IPv6. If you look at the IP address of your phone or tablet you'll see it has an IPv4 address in a private range. The providers use NAT routers to allow internet access for the devices but hide them from the big bad outside world. It makes the life of an IoT device a whole lot simpler if it doesn't have to deal with flooding attacks, random messages, etc.

And it has been slowly rolling out. You could be browsing the web via IPv6 right now and not even know it! Most major data centers around the world are providing IPv6 blocks now, which means most websites are IPv6 ready now.

Over the last 5 years, cell phone carriers have started rolling out IPv6 and, as a result, pretty much every cell phone (here in the US at least) gets an IPv6 address now. (In fact, most cell providers are using NAT for IPv4, because they have nowhere near enough addresses.)

Most home internet connections (DSL and Cable, in North America at least) can also provide an IPv6 address. Though, availability depends largely on your how you have your router configured, the capitulates of your modem and your provider. For example, some providers are still doing 6over4 tunneling, which is atrocious, but at least it allows you to connect to the IPv6 internet with no configuration on your end.

The problem with IPv4 is we ran out of useable address space years ago, and it's getting worse and worse every day. Does every IoT device *need* a public IP address? Well, no, but it's not even about that. Do you think that your *entire household* should have at least *one* public address? Of course, right? But that might not even be the case anymore! ISPs have had to resort to assigning private IPs instead of public ones, using NAT. So essentially you've got groups of a hundred customers sharing the same public IP.

On the surface, that doesn't sound so bad, until you realize that this puts you into a "double NAT" situation: Public IP X.X.X.X > ISP NAT IP 160.x.x.x > LAN NAT IP 192.168.x.x

That makes it very hard for applications that need direct incoming port access to traverse. (Think video conferencing, gaming, etc.)

Anyway, you might be surprised that you're already using IPv6, and don't even know it. I know I was last year!

[nctnico]

Video conferencing and gaming work without needing a fixed IP address. They solved that problem years (>decade) ago because you simply can't rely on people having a fixed IP address. Even IF people have some sort of fixed IP address it can change when they reset their modem or change providers. The only things on internet which need a fixed IP address are servers.

[gmb42]

Video conferencing and gaming work without needing a fixed IP address. They solved that problem years (>decade) ago because you simply can't rely on people having a fixed IP address. Even IF people have some sort of fixed IP address it can change when they reset their modem or change providers. The only things on internet which need a fixed IP address are servers.

You really need to update yourself on IPv6 and not just repeat the NAT mantra.  See RFC 4941 for how devices that don't need a static IP can automatically change it.

My Windows client systems (and the odd Linux VM) have been doing this for the 4 years I've had an IPv6 connection without an issue.  I have a whole /64 block for them to choose from (2^64 addresses), thats 2^32 bigger than the entire IPv4 address space!

[timb]

Video conferencing and gaming work without needing a fixed IP address. They solved that problem years (>decade) ago because you simply can't rely on people having a fixed IP address. Even IF people have some sort of fixed IP address it can change when they reset their modem or change providers. The only things on internet which need a fixed IP address are servers.

Well, no, not exactly... First off, are you talking about private IPs (the ones used inside your LAN, like 192.168 and 10.0)? Or public IPs (the one that *should* be globally routable and unique to you).

If you're talking about public IPs, I never said you needed a static IP address. Dynamic works just fine. (Also, no, a fixed (static) IP will never change, even when they reset their modem. That's the entire point! A dynamic IP can change when you reset your modem, or even when the DHCP lease expires.)

The issue I raised has nothing to do with that. The issue is about TCP/UDP ports, and how to correctly route them when you have more than one device using a single public IP. This was solved about a decade ago, with things like NAT-PMP (Network Address Traversal-Port Mapping Protocol) and UPnP (Universal Plug and Play).

First off, what is NAT? Network Address Translation allows multiple devices on a private network, with private IP addresses, to share a *single* public facing IP address (which can be static or dynamic). It works really well when a device on the private side requests something from the public side (browsing a website, for example). NAT keeps track of where the request came from, so it knows which computer on the private side to send the data to when the server responds.

So far so good, right? But what happens when, say, I try to make a direct connection to your public IP, without you requesting anything first? (Say, a BitTorrent client on my LAN trying to connect across the Internet to a BT client running on a machine in your LAN.) Well, it doesn't work! Unless you've gone into your router and manually setup port forwarding, to forward that specific BT port the the private IP of the machine running the client.

That's a huge pain to have to do for every game, P2P client, video chat client, etc.

So, how do we solve that problem? Well, that's what NAT-PMP and UPnP do! They allow any device in your private network to automatically setup temporary port forwarding by just making the appropriate request with your router.

So, that's why we don't have to worry about all this port forwarding stuff anymore. (And why most games and video conferencing clients have "just worked" for the last 10+ years.

So, what was I talking about in my last post? Well, NAT was only designed for private networks (aka your LAN). And NAT is certainly not designed to work behind *another* NAT.

The problem is, since we've run out of IPv4 addresses, ISPs can't get new pools of IPs to assign to their users (remember, each user should have at least *one* public facing IP address, be it statically or dynamically assigned). So, what some ISPs are doing is taking a single public IP and, using NAT, sharing it with 10 to 100 customers. (In that case, the IP assigned to your modem/router is actually a private IP inside their LAN.)

Now, why is that a problem? Well, let's use the BitTorrent example from earlier. So, your BT client uses NAT-PMP to request a specific port be forwarded from your router, which it does. The problem is, your router doesn't have a publicly accessible IP, because you're behind a second level of NAT from your ISP's router, and your BT client can't make a NAT-PMP request to that, therefor the port ultimately can't be forwarded from a public facing IP to your device.

This is called "double NAT" and it's bad. The only way around this is with IPv6, which would allow each device on your LAN to have its own public IP address, allowing us to do away with NAT and port forwarding all together.

Which, by the way, is not at all "insecure" as you suggested. Why? Because the gateway to these devices will still be your own router, which should have a firewall enabled. (Remember, firewalls are for security, NAT isn't.)

[mac.6]

Based on my work experience, USB stack complexity is not in the software, but in the myriad of exceptions and bugs due to the myraid of bogus/pelicular devices/hosts that are in the field.
On the other hand TCP/IP stack can be software beast but easier to test and with less device issues (except your network device).