Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: Registers, C++

  1. #11
    Join Date
    Dec 2003
    Location
    3dbuzzmania
    Posts
    4,064
    Quote Originally Posted by ComicSansMS View Post
    by "instruction set", i was referring to the cpu's isa, which you indeed do need to know.
    e.g. if he was using an arm-based architecture instead of geode, the masm/nasm-toolchain wouldn't have worked.

    See and now you beat me.

  2. #12
    Join Date
    Jun 2003
    Location
    Trier, Germany
    Posts
    1,350
    Quote Originally Posted by TF242 View Post
    See and now you beat me.
    so the karma has balanced itself out once again

  3. #13
    Join Date
    Jun 2008
    Posts
    11

    Thumbs up

    [QUOTE=enhzflep;1375881] Thanks, I'll try to do this. Can you explain to me : What means index 51h?

  4. #14
    Join Date
    Oct 2006
    Location
    Melbourne
    Posts
    743
    Sure, I'll see what I can do. This is the third time I've tried to answer you, but the power's been dodgy here, so I'll keep it brief.

    The Winbond chip is using Port Mapped IO as the means of getting data in and out. The only problem is that if every device used an IO port for each and every single byte of mem they contained, we would soon run out of IO ports. So, many different memory bytes are accesed through the same port.

    In order to retrieve the data that we want, we must tell the chip which memory byte to make available through said port. In your case, you want byte number 0x51. This data will be accesable via the 6th port assigned to the device. In order to tell the device that we want this data, we put the index number - 0x51 into the 5th port assigned to the device. From there, we simply read the data in the device's 6th io port.

    You'll notice my use of the words "port assigned to the device". This is where plug-n-play enters the equation. Sometimes several devices are setup to use the same ports by default, this we cannot do. What is done is the device IO ports are mapped to the system IO ports.

    In this case, the 0th device port is mapped to system port 0x290, making the 5th and 6th ports 0x295 and 0x296.
    This little wiki page may help to clarify the situation. Memory Mapped IO
    The video card for example uses Memory Mapped IO for the screen-buffer, while the Winbond chip uses Port Mapped IO for the data you're trying to retrieve.

    Here's a small pic to illustrate the Winbond IO ports in question.
    S.
    Attached Images Attached Images
    Last edited by enhzflep; 06-11-2008 at 03:59 AM. Reason: forgot to make device ports zero-based

  5. #15
    Join Date
    Jun 2008
    Posts
    11
    [QUOTE=enhzflep;1377850] Thanks for so detailed explaining.
    I followed yours explaining. I'm changing the next instruction: mov al, 0x48, becouse I'm working with sm bus. I got some data 0xff00, I have not idea what I need to do with this data

  6. #16
    Join Date
    Oct 2006
    Location
    Melbourne
    Posts
    743
    That's okay yanol, my pleasure.

    I'm a little confused.
    I don't understand
    "I'm changing the next instruction: mov al, 0x48, becouse I'm working with sm bus."
    Where does the "mov al, 0x48" come from?

  7. #17
    Join Date
    Jun 2008
    Posts
    11
    [QUOTE=enhzflep;1379818]
    In 1-st step (that you explained to me)

    ; step 1 - let chip know we want data from index 0x51
    mov dx, 0x295
    mov al, 0x51 // I thik I need data from index 0x48, becouse I'm working with serial bus. Battery in this system is an external battery that connects to the sm bus

    out dx, al

    Finally I got data 0xff00.

  8. #18
    Join Date
    Oct 2006
    Location
    Melbourne
    Posts
    743
    Could you direct my attention to the PDF page number that says to use 0x48?

    I don't follow you, I'm afraid my friend. I'll have another look at the PDF when I get home
    in 20 minutes or so.

    S.

  9. #19
    Join Date
    Jun 2008
    Posts
    11
    [QUOTE=enhzflep;1379866]
    I'm looking pages 41, 47 in PDF W83627HG - This is Serial Bus Address register

  10. #20
    Join Date
    Oct 2006
    Location
    Melbourne
    Posts
    743
    Ahhhh ha! Now I'm with you mate. Sorry about that.

    Okay then. This is just the same concept I mentioned before, except now we're using an index register to point our data register at a certain byte of memory. Once this is done, we're sending a byte to the device which is used as a second index. To use an analogy, we're positioning a window to look out. Once that's done, we're positioning a second window behind it to see the data we want.
    Perhaps code would be easier. I think this should do what you want.

    Code:
    ; step 1 - point to Serial Bus Address Register
    	mov	dx, 0x295
    	mov	al, 0x48
    	out	dx, al
    
    ; step 2 - tell Serial Bus Register that we want to read the +3.3VIN value
    	mov	al, 0x62
    	out	dx, al
    
    ; step 3 - read the value
    	in	al, dx
    I don't know which line your external battery is going to be connected to, whether it's the +3.3, +5 or +12 lines. I had previously thought you wanted the VBAT value, so didn't think to look here.

    I guess that the value returned is just a measure of where the value sits between the VMin and VMax values. E.g


    rawActual = readActualVoltage(); // the ASM function you're creating
    actualVolts = ???? * rawActual

    The values of ???? may vary depending on the voltage you're reading.
    As a guess
    12 volts in 255 divisions (0 - 0x255), means 0.04v per division (12 / 255)

    So if we had: rawActual = 0xB1 hex
    then rawActual = 177 decimal
    actualVolts = 177 * 0.04
    actualVolts = 7.08v

    If this were the case, you could re-express the equation to get a more accurate & reusable piece of code:

    Code:
    float calcActualVoltage(unsigned char rawValue, float voltRange)
    {
        return (rawValue * voltRange) / 255.0;
    }
    
    //usage
    actualVolts = calcActualVoltage(rawValue, 3.3);
    actualVolts = calcActualVoltage(rawValue, 5);
    actualVolts = calcActualVoltage(rawValue, 12);

    In either case, whether you need the 3.3v, 5.0v, 12.0v or VBAT(pdf p79) reading you'll need to do some kind of conversion on the value read from the chip.

    Just thinking about the ability to set alarms for over-voltage or temperature, my memory of doing this in the bios is that you only get 0.1v increments to change the value with. That may or may not be useful, but could well be worth keeping in mind.

    That's about all I can think of at the minute.
    I suppose just give that a try and see how it goes.

    S.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •