AVR-Chat

***ALRIGHT***   It's working!!!!!!!!!

  Thanks, guys.   It turned out I had three problems, one of which was 
in my debug routine (*doh*).  The biggest problem, however, was that I 
had miscounted in my interrupt vector table, and it wasn't doing what I 
thought it was.  *SHEEEESH*

   THANKS, to all of you, for the patience and assistance.  I am learning.


tom

On 1/18/07, Thomas Keller <tjkeller1@alltel.net> wrote:
>
>
> ***ALRIGHT***   It's working!!!!!!!!!


YAY!  :)


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

That is why I have adopted the practice of installing a
full vector table, with all the standard labels and filling
the unused ones with RETI or jump to an error handler.

Congrats,
Jim

On Thu, 18 Jan 2007 05:43:12 -0600
 Thomas Keller <tjkeller1@alltel.net> wrote:
> 
>   ***ALRIGHT***   It's working!!!!!!!!!
> 
>   Thanks, guys.   It turned out I had three problems, one
> of which was 
> in my debug routine (*doh*).  The biggest problem,
> however, was that I 
> had miscounted in my interrupt vector table, and it
> wasn't doing what I 
> thought it was.  *SHEEEESH*
> 
>    THANKS, to all of you, for the patience and
> assistance.  I am learning.
> 
> 
> tom

---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

On 1/18/07, Jim Wagner <jim_d_wagner@applelinks.net> wrote:
>
> That is why I have adopted the practice of installing a
> full vector table, with all the standard labels and filling
> the unused ones with RETI or jump to an error handler.


The only way to fly!  :)
I've always done this, or a close variant.

In some apps, I've used a jump to a "halt and DONT catch fire" routine,
where the app controlled things that could easily get nasty if left on too
long. This routine safeties the outputs, and then sits in a loop.

My templates all have ISRs that turn off that particular int.  I start my
apps with this, and then change the ones I want to use into real ISRs, and
if I get squeezed for code space then I might change the turnoffs to simpler
versions, or to RETIs.

I dont' believe in EVER writing without a fully implemented vector table
though.


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

Absolutely!   I had a fully implemented interrupt vector table, I had 
miscounted and had some rjmps where there ought to have been some 
reti's, and vice  versa.  my interrupt vector table template will be 
receiving full commentary TODAY to insure that this never happens again!

(and, to complicate things,  the debug routine I had written to show me 
which interrupt was being called didn't work either *doh*).

Micro Brix wrote:

>
> On 1/18/07, Jim Wagner <jim_d_wagner@applelinks.net 
> <mailto:jim_d_wagner%40applelinks.net>> wrote:
> >
> > That is why I have adopted the practice of installing a
> > full vector table, with all the standard labels and filling
> > the unused ones with RETI or jump to an error handler.
>
> The only way to fly! :)
> I've always done this, or a close variant.
>
> In some apps, I've used a jump to a "halt and DONT catch fire" routine,
> where the app controlled things that could easily get nasty if left on too
> long. This routine safeties the outputs, and then sits in a loop.
>
> My templates all have ISRs that turn off that particular int. I start my
> apps with this, and then change the ones I want to use into real ISRs, and
> if I get squeezed for code space then I might change the turnoffs to 
> simpler
> versions, or to RETIs.
>
> I dont' believe in EVER writing without a fully implemented vector table
> though.
>
>

On 1/18/07, Thomas Keller <tjkeller1@alltel.net> wrote:
>
>   Absolutely!   I had a fully implemented interrupt vector table, I had
> miscounted and had some rjmps where there ought to have been some
> reti's, and vice  versa.  my interrupt vector table template will be
> receiving full commentary TODAY to insure that this never happens again!
>
> (and, to complicate things,  the debug routine I had written to show me
> which interrupt was being called didn't work either *doh*).



It's always more fun when there are multiple problems to solve.
Divide and conquer!


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

That is why I use C.  My time is way more valuable than processor time or
space.

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Jim Wagner
Sent: Thursday, January 18, 2007 7:59 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] *HAHAHA*

That is why I have adopted the practice of installing a
full vector table, with all the standard labels and filling
the unused ones with RETI or jump to an error handler.

Congrats,
Jim

Larry,

    Not wishing to start a language war here, but I have to say that I 
have looked at doing C on the AVR, and frankly, it looks nastier than 
working in assembler.   I have vast experience in C programming on both 
the Winblows and *nix platforms, as well as others, and I love C.   I 
find the twists and turns and processor specific details so painful when 
working with C on a uC that I find assembler more reasonable (unless i 
need floating point math, or transcendental math, or something like that).

   Besides, particularly when working with a new processor, I like 
working at the assembly level, as it forces me to develop an intimate 
understanding of the hardware and the architecture, which is invaluable, 
regardless of what level language you eventually code in.

tom
(Your <insert unit of common distance measurement here> may vary
larry barello wrote:

>
> That is why I use C. My time is way more valuable than processor time or
> space.
>
> _,_._,___

re the below - Yes! I did asm on the AVR for a small project to get
the feel for the flash vs. RAM architecture and the
registers/addressing modes. But this was a small effort. Following
lots of examples from others' work. 

I found that using WinAVR (GCC) with the AVR is best done AFTER you
use one of the commercial C compilers, perhaps in their free demo mode
for a small project. This is because these compilers (I really liked
Codevision AVR) have easy to learn/use pragmas for putting data in
flash vs. RAM and accessing them. It is quite true that even a simple
printf()  requires attention to where the data is (RAM vs Flash). But
unlike GCC  for the AVR, the commercial compilers tend to make this
much more transparent and easy to do. 

After a project or two, doing C on the AVR will become straightforward
and intuitive. It's a problem if you work on AVRs only intermittently
and forget things.

You shouldn't come into C on the 8 bit micros like the AVR expecting
the convenience of the OS environment on PCs or $500 embedded processors.

If you can't warp your brain to deal with both the von Neuman and
Harvard architectures, stick with the 8051s!


--- In AVR-Chat@yahoogroups.com, "Micro Brix" <microbrix@...> wrote:
>
> On 1/18/07, Thomas Keller <tjkeller1@...> wrote:
> >
> > Larry,
> >
> >    Not wishing to start a language war here, but I have to say that I
> > have looked at doing C on the AVR, and frankly, it looks nastier than
> > working in assembler.   I have vast experience in C programming on
both
> > the Winblows and *nix platforms, as well as others, and I love C.   I
> > find the twists and turns and processor specific details so
painful when
> > working with C on a uC that I find assembler more reasonable (unless i
> > need floating point math, or transcendental math, or something
like that).
> >
> >   Besides, particularly when working with a new processor, I like
> > working at the assembly level, as it forces me to develop an intimate
> > understanding of the hardware and the architecture, which is
invaluable,

> > regardless of what level language you eventually code in.
> 
> 
> 
> Hmm.. A kindred spirit!
> 
> 
> [Non-text portions of this message have been removed]
>

This is where the line lables (as suggested in the device
 data sheet) really help.

Jim

On Thu, 18 Jan 2007 11:12:46 -0600
 Thomas Keller <tjkeller1@alltel.net> wrote:
>    Absolutely!   I had a fully implemented interrupt
> vector table, I had 
> miscounted and had some rjmps where there ought to have
> been some 
> reti's, and vice  versa.  my interrupt vector table
> template will be 
> receiving full commentary TODAY to insure that this never
> happens again!
> 
> (and, to complicate things,  the debug routine I had
> written to show me 
> which interrupt was being called didn't work either
> *doh*).
> 
> Micro Brix wrote:
> >
> > On 1/18/07, Jim Wagner <jim_d_wagner@applelinks.net 
> > <mailto:jim_d_wagner%40applelinks.net>> wrote:
> > >
> > > That is why I have adopted the practice of installing
> a
> > > full vector table, with all the standard labels and
> filling
> > > the unused ones with RETI or jump to an error
> handler.
> >
> > The only way to fly! :)
> > I've always done this, or a close variant.
> >
> > In some apps, I've used a jump to a "halt and DONT
> catch fire" routine,
> > where the app controlled things that could easily get
> nasty if left on too
> > long. This routine safeties the outputs, and then sits
> in a loop.
> >
> > My templates all have ISRs that turn off that
> particular int. I start my
> > apps with this, and then change the ones I want to use
> into real ISRs, and
> > if I get squeezed for code space then I might change
> the turnoffs to 
> > simpler
> > versions, or to RETIs.
> >
> > I dont' believe in EVER writing without a fully
> implemented vector table
> > though.
> >
> >   
> 

---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

On 1/18/07, Thomas Keller <tjkeller1@alltel.net> wrote:
>
> Larry,
>
>    Not wishing to start a language war here, but I have to say that I
> have looked at doing C on the AVR, and frankly, it looks nastier than
> working in assembler.   I have vast experience in C programming on both
> the Winblows and *nix platforms, as well as others, and I love C.   I
> find the twists and turns and processor specific details so painful when
> working with C on a uC that I find assembler more reasonable (unless i
> need floating point math, or transcendental math, or something like that).
>
>   Besides, particularly when working with a new processor, I like
> working at the assembly level, as it forces me to develop an intimate
> understanding of the hardware and the architecture, which is invaluable,
> regardless of what level language you eventually code in.



Hmm.. A kindred spirit!


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