memory redirection / memory mapped external access

lpcware · ‎06-15-2016

Content originally posted in LPCWare by RA1981 on Sat Sep 03 03:44:32 MST 2011
Hi,

I wonder if it's possible to access external devices as if they are internal memory locations.
I know some 8-bit MCU compilers where it's possible to have a additional "memory type" byte. This byte is used as a address extension. Because most 8-bit MCUs have different instructions for accessing code and data memory the address extension is used to determine which instructions have to be used.
This approach enables the developer to create "virtual" memory regions. For accesses to one of these non-predefined memory regions the compiler calls user-defined access functions, where the address extension byte defines which functions have to be called.

So, what's the advantage? For example, if the MCU has a internal EEPROM, access is usually done via modifying some special function registers, etc. Of course it's possible to write some access functions which deal with the register access, but the developer always have to take care about (at least) the address.
Using the above mentioned "virtual" memory and user-defined access functions enables the developer to create a variable in that memory region, but it can be handled like any other variable. The linker takes care of the address, etc. When accessing this variable the user defined access function is called and deals with the access - totally hidden from the developer. And, usually no pointer accesses could be done to such EEPROM contents. The above approach also enables pointer access, which is a big benefit in my opinion.
Another advantage is, when porting the software to a "smaller" MCU with non-internal, but external EEPROM, the access functions could be modified or new ones are created for a different memory region and the variables are moved to that region.

Is this possible in GCC/LPCxpresso?

Regards,

Ralf

lpcware · ‎06-16-2016

Content originally posted in LPCWare by RA1981 on Mon Sep 05 09:18:14 MST 2011
Hi,

Quote: igorsk
I don't think existing ARM compilers support user hooks for accessing memory. The best solution I can think of is to allocate a non-existing memory range for your variables and handle the accesses in the HardFault handler. This probaly won't be very performant, however.

Yes, that's one solution I thought about. If I find a (acceptable) performant way to it with the HF handler, I might try to implement it.

That said, do you really need this functionality? Modern chips are not that memory constrained, and if you need non-volatile storage, you can make a simple wear-leveling scheme for the internal flash - this was discussed on this forum before.
I don't really need it yet, but it was a nice feature on my 8-bit MCU projects. The mentioned EEPROM was just a example, it's also applicable to other (external) devices/peripherals.

Quote: atomicdog
GCC doesn't support that yet as far as I can tell. Eventually GCC will probable support 'C - Extensions to support embedded processors TR18037' which has that ability.

I'll take a look at it, thank you.

What do you generally think about it? As I said above, it was a nice feature and I think it makes code more readable because you see these "special" variables like any other variables.

Regards,

Ralf

lpcware · ‎06-15-2016

Content originally posted in LPCWare by atomicdog on Fri Sep 16 11:18:59 MST 2011

Quote: RA1981
...
I assume it means IDEs like eclipse, right? Are there any ready-to-use packages available?

I was about to say no but I just did a quick search and I found this eclipse plugin. I haven't tried it yet though. clang is still X86 centric so the plugin might not do cross-compiling very well or at all.

Quote: RA1981

Is it possible to get the LPCxpresso interfaces running with the clang compiler? I assume not, I think it's property of CodeRed, right? So only way to get the software onto the boards will be the internal bootloader, right?

clang is supposed to behave as a drop in replacement for gcc (for the most part). It should be possible but I don't know if it would violate the LPCxpresso user agreement.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by RA1981 on Fri Sep 16 04:34:17 MST 2011

Quote: atomicdog
clang is an open source compiler like GCC.

Ah, okay.

I took a look at the website, there's the following statement:

Quote:
Allow tight integration with IDEs

I assume it means IDEs like eclipse, right? Are there any ready-to-use packages available?

Is it possible to get the LPCxpresso interfaces running with the clang compiler? I assume not, I think it's property of CodeRed, right? So only way to get the software onto the boards will be the internal bootloader, right?

Regards,

Ralf

lpcware · ‎06-15-2016

Content originally posted in LPCWare by atomicdog on Wed Sep 14 13:49:00 MST 2011

Quote: RA1981
Sorry for the late reply.

What is the clang compiler? :)

Regards,

Ralf

clang is an open source compiler like GCC.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ktownsend on Wed Sep 14 13:42:57 MST 2011
Have you looked at SPIFI in the new LPC1850 and LPC4350? This is basically what it does, taking the external quad flash memory and mapping it to the ARM address space so that you can read from it like it was internal memory, including executing code from it, using pointers, etc. (and the speed is actually pretty impressive compared to using the internal flash when you keep in mind what's being done behind the scenes).

It's not a generic solution that covers everything you want, and the address space is read only (to program is you need to go through a ROM-based API since you need to take into account the page/sector sizes, etc.) ... but an interesting idea anyway considering how ridiculously cheap quad-spi flash is thanks to use in desktop/laptop PCs. You can get 16MBit for ~$1 these days.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by RA1981 on Wed Sep 14 13:14:12 MST 2011
Sorry for the late reply.

Quote: atomicdog
Not for GCC but the clang compiler though.

What is the clang compiler? :)

Regards,

Ralf

lpcware · ‎06-15-2016

Content originally posted in LPCWare by atomicdog on Mon Sep 05 11:22:50 MST 2011

Quote: RA1981
Hi,

I'll take a look at it, thank you.

What do you generally think about it? As I said above, it was a nice feature and I think it makes code more readable because you see these "special" variables like any other variables.

Regards,

Ralf

I like the feature. I think it would make code more readable, portable, and easier to write. This is actually on my to-do-list. Not for GCC but the clang compiler though. I plan on trying to add some feature like this that are in TR18037 to clang for the ARM and AVR targets.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by atomicdog on Mon Sep 05 08:03:56 MST 2011

Quote:
Do you know a way to tell the compiler that variables of such a section have to be accessed by a user defined function?

GCC doesn't support that yet as far as I can tell. Eventually GCC will probable support 'C - Extensions to support embedded processors TR18037' which has that ability.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by igorsk on Mon Sep 05 04:59:35 MST 2011
I don't think existing ARM compilers support user hooks for accessing memory. The best solution I can think of is to allocate a non-existing memory range for your variables and handle the accesses in the HardFault handler. This probaly won't be very performant, however.

That said, do you really need this functionality? Modern chips are not that memory constrained, and if you need non-volatile storage, you can make a simple wear-leveling scheme for the internal flash - this was discussed on this forum before.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by RA1981 on Sun Sep 04 22:13:31 MST 2011
Hi John,

Quote: atomicdog
I believe you can do this by modifying the linker scripts and using the section attribute

Ah, thank you. Section attribute is a good approach, for the above example it would be simply a section "EEPROM".
Do you know a way to tell the compiler that variables of such a section have to be accessed by a user defined function?

Regards,

Ralf

lpcware · ‎06-15-2016

Content originally posted in LPCWare by atomicdog on Sat Sep 03 15:39:12 MST 2011
I believe you can do this by modifying the linker scripts and using the section attribute.