Propeller OS - TV version
Mike Green
Posts: 23,101
I've switched from using the VGA driver to using a TV text driver. Over time, I intend to support both. I'm still trying to be able to load directly from the Propeller Tool using the OS via a separate serial connection, but am having problems. The rest seems to work. Please report any problems with the text output. Note that because of screen size, the dump format is hex only.
Comments
I'm intrigued by your O/S. What is the purpose of such an O/S, and how does one leverage this from robotics dev perspective
thanks
I plan to have a simple text editor as part of the system for creating and modifying text files for use by programs and will probably add some support for the uALFAT and USBWiz devices from GHI Electronics. These provide access to SD/MMC cards and, in the case of USBWiz, USB keychain Flash drives.
As you might imagine, this could serve as the base for a Propeller development system if a compiler/assembler were to be written for the Propeller. It could also be used for the development of any complex system for the Propeller where a keyboard, display, and external memory would be useful, particularly where overlays or multiple modules would be needed.
This is very much like what was considered to be the "Operating System" for early commercial/scientific computers when these had disk drives. Memory was limited, I/O drivers were complex, and the "Operating System" was mostly a file manager, loader, I/O driver set, and command interpreter for a simple command set.
Post Edited (Mike Green) : 9/13/2006 1:27:05 PM GMT
" ", otherwise the screen filled uop with the + sign.· Is there any way to modify the hires object so that it will work like vga.text - in other words, allow me to enter strings, use 13 for a carriage return, and so on without calling the screen address for each instance.· I would really like to use the hires version because I could get so much more data on the screen, but based on the Demo, trying to convert my program to the hires would be virtually ompossible.· Maybe I'm asking too much.· I can post a copy of my current program if you think you have a solution.· Either way, thanks.
Sid
I changed the CON for bootAddr to:
bootAddr·· = ldr#i2cBootSCL << 28
28 is the SCL pin and 29 is the SDA pin, both with pullups
·My monitor displayes the Propeller Operating System·line, then I get:
"boot eeprom not accessible, can't continue"
Where did I go wrong?
Sid
Now I can play around with your OS. (I didn't have a spare VGA monitor sitting around)
Thanks for investing the time into something so useful.
--Andrew Arsenault
Sid
The pin number for the boot SCL is defined at the beginning of OS_loader as i2cBootSCL (= 28). The other modules reference this. Change bootAddr back to the original definition. The EEPROM addresses (like bootAddr) consist of a 4 bit I2C pin pair number (0 - 15 = pins 0/1 - 30-31), a 3 bit device address, and a 16 bit address within the device. 32Kx8 EEPROMs only have a 15 bit address and the system checks for that. bootAddr is the address of the 32Kx8 boot EEPROM within this space. The "<< 18" just positions the pin number properly in this 23 bit EEPROM address.
The OS checks to make sure that the bootAddr EEPROM address is present before continuing and it looked like address 0 since the upper 9 bits are ignored.
Mike
Mike
I changed the vga start pin to 8 and left bootAddr at <<18.· I still get the error message.· The keyboard works fine - I disabled the EEPROM error line and got around that OK -· the program is waiting for an input of some kind.· I entered various keystrokes and the screen just says "unknown command".· What sort of entry is the program waiting for?· Is there a "list" of acceptable commands?· Sorry to be such a pain, but it would be really nice if I can get this program going.· I have no idea how to incorporate all of this into my existing program but I'll worry about that later.
Sid
I don't know why you're getting the EEPROM error. Do you have a "home made" Propeller board? Are you using a PropStic? I thought I fixed the bugs involving the identification of EEPROMs.
Sid
When I read that, I figured it was time to try your Propeller OS. My setup is just a PropSTICK on a couple of protoboards. Wired up the TV jack, PS/2 connectors for mouse and keyboard, and 8 LEDs so far, per the Demo board pinouts.
Was hoping I would not be running into problems like Newzed was. Nope. It ran the first time, which puts a smile on one's face.
Now to figure out what all one needs to do to utilize it.
Thanks Mike for all this development effort. Makes the job of using the Propeller so much easier. This is quite some forum and group of people having a fun time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
if not key.present
··· text.str(string("--> keyboard not present, can't continue"))
··· long[noparse][[/noparse]ldr#initMarker] := 0
··· abort false
· start
then copied and pasted the first part of my own program.· After a couple of corrections, the monitor now displays my starting menu.· It is going to be quite a job to get my whole program to run in hires because of the differences in so many of the keywords.· So.....before I start this, can I change the font size?· Or maybe change the resolution to 800x600 or to maybe 640x480 to make the letters larger?· How do I do this?
I must say that this program looks like a monumental effort on your part.· The Propeller community owes you a very large "Thank you" !!
Sid
If you look in "OS_vgaHiresText" you'll see 3 sets of CON definitions, one for 640 x 480, one for 800 x 600, and one for 1024 x 768. One set is active (I think the first), the other two are commented out. Simply uncomment the one you want and make the other two commented out and everything will adjust. That's really the only way to change the effective font size and it does work.
The test for EEPROM presence is still important in that some parts of the "file system" do check for the presence of EEPROM before looking to see if there are any files present in an EEPROM. If you're not using any of the built-in commands and not using the named file stuff, it shouldn't matter. The loader will run just fine if you supply it with an EEPROM address (in the format I mentioned). You can write your own copy routines that don't use file names and just copy from EEPROM to EEPROM using addresses.
I really haven't made plans other than to complete what I've started using the tools (I/O drivers and Propeller) available at this time. I did finally receive a uALFAT and plan to add some support for that since it adds a huge amount of potential storage transportable between a Propeller and PC. Once there's a second generation Propeller defined and if it has enough memory and speed to provide for a TV and VGA driver without using most of the memory available for the screen buffer and possible window buffers, I could see converting to a GUI.
I would like to further modify the tv and vga text drivers so that they're interchangable other than for screen size and the range and granularity of colors available. That way, users could develop programs independent of the display used. Similarly, it would be nice to make the tv and vga graphics drivers interchangable for the same reason. I wouldn't try to do conventional text manipulation on a graphical bitmap for speed reasons. Scrolling text in a graphics area is very processor intensive and the size of the vga bitmap very much limits what you can do on the current Propeller.
If I press "M" at the start menu (inventory scan) and enter the part number the program responds properly.· I can scan a tag with the RFID reader and it scans OK, but it does not communicate with the Stamp.· In fact, none of the commands involving communication with the Stamp will work.· The Stamp uses Prop Pins 0 and 1, and I feel like there is a conflict somewhere like these pins are being used by the Propeller for something else.· And my Stamp gets very hot.· Went back to my original program and everything works OK.
Sid
The resolution stuff (640x480, etc.) I copied directly from Chip's VGA driver and it does work. In the uploaded copy, it's already set to 640 x 480. Maybe you've already got it set to the largest font presentation possible. 1024x768 is really tiny except on a physically large display.
The only time the OS looks at pins other than 28/29 for the EEPROM, 26/27 for the keyboard, and 16-19 for the vga display is if you use the PROBE command which looks on the specified pair of pins for other EEPROMs. My test Demo Board has another EEPROM attached to pins 0/1 and it's ignored unless you do a "PROBE 0" command first.
Even if the OS thought there was an EEPROM on pins 0/1, those pins are left as inputs except when the OS is attempting to read from an EEPROM there which only takes maybe 200 microseconds, not enough to cause heating. You do have current limiting resistors between the Propeller and the Stamp? You need them anyway to protect the Propeller from the Stamp's 5V I/O pins.
You've got some strange stuff going on that doesn't make sense. Could you send me a copy of the modified OS files to look at?
Mike
Sid
I looked at your program and I can't see any reason for the Stamp communication not to work. The only cogs running in addition to the main one are: 2 for VGA video and these are Chip's VGA driver, 1 for keyboard and this is also unmodified, 1 for I2C and this is idle - just waiting for a command. None of these would mess with any pins other than those for VGA and keyboard. In any event, the BS2 routines reinitialize DIRA and OUTA when they're called. The BS2.start routine just saves the pin numbers for later.
I didn't try stopping and starting the video driver repeatedly. I did make sure it started properly and stored the right information and I did try stopping it, making sure it updated some tables then. I'll look at that over the weekend.
Do you have the current Propeller Tool (I think it's 0.98.1)? The earlier version had some bugs.
You don't need the "OS_editWindow" routines since you've removed the references to them from "OS_initialization"
Mike
I could turn the VGA off with no problem - I just couldn't turn it back on again.· I'll load the OS program again and try to communicate with the Stamp.
Sid
The problem with a GUI in the current Propeller is that it's tremendously resource intensive. Andre does his sprite graphics system partly by splitting up the work among a bunch of cogs and building several scan lines in advance that way. The cog doing the actual video output is mostly waiting for the WAITVID instruction to start the next tile, but WAITVID can't tolerate any delay. If the data isn't ready, it gets dropped. For the primary market for the Propeller chip, that of a general purpose microcontroller, you need to keep other cogs free for sensors, keyboard, mouse, servos, serial I/O, i2c or SPI, etc. Tieing up 4 or 5 cogs for just the video will only work for gaming or a very simple application. Your ideas are interesting and would probably work, but not for the general case (keeping most of the resources free for other stuff).
We do need a GUI and it probably should be built on the work Andre has done for the Hydra. We could certainly do buttons and simple lists, but I wouldn't want to try to do any significant amount of text on the Propeller using graphics, certainly labels and simple field entry and that may be enough for many applications. I'm really interested in seeing what's been done for the Hydra for that reason.
The Stamp doesn't get hot until I send a command to it, then it heats up very rapidly.
If I enter "A" at the start menu, the LED on the Stamp lights up just like it should.· The Stamp then sends a message back to the Prop - "Red motor on" - but instead of displaying the message the VGA displays a random line from one of my DAT lists.· The controlling method is "recdata2" at Line 204.· It really looks like OS or vga_hires_text is inhibiting or misdirecting the response from the Stamp in some way.· I'll be happy to run any tests you would like.
Sid
You've got unbounded recursion going on in your "start" and "start1" routines. You're probably not noticing a problem until you've entered a few commands and the stack has had a chance to start overwriting parts of the work areas for the OS. Your code looks like:
PUB start1 senddata2 ..... showMenu ..... waitcnt(wait*2+ cnt) start1You didn't run into this before because, when your program runs by itself, there's no used memory above it. Eventually, your program would stop working because the stack pointer would run out of RAM space and point into ROM. There's also a call to "start" after trying to restart the display. The OS's vga start routine needs some local variables and these get allocated in the stack. You should be able to rewrite this just using a repeat loop in the start1 routine.
Mike