On Thu, Sep 06, 2001 at 09:52:41AM -0400, Olin Lathrop wrote: > > Everytime I hear you say TCP/IP I get the impression that you're talking > > about a physical interface. Is that the case. > > Actually my main issue is with the considerably higher firmware complexity > required to implement TCP/IP versus some private protocol that is explicitly > intended to be easy. I may agree with TCP, which is what I've been arguing from the beginning of the thread. However UDP and IP's complexity are several orders of magnitude lower. Here is the IP header, shamelessly borrowed from RFC 791: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example Internet Datagram Header The version, IHL (header length), Type, Time to Live, Protocol, flags, Fragment offset and source addresses are all fixed. The ID field is a simple 16 bit counter. The checksum is the 1's complement of the sum of the packet. Options are of course optional. Now on to UDP: 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... There is not an obligation to compute the checksum for UDP. It can be sent as a zero field. Same for the source port. So to send a datagram All that must be set is the Destination IP and port, the length in the IP and UDP header, increment the IP ID field, and the IP checksum computed. So unless you are using a packet format with no address, no checksum, and no length information, I cannot see the "considerably higher" firmware complexity you allude to above. > > > My firmware costs will be higher. > > ... > > But my bridge will be trivial. > > Exactly. I see this as backwards. I would rather have the one be complex > and the many be simple. But I really think that it's worth the investment because the payoff is so huge. > > > It would be more software development. I don't deny that. > > I'm not as concerned about development as the minimum requirements placed on > the tiny units. With TCP/IP, many of the small micros are just not big > enough for the job, but just about any of them could support a RS-485 > network with a dumb protocol, or talk to a CAN chip. After doing the analysis above I'm positive that UDP/IP packets can be pushed from a 12C508. The headers have at maximum 18 bytes of dynamic overhead and that's if the source and destination IP addresses and ports are all configurable. With a fixed source IP, destination port, ID field, and computing the length in place, that overhead is reduced to 8 bytes (4 for the dynamic destination IP, 2 for the length and two for the checksum). The only limitation is the data. And you'd with a 4 byte window of the same limitation with any other protocol. So it's a wash. > > > But I can then take > > that same stack and reuse it in each and every networking project AAAA now > > to eternity. > > That logic can be applied in either case. There's a whole world of > networking out there that isn't TCP/IP. I did a RS-485 network for a > customer a few years ago (16C77) and have re-used the basic concept and much > of the code for two other projects since then. CAN would have been perfect > for the original network, but chips weren't readily available then. But you cannot connect those devices directly to a TCP/IP network without a gateway. It's apparent that you do not see the value add of that. Personally knowing that the far end of a network connection can be both remote and completely tested with a bunch a well known, debugged software, is a value that just cannot be overstated enough. The world is fast becoming a place where a computing devices that isn't internet connected is a useless computing device. And I strongly feel that duplicating networking effort is a waste of valuable resources. I really don't buy the "protocol is too heavyweight to run on small hardware" argument. Up to 70 percent of the header can be hardcoded with no loss of functionality. > > > And BTW: you'd end up building a minimal IP/UDP stack for your bridge > anyway. > > And a second stack for CAN. > > No, it's not just a bridge. The protocol or data doesn't just get > translated from TCP to CAN. This unit actually runs the TCP server. It > receives and interprets requests, some of which it may complete on its own, > and some of which may require communicating with one or more of the tiny > devices. Think of them more as I/O devices connected to the central unit. > I don't envision anything as complicated on the tiny units as what would > traditionally be called a "protocol stack". It's going to be a protocol stack no matter how you slice it. You will have a hardware device driver to communicate with the hardware, you will have a data link protocol that describes the format of the data on the line, you will have some type of addressing scheme to differentiate on node from another, and you will have some application specific data embedded in your packets. Unless the protocol is point to point, you're stuck with these elements. TCP/IP adds two additional layers: IP which expands addressing so that it's routable, and UDP so that in theory multiple applications ports can be addresses. But with the small concession of a single application port, the entire UDP header can be hardcoded out of existence. And the point I'll keep pounding is that by speaking UDP/IP it makes you device just like every other device on the net. And without the need on intervening hardware. Your model cannot run without a server. There's no possibility of a standalone configuration. Plus you have to implement two incompatible protocols. You cannot leverage the tons of tools, software, and expertise that already exists. > > > Questions: How much hardware/memory do you think it costs to implement > IP/UDP > > transmit and receive? How much for CAN? I'm just trying to differentiate > the > > "substantial controller" that you quote above. > > I don't know about UDP, but there is a company in England somewhere that is > trying to sell TCP/IP and related software for 18 series PICs. I asked them > what their software required if I wanted the PIC to present a single server > at a single IP address. My software would implement the server, but theirs > would provide something equivalent to the Berkeley calls you would need to > do a TCP/IP server. I also said their software would have to respond to > PING itself without bothering or notifying the application. The answer was > over 5K instructions, and part of their code needed to be called from a > regular interrupt. The phonedroid didn't understand what call stack > locations were, so he couldn't tell me how many they used up. Ouch! Now I see why you are banging away at the complexity of the stack. The last time my students were working on this project, they had implemented a PING/SLIP stack with a hardcoded ping packet. They started with Fr. Tom's UART code (and outstanding piece of work!) and coded a jump table to get and transmit the bytes. It all comes in under 256 bytes and it pinged just fine. So I'm finding 5k hard to swallow. BTW I'm writing this as much as a design document to myself as a response to you. Since it'll be archived, when I get around to actually building these things I'll already have my thoughts in a semi-coherent form. If we limit ourselves to serial hardware in the beginning then the only protocols we must support are UDP, IP, and ping. For simplicy I'll use SLIP as the data link. Transmit: Much of the headers are hard coded. Implement the header as a jump table. For the dynamic elements use a goto instead of the retlw. The goto goes to code that pulls the appropriate dynamic value from RAM and transfers into W. The application will have to fill the dynamic values (length, destination IP, pointer to data) then call. SLIP byte stuffing will be done after the jump table value is obtained. The pointer to the data is stuffed into FSR and a FSR/INDF loop is used to transmit. Can be interrupt driven but then will require a flag to inform the application when another packet can be transmitted. Receiver: Probably start out syncronous so that the application has to request a packet. May rethink later. Biggest design decision is to invest temp ram in receiving the header or coming up with a clever scheme where only the dynamic elements are stored. Something along the lines of a bit table with a double jump table, the first gets the byte position of the next received character, the second picks the bit out of the position byte. So it would only take 4 bytes of table to represent the keep/throw away status of the bytes of the header. In either case the kept data is stored sequentially in a buffer which is returned to the app when received. Normal SLIP END/ESC translation is done upon receipt. I would gag if this were more than 512 bytes of code and 28 bytes of header RAM. The data packet size of course will be constrained by the amount of RAM available on the target. > > The RS-485 protocol layer in the 16C77 I mentioned earlier takes a small > fraction of that. CAN is even simpler. The hardware does all the ACK/NACK, > error control, and interpreting the bit stream as packets. But that's orthogonal to any network/transport layers. As I said before I'd be perfectly happy to run UDP/IP on top of CAN. I could of course say exactly the same thing about ethernet in terms of packes and error control. > It can then also > filter the address in the packet so that the firmware only gets bothered > about packets that it needs to deal with. That can be done with 9 bit serial and ethernet. Those are all data link issues that sits below the IP and UDP payers. And IP/UDP packets can be delivered over each and every one of them. > CAN was specifically designed for > lightweight nodes on an inexpensive local network. The original purpose was > to reduce the cost of wiring in automobiles. For example, it's cheaper to > run power and CAN all around the car with a little silicon at each node than > to run separate wires to each thing being controlled. In other words, the > point behind CAN is that the transistors at the a rear blinker are cheaper > than the copper power wire to it. TCP would be ***WAY*** overkill for this. > Fortunately, a lot of little local control applications can benefit from the > large volumes of the automobile market. But it's apples and gorillas for the discussion we're having. Personally I can care less about the data link and physical media. The only argument I've made is that your get ubiquity by delivering UDP/IP/ICMP packets to the target. You're focus is how nodes are connected. Mine is the data that delivered to the nodes via the interface. And I believe that the firmware complexity for a UDP/IP/ICMP stack is several orders of magnitude less than you think it is. BAJ -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.