Propellor "Operating System" (work in progress)

Mike Green

I've been working on a sort of operating system for the Propellor. The idea is to have a version of the hires VGA text and keyboard drivers that use work areas at the high end of RAM and to have a loader that can load from a 32Kx8 or larger "boot" EEPROM or any other I2C EEPROMs attached to the Propellor. There will be a simple command interpreter to configure things (like where are the EEPROMS?) and to load and execute named SPIN programs from the EEPROMs. There will be a way to copy SPIN programs to the EEPROMs either from the boot EEPROM or eventually from an SD/MMC card. There will be a simple editor, mostly using the standard keyboard keys.

The vga, keyboard, and I2C drivers are modifications of those in the library and pretty much work (the I2C driver does work with the boot EEPROM on the demo board). The loader is mostly written, but not debugged yet. The editor mostly works, at least on the screen buffer. The hires vga text driver includes an interface derived from tv_wtext that maintains multiple text windows. This works pretty well except for some boundary conditions with the "lazy return" feature.

I'm posting it at this point in its development because the hires vga driver including the screen editor may be useful even at this point. I will continue to post updates as I fix significant bugs, and add new features. I'd appreciate comments and observations, keeping in mind that this is very fluid at this point and not documented much.

The intention is to have a simple system, mostly for loading other programs that will use the vga display and keyboard. Those programs will only need to reference a portion of the "built-in" drivers so they won't need to include the assembly routines (already loaded and running in COGs). I don't plan to support vga graphics because of the memory requirements for the screen buffer, but a loaded program can always take over the whole Propellor and run its own copy of the graphics drivers.

Mike Green

Here's the next installment. This will determine how many "pages" of 32Kx8 are attached to the boot I2C bus during initialization. There are several commands: "info" to display some pointers from the SPIN program in the boot EEPROM, "edit" to test the screen editor (exit with the "apps" key), "probe" to display what EEPROM memory is known about, "probe x" to probe the I2C bus on pins x (clock) and x+1 (data) for EEPROMs and record how many 32Kx8 "pages" are attached, "run <name>" and "save <file>" don't do anything yet. They'll be used to run a named SPIN program and to copy a SPIN program from the boot EEPROM to a named space.

Mike Green

This version is less buggier. There's a help command that lists the available commands and their parameters. "probe <pin>" checks whether any EEPROMs are attached to that pin (SCL) and the next one (SDA). "list" will list all used and unused 32Kx8 pages. "probe" will list each pin pair with EEPROMs attached and the total amount of memory there. "dump" will either display any portion of RAM ("dump <addr> <size>") or any portion of an attached EEPROM ("dump <pin> <page> <addr> <size>"). Again, pages are 32Kx8. There are eight 64Kx8 blocks of 2 - 32Kx8 pages each for a total of 512K bytes that can be attached to any one pair of Propeller pins. There are commands to save the boot EEPROM to another page ("save <file>"), load the boot EEPROM from another page ("load <file>"), delete the name and make the page available for a "save" ("delete <file>"), and load a SPIN program from a page into RAM and execute it ("run <file>"). These DO NOT WORK yet!, but it's only a matter of time.
The ("info <file>") command will display some useful information about the named program. "edit" still is used for testing a
screen editor that will eventually be used for a file editor.

This will work on any Propeller Demo Board or any other configured with at least a compatible keyboard and VGA output. You can hang additional EEPROM on the boot I2C bus or on any other pin pair (even-SCL/odd-SDA). There are all kinds of useful routines scattered about and the documentation on them will improve.

El Paisa

It looks like is a very nice program.
A small gripe.

Looks like this program is cap sensitive.
After typing long paths in a very tiny text size (I have a 8 in. VGA monitor), I discover that if do not use the proper Up/Down case, you get "File not found" bit.
·

Mike Green

Thanks for trying it.

1) The "<file>" commands are incomplete and buggy at the moment. The next time I post a version, I expect them to work.

2) The program is not supposed to be case sensitive. It's not really documented yet, but filenames are currently any sequence of up to 12 non-blank characters. Lower case characters are mapped into upper case. After this is all working properly and polished up a little, I will add support for some kind of SD/MMC external device that will restrict filenames to the standard DOS/Windows 8.3 format.

2) The vga hires text driver (OS_vgaHiresTest) is Chip's driver with only slight modifications. At the beginning of the driver are three groups of constant declarations, one for each of 3 resolutions (640 x 480, 800 x 600, 1024 x 768). All but one are commented out. Currently it's set to 800 x 600, but, if you comment that one out and "uncomment" the 640 x 480 group, the rest of the program will adjust. That will look better on your 8" monitor. Similarly, if you have a big monitor and good eyes, you can switch to 1024 x 768.

Mike Green

Another installment. I've changed the video resolution to 640 x 480 for better viewability (it's easily changed back). I've eliminated the SAVE and LOAD commands and replaced them with a COPY command. The special filename BOOT is always the boot EEPROM, so you can "copy boot foobah" to find a 32Kx8 unused space, store the filename in the upper 16 bytes of that space, and copy (32K - 16) bytes from the boot EEPROM to the space. It takes about 25 seconds now. In the future, this can be done faster in assembly, but it works for now. The DUMP command takes a pin # and address where the entire 512K potential address space of an I2C bus is treated as a contiguous address space with 32K internal boundaries. A dump stops at the next 32K internal boundary even if the size of the dump is larger. The only major piece left to debug is the loader which copies a program to RAM and starts the SPIN interpreter. A smaller piece is an optimization where the COPY command only copies the part of memory that's actually used by the program and its variables. That'll speed up copying substantially.

El Paisa

Hi Mike,

I like version 15

Now is more readable.

Question:

If I go to the list for example, I got a list of line numbers.

How I can go back to the main page?

I try quit, exit, etc at not avail.

Mike Green

There is an editor exit key. The keyboard driver documentation labels this as the "apps" key. On the Parallax keyboard, it's just to the left of the "Ins" key. I don't plan to keep it this way. This is really just a temporary test setup for the editing code. Eventually, the function keys will be used. If you want, you can change the key ... In "OS_initialization.spin", in method "editWindow", the second to last line, there's a test for $CC. This is the code for the "apps" key. Look at "OS_keyboard.spin" near the end ... there's a list of all recognized key codes. Pick one you like, substitute it for the $CC and recompile.

The insert mode does work. The cursor switches from a fast blink to a slow blink. In that mode, anything typed sort of pushes the rest of the text on the line to the right rather than overwriting it. Push the insert key again and the cursor speeds up and it's in overwrite mode.

Post Edited (Mike Green) : 8/2/2006 3:00:42 PM GMT

nutson

Mike, I like your OS especially as a·basis for·custom keyboard commands and program communication.
What·puzzled me·was how you planned to transfer·programs initially·into·EEPROM, think I got it now:
- compile program in propeller IDE and load into·to boot-eeprom
- compile and load your·OS into RAM
- "copy" from boot-eeprom into·another free 32K space,·assign a name.

Right?




·

Mike Green

Nutson,
Yes, that's correct. I do expect delivery of a USBwiz later this month. This provides I2C (and SPI and serial) access to a full-capability SD/MMC card as well as USB pen-drives. I plan to add a driver for that so you can save an EEPROM image to an SD card, then run it directly from the SD card using the OS on the Propeller (or copy it to another EEPROM).
Mike

Mike Green

Bug fixes (pesky little critters!) The loader still doesn't work, but it's cleaner. The system now keeps track of I2C busses that have been recognized (with PROBE) as having EEPROM attached. This is stored at the end of the boot EEPROM (until the next upload from the Tool). If there's 64K or more of boot EEPROM, this bitmap is stored at the end of the second 32K page.

Mike Green

I finally got the assembly I2C routines working. They only do single byte transfers currently so they're about 1/3 of their expected speed. They also don't check for early write completion (fixed 5ms wait). Reading and writing work. I haven't tested booting from an EEPROM yet.

Next steps: 1) Multiple byte reads and writes without readdressing the EEPROM device 2) Booting from other than the boot EEPROM.

Kaos Kidd

Way cool Milke...
I'v ordered some 128 and 512K eeproms, and hope to use some of the stuff you are working on with it...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

---

Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd

---

·

Rob7

Great Mike,

Can't wait to take it for a test run.



Rob7.

Mike Green

Another rewrite of the higher level I2C routines. This now provides for multiple byte reads and writes (although not used yet) and for reading and writing with devices other than EEPROMs.

Mike Green

Here's another update. The multibyte reads and writes appear to work just fine. The loader appears to work up to the point where an attempt is made to restart the SPIN interpreter on the newly loaded program. Spot checking the memory contents shows that the program seems to be there. The program checksum is correct, but things just hang.

Mike Green

Now the loader works!! You can have multiple programs in 32K pages of either additional EEPROM attached to the boot I2C bus or any other pair of pins. You can load these programs and execute them and return to the "Operating System". An example of a simple such program is attached. The VGA, keyboard, and I2C drivers continue to run in their own COGs while this is happening. There are still some bugs to be fixed, mostly involving the detection and keeping track of attached EEPROMs.

nutson

Congratulations Mike, great piece of work. I expect delivery of·some 64KB·parts soon·and can't wait to see it happening on my screen.·Your code enabled me·to·experiment with·addditional·keyboard commands,·like launching·and stopping Cog's with small assembly programs,·and showing the·number of free Cog's (the Cog_counter object).

Nico Hattink

Mike Green

Attached is the latest update. The parts that keep track of where the I2C busses are attached now work. The program will
always look on the boot EEPROM buss for other EEPROMs, but you have to use the PROBE <SCL pin> to look for EEPROMs on any other pair of pins.

Some other miscellaneous bugs have been fixed.

Next task will be to finish the simple text editor so that you can create and modify simple text files that fit within a 32K EEPROM page.

Post Edited (Mike Green) : 8/24/2006 4:49:26 AM GMT

Mike Green

For those of you who noticed, I did put a copyright notice in the beginning of the "Operating System" mostly because there are pieces I've modified and used like the VGA and keyboard drivers that are copyright by Parallax. It is my intention that what I've written be freely usable as part(s) of other software as long as credit is given.

Programmertanner

thats totally awsome!!!!! · · very very cool

nutson

Mike, I am stuck.·Using version .025 I have managed to "copy boot test"·and "tst2" to a 64KByte part on pin 24, by forcing the returned free EEPROM address to $00600000 in files.searchFile (I think the·pin pair is in bits 19-22, your comments say 19-21)

Version·.029·"list" showed·me the filenames, but·refused·"copy" (can't create) "delete" (file not found).·I erased address $7fff in both·EEPROM pages, now "list" shows both pages·as·"uninitialized", but·still·refuses "copy". What do I do wrong, how can I make the two pages free again?

Nico Hattink

Mike Green

You're right about the pin pair being bits 19-22. I must have missed a comment. There are two checksums in the $7FF0-$7FFF area and an error in either one is treated as "uninitialized" so you did the right thing in trying to erase the 32K page. I'll look at the routines involved. What you did should have worked. Try erasing $7FFC and $7FFD.

nutson

Mike, I forced two "copy boot name" commands to execute, by changing line 296 in OS_initialization into "fileAddrTo := $00600000" and "$00608000". The EEPROM contents "dump" is·ok, "list" shows·the filenames I have given, but·pretty much all commands that involve these filenames (copy, delete, info, run) return "file not found". I guess the files.searchFile method always returns a false, also for free space. Still big progress, consistent EEPROM detection and handling.

Nico Hattink

Mike Green

Nico,
I've added a "test clear <pin> <page>" command that clears the filename area of the specified 32K page to $FF.
I looked at the searchFile routine and the checkSums routine and they seem to be doing what I expect. For now,
I do want to keep a strict definition of a deleted file (blanks for name, checksums correct) and check for that with
the exception of incorrect checksums implying an uninitialized file space. searchFile always returns the address
of the file found with the option bits in the lower 12 bits or it does an abort with a negative value. checkSums
returns either the 12 options bits or TRUE (-1).

I did clear up some comments and added a little comment stuff about the commands.

If you could give me the filename area contents of the EEPROM pages that are problematic (last 16 bytes), that
would help me figure out what isn't working. Thanks.
Mike

nutson

Man, you are fast. As requested.·Now going to check your new command.

Nico

nutson

No change. The "test clear" command erases the high 16 bytes alright.·Beates me.

Nico

Mike Green

Silly me! I've got a definition (ldr#maxPinPairs) for the number of I/O pin pairs and a lot of loops that use pin numbers and, in the searchFiles routine, forgot to account for the difference. searchFiles was only looking at the first 16 I/O pins and you have your EEPROM on pins 24/25 and the boot EEPROM on pins 28/29 is a special case. Please check it out for me since I'm using the Demo Board and don't have easy access to those pins. Thanks
Mike

nutson

Bingo! Works now. Not all is right, but I can delete, copy info etc. Thanks, I thought it had someting to do with your 3 bit pinpair notion. I use the demoboard too, have soldered extra wires on the mouse pins, they are weel suited for this, already have pull-up on the board.

I'll report back when I have a clear picture of things working.

Nico

codepro

It would be great if you could write the Spin OS so that it could be interfaced to the Microsoft Roboitcs Studio (http://msdn.microsoft.com/robotics/)

Mike Green

The OS is really intended as a basic framework for others to use for applications. It supplies a keyboard driver, vga text driver, and I2C routines including a SPIN loader with the routines constructed so they can continue to run as a new program is loaded and begins execution. This is not what people generally think of today as an operating system that manages lots of I/O devices and file systems, communications, and networking. It's more like what was considered to be the operating system of the DEC PDP-8 or the IBM 1620, both important process control/industrial/laboratory computers in the "old days".

There are generally usable routines like a basic line editor and command scanner routines that can be incorporated essentially unchanged into an application program. I plan to have a simple text editor for editing short text files stored in EEPROMs and I'm working on a way to download directly from the Propeller Tool to an EEPROM "file". Anything else is the responsibility of the
application program. If someone wants to use the FullDuplexSerial object or Servo32 object or Floating Point object, they can incorporate it into their program and the OS can co-exist with it.

There is no reason why an application under this OS couldn't work with Microsoft's Robotics Studio since the OS doesn't really do much. Someone else would have to do the necessary interface routines and integration on both the Propeller and the Windows end.