For reference, here is the diagram from the Parallax documentation, but with the signal names and directional arrows drawn in.
There is nothing sacred about using those particular pins. But the functional connections have to be 100% correct and match the software.
One thing about the BS2px is that it executes code about 3 times faster than the BS2. The datalogger is particular about time delays, so it may be that problems you are having could be due to the 'px being faster. In particular, the units for SERIN timeout are 0.4 milliseconds instead of 1.0 millisecond. I'd suggest you look through the program and find all instances of SERIN and multiply the timeout value 2.5 or 3. For example, in "DataLoggerTestv1.1", the Purge subroutine has the following line,
SERIN RX\RTS, Baud, 500, No_Data, [noparse][[/noparse]ioByte]
Change that to,
SERIN RX\RTS, Baud, 1500, No_Data, [noparse][[/noparse]ioByte]
Do that for all the SERIN statements in both programs. You can make it a compile time constant like this:
speedFactor CON 3
SERIN RX\RTS, Baud, 500*speedFactor, No_Data, [noparse][[/noparse]ioByte]
I did not check the pause because I figured a factory program would work without modifications. I looked and there is from pause 50 to pause 500. I will look and see what happens. You are saying to increase the pause rate by the amount of multiplication of the speed of the chip. Right? I will try this Sunday. I am braindead now.
I am referring only to the SERIN commands, and I count only 2 of them in the Demo program and 3 of them in the Test program. I am not referring to the PAUSE commands. Those have units of 1 millisecond across the entire Stamp II line. That is, a PAUSE 500 will be very close to 1/2 second on any of the Stamp II series. However in
SERIN RX\RTS, Baud, 500, No_Data, [noparse][[/noparse]ioByte]
The 500 is the timeout delay parameter, that specifies how long SERIN waits for a returned character before giving up. If no character arrives, it branches to No_Data, but if a character does arrive, it continues on with the next instruction after the SERIN.
On the BS2, BS2e and BS2pe, the units come out to 500 milliseconds, but on the BS2sx, BS2p and BS2px, the units come out to 500 * 0.4 = 200 milliseconds. That may not be enough time for the memorystick datalogger to respond. Thus increase it to 1500 => 600 milliseconds, which is about the same as the program for the BS2 intended. (1500 * 0.4 = 600.) Or 1250 => 500 milliseconds.
The PAUSE commands in the program are kind of ad hoc. You can play with those too, but without good reason, I don't see which of them to twiddle.
OK, I will see about that. Thanks for helping me learn all kinds of new things. I am still braindead and won't tackle this all day for a while. I just don't understand why this stuff doesn't work out of the box. I guess so we can learn more.
and, by the way, I really like your art work. It is really helping me to see with my mind.
Here's another program to try. It can run on any Stamp by changing the $STAMP directive at the top.
The program is informational. It shows the VDAP firmware version that is installed on the datalogger, and then the root directory listing and the brand name, capacity and formatting of the attached thumb drive.
The conditional compilation statements
at the beginning of code are designed to take
care of the differences in baud serial timing from
stamp to stamp.
You can start that program either by pressing reset on the Stamp, or by powering up the Stamp and datalogger at the same time while the debug screen is active (19200 baud for the 'px, 9600 for other Stamps). Please let me know if it works for you, and if not, how far it gets.
If done at a power-up, it shows the first stage messages from the datalogger as it intitializes. If you have a firmware update file from Vinculum.com on the thumb drive, you will see it detect the update and apply it, and then reboot with the new firmware. The current version from Vinculum is 3.66. It is worthwhile to get the updates, because they are faster and also because they deal with compatibility issues.
The program has an additional compiler conditional for power control. It defaults to zero so that it does not include the power control "vPwr PIN 15". But on my own board I have p15 going to the ON-OFF control terminal of a voltage regulator, so that the Stamp can control the power to the datalogger. If you implement that hardware, then set the conditional compile variable, "#DEFINE powercontrol=1", instead of "#DEFINE powercontrol=0".
thanks again, Dr. Allen. I can't wait to go home and try this. I have been busy with social company and church work as well as honey dos. But, I hope to be free soon to try this.
OK, maybe some closure. I tried Dr. Allen's Program and it initialized and then kept timing out.
I called up Parallax and talked to an extremely nice young man by the name of Josh.· He patiently stayed with me while I explained my whole delima. On the TEST program, it went as far as generating random number (7638) I believe or something like that. It is the same each time I start the program. After the random number is created, it gives me a random number error·message.· He said he did not know what was happing on the test program. I have downloaded it many times to make sure it did not have a glitch.
But, when I ran the demo program, he stepped me through it and he said it was working as it is supposed to. I just never gave it any data.· I was trying to use this as a flash drive to save programs on to operate one at a time from the flash drive. He explained that this was really not the purpose of the data logger.
So, at this time, I can't use· the IR stuff because all my house is wired with florescent lights that interfere with the IR detectors, I have to find another way to use the datalogger.
I will have to just live with my limitations. At least I have two robots and some people have none. I will have to be happy with what I have.
Thanks for all of your help. This has been a mess for both you and me.· I am sorry for that.
But, I still plan to build two more robots and work with these to boebots and maybe I can still come up with some of the things I wanted to do.
I like to play with artificial intellegence (maybe because I have none of my own, ha!ha!).
I will talk later with my other adventures.· Be good and Happy Robotting!
Comments
I took a break because I have been at it for 9 hours. I am back and I am going to re-examine everything.
There is nothing sacred about using those particular pins. But the functional connections have to be 100% correct and match the software.
One thing about the BS2px is that it executes code about 3 times faster than the BS2. The datalogger is particular about time delays, so it may be that problems you are having could be due to the 'px being faster. In particular, the units for SERIN timeout are 0.4 milliseconds instead of 1.0 millisecond. I'd suggest you look through the program and find all instances of SERIN and multiply the timeout value 2.5 or 3. For example, in "DataLoggerTestv1.1", the Purge subroutine has the following line,
SERIN RX\RTS, Baud, 500, No_Data, [noparse][[/noparse]ioByte]
Change that to,
SERIN RX\RTS, Baud, 1500, No_Data, [noparse][[/noparse]ioByte]
Do that for all the SERIN statements in both programs. You can make it a compile time constant like this:
speedFactor CON 3
SERIN RX\RTS, Baud, 500*speedFactor, No_Data, [noparse][[/noparse]ioByte]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
As always, Thanks!
I am referring only to the SERIN commands, and I count only 2 of them in the Demo program and 3 of them in the Test program. I am not referring to the PAUSE commands. Those have units of 1 millisecond across the entire Stamp II line. That is, a PAUSE 500 will be very close to 1/2 second on any of the Stamp II series. However in
SERIN RX\RTS, Baud, 500, No_Data, [noparse][[/noparse]ioByte]
The 500 is the timeout delay parameter, that specifies how long SERIN waits for a returned character before giving up. If no character arrives, it branches to No_Data, but if a character does arrive, it continues on with the next instruction after the SERIN.
On the BS2, BS2e and BS2pe, the units come out to 500 milliseconds, but on the BS2sx, BS2p and BS2px, the units come out to 500 * 0.4 = 200 milliseconds. That may not be enough time for the memorystick datalogger to respond. Thus increase it to 1500 => 600 milliseconds, which is about the same as the program for the BS2 intended. (1500 * 0.4 = 600.) Or 1250 => 500 milliseconds.
The PAUSE commands in the program are kind of ad hoc. You can play with those too, but without good reason, I don't see which of them to twiddle.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
and, by the way, I really like your art work. It is really helping me to see with my mind.
Thanks again!
Thanks for all of your help.
The program is informational. It shows the VDAP firmware version that is installed on the datalogger, and then the root directory listing and the brand name, capacity and formatting of the attached thumb drive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
at the beginning of code are designed to take
care of the differences in baud serial timing from
stamp to stamp.
If done at a power-up, it shows the first stage messages from the datalogger as it intitializes. If you have a firmware update file from Vinculum.com on the thumb drive, you will see it detect the update and apply it, and then reboot with the new firmware. The current version from Vinculum is 3.66. It is worthwhile to get the updates, because they are faster and also because they deal with compatibility issues.
The program has an additional compiler conditional for power control. It defaults to zero so that it does not include the power control "vPwr PIN 15". But on my own board I have p15 going to the ON-OFF control terminal of a voltage regulator, so that the Stamp can control the power to the datalogger. If you implement that hardware, then set the conditional compile variable, "#DEFINE powercontrol=1", instead of "#DEFINE powercontrol=0".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I called up Parallax and talked to an extremely nice young man by the name of Josh.· He patiently stayed with me while I explained my whole delima. On the TEST program, it went as far as generating random number (7638) I believe or something like that. It is the same each time I start the program. After the random number is created, it gives me a random number error·message.· He said he did not know what was happing on the test program. I have downloaded it many times to make sure it did not have a glitch.
But, when I ran the demo program, he stepped me through it and he said it was working as it is supposed to. I just never gave it any data.· I was trying to use this as a flash drive to save programs on to operate one at a time from the flash drive. He explained that this was really not the purpose of the data logger.
So, at this time, I can't use· the IR stuff because all my house is wired with florescent lights that interfere with the IR detectors, I have to find another way to use the datalogger.
I will have to just live with my limitations. At least I have two robots and some people have none. I will have to be happy with what I have.
Thanks for all of your help. This has been a mess for both you and me.· I am sorry for that.
But, I still plan to build two more robots and work with these to boebots and maybe I can still come up with some of the things I wanted to do.
I like to play with artificial intellegence (maybe because I have none of my own, ha!ha!).
I will talk later with my other adventures.· Be good and Happy Robotting!
:-)