Yahoo Groups archive
Messages
Page 135 of 307 · 15341 messages matched
2007-01-04 by Don AE5K
Thomas Keller wrote: > Well, Well. That solved the problem nicely. > > It turns out my debugger thought it was running an ATtiny13, not the > ATtiny25. *!!* > > Inexperience in using the AVR Studio tool was the culprit all along > (thanks Don). > > tom I'm glad that my last minut
2007-01-04 by John Samperi
I have taken the liberty to rearrange your code to my liking :) this will fetch the last data byte correctly. Also watch out your use of r16 as it is also defined as temp. .include "tn25def.inc" ; Define here the variables ; .def temp =r16 .cseg ; Define here Reset and interrupt
2007-01-04 by David VanHorn
On 1/3/07, Thomas Keller wrote: > > > OK. I figured out wqhat up/downloading memory was in AVR Studio. Now, > I can see my EEPROM data when I do a memory watch. It still isn't > coming in to my data resgister when I read it, though )-:. Step it through, and see what it IS loading
2007-01-04 by John Samperi
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. R
2007-01-04 by Thomas Keller
OK. I figured out wqhat up/downloading memory was in AVR Studio. Now, I can see my EEPROM data when I do a memory watch. It still isn't coming in to my data resgister when I read it, though )-:.
2007-01-04 by David VanHorn
On 1/3/07, Thomas Keller 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
2007-01-04 by Thomas Keller
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 >
2007-01-04 by Thomas Keller
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? > >
2007-01-04 by John Samperi
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 ****************
2007-01-04 by John Samperi
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 poin
2007-01-04 by David VanHorn
On 1/3/07, Thomas Keller 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: > > :100000000000000
2007-01-04 by Thomas Keller
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 :1000100004050606080
2007-01-04 by David VanHorn
> > > 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
2007-01-04 by Thomas Keller
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 s
2007-01-04 by David VanHorn
On 1/3/07, Thomas Keller wrote: > > Well, Well. That solved the problem nicely. > > It turns out my debugger thought it was running an ATtiny13, not the > ATtiny25. *!!* I've often wondered why you have to tell studio what chip you're using given that there's all the information
2007-01-04 by Thomas Keller
Well, Well. That solved the problem nicely. It turns out my debugger thought it was running an ATtiny13, not the ATtiny25. *!!* Inexperience in using the AVR Studio tool was the culprit all along (thanks Don). tom
2007-01-03 by David VanHorn
> > > I have a go at C once a year or so but then I give up. > I have purchased a small graphic LCD and promised myself > that I would program it in C as I may be able to get some > libraries. So far work has got in the way as I'm absolutely > snowed under, so no play time :( I k
2007-01-03 by John Samperi
At 08:35 AM 4/01/2007, you wrote: >that should be THREE instructions, not >30!" Ah yes but then C compilers *OPTIMIZE* your code by removing large chunks of it because it think you don't really need it :-D I have a go at C once a year or so but then I give up. I have purchased a
2007-01-03 by David VanHorn
> > > If you can use C (I can't) then install WinAvr as it is now > integrated with Studio. It you want to stay with assembler > then you will get as much help as you need here or on > AVRFreaks.net. Once you get your learner's wheels off your bike > you will be flying. Personall
2007-01-03 by David VanHorn
On 1/3/07, John Samperi wrote: > > At 07:10 AM 4/01/2007, you wrote: > >Now, if Studio can handle multiple files I'll really be pleased.... > > It does with assembler :) :) I could not live without that. But > looks like you have been pouched by the darC side :-D :) Indeed. I pre
2007-01-03 by John Samperi
At 07:10 AM 4/01/2007, you wrote: >Now, if Studio can handle multiple files I'll really be pleased.... It does with assembler :) :) I could not live without that. But looks like you have been pouched by the darC side :-D Regards John Samperi **************************************
2007-01-03 by John Samperi
At 01:42 AM 4/01/2007, you wrote: >I am an experienced programmer, and a huge fan of the AVR Nice to know, on BOTH counts. It looked like you were some young learner at one stage trying to byte more than you could chew :) If you can use C (I can't) then install WinAvr as it is no
2007-01-03 by larry barello
Why are you even messing with asm right now? It seems to be causing you a fair amount of grief. I downloaded Atmel Studio 4.0 and the service pack (->4.498), created a new GCC project (downloaded and installed WinAvr), created the new project, added some code, hit build and run a
2007-01-03 by stevech@san.rr.com
stack underflow? ----- Original Message ----- From: Thomas Keller Date: Wednesday, January 3, 2007 6:59 am Subject: Re: [AVR-Chat] *AHA* To: AVR-Chat@yahoogroups.com > OOPS. Quite right, as several people have pointed out. yet, when > I > changed my RAMEND to 0x7f, that problem w
2007-01-03 by Thomas Keller
Quite right, John. I haven't yet completed the code for the timer and the interrupt handler for the timer, which will sequence through the table. I tend to develop code in steps, and test as I go, to simplify debugging. (NOTE: I am an experienced programmer, and a huge fan of the
2007-01-03 by Thomas Keller
OOPS. Quite right, as several people have pointed out. yet, when I changed my RAMEND to 0x7f, that problem went away. How very odd. John Samperi wrote: > > At 02:50 PM 3/01/2007, you wrote: > >RAMEND value iin tn25def.inc is incorrect. I checked > >it, and it has a decimal value
2007-01-03 by John Samperi
Works perfectly here, just checked it again. Try reassembling again (build and run) I should add that the program seems to be getting just 1 byte of data from the table before landing and stopping on DONE instead of the 99 bytes it is suppose to read (??) Regards John Samperi ***
2007-01-03 by John Samperi
At 02:32 PM 3/01/2007, you wrote: >some strnage >values, such as 0xdd, when the first rcall is executed. Again perfectly normal, 0xdf (ramend) -2 bytes of the return address takes you to 0xdd >the code returns to address >0x0000. Works perfectly here, just checked it again. Try r
2007-01-03 by John Samperi
At 02:50 PM 3/01/2007, you wrote: >RAMEND value iin tn25def.inc is incorrect. I checked >it, and it has a decimal value of 223. For memory that is only 128 >bytes long, that is pretty high, eh? NO! that's correct :) . RAMEND is 0xdf (223 decimal) and since ram starts at 0x60 (96
2007-01-03 by David VanHorn
> > > Why would that tn25def.inc RAMEND vlaue be so far off? I hate it when that happens! Typo? [Non-text portions of this message have been removed]
2007-01-03 by Thomas Keller
I found the problem with the failure to return form subroutine. Apparently, the RAMEND value iin tn25def.inc is incorrect. I checked it, and it has a decimal value of 223. For memory that is only 128 bytes long, that is pretty high, eh? I altered my code to load decimal 126 into
2007-01-03 by Thomas Keller
OK. i updated to the latest service pack on AVR Studio, which changed the problems I am having with the stack. Now, when I am simulating it, and I trace the PC and the SP, I get some strange results. The stack pointer is tasking on some strnage values, such as 0xdd, when the firs
2007-01-03 by Thomas Keller
/I don't know, John. I'll go to atmel.com and check. thank you. tom / John Samperi wrote: > > At 09:29 AM 3/01/2007, you wrote: > >and still I get the stack initialization > >error. > > I have just run your code with Studio without any error > of any kind. Do you have the latest
2007-01-03 by John Samperi
At 09:29 AM 3/01/2007, you wrote: >and still I get the stack initialization >error. I have just run your code with Studio without any error of any kind. Do you have the latest Studio version and patches? Regards John Samperi *******************************************************
2007-01-02 by John Samperi
At 10:07 AM 3/01/2007, you wrote: >"Start" is in front of the .eseg directive, and should evaluate to the same >address as "Begin" OK looking at it closely that would be the case. The assembler would start ASSUMING a .cseg (as it is not declared) and will evaluate Start, then swi
2007-01-02 by David VanHorn
> > > Correct! Except that the reset rjmp points to it and Start will > evaluate to 0x0000 being the first byte in EEPROM therefore rjmp > will jump to 0x0000 or to itself at infinitum (oh I spoke Latin :) ) As written in the first message, I disagree. I use this form in my own p
2007-01-02 by John Samperi
At 09:32 AM 3/01/2007, you wrote: >the .eseg directive should result in >this table data being pulled into EEprom Correct! Except that the reset rjmp points to it and Start will evaluate to 0x0000 being the first byte in EEPROM therefore rjmp will jump to 0x0000 or to itself at i
2007-01-02 by John Samperi
At 09:29 AM 3/01/2007, you wrote: >So why is the simulator inissting that the stack is uninitialized? Have you read up about simulator "known issues" or BUGS? It may be just that. May try it out later on today to see what I get. Regards John Samperi ******************************
2007-01-02 by Thomas Keller
Not only is the stack proper initializing, but before it throws the unitialized stack error, the rcall is causing the stack value to be updated as expected from 223 decimal to 221 decimal (0xef to 0xed). so, if the stack is initialized,and the stack value is updating correctly af
2007-01-02 by David VanHorn
Some have objected to this table, but the .eseg directive should result in this table data being pulled into EEprom and not included in the hex that's put in the program memory, so you should be executing ldi r30, ramend as the first instruction. Have you simmed it? ; > RESET: >
2007-01-02 by Thomas Keller
Yes, I jave fixed that, and still I get the stack initialization error. i have used the watch feature of the fdebugger, and in deed, my stack *IS* beingintialized, to the correct value (123 decimal, or 0xdf). So why is the simulator inissting that the stack is uninitialized? John
2007-01-02 by Thomas Keller
Working with the Attiny25 (at25def.inc). Which, according to the data sheet, has no SPH (only 128 Bytes of RAM). David VanHorn wrote: > > I don't see what chip you're working with, but I only see SPL initted, not > SPH. > > > > > ldi r30, RAMEND ; initialize stack pointer > > out
2007-01-02 by John Samperi
At 07:25 AM 3/01/2007, you wrote: >RESET: > rjmp START > >; Program starts here after Reset >; >START: The program ***CANNOT** start here. You are sending the program to an address in EEPROM which contains a TABLE and not executable code, apart from the fact that you ***CANNOT**
2007-01-02 by Zack Widup
I don't know but it looks to me like you're jumping to the table at the start of your program, not to BEGIN. I think your first code line after RESET should be "rjmp BEGIN". Your program is going to try to execute your table as code, and who knows where you will end up? Zack On T
2007-01-02 by David VanHorn
I don't see what chip you're working with, but I only see SPL initted, not SPH. > > ldi r30, RAMEND ; initialize stack pointer > out SPL, r30 What I expect to see, is: ldi TEMP,low(ramend) out spl,TEMP ldi TEMP,high(ramend) out sph,TEMP [Non-text portions of this message have bee
2007-01-02 by Thomas Keller
As far as I can see, I am initializing the stack point to RAMEND, but when i simulate this code, i am getting an uninitialized stack error when the rcall instrcution is hit. Why for? .include "tn25def.inc" ; Define here the variables ; .def temp =r16 ; Define here Reset and inter
2007-01-01 by Ralph Hilton
On Mon, 01 Jan 2007 12:07:37 -0800 you wrote: >I've been lurking for a while now and it seems most of the code used >by the group is C. I'm wondering if anyone dabbles with Bascom, as >I've been fighting a problem using a Mega2560 with a couple of >AT24C512s. My problem is writin
2007-01-01 by Jon & Tammy
Ken Arck wrote: > I've been lurking for a while now and it seems most of the code used > by the group is C. I'm wondering if anyone dabbles with Bascom, as > I've been fighting a problem using a Mega2560 with a couple of > AT24C512s. My problem is writing more than one page (128
2007-01-01 by Jim Wagner
There are BASCOM users on AVRFreaks. Jim On Mon, 01 Jan 2007 12:07:37 -0800 Ken Arck wrote: > I've been lurking for a while now and it seems most of > the code used > by the group is C. I'm wondering if anyone dabbles with > Bascom, as > I've been fighting a problem using a Mega2
2007-01-01 by Ken Arck
I've been lurking for a while now and it seems most of the code used by the group is C. I'm wondering if anyone dabbles with Bascom, as I've been fighting a problem using a Mega2560 with a couple of AT24C512s. My problem is writing more than one page (128 bytes) I can post the Ba