Re: [avr-gcc-list] External 256K FLASH - memory pointer

2012-10-01 Thread Richard Weickelt

Hi,


I do not know if there will be any code over head due to C++.
Unfortunately my forte is 'C'. Can I trouble you for some
examples/sample code please? Thank you once again.


Use a 32-bit unsigned integer and a typedef as it has been suggested and 
You're done. It would be foolish to move on to C++ in an existing project.


For fun You can try to translate Your code with avr-g++. It should compile 
and library functions seem to work even without declaring them as extern 
C, but may have side effects. Most of the language core is backward 
compatible to C.


Many stereotypes exist about the inefficiency of C++ and some of them 
contain a grain of truth. Try it Yourself and have a deep look into 
Stroustrup's The C++ programming language, which is worth every cent.


The following code example may look dumb, because it does nothing really 
interesting. But the point is: By defining all those operators manually You 
gain full control over type conversion and You can not mix up internal and 
external addresses. Many operators are missing, so take it as a hint for 
further experiments.


// Everything related to address calculation and conversion
class ExtFlashAddr
{
public:
// ExtFlashAddr myAddr = ExtFlashAddr(0x4711)
inline explicit ExtFlashAddr(uint32_t address = 0);
// Copy constructor
inline ExtFlashAddr(const ExtFlashAddr other);
// ExtFlashAddr myAddr = otherAddr
inline ExtFlashAddr operator=(const ExtFlashAddr other);
// myAddr++
inline ExtFlashAddr operator++();

friend ExtFlashAddr operator+(const ExtFlashAddr, const ExtFlashAddr);

private:
uint32_t addr;
};

inline ExtFlashAddr operator+(const ExtFlashAddr addr1, const ExtFlashAddr 
addr2);


// Access functions
class ExtFlashTools
{
public:
static void read(void* dst, const ExtFlashAddr src, size_t size);
static void erase(const ExtFlashAddr src, size_t size);
static void write(const ExtFlashAddr dst, void const* src, size_t 
size);

};


ExtFlashAddr::ExtFlashAddr(uint32_t address)
{
this-addr = address;
}

ExtFlashAddr::ExtFlashAddr(const ExtFlashAddr other)
{
this-addr = other.addr;
}


ExtFlashAddr ExtFlashAddr::operator=(const ExtFlashAddr other)
{
this-addr = other.addr;
return *this;
}

ExtFlashAddr ExtFlashAddr::operator++()
{
addr++;
return *this;
}

ExtFlashAddr operator+(const ExtFlashAddr addr1, const ExtFlashAddr addr2)
{
return ExtFlashAddr(addr1.addr + addr2.addr);
}


The code above should be optimized away with -Os.

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list


Re: [avr-gcc-list] External 256K FLASH - memory pointer

2012-09-20 Thread Parthasaradhi Nayani
Hello Richard,
Thanks a lot for your suggestion.

Yes we can and it has already been suggested: Define Your own abstract data 
type with an underlying 32 bit integer. You can even overload all operators 
for it to achieve full pointer semantics. But I would not go so far and 
overload the dereferencing operator for readability reasons. The signature for 
Your read function would then look like:

void ReadXFlashBlock (unsigned char* dst, FlashAddress src, unsigned int size);

If templates are Your friends, You can go further and add the value type to 
Your abstract address type.

This way You avoid ugly casting orgies everywhere in Your code and You can not 
mess up integers, internal memory pointers and external flash addresses. Ok, 
these are features of avr-g++, but why not?

I do not know if there will be any code over head due to C++. Unfortunately my 
forte is 'C'. Can I trouble you for some examples/sample code please? Thank you 
once again.

Regards
Nayani___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list


Re: [avr-gcc-list] External 256K FLASH - memory pointer

2012-09-18 Thread Parthasaradhi Nayani


From: Joerg Wunsch j...@uriah.heep.sax.de
To: avr-gcc-list@nongnu.org 
Sent: Tuesday, September 18, 2012 11:21 AM

What's the point?  A pointer is just a 32-bit (or perhaps 24-bit,
in recent AVR-GCC versions) number.

Normally, the point of using a pointer is that the compiler arranges
for you to dereference the pointer automatically, but this memory
being external, not accessible by normal CPU instructions, this cannot
work anyway.  Consequently, you can use the respective integer numbers
by itself (perhaps through some kind of typedef that hints them being
memory addresses).

Thanks for the response. Basically the requirement is to use external serial 
FLASH memory. We wanted large pointer for two things
1. To declare a section and assign variable names which is better than using 
absolute addresses. This is possible.
2. Pass the address to functions which do the reading and writing the memory. 
Given below is an example function prototype we would like to have

void ReadXFlashBlock (unsigned char *destptr, unsigned char *sourceaddr, 
unsigned int noofbytes);

In the above destptr is not an issue but sourceaddr is. If a 32 bit pointer can 
be somehow declared then this will be pretty elegant. If this is not possible 
then the only alternative would be to change the function parameters as shown 
below which is not really elegant.

void ReadXFlashBlock (unsigned char *destptr, long sourceaddr, unsigned int 
noofbytes);
The calling program must treat this long variable as a pointer rather than long 
itself.

Nayani___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list


Re: [avr-gcc-list] External 256K FLASH - memory pointer

2012-09-18 Thread Richard Weickelt

Hi,


If a 32 bit
pointer can be somehow declared then this will be pretty elegant. If this
is not possible then the only alternative would be to change the function
parameters as shown below which is not really elegant.
void ReadXFlashBlock (unsigned char *destptr, long sourceaddr, unsigned int 
noofbytes);


Yes we can and it has already been suggested: Define Your own abstract data 
type with an underlying 32 bit integer. You can even overload all operators 
for it to achieve full pointer semantics. But I would not go so far and 
overload the dereferencing operator for readability reasons. The signature 
for Your read function would then look like:

void ReadXFlashBlock (unsigned char* dst, FlashAddress src, unsigned int size);

If templates are Your friends, You can go further and add the value type to 
Your abstract address type.


This way You avoid ugly casting orgies everywhere in Your code and You can 
not mess up integers, internal memory pointers and external flash addresses. 
Ok, these are features of avr-g++, but why not?


Richard

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list


Re: [avr-gcc-list] External 256K FLASH - memory pointer

2012-09-17 Thread Joerg Wunsch
Parthasaradhi Nayani partha_nay...@yahoo.com wrote:

 I have an external FLASH (serial) of size 256K. I would like t=
 o create a memory section for this memory and have pointers (more than 16 b=
 its) to this memory.

What's the point?  A pointer is just a 32-bit (or perhaps 24-bit,
in recent AVR-GCC versions) number.

Normally, the point of using a pointer is that the compiler arranges
for you to dereference the pointer automatically, but this memory
being external, not accessible by normal CPU instructions, this cannot
work anyway.  Consequently, you can use the respective integer numbers
by itself (perhaps through some kind of typedef that hints them being
memory addresses).

-- 
cheers, Jorg   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list


[avr-gcc-list] External 256K FLASH - memory pointer

2012-09-16 Thread Parthasaradhi Nayani
Hello all,
I have an external FLASH (serial) of size 256K. I would like to create a memory 
section for this memory and have pointers (more than 16 bits) to this memory. 
Can some one help me please?  I am sorry if such a topic has already been dealt 
with, as my googling did not yield the desired result(s). I await your 
suggestions/help and thank you for your time.

 
Regards,
Partha___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list