Initialize static data (something like spin DAT)

ctwardell · 2012-11-16 13:40

What is the proper way to initialize static data that will go in the HUB?

I have a lookup table of 256 longs.

Building an array and explicitly assigning the values would work, but that seems inefficient.

What I would like is to have it already in place in the EEPROM image and just have a pointer to it, but I don't know how to accomplish that.

Thanks,

C.W.

jazzed · 2012-11-16 18:11

Not sure I follow C.W.

Did you see the example in one of todays threads?

You can put cogc driver code into EEPROM automatically with propeller-load using the ecogc extension, but I've never tried making a data table with it - maybe it could be done. The code would be put into a buffer that can be loaded from eeprom similar to the cog_loader example in the demos.

--Steve

David Betz · 2012-11-16 19:06

ctwardell wrote: »

What is the proper way to initialize static data that will go in the HUB?

I have a lookup table of 256 longs.

Building an array and explicitly assigning the values would work, but that seems inefficient.

What I would like is to have it already in place in the EEPROM image and just have a pointer to it, but I don't know how to accomplish that.

Thanks,

C.W.

If you just want an initialized array in hub memory you can just declare it like any normal C global variable as long as you're using the LMM, CMM, or XMMC memory model. In all of those memory models all data is placed in hub memory.

long my_array[256] = { 1, 2, 3, ... };

Replace the ... with the rest of the initializers.

ctwardell · 2012-11-17 11:50

Thanks Steve and David.

I think between your two replies I see what I need to try.

C.W.

ctwardell · 2012-11-17 12:26

OK, let me better explain what I want to do and then a few more questions.

This is for the COSMACog stuff.

We worked out the " __stack_end" setting for LMM earlier this year, I'm using that to reserve space at the top of the HUB for Mailboxes and now Lookup Tables that will remain in place for the emulator cogs to use. Once the GCC LMM loader program loads the cogs and sets up Mailboxes and LUT's it will be wiped out and its code code space re-used as general purpose RAM.

The issue I'm trying to work around is getting the LUT's into the space above __stack_end without either copying data or a bunch of manual address manipulation in the loader.

I know I can specify an address for a variable, and I've been doing that so far, but it seems to "manual" to me. When the various COSMACog "objects" are complete I want users to be able to mix and match as set of objects to build a "system". I'm afraid all the manual address manipulation will be an impedement to success for many users.

What I'd like to have is a GCC segment defined ABOVE __stack_end that grows upward as I put variables in it.

So...can I set a start address for the HEAP?

If so can I use an attribute like Steve mentioned for forcing variables into the TEXT section and then put both initialized and uninitialized variables on the HEAP using the attribute?

Thanks,

C.W.

David Betz · 2012-11-17 12:56

ctwardell wrote: »

OK, let me better explain what I want to do and then a few more questions.

This is for the COSMACog stuff.

We worked out the " __stack_end" setting for LMM earlier this year, I'm using that to reserve space at the top of the HUB for Mailboxes and now Lookup Tables that will remain in place for the emulator cogs to use. Once the GCC LMM loader program loads the cogs and sets up Mailboxes and LUT's it will be wiped out and its code code space re-used as general purpose RAM.

The issue I'm trying to work around is getting the LUT's into the space above __stack_end without either copying data or a bunch of manual address manipulation in the loader.

I know I can specify an address for a variable, and I've been doing that so far, but it seems to "manual" to me. When the various COSMACog "objects" are complete I want users to be able to mix and match as set of objects to build a "system". I'm afraid all the manual address manipulation will be an impedement to success for many users.

What I'd like to have is a GCC segment defined ABOVE __stack_end that grows upward as I put variables in it.

So...can I set a start address for the HEAP?

If so can I use an attribute like Steve mentioned for forcing variables into the TEXT section and then put both initialized and uninitialized variables on the HEAP using the attribute?

Thanks,

C.W.

I think the standard GCC way of handling this sort of thing is with a custom linker script.

ctwardell · 2012-11-17 13:58

Thanks David, I was afraid that would be the answer...

ctwardell · 2012-11-17 14:00

jazzed wrote: »

The code would be put into a buffer that can be loaded from eeprom similar to the cog_loader example in the demos.

--Steve

Is there a EGOCS or something like that that let's you create an ECOG using assembler instead C?

I'd like the "ECOG Advantage (tm)" of having the images above 32k, but with assembler created cog code instead of C.

Thanks,

C.W.

David Betz · 2012-11-17 14:45

ctwardell wrote: »

Is there a EGOCS or something like that that let's you create an ECOG using assembler instead C?

I'd like the "ECOG Advantage (tm)" of having the images above 32k, but with assembler created cog code instead of C.

Thanks,

C.W.

You can do that pretty easily if you write your assembler using GAS rather than PASM.

jazzed · 2012-11-17 21:31

David Betz wrote: »

You can do that pretty easily if you write your assembler using GAS rather than PASM.

An example of this might be useful. How would gas end up in EEPROM automatically?

David Betz · 2012-11-18 17:44

Just like C code you can place GAS code in any section. As long as it's in a section ending in .ecog it will end up in EEPROM when the loader loads it.

Just put something like this at the start of the GAS souirce file:

                    .section mygascode.ecog, "ax"

altosack · 2012-11-18 18:52

I like to automate the whole process; here's a snippet of my Makefile with what I hope are just the relevant sections. All of the GAS source files end in .S so the pre-processor is used on them; the object files are *.o for all forms of LMM, *.cog for cog sections in hub RAM, *.ecog for cog sections stored above 32k in the EEPROM, and the section name is changed automatically by OBJCOPY. And, no, I don't use SimpleIDE.

PRJSRC=main.c regulate.c prop.c
COGSRC=lcd.c fpu.S
ECOGSRC=adc.S pwmph.S

# List all object files we need to create
OBJ=$(patsubst %.c,%.o,$(patsubst %.S,%.o,$(PRJSRC)))
COGOBJ=$(patsubst %.S,%.cog,$(patsubst %.c,%.cog,$(COGSRC)))
ECOGOBJ=$(patsubst %.S,%.ecog,$(patsubst %.c,%.ecog,$(ECOGSRC)))
ALLOBJ=$(OBJ) $(COGOBJ) $(ECOGOBJ)

# Make targets:
$(TRG): $(ALLOBJ) Makefile
    $(CC) $(LDFLAGS) $(ALLOBJ) -o $(TRG)

%.o: %.c $(PRJHDR) Makefile
    $(CC) $(CFLAGS) -c $< -o $@

%.o: %.S $(PRJHDR) Makefile
    $(CC) $(CFLAGS) -c $< -o $@

%.cog: %.c $(PRJHDR) Makefile
    $(CC) $(COGFLAGS) $< -o $@
    $(OBJCOPY) --localize-text --rename-section .text=$@ $@

%.cog: %.S $(PRJHDR) Makefile
    $(CC) $(COGFLAGS) -c $< -o $@
    $(OBJCOPY) --localize-text --rename-section .text=$@ $@

%.ecog: %.c $(PRJHDR) Makefile
    $(CC) $(COGFLAGS) $< -o $@
    $(OBJCOPY) --localize-text --rename-section .text=$@ $@

%.ecog: %.S $(PRJHDR) Makefile
    $(CC) $(COGFLAGS) -c $< -o $@
    $(OBJCOPY) --localize-text --rename-section .text=$@ $@

David Betz · 2012-11-19 03:51

altosack wrote: »

I like to automate the whole process; here's a snippet of my Makefile with what I hope are just the relevant sections. All of the GAS source files end in .S so the pre-processor is used on them; the object files are *.o for all forms of LMM, *.cog for cog sections in hub RAM, *.ecog for cog sections stored above 32k in the EEPROM, and the section name is changed automatically by OBJCOPY. And, no, I don't use SimpleIDE.

PRJSRC=main.c regulate.c prop.c
COGSRC=lcd.c fpu.S
ECOGSRC=adc.S pwmph.S

# List all object files we need to create
OBJ=$(patsubst %.c,%.o,$(patsubst %.S,%.o,$(PRJSRC)))
COGOBJ=$(patsubst %.S,%.cog,$(patsubst %.c,%.cog,$(COGSRC)))
ECOGOBJ=$(patsubst %.S,%.ecog,$(patsubst %.c,%.ecog,$(ECOGSRC)))
ALLOBJ=$(OBJ) $(COGOBJ) $(ECOGOBJ)

# Make targets:
$(TRG): $(ALLOBJ) Makefile
    $(CC) $(LDFLAGS) $(ALLOBJ) -o $(TRG)

%.o: %.c $(PRJHDR) Makefile
    $(CC) $(CFLAGS) -c $< -o $@

%.o: %.S $(PRJHDR) Makefile
    $(CC) $(CFLAGS) -c $< -o $@

%.cog: %.c $(PRJHDR) Makefile
    $(CC) $(COGFLAGS) $< -o $@
    $(OBJCOPY) --localize-text --rename-section .text=$@ $@

%.cog: %.S $(PRJHDR) Makefile
    $(CC) $(COGFLAGS) -c $< -o $@
    $(OBJCOPY) --localize-text --rename-section .text=$@ $@

%.ecog: %.c $(PRJHDR) Makefile
    $(CC) $(COGFLAGS) $< -o $@
    $(OBJCOPY) --localize-text --rename-section .text=$@ $@

%.ecog: %.S $(PRJHDR) Makefile
    $(CC) $(COGFLAGS) -c $< -o $@
    $(OBJCOPY) --localize-text --rename-section .text=$@ $@

Using objcopy will certainly work to rename the sections. I just suggested the .section GAS directive to avoid having to do that extra step. Either should work.

P.S. I'm glad to see we have some Makefile users out there. I was beginning to think that no one was going to use PropGCC except with SimpleIDE. :-)

ctwardell · 2012-11-19 07:10

David Betz wrote: »
Just like C code you can place GAS code in any section. As long as it's in a section ending in .ecog it will end up in EEPROM when the loader loads it.

Just put something like this at the start of the GAS souirce file:
                    .section mygascode.ecog, "ax"

Thanks!

One of those things that is really simple, once someone shows you how.

C.W.

David Betz · 2012-11-19 07:43

ctwardell wrote: »

Thanks!

One of those things that is really simple, once someone shows you how.

C.W.

I suppose if you're going to use this scheme to place data in EEPROM then the name ".ecog" is a bit misleading. Not your fault though! :-)

ctwardell · 2012-11-19 07:56

David Betz wrote: »

I suppose if you're going to use this scheme to place data in EEPROM then the name ".ecog" is a bit misleading. Not your fault though! :-)

I'm just going to put the cog images in EEPROM, that frees up enough space in the lower 32k so that the data issue goes away.

I'm trying to make everything in the COSMACog project as standard as possible using PropGCC as way of showing a project using C code, GAS code, etc.

Everthing in the emulator iteself will be GAS, the loader program will be in C.

C.W.

David Betz · 2012-11-19 08:04

ctwardell wrote: »

I'm just going to put the cog images in EEPROM, that frees up enough space in the lower 32k so that the data issue goes away.

I'm trying to make everything in the COSMACog project as standard as possible using PropGCC as way of showing a project using C code, GAS code, etc.

Everthing in the emulator iteself will be GAS, the loader program will be in C.

C.W.

Sounds like a good plan!

Initialize static data (something like spin DAT)

Comments