Logical, but not simple. I was arguing for wording that someone completely unfamiliar with the IDE could infer the function of. If you have a project open, "new" file should just add it to the project automatically. If you don't want it part of the project, then right click and "delete".
Logical, but not simple. I was arguing for wording that someone completely unfamiliar with the IDE could infer the function of. If you have a project open, "new" file should just add it to the project automatically. If you don't want it part of the project, then right click and "delete".
The only problem i have with "import" is in many programs, the common meaning is to bring in something that may need some out of the ordinary conversion - "export" is similar but the conversion is outgoing.
A "new" feature can also require a dialog for specifying a file type, and I'm not ready to support that at the moment. Right now the user specifies the file type when they do "Save As."
Steve, I finally figured out how to articulate what my concerns are for memory models.
So, the only memory model that I really want to be able to assign is COG, so if I write a C driver in SIDe, I can mark it as COG so that my other code can launch that as a COG.
Extrapolating that idea, I came up with a visual/logical concept.
In the Project view, have a subtree element called "COG" and any files that are children of this are compiled with the COG memory model.
Now, you can right click a file in COG and assign it to launch on a specific COG at program start, automating the process of starting up code.
So, if the PGCC kernel loads on COG 0, then only COG1-7 are available, the PGCC kernel would automatically launch any statically allocated cogs
at boot time.
You can explicitly assign a file to COG 0 only in "expert" mode, and it's assumed that someone would be writing a pure standalone program kinda how SPIN/PASM works, without
any of the PGCC kernel support. I would expect the common case is where COG 0 is not assigned, only in "expert" mode would you assign it. The assumption is
that most programs will be LMM or XMM and so the LMM/XMM kernel handles loading.
It only makes sense for this layout if the project has a MM of LMM or XMM*, if it's COG, then it's assumed all code is fPIC and main() runs in COG 0 after init. I wanted to maintain
support for low level C coding like _crt0 init code.
If the project uses the full duplex serial object, then it would automatically be assigned to a COG in the project view so the resource is allocated statically.
This would be a way to visually represent the COG resources and explicitly indicate which source files are to be compiled as COG memory model for later use.
The * is an icon of a gear (COG) with the number of the resource next to it. Source files that are COG MM, but not explicitly assigned, are listed immediately after COG, the statically allocated COG resources are displayed at the bottom.
I like the icon/file idea for the file types. We don't have to associate .cogc programs with cog numbers though. All you have to do is define the file as somecode.cogc and follow the .cogc rules for drivers ... oh my where did they go. Guess i need to add a language doc section. Ugh so much to do. For now just follow the toggle examples and other demos for the different program types.
The purpose of associating a file with a COG is to have that code automatically launch on bootup. This does a minor amount of work for the programmer, but it allows the programmer to visually see resource allocation and utilization. Make sure you don't run out of cogs, or show you how many cogs you have available for additional tasks.
So you are saying that a file with the extension .cogc will always be compiled as COG MM? That's easy and makes sense, it just needs to be expressed in the IDE for coherence.
So you are saying that a file with the extension .cogc will always be compiled as COG MM? That's easy and makes sense, it just needs to be expressed in the IDE for coherence.
The .cogc extension is specifically intended for generating COG programs that can be loaded by the main C program. You can write all of your propeller code in C.
Any .c program that generates code < 1920 bytes can be compiled and run as a COG main propeller program. Choosing COG model will help make use of the smallest print method as well.
Comments
The only problem i have with "import" is in many programs, the common meaning is to bring in something that may need some out of the ordinary conversion - "export" is similar but the conversion is outgoing.
A "new" feature can also require a dialog for specifying a file type, and I'm not ready to support that at the moment. Right now the user specifies the file type when they do "Save As."
So, the only memory model that I really want to be able to assign is COG, so if I write a C driver in SIDe, I can mark it as COG so that my other code can launch that as a COG.
Extrapolating that idea, I came up with a visual/logical concept.
In the Project view, have a subtree element called "COG" and any files that are children of this are compiled with the COG memory model.
Now, you can right click a file in COG and assign it to launch on a specific COG at program start, automating the process of starting up code.
So, if the PGCC kernel loads on COG 0, then only COG1-7 are available, the PGCC kernel would automatically launch any statically allocated cogs
at boot time.
You can explicitly assign a file to COG 0 only in "expert" mode, and it's assumed that someone would be writing a pure standalone program kinda how SPIN/PASM works, without
any of the PGCC kernel support. I would expect the common case is where COG 0 is not assigned, only in "expert" mode would you assign it. The assumption is
that most programs will be LMM or XMM and so the LMM/XMM kernel handles loading.
It only makes sense for this layout if the project has a MM of LMM or XMM*, if it's COG, then it's assumed all code is fPIC and main() runs in COG 0 after init. I wanted to maintain
support for low level C coding like _crt0 init code.
You would see:
If the project uses the full duplex serial object, then it would automatically be assigned to a COG in the project view so the resource is allocated statically.
This would be a way to visually represent the COG resources and explicitly indicate which source files are to be compiled as COG memory model for later use.
The * is an icon of a gear (COG) with the number of the resource next to it. Source files that are COG MM, but not explicitly assigned, are listed immediately after COG, the statically allocated COG resources are displayed at the bottom.
So you are saying that a file with the extension .cogc will always be compiled as COG MM? That's easy and makes sense, it just needs to be expressed in the IDE for coherence.
The .cogc extension is specifically intended for generating COG programs that can be loaded by the main C program. You can write all of your propeller code in C.
Any .c program that generates code < 1920 bytes can be compiled and run as a COG main propeller program. Choosing COG model will help make use of the smallest print method as well.