 Rwy'n gweld, mae'r gweithdoedd yn cyd-fasg yng Nghymru, ac mae'r gwaith er mwyn o'r cyd-fasg o'r cyd-fasg o'r cyd-fasg a'r ddweud yn gweithio. Fyddon ni'n arsgrifiad hwnnw i'n gweithio hwn, mae'r gwaith hwnnw i'n gweithio hwnnw, o'r ddaraf i'r cyfeydd yn hynny'n gweithio'r cyllid cymryd. Felly mae'r cyflwyr yn cyflwytaethau cyllid cyffredinol, mae'n bwysig o'r cyfeidliadau yma, ac mae'r cyfeidliadau yn dda i'r cyflwyr. Felly... Cyfeidliadau cyfyrd. Mae'r cyfeidliadau cyfeidliadau cyfyrd, y bwysig, dweud i'n ymd即 o'r hwnt y proiect, dan rhai'r rhaid i fynd i gael'r oedd, rhai'r dweud i'r holl hwyl, dweud o dweud eich holleywyr, wedi'i roi'r holleywyr, o'r adeilad, o dweud i'r holleywyr, a i'r debyg, a ysbryd o'n dweud i'r holleywyr o'r ymddi, o'r colleywyr, o'r chdefnwyr, o drafod i'r holleywyr,building stage on small projects and, for example, any previous steps, the requirements analysis will save you a lot of time in the design stage and will save you time in the test, design, and development and if you develop it and test as you go along you will have a very small debugging stage I once got told in a previous job that 80% of the job was debugging and I kind of career suicided by saying, well you didn't design it very well did you? Iterive project, now this is what I tend to do. Basically the same as waterfall except you get on components within your project. So you go round the loop more than once over the period of the project. We're currently actually doing this on a project I'm doing for my employer. Where we are putting DRM in a video product and there is eventually hardware decryption at the bottom but there are several software layers so I implemented the decryption in software at the top and then once we got the APIs between that and the middleware I then re-implemented the decryption in the middleware to prove the API worked and then once we got that to the lower level I re-implemented it in software in the low level and now we're ready to do the hardware implementation. And then the buzzword of the day agile. It's basically iterative over very small periods of time. 14 days. You pick a very small piece of component or functional piece. You go over it. You do all the steps very quickly. At the end of the 14 days you have maybe just a class or an object or a small part of a piece of hardware. Very dynamic. They're called sprints because they are short, fast periods. Unlike the previous two which tend to have more project manager influence, this tends to be done more by the developers who kind of stand up in a huddle and work out what they're going to do at the next sprint. You can't get past planning without talking about a gant chart which is basically how to work out your paralysation of jobs. For example, you might have to send your PCB off and you know you're not going to get it back in four months or four weeks or whatever. So when you want to do that earlier and work on other things while it's being produced. So basically this just allows you to graphically put down all your tasks and work out the best way of doing them and figure out whether you've got any critical paths. Right. I have these design rules mainly because I can't keep a lot in my head. I need to take things simply and just ploddle on. I'm more the tortoise than the hare. So I always make sure I keep everything simple. It might be lots of simple things connected together to make something complicated but I keep it simple. I don't reinvent the wheel if somebody's done it before. If it's good enough, it's good enough for me. Attainable goals. Don't try and do something that you know you can't succeed at. Plang ahead, which is where the gant chart may come in. Follow standards. It helps you when you can borrow other people's test software on test rigs or whatever. Again, back to the current work I'm doing is it's a W3 standard at the top. So the first thing I did was sat down and wrote a piece of test code that followed the standard and then I could find out where everything broke before I wrote the code. Modularize. Small pieces are easier to develop than big pieces. Keep your number of variables and changing down to a minimum and I test as I go along. Basically, when I commit a piece of code or a design it at least compiles clean and generally works. It might not work 100%, but it generally works. So test-driven development. So there's a couple of ways you can develop and test as you go along. One of which is test-driven development. You look at your requirements. You then design your test to test the requirements. You develop those tests and then as you develop the code you run the code against tests. That proves that you're fulfilling your own requirements. Every time you get some new requirements, repeat. Another one is unit testing. For a module you write a set of tests that test that module as a black box. You might need to mock some functionality. Basically dummy code. API isn't just go, yeah, I worked without actually doing anything. And again, test as you go along. So what was, what did I base this around? I have toy trains. That's a very small one. The technology for these things has been around 100 years. They are basically 12 volts into a wire-around variable resistor that connects to the track. It picks up the current from the track that drives the motor. Chains the voltage, the train goes faster, slower. Chains the polarity, it goes backwards or forwards. Very simple. But longer track, you lose. Voltage is dirty track resistance. A factor resistance at slow speeds that you're basically the losses as a percentage of the voltage are a lot higher. So you end up with stuttering and bad behavior. Only one at once you put two on. They'll both go the same way and the same way and whatever. And if you've got signals and points and all the other stuff, everything needs its own wiring. So, step one, people start doing, look, just use PWM. It works for all sorts of other things. Keep the voltage up. Pulse output drives the trains that way. So, same layout, just a different controller. Voltage loss is lower because you're running at typically about 15 volts PWM. Dirty track problem, not so bad. Again, slow speed behavior works. Problem, still both trains go that way. Both trains go that way. And still need all your own wiring. So, about 30 years ago when technology started becoming attainable to the common person, various people came up with tried ways of using a digital control system. One has come out as a standard. It's called digital cab control. It is a standard. You can go on to the NRMA, which is, again, it's American being national, but it's actually a standard across the world. And there's whole documents that describe this. Basically, your track is a two-wire bus. And everything has an address on it. And it has a decoder. And these things. So, if we go back to this, that little blue thing in there, which is about the size of my fingernail, that connects between the wheels and the motor. And it has an address and you can program it up and you can set things like acceleration and deceleration and all of these things. So, simple wiring, you've just got two wires. Multiple trains, no problem. They've got their own address. Always full voltage because it's not the voltage from the track going to the motor. Signals and lights and everything else, you just have different decoders that control them that you wire up to the track. And you can add things like modern ones. They have small speakers in and sound start and pause and all the stuff and lighting and everything like that. Disadvantage is, well, the decoders aren't too bad. That's 15 quid, but you're looking at several hundred pounds for a controller. Because it seems that model rail people are scared of computers, they're all basically computers that look nothing like computers. So, this is the protocol straight out of the standard. It's just bits encoded on the track. And it's a packet format. So once I looked at this, I thought, oh, I want to make a controller to do this. It can't be too hard. Transitions of two equal voltages. These are determined by the length of the pulse. And the reason for that is a marvellous hack. These systems can drive one train locomotive that doesn't have a decoder. Because if you play with the bit length, you can do PWM on it. And that's why it flips between the positive rail and the negative rail and not just ground and positive. So you can actually reverse the average voltage over the track. Some motors don't like it. Some get quite hot. And it is very hacky, but whoever came up with the idea, I would, I just think it's genius. So design considerations. What were my decisions? I'm only going to do a controller. My hardware expertise is not good enough to replicate that little thing. Also, many more of these get sold as do the controllers, because every locomotive has to have one of those in it, which means they're quite cheap. Also, it's quite an accurate dependent time signal. So I decided I'm just going to go for a small microcontroller to generate the bits train stream. The other problem I've got is I need to drive relatively high current at a relatively high voltage, so we need to boost it. And it's the old... Let's go for a standard off-the-shelf solution, H-bridge. For those who don't know what an H-bridge is, basically you've got four switches in the motor, and dependent on which direction, which switches are closed, you can change the current through the motor. And if you, for example, shut S1 and S3, you actually short the motor, which will stop it dead because of the back EMF. Somebody's already done chip for doing these. This one will either drive a big stepper motor or two regular motors. And it's about three quid. But again, I'm lazy and I don't reinvent the wheel. eBay has one of those for a fiver. He uses the same chip. Even has a five-volt regulator in it to take your power voltage down to the five volts to drive the logic side. So that's my hardware. How do you develop it? Just type it in VIM. Duke and CCC on the command line. I very much prefer an IDE. Again, I'm lazy. I don't want to have to do all work. Visual Studio is quite good for software development. It's very good. I think it's Microsoft's best piece of software. I'm using an AVR. So why not just use the Arduino IDE? I tend to program CC++ at the lower level rather than through the IDE API. So the Arduino API. So I went for Eclipse. PCB design. Haven't actually got a PCB yet. I guess go for Eagle CAD. It's available. It's open source. And all the PCB manufacturers accept the file. So source control. Can't manage a project without source control. Properly manage source control, actually, because I was cursing our customer who decided in their wisdom to save some disk space. Hard drives aren't expensive. They'd wipe out a load of old versions of the source of the thing we're working on, which meant that when I found a bug and wanted to know what commit I'd put in that created that bug, I couldn't because I couldn't rewind back to the previous code. Stick everything in it. If it's a remote server, have it backed up, and you know everything's safe. Debuggers. If you're using GCC, go for GDB. You can either, for something like a pie, you can debug on the machine or GDB server, which allows you to do it remotely. You can use a nice JTAG or something like that to do it remotely. Tools that make your development easy make it quicker, make it less buggy. It might be... Ooh, cool. I can do all this on a VT220 on an 80-column screen on a command line. But actually, if I've got a nice UI and I point and click and everything like that, and it does it all for me, and I know it's going to work, great. Asyloscopes, logic analyzers, digital voltmeters are not just hardware debugging tools. About 10 years ago, I was debugging a sound driver because we were ending up with two channels flipped on SPDIF coming out of a product. I just stuck a scope on it and realised that their firmware had a bugging it, and it was putting the channel bit on the wrong packet. The code looked perfectly fine. There was something in the firmware inside the chip and you would not have spotted that had you not scoped it. Nobody was able to sort of scoping it. That was the first thing I did. I think all software engineers who work at a lower level need to know how to debug hardware at a basic level. Why do I like Eclipse? Many languages. Syntax checking as you type. Again, speed things up. I don't have to compile it and then see bugs. Other people's code. I want to find out what it's going. I can just follow functions around. Completing and linking including cross-compiles. Debugging. I've got a set up that actually allows me to write my code on my Mac, compile it for my Pi, download it onto my Pi, run it on my Pi and debug it on my Pi without actually ever touching my Pi. Code management, as I said, is you got support in there. You can actually see what you've changed. And for this I basically write the code for the AVR. I hit the button, it builds it and it squirts it straight onto the flash on my AVR. So what did I do first? I didn't build a DCC controller first. I built a PWN controller first. Because it's an easier project. I learnt some stuff as I went along. Hardware requirements are basically the same. Changes are just software. So, plank of attack. Again, split everything down into achievable units. Easy to test. I create a little serial console not reinventing the wheel. I stole the idea of using a per-serial console from a bus pirate. Couldn't remember the game for having it. You can just hang it straight off of any old laptop, pull up a serial port and you can rung it at that level. Once you've got that going I wrote some PWN generation codes. You make sure that that looks fine with the scope. Connect to the HPR if you're going make sure it looks fine with the scope. Finally, connect to track and test. Why serial? Lowest common denominator interface. Everything's got it. Simple to use. Humans can use it too if you do it right. Testable in isolation. When I said it was simple, it's simple. Remote debugging. It's an AVR to GDB server. You're not going to have it running because it's not running Linux. So, in this case it's just print F. Other things I tend to do remote debugging either with a JTAG which you can debug the processor directly or over TCP IP. Some languages, as you see scopes and we've got wires and your scope are going. So, DCC this is still a work in progress and you've got anything going on this yet. So, basically add a few extra commands to my serial console. Test, test as I go along. Code packets. We can check that without actually seeing the encoded bitstream. Then we stick the bitstream encoding in. Again, test. Stick the whole lot together. Test it before you connect to the other hardware and then finally connect it all up and see if anything actually moves. The unfortunate problem with those things is there's no return path. So, on either your things get a burst into life or nothing will happen and you can't tell why it doesn't happen without just looking at what's on the wire or in this case the track and that was basically where I've got to. Any questions? APPLAUSE