avr-gcc-list
[Top][All Lists]
Advanced

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

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


From: David Brown
Subject: [avr-gcc-list] Re: [Fwd: Re: Allocating variables to a fixed address]
Date: Tue, 12 May 2009 16:16:56 +0200
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

Robert von Knobloch wrote:
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
Jan,

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

David,
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
correct?

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,

Robert

I've often heard of problems with FTDI chips, and especially their drivers, but I've found them solid and reliable (except for their demo code for PC software, which is rubbish). The example I gave of sending multiple megabytes at over 1 MBaud is using FTDI devices.

But no matter what you are using for transferring your serial data, you should have a system for error checking and retrying in place - you can never consider such a link as 100% reliable.





reply via email to

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