I think Mike may be using my TV_wtext object instead of TV_text. If so, here is the list of control characters it recognizes:
CLS = $00 'clear screen
HOME = $01 'home
CRSRXY = $02 'set X, Y position (X, Y follow)
CRSRLF = $03 'cursor left
CRSRRT = $04 'cursor right
CRSRUP = $05 'cursor up
CRSRDN = $06 'cursor dn
USECLR = $07 'use color C (C follows)
BS = $08 'backspace
TAB = $09 'tab (8 spaces per)
LF = $0A 'linefeed
CLREOL = $0B 'clear to end of line
CLRDN = $0C 'clear down (to end of window)
CR = $0D 'return
CRSRX = $0E 'set X position (X follows)
CRSRY = $0F 'set Y position (Y follows)
DEFWIN = $10 'define window W (W, Left, Top, nCols, nRows follow)
USEWIN = $11 'use window W (W follows)
DEFCLR = $12 'define color C (C, FG, BG follow)
SCRLLF = $13 'scroll window left
SCRLRT = $14 'scroll window right
SCRLUP = $15 'scroll window up
SCRLDN = $16 'scroll window down
CHGCLR = $17 'change all colors in window to C (C follows)
CLRW = $1E 'same as CLR, but can be used in strings.
ESC = $1F 'escape next character C (i.e. print as-is) (C follows)
ZERO = $FF 'can be used for 0, which is not allowed in strings, for command arguments
Except for the windowing and color stuff, these are much the same as the PBasic DEBUG screen commands. You can copy these definitions into a CON block and use the names in your code instead of the numbers to help readability.
Sid,
One of the items on top of my Spin wish list is an inline constructor for strings, along with byte, word, and long arrays, that allows variables and expressions. It would be very handy also for creating parameter lists where the number of parameters can vary. Hopefully, someday...
When I tried to compile, I got an error "Expected an instruction or variable"
and it highlighted the "serialOut" word.· Can you think of any reason why?
It is exactly like my other Prop program, which works great.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
1) You need at a minimum a Propeller Demo Board or the equivalent with a PS/2 keyboard connection and either a TV video connection or a VGA connection. By equivalent, I mean "wired the same as the Demo Board".
2) The OS runs out of the standard 32K boot EEPROM as supplied on the Demo Board, PropStick, or equivalent. It works better and you can do more if you have more memory, either additional 32K EEPROMs or larger I2C EEPROMs attached in place of the standard boot EEPROM or in addition to the boot EEPROM on the same I2C bus (pins 28/29) or as an additional I2C bus on any pair of I/O pins.
3) You need a PC running Windows XP and the Propeller Tool to compile and download programs including the OS. A Mac will work if you have an Intel Mac with BootCamp or a Power PC Mac running Guest PC or Virtual PC.
5) The OS is not what most people think of these days as an operating system. It's basically some I/O routines (keyboard, display, and I2C) and a program loader along with a simple command interpreter. It has a framework for more, like the beginnings of a simple text editor and a very simple file system using EEPROMs.
Sid,
Please look at the example I just posted previously. Maybe the double quotes I put around the whole phrase confused you. Here it is as a code fragment:
OK, Mike - I've got the Stamp receiving a string.· I wrote:
sendstr(string("Hello *,0"))
The " * " terminates the Stamp string if it is less than the declared bytes.·
Now then another question - the Hello is written into the program for a start.
In real life I would like to press the option key, have the screen say:
"Enter string to transmit"· and then be able to enter a string, save it to a
variable, then be able to write sendstr(string(variable)).
How do I do that?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Why don't you try to come up with something to do this? You have to accumulate a sequence of bytes in a byte array from the serial input routine, check for some kind of terminating character like a return (13). You have to store a zero at the end of the string (when the return comes in). You have to check for too many characters. When that's all done, you have a zero-terminated string in a byte array. You can pass the address of the byte array to sendstr (or any other routine that expects the address of a string).
You are asking a lot, Mr. Green.· I can send a string from a DAT list, so now
I'll·try the on-the-fly thing.· If you don't hear from me in 24 hours call 911.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Mike, I declared a VAR "msg[noparse][[/noparse]16]" - 16 being the number of bytes in the Stamp
serstring, and wrote the following new method:
PUB writestr | p ··· text.out(0) ··· p := 0 ··· text.str(string("Enter string to send",13,13)) ··· repeat until· (msg[noparse][[/noparse]p] := key.getkey) == 13 ····· text.out(msg[noparse][[/noparse]p++]) ··· sendstr(@msg)
At the prompt I typed in··"Does it work?*0" (without the quotes) and the
Stamp· debug displayed··"Does it work?".· It would have been nice is the
Stamp had said· "Of course!"· but I guess it's not that smart.
I never thought I could do it.· I think I shall promote myself again.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Now how would you add:
1) The zero byte at the end. (It worked the first time. Try calling writestr a second time and entering just "Hello?")
2) Checking for too many characters (Hint: Treat the 16th character as if it were a return)
Hello* - without the 0 - it works just as well, probably because when p
increments and I press Enter, it reads a 0 - I'm not sure.· However, I can not
leave off the *.· Without that the Stamp keeps waiting for another byte
unless the Prop sends 16 bytes.
On the too many characters thing, I didn't worry too much about that.· The
Stamp is going to limit any reception to 16 bytes.
I'm working on the Stamp writing to EEPROM whatever it receives from the
Prop.· If I get that worked out, I can switch to a BS2pe and use the last 8
banks - 16KB - for inventory data.· That would save a lot of memory in the
Prop.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
1) The problem with leaving off the zero isn't on the Stamp end. It's on the Propeller end. The serialStr routine keeps sending characters until it finds a zero. If, for some reason, there isn't a zero byte for several thousand bytes beyond the end of the entered string, the Propeller will keep sending what it finds until it stumbles across a zero.
2) Again, I'm not worried about the Stamp end. On the Propeller end, you will eventually start storing characters into the next declared variable (or maybe into a section of SPIN interpretive code).
These boundary conditions are important. They often "bite" you when you least expect it and are difficult to find.
Sid,
No. What you describe is implemented in some programming languages, but not in C or SPIN for example. The declaration simply defines how much memory is set aside. Your program will continue merrily storing typed characters in successive locations in memory until something critical gets overwritten (or your fingers tire and you quit typing).
Mike
I wanted to add some math functions to my workhorse Prop program, so I
started writing the necessary methods, checking the program after each
addition.· And then........the program started acting weirdly, jumping to
methods that hadn't even been called.· I spent hours redoing and checking,
then I remembered something Mike had said about "popping" off the stack.
I really didn't understand what Mike was saying, but I had the feeling that
something was running into something.· So I saved the program as a new
version, deleted everything that was not fundamental to what I wanted to
do, and lo and behold, everything worked perfectly.
I still had about 2800 longs free when I was having the problem so it could
not have been lack of memory.· That leaves the stack - whatever that is -
as the source of the trouble.
The point of this is - is there some way the Propeller Tool could be modified
to alert the user when he is about to have a stack problem?· Had it not been
for Mike's comment, I would never have figured out what was wrong.· Maybe
the stack is not the problem, but no other possibility comes to mind.
Thanks, gentlemen.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Sid,
You may also recall some comments of mine about recursion. In some of your programs, you are using the procedure call as a form of goto and that does cause exactly what you're observing. You're basically calling a routine that never returns and that routine calls another that never returns, etc. Eventually, some routine calls the first routine and the stack just keeps getting filled higher and higher with return addresses.
The Propeller Tool unfortunately can't tell you for sure whether you're going to have stack problems. It takes a lot of analysis on the part of the compiler to even make a good guess and that takes a huge development effort which Parallax is not set up for.
Mike
Mike, I'm back to this EEPROM thing again.· If I load the mill program into
the Demo board, it saves the X and Y positions just fine.· If I load the same
program into my Propeller board, it will not save them.· As far as I can tell
my Propeller board is exactly like the Demo board with the following
exceptions:
VGA start pin is 8 instead of 16
Only one PS/2 connector
No headphones or mike connections
The Demo board is programmed via a USB MiniB cable whereas my Propeller ··· board is programmed via a Prop Plug.
The pullup I had on SCL has been removed.· After programming the Propeller,
I removed the Prop Plug just in case.· Can you think of any reason the
Propeller board will not save X and Y?· I can give you the Expresspcb layout
of the board if that would be any help.· This is driving me bananas.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Sid,
It's driving me crazy too. I've corrected a variety of bugs in the OS and added some features in the last couple of weeks, but I'm holding off on posting anything until I can find and fix this intermittant problem with I2C I/O. It doesn't seem to show up on my main test rig (Demo Board with an additional Microchip 64K x 8 EEPROM on pins 0/1), but shows up on my new test rig with one or two 128K x 8 Atmel boot EEPROMs substituted for the standard 32K x 8 one. The Demo Board works fine with 400KHz I2C bus timing, but the new setup will only work at 100KHz and not 100% then. It's puzzling.
Mike
Sid,
There would be slightly longer paths from the chip to the board and probably from the DIP socket to the EEPROM, but it shouldn't make that much difference. The EEPROMs are not super high speed chips. The fastest clocks I use are 400KHz and the signals back and forth to the EEPROMs should be stable well under the minimum 250ns setup/hold times at the 400KHz clock rate. The video happens to be set up on pins 24-27 and there might be coupling to the adjacent pins, but I don't have an analog scope to check. I would expect more frequent problems and more random ones if that were the problem and that's not the case.
Mike
Mike, I have been trying to figure out a way for the Prop to display the time automtically every two minutes if there is no Menu selection.· So far no luck.· Here is the method where menu selection is made:
PRI getChoice : selectedOption
{ Accept menu choice. Returns uppercase letter. } · 'key.clearkeys · repeat ··· repeat until selectedOption := key.key ····· text.str(string(19,34,10,240)) ····· waitcnt(clkfreq/2 + cnt) ···· text.str(string(19,34,254,200))· ····· waitcnt(clkfreq/2+ cnt) ··· if (selectedOption => "a") and (selectedOption =< "z")························ ····· selectedOption -= 32··· '32 = ("a" - "A")··'Convert letters to uppercase · until (lookdown (selectedOption : "ABCDEFOQGMNTPRS"))
I was trying to figure out a way to say "If no key is pressed within
waitcnt(clkfreq*120 + cnt) selection := "G".· Any suggestions?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Sid Weaver
Don't have VGA?
Comments
I guess that's just the way they designed it. There is no mention of $02 in the out command docs.
I think Mike may be using my TV_wtext object instead of TV_text. If so, here is the list of control characters it recognizes:
Except for the windowing and color stuff, these are much the same as the PBasic DEBUG screen commands. You can copy these definitions into a CON block and use the names in your code instead of the numbers to help readability.
Sid,
One of the items on top of my Spin wish list is an inline constructor for strings, along with byte, word, and long arrays, that allows variables and expressions. It would be very handy also for creating parameter lists where the number of parameters can vary. Hopefully, someday...
-Phil
repeat y from 21 to 25 text.out($02) text.out(x) text.out(y) text.str(string("*",13))??
Graham
simulator object, the senddata method and the recdata method.
PUB SendData(c)
·· serialOut(0,c,stampBaud,sim#NInv,8)
PUB recData | c
··· text.str(string(13,13,"· Received:· "))
··· repeat until (c := serialIn(1,stampBaud,sim#NInv,8)) == 10
····· text.out(c)
··· text.out(13)
··· waitcnt(wait + cnt)
When I tried to compile, I got an error "Expected an instruction or variable"
and it highlighted the "serialOut" word.· Can you think of any reason why?
It is exactly like my other Prop program, which works great.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
What do I need to do to get the OS to run?
Do I need a blank memory or simply a place to store it?
Do I need a computer or something else?
What is the newest version?
2) The OS runs out of the standard 32K boot EEPROM as supplied on the Demo Board, PropStick, or equivalent. It works better and you can do more if you have more memory, either additional 32K EEPROMs or larger I2C EEPROMs attached in place of the standard boot EEPROM or in addition to the boot EEPROM on the same I2C bus (pins 28/29) or as an additional I2C bus on any pair of I/O pins.
3) You need a PC running Windows XP and the Propeller Tool to compile and download programs including the OS. A Mac will work if you have an Intel Mac with BootCamp or a Power PC Mac running Guest PC or Virtual PC.
4) Look at this thread <http://forums.parallax.com/forums/default.aspx?f=25&m=147980&p=1> for the current version.
5) The OS is not what most people think of these days as an operating system. It's basically some I/O routines (keyboard, display, and I2C) and a program loader along with a simple command interpreter. It has a framework for more, like the beginnings of a simple text editor and a very simple file system using EEPROMs.
I added two new methods:
PUB sendstr(str)
··· serialStr(0, str, stampBaud,sim#NInv,8 )
···········
PUB serialStr(pin, str, Baud, mode, bits ) | c·········
· repeat while (c := byte[noparse][[/noparse]str++]) <> 0
····· serialOut(pin,c,Baud,mode,bits)
Then I called sendstr with:
sendstr("Hello",0)
I got an error saying a ) was expected after the H - what did I not do?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Remember, you have to use the "string()" built-in function like "sendstr(string("Hello",0))".
Mike
" 0 " in?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
sendstr(string("Hello, 0")
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Please look at the example I just posted previously. Maybe the double quotes I put around the whole phrase confused you. Here it is as a code fragment:
sendstr(string("Hello",0))sendstr(string("Hello *,0"))
The " * " terminates the Stamp string if it is less than the declared bytes.·
Now then another question - the Hello is written into the program for a start.
In real life I would like to press the option key, have the screen say:
"Enter string to transmit"· and then be able to enter a string, save it to a
variable, then be able to write sendstr(string(variable)).
How do I do that?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
I'll·try the on-the-fly thing.· If you don't hear from me in 24 hours call 911.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
serstring, and wrote the following new method:
PUB writestr | p
··· text.out(0)
··· p := 0
··· text.str(string("Enter string to send",13,13))
··· repeat until· (msg[noparse][[/noparse]p] := key.getkey) == 13
····· text.out(msg[noparse][[/noparse]p++])
··· sendstr(@msg)
At the prompt I typed in··"Does it work?*0" (without the quotes) and the
Stamp· debug displayed··"Does it work?".· It would have been nice is the
Stamp had said· "Of course!"· but I guess it's not that smart.
I never thought I could do it.· I think I shall promote myself again.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Graham
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
Now how would you add:
1) The zero byte at the end. (It worked the first time. Try calling writestr a second time and entering just "Hello?")
2) Checking for too many characters (Hint: Treat the 16th character as if it were a return)
Hello* - without the 0 - it works just as well, probably because when p
increments and I press Enter, it reads a 0 - I'm not sure.· However, I can not
leave off the *.· Without that the Stamp keeps waiting for another byte
unless the Prop sends 16 bytes.
On the too many characters thing, I didn't worry too much about that.· The
Stamp is going to limit any reception to 16 bytes.
I'm working on the Stamp writing to EEPROM whatever it receives from the
Prop.· If I get that worked out, I can switch to a BS2pe and use the last 8
banks - 16KB - for inventory data.· That would save a lot of memory in the
Prop.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
2) Again, I'm not worried about the Stamp end. On the Propeller end, you will eventually start storing characters into the next declared variable (or maybe into a section of SPIN interpretive code).
These boundary conditions are important. They often "bite" you when you least expect it and are difficult to find.
you can write to it?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
No. What you describe is implemented in some programming languages, but not in C or SPIN for example. The declaration simply defines how much memory is set aside. Your program will continue merrily storing typed characters in successive locations in memory until something critical gets overwritten (or your fingers tire and you quit typing).
Mike
Mike
I wanted to add some math functions to my workhorse Prop program, so I
started writing the necessary methods, checking the program after each
addition.· And then........the program started acting weirdly, jumping to
methods that hadn't even been called.· I spent hours redoing and checking,
then I remembered something Mike had said about "popping" off the stack.
I really didn't understand what Mike was saying, but I had the feeling that
something was running into something.· So I saved the program as a new
version, deleted everything that was not fundamental to what I wanted to
do, and lo and behold, everything worked perfectly.
I still had about 2800 longs free when I was having the problem so it could
not have been lack of memory.· That leaves the stack - whatever that is -
as the source of the trouble.
The point of this is - is there some way the Propeller Tool could be modified
to alert the user when he is about to have a stack problem?· Had it not been
for Mike's comment, I would never have figured out what was wrong.· Maybe
the stack is not the problem, but no other possibility comes to mind.
Thanks, gentlemen.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
You may also recall some comments of mine about recursion. In some of your programs, you are using the procedure call as a form of goto and that does cause exactly what you're observing. You're basically calling a routine that never returns and that routine calls another that never returns, etc. Eventually, some routine calls the first routine and the stack just keeps getting filled higher and higher with return addresses.
The Propeller Tool unfortunately can't tell you for sure whether you're going to have stack problems. It takes a lot of analysis on the part of the compiler to even make a good guess and that takes a huge development effort which Parallax is not set up for.
Mike
the Demo board, it saves the X and Y positions just fine.· If I load the same
program into my Propeller board, it will not save them.· As far as I can tell
my Propeller board is exactly like the Demo board with the following
exceptions:
VGA start pin is 8 instead of 16
Only one PS/2 connector
No headphones or mike connections
The Demo board is programmed via a USB MiniB cable whereas my Propeller
··· board is programmed via a Prop Plug.
The pullup I had on SCL has been removed.· After programming the Propeller,
I removed the Prop Plug just in case.· Can you think of any reason the
Propeller board will not save X and Y?· I can give you the Expresspcb layout
of the board if that would be any help.· This is driving me bananas.
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
It's driving me crazy too. I've corrected a variety of bugs in the OS and added some features in the last couple of weeks, but I'm holding off on posting anything until I can find and fix this intermittant problem with I2C I/O. It doesn't seem to show up on my main test rig (Demo Board with an additional Microchip 64K x 8 EEPROM on pins 0/1), but shows up on my new test rig with one or two 128K x 8 Atmel boot EEPROMs substituted for the standard 32K x 8 one. The Demo Board works fine with 400KHz I2C bus timing, but the new setup will only work at 100KHz and not 100% then. It's puzzling.
Mike
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·
There would be slightly longer paths from the chip to the board and probably from the DIP socket to the EEPROM, but it shouldn't make that much difference. The EEPROMs are not super high speed chips. The fastest clocks I use are 400KHz and the signals back and forth to the EEPROMs should be stable well under the minimum 250ns setup/hold times at the 400KHz clock rate. The video happens to be set up on pins 24-27 and there might be coupling to the adjacent pins, but I don't have an analog scope to check. I would expect more frequent problems and more random ones if that were the problem and that's not the case.
Mike
PRI getChoice : selectedOption
{ Accept menu choice. Returns uppercase letter. }
· 'key.clearkeys
· repeat
··· repeat until selectedOption := key.key
····· text.str(string(19,34,10,240))
····· waitcnt(clkfreq/2 + cnt)
···· text.str(string(19,34,254,200))·
····· waitcnt(clkfreq/2+ cnt)
··· if (selectedOption => "a") and (selectedOption =< "z")························
····· selectedOption -= 32··· '32 = ("a" - "A")··'Convert letters to uppercase
· until (lookdown (selectedOption : "ABCDEFOQGMNTPRS"))
I was trying to figure out a way to say "If no key is pressed within
waitcnt(clkfreq*120 + cnt) selection := "G".· Any suggestions?
Sid
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?
Newzed@aol.com
·