[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Re: [avr-gcc-list] Allocating variables to a fixed address]

From: Robert von Knobloch
Subject: Re: [Fwd: Re: [avr-gcc-list] Allocating variables to a fixed address]
Date: Tue, 12 May 2009 15:31:02 +0200
User-agent: Thunderbird (X11/20060911)

Jan Waclawek wrote:
>> Why would the compiler respect assembler any more than my C calls 
> Because the compiler knows nothing on assembly language. It simply passes it 
> as a string to the assembler: it does not attempt to parse it (except for the 
> escape sequences), so it has no chance to modify the order of anything.
> On the other hand, a compiler is free to do whatever it wants to do with 
> statements you pass to it: it can reorder and insert voids wherever and 
> whenever it wants. This is the very principle of high level languages: you 
> give up part of control in exchange of increase in convenience. If you want 
> to re-gain control for whatever reason, the best thing to do is to revert to 
> assembler.
> As I said, you can make this a standalone assembler source, if you feel more 
> comfortable with it, and the link it together. The same thing can be done 
> with variables, see attachment - this avoids the need to put all variables 
> into a single struct (to ensure their fixed order); but I don't say this is 
> the best way to do with variables.
> JW

OK, sounds good, If GCC really will leave my assembler alone then that
would be the best way to go.
I am no longer so worried about the variables, although they were my
original concern - I have written helper functions which make them
transparent to the 'other side' and I think this is better practice. All
I need now is the jump table...

>> While it's good practice to design your protocol to handle errors,
you shouldn't be seeing ANY errors wether or not the port is USB.  I'd
look to solving >> that problem.  Are you sure that your baud rate is

Yes, quite sure. This is a known (to me) issue with FDDI USB to serial
chips. If use a level converter and 'proper' RS-232 with the same setup
I never ever get an error. The receive side uses a circular buffer with
high & low water marks and therefore can do 'proper' handshaking.
 It's just that i cannot rely on a modern (cheap) PC having a serial
bus. The errors are only very occasionally, hardly an issue with my data
volumes. They would become a problem if I started transferring large chunks.
Tracking the FDDI down will have to wait.

Many thanks for all your comments, they are really a big help,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]