Both ideas for the rendevous location have merits.· A simple array is easier to understand and debug.· A list of pointers to data structures is more flexible.· A linked list would be even more flexible.· However, more levels of indirection make it harder to debug and maintain.· When one of the apps or drivers steps on a data structure it can be quite difficult to figure out who did it.
With that being said, data buffers should not be part of the rendevous location.· Therefore I would lean toward a list of pointers to data structures.
My earlier description of the OS being made up of a BIOS and a DOS may be confusing.· The BIOS is really the basic plumbing, which sets up the rendevous area and loads basic drivers for standard in, standard out and the file system.· I think it should also include a heap manager and a real-time clock.· The DOS is really nothing more than a shell command-line interpreter and a bunch of utilities.· Some people may view the BIOS as the OS, and the shell and utilities are just apps.
I think the OS should support the minimum Prop hardware, which would be a Prop chip plus a 32K EEPROM and a serial port.· The BIOS would take up a small part of the lower memory, and a tiny file system would reside in the upper part.· In this configuration there may not even be a command shell, but just a single user app.
Larger hardware systems could support much more, and could become quite sophisticated.
@Bill: Reply on PropCade thread.
@jazzed: There is a wiki and a thread·for SphinxOS which gives some features (links in my signature).
Nice work. May I suggest the following (currently 3 longs undefined - see below for possibilities to fill these)...
' minimalist 64 byte interface / rendevous structure
_HubTop_ptr = $8000 - 1 * 4 '$7FFC stores the top of hub used ... i.e. =$7FC0 =_COG0_ptr
_StdOut = _HubTop_ptr - 1 * 4 '$7FF8 StdOut rendezvous (or pointer to stdout data structure?)
_StdIn = _StdOut - 1 * 4 '$7FF4 StdIn rendezvous (or pointer to stdin data structure?)
_SD_ptr = _StdIn - 1 * 4 '$7FF0 pointer to sd or other storage interface data structure
_???? = _SD_ptr - 1 * 4 '$7FEC ????
_???? = - 1 * 4 '$7FE8 ????
_???? = - 1 * 4 '$7FE4 ????
_ProgParm_ptr = - 1 * 4 '$7FE0 pointer to program parameters and exit status value
_COG7_ptr = _SD_ptr - 1 * 4 '$7FDC pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG6_ptr = _COG7_ptr - 1 * 4 '$7FD8 pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG5_ptr = _COG6_ptr - 1 * 4 '$7FD4 pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG4_ptr = _COG5_ptr - 1 * 4 '$7FD0 pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG3_ptr = _COG4_ptr - 1 * 4 '$7FCC pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG2_ptr = _COG3_ptr - 1 * 4 '$7FC8 pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG1_ptr = _COG2_ptr - 1 * 4 '$7FC4 pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG0_ptr = _COG1_ptr - 1 * 4 '$7FC0 pointer to cog[noparse][[/noparse]n] interface/other data structure
The way Sphinx currently uses the StdIn and StdOut rendesvous locations, they hold the data, not a pointer.
I didn't include the following... are they required???
_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
Do we need an RTC (real time clock) ? It can always be added later. If we need it, how do we define the 32 bit long for date/time? It could always be part of one of the cog drivers without a special RTC chip.
_DateTime = - 1 * 4 'current Date/Time
If we included Serial, then 2 longs would be required - an inout and an output rendezvous longs if the buffers are in the cog, or pointers if the buffers are·in hub.
A shell would be nice. jazzed, do you want to spec and do it??
@Dave: Yes, I am expecting we do not need to be so complex to have a seperate BIOS & DOS. I am against any code permanently residing in lower hub because it breaks the compilers and downloaders. Bill is doing his own compiler. I do not see that the BIOS/DOS would remain resident (the hub section - the cog section would remain resident for OS aware programs). Any extra services·would be compiled into one's program if those features are required and could be made available as objects for this purpose. We do not want to waste hub space for anything not required by almost every program.
I don't agree we need to support the EEPROM in this OS. It can be an object added into whatever program requires it. Remember, at least I don't think the EEPROM should change. Anything required to be stored on EEPROM could be stored on the SD card. For an OS that is EEPROM based, a different version which substitutes the SD driver for the EEPROM driver could be done.
@jazzed: Yes, we could all write our own. In fact, that is why I raised this thread. I would like to see, as I think you would, a joint effort so we can get the best system for all. This way we can all add sections that we are comfortable with.
SD Driver:
The one thing that needs to be considered is the SD driver. We have a number of versions. IMHO, we have 2 which are better... fsrw2.6 (or is it 2.7?) and Kye's. I think we need a combo which takes the best of both versions. Sphinx uses 3 cogs and I don't think this is workable. We need a single cog for the low level SD access, and whatever basics for FAT16/32 that can fit into the cog. Anything else has to be in an object that can be included only in the OS programs that require those features. This means that programs can minimise the hub space used for this to gain maximum space for their application. Sphinx also used 11 longs for the rendezvous. Do we have anyone willing to do this???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'd prefer if the SD cog ONLY provided basic SD functionality (setup, get status, read sector, write sector) so that it is file system agnostic. It should use a mailbox interface [noparse]:)[/noparse] and I think 4 longs is sufficient.
Reason: other languages, vm's, could implement other file systems in their own byte code, sometimes holding said code in virtual memory
Cluso99 said...
@Dave: Yes, I am expecting we do not need to be so complex to have a seperate BIOS & DOS. I am against any code permanently residing in lower hub because it breaks the compilers and downloaders. Bill is doing his own compiler. I do not see that the BIOS/DOS would remain resident (the hub section - the cog section would remain resident for OS aware programs). Any extra services·would be compiled into one's program if those features are required and could be made available as objects for this purpose. We do not want to waste hub space for anything not required by almost every program.
I don't agree we need to support the EEPROM in this OS. It can be an object added into whatever program requires it. Remember, at least I don't think the EEPROM should change. Anything required to be stored on EEPROM could be stored on the SD card. For an OS that is EEPROM based, a different version which substitutes the SD driver for the EEPROM driver could be done.
You seem to be concerned about the terms BIOS and DOS.· I'll refer to them as OS and shell instead.· I don't think I ever said the OS (BIOS) remained in hub RAM permanently.· Once the basic COGs are loaded the OS could reside entirely in a COG except for buffers and the rendezvous area.· However, there should be nothing to prevent the OS from remaining in lower HUB permanently.
I don't understand why a program in lower hub RAM would break the compilers and downloaders.· We should be able to run multiple processes without a concern where they are located in hub memory.· Of course, there may be some programs that require the full hub memory, and in that case all of the other processes that use hub memory would have to be terminated.
Driver code should not be constrained to reside entirely in a COG.· There may be cases where a driver can be implemented more efficiently using a Spin interpreter in a COG and a kilo-byte of spinbytes in hub ram.· Perhaps you would feel better if you thought of the 1K spn program as a data buffer that is used by a COG.
It is convient to store a small amount of configuration data in the EEPROM.· I don't understand why we wouldn't take advantage of that.· Platform-specific stuff could be stored in the EEPROM.· I am not proposing that every platform should implement an EEPROM file system.· However, we shouldn't prevent a minimal system from being implemented that only contains an EEPROM for mass storage.· This means that a system does not necessarily require an SD card.· It does require a file system of some form, which could be EEPROM, SD card, USB memory stick, remote file system over LAN, etc.
' minimalist 64 byte interface / rendevous structure
_HubTop_ptr = $8000 - 1 * 4 '$7FFC stores the top of hub used ... i.e. =$7FC0 =_COG0_ptr
_StdOut = _HubTop_ptr - 1 * 4 '$7FF8 StdOut rendezvous (or pointer to stdout data structure?)
_StdIn = _StdOut - 1 * 4 '$7FF4 StdIn rendezvous (or pointer to stdin data structure?)
_SD_ptr = _StdIn - 1 * 4 '$7FF0 pointer to sd or other storage interface data structure
_???? = _SD_ptr - 1 * 4 '$7FEC ????
_???? = - 1 * 4 '$7FE8 ????
_???? = - 1 * 4 '$7FE4 ????
_ProgParm_ptr = - 1 * 4 '$7FE0 pointer to program parameters and exit status value
_COG7_ptr = _SD_ptr - 1 * 4 '$7FDC pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG6_ptr = _COG7_ptr - 1 * 4 '$7FD8 pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG5_ptr = _COG6_ptr - 1 * 4 '$7FD4 pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG4_ptr = _COG5_ptr - 1 * 4 '$7FD0 pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG3_ptr = _COG4_ptr - 1 * 4 '$7FCC pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG2_ptr = _COG3_ptr - 1 * 4 '$7FC8 pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG1_ptr = _COG2_ptr - 1 * 4 '$7FC4 pointer to cog[noparse][[/noparse]n] interface/other data structure
_COG0_ptr = _COG1_ptr - 1 * 4 '$7FC0 pointer to cog[noparse][[/noparse]n] interface/other data structure
The way Sphinx currently uses the StdIn and StdOut rendesvous locations, they hold the data, not a pointer.
Ok, I assume COG 0 is aligned to a page so it's easy to reference the others.
I see what you're doing with stdin/stdout, but I'm not comfortable that a one long interface would serve all device needs.
What if:
Someone wants to dynamically change the stdout device?
Someone wants to use UDP connected I/O devices (need IP port/address config)?
I suppose the strict non-pointer definition could be hijacked without impact in such cases.
Cluso99 said...
I didn't include the following... are they required???
_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
A pointer to the top of *user* memory space says "Now user, everything from here down is yours and you can break it all you like." This is a different function than what _HubTop_ptr serves I think. _HubTop_ptr content to me says "here is the end of the system services data structure which is the _COG0_ptr." The system uses everything from _HubTop_ptr address down to the value stored in Heap_ptr."
The misc pointer is intended to provide a way for the *system* to keep track of devices that are not defined in the static structure from long[noparse][[/noparse]_HubTop_ptr] to _HubTop_ptr. For ease of use a _MiscEnd_ptr would also be used. Perhaps it's better named _ExtDev_ptr (Extended or Extra system device list pointer).
I'm not sure if we need an RTC because it seems optional although fake RTC could be added, but the rendezvous / interface data structure would be a good candidate for storage in the _Misc_ptr device list.
Cluso99 said...
A shell would be nice. jazzed, do you want to spec and do it??
I'll look into it. A shell would need access to extra system space (_Misc_ptr) to save states since it can not be live all the time.
Can an O/S application manager (or scheduler) be left running in the background (in a COG)? Maybe this is an optional feature. Being able to kill a user application for example with Ctrl-C is very desirable and can't be done without it.
Typically a shell is allowed to run a background application and wait for it to terminate. A background application manager is of course required for such a shell feature.
Sorry for the stupid questions, but I could not find the wiki. All I see is the "morphed" Spinx compiler thread.
It would be helpful for the high level (file open) routines to create a table with the cluster start (sector #) and number of sectors for each cluster in the file, perhaps with an upper limit on the number of clusters in the file table. For creating a new file, you could specify the size of the file and the file create routine would create such an file (uninitialized) and set up a cluster table. If the file existed, but was too small, the create routine could extend the file with one or more clusters and set up the appropriate cluster table. This would allow programs to have a command line interpreter (or this would be part of the OS's command interpreter) that would open or create any necessary files and pass the cluster tables and other parameters to a 2nd phase that would only need the low level SD card I/O routines, not the high level (FSRW) stuff. There could be a "clean up" function in the OS or in another phase of the program that would delete any unneeded temporary files or shorten any files that were created or extended larger than was necessary.
Dave said...
You seem to be concerned about the terms BIOS and DOS.· I'll refer to them as OS and shell instead.· I don't think I ever said the OS (BIOS) remained in hub RAM permanently.· Once the basic COGs are loaded the OS could reside entirely in a COG except for buffers and the rendezvous area.· However, there should be nothing to prevent the OS from remaining in lower HUB permanently.
I don't understand why a program in lower hub RAM would break the compilers and downloaders.· We should be able to run multiple processes without a concern where they are located in hub memory.· Of course, there may be some programs that require the full hub memory, and in that case all of the other processes that use hub memory would have to be terminated.
The problem with anything remaining in lower hub memory is that the compilers compile the code starting from $0. All the pointer tables commence here. This would complicate the process for everyone who wanted to write an OS aware program (such as an enhanced version of DIR i.e. LS). Any OS code remaining in hub would have to be at the top and the _HubTop_ptr adjusted accordingly. Currently, we can use a program binary compiled with PropTool and copy it to SD (renamed of course) and bingo, the program can run under the OS.
jazzed said...
Ok, I assume COG 0 is aligned to a page so it's easy to reference the others.
I see what you're doing with stdin/stdout, but I'm not comfortable that a one long interface would serve all device needs.
What if:
Someone wants to dynamically change the stdout device?
Someone wants to use UDP connected I/O devices (need IP port/address config)?
I suppose the strict non-pointer definition could be hijacked without impact in such cases.
Cog0 alignment - yes.
StdIn/StdOut are character interfaces and currently work for TV/VGA/Keyboard/Serial. Since we have a full long interface, commands are also possible, including responses. Dynamic driver changes for StdIn & StdOut should indeed be possible. If this interface changes then I am unsure how the OS aware programs would handle it.
jazzed said...
A pointer to the top of *user* memory space says "Now user, everything from here down is yours and you can break it all you like." This is a different function than what _HubTop_ptr serves I think. _HubTop_ptr content to me says "here is the end of the system services data structure which is the _COG0_ptr." The system uses everything from _HubTop_ptr address down to the value stored in Heap_ptr."
The misc pointer is intended to provide a way for the *system* to keep track of devices that are not defined in the static structure from long[noparse][[/noparse]_HubTop_ptr] to _HubTop_ptr. For ease of use a _MiscEnd_ptr would also be used. Perhaps it's better named _ExtDev_ptr (Extended or Extra system device list pointer).
No. My intention is that we only have _HubTop-ptr which performs what you are calling _MiscEnd_ptr or _ExtDev_ptr. It is just a pointer that tells a program where the OS reserved bits start. So if a buffer is allocated by the OS or Driver, then _HubTop_ptr·reduces by that amount (points to the last allocated). Of course, you will not necessarily be able to "unallocate" due to fragmentation (this is just too complex for a Prop OS IMHO).
jazzed said...
I'm not sure if we need an RTC because it seems optional although fake RTC could be added, but the rendezvous / interface data structure would be a good candidate for storage in the _Misc_ptr device list.
Thinking further, maybe we should allocate 1 of the 16 rendezvous locations for an RTC Date/Time value which would be zero if none exists. If no RTC then the OS may request a date & time and place it here. If a·cog performing the RTC function (within another driver such as SD) then it would update the Date/Time rendezvous location. Presume we have 1 long... What format??? and resolution???
Ctl-C to abort a program: Yes this would be nice. The StdIn driver would have to do/cause this somehow???
Shell: Yes, I am unsure what would be required. Perhaps just a single long would do which would store the physical sector of the batch file being executed, plus an abort code of 8 bits?????
@Mike: Yes, an object (or objects) to do the upper levels would be extremely helpful. Kye has done a lot of this work which could be broken down into smaller sections. Maybe you &/or Kye would like to do a list of features for each such object??? I would like the lower level fsrw in cog to have as much support code as possible. fsrw currently has a 512 byte buffer in the cog which is used to read ahead. I disabled this in ZiCog, because we break it into·128 byte sectors which didn't work. However, a second 512 byte buffer could work nicely. Something to be considered. IIRC there is also an RTC function in the cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
StdIn/StdOut are character interfaces and currently work for TV/VGA/Keyboard/Serial. Since we have a full long interface, commands are also possible, including responses. Dynamic driver changes for StdIn & StdOut should indeed be possible. If this interface changes then I am unsure how the OS aware programs would handle it.
The point in bold (your words, my emphasis) is exactly the point I'm trying to make for future interfaces. It's probably fine for the short term though. I've found that headache avoidance is as much a part of software engineering as anything else and am honestly trying to help you with that.
jazzed: That is my point too. But why would the StdIn and StdOut interface want to change from a character/command interface? It has lasted for 30 years. There is no point in indirection if it's never going to be used. It just becomes another complexity and another waste of hub space. Perhaps you can give me an example.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'd call the _SD_ptr something like _Block_IO. Maybe having more than one _Block_IO would make sense as well.
2nd level drivers like FSRW could be implemented using _Block_IO low level drivers. Then there is no problem in using a file-system on SD-card, in EEPROM, in Flash .....
Cluso99 said...
The problem with anything remaining in lower hub memory is that the compilers compile the code starting from $0. All the pointer tables commence here. This would complicate the process for everyone who wanted to write an OS aware program (such as an enhanced version of DIR i.e. LS). Any OS code remaining in hub would have to be at the top and the _HubTop_ptr adjusted accordingly. Currently, we can use a program binary compiled with PropTool and copy it to SD (renamed of course) and bingo, the program can run under the OS.
I don't understand what breaks if you leave the boot program at location zero.· Spin programs are fully relocatable.· They don't need to run at location zero.· The rendezvous locations are at high memory.· Why won't it work?
Dave
Cluso99 said...
jazzed: That is my point too. But why would the StdIn and StdOut interface want to change from a character/command interface? It has lasted for 30 years. There is no point in indirection if it's never going to be used. It just becomes another complexity and another waste of hub space. Perhaps you can give me an example.
Unix uses special file handles (pointers) to implement the stdin, stdout, stderr character interfaces. I already suggested another example above as in UDP network connections: you ignored it. I'm not going to beg you to use pointers.
I believe linux maintains a constant address for the stdin and stdout FILE structs, but copies the redirected FILE contents into those structs.· When I run the following program I always get the same address independent of whether I redirected stdin and/or stdout.
#include <stdio.h>
void main(void)
{
fprintf(stderr, "address of stdin = %8.8x\n", stdin);
fprintf(stderr, "address of stdout = %8.8x\n", stdout);
fprintf(stderr, "address of stderr = %8.8x\n", stderr);
}
The current version of CLIB only supports serial I/O, but you can use fgetc, fgets, fprintf, etc. by specifying a file info pointer, which is similar to a (FILE *) pointer in standard C.· This allows for using the standard C functions with multiple serial ports.
I have been working on adding file system support to CLIB for a few months, and I am able to do stdin/stdout redirection quite easily.· The file info struct consists of two longs -- a file type and a pointer to the driver data.· I could have used two words instead.
When I open the console serial port I create three file info structs, which are pointed to by stdio, stdin and stdout.· They all initially point to the console serial port handle.· I can redirect stdin and stdout by calling setstdin or setstdout with the address of the file info struct for a file, which copies the file info struct.· I reset the redirection by copying the stdio information.· The Spin code is shown below.
stdio could be replaced by conin and conout for console input and console output.· This way independent input and output could be used, such as a keyboard and VGA display.
CON
' File info types
file_info_serial = 0
file_info_disk1 = 2
' File info offsets
file_info_type = 0
file_info_data = 1
file_info_size = 8
DAT
' Standard I/O pointers
stdout long 0
stdin long 0
stdio long 0
PUB setstdin(pfileinfo)
memcpy(stdin, pfileinfo, file_info_size)
PUB setstdout(pfileinfo)
echoflag := 0
memcpy(stdout, pfileinfo, file_info_size)
PUB resetstdin
memcpy(stdin, stdio, file_info_size)
PUB resetstdout
echoflag := 1
memcpy(stdout, stdio, file_info_size)
PUB getstdin
return stdin
PUB getstdout
return stdout
Dave Hein said...
I believe linux maintains a constant address for the stdin and stdout FILE structs, but copies the redirected FILE contents into those structs.
Dave,
I'm always impressed with your professional efforts, desire, and ability to do clib based work.
Most programmers understand the clib functions. Stdio file handle descriptor ids are constants for sure.
Here's a good summary for those who care to look en.wikipedia.org/wiki/File_descriptor
Steve (jazzed) & I have been discussing this offline.
We agree that the SD driver needs to be...
a single cog
low level driver
fast
512 byte sector buffer in cog is good
simple FAT16/32 code if space available
The upper level code can then be an object to be included in the user program. fsrw seems to have issues with some SD cards, but would be my preference for starters. Kye's code for the upper levels would probably be the better way too.
I am still trying to understand what Steve is driving at with StdIn/Out and why we cannot keep it simple, so will keep this offline for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
It will be pretty much impossible to fit all FAT32/16 code needed to open a file in open cog. You would need to do some LMM style stuff for that to work.
Just look at the mounting function in FSRW. Then combine that with the open file function...
For all this to work only reading mode could be supported for the SD card... and the file to work with would need to be in the root directory.
Working out how to get the driver to accpet command would be another matter after that.
...
I'm willing to help out somewhat on this. I don't really want to write any new code but I could set the framework up for you guys by ripping my own block driver apart. Then the ASM rountines in the driver would be easy.·
If I don't support writing mode it can be possible. I'll need explict details however.
I know the conversation here is regarding a Prop OS. But I'd like to continue to push the idea of COGs as peripheral blocks with "firmware".
"firmware" is that PASM and DAT data that gets loaded to a COG when you start it.
"firmware" is NOT any of the Spin code you may normally access it with from other spin obects.
"firmware" has ONLY a HUB memory interface that is used to configure, control and input/output data. That is it has a "register" interface. Call it a "mailbox" or whatever.
Such firmware can then be used in any Prop OS and with any programming language.
So Kye, for example, I'd love to see your block level driver as such a firmware. when integrated into an OS one might use your Spin FAT code to drive it or some other FAT code in C or whatever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cluso99 said...
Steve (jazzed) & I have been discussing this offline.
We agree that the SD driver needs to be...
a single cog
low level driver
fast
512 byte sector buffer in cog is good
simple FAT16/32 code if space available
I doubt if having the 512 byte buffer in the same COG is as the driver is possible.
Still, yes I agree this is all very desirable. Kudo's go to anyone who can do it.
There is no reason such an "in COG" low level driver cannot be told through its "register", "mailbox" or whatever you want to call it interface, where to fined a 512 byte buffer in HUB.
It is quite common in the world of real hardware peripheral chips that they are pointed at areas of memory that they can use. In this scenario the "in-COG" driver is performing the role of such a peripheral chip with a memory mapped interface.
As I say the actual FAT code is another issue that belongs to the application code or OS code. It should be possible to write such code in any language. Spin, C, etc etc.
Or perhaps one wants to just write ones whole app/OS in LMM PASM. I would be great to be able to use such in-cog Spin-free low level drivers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks Kye. I need to relook at fsrw2.6. I thought that the buffer was within the cog, but maybe I am wrong (it's always on the other laptop [noparse]:([/noparse] )
heater: Yes, what you are saying will work. It's only semantics anyway. I want to use it in ZiCog too!! So ZiCog (or ZiCogII) will be an OS aware program.
jazzed: I will take a look a little later (see my comment to Kye above)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
heater said...
There is no reason such an "in COG" low level driver cannot be told through its "register", "mailbox" or whatever you want to call it interface, where to fined a 512 byte buffer in HUB.
Absolutely. We do it all the time.
Being able to tell a driver where to put its data is of great value.
It's just like using a pointer for fread or fwrite in C.
It also eliminates eating up hub space for apps that won't use SD.
FSRW 2.6 has two sets of variables.· One set sits in a DAT section and contains information about the SD file system.· The other set sits in a VAR section and contains specific information about the file or directory that is currently opened.· Both sections contain a 512-byte sector buffer.· The VAR data is used so that multiple files can be opened by including the FSRW object multiple times.· This method is useful, but it also has a negative side effect where the opened file instance cannot be accessed from different objects.
I use a modified version of FSRW 2.6 that keeps all of its variables in a DAT section.· It supports multiple opened files by allocating memory for the 512-byte sector buffer plus 11 longs that hold the file state information.· I used a file handle, which poiints to the block of 11 longs that I allocated.· I access different opened files by saving the 11 state variables in FSRW, and then copying the new state variables from the handle to FSRW.· It works great.· And in Spin, the overhead of doing a longmove of 11 variables is quite small compared to other operations.
It will be difficult to fit FSRW into one cog.· I think it requires about 1000 longs of spin bytecodes.· A pure PASM implementation would probably take 2 or 3 cogs.
I don't know where to start with posting my code, because I have a lot running now, but it would need some kind of an installer.
What I have now:
=============
COGdesc - which is the OS or bootloader part of the driver descriptor table for EEPROM and a driver list & memory allocation in HUB-RAM.
cogOScore - an extract of COGdesc needed if the application loads the drivers itself
cogOScoreRAM - an extract of COGdesc needed if the application should use pre-loaded drivers
PASMstoreE_xxx - code that uses COGdesc to store the PASM-part of a driver in EEPROM
newCogOS - my OS which allows to list the drivers stored in EEPROM, the running drivers, copy a driver from
SD to EEPROM ....
Above·is an example session of the OS. commands are peceeded by the >.
listdrv shows the list of drivers in EEPROM. Currently one entry needs 5 longs. There is a name (12byte) a version number ( 1 word - the number starting with a V·), the number of longs in HUB memory needed by the driver (1 word - the number starting with #) and an additional currently not needed long - maybe in future it could point to a vMem address. The number starting with a ° is the hash-value of name and version which is later on used in the list of loaded drivers.
listcog shows the list of loaded drivers. The first value is the hash value of the driver followed by the number of longs in HUB ram, followed by the address of these longs. The last value is a long containing flags and later on the COGID that runs this driver.
The exec command runs the *.BIN file given as parameter. All following parameters are also accessible by the started code. As you can see the SPIN code simply takes over the serial interface and is writing some words.
The code in the *.BIN to do that is minimal:
driver.initRAMDesc
i := driver.findRAMDrv( 0, driver.Hash( string("FDSerial"), $0110 ) )
' no driver found, so it's better to stay in an endless loop
if i==-1
repeat
serial.start(0,0,0,0, driver.getRAMParAddress( i ) )
That's it ... from there on the application can use serial.str ...
But there are a lot of things that need to be done. COGdesc for SDcard for example. As already discussed, a driver could be stored in a *.COG file. I'd propose to store additional data in this file, as I do in the EEPPROM descriptor - name, version, HUB-RAM needed. This is the minimum you need for allowing an OS to manage the drivers. So, first long could be the size of the driver followed by the PASM, followed by the additional data.
For allowing a low level driver used by some higher level code we should think about a general interface for device drivers. Block device/streaming device/display device .... Each block device driver then should implement the same minimum of functions ....
This way a Flash ram driver and a SDcard driver written as a block device driver can be used by a FAT high level driver ... configurable ...
I would *STRONGLY* prefer if the SD cog just provided basic SD services, and was file system agnostic.
Frankly, other than experiments, I will only use such a cog in Largos.
Why?
1) FAT is bloated, slow, and takes too much memory. When I have a bit of time, I will port my FlashFS (the one running on Winbond and compatible SPI flashes) from the Largos development platform to SD.
2) with VMCOG, the FS could be in virtual memory, and rarely used FS code would not take up hub memory until needed.
3) with XLMM, the FS could be in XMM, executed as XLMM in place
I have been tinkering with loading drivers and using rendezvous locations.· It's cool stuff.· I created a small OS that runs a boot program, which loads a serial driver, an I2C driver and an EEPROM file system driver.· The first two drivers are in PASM and run in cogs 1 and 2.· The file system driver is a Spin program that runs in cog 3.· It uses the mailbox method that I described above to remotely call file system functions in cog 3.
The last thing the boot program does is run a Spin program call shell.binary.· shell.binary then kills the boot program by calling cogstop on cog 0.· Try running the attached install.binary program.· It will install a boot program and a small 20 Kbyte file system in the first 32K of the boot EEPROM.· It communicates though a serial port on pins 30 and 31 at 57600 baud.· The file system will only contain 3 files after installation -- shell.binary, help.txt and rb.binary.
There's only about 7KB of space left in the file system, but it's enough to try a few things.· Type help to see the available commands.· You can create files and directories, and you can run the app rb.binary.· This app can be used to receive files using YMODEM.· I have tested it with the Windows Hyperterminal.
Check out the malloc command.· This command prints the allocated and free memory lists.· It will look like this after boot up.
The 5 entries in the malloc list are the shell.binary program, the file system driver, the standard in and standard out handles, and the serial data structure.· I currently include a large 512-byte receive buffer for the serial port, but I'll reduce that in the future.
The free list shows a block of 16 KB available for user programs.· The 116-byte block was a file handle used when loading shell.binary.· Type "malloc >t" and then "type t" and you'll see the 116-byte chunk allocated when the output was redirected to the file "t".
Dave
Edit:· I forgot to mention that my rendezvous location starts at 7f00.· You can use the "dumpm 7f00 100" command to see a hex dump of it.· It's just a first cut at using the rendezvous technique, and it's pretty sparse.· The rendezvous locations are defined in a Spin file as
You missed my point. How do you tell a FAT FS system cog what to do using a mailbox rountine? Its not that simple. I'm not talking about low level get block and put block rountines. I'm talking about opening files and such.
Comments
With that being said, data buffers should not be part of the rendevous location.· Therefore I would lean toward a list of pointers to data structures.
My earlier description of the OS being made up of a BIOS and a DOS may be confusing.· The BIOS is really the basic plumbing, which sets up the rendevous area and loads basic drivers for standard in, standard out and the file system.· I think it should also include a heap manager and a real-time clock.· The DOS is really nothing more than a shell command-line interpreter and a bunch of utilities.· Some people may view the BIOS as the OS, and the shell and utilities are just apps.
I think the OS should support the minimum Prop hardware, which would be a Prop chip plus a 32K EEPROM and a serial port.· The BIOS would take up a small part of the lower memory, and a tiny file system would reside in the upper part.· In this configuration there may not even be a command shell, but just a single user app.
Larger hardware systems could support much more, and could become quite sophisticated.
@jazzed: There is a wiki and a thread·for SphinxOS which gives some features (links in my signature).
Nice work. May I suggest the following (currently 3 longs undefined - see below for possibilities to fill these)...
The way Sphinx currently uses the StdIn and StdOut rendesvous locations, they hold the data, not a pointer.
I didn't include the following... are they required???
Do we need an RTC (real time clock) ? It can always be added later. If we need it, how do we define the 32 bit long for date/time? It could always be part of one of the cog drivers without a special RTC chip.
If we included Serial, then 2 longs would be required - an inout and an output rendezvous longs if the buffers are in the cog, or pointers if the buffers are·in hub.
A shell would be nice. jazzed, do you want to spec and do it??
@Dave: Yes, I am expecting we do not need to be so complex to have a seperate BIOS & DOS. I am against any code permanently residing in lower hub because it breaks the compilers and downloaders. Bill is doing his own compiler. I do not see that the BIOS/DOS would remain resident (the hub section - the cog section would remain resident for OS aware programs). Any extra services·would be compiled into one's program if those features are required and could be made available as objects for this purpose. We do not want to waste hub space for anything not required by almost every program.
I don't agree we need to support the EEPROM in this OS. It can be an object added into whatever program requires it. Remember, at least I don't think the EEPROM should change. Anything required to be stored on EEPROM could be stored on the SD card. For an OS that is EEPROM based, a different version which substitutes the SD driver for the EEPROM driver could be done.
@jazzed: Yes, we could all write our own. In fact, that is why I raised this thread. I would like to see, as I think you would, a joint effort so we can get the best system for all. This way we can all add sections that we are comfortable with.
SD Driver:
The one thing that needs to be considered is the SD driver. We have a number of versions. IMHO, we have 2 which are better... fsrw2.6 (or is it 2.7?) and Kye's. I think we need a combo which takes the best of both versions. Sphinx uses 3 cogs and I don't think this is workable. We need a single cog for the low level SD access, and whatever basics for FAT16/32 that can fit into the cog. Anything else has to be in an object that can be included only in the OS programs that require those features. This means that programs can minimise the hub space used for this to gain maximum space for their application. Sphinx also used 11 longs for the rendezvous. Do we have anyone willing to do this???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Reason: other languages, vm's, could implement other file systems in their own byte code, sometimes holding said code in virtual memory
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I don't understand why a program in lower hub RAM would break the compilers and downloaders.· We should be able to run multiple processes without a concern where they are located in hub memory.· Of course, there may be some programs that require the full hub memory, and in that case all of the other processes that use hub memory would have to be terminated.
Driver code should not be constrained to reside entirely in a COG.· There may be cases where a driver can be implemented more efficiently using a Spin interpreter in a COG and a kilo-byte of spinbytes in hub ram.· Perhaps you would feel better if you thought of the 1K spn program as a data buffer that is used by a COG.
It is convient to store a small amount of configuration data in the EEPROM.· I don't understand why we wouldn't take advantage of that.· Platform-specific stuff could be stored in the EEPROM.· I am not proposing that every platform should implement an EEPROM file system.· However, we shouldn't prevent a minimal system from being implemented that only contains an EEPROM for mass storage.· This means that a system does not necessarily require an SD card.· It does require a file system of some form, which could be EEPROM, SD card, USB memory stick, remote file system over LAN, etc.
I see what you're doing with stdin/stdout, but I'm not comfortable that a one long interface would serve all device needs.
What if:
Someone wants to dynamically change the stdout device? Someone wants to use UDP connected I/O devices (need IP port/address config)?
I suppose the strict non-pointer definition could be hijacked without impact in such cases.A pointer to the top of *user* memory space says "Now user, everything from here down is yours and you can break it all you like." This is a different function than what _HubTop_ptr serves I think. _HubTop_ptr content to me says "here is the end of the system services data structure which is the _COG0_ptr." The system uses everything from _HubTop_ptr address down to the value stored in Heap_ptr."
The misc pointer is intended to provide a way for the *system* to keep track of devices that are not defined in the static structure from long[noparse][[/noparse]_HubTop_ptr] to _HubTop_ptr. For ease of use a _MiscEnd_ptr would also be used. Perhaps it's better named _ExtDev_ptr (Extended or Extra system device list pointer).
I'm not sure if we need an RTC because it seems optional although fake RTC could be added, but the rendezvous / interface data structure would be a good candidate for storage in the _Misc_ptr device list.
I'll look into it. A shell would need access to extra system space (_Misc_ptr) to save states since it can not be live all the time.
Can an O/S application manager (or scheduler) be left running in the background (in a COG)? Maybe this is an optional feature. Being able to kill a user application for example with Ctrl-C is very desirable and can't be done without it.
Typically a shell is allowed to run a background application and wait for it to terminate. A background application manager is of course required for such a shell feature.
Sorry for the stupid questions, but I could not find the wiki. All I see is the "morphed" Spinx compiler thread.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
It would be helpful for the high level (file open) routines to create a table with the cluster start (sector #) and number of sectors for each cluster in the file, perhaps with an upper limit on the number of clusters in the file table. For creating a new file, you could specify the size of the file and the file create routine would create such an file (uninitialized) and set up a cluster table. If the file existed, but was too small, the create routine could extend the file with one or more clusters and set up the appropriate cluster table. This would allow programs to have a command line interpreter (or this would be part of the OS's command interpreter) that would open or create any necessary files and pass the cluster tables and other parameters to a 2nd phase that would only need the low level SD card I/O routines, not the high level (FSRW) stuff. There could be a "clean up" function in the OS or in another phase of the program that would delete any unneeded temporary files or shorten any files that were created or extended larger than was necessary.
Cog0 alignment - yes.
StdIn/StdOut are character interfaces and currently work for TV/VGA/Keyboard/Serial. Since we have a full long interface, commands are also possible, including responses. Dynamic driver changes for StdIn & StdOut should indeed be possible. If this interface changes then I am unsure how the OS aware programs would handle it.
No. My intention is that we only have _HubTop-ptr which performs what you are calling _MiscEnd_ptr or _ExtDev_ptr. It is just a pointer that tells a program where the OS reserved bits start. So if a buffer is allocated by the OS or Driver, then _HubTop_ptr·reduces by that amount (points to the last allocated). Of course, you will not necessarily be able to "unallocate" due to fragmentation (this is just too complex for a Prop OS IMHO).
Thinking further, maybe we should allocate 1 of the 16 rendezvous locations for an RTC Date/Time value which would be zero if none exists. If no RTC then the OS may request a date & time and place it here. If a·cog performing the RTC function (within another driver such as SD) then it would update the Date/Time rendezvous location. Presume we have 1 long... What format??? and resolution???
Ctl-C to abort a program: Yes this would be nice. The StdIn driver would have to do/cause this somehow???
Shell: Yes, I am unsure what would be required. Perhaps just a single long would do which would store the physical sector of the batch file being executed, plus an abort code of 8 bits?????
Sphinx wiki: Sorry it's not in my signature after all http://propeller.wikispaces.com/Sphinx
@Mike: Yes, an object (or objects) to do the upper levels would be extremely helpful. Kye has done a lot of this work which could be broken down into smaller sections. Maybe you &/or Kye would like to do a list of features for each such object??? I would like the lower level fsrw in cog to have as much support code as possible. fsrw currently has a 512 byte buffer in the cog which is used to read ahead. I disabled this in ZiCog, because we break it into·128 byte sectors which didn't work. However, a second 512 byte buffer could work nicely. Something to be considered. IIRC there is also an RTC function in the cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
2nd level drivers like FSRW could be implemented using _Block_IO low level drivers. Then there is no problem in using a file-system on SD-card, in EEPROM, in Flash .....
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
#include <stdio.h> void main(void) { fprintf(stderr, "address of stdin = %8.8x\n", stdin); fprintf(stderr, "address of stdout = %8.8x\n", stdout); fprintf(stderr, "address of stderr = %8.8x\n", stderr); }The current version of CLIB only supports serial I/O, but you can use fgetc, fgets, fprintf, etc. by specifying a file info pointer, which is similar to a (FILE *) pointer in standard C.· This allows for using the standard C functions with multiple serial ports.
I have been working on adding file system support to CLIB for a few months, and I am able to do stdin/stdout redirection quite easily.· The file info struct consists of two longs -- a file type and a pointer to the driver data.· I could have used two words instead.
When I open the console serial port I create three file info structs, which are pointed to by stdio, stdin and stdout.· They all initially point to the console serial port handle.· I can redirect stdin and stdout by calling setstdin or setstdout with the address of the file info struct for a file, which copies the file info struct.· I reset the redirection by copying the stdio information.· The Spin code is shown below.
stdio could be replaced by conin and conout for console input and console output.· This way independent input and output could be used, such as a keyboard and VGA display.
·
I'm always impressed with your professional efforts, desire, and ability to do clib based work.
Most programmers understand the clib functions. Stdio file handle descriptor ids are constants for sure.
Here's a good summary for those who care to look en.wikipedia.org/wiki/File_descriptor
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
We agree that the SD driver needs to be...
The upper level code can then be an object to be included in the user program. fsrw seems to have issues with some SD cards, but would be my preference for starters. Kye's code for the upper levels would probably be the better way too.
I am still trying to understand what Steve is driving at with StdIn/Out and why we cannot keep it simple, so will keep this offline for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Just look at the mounting function in FSRW. Then combine that with the open file function...
For all this to work only reading mode could be supported for the SD card... and the file to work with would need to be in the root directory.
Working out how to get the driver to accpet command would be another matter after that.
...
I'm willing to help out somewhat on this. I don't really want to write any new code but I could set the framework up for you guys by ripping my own block driver apart. Then the ASM rountines in the driver would be easy.·
If I don't support writing mode it can be possible. I'll need explict details however.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 6/19/2010 5:09:24 AM GMT
"firmware" is that PASM and DAT data that gets loaded to a COG when you start it.
"firmware" is NOT any of the Spin code you may normally access it with from other spin obects.
"firmware" has ONLY a HUB memory interface that is used to configure, control and input/output data. That is it has a "register" interface. Call it a "mailbox" or whatever.
Such firmware can then be used in any Prop OS and with any programming language.
So Kye, for example, I'd love to see your block level driver as such a firmware. when integrated into an OS one might use your Spin FAT code to drive it or some other FAT code in C or whatever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Still, yes I agree this is all very desirable. Kudo's go to anyone who can do it.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
It is quite common in the world of real hardware peripheral chips that they are pointed at areas of memory that they can use. In this scenario the "in-COG" driver is performing the role of such a peripheral chip with a memory mapped interface.
As I say the actual FAT code is another issue that belongs to the application code or OS code. It should be possible to write such code in any language. Spin, C, etc etc.
Or perhaps one wants to just write ones whole app/OS in LMM PASM. I would be great to be able to use such in-cog Spin-free low level drivers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: Yes, what you are saying will work. It's only semantics anyway. I want to use it in ZiCog too!! So ZiCog (or ZiCogII) will be an OS aware program.
jazzed: I will take a look a little later (see my comment to Kye above)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Being able to tell a driver where to put its data is of great value.
It's just like using a pointer for fread or fwrite in C.
It also eliminates eating up hub space for apps that won't use SD.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I use a modified version of FSRW 2.6 that keeps all of its variables in a DAT section.· It supports multiple opened files by allocating memory for the 512-byte sector buffer plus 11 longs that hold the file state information.· I used a file handle, which poiints to the block of 11 longs that I allocated.· I access different opened files by saving the 11 state variables in FSRW, and then copying the new state variables from the handle to FSRW.· It works great.· And in Spin, the overhead of doing a longmove of 11 variables is quite small compared to other operations.
It will be difficult to fit FSRW into one cog.· I think it requires about 1000 longs of spin bytecodes.· A pure PASM implementation would probably take 2 or 3 cogs.
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
What I have now:
=============
COGdesc - which is the OS or bootloader part of the driver descriptor table for EEPROM and a driver list & memory allocation in HUB-RAM.
cogOScore - an extract of COGdesc needed if the application loads the drivers itself
cogOScoreRAM - an extract of COGdesc needed if the application should use pre-loaded drivers
PASMstoreE_xxx - code that uses COGdesc to store the PASM-part of a driver in EEPROM
newCogOS - my OS which allows to list the drivers stored in EEPROM, the running drivers, copy a driver from
SD to EEPROM ....
Above·is an example session of the OS. commands are peceeded by the >.
listdrv shows the list of drivers in EEPROM. Currently one entry needs 5 longs. There is a name (12byte) a version number ( 1 word - the number starting with a V·), the number of longs in HUB memory needed by the driver (1 word - the number starting with #) and an additional currently not needed long - maybe in future it could point to a vMem address. The number starting with a ° is the hash-value of name and version which is later on used in the list of loaded drivers.
listcog shows the list of loaded drivers. The first value is the hash value of the driver followed by the number of longs in HUB ram, followed by the address of these longs. The last value is a long containing flags and later on the COGID that runs this driver.
The exec command runs the *.BIN file given as parameter. All following parameters are also accessible by the started code. As you can see the SPIN code simply takes over the serial interface and is writing some words.
The code in the *.BIN to do that is minimal:
driver.initRAMDesc i := driver.findRAMDrv( 0, driver.Hash( string("FDSerial"), $0110 ) ) ' no driver found, so it's better to stay in an endless loop if i==-1 repeat serial.start(0,0,0,0, driver.getRAMParAddress( i ) )That's it ... from there on the application can use serial.str ...
The cogOScoreRAM only needs 78 longs.
;o)
Post Edited (MagIO2) : 6/19/2010 1:44:05 PM GMT
For allowing a low level driver used by some higher level code we should think about a general interface for device drivers. Block device/streaming device/display device .... Each block device driver then should implement the same minimum of functions ....
This way a Flash ram driver and a SDcard driver written as a block device driver can be used by a FAT high level driver ... configurable ...
So many ideas, so little time... ;o)
A simple way to do this is use a "mailbox" containing command and data pointer variables.· The Spin code for the caller would look like this.
The Spin code in the receiver would look like this:
PUB RemoteFunctionCheck(pMailBox) | FunctionNumber, pParmList, parm1, parm2, parm3 FunctionNumber := long[noparse][[/noparse]pMailBox][noparse][[/noparse]0] ifnot FunctionNumber return pParmList := long[noparse][[/noparse]pMailBox][noparse][[/noparse]1] parm1 := long[noparse][[/noparse]pParmList] parm2 := long[noparse][[/noparse]pParmList][noparse][[/noparse]1] parm3 := long[noparse][[/noparse]pParmList][noparse][[/noparse]2] case FunctionNumber 1: result := Function1(parm1, parm2) 2: result := Function2 3: result := Function3(parm1) 4: result := Function4(parm1, parm2, parm3) long[noparse][[/noparse]pMailBox][noparse][[/noparse]1] := result long[noparse][[/noparse]pMailBox][noparse][[/noparse]0] := 0The receiving cog would run a polling loop that would call RemoteFunctionCheck continuously.
Dave
The other way to pas a command and data pointer using a single long
long[noparse][[/noparse]pMailbox] := pCommand << 24 | pDataPointer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Excellent work guys.
I would *STRONGLY* prefer if the SD cog just provided basic SD services, and was file system agnostic.
Frankly, other than experiments, I will only use such a cog in Largos.
Why?
1) FAT is bloated, slow, and takes too much memory. When I have a bit of time, I will port my FlashFS (the one running on Winbond and compatible SPI flashes) from the Largos development platform to SD.
2) with VMCOG, the FS could be in virtual memory, and rarely used FS code would not take up hub memory until needed.
3) with XLMM, the FS could be in XMM, executed as XLMM in place
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The last thing the boot program does is run a Spin program call shell.binary.· shell.binary then kills the boot program by calling cogstop on cog 0.· Try running the attached install.binary program.· It will install a boot program and a small 20 Kbyte file system in the first 32K of the boot EEPROM.· It communicates though a serial port on pins 30 and 31 at 57600 baud.· The file system will only contain 3 files after installation -- shell.binary, help.txt and rb.binary.
There's only about 7KB of space left in the file system, but it's enough to try a few things.· Type help to see the available commands.· You can create files and directories, and you can run the app rb.binary.· This app can be used to receive files using YMODEM.· I have tested it with the Windows Hyperterminal.
Check out the malloc command.· This command prints the allocated and free memory lists.· It will look like this after boot up.
MallocList
addr = 3f08 size = 9936
addr = 664c size = 5676
addr = 7c78 size = 12
addr = 7c84 size = 12
addr = 7c90 size = 624
FreeList
addr = 0010 size = 16120
addr = 65d8 size = 116
16260 bytes allocated, 16236 bytes free
The 5 entries in the malloc list are the shell.binary program, the file system driver, the standard in and standard out handles, and the serial data structure.· I currently include a large 512-byte receive buffer for the serial port, but I'll reduce that in the future.
The free list shows a block of 16 KB available for user programs.· The 116-byte block was a file handle used when loading shell.binary.· Type "malloc >t" and then "type t" and you'll see the 116-byte chunk allocated when the output was redirected to the file "t".
Dave
Edit:· I forgot to mention that my rendezvous location starts at 7f00.· You can use the "dumpm 7f00 100" command to see a hex dump of it.· It's just a first cut at using the rendezvous technique, and it's pretty sparse.· The rendezvous locations are defined in a Spin file as
CON
serial = $7f00
memlocknum = $7f04
memfreelist = $7f08
malloclist = $7f0c
laststackaddr = $7f10
filecmd = $7f14
fileparm = $7f18
stdio = $7f1c
stdin = $7f20
stdout = $7f24
i2c_cmd = $7f28
i2c_parm = $7f2c
Post Edited (Dave Hein) : 6/19/2010 3:22:29 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,