|
Mon 14 Dec 2009 Well here we are at the first electronics diary entry, maybe it will run as long as the Graynomad Chronicles which have been running for 12 years now, maybe not. We'll see I guess. You may have noticed that I'm using three digits for the diary number so I'm allowing for 999 entries :-) I've been inspired to write stuff about my electronics adventures partly because that's what I do ie. write stuff about what I do (is that recursive?), and partly because I've been reading Keith's Electronics Blog and I find it an entertaining read and thought maybe I can emulate that in a small way. Wed 16 Dec I've been prototyping various aspects of the speedo lately and things seem to work as expected. I've also been designing the PCB and it's ready to go so today I emailed the Gerber files to the PCB manufacturer. Here's hoping I haven't stuffed up too much. Fri 18 Dec I've been doing a lot of work on my network design and I have to say I think it's coming along well. There are a lot of features though and I started wondering if an ATtiny85 would be able to fit the code, not to mention be fast enough to run at the 4800bps I've been specifying. So I wrote a small amount of code to at least get some idea as to code size/speed etc. The test code is written in my language of preference C, it constantly transmits data in 8N1 async format out an IO pin and maintains five software timers. Here's a trace of the results.
Note the following.
As you can see by the lack of activity on the MAIN trace and the almost symmetrical wave on the ISR trace, the processor is spending at least 50% of it's time servicing the timer interrupt which is used for both the serial transmit and software timer maintenance. And this is as 1200bps on the serial line, I wanted to do 4800. Now I know the code isn't pretty and performance enhancements could probably be made, but I'm not going to get an order of magnitude improvement which is probably what I'd like. Another thing I discovered it that I've already used 43% of the 85s 8k program space. Maybe that's mostly a library and therefore the code won't grow proportionately, but still it's pretty big. Hmmm, I don't think this is going to fly. Sat 19 Dec Why isn't my processor running as fast as it should? I'm writing some code in assembler and pulsing an IO pin as such. sbi 0x18, 0; Which should produce a pulse two clock cycles in width. The processor is set to be running at 8Mhz so how come the pulse width is 2uS? It should be more like 0.25uS. I take a really close look at the data sheet and notice a clk/8 option, then I check out the "Fuse" section of the AVR Studio programming dialogue and see this.
Notice anything? (hint, the red circle might help) The internal fuses are set to divide the oscillator clock frequency by 8. Doh! Guess I may have to look at that C code timing again.
Wow, look at the difference. The MAIN trace is now working overtime with just short breaks for the ISR. That looks a lot better, but we're still at 1200bps, let's try 4800.
I've left the time base the same so you can see the bits are now going out the serial pin 8x faster and the increased load this is placing on the software. It's keeping up but only just, notice that the ISP is now taking up a bit less than 1/3rd of the time available even with a serial data rate of 4800, whereas before (back on the 18th) it was about 50% and the serial data rate was only 1200. So there's a vast improvement, but I'm still using 43% of available program memory and haven't written 1/10th of the code yet. Nope, it looks like I'm going to have to brush up on my assembler skills, it's been 20 years since written a whole project in assembler, it'll be like a walk down memory lane. Here's hoping assembler code will be fast enough, it should be. Sun 20 Dec I've rewritten the above slow C code in assembler, something of a chore because it's been so long since I've written in assembly language, but also because I've never written with the AVR instruction set. Still they're not all that different. Here's the results (sorry the traces are in different locations, but the important labels are the same).
Look at the white blocks on the top line, that's the MAIN idle loop pulsing a pin. The ISR is now only taking up about 1/10th of the processor's time plus I've got five timer callback routines going as well, before I only had one. And the other good news, the program takes up only 4.6% of available memory as opposed to the 43% the C equivalent did. Looks like I'll be doing some more assembly language programming over the next few weeks. Tue 22 Dec My network design is coming along, and I must say I'm enjoying tinkering in assembly language for a change. Talk about control, I know people reckon that modern optimising C compilers can do as good as hand-coded assembler, but I just can't see it, in the last day I've got my poor little ATtiny85 doing the following.
And all this in 938 bytes (including some debug code), and I spent half my time mucking around wondering how to do a MACRO or load indirect of X in an unfamiliar assembler and instruction set. I remember back in the days when everything was done in assembler and C was just getting a look in. I had such a large library of macros and utility functions that I was almost writing in a 2GL anyway and I didn't see the need for C. I'm nowhere near that state yet of course, and I probably never will be because there's no doubt you get a lot more done with 2, 3 or 4GLs in any give time. But this little network project of mine does need some serious real-time stuff at the bottom end. Let's have a look at some of it.
The top two traces (TX1 and TX2) are the serial lines transmitting "packets" of data (TX1 sends 11,22,33,44 and TX2 sends 01,02,03,04,05,06,07,08, each has a frame counter as the first byte). These transmissions are set off by two tasks that run as a result of two of the timers expiring. As the timers are set to different times and the packet lengths are different the two events are essentially asynchronous, therefore sometimes TX1 will get a couple of frames out between TX2 and sometimes only 1. This is the luck of the draw as the two times "beat". The bottom three traces that look like almost solid blobs are the main loop and the three tasks or procedures (main and proc1 share a trace) working. Let's have a closer look.
Here we see a brief period between sending bytes on the serial line, the solid blobs from the previous trace photo are now zoomed out and we can see the main loop and three procedures are getting quite a lot done. Not that they really have anything to do yet except pulse a pin for my benefit, but they will. But we're not only doing stuff in between serial bytes yet and there's no point twiddling your thumbs just because a few bits are being stuck out a port.
Now we see procedure 3 going gang busters during the 208uS (millionths of a second) it takes to transmit a single serial bit on TX2. Ok I won't be able spell-check War and Peace during the idle times, but I can get some work done like read a sensor. See the 9 wide breaks in the pulses, that's the 21uS interrupt breaking in and deciding there's nothing to do, on the tenth occasion it realises that a new bit has to be sent so the break is a bit longer. It's partly a cooperative system and I'm still not 100% convinced it's fully working, but it's sure looking like it. Thu 31 Dec Still working on the network spec and prototyping some of the circuits, here's the line interface. Thu 4 Mar 2010 Don't take any notice of the above circuit, it works fine but connecting MosFETs directly to the real world like that is not a good idea. After a couple of months working on the network design I've recently got back onto my speedo, but before I could do much I had to build something to house all the tools I need for prototyping, it was getting to be a real mess. So I've built a "Lab in a Box", I bought a set of BBQ utensils, threw the contents away and converted the case. It's working really well and the elastics straps that were for the utensils now hold my tools.
On the lid you can see some tools, pliers, logic probe, calipers etc. and in the base is a small DVM, bread board, AVR development board, and a PSU. The speedo can be seen leaning up against the lid with the ISP cable running to the development board which in this case is just being used as a programmer. All this allows me to close the lid and put the lot away, remember that we live in an area about 2x2 metres so things have to be easily stowable. Most of the code for the speedo is running, I test it using pulses generated by another AVR at frequencies similar to those expected from the tail shaft. I suppose the next thing to do is wire up the sensor and then wait till we move in a few days to see if it works. Fri 5 Mar The network design is coming along well, about 200 pages of specifications at present and still growing although I haven't added any features lately which means the design is becoming fairly stable. Mostly now it's a case of filling in the blanks. Mon 5 Apr The speedo has been installed for a week or two now and it works great, still needs calibrating and the code is not exactly production quality, but it'll do. Apart from that I'm still working on the network design. If you're interested there's some blurb here. Sun 30 May Not much happening here at present, all the action is over at the BUSnet section. Mon 30 Aug Still not much happening here at present, however at present all the action is over at the Quub section.
|
