Re: [avr-libc-dev] New pgm_read_ptr() macro?

[Dale Whitfield]

Hi

> > I would also like very much to finally add the FAR macros that Carlos put 
> > together a long time ago, or something very similar. I don't remember if 
> > there was ever any issues with them that need to get resolved, or if there 
> > is basic agreement that these should be added the way they are etc. But I 
> > would like to put the issue to rest and get them added in some fashion.
> 
> I am using Carlos' work daily for more than a year now and there's no issue 
> with it. There might be some functions added - I've written for example a 
> memcmp_PF() for my own purposes.
> 
> Recently, I've summarized some of my experience in 
> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=93874&highlight=
>  . Mostly minor issues, but if I've had that information on hand when I 
> started using the "far FLASH" it would spare me some time and experimentation.
> 
> I've also posted a couple of more pgmspace.h-related remarks in 
> https://savannah.nongnu.org/bugs/?28058 .
> 
> JW
> 
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
> 

Also been using them for more than a year without issues. 

Perhaps also consider, hand-in-hand with this support, some input and
experiences in some of the threads on avrfreaks. There's been some
pretty thorough discussion on it recently.

Some points include:

1) making access to progmem more transparent, in terms of whether its
near or far. The cons are that this carries overhead. Since the macros
work anywhere in progmem, not just far, its easy to just use them
regardless.

2) linker script updates to include a section that handles far progmem.
Large chunks of data ending up in progmem (<64k) will push code up
towards 128k and the resultant issues that go with it. Keeping progmem
data far relieves that situation.

3) Resolving the compiler/linker issues, specifically code generated
when the gs() macro kicks in. Jan, I'm still not convinced its purely a
linker error, more likely a problem with gs() but I didn't get to dig
much further.

Combining 1) and 2) above could be switched by #define to either:
a) put all strings high, rather than low in progmem on devices with
>128k. Then all progmem access would be simple and transparent to the
user. 
b) leave it completely to the user to manage where progmem data ends up.

That said, it will be a staged process which involves getting the
support in first. I would welcome that.

-- 

Regards

Dale