 I'm going to talk about low-level Ethernet, by which I mean Ethernet is close to the silicon or the metal if you prefer, thinking about what's actually going on. I'll start off there just to try and be controversial. Just to remind you, Ethernet is not IP and IP is not Ethernet. The internet often gets transmitted over bits of Ethernet, but Ethernet can do things without IP and obviously Ethernet can do things without Ethernet, so people forget that too often, so I should just make the point. Ethernet is a combination of physical and protocol standards, and unless I've totally misremembered, I think it was invented by a bizarre mixture of Intel and Xerox when Xerox actually mattered, which unfortunately it don't anymore. But I'm not going to talk about that kind of Ethernet because it's moved on and it doesn't cost £2,000 for a board anymore, but it's got quite cheap. I've already said some of this, so I'll skip on. Ethernet can go over all sorts of different physical layers, but I'm only interested in the little RJ45 connectors and wire with four twisted pairs, but I'm really only interested in what's called 100 base T, or probably 100 base T4, and the point about that is it's 100 mega bits per second, so it's quite fast. It's also just sometimes called fast Ethernet, but it's really ought to be called 100 base T. I'm talking about using Ethernet with little microcontrollers. In my book, a little microcontroller is up to a sort of Cortex N4, maybe a couple of hundred megahertz, but definitely not system-on-a-chip kind of processors. Perhaps the first question is why would you bother? There are lots of ways little micros can talk to each other. They can talk through simple sort of UART and kind of interfaces, or parallel, or whatever you like. People often talk about using things like RS485 or CAN, but the great thing about Ethernet and the first thing that's important is it's so fast. None of those other technologies can do wire at 100 mega bits a second, and that's really quite fast, and you can do a lot of interesting things that you just can't do with RS485, and it has other advantages too. It's cheap. Ethernet's sort of crept up, and it's become really quite cheap to implement, so the cost of putting Ethernet on a little micro is really very, very low, and you get all that speed for not much money. It's also really got quite simple. There are lots of micros now with the sort of hardware you need. You can get all the bits easily. Connectors are cheap, the wires are cheap. It's all easy to do, and it's very reliable. Ethernet is much more interference resistant and other electrical problems resistant than things like RS485 because the standard is connected to the little transformers, the frequencies involved them, on the wire are relatively low for the 100 mega bits, so it's a really good system. It's beautifully thought out and a lot of work has gone into making it reliable. So if you want to link two little micros or perhaps 100 little micros with Ethernet, what do you need? Every node has to have a Mac. I don't know how familiar people are with the terminology. Does anybody not know what a Mac is? OK. Well, when it rains, you can't need to go down. No, that was wrong. It's a media access controller. It's a bit of Ethernet jargon, but it's a bit of hardware usually. It doesn't absolutely have to be, but it's almost invariably hardware. It allows your micro to translate data, which is probably a stream of bytes into the sort of packets that are going to go out on the Ethernet on the wire. After the Mac, you need a PHY. That's the physical interface. So you have logic level signals coming out of the micro and they have to get out onto the wire. The chip that does that is called a PHY. You can get micros with the PHY in the same package. As far as I know, nobody makes a micro where it's actually on the same chip, but usually the PHY is a separate chip. Then to actually get from the PHY to the wire, you need a connector and the little transformers. It's much easier if you have the little transformers inside the connector. Then you actually need the wire and that's got to be the right wire, otherwise it doesn't work very well. If you use the right wire, which is still dead cheap, you can do sort of hops of 300 feet in theory. In practice, you often can as well, but you can 50 feet is no bother. I've not ever had any problems with wire that long. And you need some software and we'll talk about that later. So if you want to play, what do you have to do? Well, you can cheat and buy a board where someone sorted it all out for you already. There are two that look reasonable. I haven't actually used either of them. The Ti one is dead cheap. It's 15 quid. That is one of the few micros where the PHY is on chip. In package, it's not on chip, so it's no easier to use from a software point of view than a separate part. If you're going to buy a board, it doesn't much matter. It's an ARM Cortex processor. FreeScale have a board, which is also quite cheap. There are lots of other boards, but they're all more money. There are ways you can do it by putting shields on arduinos, but no question more on the performance will be awful, so probably not the best way to go. But my further best way to do it is to make your own board or design your own board. I'm going to talk mainly about doing that, but you don't have to make your own board. I'm going to talk about bits you might use. Obviously, it's not an exhaustive survey of all the bits that might work, but these are bits that do work. I used an STR processor. It's quite fast. That one will go at 180 megahertz, which is quick. It's got lots of RAM. It's got the Mac on board. Like all the ST Cortex processors, it's quite well documented, widely used, well supported. The brilliant feature is they make a whole range of them and they're all pin-compatible. You can go up and down the range, but they're all soldered in the same place, which is good. I've used a micro-fi. Other people make ffis to make them. The micro ones are easy to get, cheap. Fi's about £1.50. But they make some other interesting bits as well. One of those bits is just a fi, but the other one is a switch. Then you need the connector with magnetics. We'll talk a little bit about that on the next slide. You have to have a Mac ID. You probably all know you have IP addresses, but all things on Ethernet have to have a unique ID. If you're playing by the rules, then you should buy your ID from somebody. You can buy it directly from the IE or you can buy it, as this suggests, on a chip. The great thing about buying this is it will cost you £30. But the IE will have a minimum order charge of a few hundred quid. You get lots of addresses for that, but if you only want one, it's not much use. Then you want some software tools. I'm going to talk about using Kyle's tools. There are lots of other things you can use. I like them because they'll be bugging so good. I might like other things if I really use them, but these work fine. Anyway, you've got a 32K limit with a free tool like that because it's free as in beer. It's not open source. That's good because it imposes discipline and nobody should ever write code that's more than 32K. Gates was wrong when he said 640K was enough. No, it's 32K is enough. It's connected with magnetics and a little digression about buying bits. If you want a connector with magnetics in, I can't find anywhere in this country that will sell you one in small numbers for less than £2 or £3. But if you look at a switch that you buy with 18 of these connectors on the front for 50 quid from Amazon, it's perfectly obvious that the connectors with the magnetics in are not worth that much. If you have a little hunt around and find AliExpress on the web, you'll find lots of lovely people selling you them at a reasonable price. You might have to buy more than one. You don't have to buy 100. You'll probably get away with five. Anyway, if you buy 100, there's 36pence each, which is more like what they're worth. If anybody here just wants one, send me an email and I might send you one. But in general, buying stuff from AliExpress is pretty effective. It seems to work much better than buying stuff from eBay. The prices are unbelievably low, and so far I've never bought anything that didn't work as advertised. Maybe I've just been lucky, but it's a good place to go if you want bits that are cheap. Now, in the first sort of rush of enthusiasm for doing this talk, I thought I'd design a board especially for the purpose, and I did. But then more work stuff came up, so although I have actually built the boards, I have not written the software, so I can't show you on working. But this was my board for this, and because it was just for fun, it's not just a fire, it's a switch. So this is a managed switch with three ports and a micro. On the other side, you can put a little Chinese display, and it's got some expansion connectors, and it's got room for a chip to the Mac, and a real-time clock, because there was a corner of the board left over. The reason it's got a switch is I thought it would be really fun to daisy-chain things with Ethernet, and I wanted to explore doing that, because normally, of course, we tend to style wire everything on Ethernet. But daisy chains are one of the things that all these RS485 people go on about, so I wanted to prove that you could do that too. So that's the board, and eventually, I have sold it all the bits on, and I will write the software. And when I do, I'll put it on my website, and you can have it. But the reason I got sidetracked and stopped doing the board is that someone paid me to do this instead. This is quite similar. It's very similar micro, but instead of a switch, it's just a simple fi, which is this little beastie here. And it's the only thing that should be a challenge to a home solderer, because, unfortunately, it's a QFN package, which means it has no legs, and you can't solder them without using solder paste, and you have to have a hot plate. But if you do that chip first, actually you can do it with hot air, but if you do that chip first, you'll get away with it, and you can hand solder everything else. Just to prove that it really is simple, here's a circuit. That's a little bit of the micro. It's just enough of the micro to show you what connects to the fi. That's the fi. And it connects in a very straightforward way to the connector with the transformers. These old resistors are for programming the fi, so that we just put the power on and it comes up doing the right things. So you don't have to set up lots of registers in it, but you can if you like. And it's actually quite a simple interface. It's just as well, it's quite simple, because obviously it's going quite fast, so unless you've got a decent scope, you won't be able to see what the signals are doing, so you need to get it right first time. Does anyone ever make stuff like this? Does anyone solder bits together like this? Oh, good. OK, software. When I set out to write some software for these things, I have some rather strange goals, and these are sparked off by various things. I suppose one is I'm a bit cheesed of when I see all this sort of media stuff about an amazing kid makes web server and it turns out he bought a Raspberry Pi and sort of followed some instructions, which is fine, but it's not that amazing. But a lot of people seem to think that coding, as they like to call it, is like Lego, where you buy or get huge chunks of IP that other people put enormous amounts of effort into, clip them together and off it goes. The trouble is they don't know anything at all about what's happening underneath. Now, if you think you would like to know what's happening underneath, you have to extend this philosophy and say, well, I won't obviously use an RTOS, because that would be ridiculous, because that's huge amounts of code I didn't write, but really you need to take it a bit further and say I won't use any library code at all, and so that's the aim of this, and it's quite successful. It's sort of linked by not using the library code, the code will become small, and I mean small in the context of 32k, and I would like the thing eventually to do stuff other than just the if and at, which is just peripheral for talking to stuff. So, I mean very small, and by first, I mean it shouldn't waste time, so I don't want one of these ridiculous IP stacks which copies things from buffer to buffer five times as they get from your application out to the Mac. If we have time, we may digress into that, but most of these Macs have beautiful DMA systems, and if you use the DMA system properly, you don't need any buffering, so that's the goal. I haven't mastered this at all. There we go, right. What does the software have to do? Well, an awful lot of the work it has to do is just to set up the Mac and the Fi, that's the hard bit, because that will mean that you have to read the datasheet that comes with the processor, and when you've read it, you don't have to read it again and again, because it won't make much sense the first time. It probably won't make a lot of sense the third time, but most of what you need is there, and there are examples of making the things work on the web, but they're all mixed in terms of how well they're documented. Then you need something to send and receive basic ethernet frames. And a basic ethernet frame is a very simple thing. It has inside the frame, you've got the source address, the destination address, two bytes for the protocol you're using, then you have your data, then you have four bytes of CRC. It's useful to remember there's a CRC there, all this extra stuff that internet protocols put in, where they calculate odd checksums in funny, slow and creepy ways, are only necessary if you have a transport media which doesn't do any checking. It's more than reasonable for internet protocols to have them, because you might have sent the data over a phone line. But if you're using ethernet, you don't need to bother. Optionally, you can have some of the IP-ish things, which will be useful if you want to talk to a PC rather than just more things that you made yourself. And you can have an incredibly limited ARP, an ICMP. If I use acronyms that don't mean anything, shout out. Well, I'm shouting, that's good. And you can send little UDPs. I mean you can send big UDPs if you want, but we'll stick with single fragments. And how big does it end up? Well, the basic ethernet support is about 500 lines of C, it's about 2K bytes of code, and adding a very minimal ARP, ICMP and UDP, it's about 900 bytes, so we're talking about under 3K, so it's less than 10% for 32K, so it can be small, but it is limited. My ARP is as limited an ARP as I know how to do. So it only ever responds, it never initiates a transaction, and it only supports space for one address. So once it's talking to somebody, that's the only person it's going to talk to. It's good enough. You can obviously extend it, but that's to keep it small. The ICMP supports ping and it responds. It's just handy when you connect it to a PC for knowing if there are any things there or not. UDP is a bit more extensive, it will transmit or receive, but it will only do a single fragment, it doesn't handle fragmentation. But that is enough to live on a network with Windows PCs. I don't know if anyone's spent any time looking at what comes out of something like Wireshark when you've got a lot of PCs on a network. There is an awful lot of rubbish, but it can live in that environment, and it can talk to as many other devices as you like. Of course if you only want to talk to devices of your own making, you don't have to listen to the PCs at all, because you can just use a different protocol. You can invent your own ethernet protocol if you like, though I haven't actually done that yet. How fast? Well I haven't tested it on my faster process, I've only tested it on the 168 MHz 407. Every time you get a message that's reasonably valid that the thing has to think about, you waste a microsecond in the interact request handler, which isn't too bad, because you'll probably see, on a Windows-y network, you might see a hundred, if you're really unlucky, you might see a thousand such messages a second, but that will be pretty grim. So it's not wasting too much process of time. It takes it a microsecond or two to decide what to do about the message. Obviously depending on how closely the message is aligned to what you might be interested in, it takes you longer and longer to reject it. And the total time from a message in the receive buffer to a reply on Pings, that nine microsecond. It's quite quick. Because I said I would, I shall talk about these things, similar stuff. Now, I mentioned earlier that all these microse have wonderful DMA systems, which I can only describe incredibly briefly. But effectively what they have is a sort of two tiered DMA structure, where you have in your memory a list of data descriptors, or buffer descriptors, which tell the processor DMA block about the buffers where you have actually stored data that you've received or to transmit. Now the DMA controller in the micro looks at the descriptors and then it goes off and looks at the actual place in memory that they point to. And it does this completely automatically without wasting any of the caused time. So what you could do if you have an FPGA is you can map the FPGA into the processor's memory and arrange that its little window of memory is where the DMA believes all the data buffers to be because you set the descriptors up to point in that area. That means that all the micro has to do is to set the descriptors and then when any data actually needs to be transferred it goes in and out of the FPGA which the micro thought was the memory. Now the great thing about that is that you don't even have to properly map the address lines because the FPGA can count. So when you transfer a thousand bytes it just increments its addresses automatically. So you get an interface with the least possible number of lines and it can be very, very fast. In fact it can be so fast that you can quite easily run the ethernet at wire speed with a fairly average sort of micro. Obviously the FPGA might be quite busy but they don't care about that. And it can be useful because if you want to make a data acquisition system that's quite a good way of doing it and it means you can get 100 megabits of data onto the ethernet from something like an ADC with a fairly pathetic little micro which never actually sees the data itself it just looks after the overheads and descriptors and so forth. It's going to be time to go into that in detail. Oh! Right, okay, yes. You can use a fairly feeble FPGA. I've done it with XP2. Altera Cyclone 2 is probably easier to get. You can buy those from China on little boards, really cheap. You could probably get away with a lattice ISE 40 because they come in rather unfriendly packages. You might need an SD RAM, you might not, depends what you want to do with buffering the data. I don't think I need to bother with this because you all know about this kind of stuff. Hi! And we talked about it earlier. So I've got this information. The data sheets are the best thing, the most important thing. Sometimes that people ask questions about how do I make this work and so on and so forth, and they've not read the data sheet. Just about everybody publishes reasonable data sheets and some of them are very, very good. So they're worth looking at. The web's pretty amazing. If you want to know about Ethernet protocols then just type the question vaguely and Google it, and there'll be some nonsense, and you don't have to have books, but I use it a lot. There's a book I quite like by whoever he is, Jeremy Bentham, which is called TCPIP Lean of Mustafa Capital Letter. That's quite a good book if you really want to get into the nuts and bolts. His code example is a bit weird, but you don't need to bother with them. And you can look at my website where I will, though I haven't done it yet, published the schematic and the software for the switching thing once it's working. Ah, and that's it. Right, okay. Thank you.