Far pointers revisited

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm aware of some of the far routines available but I would like to just get the significant high byte to a PROGMEM address. I can do this with inline asm, but was wondering if there is an equivalent C form yet?

uint8_t i;
asm volatile("ldi %0, hh8(%1)" : "=a" (i) : "p" (ptrFlash));

Is there a C form of:

i = hh8(ptrFlash);
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely you just use >>8 or something?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Surely you just use >>8 or something?

Using the usual shift methods doesn't seem to work in this case because GCC still sees the pointer as only 16 bits. Casting to 32 bits first doesn't seem to make any difference.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure there is a C way to do it at this point, unless GCC has been fixed.

See the post by "carloslamas" in this thread

https://www.avrfreaks.net/index.p...

The macro he provides will give you a 32bit integer (pointer) that you can then retrieve the high byte from.

[edit]
Looks like what you had is already just a stripped down version of what he does. AFAIK this is the only way to do it right now. So for a more "C" like method, I would just wrap it in a macro. If GCC didn't have this limitation, you would be able to do it with normal shifting, which would be the official "C" way.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the info. I had done some searching around and it wasn't really clear how far GCC had gotten with supporting the larger devices. Didn't really want to put in a bunch of work arounds if a better method was available. I did see reference to a get far address a couple times which must have originated from the link you provided because I couldn't find any official documentation on it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm one of those on the "bleeding edge" of m2560 support in the GCC. When it comes to the m2560, GCC supports code +/- pretty well (there are some gotchas with function pointers, but on the whole it works okay). Support of the PROGMEM constants is a little weaker. Some would say that the PROGMEM stuff is weak already, since other compilers (IAR, ImageCraft, ...) support these constants directly with a simple keyword.

Carlos Lamas' method is what I use in my code and I'm satisfied with it. Never had a need for the top 8 bits of the address, though.

Feel free to PM me for other tips on the m2560, if you need help.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Carlos Lamas' method is what I use in my code and I'm satisfied with it. Never had a need for the top 8 bits of the address, though.

I ported the IAR AES boot loader to GCC and was making the mods for the larger devices since I plan to use it in a Mega2561 application I'm doing. The way the code was already setup it just made it cleaner to just pass the top address with the existing 16bit address.

I don't find the PROGMEM setup that bad to work with really. After briefly evaluating Imagecraft and CV I actually prefer GCC so far.

Thanks,
Mike