Is this possible in PropGCC?

Brian Fairchild · 2012-06-20 01:20

(for more background see my 'frustrations' topic)

At run time I want the following...

8 COGs each running their own PASM code
32k of data in HUB RAM

Which is quite achievable by the silicon.

The problem in SPIN appears to be that all addresses in the 32k boot memory image must be unique. You can't reclaim/overlay DAT space after COGs have loaded for variable use.

What about PropGCC? Can I do this directly or will it be necessary to use some kind of overlay loader?

Brian Fairchild · 2012-06-20 02:29

OK, so my scenario might be a bit extreme and in reality you're probably still going to have one COG in there running code out of HUB as a supervisor.

Having written some test SPIN code I can see what the problem is. The 32k image contains everything exactly where it ends up at boot time. Even large blank areas for variables. Trying to reclaim that space is a kludge at best as, without some extreme care, there's no way to guarantee that your PASM/DAT code is contiguous.

As an example in C I want to...

declare 24 1kbyte arrays
write 8 cog files which run standalone (mcog or PASM) which use those arrays
write a main file which starts the whole thing running

...and have the compiler do what it should which is hide where those arrays are and deal with all the address references. If I want to I should be able to declare the arrays as global and pick up their address in the cog code.

David Betz · 2012-06-20 03:51

Brian Fairchild wrote: »

OK, so my scenario might be a bit extreme and in reality you're probably still going to have one COG in there running code out of HUB as a supervisor.

Having written some test SPIN code I can see what the problem is. The 32k image contains everything exactly where it ends up at boot time. Even large blank areas for variables. Trying to reclaim that space is a kludge at best as, without some extreme care, there's no way to guarantee that your PASM/DAT code is contiguous.

As an example in C I want to...

declare 24 1kbyte arrays
write 8 cog files which run standalone (mcog or PASM) which use those arrays
write a main file which starts the whole thing running

...and have the compiler do what it should which is hide where those arrays are and deal with all the address references. If I want to I should be able to declare the arrays as global and pick up their address in the cog code.

Propeller GCC supports what we call "ecog" drivers. These are drivers that are placed in external memory, currently in EEPROM above the 32k that contains your program that the Propeller loads on reset. We also provide a way to load those drivers into COGs after your program starts. This allows you to leave more of the 32k of hub memory available for program use since the COG images are in high EEPROM not taking up space in hub memory. There is a cost to this though. First, an I2C EEPROM driver will be linked with your program to allow it to read the COG images from EEPROM. Second, a 496 long buffer must be available in hub memory to read the COG image into in order to do cognew or coginit to load it into a COG. The Propeller can't load code directly from EEPROM into a COG. The code is currently configured to load the I2C EEPROM driver and then reuse the space taken by its image as the COG image buffer. After you've loaded all of the COGs you want to load you can reuse that 496 long buffer for other purposes. There is an example of how to do this in the Google Code repository under propgcc/demos/cog_loader. It loads a simple LED blinking program into all 8 COGs. It works either on a PropBOE with LEDs wired to P0-P7 or on a QuickStart board.

jazzed · 2012-06-20 12:35

Hi Brian,

Here is an example of how to write an ECOG C program like David mentions with SimpleIDE. David's example in the Propeller-GCC Demos v0-3-4 package is much more interesting, but it's not a .side project yet.

Hey Rick! Another toggle demo for ya!

Thanks,
--Steve

dnalor · 2012-06-20 13:17

jazzed wrote: »

Hi Brian,

Here is an example of how to write an ECOG C program like David mentions with SimpleIDE. David's example in the Propeller-GCC Demos v0-3-4 package is much more interesting, but it's not a .side project yet.

Hey Rick! Another toggle demo for ya!

Thanks,
--Steve

I tried to compile this project. There is a errormessage: ecogc_toggle.c:20:17: fatal error: i2c.h: No such file or directory.
Where should this header be ? Where is information about the i2c driver ?

Is there further information how this cogc and ecogc things work.
Where is this magic "extern unsigned int _load_start_toggle_fwcog[]" and how does it get its name. From the c-filename?

Is that the only magic or is there something hidden:
propeller-elf-gcc.exe -r -Os -mcog -o toggle_fw.cog -xc toggle_fw.cogc
propeller-elf-objcopy --localize-text --rename-section .text=toggle_fw.cog toggle_fw.cogIgnoring "Simple printf" flag in COG mode program.

Thanks!

jazzed · 2012-06-20 13:27

dnalor wrote: »

I tried to compile this project. There is a errormessage: ecogc_toggle.c:20:17: fatal error: i2c.h: No such file or directory.
Where should this header be ? Where is information about the i2c driver ?

Is there further information how this cogc and ecogc things work.
Where is this magic "extern unsigned int _load_start_toggle_fwcog[]" and how does it get its name. From the c-filename?

Is that the only magic or is there something hidden:
propeller-elf-gcc.exe -r -Os -mcog -o toggle_fw.cog -xc toggle_fw.cogc
propeller-elf-objcopy --localize-text --rename-section .text=toggle_fw.cog toggle_fw.cogIgnoring "Simple printf" flag in COG mode program.

Thanks!

Please update your installation to the latest packages. Minimum requirements are SimpleIDE v0-7-2 and Propeller-GCC v0-3-4. Both are in one of the latest SimpleIDE packages.

David Betz · 2012-06-20 14:53

Here is a SimpleIDE version of the propgcc/demos/cog_loader demo that loads all 8 COGs with COG C drivers that each blinks a different LED. It will work on any Propeller board that has 8 LEDs connected to adjacent pins but it is setup to work with the QuickStart board with LEDs on P16-P23.

Brian Fairchild · 2012-06-21 01:06

Thanks guys,

I'll fire up some hardware later and have a play.

dnalor · 2012-06-21 13:20

jazzed wrote: »

Please update your installation to the latest packages. Minimum requirements are SimpleIDE v0-7-2 and Propeller-GCC v0-3-4. Both are in one of the latest SimpleIDE packages.

David Betz wrote: »

Here is a SimpleIDE version of the propgcc/demos/cog_loader demo that loads all 8 COGs with COG C drivers that each blinks a different LED. It will work on any Propeller board that has 8 LEDs connected to adjacent pins but it is setup to work with the QuickStart board with LEDs on P16-P23.

That is strange! Why I had downloaded 0-6-12 ? I thought I followed Daniel Harris' link.
Anyway with the newest version it compiles.
Thank you.

But there is to much magic!

Why is '_load_start_toggle_fw_0_ecog' the address for cognewFromBootEeprom ?

Is there a memory-map where I can see what the compiler did ?

What address is 0xc0000000 (used in COG_IMAGE_EEPROM_OFFSET) ?

I want to understand what's going on.

Thank you.

David Betz · 2012-06-21 13:30

dnalor wrote: »

That is strange! Why I had downloaded 0-6-12 ? I thought I followed Daniel Harris' link.
Anyway with the newest version it compiles.
Thank you.

But there is to much magic!

Why is '_load_start_toggle_fw_0_ecog' the address for cognewFromBootEeprom ?

Is there a memory-map where I can see what the compiler did ?

What address is 0xc0000000 (used in COG_IMAGE_EEPROM_OFFSET) ?

I want to understand what's going on.

Thank you.

The address 0xc0000000 is where the linker script places ecog images. The loader knows to write data from that address to EEPROM rather than trying to load it into hub memory. That means that to find an image in the area of EEPROM above the 32k boot section used by the Propeller chip, it is necessary to take the address that the linker assigned to the ecog image, subtract 0xc0000000 from it and add 0x8000 (the area above the boot section of the EEPROM). You can get the linker to output a map. Maybe Steve can say how to do that with SimpleIDE.

jazzed · 2012-06-21 14:40

David Betz wrote: »

You can get the linker to output a map. Maybe Steve can say how to do that with SimpleIDE.

Right-click on a project manager source file name. Then click "Show Map File".
The map file is not pretty, but it has everything you need.

_load_start_toggle_fw_0_ecog is the address because that's the symbol defined in the tools.

They can be read as _load_start_<filename>_cog or _load_start_<filename>_ecog.

In SimpleIDE:

filename.cogc and extensions will be addressable as _load_start_filename_cog.
filename.ecogc and extensions will be addressable as _load_start_filename_ecog.

The .cogc file binaries (.cog) are loaded in the HUB RAM for LMM programs.
The .ecogc file binaries (.ecog) are saved to eeprom for LMM/XMM programs.

David Betz · 2012-06-21 14:59

jazzed wrote: »

The .ecogc file binaries (.ecog) are saved to eeprom for LMM/XMM programs.

Actually, the .ecog drivers are not loaded to EEPROM in XMM mode. Usually you would put COG images in XMM memory in XMM mode I think. We could revisit that decision in the future though.

jazzed · 2012-06-21 15:03

David Betz wrote: »

Actually, the .ecog drivers are not loaded to EEPROM in XMM mode. Usually you would put COG images in XMM memory in XMM mode I think. We could revisit that decision in the future though.

Unnecessary. I forgot. We need to document this better.

David Betz · 2012-06-21 15:04

jazzed wrote: »

Unnecessary. I forgot. We need to document this better.

I believe that the loader document does mention this.

Brian Fairchild · 2012-06-22 00:04

Looks like I need to...

1) get a strong coffee
2) print out all the docs
3) go sit in the garden and have a read

3) might be difficult as it's summer here in the UK.

dnalor · 2012-06-22 10:33

Aha! Loader.pdf would have been the right place to search not somwhere in memory models.

Do I understand that correct now?
Linker puts all ecog-code (Code from file with extension ecogc) from address 0xc0000000 upward. Loader puts that code not to hub but to whatever memory is connected to propeller and described in board.cfg (and of course supported by the loader).
_load_start_toggle_fw_0_ecog is an address in that ecogc section and loader knows to read that from external memory to buffer in hub and from there to cog memory.

Ok, but I do not like the idea to have special filenames with multiple mains. That is strange.
And if I have to use filenames for addressing than it is magic not c.

I would expect to define sections and have "normal" c-files. That would be the standard way.

#if(_CODEVERSION == ECOG)
section ("cog1")
_NATIVE
#endif
void cogfunction1(volatile struct PARAMETER * p)
{
...
}

#if(_CODEVERSION == ECOG)
section ("cog2")
_NATIVE
#endif
void cogfunction2(volatile struct PARAMETER * p)
{
...
}

What is the reason to choose such a mysterious way? Is there some problem I do not see?
Ok, for beginners or spin-users this is maybe the more understandable way, but I thought you want to address c-users?

David Betz · 2012-06-22 10:40

dnalor wrote: »

Aha! Loader.pdf would have been the right place to search not somwhere in memory models.

Do I understand that correct now?
Linker puts all ecog-code (Code from file with extension ecogc) from address 0xc0000000 upward. Loader puts that code not to hub but to whatever memory is connected to propeller and described in board.cfg (and of course supported by the loader).

Not exactly. The loader puts that data in the boot EEPROM starting at the offset 0x8000. It won't put it in any other attached memory. In fact, this mode was designed to work with a Propeller board with no external memory other than a >32KB boot EEPROM.

In answer to your other questions, yes it is possible to use sections to handle this. In fact, that is exactly what happens to these .ecogc programs when they're compiled. They get put into sections whose names end in ".ecog". The linker knows to place those sections in high memory and to define symbols that identify the starting and ending address of each of these sections. This could be done without any loader magic but would require a custom linker script for each program. That is still possible with Propeller GCC. This is just an easier and more automated way of doing this.

jazzed · 2012-06-22 11:08

Things in SimpleIDE are done the way they are as a convenience to programmers who may not have a grasp of makefile and tool-chain concepts especially with respect to linker scripts. There is a makefile project in the propeller-gcc v0_3_4 demos package that shows how to do things without SimpleIDE.

dnalor · 2012-06-23 08:51

jazzed wrote: »

Things in SimpleIDE are done the way they are as a convenience to programmers who may not have a grasp of makefile and tool-chain concepts especially with respect to linker scripts. There is a makefile project in the propeller-gcc v0_3_4 demos package that shows how to do things without SimpleIDE.

Do not understand me wrong. You did a good job and it is good that simpleIDE do this in background.
I program now for about ten years (job-related) with c on microcontrollers and I had never to edit a makefile or linker script. Thanks to HEW(Renesas) and MPLAB.
But the way it is done here, I think, is not good for understanding what is going on.
Changing the file extension is a strange way and make files incompatible with other editors (syntax highlighting).

Why you do not make (virtual) folders like ecogc in projekt manager.

I put the c file in ecog, SimpleIDE generates then automatically a headerfile with

extern unsigned char _load_start_file_ecog[];  
extern unsigned char _load_stop_file_ecog[];

#define startcog_eeprom_file(arg)    cognewFromBootEeprom(                            \
                                      _load_start_file_ecog,                          \
                                      _load_stop_file_ecog - _load_start_file_ecog,    \
                                      arg)

This headerfile I include and things are more logical and c conform.

Anyway it would be good to see all Headerfiles (even the library headers) in projekt manager after first compiling.
And search in project files is also missing.

My wish for project manager would be:

projekt.side
|
+-- c header files
|   |
|   x.h
+-- c source files
|   |
|   x.c
|
+-- cog header files
|   |
|   cog1.h
|
+-- cog source files
|   |
|   cog1.c
|
+-- ecog header files
|   |
|   ecog1.h
|
+-- ecog sourc files
|   |
|   ecog1.c
|
+-- dependencies
    |
    cogload.h
    i2c.h
    ...

Is this possible in PropGCC?

Comments