SV: SV: SV: [Icc-avr] Bootloader problem
Steven Lose
sl at ecpower.dk
Thu Nov 1 05:06:20 PST 2007
Hi David.
Of cause you should always know what the variables are used fore, but thinking that you know is a source for trouble, the prefix just helps being sure. (Helps me anyway)
I don't follow the "Hungarian notation" in its complete form, but I like the prefix and got so much used to it, that now the variables kind of looking strange to me without it. ;o)
By the way, can you always be sure that the compiler will promote the variable?. All compilers?
Casting them my self make me safer, but it also makes the code less readable at times.
Med venlig hilsen / Best regards / mit freundlichen Grüßen
EC POWER A/S
Steven Lose
Software Ingeniør
Tlf.: +45 87434100
Direkte tlf. +45 58286608
Email: sl at ecpower.dk
www.ecpower.dk
-----Oprindelig meddelelse-----
Fra: icc-avr-bounces at imagecraft.com [mailto:icc-avr-bounces at imagecraft.com] På vegne af David Brown
Sendt: 1. november 2007 12:06
Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this.
Emne: Re: SV: SV: [Icc-avr] Bootloader problem
Steven Lose wrote:
> Hi.
>
> You're right; I'm not a native English speaker too. ;o)
I had guessed that from the Danish address, but I don't think I have
noticed any errors in your writing until now - "I'm not a native English
speaker *either*" :-) Of course, you'd see plenty more errors in my
written Norwegian, even though I've lived here for 15 years.
>
> But an extra cast may be needed in front of tmpLo:
>
> uint8_t tmpLo = RxChar();
> uint8_t tmpHi = RxChar();
> PageAddressHigh = (uint16_t)tmpLo | (((uint16_t) tmpHi) << 8);
>
The extra cast is not necessary (tmpLo will be promoted to uint16_t
automatically - the cast for tmpHi is actually only to make sure you are
using unsigned ints, since the "<< 8" would normally cause the left
argument to be promoted to a signed int). However, if it makes the
working of the code clearer, use it!
> And if this is 1000 lines below the define of PageAddressHigh, you
> might be unsure. "Did I declare it as char or int?" That's why I
> always use letters in front to remind me
>
> Unsigned int uiPageAddressHigh
>
You should always know what your variables are and what they are for
before using them - if you are not absolutely sure of what
PageAddressHigh is, you should look it up before writing the code!
Adding "ui" and similar prefixes is not a convention I like in the
general case - it makes code less readable, and gives you no extra
information that you don't already have. There are certainly cases
where it makes sense, because it makes the code clearer - a prefix of
"p" for pointers is often helpful, and I often use prefixes for
enumerated types ("typedef enum { colourRed, colourBlue, colourGreen }
colours"), and I use prefixes somewhat in gui programming on PC's. In
this, I follow the original "Hungarian notation", rather than the
excessive usage that some people like.
mvh.,
David
> Med venlig hilsen / Best regards / mit freundlichen Grüßen
>
> EC POWER A/S
>
> Steven Lose
>
> Software Ingeniør
>
> Tlf.: +45 87434100
>
> Direkte tlf. +45 58286608
>
> Email: sl at ecpower.dk
>
> www.ecpower.dk
>
> -----Oprindelig meddelelse----- Fra: icc-avr-bounces at imagecraft.com
> [mailto:icc-avr-bounces at imagecraft.com] På vegne af David Brown
> Sendt: 1. november 2007 09:27 Til: Discussion list for ICCAVR and
> ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are
> a member of this. Emne: Re: SV: [Icc-avr] Bootloader problem
>
>
> (Rant - could people please not post hideous html emails on mailing
> lists like this? Plain text email works much better, and makes it
> easier to track attributions and quotations from different posters.)
>
> C does not *execute* from left to right. It *parses* from left to
> right, but the order of expressions within a sequence is not
> guaranteed in any way. The concept to understand here is "sequence
> points". The various expressions and statements of your program are
> separated by these sequence points, and the compiler's generated code
> preserves the order at each point. Thus all source code before a
> sequence point is executed before the given point, and none of the
> code from after that point has run. (Note that we are talking about
> the code's effect on the C virtual machine - optimising can re-order
> or change the code at any time, as long as it *acts* the same in the
> end.)
>
> Important sequence points are the ";" at the end of statements, just
> before a function call or return, and at the && and || operators.
> Other operators do not have sequence points, and there are no
> sequence points when evaluating function parameters.
>
> Thus the code: (A && B) will first evaluate A, then B (assuming that
> A evaluated to non-zero).
>
> However, the code (A + B) can evaluate A first, or B first - the
> order is not determined, as there is no sequence point.
>
> Similarly, foo(A, B) may evaluate A or B first. You might have come
> across this with examples like "foo(i, i++)" being undefined in C,
> since the order of evaluation is not specified.
>
>
> Thus the code: PageAddressHigh = RxChar() + (RxChar() << 8); is
> wrong.
>
> A good way to write this, ensuring that evaluation order is correct
> and is clear from the code, is:
>
> uint8_t tmpLo = RxChar(); uint8_t tmpHi = RxChar(); PageAddressHigh =
> tmpLo | (((uint16_t) tmpHi) << 8);
>
>
> mvh.,
>
> David
>
>
>
>
>
> Steven Lose wrote:
>> Hi Sylvian.
>>
>>
>>
>> C executes from left to right, so #1 will be executes first.
>>
>>
>>
>> Just like this:
>>
>>
>>
>> If( ucCount && --!ucCount)
>>
>> {
>>
>> }
>>
>>
>>
>> Will detect the transition from non zero to zero
>>
>>
>>
>> But, is it readable?
>>
>> I avoid it and make an extra line, then it is clear what happens.
>>
>>
>>
>> Hence you ask, it is not clear what is happening, and then it is
>> best to avoid it.
>>
>> Or as some would says, if you read some code and have to stop at a
>> line and use time to understand what is happening, then it is not
>> clear enough.
>>
>>
>>
>> Med venlig hilsen / Best regards / mit freundlichen Grüßen
>>
>> *EC POWER A/S*
>>
>> *Steven Lose*
>>
>> Software Ingeniør
>>
>> Tlf.: +45 87434100
>>
>> Direkte tlf. +45 58286608
>>
>> Email: sl at ecpower.dk <blocked::mailto:bsl at ecpower.dk>
>>
>> www.ecpower.dk <http://www.ecpower.dk>
>>
>> ------------------------------------------------------------------------
>>
>>
>> *Fra:* icc-avr-bounces at imagecraft.com
>> [mailto:icc-avr-bounces at imagecraft.com] *På vegne af *Sylvain
>> Bissonnette *Sendt:* 1. november 2007 03:44 *Til:* Discussion list
>> for ICCAVR and ICCtiny Users. You do NOT
>> needtosubscribetoicc-announce if you are a member of this. *Emne:*
>> Re: [Icc-avr] Bootloader problem
>>
>>
>>
>> Hi Rodney,
>>
>>
>>
>> Thanks for your email that can not be more clear! a last question,
>> if I have
>>
>>
>>
>> PageAddressHigh = RxChar() + (RxChar() << 8);
>>
>> #1 #2
>>
>>
>>
>> witch one of the 2 RxChar() will be execute first?
>>
>>
>>
>> Thanks
>>
>> Sylvain
>>
>>
>>
>>
>>
>> ----- Original Message -----
>>
>> *From:* Rodney Pearson <mailto:rodney at junipersys.com>
>>
>> *To:* Discussion list for ICCAVR and ICCtiny Users. You do NOT
>> needtosubscribeto icc-announce if you are a member of this.
>> <mailto:icc-avr at imagecraft.com>
>>
>> *Sent:* Wednesday, October 31, 2007 9:01 AM
>>
>> *Subject:* RE: [Icc-avr] Bootloader problem
>>
>>
>>
>> Sylvain -
>>
>>
>>
>> To repeat what John mentioned in his email and to answer your
>> question:
>>
>>
>>
>> 1 - Make a copy of init.s (found in ICCAVR/libsrc.avr). Name it
>> something like 'initboot.s'
>>
>> 2 - Make a copy of the appropriate crtbootXXX.s file based on the
>> device (found in ICCARV/libsrc.avr). Name it whatever makes sense.
>>
>> 3 - Edit the new crtboot.s file to include the 'initbot.s'
>>
>> 4 - Edit the 'initboot.s' to only set up the HW & SW stack
>> pointers. Remove unneeded code.
>>
>> 5 - Open the new crtboot.s (if not already open) in ICCAVR
>>
>> 6 - Go to File->Compile File->Start Up File to Object. This will
>> gernerate a new *.o library with the same name as the crtboot.s
>> file.
>>
>> 7 - Copy the new startup library to the library directory
>> (ICCAVR/lib)
>>
>> 8 - You will need to tell the compiler to use the new startup
>> library when building the bootloader:
>>
>> A - Go to Compiler Options->Target->Advanced->Non-default Startup
>>
>> B - Enter in the name of the new startup library (include the .o
>> extension)
>>
>> C - Perform a "Rebuild All" to force the compiler to perform a
>> clean build and use the new library (not technically necessary, but
>> I've found that the
>>
>> compiler will sometimes not use the new library until it needs to
>> perform a clean build.)
>>
>> 9 - You should be good to go.
>>
>> 10 - You can verify that the new startup library code is included
>> by looking at the output listing and comparing it the changes you
>> made in the 'initboot.s' file
>>
>>
>>
>> See the ICCAVR help "Startup File" for a bit more explanation on
>> the startup code and how to use it.
>>
>>
>>
>> Cheers!
>>
>>
>>
>> Rodney Pearson
>>
>> Software Engineer
>>
>> Juniper Systems, Inc.
>>
>> www.junipersys.com
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> *From:* icc-avr-bounces at imagecraft.com
>> [mailto:icc-avr-bounces at imagecraft.com] *On Behalf Of *Sylvain
>> Bissonnette *Sent:* Tuesday, October 30, 2007 5:47 PM *To:*
>> Discussion list for ICCAVR and ICCtiny Users. You do NOT
>> needtosubscribetoicc-announce if you are a member of this.
>> *Subject:* Re: [Icc-avr] Bootloader problem
>>
>>
>>
>> Hi Rodney,
>>
>>
>>
>> Hmmm, it's 256 word, 256k for a bootloader is a little big, If I
>> modify the init.s what I must do to say to the
>>
>> compiler to use my init.s and not the original one?
>>
>>
>>
>> Thanks
>>
>> Sylvain
>>
>> ----- Original Message -----
>>
>> *From:* Rodney Pearson <mailto:rodney at junipersys.com>
>>
>> *To:* Discussion list for ICCAVR and ICCtiny Users. You do NOT
>> needtosubscribeto icc-announce if you are a member of this.
>> <mailto:icc-avr at imagecraft.com>
>>
>> *Sent:* Tuesday, October 30, 2007 4:37 PM
>>
>> *Subject:* RE: [Icc-avr] Bootloader problem
>>
>>
>>
>> Hi Sylvain -
>>
>>
>>
>> I'm assuming you meant 256 bytes, not 256k? (words? Bytes?)
>>
>>
>>
>> Either way you can save space in the start up file be removing the
>> code that initializes the memory of SRAM (assuming you are not
>> using SRAM in the same manner as "normal" application code). Take
>> a look in the init.s startup file - that is where the
>> initialization code is located. It is in Assembly.
>>
>>
>>
>> Cheers!
>>
>>
>>
>> Rodney Pearson
>>
>> Software Engineer
>>
>> Juniper Systems, Inc.
>>
>> www.junipersys.com
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> *From:* icc-avr-bounces at imagecraft.com
>> [mailto:icc-avr-bounces at imagecraft.com] *On Behalf Of *Sylvain
>> Bissonnette *Sent:* Tuesday, October 30, 2007 3:42 PM *To:*
>> Discussion list for ICCAVR and ICCtiny Users. You do NOT
>> needtosubscribetoicc-announce if you are a member of this.
>> *Subject:* [Icc-avr] Bootloader problem
>>
>>
>>
>> Hi,
>>
>>
>>
>> I'm currently working on my MegaLoad bootloader and I want to fit
>> this one in 256k size. when compiling
>>
>> I get not large enough... I need only couple of byte more. I don't
>> use any interrupt, is there some way to
>>
>> get a bit more maybe in the startup file? but I never had work with
>> the startup and I don't really now how
>>
>> to do this. Any help will be welcome.
>>
>>
>>
>> Thanks
>>
>> Sylvain Bissonnette
>>
_______________________________________________
Icc-avr mailing list
Icc-avr at imagecraft.com
http://dragonsgate.net/mailman/listinfo/icc-avr
More information about the Icc-avr
mailing list