[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avrdude-dev] Cleaning up of avr910.c
From: |
Jan-Hinnerk Reichert |
Subject: |
Re: [avrdude-dev] Cleaning up of avr910.c |
Date: |
Mon, 8 Dec 2003 19:53:15 +0100 |
User-agent: |
KMail/1.5.1 |
On Monday 08 December 2003 19:00, Theodore A. Roth wrote:
> On Mon, 8 Dec 2003, Jan-Hinnerk Reichert wrote:
> > #define show_func_info() \
> > fprintf(stderr, "%s: line %d: called %s()\n", \
> > __FILE__, __LINE__, __FUNCTION__)
> >
> > #define no_show_func_info()
> > -------------------------
> > So, can we remove them now?
>
> I think it's safe to say it has outlived it's usefulness. Rip away.
That's good news.
> > In avr910_write_setup() there is a strange workaround form Ted.
> > Does anyone know if it is still needed or on which programmer
> > firmware this was neccessary.
> > I also believe that sending "y" here is not good, since it is
> > specified to have an argument. However, the AVR910 returns an
> > error and doesn't get the argument ;-(
>
> When I wrote that, the firmware I was using didn't indicate that
> 'y' took an argument. Here's the the firmware code:
Yes, the firmware works like this.
However, there are comments above the code explaining the commands.
These say that "y" takes an argument. The footnote to this command
implies that there are some development boards that actually use this
command.
You could say that Atmel's firmware isn't following their own
specifications, but who cares?
> waitcmd:rcall getc ; while (getc() == ESC) {};
> cpi u_data,0x1b
> breq waitcmd
>
> It should probably just send an 'ESC' instead of the 'y'. I don't
> remember why I used 'y'.
IIRC, I have seen code from Atmel that uses 'ESC' to reset the
programmer.
> > Now, the cosmetic stuff. IMHO, there is too much output when
> > using the AVR910.
> >
> > I don't want to see a list of all supported chips every time I
> > use avrdude. IMHO, it should only be done if no chip is selected
> > or if chip is not supported (or perhaps if verbose is set to some
> > value).
>
> That's fine.
Okay, then.
> > IMHO, a progress indicator for reading signature-bits is
> > confusing, because I haven't requested the read.
>
> That's a side effect of the generic read/write design of avrdude. I
> didn't like it when I saw it, but I don't think it hurts anything.
However, avr_get_cycle_count() doesn't report a progress, so it seems
possible.
/Jan-Hinnerk
- Re: [avrdude-dev] Cleaning up of avr910.c, (continued)
- Re: [avrdude-dev] Cleaning up of avr910.c, E. Weddington, 2003/12/08
- Re: [avrdude-dev] Cleaning up of avr910.c, Jan-Hinnerk Reichert, 2003/12/08
- Re: [avrdude-dev] Cleaning up of avr910.c, E. Weddington, 2003/12/08
- Re: [avrdude-dev] Cleaning up of avr910.c, Jan-Hinnerk Reichert, 2003/12/09
- Re: [avrdude-dev] Cleaning up of avr910.c, E. Weddington, 2003/12/09
- RE: [avrdude-dev] Cleaning up of avr910.c, Alex Shepherd, 2003/12/09
- Re: [avrdude-dev] Cleaning up of avr910.c, Jan-Hinnerk Reichert, 2003/12/09
- Re: [avrdude-dev] Cleaning up of avr910.c, Jan-Hinnerk Reichert, 2003/12/09
- Re: [avrdude-dev] Cleaning up of avr910.c, Jan-Hinnerk Reichert, 2003/12/10
Re: [avrdude-dev] Cleaning up of avr910.c, Theodore A. Roth, 2003/12/08
- Re: [avrdude-dev] Cleaning up of avr910.c,
Jan-Hinnerk Reichert <=