Please have a quick look at my old PropellerOS and at BoeBotBasic. There's a link to the former in Graham Stabler's Pretty Good Thread Index and the latter is in the Object Exchange. Both use a global communication/storage area at the top of memory. I would suggest storing the cog #s of the I/O drivers in this area as well as the "rendezvous" information. That's handy if you need to stop all other cogs. These include a pointer to the first free location which is a word. Typically, the I/O drivers would have a fixed size block at known locations and they'd allocate their buffers dynamically starting below the "free" pointer with the buffer addresses stored in the fixed area. Accessing the buffers this way doesn't add that much overhead and it allows the buffer sizes to be easily configurable.
The BoeBotBasic drivers are already modified to use this scheme and include a version of FullDuplexSerial, sdspiFemto (low-level I2C and SPI driver). The PropellerOS includes VGA and TV text drivers and a PS/2 keyboard driver, all modified from Chip's code to use this memory layout scheme.
Post Edited (Mike Green) : 6/11/2010 2:24:46 AM GMT
Cluso99 said...
Lets discuss this bit so we can settle on something. The buffer allocations can be made by the os when loading the appropriate driver. I am NOT suggesting to do a linked list!!! Just update the "free" pointer at $7FFF.
So you're suggesting hard-coding everything then or what? Show a picture your example.
Using a linked list or some other pointer management scheme allows for flexibility and
provides a way for applications to know where their part of the "heap" can begin. This
is especially important since you appear to want a piece of upper memory to remain intact.
jazzed,
That's what I was referring to. It's 4 years old from way before SD cards came into use on the Propeller, but the ideas are sound, still applicable, and similar to things others have proposed. I bring it up because there may be some pieces of value in it as people puzzle out a direction for some of the future Propeller development based on current experience.
2) There is the practical 'hands on' explanation. Start with
main
do
loop
then add
main
do
call subroutine 1
call subroutine 2
loop
(which is how I tend to start my software projects)
3) and then there is a picture with some terribly nerdy humour, from an electronics magazine from years ago where they took a real picture and added a silly caption. The picture was of an attractive female data entry operator in early '70s attire sitting in front of an old computer that had covered her in reams of punched paper tape. The 'new' caption read 'Top Down Programming sure is fun, so long as you know which is the top".
@ Mike Green, it sounds like some of this work is already done? Off to check it out now...
I guess everyone see the propeller differently to some extent.
I think a Pin-Map would be nice for when you want to make some sort of executable that can just be compiled to .bin, dropped on an SD card and runs on any hardware configuration.
I personally see the propeller more like a small single chip computing platform then a micro-controller. With the PropII this computer type use will be even more common place.
Having high RAM locations for shared drivers works well if your writing some sort of command line type program that shares the same interface as the OS, but sometimes a program will want to take full control of the hardware, Start custom video drivers, load up sound drivers, etc.
As for the whole File System matter.
I personally feel that FAT should be supported! The luxury of just being able to drop files on to SD from any Computer, PDA, Mp3 player, Cellphone or Camera is amazing. Files can be downloaded off of the internet and just dropped onto SD card for execution on the prop. :]
I think almost everyone is in agreement that we require FAT16/32 compatibility, so can we settle that and move on? If anything else is required it has to fit inside FAT16/32 like FUSE, directories, and CPM drive emulations.
Drac: It has nothing to do with Top Down or Bottom Up which is a coding method. This is to seperate the OS and drivers from the "program".
I have used the term "rendezvous" because mpark coined that in Sphinx and it sounded good to me. There are already TV, Keyboard, PC (simulating TV and Keyboard) and 1pin TV and TV drivers already done. As I said SD needs changing. The rendezvous locations need pushing down to make room for the "free" pointer.
The space to load a cog is not that great and could be done by an OS aware program anyway, so a buffer in top hub would not be required.
Below is a later proposed list of rendezvous locations. Here is a link which proposed a list of rendezvous locations and is based primarily on Sphinx.·http://propeller.wikispaces.com/Sphinx and here for a more detailed discussion on SphinxOS http://forums.parallax.com/showthread.php?p=819353·However, to accomodate the buffers and rendezvous that may be required for extra drivers (the SD driver currently used in Sphinx requires many rendezvous locations - this needs a rewrite and to use the bottom level fsrw 2.6 driver or similar), we need to know where the free space starts. It is best to have this in a fixed place of $7FFF.
Again my oppinions:
I think we have 2 kind of uses for an OS:
1. the OS is doing what every OS is doing - namely it provides a full set of services to allow programs to use them.
Here the OS would be started as the main-application on boot. Then the OS loads all necessary drivers for itself to operate. With something lika an AUTOSTART.CB (Cog batch ;o) you can for example start a menu system which lists all installed applications to choose from. When starting an application the OS in advance makes sure that all drivers needed by the application are loaded and running. Thus the application does not need code for drivers or for loading and starting drivers. The information on what drivers are needed could be saved in a *.INI file, where * has the same name as the application.
2. the OS is not meant to run in the end-product. Thus it's only a tool to make development easier (file up-/download, edit files on the system, maybe compile ....) and more flexible (use the same development plattform for different projects with different hardware simply by loading different drivers).
Here the OS itself is not part of the software to be installed on the end-product. The firmware will only use a OScore.spin for example for loading the drivers.
Guess I already mentioned it: Currently I have some code which creates a descriptor table at the end of upper EEPROM. (Of course it could also be shifted to the end of boot-loader EEPROM) The descriptor table contains a name, the version, the number of longs the message-/video- or whatever-buffer needs for each installed driver. A driver can simply be loaded by name and version number. The code for loading is extracted to a CogOScore.spin. I like the idea to extend it to also use the SD card for loading drivers.
For *.COG files I'd suggest to add some more data. My *.COG file currently contains a length and the binary dump of the PASM-code. But plans are to add more information, like the version number, the number of longs needed for message-/video- or whatever-buffer (like I have it in the EEPROM descriptor table). More? Who knows ;o)
The CogOScore has no own buffer for loading the driver, so it needs to be passed as parameter by the application. This allows the application to use the buffer otherwise when done with driver-load.
For some usecases it might be good to have a COG descriptor table in the upper HUB RAM which describes which COG runs which driver currently. But I think this should be optional. If the application fits into one 32kB image there is no need to have it. If the application is split up into several sub-systems it's cool if the startup-code can simply have a look at the table and see which drivers run and where the message buffers are placed.
@Ym2413:
If we have a driver concept that's not needed. The application won't have any driver code. It loads the pre-compiled drivers from somewhere (EEPROM or *.COG files) - that's it.
Why would you like to have a fixed rendevouz-table? The systems we build based on the propeller are to different. I'd propose to have a descriptor-table.
To keep it short the runtime descriptor table does not use full driver names (as they are available in EEPROM descriptor or *.COG meta-data), but hash values build out of driver name and version number (1 long). This is followed by the message-buffer address (1 word) and the size (1 word). If additional buffers are needed they simply follow the message buffer and increase the given size.
With this information every application can see if a required driver is loaded and knows where to send commands to it.
Maybe later on we could have drivers which have commands for suspend and resume.
Not sure I follow all the details of the discussion here but I can make an observation or two anyway[noparse]:)[/noparse]
There is talk of "rendezvous" for low level drivers which run in COGs (and other codes like file systems?). If I understand the "rendezvous" idea correctly it's like this: Most drivers nowadays are coded in PASM and then provide access methods in Spin. The Spin and DAT blob for the driver are intermixed in a Spin file and use up HUB space permanently . In the "rendezvous" idea the driver PASM is a binary blob that can be read from anywhere (SD, EEPROM etc) and set running in a COG. One then communicates with it via some HUB memory, the "rendezvous". This is great because it frees up HUB memory which can be reused after the COG is loaded.
My observation is that "rendezvous" is much the same idea as Bill Hennings mail-boxes and whatever is used in BoeBotBasic. Bill would like to keep mail boxes at the bottom of HUB RAM for a number of reasons though.
My second observation is that having binary blob drivers in COG that communicate through HUB "rendezvous" or "mailboxes" or whatever has another great advantage. They are no longer dependent on Spin. Or any particular language for that matter. COG code written this way has the possibility to communicate with other COG codes via the mailbox/rendezvous without having to go through a Spin layer.
Further more it becomes possible to use those same COG drivers from different languages like C provided by Catalina LMM or Zog. Or BASIC or from various Z80 and other emulators or whatever comes up.
All in all decoupling these low level drivers from Spin access functions is an excellent idea.
I'd like to introduce the use of the word "firmware" to describe these binary blobs intended to load and start in COGs. Basically the model is that one loads the "firmware" for say UART into a COG and starts it. Then one accesses it via "registers" in HUB space. Just like you do on a normal micro-controller with built in memory mapped peripherals. With this in place it matters not what language you are using.
Edit: By last observation is that with the COG code as "firmware" idea in place it decouples the driver codes from the operating system as well as the language used. Many hardware devices today in the PC world rely on firmware being loaded into them before they will work. WIFI chip sets for example. It matters not if that is done from Windows or Linux or BSD or whatever.
So properly defined "firmware" for COGs will work anywhere, you only have to tell it where it's mailbox/rendezvous/whatever is when it is started. cognew(@somefirmawareblob, @somerendezvous)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In an ideal world a cog might only have a couple of rendevous bytes. In the real world, as the example above shows, the number grows. The table could end up containing data for cogjects that are not even used. Potentially the list of unused cogjects could be every object in the obex. There might be no hub ram left once all these (unused) rendevous points are loaded.
MagIO2's idea solves that. If you load 7 cogjects, whatever loaded them would be able to create a list of their rendevous points and act as a redirector for that cogject. A calling routine passes the name of the cogject, and the name of the variable (or they could be numbered to speed things up). It then does the lookup.
MagIO2's descriptor table idea replicates the 'glue' that is currently done in spin code.
The driver idea does sound interesting. I like it.
But I still don't see how a program (or in this case the driver) would know which pin it should output to without some sort of pre-defined pin mapping. Are we saying that we write a different version of each .COG for each pin? Then you get back into the issue of what defines the PIN for each .COG driver?
Wouldn't want to see:
Demoboard_40hcharNTSC.COG
Pin16_40hcharNTSC.COG
Hybrid_40hcharPAL.COG
The driver would have to be started with some sort of pre-defined pin mapping coming from the OS its self.
I guess that wouldn't be too hard to manage. :]
OS could start the drivers with a lookup table of where each pin is.
Ym2413a: No we don't need a new binary compiled for each possible pin configuration.
I imagine that a binary driver firmware blob is obtained from somewhere, SD card say. It is saved to a temporary buffer. From there a it can be used to start a COG and then the buffer can be reused.
The mailbox/rendezvous block is used during normal running for exchanging commands/data/status BUT during that initial start of the COG the mailbox/rendezvous block can be used to pass pin definitions to the driver. If need be one or more of the mailbox/rendezvous fields can be used during start up as a pointer to a pin table or any other data the COG needs to be aware of.
What I want to know is how do we compile such PASM only firmware to binary blobs?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater,
Until some kind of feature is added to the Propeller Tool and/or the other Spin compiler/assemblers, the I/O drivers would have to be compiled in a wrapper of some sort that either writes them out to areas of EEPROM above 32K or writes them to SD card files. You'd load this program to RAM and execute it to initialize your system for use with the OS, then load the OS itself to EEPROM (the 1st 32K).
@heater:
Simple ... just put a small wrapper SPIN around it, which saves it as COG-file to the SD-card. You send that program to the Propeller once for execution and viola ... there you have the COG-file.
@ym2413a:
I think each driver should have a set of commands which are common for all drivers. Such like NOP, ERR, SET_BUFFER, SET_PIN_BASE, SUSPEND ... whatever comes into our mind. Let's say we reserve the first 256 numbers for such gereral purpose stuff.
NOP = 0 means no command send. It's set by the user of the driver to another value and the driver will set it back to 0 or 1 when done.
ERR = 1 means error occurred or function not supported. If the driver has to report more error states that's done in the following message buffer long.
That would be a driver model which allows all possibilities. Drivers that allow to set the pin and drivers with pre-compiled pins.
I personally like the precompiled version, as setting a pin-number only adds code for a flexibility that's not really needed in a finished hardware setup! I don't mind compiling the driver twice. The drivers for common boards could be packed into the code package precompiled. Maybe a driver management software can be written to extend the PropellerTool.
I already suggested to have a driver pin base .spin file which only has constants for the PIN-base of every driver you might want to use.
CON
PIN_BASE_TV = 4
PIN_BASE_SD = 0
...
Any kind of driver that drives a TV would simply use that PIN_BASE_TV constant.
All that is required is to write a "PUB start" at the beginning to satisfy the compiler, BST anyway. Then go straight into your PASM code. Then do "compile and save a binary". Use the file name of you choice "uart.cog" for example. The resulting binary has 16 bytes you don't need at the beginning and 4 at the end. These could be easily removed or just leave them there and ignore them when loading the *.cog at run time.
For example:
PUB start
DAT
enter mov a, b
mov a, b
mov a, b
mov a, b
mov a, b
mov a, b
mov a, b
a long 0
b long 0
heaters post (3 ago) describes exactly how Sphinx works now which is what I believe should be done. It loads a cog with code and passes the pin number(s) on startup. SO, only 1 binary is required for all pin numbers. The "rendezvous" is 1 long per direction. SO, the FDX driver is actually 2 directions, a read and a write. In fact, the FullDuplexSerial object works with only the modification that we now only use a 1 char buffer (part of the 1 long) and the buffer is in the cog. The same applies to the TV object. My 1pin TV driver includes the font and basic screen controls within the cog and just uses 1 long as the rendezvous location. When it is lkoaded/started the pin number is passed via the rendezvous location. If a group of parameters are required to be passed, then the rendezvous stores a pointer to the parameter list. The cogstart has PAR pointing to the rendezvous location.
This method allows programs such as CPM emulation to use the rendezvous without knowing if it is talking to a TV or VGA or serial output·and the same with input from a keyboard or serial, nor does it need to know which pins are used. It does not matter if it is 1pin or standard keyboard or TV. This means a single binary can be shipped, depending on of course, the SRAM implementation.
There is nothing complex about this which is why I like it so much. mpark designed the original rendezvous idea (or at least that is where I saw it) and it is only a slight extension to what objects do now. No need for complex tables and parameters. KISS.
You all really should look at Sphinx because I seem to be losing something in the translation - or is it that you are trying to create a monster, or am I missing something??? I am after the most hub free for the app program and minimal hub overhead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
heater said...
What I want to know is how do we compile such PASM only firmware to binary blobs?
Umm... LAS will assemble them just fine ... well it should, anyway, it passed my test suite. It is however still missing expressions and macro's.
I do plan on resuming work on it (and PropellerBasic) after UPEW.
The memory map I am using for Minos (single user, cut down version of Largos, uses VMCOG) is:
$0000-$01FF - reserved for OS and mailboxes
$0200-$07FF - reserved for VMCOG
$0800-$0FFF - reserved for 2KB cog load area / file system buffers
$1000-$7FFF - user ram, normally used as a 56 page working set for VMCOG
But the idea was that the last page ($7E00-$7FFF) could be left unused for SphinxOS compatibility.
I strongly recommend NOT fixing the screen buffer addresses, and only keeping rendezvous locations and pointers in the last page for SphinxOS
rendezvous locations are two longs, like Cluso says, whereas mailboxes are four longs.
All that is required is to write a "PUB start" at the beginning to satisfy the compiler, BST anyway. Then go straight into your PASM code. Then do "compile and save a binary". Use the file name of you choice "uart.cog" for example. The resulting binary has 16 bytes you don't need at the beginning and 4 at the end. These could be easily removed or just leave them there and ignore them when loading the *.cog at run time.
Or use bstc -c which will write a straight binary dump of only the DAT section from the top object. No header, no method tables, no spin, no sub-objects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
BradC: OK that's cool. However I have a little problem...
Lets say you are creating an emulator ZiCog, yZ80, Zog whatever. Often there is a need for a jump table. These tables are full of addresses of functions in the DAT block. Often these tables are not to be loaded to COG but used from HUB.
This kind of problem could also arise outside the emulator world. For example if your COG code can get a lot of different commands through it's mail box and a jump table in COG is used to find the PASM code section to handle the command.
So there is the problem, to extract the portion of DAT that should be loaded to COG and the portion that should be loaded to HUB somewhere. Of course this can be done by some post processing of the binary with some custom script or whatever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The operating system should be seperated into a BIOS and a DOS.· The BIOS is loaded from EEPROM and it provides very basic functionality for setting up the standard input, standard output and the file system.· A BIOS is specific to each platform.· It knows whether the standard input comes from a serial port or a keyboard.· It knows that the standard output is either a serial port, TV display, VGA display or something else.· It also contains a file system driver, which may talk to an SD card, USB memory stick, additional EEPROM or even use a host file system through a serial port.
The BIOS would contain the pin mappings for the basic I/O functions of standard in, standard out and file system.· It may also contain a real-time clock, which could be implemented by an external device or could be a PASM timer routine.· The BIOS would reside entirely within the first 32K of the boot EEPROM, and would be written in Spin and PASM.· The source for the BIOS would contain various constants that would be configured for a specific platform.· It would also contain a set of standard driver objects mostly written in PASM, which could be selected for a particular platform.· After the BIOS source is properly configured for a particular platform it would be compiled and programmed into the boot EEPROM.
The BIOS would contain a simple monitor program that would allow for setting the time/date and reconfiguring some of the parameters, such as the pin assignements for the installed drivers.· The BIOS will also mount the file system and perform basic file operations, such as checking the disk, formatting, and·booting the DOS from the file system.
The DOS will provide a more sophisticated command-line interace than the BIOS.· It may use the drivers that were installed by the BIOS, or it may load other drivers that replace the functionallity of the BIOS drivers.· It may also load additional drivers to support other peripherals beyond the basic standard I/O and file system drivers.· The DOS will provide extensive file system utilities in the form of executable programs that will run under the operation system.· These will include utilities such as cat, echo, ls, tar, gzip, cd, pwd, od, grep, vi, bash, and other standard linux utilities.· The DOS will pass command-line arguments to the user programs.· It will also provide for standard I/O redirection and I/O pipes.
The BIOS and DOS drivers would be accessable by user programs through a standard mailbox protocol.· User programs could load additional drivers, which could stay resident after the program completes.· Certain drivers would be marked as "dynamic" and could be swapped out if a resource (i.e., COG) is needed by a program, and the current resident dynamic driver is not needed by the OS or user program.· Standard OS source libraries will be available in various languages, such as Spin, C and Basic.
The OS will support multiple concurrent processes through the use of multiple COGS.· The number of processes will be limited by the number of available COGs.
MagIO2 is onto something absolutely brilliant. It encapsulates some things I have been thinking about since I started actually using KyeDOS. Essentially, the eeprom no longer is the repository for much of the information. Once you have decided that an sd card is the place where information is stored, suddenly there are so many more ways to do things. (And I think that is where we are going, right? Sure, an OS can sit in eeprom, but I'm increasingly liking Cluso's idea of only putting the minimum of a program in eeprom eg a fat driver that loads from sd card that then loads and passes control to files on the sd card).
The 'cost' with moving data is when you write to eeprom or sd card, ie it wears those both out. But there is no 'cost' moving data from sd card to propeller ram. You can do it once with a cog load, but you can do it many times. You can load a cog with one bit of code, run it for a short while, then shut it down and reload it with something else. Again, this changes the way you think about using the propeller. The only 'cost' is a slight time delay.
Looking at the last few posts, it seems there are some really nifty ways to create what I call 'cogjects', ie binary files that end in the extension .cog that can be loaded and run as independent entities.
Assuming that does work, I can think of two ways to attach 'variables' like pins and the way data is transferred. You can do it within the .cog file. Or, you could do it with an associated file, maybe a .cgg file, that contains all the relevant data.
A .cgg file can be read with one piece of code that works for all of them. It might contain pin data. It might contain the cog this binary is to be loaded into.
As long as the driver can process commands, such a file could contain large amounts of information. This effectively shifts data from within the .cog binary into another file. And in doing so, it ought to save some space within the cog binary itself - space which we all know is precious. So you could write data 'longhand' eg with lots of text but a generic processor could turn that into shorthand data. eg there "Pin 1 = sd base" could be translated into just one number that goes to a particular location. So .cgg files are much easier to read. Comments are ignored. They are a bit like .bat or .ini or .sys files in Windows.
Even the preprocessor that processes .cgg files can be run in a different way. Load it into a cog, use it to process loading up other cogs by converting verbose text into simple bytes that are poked into hub ram, then finally when it has done its job, throw it away. Load some new data into that cog, like a keyboard driver. This is what you can do when there is no cost associated with moving data from sd card to cog.
I'm going to re-read MagIO2's recent posts again. I don't quite understand them all but I think there are some real gems of ideas in there.
Dave's approach would work very well, however I am taking a different approach.
Both Minos and Largos will only require the eeprom to hold enough of a boot loader to be able to access a file system. The boot loader will leave the low-level SD cog running, with a known mailbox interface.
Until I have time to port my flash file system to SD cards, Minos will use fsrw and 8.3 file names. Largos will wait for the port of my file system.
The reason I am taking this approach is that it does not require a large BIOS, and only the SD driver and pins need to be hard coded into the bootloader.
Minos will use the contents of a "MODULES" file, which will have a list of drivers, followed by parameters to pass to the drivers in a mailbox.
Here is an example "MODULES" file:
# module configuration - mailbox addresses either passed in, or standardized
# to set mailbox address, prefix driver file name with $nnnn for the mailbox hub address
# vga640.cog 16 # the vga driver is commented out
keyboard.cog 24 25
mouse.cog 26 27
tvtext.cog 12 NTSC
vmcog.cog 512KB
(under Largos, the file is /etc/modules)
The idea is that you can use a PC to edit the MODULES file on the SD card for a new platform, and only need to build a simple new bootloader eeprom to be able to boot the SD card.
After loading and launching the drivers, Minos will look for a "INIT.D" file.
Initially, this will be the name of the executable to launch - and the virtual machine to run it on would be determined by the extension.
On a "bare" Minos system, the content of INIT.D would be:
# init.d startup script
sh.zog
(under Largos, the file is /etc/init.d)
I intend to keep a large degree of compatibility between Minos and Largos - I definitely want application-level compatibility.
The reason I've decided to make Minos (Minimum OS) is to have something with a Unix flavor for PropCade, before I have time to finish Largos.
Largos is meant for more capable platforms like Morpheus, and Largos will be LMM/Catalina based, whereas Minos is VMCOG/ZOG/gcc based.
Both Largos and Minos are also intended to come with mpark's outstanding Sphinx compiler, for native Spin development.
The combination of VMCOG and ZOG will allow Minos to run on any hardware that is supported by VMCOG - which I hope will be every platform out there [noparse]:)[/noparse]
Some thoughts ... I like flexibility ... when I think about the propeller and it's possibilities I see boards with only one propeller and some external devices ... and I see multi propeller boards with tons of hardware around.
I see boards which run like any other microcontroller board and I see boards which work more like a general purpose microcomputer does.
For both I want to use the same drivers, but for both I want to use the drivers in a different way. In the microcontroller board I don't want to have a bootloader! For what reason? It doubles load time on startup, as the propeller will always load the full 32kB from EEPROM. So my goal for such a case is to load the whole code with the usual boot procedure. BUT ... to save valuable HUB RAM I want the PASM drivers to be stored in upper EEPROM. And YES, I like upper EEPROM in this case, as the BASIC I2C is only ~130longs whereas the SD card driver has ~800longs. AND the EEPROM is not removable ... it can be write protected ... we need it anyway.
So, having a driver concept here simply gives us additional free HUB-RAM for the application.
To support this a OScore.spin will contain the needed functions. For example:
OBJ
sd: "fsrwFemto_NP"
desc: "OScore"
var
' keep both buffers togther, as cogOScore expects it to be continuous
' first buffer is for storing the sector that contains the list of drivers
' after loading
long buffer[noparse][[/noparse] BUFFER_SIZE ]
' second buffer is for loading a driver
long ld_buffer[noparse][[/noparse] LD_BUFFER_SIZE ]
PUB main
' tell the core which memory to use for reading the descriptor
' and for loading the driver
desc.init( @buffer )
' now load the SD driver with name/version
tmp := desc.loadDriver( string( "SDcard" ) , $0170 )
' tell the SPIN part of the driver the location of the parameter buffer
sd.start(@ioControl,@ld_buffer)
' start the driver
i:=cognew( @ld_buffer, @ioControl )
' now all usual SD functions can be called
sd.popen( .... )
After loading all needed drivers the buffers can be used differently.
For a microcomputer system the OS will be booted and different kind of applications will be started on demand. (Of course·the OS will·use OScore itself to load the drivers). To support that, the drivers need to be managed ... and need to be managable! For example:
Your system is booting. The OS needs the FullDuplex for user I/O·and the SD driver for file access. Then you want to start an application A. This needs no user I/O, but SD card and an A/D driver. Additional HUB-RAM can be freed, if the application itself does not have to load the drivers (no load buffer needen, no I2C needed, no load code needed). This is done by the OS before starting the application. Again the application only needs a OScore (maybe a different one) to find out all it needs to know about the driver.
Now application A is done and you want to run application B. This needs TV, no SD and·Keyboard.
That's why·I think a short DYNAMIC descriptor table would be usefull.
Another kind of application might be very huge but·not all the code is running at the same time.·(For example my home automation system, which is the goal of all of my effords ;o)·It'll have a menu system which starts sub-programs. The needed drivers will stay, the others might be replaced according to the functional area.
In this case EEPROM might be to small for all the drivers, so another COGcore module also supports to load the COGs from SDcard.
BradC said...
Or use bstc -c which will write a straight binary dump of only the DAT section from the top object. No header, no method tables, no spin, no sub-objects.
Nice Brad
heater said...
My observation is that "rendezvous" is much the same idea as Bill Hennings mail-boxes and whatever is used in BoeBotBasic. Bill would like to keep mail boxes at the bottom of HUB RAM for a number of reasons though.
My second observation is that having binary blob drivers in COG that communicate through HUB "rendezvous" or "mailboxes" or whatever has another great advantage. They are no longer dependent on Spin. Or any particular language for that matter. COG code written this way has the possibility to communicate with other COG codes via the mailbox/rendezvous without having to go through a Spin layer.
Further more it becomes possible to use those same COG drivers from different languages like C provided by Catalina LMM or Zog. Or BASIC or from various Z80 and other emulators or whatever comes up.
All in all decoupling these low level drivers from Spin access functions is an excellent idea.
Exactly!
Bill said...
But the idea was that the last page ($7E00-$7FFF) could be left unused for SphinxOS compatibility.
I strongly recommend NOT fixing the screen buffer addresses, and only keeping rendezvous locations and pointers in the last page for SphinxOS
Agreed. We do not want to fix the screen location, nor it's size. A quick call via rendezvous will return the location and size from the pasm cog.
Bill said...
rendezvous locations are two longs, like Cluso says, whereas mailboxes are four longs.
Not quite. Rendezvous can be a single long if the driver is uni-directional as in a keyboard.
Dave said...
The operating system should be seperated into a BIOS and a DOS.· The BIOS is loaded from EEPROM and it provides very basic functionality for setting up the standard input, standard output and the file system.· A BIOS is specific to each platform.· It knows whether the standard input comes from a serial port or a keyboard.· It knows that the standard output is either a serial port, TV display, VGA display or something else.· It also contains a file system driver, which may talk to an SD card, USB memory stick, additional EEPROM or even use a host file system through a serial port.
No, I think the BIOS and DOS you refer to should be a DOS style. Why? Because the OS may have to ask which drivers to load today. Suppose you have a pluggable device (e.g. A TV and a VGA) which share the same pins. The OS will need to load the correct driver for the hardware that is plugged in. (another cat out of the bag).
Dave said...
The DOS will provide a more sophisticated command-line interace than the BIOS.·It may use the drivers that were installed by the BIOS, or it may load other drivers that replace the functionallity of the BIOS drivers.· It may also load additional drivers to support other peripherals beyond the basic standard I/O and file system drivers.· The DOS will provide extensive file system utilities in the form of executable programs that will run under the operation system.· These will include utilities such as cat, echo, ls, tar, gzip, cd, pwd, od, grep, vi, bash, and other standard linux utilities.· The DOS will pass command-line arguments to the user programs.· It will also provide for standard I/O redirection and I/O pipes.
This is the idea. Sphinx/SphinxOS already does the dir, ren, del, etc as utilities. This makes it easy to add new utilities easily. Maybe someone wants a special list that only shows a particular set of extensions, but does not want to type DIR *.xyz all the time. Here, it is simple to add. So are various file transfers, etc.
Drac mentions the wear issue. If the Sd card wears out, we replace it. If the EEPROM wears out and it is smt (or soldered) it may be goodbye to the pcb!
mpark said: Just to give credit/blame where it's due, I got the term "rendezvous" from rokicki's fsrw. - OK so I will blame him too! LOL
Bill said...
Both Minos and Largos will only require the eeprom to hold enough of a boot loader to be able to access a file system. The boot loader will leave the low-level SD cog running, with a known mailbox interface.
.............only the SD driver and pins need to be hard coded into the bootloader.
This is what I am promoting and do in the RamBlade. Currently I am using SD·femto and it needs to change to support FAT32.·The only difference is I do not leave the low level SD cog running because·that seems to be changing and I do not want to change the EEPROM EVER. So the SD driver is·loaded as part of the first·boot program loaded from the SD card.
@MagIO:
I do see your difference between a microcontroller and a microcomputer. The microcontroller·most likely does not have an SD card anyway. This is just a different way of doing the same thing but using EEPROM.
What I see you explaining next is a complex system that could be done or extended later. I am preferring to walk first.
Postedit: One last thought. The code loaded from SD card is only the length required, and the remainder of hub is cleared (to the bottom of the rendezvous hub later). So, the OS is loaded quicker than you may expect. The EEPROM of course is first loaded (on boot) for the full 32KB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I think we can blame Jean Ichbiah and co. the designers of the ADA language for "rendezvous".
From the ADA documentation:
"The Rendezvous is the basic mechanism for synchronization and communication of Ada tasks. The model of Ada is based on a client/server model of interaction. One task, the server, declares a set of services that it is prepared to offer to other tasks (the clients). It does this by declaring one or more public entries in its task specification. A rendezvous is requested by one task making an entry call on an entry of another task. For the rendezvous to take place the called task must accept this entry call. During the rendezvous the calling task waits while the accepting task executes. When the accepting task ends the rendezvous both tasks are freed to continue their execution"
and
"Each entry identifies the name of the service, the parameters that are required with the request and the results that will be returned"
"Rendezvous" is also used in the Plan 9 operating system form Bell Labs:
"Rendezvous is a data synchronization mechanism in Plan 9 from Bell Labs. It is a system call that allows two processes to exchange a single data item while synchronizing."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Not everyone needs a screen buffer. An O/S that can be used by everyone will have dynamically managed resources.
I need every single byte I can get from Propeller hub memory. Some static declarations, but not all, make sense for operational simplicity especially regarding pointers to COG interfaces, etc.... I see no provision for passing program parameters or exit status. Do you have any plans at all for that?
It is truly not necessary to hog up so much of Propeller HUB. Perhaps you would consider something smaller like this?
' minimalist 64 byte interface / rendevous structure
_HubTop_ptr = $8000 - 1 * 4 'stores the top of hub used ... i.e. the heap pointer
_StdOut_ptr = _HubTop_ptr - 1 * 4 'pointer to stdout data structure
_StdIn_ptr = _StdOut_ptr - 1 * 4 'pointer to stdin data structure
_SD_ptr = _StdIn_ptr - 1 * 4 'pointer to sd or other storage interface data structure
_COG1_ptr = _SD_ptr - 1 * 4 'pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG2_ptr = _COG1_ptr - 1 * 4 'pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG3_ptr = _COG2_ptr - 1 * 4 'pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG4_ptr = _COG3_ptr - 1 * 4 'pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG5_ptr = _COG4_ptr - 1 * 4 'pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG6_ptr = _COG5_ptr - 1 * 4 'pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG7_ptr = _COG6_ptr - 1 * 4 'pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG8_ptr = _COG7_ptr - 1 * 4 'pointer to cog[noparse][[/noparse]n] interface/other data structure
_ProgParm_ptr = _COG8_ptr - 1 * 4 'pointer to program parameters and exit status value
_Misc_ptr = _ProgParm_ptr - 1 * 4 'pointer to miscellaneous system info not covered above
_Heap_ptr = _Misc_ptr - 1 * 4 'top of user memory data-space below system _Misc_ptr data
For those of you who do not know, a simple data structure is a definition in a block of memory of bytes/words/longs used for efficient storage and pointers to data structures are often used to enable flexibility. A good general definition of data structure with pointers to most of its incarnations can be found in wikipedia en.wikipedia.org/wiki/Data_structure The wiki page goes into abstract data types also, but very few of those will be used in Propeller.
--
I'm not interested in some kind of an O/S hissing contest. The term O/S is being used rather loosely in any case.
Primarily, what I am interested in is making Java2 possible on Propeller and I do not need a generalized O/S to make that happen; I do need every available byte though. Secondarily I'm interested in contributing to a shell program which potentially could be used on any O/S. Finally I'm interested in having an O/S that is *nix like (but not necessarily fully POSIX compliant) because it is easily comprehensible by most educated software engineers and can lift up the coders who care to learn.
For Java2 on Propeller vmcog and a file-system with directory/long file name support is necessary. If both Minos and Sphinx both allow this, that's great. If only Minos allows it, that's fine too. If neither allow for it, I'm bright enough to do it with current resources without anyone's help.
A shell program is necessary to do big things in a small system (in DOS it's called a batch). Just being able to run programs sequentially from a command prompt without human intervention is a big help. Being able to make decisions and do while loops based on system status, etc... provides power since different programs can be loaded as necessary. This allows for big applications on a small controller. Without some kind of a shell an O/S is not an O/S (of course there are other things that define an O/S).
Since Linux is an "impossibility" on Propeller having an O/S that works like Linux or other *nix is attractive to facilitate rapid development and maintainable deployment. I believe that a *nix like O/S is the best solution for serious users. Any O/S definition is fine I'm sure, but I prefer something easily comprehensible/maintainable for a long term product.
So, that's where I stand. I don't need an O/S or anyone's help from this forum to reach my goals, but if something sane exists, there's nothing wrong with using it with adherence to license.
Cheers,
--Steve
Changed "p*ing" to "hissing" to avoid forum intolerance issues.
Comments
The BoeBotBasic drivers are already modified to use this scheme and include a version of FullDuplexSerial, sdspiFemto (low-level I2C and SPI driver). The PropellerOS includes VGA and TV text drivers and a PS/2 keyboard driver, all modified from Chip's code to use this memory layout scheme.
Post Edited (Mike Green) : 6/11/2010 2:24:46 AM GMT
So you're suggesting hard-coding everything then or what? Show a picture your example.
Using a linked list or some other pointer management scheme allows for flexibility and
provides a way for applications to know where their part of the "heap" can begin. This
is especially important since you appear to want a piece of upper memory to remain intact.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Are you referring to this? http://forums.parallax.com/showthread.php?p=598350
It seems to me that someone interested in an O/S should be building on your work unless there are other motives.
@Dr_A,
Maybe you would care to describe for us the classical meaning of Top-Down Design so everyone may know that too?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
That's what I was referring to. It's 4 years old from way before SD cards came into use on the Propeller, but the ideas are sound, still applicable, and similar to things others have proposed. I bring it up because there may be some pieces of value in it as people puzzle out a direction for some of the future Propeller development based on current experience.
Yes, sorry, I should clarify that. There is;
1) the formal description en.wikipedia.org/wiki/Top-down_and_bottom-up_design
2) There is the practical 'hands on' explanation. Start with
then add
(which is how I tend to start my software projects)
3) and then there is a picture with some terribly nerdy humour, from an electronics magazine from years ago where they took a real picture and added a silly caption. The picture was of an attractive female data entry operator in early '70s attire sitting in front of an old computer that had covered her in reams of punched paper tape. The 'new' caption read 'Top Down Programming sure is fun, so long as you know which is the top".
@ Mike Green, it sounds like some of this work is already done? Off to check it out now...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I think a Pin-Map would be nice for when you want to make some sort of executable that can just be compiled to .bin, dropped on an SD card and runs on any hardware configuration.
I personally see the propeller more like a small single chip computing platform then a micro-controller. With the PropII this computer type use will be even more common place.
Having high RAM locations for shared drivers works well if your writing some sort of command line type program that shares the same interface as the OS, but sometimes a program will want to take full control of the hardware, Start custom video drivers, load up sound drivers, etc.
As for the whole File System matter.
I personally feel that FAT should be supported! The luxury of just being able to drop files on to SD from any Computer, PDA, Mp3 player, Cellphone or Camera is amazing. Files can be downloaded off of the internet and just dropped onto SD card for execution on the prop. :]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
Drac: It has nothing to do with Top Down or Bottom Up which is a coding method. This is to seperate the OS and drivers from the "program".
I have used the term "rendezvous" because mpark coined that in Sphinx and it sounded good to me. There are already TV, Keyboard, PC (simulating TV and Keyboard) and 1pin TV and TV drivers already done. As I said SD needs changing. The rendezvous locations need pushing down to make room for the "free" pointer.
The space to load a cog is not that great and could be done by an OS aware program anyway, so a buffer in top hub would not be required.
Below is a later proposed list of rendezvous locations. Here is a link which proposed a list of rendezvous locations and is based primarily on Sphinx.·http://propeller.wikispaces.com/Sphinx and here for a more detailed discussion on SphinxOS http://forums.parallax.com/showthread.php?p=819353·However, to accomodate the buffers and rendezvous that may be required for extra drivers (the SD driver currently used in Sphinx requires many rendezvous locations - this needs a rewrite and to use the bottom level fsrw 2.6 driver or similar), we need to know where the free space starts. It is best to have this in a fixed place of $7FFF.
[/code][/size]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I think we have 2 kind of uses for an OS:
1. the OS is doing what every OS is doing - namely it provides a full set of services to allow programs to use them.
Here the OS would be started as the main-application on boot. Then the OS loads all necessary drivers for itself to operate. With something lika an AUTOSTART.CB (Cog batch ;o) you can for example start a menu system which lists all installed applications to choose from. When starting an application the OS in advance makes sure that all drivers needed by the application are loaded and running. Thus the application does not need code for drivers or for loading and starting drivers. The information on what drivers are needed could be saved in a *.INI file, where * has the same name as the application.
2. the OS is not meant to run in the end-product. Thus it's only a tool to make development easier (file up-/download, edit files on the system, maybe compile ....) and more flexible (use the same development plattform for different projects with different hardware simply by loading different drivers).
Here the OS itself is not part of the software to be installed on the end-product. The firmware will only use a OScore.spin for example for loading the drivers.
Guess I already mentioned it: Currently I have some code which creates a descriptor table at the end of upper EEPROM. (Of course it could also be shifted to the end of boot-loader EEPROM) The descriptor table contains a name, the version, the number of longs the message-/video- or whatever-buffer needs for each installed driver. A driver can simply be loaded by name and version number. The code for loading is extracted to a CogOScore.spin. I like the idea to extend it to also use the SD card for loading drivers.
For *.COG files I'd suggest to add some more data. My *.COG file currently contains a length and the binary dump of the PASM-code. But plans are to add more information, like the version number, the number of longs needed for message-/video- or whatever-buffer (like I have it in the EEPROM descriptor table). More? Who knows ;o)
The CogOScore has no own buffer for loading the driver, so it needs to be passed as parameter by the application. This allows the application to use the buffer otherwise when done with driver-load.
For some usecases it might be good to have a COG descriptor table in the upper HUB RAM which describes which COG runs which driver currently. But I think this should be optional. If the application fits into one 32kB image there is no need to have it. If the application is split up into several sub-systems it's cool if the startup-code can simply have a look at the table and see which drivers run and where the message buffers are placed.
@Ym2413:
If we have a driver concept that's not needed. The application won't have any driver code. It loads the pre-compiled drivers from somewhere (EEPROM or *.COG files) - that's it.
Why would you like to have a fixed rendevouz-table? The systems we build based on the propeller are to different. I'd propose to have a descriptor-table.
To keep it short the runtime descriptor table does not use full driver names (as they are available in EEPROM descriptor or *.COG meta-data), but hash values build out of driver name and version number (1 long). This is followed by the message-buffer address (1 word) and the size (1 word). If additional buffers are needed they simply follow the message buffer and increase the given size.
With this information every application can see if a required driver is loaded and knows where to send commands to it.
Maybe later on we could have drivers which have commands for suspend and resume.
There is talk of "rendezvous" for low level drivers which run in COGs (and other codes like file systems?). If I understand the "rendezvous" idea correctly it's like this: Most drivers nowadays are coded in PASM and then provide access methods in Spin. The Spin and DAT blob for the driver are intermixed in a Spin file and use up HUB space permanently . In the "rendezvous" idea the driver PASM is a binary blob that can be read from anywhere (SD, EEPROM etc) and set running in a COG. One then communicates with it via some HUB memory, the "rendezvous". This is great because it frees up HUB memory which can be reused after the COG is loaded.
My observation is that "rendezvous" is much the same idea as Bill Hennings mail-boxes and whatever is used in BoeBotBasic. Bill would like to keep mail boxes at the bottom of HUB RAM for a number of reasons though.
My second observation is that having binary blob drivers in COG that communicate through HUB "rendezvous" or "mailboxes" or whatever has another great advantage. They are no longer dependent on Spin. Or any particular language for that matter. COG code written this way has the possibility to communicate with other COG codes via the mailbox/rendezvous without having to go through a Spin layer.
Further more it becomes possible to use those same COG drivers from different languages like C provided by Catalina LMM or Zog. Or BASIC or from various Z80 and other emulators or whatever comes up.
All in all decoupling these low level drivers from Spin access functions is an excellent idea.
I'd like to introduce the use of the word "firmware" to describe these binary blobs intended to load and start in COGs. Basically the model is that one loads the "firmware" for say UART into a COG and starts it. Then one accesses it via "registers" in HUB space. Just like you do on a normal micro-controller with built in memory mapped peripherals. With this in place it matters not what language you are using.
Edit: By last observation is that with the COG code as "firmware" idea in place it decouples the driver codes from the operating system as well as the language used. Many hardware devices today in the PC world rely on firmware being loaded into them before they will work. WIFI chip sets for example. It matters not if that is done from Windows or Linux or BSD or whatever.
So properly defined "firmware" for COGs will work anywhere, you only have to tell it where it's mailbox/rendezvous/whatever is when it is started. cognew(@somefirmawareblob, @somerendezvous)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 6/11/2010 10:00:09 AM GMT
In an ideal world a cog might only have a couple of rendevous bytes. In the real world, as the example above shows, the number grows. The table could end up containing data for cogjects that are not even used. Potentially the list of unused cogjects could be every object in the obex. There might be no hub ram left once all these (unused) rendevous points are loaded.
MagIO2's idea solves that. If you load 7 cogjects, whatever loaded them would be able to create a list of their rendevous points and act as a redirector for that cogject. A calling routine passes the name of the cogject, and the name of the variable (or they could be numbered to speed things up). It then does the lookup.
MagIO2's descriptor table idea replicates the 'glue' that is currently done in spin code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
But I still don't see how a program (or in this case the driver) would know which pin it should output to without some sort of pre-defined pin mapping. Are we saying that we write a different version of each .COG for each pin? Then you get back into the issue of what defines the PIN for each .COG driver?
Wouldn't want to see:
Demoboard_40hcharNTSC.COG
Pin16_40hcharNTSC.COG
Hybrid_40hcharPAL.COG
The driver would have to be started with some sort of pre-defined pin mapping coming from the OS its self.
I guess that wouldn't be too hard to manage. :]
OS could start the drivers with a lookup table of where each pin is.
Don't mind me, I'm just thinking out loud.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
I imagine that a binary driver firmware blob is obtained from somewhere, SD card say. It is saved to a temporary buffer. From there a it can be used to start a COG and then the buffer can be reused.
The mailbox/rendezvous block is used during normal running for exchanging commands/data/status BUT during that initial start of the COG the mailbox/rendezvous block can be used to pass pin definitions to the driver. If need be one or more of the mailbox/rendezvous fields can be used during start up as a pointer to a pin table or any other data the COG needs to be aware of.
What I want to know is how do we compile such PASM only firmware to binary blobs?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Until some kind of feature is added to the Propeller Tool and/or the other Spin compiler/assemblers, the I/O drivers would have to be compiled in a wrapper of some sort that either writes them out to areas of EEPROM above 32K or writes them to SD card files. You'd load this program to RAM and execute it to initialize your system for use with the OS, then load the OS itself to EEPROM (the 1st 32K).
Simple ... just put a small wrapper SPIN around it, which saves it as COG-file to the SD-card. You send that program to the Propeller once for execution and viola ... there you have the COG-file.
@ym2413a:
I think each driver should have a set of commands which are common for all drivers. Such like NOP, ERR, SET_BUFFER, SET_PIN_BASE, SUSPEND ... whatever comes into our mind. Let's say we reserve the first 256 numbers for such gereral purpose stuff.
NOP = 0 means no command send. It's set by the user of the driver to another value and the driver will set it back to 0 or 1 when done.
ERR = 1 means error occurred or function not supported. If the driver has to report more error states that's done in the following message buffer long.
That would be a driver model which allows all possibilities. Drivers that allow to set the pin and drivers with pre-compiled pins.
I personally like the precompiled version, as setting a pin-number only adds code for a flexibility that's not really needed in a finished hardware setup! I don't mind compiling the driver twice. The drivers for common boards could be packed into the code package precompiled. Maybe a driver management software can be written to extend the PropellerTool.
I already suggested to have a driver pin base .spin file which only has constants for the PIN-base of every driver you might want to use.
CON
PIN_BASE_TV = 4
PIN_BASE_SD = 0
...
Any kind of driver that drives a TV would simply use that PIN_BASE_TV constant.
All that is required is to write a "PUB start" at the beginning to satisfy the compiler, BST anyway. Then go straight into your PASM code. Then do "compile and save a binary". Use the file name of you choice "uart.cog" for example. The resulting binary has 16 bytes you don't need at the beginning and 4 at the end. These could be easily removed or just leave them there and ignore them when loading the *.cog at run time.
For example:
PUB start DAT enter mov a, b mov a, b mov a, b mov a, b mov a, b mov a, b mov a, b a long 0 b long 0produces this in the .cog file:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This method allows programs such as CPM emulation to use the rendezvous without knowing if it is talking to a TV or VGA or serial output·and the same with input from a keyboard or serial, nor does it need to know which pins are used. It does not matter if it is 1pin or standard keyboard or TV. This means a single binary can be shipped, depending on of course, the SRAM implementation.
There is nothing complex about this which is why I like it so much. mpark designed the original rendezvous idea (or at least that is where I saw it) and it is only a slight extension to what objects do now. No need for complex tables and parameters. KISS.
You all really should look at Sphinx because I seem to be losing something in the translation - or is it that you are trying to create a monster, or am I missing something??? I am after the most hub free for the app program and minimal hub overhead.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 6/11/2010 1:33:12 PM GMT
Umm... LAS will assemble them just fine ... well it should, anyway, it passed my test suite. It is however still missing expressions and macro's.
I do plan on resuming work on it (and PropellerBasic) after UPEW.
The memory map I am using for Minos (single user, cut down version of Largos, uses VMCOG) is:
$0000-$01FF - reserved for OS and mailboxes
$0200-$07FF - reserved for VMCOG
$0800-$0FFF - reserved for 2KB cog load area / file system buffers
$1000-$7FFF - user ram, normally used as a 56 page working set for VMCOG
But the idea was that the last page ($7E00-$7FFF) could be left unused for SphinxOS compatibility.
I strongly recommend NOT fixing the screen buffer addresses, and only keeping rendezvous locations and pointers in the last page for SphinxOS
rendezvous locations are two longs, like Cluso says, whereas mailboxes are four longs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Or use bstc -c which will write a straight binary dump of only the DAT section from the top object. No header, no method tables, no spin, no sub-objects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Lets say you are creating an emulator ZiCog, yZ80, Zog whatever. Often there is a need for a jump table. These tables are full of addresses of functions in the DAT block. Often these tables are not to be loaded to COG but used from HUB.
This kind of problem could also arise outside the emulator world. For example if your COG code can get a lot of different commands through it's mail box and a jump table in COG is used to find the PASM code section to handle the command.
So there is the problem, to extract the portion of DAT that should be loaded to COG and the portion that should be loaded to HUB somewhere. Of course this can be done by some post processing of the binary with some custom script or whatever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The operating system should be seperated into a BIOS and a DOS.· The BIOS is loaded from EEPROM and it provides very basic functionality for setting up the standard input, standard output and the file system.· A BIOS is specific to each platform.· It knows whether the standard input comes from a serial port or a keyboard.· It knows that the standard output is either a serial port, TV display, VGA display or something else.· It also contains a file system driver, which may talk to an SD card, USB memory stick, additional EEPROM or even use a host file system through a serial port.
The BIOS would contain the pin mappings for the basic I/O functions of standard in, standard out and file system.· It may also contain a real-time clock, which could be implemented by an external device or could be a PASM timer routine.· The BIOS would reside entirely within the first 32K of the boot EEPROM, and would be written in Spin and PASM.· The source for the BIOS would contain various constants that would be configured for a specific platform.· It would also contain a set of standard driver objects mostly written in PASM, which could be selected for a particular platform.· After the BIOS source is properly configured for a particular platform it would be compiled and programmed into the boot EEPROM.
The BIOS would contain a simple monitor program that would allow for setting the time/date and reconfiguring some of the parameters, such as the pin assignements for the installed drivers.· The BIOS will also mount the file system and perform basic file operations, such as checking the disk, formatting, and·booting the DOS from the file system.
The DOS will provide a more sophisticated command-line interace than the BIOS.· It may use the drivers that were installed by the BIOS, or it may load other drivers that replace the functionallity of the BIOS drivers.· It may also load additional drivers to support other peripherals beyond the basic standard I/O and file system drivers.· The DOS will provide extensive file system utilities in the form of executable programs that will run under the operation system.· These will include utilities such as cat, echo, ls, tar, gzip, cd, pwd, od, grep, vi, bash, and other standard linux utilities.· The DOS will pass command-line arguments to the user programs.· It will also provide for standard I/O redirection and I/O pipes.
The BIOS and DOS drivers would be accessable by user programs through a standard mailbox protocol.· User programs could load additional drivers, which could stay resident after the program completes.· Certain drivers would be marked as "dynamic" and could be swapped out if a resource (i.e., COG) is needed by a program, and the current resident dynamic driver is not needed by the OS or user program.· Standard OS source libraries will be available in various languages, such as Spin, C and Basic.
The OS will support multiple concurrent processes through the use of multiple COGS.· The number of processes will be limited by the number of available COGs.
The 'cost' with moving data is when you write to eeprom or sd card, ie it wears those both out. But there is no 'cost' moving data from sd card to propeller ram. You can do it once with a cog load, but you can do it many times. You can load a cog with one bit of code, run it for a short while, then shut it down and reload it with something else. Again, this changes the way you think about using the propeller. The only 'cost' is a slight time delay.
Looking at the last few posts, it seems there are some really nifty ways to create what I call 'cogjects', ie binary files that end in the extension .cog that can be loaded and run as independent entities.
Assuming that does work, I can think of two ways to attach 'variables' like pins and the way data is transferred. You can do it within the .cog file. Or, you could do it with an associated file, maybe a .cgg file, that contains all the relevant data.
A .cgg file can be read with one piece of code that works for all of them. It might contain pin data. It might contain the cog this binary is to be loaded into.
As long as the driver can process commands, such a file could contain large amounts of information. This effectively shifts data from within the .cog binary into another file. And in doing so, it ought to save some space within the cog binary itself - space which we all know is precious. So you could write data 'longhand' eg with lots of text but a generic processor could turn that into shorthand data. eg there "Pin 1 = sd base" could be translated into just one number that goes to a particular location. So .cgg files are much easier to read. Comments are ignored. They are a bit like .bat or .ini or .sys files in Windows.
Even the preprocessor that processes .cgg files can be run in a different way. Load it into a cog, use it to process loading up other cogs by converting verbose text into simple bytes that are poked into hub ram, then finally when it has done its job, throw it away. Load some new data into that cog, like a keyboard driver. This is what you can do when there is no cost associated with moving data from sd card to cog.
I'm going to re-read MagIO2's recent posts again. I don't quite understand them all but I think there are some real gems of ideas in there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 6/11/2010 2:26:46 PM GMT
Both Minos and Largos will only require the eeprom to hold enough of a boot loader to be able to access a file system. The boot loader will leave the low-level SD cog running, with a known mailbox interface.
Until I have time to port my flash file system to SD cards, Minos will use fsrw and 8.3 file names. Largos will wait for the port of my file system.
The reason I am taking this approach is that it does not require a large BIOS, and only the SD driver and pins need to be hard coded into the bootloader.
Minos will use the contents of a "MODULES" file, which will have a list of drivers, followed by parameters to pass to the drivers in a mailbox.
Here is an example "MODULES" file:
(under Largos, the file is /etc/modules)
The idea is that you can use a PC to edit the MODULES file on the SD card for a new platform, and only need to build a simple new bootloader eeprom to be able to boot the SD card.
After loading and launching the drivers, Minos will look for a "INIT.D" file.
Initially, this will be the name of the executable to launch - and the virtual machine to run it on would be determined by the extension.
On a "bare" Minos system, the content of INIT.D would be:
(under Largos, the file is /etc/init.d)
I intend to keep a large degree of compatibility between Minos and Largos - I definitely want application-level compatibility.
The reason I've decided to make Minos (Minimum OS) is to have something with a Unix flavor for PropCade, before I have time to finish Largos.
Largos is meant for more capable platforms like Morpheus, and Largos will be LMM/Catalina based, whereas Minos is VMCOG/ZOG/gcc based.
Both Largos and Minos are also intended to come with mpark's outstanding Sphinx compiler, for native Spin development.
The combination of VMCOG and ZOG will allow Minos to run on any hardware that is supported by VMCOG - which I hope will be every platform out there [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 6/11/2010 4:52:34 PM GMT
I see boards which run like any other microcontroller board and I see boards which work more like a general purpose microcomputer does.
For both I want to use the same drivers, but for both I want to use the drivers in a different way. In the microcontroller board I don't want to have a bootloader! For what reason? It doubles load time on startup, as the propeller will always load the full 32kB from EEPROM. So my goal for such a case is to load the whole code with the usual boot procedure. BUT ... to save valuable HUB RAM I want the PASM drivers to be stored in upper EEPROM. And YES, I like upper EEPROM in this case, as the BASIC I2C is only ~130longs whereas the SD card driver has ~800longs. AND the EEPROM is not removable ... it can be write protected ... we need it anyway.
So, having a driver concept here simply gives us additional free HUB-RAM for the application.
To support this a OScore.spin will contain the needed functions. For example:
After loading all needed drivers the buffers can be used differently.
For a microcomputer system the OS will be booted and different kind of applications will be started on demand. (Of course·the OS will·use OScore itself to load the drivers). To support that, the drivers need to be managed ... and need to be managable! For example:
Your system is booting. The OS needs the FullDuplex for user I/O·and the SD driver for file access. Then you want to start an application A. This needs no user I/O, but SD card and an A/D driver. Additional HUB-RAM can be freed, if the application itself does not have to load the drivers (no load buffer needen, no I2C needed, no load code needed). This is done by the OS before starting the application. Again the application only needs a OScore (maybe a different one) to find out all it needs to know about the driver.
Now application A is done and you want to run application B. This needs TV, no SD and·Keyboard.
That's why·I think a short DYNAMIC descriptor table would be usefull.
Another kind of application might be very huge but·not all the code is running at the same time.·(For example my home automation system, which is the goal of all of my effords ;o)·It'll have a menu system which starts sub-programs. The needed drivers will stay, the others might be replaced according to the functional area.
In this case EEPROM might be to small for all the drivers, so another COGcore module also supports to load the COGs from SDcard.
Post Edited (MagIO2) : 6/11/2010 10:46:25 PM GMT
Exactly!
Agreed. We do not want to fix the screen location, nor it's size. A quick call via rendezvous will return the location and size from the pasm cog.
Not quite. Rendezvous can be a single long if the driver is uni-directional as in a keyboard.
No, I think the BIOS and DOS you refer to should be a DOS style. Why? Because the OS may have to ask which drivers to load today. Suppose you have a pluggable device (e.g. A TV and a VGA) which share the same pins. The OS will need to load the correct driver for the hardware that is plugged in. (another cat out of the bag).
This is the idea. Sphinx/SphinxOS already does the dir, ren, del, etc as utilities. This makes it easy to add new utilities easily. Maybe someone wants a special list that only shows a particular set of extensions, but does not want to type DIR *.xyz all the time. Here, it is simple to add. So are various file transfers, etc.
Drac mentions the wear issue. If the Sd card wears out, we replace it. If the EEPROM wears out and it is smt (or soldered) it may be goodbye to the pcb!
mpark said: Just to give credit/blame where it's due, I got the term "rendezvous" from rokicki's fsrw. - OK so I will blame him too! LOL
This is what I am promoting and do in the RamBlade. Currently I am using SD·femto and it needs to change to support FAT32.·The only difference is I do not leave the low level SD cog running because·that seems to be changing and I do not want to change the EEPROM EVER. So the SD driver is·loaded as part of the first·boot program loaded from the SD card.
@MagIO:
I do see your difference between a microcontroller and a microcomputer. The microcontroller·most likely does not have an SD card anyway. This is just a different way of doing the same thing but using EEPROM.
What I see you explaining next is a complex system that could be done or extended later. I am preferring to walk first.
Postedit: One last thought. The code loaded from SD card is only the length required, and the remainder of hub is cleared (to the bottom of the rendezvous hub later). So, the OS is loaded quicker than you may expect. The EEPROM of course is first loaded (on boot) for the full 32KB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 6/12/2010 4:26:02 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
From the ADA documentation:
"The Rendezvous is the basic mechanism for synchronization and communication of Ada tasks. The model of Ada is based on a client/server model of interaction. One task, the server, declares a set of services that it is prepared to offer to other tasks (the clients). It does this by declaring one or more public entries in its task specification. A rendezvous is requested by one task making an entry call on an entry of another task. For the rendezvous to take place the called task must accept this entry call. During the rendezvous the calling task waits while the accepting task executes. When the accepting task ends the rendezvous both tasks are freed to continue their execution"
and
"Each entry identifies the name of the service, the parameters that are required with the request and the results that will be returned"
"Rendezvous" is also used in the Plan 9 operating system form Bell Labs:
"Rendezvous is a data synchronization mechanism in Plan 9 from Bell Labs. It is a system call that allows two processes to exchange a single data item while synchronizing."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
IMHO, you should consider writing a feature specification.
That would provide: 1) a definition of the "O/S" and 2) a list items that contributors can develop.
As for your system interface reference ....
Not everyone needs a screen buffer. An O/S that can be used by everyone will have dynamically managed resources.
I need every single byte I can get from Propeller hub memory. Some static declarations, but not all, make sense for operational simplicity especially regarding pointers to COG interfaces, etc.... I see no provision for passing program parameters or exit status. Do you have any plans at all for that?
It is truly not necessary to hog up so much of Propeller HUB. Perhaps you would consider something smaller like this?
For those of you who do not know, a simple data structure is a definition in a block of memory of bytes/words/longs used for efficient storage and pointers to data structures are often used to enable flexibility. A good general definition of data structure with pointers to most of its incarnations can be found in wikipedia en.wikipedia.org/wiki/Data_structure The wiki page goes into abstract data types also, but very few of those will be used in Propeller.
--
I'm not interested in some kind of an O/S hissing contest. The term O/S is being used rather loosely in any case.
Primarily, what I am interested in is making Java2 possible on Propeller and I do not need a generalized O/S to make that happen; I do need every available byte though. Secondarily I'm interested in contributing to a shell program which potentially could be used on any O/S. Finally I'm interested in having an O/S that is *nix like (but not necessarily fully POSIX compliant) because it is easily comprehensible by most educated software engineers and can lift up the coders who care to learn.
For Java2 on Propeller vmcog and a file-system with directory/long file name support is necessary. If both Minos and Sphinx both allow this, that's great. If only Minos allows it, that's fine too. If neither allow for it, I'm bright enough to do it with current resources without anyone's help.
A shell program is necessary to do big things in a small system (in DOS it's called a batch). Just being able to run programs sequentially from a command prompt without human intervention is a big help. Being able to make decisions and do while loops based on system status, etc... provides power since different programs can be loaded as necessary. This allows for big applications on a small controller. Without some kind of a shell an O/S is not an O/S (of course there are other things that define an O/S).
Since Linux is an "impossibility" on Propeller having an O/S that works like Linux or other *nix is attractive to facilitate rapid development and maintainable deployment. I believe that a *nix like O/S is the best solution for serious users. Any O/S definition is fine I'm sure, but I prefer something easily comprehensible/maintainable for a long term product.
So, that's where I stand. I don't need an O/S or anyone's help from this forum to reach my goals, but if something sane exists, there's nothing wrong with using it with adherence to license.
Cheers,
--Steve
Changed "p*ing" to "hissing" to avoid forum intolerance issues.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Post Edited (jazzed) : 6/12/2010 6:25:21 PM GMT
I am about to try porting SphinxOS to PropCade... is v0.11c that I found at http://forums.parallax.com/forums/default.aspx?f=25&p=8&m=363645
by following the link in your sig the latest version?
Thanks,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system