Recently, I've been pretty much obsessed with my micro. In my last entry, I spoke of some of the hardware issues, this one I'm going to talk about some software stuff.
The sinewave had to exceed a certain frequency. Now, considering the speed of my MCU (microcontroller), this wasn't a super high frequency.
I wasn't satisfied to just meet the specified frequency. I wanted... no, I NEEDED to get the highest frequency possible.
My initial code was slow. I wrote it how the instructor suggested. I then began to optimize the code.
I needed to generate a 32 point sinewave. Each point had to be sent to the digital to analog converter. The MCU could send data to the SPI (serial peripheral interface) at a maximum rate of 614400 bits per second. This meant that it took 1.627 micro seconds per bit. I had to transfer two 8 bit bytes to the SPI for each data point. So transferring 16 bits would take 26.041 micro seconds and, since the MCU takes 813.8 nano seconds per cycle, this meant that it would take about 32 cycles. Each 8 bit transfer took 16 cycles. I pre-calculated each of the 32 datapoints. I eliminated all stacking and unstacking operations. I eliminated the use of subroutines. My code went from like 40 lines to somewhere around 900 lines. I moved the registers to memory location 0x0000 so I could use direct addressing, eliminating even more cycles. I even went through the output of the assembler, making sure that the the opcodes I wanted were being used.
I sent the first half of a data point to the SPI. Then did 8 NOPs (no operation, takes 2 cycles). This allowed the transfer to complete. I then loaded the SPSR (SPI status register) into accumulator A to clear the spif bit. Then I sent the second half, did 8 NOPs, cleared the spif bit. (the spif bit had to be cleared before I could continue). I then toggled SS (slave select (PORTD PD5 (pin 5, which was tied to the load line on the DAC))), causing the DAC to convert the digital code into an analog voltage. As soon as that was done, I sent the next point of data the same way, etc. Once all 32 points were output, I jumped back to where I sent the first datapoint and continued from there. This made a very nice sinewave, especially when I looked at the filtered output. Nice and smooth and I think it was somewhere over 690Hz. I was very satisfied because I am very confident that the only way the code could be faster would be increasing the clockspeed of the MCU. And my prof went over my code and agreed that it was as fast as it could be.
My micro course is definitely the course I am most passionate about. I am almost as passionate about windows programming although I'd rather be using c++ than using c#. I can't seem to get as passionate about web development. Being able to write facebook from scratch just doesn't quite excite me the same way my micro does. Since I'm so deep into the MCU, my prof gave me a hardcopy of the MCU reference manual (the full manual, with all details in it... it's bigger than some of my textbooks), and the MCU technical specifications manual (about half as big), and I already had the quick reference book. I've already read most of the reference and technical specification manuals and I've had them for a week. I kinda consider my micro board as a pet... or maybe my baby... and... I guess I love it. I know it inside and out.
I got the analog to digital converter working and I bought an extra ref02 voltage reference and a capacitor and resistor and ten turn 10k trimpot, just so I could calibrate it so the step size of the ADC would be 20mV (it's only an 8 bit ADC, unfortunately). I could now write a program that uses my microboard as a voltmeter. The next project part will be to interface an lm335 temperature sensor to it and I'm really excited to do this. Then I can code a thermometer program for my micro.
In windows programming, I'm writing a program that will generate barcodes and allows the user to print them. And making a more useful graphics manipulation program.
Speaking of windows programming, I have a lab exam in that tomorrow so I should probably get some sleep.
Thursday, September 25, 2008
Tuesday, September 23, 2008
Post
As per lab specifications, the DAC hardware was installed and tested on the micro board (including all necessary filtering etc.).
All initial tests indicated that the DAC was properly installed and working within specified limits.
The subsequent part of the lab was to write code to create a sinewave out from the DAC, then to optimise the code to exceed the specified minimum frequency. Upon demonstration of the code running in ram, small modifications were to be made to allow the program to run from startup and the program was then to be bootloaded into the EEPROM and the entire system demonstrated to obtain checkoff.
The code worked fine in ram, producing a very nice sine wave out of the DAC. However, the modified code loaded into EEPROM for execution from startup failed to produce anything even remotely resembling a sinewave.
Initial suspicion was that the modifications made to the code prevented it from running, or that the minimal OS was taking care of some other aspect of the microcontroller that the DAC lab code was failing to initialize.
Code was examined line by line, each instruction checked and logic evaluated. The actual assembly produced by the assembler was also checked to ensure the proper form of instruction was being chosen.
After this failed to turn up any errors, the focus was shifted to the hardware.
Visual inspection revealed no obvious problems (any obvious flaws were caught and corrected before reaching this state). An oscilloscope was used to probe various pins relevant to the DAC subsystem. The output waveform (unfiltered) stayed low, though occasionally showed a minor pulse at regular intervals, indicating that the DAC was attempting to do something but was dying part way through the first cycle. The first significant issue detected was on SCLK (SPI clock). SCLK would show the proper clock pulses required to drive the DAC, but sometimes instead of a clear pulse, the voltage exhibited an exponential decay, even though there should have been no capacitance at that point. This explained why there was no wave out, but the cause of the SCLK glitch was still unknown at this point.
The second major breakthrough was that when SS (slave select) was probed, the clock was magically fixed until a reset pulse (at which point, the exponential decay was again seen). This raised some interesting questions since there was absolutely no logical reason why probing SS would fix SCLK. And didn't explain why SCLK was broken in the first place. Since this behavior was extremely abnormal, the chip was pulled on the suspicion that it may be blown. Logic levels were then tested on the socket while the chip was out. This revealed that there was no +5V into the chip on pin 1. The +5V rail was tested as well as the pin where the connection was made from the rail to the socket. The rail and pin tested fine, but the socket was showing no voltage to the chip. The wirewrap connection was inspected and although it appeared sound, solder was applied to ensure a solid connection. The socket now had +5V on pin 1 and the chip was re-inserted. The system was booted and the desired sinusoidal waveform appeared on the scope's display.
In summary, either the connection was good enough that when the chip was inserted, some current was able to flow through it, or the DAC8512 itself was putting approximately 2.2V out on pin 1 (Vin). When operating from ram, this problem did not manifest, but became apparent upon operation from EEPROM and this is why hardware was not initially suspected (due to the (apparent) proper operation of the DAC).
All wirewrap connections on the board are now suspect, however the board now works and since tearing it down could (although unlikely) cause damage, it is not recommended that the board be rebuilt at this point, although if furthur problems are discovered, this would likely be the best course of action.
All initial tests indicated that the DAC was properly installed and working within specified limits.
The subsequent part of the lab was to write code to create a sinewave out from the DAC, then to optimise the code to exceed the specified minimum frequency. Upon demonstration of the code running in ram, small modifications were to be made to allow the program to run from startup and the program was then to be bootloaded into the EEPROM and the entire system demonstrated to obtain checkoff.
The code worked fine in ram, producing a very nice sine wave out of the DAC. However, the modified code loaded into EEPROM for execution from startup failed to produce anything even remotely resembling a sinewave.
Initial suspicion was that the modifications made to the code prevented it from running, or that the minimal OS was taking care of some other aspect of the microcontroller that the DAC lab code was failing to initialize.
Code was examined line by line, each instruction checked and logic evaluated. The actual assembly produced by the assembler was also checked to ensure the proper form of instruction was being chosen.
After this failed to turn up any errors, the focus was shifted to the hardware.
Visual inspection revealed no obvious problems (any obvious flaws were caught and corrected before reaching this state). An oscilloscope was used to probe various pins relevant to the DAC subsystem. The output waveform (unfiltered) stayed low, though occasionally showed a minor pulse at regular intervals, indicating that the DAC was attempting to do something but was dying part way through the first cycle. The first significant issue detected was on SCLK (SPI clock). SCLK would show the proper clock pulses required to drive the DAC, but sometimes instead of a clear pulse, the voltage exhibited an exponential decay, even though there should have been no capacitance at that point. This explained why there was no wave out, but the cause of the SCLK glitch was still unknown at this point.
The second major breakthrough was that when SS (slave select) was probed, the clock was magically fixed until a reset pulse (at which point, the exponential decay was again seen). This raised some interesting questions since there was absolutely no logical reason why probing SS would fix SCLK. And didn't explain why SCLK was broken in the first place. Since this behavior was extremely abnormal, the chip was pulled on the suspicion that it may be blown. Logic levels were then tested on the socket while the chip was out. This revealed that there was no +5V into the chip on pin 1. The +5V rail was tested as well as the pin where the connection was made from the rail to the socket. The rail and pin tested fine, but the socket was showing no voltage to the chip. The wirewrap connection was inspected and although it appeared sound, solder was applied to ensure a solid connection. The socket now had +5V on pin 1 and the chip was re-inserted. The system was booted and the desired sinusoidal waveform appeared on the scope's display.
In summary, either the connection was good enough that when the chip was inserted, some current was able to flow through it, or the DAC8512 itself was putting approximately 2.2V out on pin 1 (Vin). When operating from ram, this problem did not manifest, but became apparent upon operation from EEPROM and this is why hardware was not initially suspected (due to the (apparent) proper operation of the DAC).
All wirewrap connections on the board are now suspect, however the board now works and since tearing it down could (although unlikely) cause damage, it is not recommended that the board be rebuilt at this point, although if furthur problems are discovered, this would likely be the best course of action.
Thursday, September 04, 2008
omg school again
So school has begun once again. Well, last week.
But I didn't get around to blogging until just now.
Web development class seems interesting and the prof seems pretty cool.
Windows programming with C# feels like an insult to my intelligence so far. After years of coding apps in C++, the fact that Visual Studio writes most of my code is an insult. But leaves me more time to focus on my other classes so that's good in a way. I'm always gonna be a C++ coder though, I definitely like it better.
But I'm picking up C# really easily which is nice.
I have the same prof for micro 2 and DMAC and he is really good. I feel a lot better about DMAC now than I did when I dropped it last year. The prof makes a huge difference.
Industrial programming also seems pretty good so far. The only obstacle in that course will be that the trilogy software is kinda shitty. Well... the interface is really shitty. Like, if you're naming IO lines, you can't just tab to the next field or click the next field. You HAVE to hit enter after every entry. And then when adding relays, (switches and stuff) to make certain things (like two in parallel followed by one in series) the order you add things makes a huge difference and often you have to re enter entire circuits because the software sucks. ...you'd have to use it to understand. Anyway, by the end of the course we'll be programming a PLD to control a chemical plant.
The best class is micro 2. Since there are only 2 students other than me. One of them rarely shows up and the other sometimes doesn't, so sometimes it's just me and the prof. And he's teaching it more like a seminar. I'm really enjoying it and it's giving me a much better understanding of the base hardware design (micro 2 is short for micro computer design 2), and coding directly for the hardware. It makes me feel really smart. Yesterday I mounted the stuff for the DAC and I still have to finish wirewrapping it but I've already begun writing the code to use the DAC with the HC11's SPI.
Other than that, I'm fighting off a cold (runny nose, stuffed up sinuses, headaches, cough, etc). But I feel pretty healthy otherwise. Work is taking up my weekends.
But I'm doing ok so far.
But I didn't get around to blogging until just now.
Web development class seems interesting and the prof seems pretty cool.
Windows programming with C# feels like an insult to my intelligence so far. After years of coding apps in C++, the fact that Visual Studio writes most of my code is an insult. But leaves me more time to focus on my other classes so that's good in a way. I'm always gonna be a C++ coder though, I definitely like it better.
But I'm picking up C# really easily which is nice.
I have the same prof for micro 2 and DMAC and he is really good. I feel a lot better about DMAC now than I did when I dropped it last year. The prof makes a huge difference.
Industrial programming also seems pretty good so far. The only obstacle in that course will be that the trilogy software is kinda shitty. Well... the interface is really shitty. Like, if you're naming IO lines, you can't just tab to the next field or click the next field. You HAVE to hit enter after every entry. And then when adding relays, (switches and stuff) to make certain things (like two in parallel followed by one in series) the order you add things makes a huge difference and often you have to re enter entire circuits because the software sucks. ...you'd have to use it to understand. Anyway, by the end of the course we'll be programming a PLD to control a chemical plant.
The best class is micro 2. Since there are only 2 students other than me. One of them rarely shows up and the other sometimes doesn't, so sometimes it's just me and the prof. And he's teaching it more like a seminar. I'm really enjoying it and it's giving me a much better understanding of the base hardware design (micro 2 is short for micro computer design 2), and coding directly for the hardware. It makes me feel really smart. Yesterday I mounted the stuff for the DAC and I still have to finish wirewrapping it but I've already begun writing the code to use the DAC with the HC11's SPI.
Other than that, I'm fighting off a cold (runny nose, stuffed up sinuses, headaches, cough, etc). But I feel pretty healthy otherwise. Work is taking up my weekends.
But I'm doing ok so far.
Subscribe to:
Comments (Atom)