Ok, I've finally finished those tests for power consumption for the board that has the RF antenna on it. Only difference is, the low-side sensing wouldn't work for me. I forgot I had a serial port connection, which obviously has a ground shield on it, so not all the current was returning through the negative terminal. Leaving me with crappy results in the region of 50mV when it should have been a good solid 2V.
Anyways, for high-side current sensing, the shunt resistor needs to be added on the positive wire. However, adding this resistor on the wire will cause a voltage drop and will decrease the voltage into my device. By how much, you say? Ask Mr. Ohm and his law, (V=IR), it just keeps coming back up. So there's about 2V drop across the shunt. I needed to increase the bench supply by about 1.7 volts, thus compensating the drop and ensuring 12V input to my device. With my negative terminal grounded and all my other connections setup, I needed to sort out the oscilloscope traces. Again, I need to find the drop across the resistor to find the current consumption. I add one probe on one side of the shunt and another probe to the other side. Both probes can be grounded on the ground terminal. Now all you have to do is get the trace on the scope, subtract the differences under different operations and divide by the shunt resistance to get your current. Now I'm finally done and back to my C++ project.
Thursday, 19 February 2009
Current Sensing
I've been working another project in parallel with my C++ programming stuff and it's been interesting to say the least. I think I may have mentioned a DVT on a small little board a few weeks back. Anyway, I've been given the task of doing tests on the power consumption of this board. Simple enough you may think. It was, but now it's slightly more complicated.
First off, I just attached a digital multimeter in series with the negative terminal to the DC power supply. I made all my measurements through this, and it worked grand. Unfortunately, we have an RF board attached and when this is powered, I need to measure for current spikes. The multimeter won't catch these as they'll be quick. So I found I need to attach a shunt and an oscilloscope to the works.
Now this is where it all became a little more complicated. I've probably got the worst setup ever, but it'll do for the moment. I started reading up on current sensing and found that if I had a current probe with a torsal ring, I could simply attach it onto the wire (unobtrusively), without worrying about change in voltage. Do I have one? No. So I have to figure out the other way to do this. So I need to setup a low-side current sensing circuit in order to take my measurements. What's low-side? This is where I attach a small series resistor with high power rating, breaking the negative terminal. I also have to connect the negative terminal to a grounding point for accurate results. Then I need two traces, one tracking the voltage across the 12V bench power supply and another across the resistor measuring the voltage drop across it.
Now I've used a 10ohm resistor, 5% tolerance and rated at 1/4W, this is not an ideal resistor to use at all. The value should be as low as possible, with a tolerance of 1% or even 0.1% for accurate results as well as a proper power rating. My circuit is operating at 12V, my current load is roughly 0.2 to 0.3A, which means, my power rating should be 4Watts. I'm way off the mark with a 1/4W resistor. As a result I'm going to lose accuracy due to temperature rise.
Now with a proper setup, I should be able to accurately measure any current spikes by recording voltage spikes and doing the necessary maths using good old Ohm's law (Voltage = Current x Resistance). Currently I'm not finding any specific spikes other than plain noise, so I guess my circuit is ok for now.
First off, I just attached a digital multimeter in series with the negative terminal to the DC power supply. I made all my measurements through this, and it worked grand. Unfortunately, we have an RF board attached and when this is powered, I need to measure for current spikes. The multimeter won't catch these as they'll be quick. So I found I need to attach a shunt and an oscilloscope to the works.
Now this is where it all became a little more complicated. I've probably got the worst setup ever, but it'll do for the moment. I started reading up on current sensing and found that if I had a current probe with a torsal ring, I could simply attach it onto the wire (unobtrusively), without worrying about change in voltage. Do I have one? No. So I have to figure out the other way to do this. So I need to setup a low-side current sensing circuit in order to take my measurements. What's low-side? This is where I attach a small series resistor with high power rating, breaking the negative terminal. I also have to connect the negative terminal to a grounding point for accurate results. Then I need two traces, one tracking the voltage across the 12V bench power supply and another across the resistor measuring the voltage drop across it.
Now I've used a 10ohm resistor, 5% tolerance and rated at 1/4W, this is not an ideal resistor to use at all. The value should be as low as possible, with a tolerance of 1% or even 0.1% for accurate results as well as a proper power rating. My circuit is operating at 12V, my current load is roughly 0.2 to 0.3A, which means, my power rating should be 4Watts. I'm way off the mark with a 1/4W resistor. As a result I'm going to lose accuracy due to temperature rise.
Now with a proper setup, I should be able to accurately measure any current spikes by recording voltage spikes and doing the necessary maths using good old Ohm's law (Voltage = Current x Resistance). Currently I'm not finding any specific spikes other than plain noise, so I guess my circuit is ok for now.
Trying to learn C++ fast!
For the last week, I've been trying to learn C++ using Microsoft Visual Studio 2008. It's a great tool and a very useful language to know, as well as a great addition to my CV.
However, I've been currently trying to decode someone else's program in order to re-write one section of the code and it's driving me mad. I wish I could just get some program that reads the code, tries to make sense of the code and then explains in comments on each line exactly what is going on. What I want to add is a very simple little adjustment, but the problem lies with using current variables and placing it in the right part of the code, which means I must have a proper understanding of the part that I want to edit.
So I think I'll cheat for the moment instead, I'm just going to add in code as follows
This is a simple piece of code which outputs to the stream the text.
That way when I run the code, I can try and figure out where it does what. It's kind of cheating and nor really learning, but I'm under time constraints and this will do for the moment. Next problem, writing the code I want to use.
However, I've been currently trying to decode someone else's program in order to re-write one section of the code and it's driving me mad. I wish I could just get some program that reads the code, tries to make sense of the code and then explains in comments on each line exactly what is going on. What I want to add is a very simple little adjustment, but the problem lies with using current variables and placing it in the right part of the code, which means I must have a proper understanding of the part that I want to edit.
So I think I'll cheat for the moment instead, I'm just going to add in code as follows
puts ( "In this section, I'm doing....!\n");
This is a simple piece of code which outputs to the stream the text.
That way when I run the code, I can try and figure out where it does what. It's kind of cheating and nor really learning, but I'm under time constraints and this will do for the moment. Next problem, writing the code I want to use.
Friday, 13 February 2009
Operating Systems I've worked with
DOS 6.22
Windows 3.1
Windows 95
Windows 98/ME
Windows NT 4
Windows 2000
Windows Server 2003
Windows XP
Windows Vista (32/64 bit)
MAC OS 9
MAC OS X
Ubuntu 8.10
Red Hat's Fedora 10
Suse 9.0
openSuse 10.2
openSuse 11.1
Suse Entreprise 10.2
FreeBSD 7.1
uCOS
RTOS's
Windows 3.1
Windows 95
Windows 98/ME
Windows NT 4
Windows 2000
Windows Server 2003
Windows XP
Windows Vista (32/64 bit)
MAC OS 9
MAC OS X
Ubuntu 8.10
Red Hat's Fedora 10
Suse 9.0
openSuse 10.2
openSuse 11.1
Suse Entreprise 10.2
FreeBSD 7.1
uCOS
RTOS's
Programming languages I've worked with
PERL
C
C++
Visual Basic
GW Basic (back in the old days)
HTML (and a few other related ones, dhtml, xml, etc)
PHP (very basic)
Assembly (ASM, 8086 and embedded)
UML
This list is not finished yet
C
C++
Visual Basic
GW Basic (back in the old days)
HTML (and a few other related ones, dhtml, xml, etc)
PHP (very basic)
Assembly (ASM, 8086 and embedded)
UML
This list is not finished yet
C++ and MicroCodes
So yesterday I was given a new project to get cracking on a program that was originally written to display and update micro codes into a BIOS ROM file. The program is written in C++. I've got a little background in the language, but not enough. So I've got my work cut out for me as some people would say.
So microcodes, what are they? Microcodes are made by the CPU engineer up building of a processor. These microcodes act as a fix or a workaround for errors within the processor. They can be stored in a high speed memory usually embedded into the processor itself. They translate machine instructions into sequences of detailed circuit-level operations. Now Wikipedia says they are not supposed to be visible or changeable by a normal programmer of an assembly programmer but this isn't strictly true. These codes can be embedded into the BIOS ROM and flashed to the BIOS PROM, where the microcodes will then be utilized.
So what do I have to do? My job entails taking the current program we have for displaying and updating these microcodes and adapting it to be able to upload microcode blocks into the ROM that may be larger than the microcodes it's replacing. The current program will overwrite adjacent sectors in the ROM, removing other microcodes. So I'm basically going to be working a fix.
So here I go, I've just finished installing Microsoft Visual Studio 2008 and I'm looking forward to doing more programming.
So microcodes, what are they? Microcodes are made by the CPU engineer up building of a processor. These microcodes act as a fix or a workaround for errors within the processor. They can be stored in a high speed memory usually embedded into the processor itself. They translate machine instructions into sequences of detailed circuit-level operations. Now Wikipedia says they are not supposed to be visible or changeable by a normal programmer of an assembly programmer but this isn't strictly true. These codes can be embedded into the BIOS ROM and flashed to the BIOS PROM, where the microcodes will then be utilized.
So what do I have to do? My job entails taking the current program we have for displaying and updating these microcodes and adapting it to be able to upload microcode blocks into the ROM that may be larger than the microcodes it's replacing. The current program will overwrite adjacent sectors in the ROM, removing other microcodes. So I'm basically going to be working a fix.
So here I go, I've just finished installing Microsoft Visual Studio 2008 and I'm looking forward to doing more programming.
System DVT
SO, over the last week, I've been up to fairly boring monotonous stuff. But given that, I've now got exposure to Fedora 10, Suse 10.2, Windows Server 2003, FreeBSD 7.1 and FreeDOS 1.0. Also got to use a number of AMD BIOS utilities through NDA, Linux Firmware Development Kits and other PCI testing programs.
Basically, I was given a system to run a DVT (Design Validation Test) on. The DVT document was already written up and the tests had already passed on its official DVT. I just had to get up to speed with the technology in order to start a DVT on a newer version of the system.
Firstly I had to log into the system remotely over the RLM console (Remote LAN Module) and log into the console via serial. Then with various commands I had to take dumps of the PCI setup with varying different cards installed and setup. I still have a lot to learn on PCI architecture so my checks of the PCI dump were slow. Since the start of this DVT, I've actually started reading my PCI System Architecture book and I'm slowly beginning to grasp what PCI is all about. Then of course when I finish that, I'll be moving onto PCIe. Plenty to do.
Anyway, part of the DVT involved enabling and disabling Option ROM's. These are devices which are called by the BIOS to add functionality to the PC. The most common of these would be a VGA card. You can see exactly when this Option ROM is called by the BIOS as it is the first thing that comes up on screen. Other Option ROM's include network cards, SCSI cards, hard drives (SATA/PATA) or Fibre Optic Channels.
This brings me to IPL. In order to test the robustness of the system, it was necessary to load a number of operating systems onto a hard drive through the system. So I went through the monotony of installing, loading and configuring Windows Server 2003, Fedora Linux 10, FreeBSD, FreeDOS and DOS from a floppy drive. Other similar tests were booting from a USB key and from a PXE server (which I mentioned before).
All in all a very interesting experience. I'm looking forward to using the new system, but that doesn't arrive until next week when I'm gonna test the crap out of it!
Basically, I was given a system to run a DVT (Design Validation Test) on. The DVT document was already written up and the tests had already passed on its official DVT. I just had to get up to speed with the technology in order to start a DVT on a newer version of the system.
Firstly I had to log into the system remotely over the RLM console (Remote LAN Module) and log into the console via serial. Then with various commands I had to take dumps of the PCI setup with varying different cards installed and setup. I still have a lot to learn on PCI architecture so my checks of the PCI dump were slow. Since the start of this DVT, I've actually started reading my PCI System Architecture book and I'm slowly beginning to grasp what PCI is all about. Then of course when I finish that, I'll be moving onto PCIe. Plenty to do.
Anyway, part of the DVT involved enabling and disabling Option ROM's. These are devices which are called by the BIOS to add functionality to the PC. The most common of these would be a VGA card. You can see exactly when this Option ROM is called by the BIOS as it is the first thing that comes up on screen. Other Option ROM's include network cards, SCSI cards, hard drives (SATA/PATA) or Fibre Optic Channels.
This brings me to IPL. In order to test the robustness of the system, it was necessary to load a number of operating systems onto a hard drive through the system. So I went through the monotony of installing, loading and configuring Windows Server 2003, Fedora Linux 10, FreeBSD, FreeDOS and DOS from a floppy drive. Other similar tests were booting from a USB key and from a PXE server (which I mentioned before).
All in all a very interesting experience. I'm looking forward to using the new system, but that doesn't arrive until next week when I'm gonna test the crap out of it!
Subscribe to:
Posts (Atom)