CEMETECH
Leading The Way To The Future
Login [Register]
Username:
Password:
Autologin:

Don't have an account? Register now to chat, post, use our tools, and much more.
Latest Headlines
» HP Prime Multitouch Graphing Calculator: The Scoop
» More Details on the Casio fx-CP400 Touchscreen Calculator
» Editorial: On Choosing and Shelving Projects
» Presenting Graph3D v4.1, a Color 3D Grapher
Online Users
There are 107 users online: 3 members, 77 guests and 27 bots.
Members: Ashbad, flyingfisch.
Bots: VoilaBot (1), Magpie Crawler (3), VoilaBot (3), Yahoo! Slurp (1), Googlebot (18), MSN/Bing (1).
RSS & Social Media
[t] Follow @cemetech
[t] 'Like' Cemetech
[RSS] News Headlines
[RSS] Latest Posts
SAX
You must log in to view the SAX chat widget
Prizm memory map
» >
    »
» View previous topic :: View next topic  
Author Message
hugh9860


Newbie


Joined: 08 Aug 2012
Posts: 32
Location: London, UK
Posted: 08 Aug 2012 08:45:54 am    Post subject: Prizm memory map
Hello all,

i'm using the PrizmSDK 0.3 (the gcc tool chain) for some Prizm development. AFAIK, the other tools (mini SDK) requires the old Casio compiler. I have had problems with the casio compiler so i prefer not to use it again.

I need to adjust link settings to make more ram available for my app. i tried changing prizm.ld MEMORY like this:

MEMORY
{
/* Loads code at 300000, skips g3a header */
rom (rx) : o = 0x00300000, l = 512k
ram (rwx) : o = 0x08100004, l = 500k
}

This works (so far), i can have a bit more ram for BSS. However the heap is still limited to 128k. Does anyone know the memory map for the device.

So far, i have this info from another document but i don't know whether the numbers are valid for PrizmSDK (because they don't tally with the above).

Flash 32 MB
Flash: 0xA0000000..0xA1FFFFFF (0x80000000..0x81FFFFFF: physically identical, but cacheable)
RAM 2 MB
0xA8000000..0xA81FFFFF (0x88000000..0x881FFFFF: physically identical, but cacheable)
0xA8000000..0xA80287FF: VRAM
0xA80D35D0 : start of main memory
0xA80E3000 : end of main memory
0xA80F0000..0xA815FFFF: system stack (512 kB).
0xA8160000..0xA81DFFFF: add-in stack (512 kB).
0xA81E0000..0xA81FFFFF: heap.

I know that sometimes address areas are duplicated, so some places can have different address for the same region. maybe we have that here.

I know that the heap i likely to be limited to 128k in which case, i might have to code my own heap management of a chunk of ram, once i know the actual layout and arrangement.

thanks for any help,
-- hugh.
Back to top
Tari


Systems Integrator


Joined: 03 Jul 2006
Posts: 2106
Location: Always-winter, Michigan
Posted: 08 Aug 2012 12:07:08 pm    Post subject:
As the one who wrote that linker script, I can hopefully offer some help. Smile

hugh9860 wrote:
This works (so far), i can have a bit more ram for BSS. However the heap is still limited to 128k. Does anyone know the memory map for the device.

So far, i have this info from another document but i don't know whether the numbers are valid for PrizmSDK (because they don't tally with the above).
These numbers look reasonable, but I have no idea what sort of address mirroring happens (or what exactly the MMU is configured to do). I suspect that the ROM region in the linker script is actually a virtual memory mapping to wherever the current addin happens to be in Flash, though.

As for .bss, I don't think anybody's determined what's actually there, nor how much memory is available. If we assume that the memory map you present is correct (albeit missing some mappings), my best guess is that we're pointing the section at the middle of the system stack, which doesn't cause problems because that memory region is grossly oversized for that it's needed for.

hugh9860 wrote:
I know that the heap i likely to be limited to 128k in which case, i might have to code my own heap management of a chunk of ram, once i know the actual layout and arrangement.
The ability to claim extra heap space from the addin stack is something that's been on my list to add to libfxcg for a while, such that you can specify a maximum addition at link-time.
Since libfxcg provides its own malloc function (which currently just calls the malloc syscall), that implementation can be refined to use the additional claimed space as necessary.

Until I (or somebody) put together such a thing, though, I'd suggest grabbing a chunk of stack at startup and managing that as desired.
Code:
#include <fxcg/heap.h>
void *alloca(size_t n);

static heap_t *extra_heap;

void *my_malloc(size_t n) {
    // Do stuff with extra_heap
}

int main() {
    extra_heap = alloca(0x40000);
    do_stuff();
    return 0;
}

_________________


Ask questions the smart way · タリ
Back to top
hugh9860


Newbie


Joined: 08 Aug 2012
Posts: 32
Location: London, UK
Posted: 08 Aug 2012 01:08:25 pm    Post subject:
i like the idea of using alloca, because the stack is above the add-in ram.

however, where is heap.h, im using PrizmSDK 0.3?

-- hugh.
Back to top
Tari


Systems Integrator


Joined: 03 Jul 2006
Posts: 2106
Location: Always-winter, Michigan
Posted: 08 Aug 2012 01:11:20 pm    Post subject:
Oh, my fault there. fxcg/heap.h is new-style header providing the prototype for sys_malloc (the malloc syscall), but then I didn't do anything with it. You can just ignore that line.
_________________


Ask questions the smart way · タリ
Back to top
hugh9860


Newbie


Joined: 08 Aug 2012
Posts: 32
Location: London, UK
Posted: 08 Aug 2012 01:14:23 pm    Post subject:
_alloca undefined at link. Sad

poo.
Back to top
AHelper


LONG LIVE COMICTECH


Joined: 30 Jan 2011
Posts: 1657
Location: Aufhelperstan, Utopian Republic
Posted: 08 Aug 2012 02:05:54 pm    Post subject:
Firstly, the adjustment that you did changes the stack, not the heap. Malloc uses the heap. alloca may be what you want, don't know what it does.

Remember that PrizmSDK is old. These functions are located in libfxcg on github.
_________________
°ᴥ° Get Lucky

<BrandonW> "You don't even want to know what TI Connect does when it's just detecting your calculator...It ACTUALLY ERASES THE SWAP SECTOR on every communication attempt...EVERY SINGLE ATTEMPT...Yes, TI Connect will kill your calculator..What do I have to do to get your attention?!....Such a bloated protocol."
Back to top
hugh9860


Newbie


Joined: 08 Aug 2012
Posts: 32
Location: London, UK
Posted: 08 Aug 2012 02:06:42 pm    Post subject:
ok, i put my own malloc in and, because alloca is missing, i initialise the heap from the stack by delcaring a large automatic array!

eg

main()
{
char heap[256*1024];

initialiseHeap(&heap, sizeof(heap));
...
}


nasty but works. currently i now have 256k for heap. not tried any bigger yet.
Back to top
Tari


Systems Integrator


Joined: 03 Jul 2006
Posts: 2106
Location: Always-winter, Michigan
Posted: 08 Aug 2012 02:10:37 pm    Post subject:
AHelper wrote:
Firstly, the adjustment that you did changes the stack, not the heap. Malloc uses the heap. alloca may be what you want, don't know what it does.

Remember that PrizmSDK is old. These functions are located in libfxcg on github.
It does exactly what I wanted. Should be implemented as a builtin, but we can work around that in a hideous fashion.

Pre-post ninja response:
hugh9860 wrote:
ok, i put my own malloc in and, because alloca is missing, i initialise the heap from the stack by delcaring a large automatic array!
That works too. Actually a little bit cleaner than alloca, or the solution I was going to propose (inline assembly to adjust the stack pointer).

I'd expect alloca to be provided as a builtin (since it needs to be inlined), so either I mucked up the prototype or our GCC build is wonky. I'll have to investigate further.
_________________


Ask questions the smart way · タリ
Back to top
hugh9860


Newbie


Joined: 08 Aug 2012
Posts: 32
Location: London, UK
Posted: 08 Aug 2012 02:11:22 pm    Post subject:
alloca does the same as my hack, but cleaner.

what i really need to do is set the start of my heap to the end of my add-in. then it can use all the headroom of the add-in ram and *then* roll over the old heap space and get anothr 128k.

is there source for crt0.s. also how do i get the latest PrizmSDK from github

thanks,
-- hugh.
Back to top
AHelper


LONG LIVE COMICTECH


Joined: 30 Jan 2011
Posts: 1657
Location: Aufhelperstan, Utopian Republic
Posted: 08 Aug 2012 02:24:23 pm    Post subject:
Um, note that the addin is located in ROM (just saying due to the wording). Also, the stack can't be completely used. The addin's stack grows downwards. Running the heap into that will be very painful.

Also, crt0.s is the source. crt0.o is the compiled version. .s usually means assembly (in this case, SH4a asm)
_________________
°ᴥ° Get Lucky

<BrandonW> "You don't even want to know what TI Connect does when it's just detecting your calculator...It ACTUALLY ERASES THE SWAP SECTOR on every communication attempt...EVERY SINGLE ATTEMPT...Yes, TI Connect will kill your calculator..What do I have to do to get your attention?!....Such a bloated protocol."
Back to top
hugh9860


Newbie


Joined: 08 Aug 2012
Posts: 32
Location: London, UK
Posted: 08 Aug 2012 02:29:09 pm    Post subject:
Yes, you're right about the stack being in the way.

the idea would be to adjust crt0 to put the stack at the end of the old heap space and the start of the heap at the end of add-in RAM area.

eventually they will still collide though Smile
Back to top
Tari


Systems Integrator


Joined: 03 Jul 2006
Posts: 2106
Location: Always-winter, Michigan
Posted: 10 Aug 2012 09:15:35 am    Post subject:
I just added alloca to the libfxcg headers, so it appears to work now.
Silly example:
Code:
#include <alloca.h>

int main() {
    int *l[16];
    int i;
    for (i = 0; i < 16; i++) {
        l[i] = alloca(sizeof(int));
        l[i] = i;
    }
    return 0;
}

_________________


Ask questions the smart way · タリ
Back to top
KermMartian


Site Admin


Joined: 14 Mar 2005
Posts: 55736
Location: Earth, Sol, Milky Way
Posted: 10 Aug 2012 04:06:22 pm    Post subject:
AHelper wrote:

Remember that PrizmSDK is old. These functions are located in libfxcg on github.
That reminds me once more that we need to pack up a new PrizmSDK including all the libfxcg updates into a v0.4 version, perhaps. Can you guys coordinate on when the current set of libraries is sufficiently complete and functional?
_________________
Back to top
Display posts from previous:   
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Prizm memory map
    »
» View previous topic :: View next topic  
Page 1 of 1 » All times are GMT - 5 Hours

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© Copyright 2000-2013 Cemetech & Kerm Martian :: Page Execution Time: 0.036115 seconds.