I guess you could use one of the pins on the stamp (maybe two) to use as a flag to the tell the stamp when you want the stamp to "LOAD" variables, and when you want the stamp to "RUN" the program.
I don't think there is anything that says you can't program from VB (you can't of course without writing your own program) but there isn't anything that said you could. Can you tell me (just curious) which microcontrollers you have found that you CAN program from VB?
I didn't want to program from VB.· I just wanted to modify variables from a VB app when the Stamp was not busy counting.
I didn't / don't know what is possible with the stamp, didn't know anything about the language, I just assumed that it was similar to BASIC, and from the little I have seen,it seems in many ways it is.· There used to be a PEEK and POKE instruction where you could "POKE" values into memory locations, or "peek" and read what memory locations contained.
·I know this is simplistic, but this is what I thought...· assume that the memory locations from 0 to 360 were available for use and could be accessed by these instructions.· I envisioned "PEEK"ing into the memory locations specified by the count of the encoder, and setting the outputs· accordingly.· I am sure this is not valid code, I don't know PBasic, but the idea was· ...·
8OutputPort=PEEK(VariableCountingEncoder)
· If the memory location specified by the VariableCountingEncoder contained the value 150, the 8OutputPort outputs would be 10010110.
·I know I am insulting your intelligence so I'll knock that off, but that was my thinking.
I figured it would only take a few instructions to accomplish the PEEK, and at 12000 per second , I should be able to get 24 instructions in each period of the encoder.· I am not totally naive, I knew it wouldn't be that clean or easy, but from the info presented on the site, I figured it was worth a shot.
The basic stamp 2 p specifies "program execution speed" of approx 12000 intstructions per second
The BS2 approx 4000 instructions.· I don't know what an instruction is... perhaps a single BASIC command contains a whole buch of assy language instructions and those are the 4000 and 12000 "program execution speeds" I don't know.
Similarly, I imagined "POKE"ing values into these memory locations from values contained in my VB app which could be changed by the user.
I am still at a loss to understand why some of you think there is something wrong with my expecting there to be a "canned" communication program that I could just drop onto a VB form and use.· I was able to use the·"Stamp editor" without writing any code.·· I get lots of stuff that I can hook up with a little usb cord or something and it communicates without my having to write code.·
I still think there should be.
Why wouldn't lots of people want a communication tool to use with VB? Why would you want to fool around with MS Comm?· I wanted to make an electronic cam, not fool around with framing errors and buffer overflows and that sort of nonsense.
Post Edited (realolman) : 9/18/2007 10:26:32 AM GMT
[noparse][[/noparse]quote]I am still at a loss to understand why some of you think there is something wrong with my expecting there to be a "canned" communication program that I could just drop onto a VB form and use. I was able to use the "Stamp editor" without writing any code. I get lots of stuff that I can hook up with a little usb cord or something and it communicates without my having to write code.
well if you comparing a program like labview, then I can say labview is it's own program, yes it has a text box that is setup as a code editor, but unlike VB the labview you can't make other exe's either. where with VB it's more designed to create exe then to communicate with other hardware. The makers of labview still spent the time to create the interface between labview and the stamp along with other controllers and other hardware.
If there was a control for the stamp to drop into vb it would be a modified version of the ms comm control, probably just the mscomm control with a couple of extra events and methods added to it. like be able to find the stamp similar to what the stamp code editor does.
or are would you want the following included?
change as you said a few variables by their machine address instead of by their variable name in code
Being able to PEEK/POKE memory locations really doesn’t provide any way to interface to the outside world since those are local functions of BASIC. The ability to send/receive commands exists through the SERIN/SEROUT commands. You simply write your code to send/receive characters from the programming port (already connected to the PC). The VB app need only open a simple COM Port and send/receive data from it serially. If both sides agree on baud rate then you’re set. Because the communication is serial, because there are no pre-defined functions and because you define these things in code on the BASIC Stamp there cannot be a function library or API for VB related to the BASIC Stamp. I hope this helps. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Chris Savage Parallax Tech Support
Well, there ARE "communication tools". If you want to use VB, then the MSComm control IS the interface to the serial port that you can use.
This is software, dude. "Canned" solutions DO exist, but apparently not for what you're looking for. The examples you gave seem to imply some way to 'memory map' the BS2 into the PC's memory space -- but that's not an interface the BS2 supports.
So, on the one hand, you're asking for something "Canned". While on the other hand, you're rejecting all the "Canned" solutions offered you. Then you're telling us (apparently) that there ARE no "canned" solutions, and that we think you're wrong for wanting one.
It's a very confusing mix of requirements you apparently have. And you explain them so poorly (and with such judgmental terms) that it's very difficult to reply without being defensive.
The solution to his conundrum is to drop back, breathe a little bit, think a little bit more about the scenario you want to achieve, and start another thread saying something like:
"I want to hook my xyz to my BS2. Then I want to run a program on my PC to 'talk' to my BS2, to get the data from my xyz and display it in a spreadsheet. What programs would I need to write to get the BS2 to do this?"
THAT kind of question we can answer.
"Don't tell me there's no canned solution for the BS2 that does what I want it to do" really HAS no good answer.
realolman,
I went back and re-read your last post where you talked about PEEK and POKE from the PC end, essentially where you could arbitrarily control the contents of the Stamp memory from the VB side. It sounds like you're talking about something like a remote debugger which is something that's available for many high level languages, particularly under Linux or Unix where the connection between debugger and program is usually via a local network connection.
The Stamp is based on a simple microcontroller with limited capabilities and the PBasic interpreter included in the Stamp's microcontroller doesn't have room for the very complex sort of debugger you're talking about on top of the PBasic interpreter itself. Except for the program download process, the Stamp always functions as the "master". Even debugging is done from that standpoint with DEBUG and DEBUGIN statements inserted by the programmer where needed.
The StampPlot program we've mentioned works as a slave to the Stamp although it provides for a GUI interface for the Stamp on the PC. The PINK webserver module also provides a web-based GUI for the Stamp where you can set variable values from a web page, but the variables are in the PINK itself, not the Stamp. The Stamp program you provide explicitly interrogates the PINK for those values.
This is really very different from what you were describing. Also, keep in mind that not everyone uses VB. There are many other scripting/programming languages and there are operating systems other than Windows. A simple serial port is generally available on almost any system and accessible to almost any programming language and transferring arbitrary data across a serial channel is simple from both the Stamp and the desktop computer side.
realolman said...
I didn't / don't know what is possible with the stamp, didn't know anything about the language, ...
This, I beleive, is central to the miscommunication and misunderstanding extant in this thread, and it's a problem with an obvious solution. You need to gain some hands-on familiarity with PBASIC first. There's an abundance of self-training materials available from Parallax, and the forum members are always glad to help with specific questions. Once you're up to speed and understand what the language and BASIC Stamps are capable of, as well as their limitations, it will be easier for to you formulate questions that we can help you with. Right now, you're in a foreign land, have a limited grasp of the local language, and the natives, as much as they want to help, are having difficulty deciphering your frustrated hand gestures. The PBASIC Berlitz course may be just the ticket!
Hi realolman, I like allanlane's approach of standing back and taking a deep breath, my ole mind is going in circles.
The main problem as I see it is catching the encoder pulses and still being able to process your cam settings. I was wondering how many cams you required and whether it would be acceptable to halve the resolution. If you brought the encoder pulse in via a 2:1 divider you would have a resolution of 1.44 deg a pulse as opposed to 0.72 but this would double the time you had to operate the cams.
It is certainly·feasible to have settings in a PC database but changing the settings on the fly with a BS2 would take too long and pulses would be missed, so to adjust the cams the machine would have to be stopped. You have the BOE so you have nothing to lose by running a few tests. If you find the BS2 can't handle it you can always port the program over to a BS2px , SX or Propeller.
This is really wild.· I'm beginning to think you guys are messing with me ...
There are several distinct and seperate things I am trying to talk about.
1. The canned communication control.·· I was able to communicate with the stamp·using the "Stamp Editor" without writing any code.··None.· I got no framing errors... no buffer overflows...·No communication errors.. .Someone with stamp expertise far exceeding mine had all the bugs worked out of it.
···Imagine a control similar to the "Stamp Editor" that I· could drop onto a form in Visual Basic and communicate with the stamp from the finished·and compiled app...·BUT the user of the app. would never see it.·And there would be no bugs or errors·due to communication...·just like the Stamp Editor...·Because I want to install an "electronic cam" in my machine... not re-invent serial communication with the stamp
·I mentioned that the·LabJack had a control exactly like that, so it is not unheard of.··There is precedence.
·· I don't want anyone to program anything beyond that.... just an easy to use method of communicating with the stamp form an app written in Visual Basic... MsComm is not an easy method.
·· The availability of such a communication tool would make the Stamp more attractive to a much greater range of users / buyers. Those who did not want to use it, would not use it, and they have lost nothing.· It's that simple.
2. There is no question that I do not know anything about the stamp·...except what I read and tried to figure out from the web site.· The web site said that the BS2P had a "program execution speed" of 12000 instructions per second.· What does that mean?··Using my 500 Hz encoder , that would be 24 instructions per pulse.·· I can't know anything about something with which I am not familiar except what the literature or advertising says.
·What constitutes an instruction? How many instructions does it take to count a pulse and set outputs?· I certainly don't know.· I'm new to the stamp.
Will it do 12000 instructions / sec.or will it not?· 12000· instructions of what kind?
3.·In the·"electronic cam" I was trying to describe, the stamp need do nothing but count pulses from 0 to 360, and·for every count, it needs to set all the available outputs to a pre programmed state for that particular count.
·It does not have to do anything beyond that on the fly.·
Cycles could be stopped to "set the program" for the ·states of the outputs at each count. That would suit me fine.
4.The PEEK and POKE commands to which I referred are old GWBASIC commands that Bill Gates killed because he couldn't have my program using his memory locations for·my purposes, even though I bought the computer and considered it mine... Windows might need them for it's purposes.· I thought that since the·STAMP didn't have a windows operating system, something similar to PEEK and POKE might be available in PBASIC... see bold point # 2
The stamp would count the pulses, and set the outputs according to the contents of the memory location that it PEEKED at, which would be determined by the count.
8OutputPortStates=PEEK( EncoderPulseCounter )
·It has nothing to do with the VB program controlling the contents of the stamp's memory.· The stamp could put the numbers in it's own memory locations... the VB program would just tell the stamp the values.·( that would be input by the user into my app and communicated to the stamp by the "canned" communication program.)
Perhaps an array would work ... I don't know... does the stamp do arrays?··· The PEEK and POKE were just ways I tried to explain ... I thought·older guys might get that.
5.You folks sure seem like nice people.... I don't think I need to explain that... but I will anyway... I gripe and admit to complete ignorance , but you are still here and still being civil.... see bold point #5.
5. Yes, these folks are nice. They even, at times, talk to me. Generally, these people, like people on other microcontroller fora I participate with, will cheerfully help another learn, but also expect the correspondent to be engaged in the learning.
Perhaps you don't mean it, but you come across with a "gimme" attitude.
4. PEEK and POKE from GWBASIC are the INx and and OUTx commands in PBASIC, at least for the external pins on the microcontroller. Access to internal memory locations are largely treated as variable references.
3. Your cam might be as simple as something like:
Loop:
if IN1 then
count = count + 1
if count = 360 then count = 1
endif
OUTL = count
goto loop
There are a few obvious problems, such as the program snippet above increments the count variable while the IN1 signal is high, not on its rising edge.
Grey code would be just a bit harder to implement. Your user-defined output for each value of count the next step.
Depending on the Stamp model you have, there may not be enough user-memory for you to specify a different byte or word pattern to be output for each value of count.
2. The code snippet above has 4 (or 6, depending on execution path) instructions: one (or two) IF, two (or three) assignments, and one GOTO. Read the PBASIC manual--each instruction is a well documented command.
1. Shrug. MSComm is a control you can drop on your application. If you don't like it, there was (last time I used comm controls a lot, there were at least three other 3rd party comm controls). Perhaps you should take a look at Jan Axelson's "Serial Port complete" website (lvr.com/serport.htm) and look for the XMComm wrapper.
Also note, assuming you are an average programmer, that there are large number of people within several standard deviations (either way) of your skill that have programmed their own comms between a PC (of a number of operating systems) and the Stamp. Question: have you considered that you will need to write the Stamp side of the transaction--how else would the Stamp know what your "commands" mean. You could just as well use any old serial comms program (remember ProComm?) or Hyperterm to interact with your Stamp, too.
As to whether Parallax sees the same value as you in supporting the tool you suggest is a marketing decision left up to them. Perhaps this is your opportunity to fill a niche need and make a buck on it too.
Okay, let’s see if we can provide more detailed answers to your points you have listed.
1. Canned Communication…You are referring to downloading the program to the BASIC Stamp. The function that allows this to happen is built into the interpreter and is the only communications facility implemented with any particular protocol. That protocol is described in the BASIC Stamp Tokenizer Library, available as a free download from our website.
2. BASIC Stamp information is available on the website, but if you really want to learn the BASIC Stamp you will need to download a PDF version of our “What’s a Microcontroller?” manual or better yet, get a starter kit. Nothing beats hands on for experimenting. You can read all the material but without applying it you just won’t know what will work in a particular/custom application.
3. Relating to the second part of #2 and #3…The BASIC Stamp executes x amount of instructions per second (approximate). Why is there no hard numbers here? Because that is impossible to define with one number. It really depends on the instruction. Different instructions take different amounts of time to execute. Take a SEROUT statement for example. You can say it takes x amount of time to execute, but that doesn’t factor in the baud rate and the amount of data being sent in the instruction, both of which affect execution time. And then there are instructions that inherently take varying amounts of time such as PAUSE, where you specify the time.
4. PEEK/POKE…While these do not exist, equivalent instructions do exist. Any variable (RAM) location can be read or written to randomly using its register name. On models that have SPRAM any location can be accessed using GET (Read) or PUT (Write). The instructions exist but you need to refer to them in the Help File or BASIC Stamp Manual. Just familiarizing yourself with that information would provide more insight to capability.
5. I hope I was able to provide useful information for you. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Chris Savage Parallax Tech Support
Comments
Sounds like Ladder Logic to me. But I suspect your trying to avoid the extreme high cost of industrial PLC equipment and software.
yes/no?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
I didn't / don't know what is possible with the stamp, didn't know anything about the language, I just assumed that it was similar to BASIC, and from the little I have seen,it seems in many ways it is.· There used to be a PEEK and POKE instruction where you could "POKE" values into memory locations, or "peek" and read what memory locations contained.
·I know this is simplistic, but this is what I thought...· assume that the memory locations from 0 to 360 were available for use and could be accessed by these instructions.· I envisioned "PEEK"ing into the memory locations specified by the count of the encoder, and setting the outputs· accordingly.· I am sure this is not valid code, I don't know PBasic, but the idea was· ...·
8OutputPort=PEEK(VariableCountingEncoder)
· If the memory location specified by the VariableCountingEncoder contained the value 150, the 8OutputPort outputs would be 10010110.
·I know I am insulting your intelligence so I'll knock that off, but that was my thinking.
I figured it would only take a few instructions to accomplish the PEEK, and at 12000 per second , I should be able to get 24 instructions in each period of the encoder.· I am not totally naive, I knew it wouldn't be that clean or easy, but from the info presented on the site, I figured it was worth a shot.
The basic stamp 2 p specifies "program execution speed" of approx 12000 intstructions per second
The BS2 approx 4000 instructions.· I don't know what an instruction is... perhaps a single BASIC command contains a whole buch of assy language instructions and those are the 4000 and 12000 "program execution speeds" I don't know.
Similarly, I imagined "POKE"ing values into these memory locations from values contained in my VB app which could be changed by the user.
I am still at a loss to understand why some of you think there is something wrong with my expecting there to be a "canned" communication program that I could just drop onto a VB form and use.· I was able to use the·"Stamp editor" without writing any code.·· I get lots of stuff that I can hook up with a little usb cord or something and it communicates without my having to write code.·
I still think there should be.
Why wouldn't lots of people want a communication tool to use with VB? Why would you want to fool around with MS Comm?· I wanted to make an electronic cam, not fool around with framing errors and buffer overflows and that sort of nonsense.
Post Edited (realolman) : 9/18/2007 10:26:32 AM GMT
well if you comparing a program like labview, then I can say labview is it's own program, yes it has a text box that is setup as a code editor, but unlike VB the labview you can't make other exe's either. where with VB it's more designed to create exe then to communicate with other hardware. The makers of labview still spent the time to create the interface between labview and the stamp along with other controllers and other hardware.
If there was a control for the stamp to drop into vb it would be a modified version of the ms comm control, probably just the mscomm control with a couple of extra events and methods added to it. like be able to find the stamp similar to what the stamp code editor does.
or are would you want the following included?
change as you said a few variables by their machine address instead of by their variable name in code
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
This is software, dude. "Canned" solutions DO exist, but apparently not for what you're looking for. The examples you gave seem to imply some way to 'memory map' the BS2 into the PC's memory space -- but that's not an interface the BS2 supports.
So, on the one hand, you're asking for something "Canned". While on the other hand, you're rejecting all the "Canned" solutions offered you. Then you're telling us (apparently) that there ARE no "canned" solutions, and that we think you're wrong for wanting one.
It's a very confusing mix of requirements you apparently have. And you explain them so poorly (and with such judgmental terms) that it's very difficult to reply without being defensive.
The solution to his conundrum is to drop back, breathe a little bit, think a little bit more about the scenario you want to achieve, and start another thread saying something like:
"I want to hook my xyz to my BS2. Then I want to run a program on my PC to 'talk' to my BS2, to get the data from my xyz and display it in a spreadsheet. What programs would I need to write to get the BS2 to do this?"
THAT kind of question we can answer.
"Don't tell me there's no canned solution for the BS2 that does what I want it to do" really HAS no good answer.
I went back and re-read your last post where you talked about PEEK and POKE from the PC end, essentially where you could arbitrarily control the contents of the Stamp memory from the VB side. It sounds like you're talking about something like a remote debugger which is something that's available for many high level languages, particularly under Linux or Unix where the connection between debugger and program is usually via a local network connection.
The Stamp is based on a simple microcontroller with limited capabilities and the PBasic interpreter included in the Stamp's microcontroller doesn't have room for the very complex sort of debugger you're talking about on top of the PBasic interpreter itself. Except for the program download process, the Stamp always functions as the "master". Even debugging is done from that standpoint with DEBUG and DEBUGIN statements inserted by the programmer where needed.
The StampPlot program we've mentioned works as a slave to the Stamp although it provides for a GUI interface for the Stamp on the PC. The PINK webserver module also provides a web-based GUI for the Stamp where you can set variable values from a web page, but the variables are in the PINK itself, not the Stamp. The Stamp program you provide explicitly interrogates the PINK for those values.
This is really very different from what you were describing. Also, keep in mind that not everyone uses VB. There are many other scripting/programming languages and there are operating systems other than Windows. A simple serial port is generally available on almost any system and accessible to almost any programming language and transferring arbitrary data across a serial channel is simple from both the Stamp and the desktop computer side.
This, I beleive, is central to the miscommunication and misunderstanding extant in this thread, and it's a problem with an obvious solution. You need to gain some hands-on familiarity with PBASIC first. There's an abundance of self-training materials available from Parallax, and the forum members are always glad to help with specific questions. Once you're up to speed and understand what the language and BASIC Stamps are capable of, as well as their limitations, it will be easier for to you formulate questions that we can help you with. Right now, you're in a foreign land, have a limited grasp of the local language, and the natives, as much as they want to help, are having difficulty deciphering your frustrated hand gestures. The PBASIC Berlitz course may be just the ticket!
-Phil
The main problem as I see it is catching the encoder pulses and still being able to process your cam settings. I was wondering how many cams you required and whether it would be acceptable to halve the resolution. If you brought the encoder pulse in via a 2:1 divider you would have a resolution of 1.44 deg a pulse as opposed to 0.72 but this would double the time you had to operate the cams.
It is certainly·feasible to have settings in a PC database but changing the settings on the fly with a BS2 would take too long and pulses would be missed, so to adjust the cams the machine would have to be stopped. You have the BOE so you have nothing to lose by running a few tests. If you find the BS2 can't handle it you can always port the program over to a BS2px , SX or Propeller.
Jeff T.
There are several distinct and seperate things I am trying to talk about.
1. The canned communication control.·· I was able to communicate with the stamp·using the "Stamp Editor" without writing any code.··None.· I got no framing errors... no buffer overflows...·No communication errors.. .Someone with stamp expertise far exceeding mine had all the bugs worked out of it.
···Imagine a control similar to the "Stamp Editor" that I· could drop onto a form in Visual Basic and communicate with the stamp from the finished·and compiled app...·BUT the user of the app. would never see it.·And there would be no bugs or errors·due to communication...·just like the Stamp Editor...·Because I want to install an "electronic cam" in my machine... not re-invent serial communication with the stamp
·I mentioned that the·LabJack had a control exactly like that, so it is not unheard of.··There is precedence.
·· I don't want anyone to program anything beyond that.... just an easy to use method of communicating with the stamp form an app written in Visual Basic... MsComm is not an easy method.
·· The availability of such a communication tool would make the Stamp more attractive to a much greater range of users / buyers. Those who did not want to use it, would not use it, and they have lost nothing.· It's that simple.
2. There is no question that I do not know anything about the stamp·...except what I read and tried to figure out from the web site.· The web site said that the BS2P had a "program execution speed" of 12000 instructions per second.· What does that mean?··Using my 500 Hz encoder , that would be 24 instructions per pulse.·· I can't know anything about something with which I am not familiar except what the literature or advertising says.
·What constitutes an instruction? How many instructions does it take to count a pulse and set outputs?· I certainly don't know.· I'm new to the stamp.
Will it do 12000 instructions / sec.or will it not?· 12000· instructions of what kind?
3.·In the·"electronic cam" I was trying to describe, the stamp need do nothing but count pulses from 0 to 360, and·for every count, it needs to set all the available outputs to a pre programmed state for that particular count.
·It does not have to do anything beyond that on the fly.·
Cycles could be stopped to "set the program" for the ·states of the outputs at each count. That would suit me fine.
4.The PEEK and POKE commands to which I referred are old GWBASIC commands that Bill Gates killed because he couldn't have my program using his memory locations for·my purposes, even though I bought the computer and considered it mine... Windows might need them for it's purposes.· I thought that since the·STAMP didn't have a windows operating system, something similar to PEEK and POKE might be available in PBASIC... see bold point # 2
The stamp would count the pulses, and set the outputs according to the contents of the memory location that it PEEKED at, which would be determined by the count.
·It has nothing to do with the VB program controlling the contents of the stamp's memory.· The stamp could put the numbers in it's own memory locations... the VB program would just tell the stamp the values.·( that would be input by the user into my app and communicated to the stamp by the "canned" communication program.)
Perhaps an array would work ... I don't know... does the stamp do arrays?··· The PEEK and POKE were just ways I tried to explain ... I thought·older guys might get that.
5.You folks sure seem like nice people.... I don't think I need to explain that... but I will anyway... I gripe and admit to complete ignorance , but you are still here and still being civil.... see bold point #5.
thanks
Let's take your points in reverse order.
5. Yes, these folks are nice. They even, at times, talk to me. Generally, these people, like people on other microcontroller fora I participate with, will cheerfully help another learn, but also expect the correspondent to be engaged in the learning.
Perhaps you don't mean it, but you come across with a "gimme" attitude.
4. PEEK and POKE from GWBASIC are the INx and and OUTx commands in PBASIC, at least for the external pins on the microcontroller. Access to internal memory locations are largely treated as variable references.
3. Your cam might be as simple as something like:
Loop: if IN1 then count = count + 1 if count = 360 then count = 1 endif OUTL = count goto loopThere are a few obvious problems, such as the program snippet above increments the count variable while the IN1 signal is high, not on its rising edge.
Grey code would be just a bit harder to implement. Your user-defined output for each value of count the next step.
Depending on the Stamp model you have, there may not be enough user-memory for you to specify a different byte or word pattern to be output for each value of count.
2. The code snippet above has 4 (or 6, depending on execution path) instructions: one (or two) IF, two (or three) assignments, and one GOTO. Read the PBASIC manual--each instruction is a well documented command.
1. Shrug. MSComm is a control you can drop on your application. If you don't like it, there was (last time I used comm controls a lot, there were at least three other 3rd party comm controls). Perhaps you should take a look at Jan Axelson's "Serial Port complete" website (lvr.com/serport.htm) and look for the XMComm wrapper.
Also note, assuming you are an average programmer, that there are large number of people within several standard deviations (either way) of your skill that have programmed their own comms between a PC (of a number of operating systems) and the Stamp. Question: have you considered that you will need to write the Stamp side of the transaction--how else would the Stamp know what your "commands" mean. You could just as well use any old serial comms program (remember ProComm?) or Hyperterm to interact with your Stamp, too.
As to whether Parallax sees the same value as you in supporting the tool you suggest is a marketing decision left up to them. Perhaps this is your opportunity to fill a niche need and make a buck on it too.
HTH,
Daniel
--Edit to add wrapping the count variable at 360.
Post Edited (daniel) : 9/19/2007 2:28:12 AM GMT
1. Canned Communication…You are referring to downloading the program to the BASIC Stamp. The function that allows this to happen is built into the interpreter and is the only communications facility implemented with any particular protocol. That protocol is described in the BASIC Stamp Tokenizer Library, available as a free download from our website.
2. BASIC Stamp information is available on the website, but if you really want to learn the BASIC Stamp you will need to download a PDF version of our “What’s a Microcontroller?” manual or better yet, get a starter kit. Nothing beats hands on for experimenting. You can read all the material but without applying it you just won’t know what will work in a particular/custom application.
3. Relating to the second part of #2 and #3…The BASIC Stamp executes x amount of instructions per second (approximate). Why is there no hard numbers here? Because that is impossible to define with one number. It really depends on the instruction. Different instructions take different amounts of time to execute. Take a SEROUT statement for example. You can say it takes x amount of time to execute, but that doesn’t factor in the baud rate and the amount of data being sent in the instruction, both of which affect execution time. And then there are instructions that inherently take varying amounts of time such as PAUSE, where you specify the time.
4. PEEK/POKE…While these do not exist, equivalent instructions do exist. Any variable (RAM) location can be read or written to randomly using its register name. On models that have SPRAM any location can be accessed using GET (Read) or PUT (Write). The instructions exist but you need to refer to them in the Help File or BASIC Stamp Manual. Just familiarizing yourself with that information would provide more insight to capability.
5. I hope I was able to provide useful information for you. Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support