AVR-Chat

OK.  Now the program works correctly in terms of the stack and other 
technical details, but seems not to be reading the EEPROM data successfully.

   IIUC, the EEPROM data for the simulator in AVR Studio is read from 
the .eep file, which does exist, and which does contain the data I 
stored in it in the code (as best I can tell...it also contains some 
extraneous data which I am presuming is formatting data added by AVR 
Studio,which would not be written the the physical EEPROM when the chip 
is programmed).

   So wy is this code not actually reading the EEPROM data?  not only is 
it not showing up in r0, but using the Watch tool, it is not showing as 
being addressed in EEDR, despite the data addresses appearing as called 
out in EEARL (with EEARH loaded with a 0x00, since I ommly use but 100 
bytes of the EEPROM).

    ***ARGH*** but learning to use new tools can be such a pain in the 
tookus!!!

tom

>
>
>   IIUC, the EEPROM data for the simulator in AVR Studio is read from
> the .eep file, which does exist, and which does contain the data I
> stored in it in the code (as best I can tell...it also contains some
> extraneous data which I am presuming is formatting data added by AVR
> Studio,which would not be written the the physical EEPROM when the chip
> is programmed).



There isn't any additional "formatting" data.



>   So wy is this code not actually reading the EEPROM data?  not only is
> it not showing up in r0, but using the Watch tool, it is not showing as
> being addressed in EEDR, despite the data addresses appearing as called
> out in EEARL (with EEARH loaded with a 0x00, since I ommly use but 100
> bytes of the EEPROM).


Walk through the sequence, I've used it tons, and it works.
A tip:  Don't use location 0, and make sure that whenever you're not using
the EE, the EEARL and EEARH both contain 0.  This makes accidental writes
more or less harmless.


   ***ARGH*** but learning to use new tools can be such a pain in the
> tookus!!!
>
> tom
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


-- 
Feel the power of the dark side!  Atmel AVR


[Non-text portions of this message have been removed]

I have walked through it, both manually and in the simulator, and it 
isn't loading any data.

   As for formatting data, there is extraneous data in the .eeg file 
that *I* didn't place there.  Here is the .eep file data:

:1000000000000000000000000000000102020303E5
:100010000405060608090A0B0D0E10121416181A0C
:100020001D1F2224272C3034373B3E42464A4E5275
:10003000565A5E63676C7075797E82878C9095994D
:100040009EA3A7ACB0B4B9BDC1C5C9CDD1D4D8DBCE
:10005000DFE2E5E8EAEDEFF2585AF7F9FAFCFDFEC7
:03006000FFFFFFA0
:00000001FF


and here is the code which is generating it...obviously there are values 
in here that *I* didn't place here.

;    this table provides the data for the intensity curve needed for
;    xxxxxxxxxxxxxxx.  the data represent the value sin^3 * 255 for
;    each angle from 0 through 90  at .9 degree increments

    .eseg

TABLE:
    .db    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 2, 3, 3, 4, 5, 6, 6
    .db    8, 9, 10, 11, 13, 14, 16, 18, 20, 22, 24, 26, 29, 31, 34, 36
    .db    39, 44, 48, 52, 55, 59, 62, 66, 70, 74, 78, 82, 86, 90, 94, 99
    .db    103, 108, 112, 117, 121, 126, 130, 135, 140, 144, 149, 153
    .db    158, 163, 167, 172, 176, 180, 185, 189, 193, 197, 201, 205
    .db    209, 212, 216, 219, 223, 226, 229, 232, 234, 237, 239, 242
    .db    344, 346, 247, 249, 250, 252, 253, 254, 255, 255, 255

David VanHorn wrote:

>
> >IIUC, the EEPROM data for the simulator in AVR Studio is read from
> > the .eep file, which does exist, and which does contain the data I
> > stored in it in the code (as best I can tell...it also contains some
> > extraneous data which I am presuming is formatting data added by AVR
> > Studio,which would not be written the the physical EEPROM when the chip
> > is programmed).
>
> Walk through the sequence, I've used it tons, and it works.
> A tip: Don't use location 0, and make sure that whenever you're not using
> the EE, the EEARL and EEARH both contain 0. This makes accidental writes
> more or less harmless.
>

On 1/3/07, Thomas Keller <tjkeller1@alltel.net> wrote:
>
>   I have walked through it, both manually and in the simulator, and it
> isn't loading any data.
>
>   As for formatting data, there is extraneous data in the .eeg file
> that *I* didn't place there.  Here is the .eep file data:
>
> :1000000000000000000000000000000102020303E5
> :100010000405060608090A0B0D0E10121416181A0C
> :100020001D1F2224272C3034373B3E42464A4E5275
> :10003000565A5E63676C7075797E82878C9095994D
> :100040009EA3A7ACB0B4B9BDC1C5C9CDD1D4D8DBCE
> :10005000DFE2E5E8EAEDEFF2585AF7F9FAFCFDFEC7
> :03006000FFFFFFA0
> :00000001FF


Ok, but you're looking at an intel hex file.
There's line numbers, and checksums there.
What ends up in the ee space should be only and exactly what you specify.
Open a new memory window, and point it to the eeprom, and see what you get.

Of course now I'm wondering why this table isn't in code space.
Do you figure on altering it during execution?


[Non-text portions of this message have been removed]

At 12:36 PM 4/01/2007, you wrote:
>    So wy is this code not actually reading the EEPROM data?

1st thing you need to up/download memory (from debug) to have the EEP
file put into eeprom space.
Then the first time around you are filling r16 with 0 and then
decrementing it which points to 0xff. Last EEPROM address is 0x7f
or 128 bytes :)

This is my EEP reading routine, try to find out why yours doesn't
work :)

;Get 1 byte pointed by Z. Data returned in temp
get_ieep_byte:
     out    EEARL,zl   ;Sets up address in EEP
     sbi   EECR,EERE
     in    temp,EEDR   ;Get data
     ret

EEARH also is not used as it is only needed when EEP>256 bytes.
Once I made some small changes to your code I could see the EEP
data into r0.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

At 01:33 PM 4/01/2007, you wrote:
>there is extraneous data in the .eeg file
>that *I* didn't place there.

True the assembler does that for you, it is called an
Intel hex format, when you download it into the simulator
it will all be correct.


Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

Well, I was under the impression that data HAD to be in EEPROM or RAM.  
How woudl you address it if it is in the code space?

David VanHorn wrote:

>
>
> Of course now I'm wondering why this table isn't in code space.
> Do you figure on altering it during execution?
>
>

I don't understand:  "download memory (from debug)" ?????????   What 
does this mean?
tom


John Samperi wrote:

>
> At 12:36 PM 4/01/2007, you wrote:
> > So wy is this code not actually reading the EEPROM data?
>
> 1st thing you need to up/download memory (from debug) to have the EEP
> file put into eeprom space.
> Then the first time around you are filling r16 with 0 and then
> decrementing it which points to 0xff. Last EEPROM address is 0x7f
> or 128 bytes :)
>

On 1/3/07, Thomas Keller <tjkeller1@alltel.net> wrote:

> Well, I was under the impression that data HAD to be in EEPROM or RAM.
> How woudl you address it if it is in the code space?


Table:  .db  $00, $01.....



Read_Table:  ; called with offset in TEMP, output in TEMP
     clr    R0   ; Trashes R0
     ldi   ZL,low(table*2)    ;Point at the table
     ldi   ZH,high(Table*2)
     add  ZL,TEMP           ;Add the offset
     adc  ZH,R0               ;16 bit add
     lpm  ;On smaller AVRs the result is in R0, in larger ones it's
     mov  TEMP,R0       ;lpm TEMP


[Non-text portions of this message have been removed]

At 02:22 PM 4/01/2007, you wrote:
>Well, I was under the impression that data HAD to be in EEPROM or RAM.
>How woudl you address it if it is in the code space?

That's true in a TRUE Harvard architecture. Fortunately
we are not limited to that with MODIFIED Harvard architecture.
Read up on the LPM instruction.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

Ah.    A real world example of the mysterious lpm instruction. Now I 
see how that is used.  Thanks, David.


David VanHorn wrote:

>
> On 1/3/07, Thomas Keller <tjkeller1@alltel.net 
> <mailto:tjkeller1%40alltel.net>> wrote:
>
> > Well, I was under the impression that data HAD to be in EEPROM or RAM.
> > How woudl you address it if it is in the code space?
>
> Table: .db $00, $01.....
>
> Read_Table: ; called with offset in TEMP, output in TEMP
> clr R0 ; Trashes R0
> ldi ZL,low(table*2) ;Point at the table
> ldi ZH,high(Table*2)
> add ZL,TEMP ;Add the offset
> adc ZH,R0 ;16 bit add
> lpm ;On smaller AVRs the result is in R0, in larger ones it's
> mov TEMP,R0 ;lpm TEMP
>
>

On 1/4/07, Thomas Keller <tjkeller1@alltel.net> wrote:
>
>    Ah.    A real world example of the mysterious lpm instruction. Now I
> see how that is used.  Thanks, David.



The part that gets most people, is the multiplication of the table address
by two, but when you see that the AVR stores words instead of bytes, it all
makes sense.  The LSB selects which byte you get, and acts as if it were an
address bit directly.


[Non-text portions of this message have been removed]

Believe me when I say I feel your pain in getting started, but also believe
me: The tools and the processor are not buggy.  They really do work as the
data sheet says. 

I consider myself a fairly advanced AVR programmer in both C and ASM.   Of
all the times I have been stumped by something and finally started to
conclude there was a problem in the processor, I have always, ALWAYS, found
it to be my own mistake.  There are definitely bugs in the AVR chips, but I
have never actually run across one in my own code.  Still it is wise to keep
up on the errata sheets for the chip you are using.

The tools are a different story: sometimes the Atmel tools can be a
nightmare, but mostly they work as advertised - just make sure you review
the errata before charging off.

-- my plug for using C compilers ---

"First get it working, then optimize." 

All compilers have code generation issues.  But, in response to the C code
generation issue: who cares?  If writing and debugging in C goes 10x faster
and allows the coder to visualize and code more effective algorithms and
makes it easy to abstract the algorithms so they can be used in more places,
then the resulting application will be smaller and faster than the
equivalent assembly code - and be more correct and be done sooner.  Once the
program is working, then, if necessary, one can go back and look for
optimizations.  Something that is difficult to do with assembly code.  

There have been times, I'll admit, when I find it faster to write a small
routine in asm rather than torture the C compiler to do what I want - that
is why it is always good to have a working knowledge of the underlying
machine architecture in embedded projects.  But those times are getting
pretty scarce in my work.

The only problem I have with C is that it is too easy to add functionality
to a project...

Cheers!

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Thomas Keller
Sent: Thursday, January 04, 2007 7:18 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] *sigh*

    Ah.    A real world example of the mysterious lpm instruction. Now I 
see how that is used.  Thanks, David.


David VanHorn wrote:
>
> On 1/3/07, Thomas Keller <tjkeller1@alltel.net 
> <mailto:tjkeller1%40alltel.net>> wrote:
>
> > Well, I was under the impression that data HAD to be in EEPROM or RAM.
> > How woudl you address it if it is in the code space?
>
> Table: .db $00, $01.....
>
> Read_Table: ; called with offset in TEMP, output in TEMP
> clr R0 ; Trashes R0
> ldi ZL,low(table*2) ;Point at the table
> ldi ZH,high(Table*2)
> add ZL,TEMP ;Add the offset
> adc ZH,R0 ;16 bit add
> lpm ;On smaller AVRs the result is in R0, in larger ones it's
> mov TEMP,R0 ;lpm TEMP
>
>



 
Yahoo! Groups Links