Chip, I went to the forum but your post wasn't there, even though I got e-mail notification.· Did you delete it?· Anyway, thanks for the heads up - didn't actually multiply the numbers out to see how big they were.· Doing four 30-second waits shouldn't be a problem if I can ever figure out how to do it without a key press.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Chip, I went to the forum but your post wasn't there, even though I got e-mail notification.· Did you delete it?· Anyway, thanks for the heads up - didn't actually multiply the numbers out to see how big they were.· Doing four 30-second waits shouldn't be a problem if I can ever figure out how to do it without a key press.
Sid
Sid,
I responded, but then realized I hadn't read your question carefully enough, so I deleted it.
Generally speaking, you need a loop that continues to execute, regardless of whether or not a keypress comes in. The keyboard object has a method which always returns, but gives (I think) -1 if no key was pressed. Anway, you need to wrap a loop around that while checking for lapsed time (perhaps by having milestone targets for every coming 30 seconds). I hope this helps, somewhat.
The Propeller OS is intended to provide a framework for creating complex programs for the Propeller. It supplies a standard text display driver and a keyboard driver. It provides a driver for EEPROMs (and other I2C devices) including a loader for programs and fast read/write routines. The I/O drivers are designed to run continuously as successive programs load and execute so that: 1) There's continuity so there's no practical difference between related programs and overlays. 2) Programs don't need the memory overhead of the I/O drivers. Once they're initialized and loaded into their cogs, the HUB memory occupied by their assembly code is not needed.
On top of this is a simple command interpreter to allow storage of multiple named programs on attached EEPROMs. There is the beginnings of a text editor and some utility functions. At some point, support for some USB and/or SD/MMC card mass storage will be added.
The idea eventually will be to make the Propeller somewhat self-supporting with at least a native assembler, possibly with a native SPIN compiler. There already exist two simple Basic interpreters for the Propeller that have no provisions for loading/saving of programs, but this could be added. There's a Forth system under construction that could be integrated as well.
In many ways, this is more like the early DOS or pre-PC small computer OS than what most people associate with the name today.
I deleted my prevoous post because I didn't asl all the questions.
I need to input a value like $02 from the keyboard, and then set "day" - or hour, date, etc. - equal to this value.· How would I write this?·· I want to be able to reset my DS1302 on the fly.
Thanks
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Sid,
Look at the OS_mainProgram.spin file in the OS, particularly the method "getNumber" near the end. This will pick up characters from the screen buffer on the current line and process them as numbers, including decimal, hex ($), and binary (%). You can just cut and paste this routine (and the following "hexDigit" method) into your program then call it. You'll need the method "skipBlanks" too. For picking up words from the displayed information, use the method "getTextWord". The "enterDoCommand" method is the command scanner for the OS and contains all kinds of examples of different format commands and how they're scanned.
Mike
Mike, I'll try to decipher all that.· I know you're very busy so I won't ask for help.· If I can't make it work, I can always unplug the DS1302 and take it over to my Stamp to reset it.·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Mike, would I use day, hrs, etc., for the numberAddr?· If so, then I would have to call this method 7 times, each time with a different numberAddr.· What would the normal value of x be?··0?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Sid,
Basically yes to both. numberAddr points to a long where the binary value is placed. You would call this method 7 times, each time with a different numberAddr (to place the number). The value of x passed on the first call would be 0 if you wanted to begin scanning at the first column of the current row of the display. If you want to start at some other column, use that as the value of x. The routine always returns a new value of x if it's successful and that is normally used on the next call. Again, look at the command scanner. It usually uses "x := \getNumber(x,@value)". Error conditions always abort with a negative number and column numbers are never negative, so check for x < 0 after the call. Remember that the scanner sees what you see on the display because it's reading out of the display buffer.
Mike
I added the GetNumber, skipBlanks and hexDigit methods, changing dsp. to text. and substituting u for x in the skipBlanks method and in all references in the other methods.
When I select Set time from the menu, the program jumps to getNumber.· I entered "$02" from the keyboard but nothing displayed on my screen and I could not get out of the "Enter day" line.· Do I need to add the WindowEditor object to the program?· The program compiled fine without it.· I think this is the line I'm having trouble with:
c := text.windowChar(u++,0)·
Whenever you have time.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Sid,
1) The second parameter to getNumber is an address. You need to put @day there instead of just day.
2) getNumber doesn't read from the keyboard. It just looks at the screen buffer. You need to write a routine that reads from the keyboard, displays on the screen, and stops at an Enter key code (or whatever you want). The WindowEditor object will do that for you and handles things like backspaces. You can look at the beginning of the "enterDoCommand" routine to see how the WindowEditor is called. If you want, you could modify getNumber and skipBlanks to read directly from the keyboard, substituting calls to key.getkey and dsp.out where there's a call to dsp.windowChar. You'd have to add some kind of handling for the Enter key and a backspace key if you wanted it. I think using the WindowEditor is better.
3) getNumber uses the abort statement on errors. If you don't use the "\" prefix to catch the abort, your program will just stop when an error occurs (like illegal character or end of line when it's not expected). Look at the examples of its use.
Mike
Mike, I just couldn't get the Prop to reset the DS1302 so I went back to the Stamp.· This time I used a BS2pe with a DS1302 piggyback.· When I ask· Stamp A·for the time the VGA displays:
The current time is 15:52:51 - Eastern Standard Time
Today is November 16, 2006
I added two more options to my Menu:
M - Send data to Stamp A·for storage
R - Read Stamp A EEPROM
I get the temperature from Stamp B, then send the data to Stamp A, where it is stored in bank 8.· If some time later I key in "R", Stamp A responds and the VGA displays:
Temperature was 79.6 at 15:35:36 on 11/16/2006
Temperature was·78.9 at 15:36:01 on 11/16/2006
Temperature was·78.5 at 15:47:22 on 11/16/2006
I can store 227 such entries in bank 8 and roll over to Bank 9 if I want to continue storing.· This leaves 6 banks to store·other data.
If I want to start over, I have an option at the beginning of the Stamp A program that lets me write 0's to all 2048 bytes of bank 8.
When the Stamp writes a data batch to EEPROM, it increments the EEPROM address and·WRITEs that address to the EEPROM in bank 0.· When the Stamp writes the next batch of data, it READs the EEPROM and gets the next address, so it knows where to write to.
Pretty neat, huh?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Mike, I modified my Propeller program and the program for the Stamp that stores the temperature data in EEPROM.· A picture of what the VGA display looks like now is attached.
When the temperature data is received from the data-collecting Stamp, the data to be stored in EEPROM is entered manually for each location.· The next step is to modify both Stamp programs so that when the data Stamp sends its info the the Propeller, it also sends it to the EEPROM Stamp for storage.· Not sure how I'm going to do it yet -· and don"t say "That sounds easy enough" - nothing is easy for me where the Propeller is concerned.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Mike, finally got all the programs modified.· Wound up with Stamp B sending the normal transmission to the Propeller, then transmitting an "M" to put Stamp A in the 'datastore' mode, followed by "I(nside), temp data, O(utside).temp data, S(hop), temp data".· Works perfectly.· I was even able to format the VGA display so that each group of three - Inside, Outside and Shop - is followed by a blank line.· Makes the whole thing very readable.· Here is what the display looks like:
Sid,
You're really doing a nice job of splitting multiple functions among different processors and communicating back and forth. Sometimes with the ability of the Propeller to run several tasks at once, we forget that some tasks can be easily off-loaded to something like a Stamp or another Propeller.
Mike
I've learned a lot about talking betweem the Propeller and a Stamp.· I'm actually using four Stamps now.· Stamp A, a BS2pe, is my clock
(DS1302 PB)·and EEPROM storage Stamp.· Stamp B, a BS2,·is my data collection Stamp.· Stamp C, a BS2,·receives temp data from Stamp D, a BS2, which is located out in the shop.· The Prop, Stamp A and Stamp B all have XBEE transceivers.· Stamp C receives data from Stamp D via a Parallax 433mHz transmitter/receiver, which I happened to have on hand, ·and relays the data to Stamp B via hardwired connections.
It has taken quite awhile to get everything working reliably and to give me the VGA display I wanted.· I could never have done it without your OS system and that outstanding "simulation" object.· That was the key to the whole thing.
I'm thinking of adding a wind direction and velocity module to Stamp B to complete my 'weather station', but·I need to check on the format of the wind module output.· The module is from fascinatingelectronics.com.
I'll keep you posted.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Mike, I decided I would try my hand at machining a block, so I revised my Mill program.· The revision included the addition of two methods for moving the cutter up and down 50 mils, so I could call it from a DAT list.· Everything works fine, but in the revision process I noticed somewthing weird.· In the top half of the program where direction and travel·are entered from the keyboard, the pulsetrain =
"pulsetrain := (dist * Xppm)/100 ".
In the Autorun section pulsetrain =
"pulsetrain := (dist * Xppm)/50"
Both sections use the same pulsepin method, and a travel of 1000 is exactly the same, whether entered manually or via Autorun.· I have looked at the program a dozen times and I can not figure out why the two different statements produce the same result.· Can you tell me?· I have attached a copy of the original Mill program, without the revisions ,·in case you need to refresh your memory.
Whenever you have the time.
Thanks
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Yesterday is history, tomorrow is a mystery, and today is a gift.
Sid,
You'll have to figure this one out for yourself. Your program is too complex and not well enough documented for its complexity for me to sort out. Clearly there are maybe 6-8 places where you have "/100" and 2-3 places where you have "/50". I suggest you figure out what set of control inputs you would need to force the program through one set of computations (with "/100") and which ones to force it though the path with the "/50", then compare the outputs. You might be able to figure out why it seems to work ok. It may be that the program isn't going through the paths you think and, fortuitously, it's actually doing the "right thing".
The trick in debugging this sort of thing is to really simplify what you're trying to debug. You program is doing all sorts of things that, hopefully, don't affect this particular computation (for pulsetrain). If you can pare the logic down to a simple flow chart that just involves pulsetrain and inputs and decisions that affect pulsetrain, you can often figure out what's really happening (and fix it). Good luck.
Comments
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
I responded, but then realized I hadn't read your question carefully enough, so I deleted it.
Generally speaking, you need a loop that continues to execute, regardless of whether or not a keypress comes in. The keyboard object has a method which always returns, but gives (I think) -1 if no key was pressed. Anway, you need to wrap a loop around that while checking for lapsed time (perhaps by having milestone targets for every coming 30 seconds). I hope this helps, somewhat.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
To work like a PC?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
On top of this is a simple command interpreter to allow storage of multiple named programs on attached EEPROMs. There is the beginnings of a text editor and some utility functions. At some point, support for some USB and/or SD/MMC card mass storage will be added.
The idea eventually will be to make the Propeller somewhat self-supporting with at least a native assembler, possibly with a native SPIN compiler. There already exist two simple Basic interpreters for the Propeller that have no provisions for loading/saving of programs, but this could be added. There's a Forth system under construction that could be integrated as well.
In many ways, this is more like the early DOS or pre-PC small computer OS than what most people associate with the name today.
Check out my large memory model for propellers... you might find it useful [noparse]:)[/noparse]
Bill
I need to input a value like $02 from the keyboard, and then set "day" - or hour, date, etc. - equal to this value.· How would I write this?· · I want to be able to reset my DS1302 on the fly.
Thanks
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Look at the OS_mainProgram.spin file in the OS, particularly the method "getNumber" near the end. This will pick up characters from the screen buffer on the current line and process them as numbers, including decimal, hex ($), and binary (%). You can just cut and paste this routine (and the following "hexDigit" method) into your program then call it. You'll need the method "skipBlanks" too. For picking up words from the displayed information, use the method "getTextWord". The "enterDoCommand" method is the command scanner for the OS and contains all kinds of examples of different format commands and how they're scanned.
Mike
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Basically yes to both. numberAddr points to a long where the binary value is placed. You would call this method 7 times, each time with a different numberAddr (to place the number). The value of x passed on the first call would be 0 if you wanted to begin scanning at the first column of the current row of the display. If you want to start at some other column, use that as the value of x. The routine always returns a new value of x if it's successful and that is normally used on the next call. Again, look at the command scanner. It usually uses "x := \getNumber(x,@value)". Error conditions always abort with a negative number and column numbers are never negative, so check for x < 0 after the call. Remember that the scanner sees what you see on the display because it's reading out of the display buffer.
Mike
Got the clock program reading the time fine in OS.· Then I added a menu option to set the time:
·"C":
······· text.out(0)
········text.str(string("Enter day"))
······· getnumber(0,day)
······· settime
I added the GetNumber, skipBlanks and hexDigit methods, changing dsp. to text. and substituting u for x in the skipBlanks method and in all references in the other methods.
When I select Set time from the menu, the program jumps to getNumber.· I entered "$02" from the keyboard but nothing displayed on my screen and I could not get out of the "Enter day" line.· Do I need to add the WindowEditor object to the program?· The program compiled fine without it.· I think this is the line I'm having trouble with:
c := text.windowChar(u++,0)·
Whenever you have time.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
1) The second parameter to getNumber is an address. You need to put @day there instead of just day.
2) getNumber doesn't read from the keyboard. It just looks at the screen buffer. You need to write a routine that reads from the keyboard, displays on the screen, and stops at an Enter key code (or whatever you want). The WindowEditor object will do that for you and handles things like backspaces. You can look at the beginning of the "enterDoCommand" routine to see how the WindowEditor is called. If you want, you could modify getNumber and skipBlanks to read directly from the keyboard, substituting calls to key.getkey and dsp.out where there's a call to dsp.windowChar. You'd have to add some kind of handling for the Enter key and a backspace key if you wanted it. I think using the WindowEditor is better.
3) getNumber uses the abort statement on errors. If you don't use the "\" prefix to catch the abort, your program will just stop when an error occurs (like illegal character or end of line when it's not expected). Look at the examples of its use.
Mike
The current time is 15:52:51 - Eastern Standard Time
Today is November 16, 2006
I added two more options to my Menu:
M - Send data to Stamp A·for storage
R - Read Stamp A EEPROM
I get the temperature from Stamp B, then send the data to Stamp A, where it is stored in bank 8.· If some time later I key in "R", Stamp A responds and the VGA displays:
Temperature was 79.6 at 15:35:36 on 11/16/2006
Temperature was·78.9 at 15:36:01 on 11/16/2006
Temperature was·78.5 at 15:47:22 on 11/16/2006
I can store 227 such entries in bank 8 and roll over to Bank 9 if I want to continue storing.· This leaves 6 banks to store·other data.
If I want to start over, I have an option at the beginning of the Stamp A program that lets me write 0's to all 2048 bytes of bank 8.
When the Stamp writes a data batch to EEPROM, it increments the EEPROM address and·WRITEs that address to the EEPROM in bank 0.· When the Stamp writes the next batch of data, it READs the EEPROM and gets the next address, so it knows where to write to.
Pretty neat, huh?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
When the temperature data is received from the data-collecting Stamp, the data to be stored in EEPROM is entered manually for each location.· The next step is to modify both Stamp programs so that when the data Stamp sends its info the the Propeller, it also sends it to the EEPROM Stamp for storage.· Not sure how I'm going to do it yet -· and don"t say "That sounds easy enough" - nothing is easy for me where the Propeller is concerned.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
96···· Inside···· 77.7··· 11:39:50··· 01/16
104·· Outside·· 83.4··· 11:39:50··· 01/16
112·· Shop····· 69.2· ·· 11:39:50··· 01/16
120·· Inside·····78.0··· 12:29:56··· 01/16
128·· Outside···77.8··· 12:29:56··· 01/16
136·· Shop····· ·72.1··· 12:29:56··· 01/16
and so on.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
You're really doing a nice job of splitting multiple functions among different processors and communicating back and forth. Sometimes with the ability of the Propeller to run several tasks at once, we forget that some tasks can be easily off-loaded to something like a Stamp or another Propeller.
Mike
I've learned a lot about talking betweem the Propeller and a Stamp.· I'm actually using four Stamps now.· Stamp A, a BS2pe, is my clock
(DS1302 PB)·and EEPROM storage Stamp.· Stamp B, a BS2,·is my data collection Stamp.· Stamp C, a BS2,·receives temp data from Stamp D, a BS2, which is located out in the shop.· The Prop, Stamp A and Stamp B all have XBEE transceivers.· Stamp C receives data from Stamp D via a Parallax 433mHz transmitter/receiver, which I happened to have on hand, ·and relays the data to Stamp B via hardwired connections.
It has taken quite awhile to get everything working reliably and to give me the VGA display I wanted.· I could never have done it without your OS system and that outstanding "simulation" object.· That was the key to the whole thing.
I'm thinking of adding a wind direction and velocity module to Stamp B to complete my 'weather station', but·I need to check on the format of the wind module output.· The module is from fascinatingelectronics.com.
I'll keep you posted.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
where can I find the source for your "simulation" object?
Regards
David
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
"pulsetrain := (dist * Xppm)/100 ".
In the Autorun section pulsetrain =
"pulsetrain := (dist * Xppm)/50"
Both sections use the same pulsepin method, and a travel of 1000 is exactly the same, whether entered manually or via Autorun.· I have looked at the program a dozen times and I can not figure out why the two different statements produce the same result.· Can you tell me?· I have attached a copy of the original Mill program, without the revisions ,·in case you need to refresh your memory.
Whenever you have the time.
Thanks
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yesterday is history, tomorrow is a mystery, and today is a gift.
That is why they call it the present.
Don't have VGA?
Newzed@aol.com
You'll have to figure this one out for yourself. Your program is too complex and not well enough documented for its complexity for me to sort out. Clearly there are maybe 6-8 places where you have "/100" and 2-3 places where you have "/50". I suggest you figure out what set of control inputs you would need to force the program through one set of computations (with "/100") and which ones to force it though the path with the "/50", then compare the outputs. You might be able to figure out why it seems to work ok. It may be that the program isn't going through the paths you think and, fortuitously, it's actually doing the "right thing".
The trick in debugging this sort of thing is to really simplify what you're trying to debug. You program is doing all sorts of things that, hopefully, don't affect this particular computation (for pulsetrain). If you can pare the logic down to a simple flow chart that just involves pulsetrain and inputs and decisions that affect pulsetrain, you can often figure out what's really happening (and fix it). Good luck.