Re: USB Boarduino on AVR-Ada Tutorial

["b.robinson.jp@gmail.com" <b.robinson.jp@gmail.com>]

Thanks for the suggestion.

I do have the right chip number (I verified it on the surface of the
IC too), and I do have the right IO port and pin number (verified with
the C program).  The C version compiles and runs as expected, so I
think I'm going to have to study the bootstrapping process and get my
hands wet.

On Aug 27, 8:51 am, Warren <ve3...@gmail.com> wrote:
> b.robinson...@gmail.com expounded in news:1db702dd-3289-4e76-98fe-
> 08ab4bae3...@v8g2000yqe.googlegroups.com:
>
> >>.. I was able to
> > compile the project and generate my binary.  The LED stays lit and
> > does not flash, but at least I have something to work on now. :)
>
> Check that you have exactly the right part specified for
> compiling the unit. What happens is that the object code
> may be compatible, but the configured SRAM size is not. This
> is critical in the main program, where it initializes the
> stack pointer (SP) at startup.
>
> I ran into this when building for atmega328, which supports
> a 2K SRAM. I was using an atmega168 with a 1K SRAM instead,
> but is otherwise completely compatible with the 328.  
>
> So everything would work until you _called_ something. The
> called routine might work (if it needed no local vars or kept
> them in registers). But when it would try to return to the
> calling program, it would go west. Building for the 328
> sets the SP 1K higher than the 168 address wise, where
> there is no SRAM. So a return would go to address 16#FFFF#,
> since FF is what "no memory" returns.
>
> Compiling _libraries_ for a bigger part is ok, since it
> doesn't have to initialize the SP.  But the main program
> has to be "right on" in this respect.
>
> In your case, I suspect that the delay routine is not
> returning properly. This strongly hints at the stack
> size problem. So check that MCU= parameter (I had to
> get a magnifying glass out to read my chip).
>
> Warren