[avr-gcc-list] Re: [Fwd: Re: Allocating variables to a fixed address]
Robert von Knobloch wrote:
Jan Waclawek wrote:
I simply require a way to fix absolutely this jump table in memory.
Whether I write it in C or assembler seems to me to be irrelevant, as is
using an array of pointer to functions, because I still have the problem
of fixing these at absolute addresses.
If anyone knows a way to do this, I would very much appreciate it.
The attachment illustrates what I mean by jumptable in asm, and its usage (see main). Address of .mysection was fixed to 0x00FF by passing it to the linker through avr-gcc (-Wl,--section-start,.mysection=0xFF00).
It of course can be a separate asm file, and the individual lines can be
generated by a handy macro; but those are only unimportant details.
Enjoy! ;-)
JW
Thanks Jan,
This is effectively what I have done, except I used C stubs instead of
assembler:
[.section origin is at 0xff00]
void test_func_1(uint16_t foo)
{
func_1(foo);
}
void test_func_2(uint16_t foo)
{
func_2(foo);
}
Why would the compiler respect assembler any more than my C calls (it
changes the order of them as they are stored in memory, so I cannot
guarantee the address of test_func_1())
If GCC will respect the order of the assembler jumps (and thus the
absolute address) then that is my easiest solution. At the moment I
can't really see any difference between assembler and C here. Or does
someone know better ?
You see I really distrust the compiler now :-)
Robert
Not only can the compiler re-order the function, but it can also use
different sizes for each function (for example, the size may depend on
the number and type of parameters and return type), and it can optimise
the code in different ways (such as by inlining, or by removing unused
functions). The only way in C that you can guarantee the ordering and
consistent offests is to use a table of function pointers.
There are ways to get it sort-of-right, if you want to maximize your
efficiency and avoid the pointer and indirect call. You can use an
optimisation flag to avoid re-ordering the functions (I can't remember
the flag, but now you know it is there, you can look it up!), and
function attributes to force code generation even though the function
appears unused, and to force non-inlined generation. You can then use
some post-processing on the map file and generate a matching interface
file to use in the plugins - with enough unpleasant macros and type
casting, you should be able to produce something that can be used as
normal function calls in the plugin and compile to a call in the main
program. However, it would be a lot of work for very little gain - a
table of function pointers would be very much easier to get right.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Re: [Fwd: Re: Allocating variables to a fixed address]
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. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
