SV: SV: [Icc-avr] Bootloader problem

[David Brown]

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
>>