"Spinless" objects, "coglet's", etc.

[Dr_Acula]

I wonder if one could think about a proptool that could handle coglets?

First, don't define any protocols or standards for cog comms. That is up to the user to do.

Let's say I have a program and it has a single pasm section, and I want that pasm to be loaded from somewhere externally rather than included as part of the program.

You can put the pasm code on an sd card but the overhead of the SD code (maybe 1/4 to 1/3 of hub ram) kind of negates using SD. So I'm wondering about using an eeprom, and simply use a 64k instead of a 32k eeprom.

You may not need to always load the data to eeprom. What you need is a smart editor program and if you hit F10, it knows whether the pasm code was changed since last time you did a download, and it only sends the pasm part if there is a change. So most of the time the coglets are not updated.

It probably would need a tiny bootloader program on the prop. Send that first as part of the F10 download and it handles transferring any new coglets into eeprom. Then send the main program.

In the editor program, you might need a checkbox to select or deselect sending pasm separately. It might get a little complex if some pasm code you want included and some you want separate.

This could almost double the size of a spin program you could fit in a propeller.

[Cluso99]

Drac: The problem with the SD code is FAT compatability. If you forgo that you could have a small footprint. So eeprom does not get you anything really. Much better for an os to have and use only SD after initial boot. Otherwise, the os will require both SPI and I2C and the I2C will require some type of file structure.

But we need to keep the hub to a minimum. If you don't need FAT after you load up everything then that can be unloaded. Currently in my os (derived from your kyedos) the sd driver of kye's is not resident at all.

I have reserved a 2KB block of hub ram ($7800-$7FFF):

• a 1KB vector table for my faster spin interpreter (can be optional)
• a 512B sector buffer
• 8 x 32B cog table (undefined for now)
• 3 x 64B buffers (which can be joined as 1 x 192B buffer) eg for string buffers, etc
• leaving 64B (16 longs) for miscellaneous including the last long as a pointer to the start of protected hub sram (eg $7800)
• ..

Dave has a 24B cog table. I prefer this to be a block of longs to the power of 2 so that a simple shift of the cogid is all that is required to access your cog table. The first B should be a "type" flag indicating the cog is loaded, and what type of service (input, output, I/O, etc it provides). Something akin to Catalina seems perfect. The rest can depend on the useage, but we should define a couple of standard ones for keyboard, tv, vga, pc serial. If the next 11B is not required, then it should be used to store the cogs' filename it was loaded from. Now, presuming we allocated 32B (8 longs) per cog, that still leaves 20B (5 longs) free for buffer/whatever. The alternative is to trim to 16B (4 longs) per cog.

I allocated a long to be used for: 1B with a bit for each cog to indicate it should remain loaded between each os/program load. 2B stores the screen size (8 bits columns, 7 bits row, and 1 bit for autoLF). 1B stores the clock mode.

1L stores the clockfreq; 1L stores the SD pins (1B per pin); 1L stores the serial pins (SI, SO, mode and the cogid); 1L stores the baud;

I used 4L to store rendezvous locations for: StdIn, StdOut, AuxIn, AuxOut. Perhaps with the Cog Tables, these could be reduced to a nibble each and just store the cog# to be used. I really liked the Sphinx idea of a single buffer for stdin and another single buffer for stdout, etc. But, this is a problem that means serial needs to internally buffer, or another buffer needs to be added to the mix (particularly for input). We have a few drivers (serial, tv, vga 1pin tv, keyboard, 1pin keyboard) already done with 1 character buffers courtesy of Sphinx. This method gives spinless objects. I would like to see some more discussion here.

[ctwardell]

It looks like there are two use cases here:

1) Treating the prop as a general purpose computer running some type of OS with an SD card based file system.

2) More traditional "microcontroller type" applications running a fixed set of firmware to do one specific task.

Most of the ideas presented here seem to be more focused on case 1 than case 2.

My primary interest is case 2.

C.W.

[jazzed]

It looks like there are two use cases here:

1) Treating the prop as a general purpose computer running some type of OS with an SD card based file system.

2) More traditional "microcontroller type" applications running a fixed set of firmware to do one specific task.

Most of the ideas presented here seem to be more focused on case 1 than case 2.

My primary interest is case 2.

C.W.

Hi C.W.

Case 2 is a simple and practical approach as first presented here - resetting the propeller really complicates things and will be avoided. In the near future we will be adding a loader feature that put's COG code into upper 32KB EEPROM locations for loading in Propeller-GCC according to the object linking. This eliminates complexity required otherwise. That is, you always know before hand what will be loaded and can let the compiler and tools do the work for you with no overhead other than PAR mailbox info. The start-up I2C COG PASM buffer in the main program will be recycled for the code array space - the I2C PASM will read the code into the array and then we can do cognew with that. That is the general approach we will take.

Does that sound about right for your interest?

Thanks,
--Steve

[Dr_Acula]

Thanks jazzed for that discussion thread link. All very interesting to read through that.

re Cluso99, I am thinking simpler than a FAT. If you are going to put 7 coglets into high eeprom, you don't really need a FAT. Make them all the same length (2048 bytes) and put them one after the other in order. The compiler and the program then knows where they are.

I think this is the same as what jazzed is saying.

I'm also thinking you have a smart compiler that only reloads eeprom code that has changed. So when you first turn on your PC and start the compiler (GCC or whatever), maybe the first download it either sends all the coglets to eeprom, or if you want to be smart, reads them off the eeprom, compares with what might be downloaded, and only downloads if things have changed since before (this latter system avoids any unnecessary eeprom writes).

Then if the compiler program detected a change when you do an F10, it would send new code. Most of the time, coglets would be fairly stable code, eg keyboard, mouse, video driver, so they never need change. This could even speed up a download compared with the current proptool as you would not be sending all the pasm code each F10. I am thinking the way I often write programs, I start by grabbling the core bits out of the obex. Mouse. Keyboard. A video driver. So the first time you download all that, all the coglets go out to eeprom. But from that point on, as you write and rewrite your main program and do repeated F10 downloads to test it, no further coglets ever get written to eeprom. They are already there.

re

I have reserved a 2KB block of hub ram ($7800-$7FFF):

I'm not sure you need any rules about where things are in hub ram. That will change for each program you write, and you might not even need a buffer for keyboard or serial port (eg the GUI I'm writing with a touchscreen, where inputs and outputs are pictures, not text, and the pictures are too big to fit in hub anyway). So the only rule really is that all parameters must be passed to a cog via a par section at the beginning. That keeps it very simple and easy to explain.

It sounds like the GCC team is making great progress.

[ctwardell]

Hi C.W.

Case 2 is a simple and practical approach as first presented here - resetting the propeller really complicates things and will be avoided. In the near future we will be adding a loader feature that put's COG code into upper 32KB EEPROM locations for loading in Propeller-GCC according to the object linking. This eliminates complexity required otherwise. That is, you always know before hand what will be loaded and can let the compiler and tools do the work for you with no overhead other than PAR mailbox info. The start-up I2C COG PASM buffer in the main program will be recycled for the code array space - the I2C PASM will read the code into the array and then we can do cognew with that. That is the general approach we will take.

Does that sound about right for your interest?

Thanks,
--Steve

Steve,

It sounds very close. Will the COG code be able to be imported as a PASM binary?

By that I mean if I've already created a PASM binary using "normal" propeller assembly in the propeller tool will I be able to use that binary versus needing to code it using GCC or GAS.

It sounds like the only requirement of the COG PASM is that it gets all setup info via the address passed to PAR, is this correct.

Thanks,

C.W.

[Dave Hein]

There's been some great ideas proposed in this thread about Spinless objects, but to me it seems like it's better to include a little bit of Spin code to set up the PASM cog. This alleviates having to do the setup in PASM or having the calling program do the setup. As far as storing the drivers in EEPROM, you could implement a very simple linear file system in EEPROM. It would basically consist of a file name, file size and file contents stored one after another. Another possibility is to have a small directory consisting of file name, size and starting locations. The EEPROM file system would be read-only, so it doesn't have to be very complicated.

[Heater.]

Dave Hein,

There's been some great ideas proposed in this thread about Spinless objects, but to me it seems like it's better to include a little bit of Spin code to set up the PASM cog

Perhaps so but what if you want to borrow such a "coglet" for use in language other than Spin? Arranging to get binary blobs of "firmware" started in a COG is hard enough with having to also start up a Spin interpreter to configure the thing and get it going.

[Dr_Acula]

How about keeping the spin code to such a minimum that it is easy enough to write the equivalent code in any language? eg

To start

  cog := 1 + cognew(@mycode, @parameters)

To stop

   if cog
      cogstop(cog~ - 1)

and to pass parameters and do clever things like pass different commands to a cog to run various routines, just designate one of the longs in the parameter list as a "command" long and change it and the cog code changes it to something else to say it has finished. It will all be very similar in different languages - you talk to a cog by changing a long in hub, and wait for the long to change to signal the routine has finished. All languages can write to and read longs in hub.

If the cog is a "start and run forever" cog, you just run the startup routine.

I suppose the key here is good documentation. For a particular coglet, you might define it has n longs as the parameter list, and they are in a fixed order. So you just need to explain that in a verbose way that is easy to understand.

re ctwardell

By that I mean if I've already created a PASM binary using "normal" propeller assembly in the propeller tool will I be able to use that binary versus needing to code it using GCC or GAS.

That is exactly the idea. You can compile these using the proptool. Save them as a .binary file. Or a .cog file, or whatever you want. Store them on an sd card, or in high eeprom, it does not matter. Once that binary file exists, any language can use it, Spin, C, Basic etc.

This is some code I was using for Catalina that is a skeleton pasm routine that compiles independently using the proptool and which passes a group of variables:

CON
  _clkfreq = 80_000_000
  _clkmode = xtal1 + pll16x

PUB Main
    coginit(1,@entry,0)                     ' cog 1, entry, dummy value

DAT
                  org 0
entry                                          ' start of the cog code
                  mov arraypointer,par         ' arraypointer is the address of the array
                  rdlong array0,arraypointer   ' array0 = array[0]
                  mov array1,array0            ' array[1]=array[0] - long is 4 bytes so add 4
                  add array1,#4                ' array[1] += 1 change the value so see cog works
                  add arraypointer,#1          ' pointer += 1
                  wrlong array1,arraypointer   ' write array[1] back to hub
                  jmp #entry

arraypointer      long    $00000000            ' pointer to array[0]
array0            long    $00000000            ' first array location
array1            long    $00000000            ' second array location
                  fit 496

[jazzed]

It sounds very close. Will the COG code be able to be imported as a PASM binary?

Yes, we support PASM, GAS, or GCC native COG C drivers. We have a few different ways of extracting PASM from the SPIN code.

Going the extra step to loading the COG code after boot just requires a loader enhancement and including the I2C driver.

It sounds like the only requirement of the COG PASM is that it gets all setup info via the address passed to PAR, is this correct.

Yes, that's correct.

Using SPIN methods to poke values into the PASM at SPIN run time before cognew should of course be avoided. Some obex code does this and would have to be ported. The Graphics.spin file is an example that had to be ported. Of course if you know the address of things to poke it doesn't matter except for portability and keeping up with whatever changes may happen.

I like the idea of a COG letting the main program know when it's ready, but it is not necessary to do that. When you have control over things at compile time, you can do whatever you like within reason.

[ctwardell]

Jazzed,

Excellent. Do you have an ETA for when the loader will be available?

I'll move ahead making my objects having them get setup via PAR and can migrate to the new loader and GCC when it is ready.

Thanks,

C.W.

[Dave Hein]

Perhaps so but what if you want to borrow such a "coglet" for use in language other than Spin? Arranging to get binary blobs of "firmware" started in a COG is hard enough with having to also start up a Spin interpreter to configure the thing and get it going.

It's fairly easy to start up a Spin program anywhere in memory. This could be done from any language. This way you only write the PASM startup code once in Spin, and it doesn't have to be redone in each language that you support. The drawback is that you need to write a Spin program loader routine in the language you are using, but an OS has to do that anyway. The other issue is that you need a standard way to pass parameters to the PASM startup programs. In Spinix, I use the (argc, argv) method that is used for C programs. This is very flexible, and it works well in the Spinix architecture.

Another advantage to including the Spin code with the PASM cog code is that it goes away after the cog is loaded, and that memory is available for use by other programs. This may not be a big issue for some PASM dirivers where all that is needed is a cognew. However, some PASM drivers require quite of bit of setup, such as a display driver or a memory cache driver. PropGCC uses a Spin program to set up the memory cache driver. In theory, Spin programs could use the same driver to access external memory.

The only part that needs to be converted to another language is the API used to talk to the driver.

[jazzed]

Excellent. Do you have an ETA for when the loader will be available?

Hi C.W.

I don't have an ETA at the moment.

It will be after Propeller-GCC Beta start.
I'm shooting for Beta next week ... we'll see.

[RossH]

Dave Hein,

Perhaps so but what if you want to borrow such a "coglet" for use in language other than Spin? Arranging to get binary blobs of "firmware" started in a COG is hard enough with having to also start up a Spin interpreter to configure the thing and get it going.

Gosh, it seems like we've been round this loop so many times now that I now get dizzy just thinking about it. Although I haven't had as much time for such things as I'd like recently, I've already implemented all the necessary techniques (i.e. the ones described here) in Catalina. It has made everything much simpler, and the overhead is quite low - in fact, programs often end up smaller now than they used to be, since this approach generally requires less messing about in Spin. I should have a version ready to release in a few days. I'll go back and update that document after I do - there have been a a couple of minor changes and additions to what I originally proposed.

Someone recently asked me if I could support multiple serial ports in Catalina, and so I thought the OBEX "4 port serial driver" would make a perfect example of the benefits to be had. It took a couple of hours to port and test and it works a treat. It required no changes to the orignal PASM code (which is just as well, since I have no idea how it works internally, and nor do I want to - just reading the code makes my brain hurt!) and only a couple of changes to the Spin code - most of it I simply delete as it is no longer necessary. The main reason I do this is that Homespun does not automatically remove unused Spin methods, so leaving them in just eats up potential code space for no good reason - but (thinking about it now) perhaps it would make sense to leave them in but put a simple "#ifdef .. #endif" around them - that way, exactly the same OBEX object could be used from Spin, C or any other language that implemented the same technique. I may go back and do this just to provide a complete multi-language example. I already have all the Spin code, since Catalina's initialization code is now just a simple Spin program (the complexity that many people used to find so confusing is now gone - thanks largely to the adoption of these techniques).

I think it's a real shame that more people don't seem to see the potential benefits in writing all OBEX objects this way - there are heaps of amazingly clever and really useful objects already in the OBEX that could easily be used from multiple languages with quite trivial re-work. Just imagine the thousands of hours of duplicate effort we would all have saved - and also how much more attractive it would make the Propeller if all varieties of developers - hobbyist or professional - could use the same set of "vetted" objects - no matter what language they chose to use. Sigh!

Ross.

[RossH]

It's fairly easy to start up a Spin program anywhere in memory. This could be done from any language. This way you only write the PASM startup code once in Spin, and it doesn't have to be redone in each language that you support. The drawback is that you need to write a Spin program loader routine in the language you are using, but an OS has to do that anyway. The other issue is that you need a standard way to pass parameters to the PASM startup programs. In Spinix, I use the (argc, argv) method that is used for C programs. This is very flexible, and it works well in the Spinix architecture.

Another advantage to including the Spin code with the PASM cog code is that it goes away after the cog is loaded, and that memory is available for use by other programs. This may not be a big issue for some PASM dirivers where all that is needed is a cognew. However, some PASM drivers require quite of bit of setup, such as a display driver or a memory cache driver. PropGCC uses a Spin program to set up the memory cache driver. In theory, Spin programs could use the same driver to access external memory.

The only part that needs to be converted to another language is the API used to talk to the driver.

Ah! didn't read far enough down in the thread before responding - yes, I agree with Dave. And we already have everything we need to make it work!

Ross.