I'm very glad you did not give up on this project!
You might have to be somewhat more direct with Parallax. Your request for their help was down towards the bottom of your message. I'd either send tech support an e-mail outlining the problem and including the url of this entire thread, or start a new thread with a subject line that makes it clear you are asking specifically for their help.
I've done both, including calling them. I cannot recommend one method over the other. All have worked very well for me. Additionally, folks reading this thread will probably offer help, as well.
It snowed a little while ago. But, it is too warm and it all went away. Things are back to normal here in The Land Of Oz, except the wind has died way down. I'm sure the gusts aren't over 50mph, or so.
Can you take a picture of your actual setup? Or post a correct schematic?
The FREQ directive does NOT change the running clock speed of an SX running standalone -- whatever the resonator is is what the clock speed will be. The FREQ directive tells both the compiler what frequency to presume when generating code for SERIN, SEROUT, etc. and for setting up the SX-Key in debug mode.
If you have a given FREQ, make sure to have a resonator that matches that freq and that your OSC settings are correct, and that you have the parallel resistor (see the SX manual for values) across the outer two pins of the resonator (10k for 20mhz-50mhz, higher values for lower clock speeds). The resonators are not polarized -- the outer two pins go to the OSC pins, the inner pin is ground.
If your FREQ directive does not match the resonator, then SX/B timed commands like SERIN, SEROUT, PAUSE, PULSIN, RCTIME, etc. will be way off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ When the going gets weird, the weird turn pro. -- HST
I will agree with you that the PDB is the BEST tool for developing SX28 apps -- especially those that want to talk with a BS2.
Again, don't take the simple stuff for granted; in 35+ years of experimenting I cannot count the number of times when a bad connection or broken wire (inside the insulation) has caused me hours if not days of misery.
Okay-
This is a very good thread (at least for me) for a couple reasons:
1. It got me to play with my new PDB!! Yeah, use that device!! [noparse]:)[/noparse]
2. It got me playing with my SX!!!
So, with happiness out of the way, lets get onto unhappiness. I have tried all three of JonnyMac's demo programs for talking to and from a BS2 with an SX. None of them work for me. I have checked and double and triple checked my connections. The darn 'forget to put the resonator in' thing got me...twice ( one day, shawn, you wont be stupid ).
I am attaching the first program as modified by me. I have a BS2SX not a bs2. I am also attaching the SX program as I could not find a 20 M resonator, but found a 4 M. I am also attaching a schematic of my hookup ( a quick one ).
I understand Jon got his running on his PDB, and I know his programs work. Just not for me. Im with Ugha - what can I be doing wrong? The program works for me, just no good data. In my first program I slowed it down so I could see the led blink for each byte, and my bs2 cycled through the data, but all I got on the debug window from the stamp was <?>. The other two programs did nothing, I waited about 2 minutes, but nada.
·
edit:uploaded photo of hookups
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Shawn Lowe
When all else fails.....procrastinate!
Post Edited (Shawn Lowe) : 2/12/2009 3:39:42 AM GMT
Shawn:
I'm glad I'm not the only one going bonkers trying to figure this out!
PLEASE by all means, let me know if you come up with a solution!
I've attached two programs I wrote that work a great deal like JonnyMac's BS2_TO_SX programs... except for the case change anyways.
They are extremely simple and I was using them to just figure out if there was something wrong with my processors... they both work perfectly.
The SX program is completely in SX/B and very poorly coded (no constants, no subs/functions) as this was purely a test platform to see if
I could figure out any way for serial to work at all.
I did find one thing out though... the SX is so fast that when communicating with a BS2 using flow control and SEROUT, you have to wait for the
control line to come back up to 1 between each byte or else it'll send the data faster than the stamp can raise pins high and low, thus missing the
first bit or two and receiving garbage (This is why my previous program had to send a byte of "trash" to get them in sync).
My testing reveals no problems sending uninterrupted SEROUTs if flow control isn't used... but I wouldn't trust it to always be true.
I still can't get JonnyMac's version to work, even after attempting to tweak it. You can attribute that to my complete lack of understanding for
assembly though.
Can someone else attempt JonnyMac's programs? If we can find someone else that it works for, we can compare the setups and track down the
problem.
Edit: I forgot to mention that I used Watch in JonnyMac's programs and it shows that the bytes are being received corrupted for some reason I
can't figure.
Is serial active-low? I thought it was active-high?
Would the SX's internal pullup work?
Also, to take a screenshot press the Print Screen (sometimes Prn Scr) button on your keyboard. To take a picture of JUST your active window (the window
your working in right now) press alt+print screen.
Then paste it into an art program like Microsoft Paint.
Zoot-
Yeah, I was going to try that last night. I even suggested Ugha try, but I couldn't see anything in any posts about it. I should have been more thourough. I'll give it a shot after work tonight. Ugha, if you can try it sooner, let me know your results!
After you press Alt+PrintScreen, do you see anything or does it just copy to the clipboard?
After you press Alt+PrintScreen, do you see anything or does it just copy to the clipboard?
You can paste it into Word or Paint or even Excel (I think). To paste it, call up the target program (say, Word), click Edit/Paste, or simply do a Ctrl-V.
Ugha and Shawn -- TIME TO START A THREAD JUST FOR YOUR SERIAL comm. questions. This thread is all over the place ("Learning SX/B??") . The need for a pullup has been mentioned several times.
The serial protocol used by JonnyMac and others is generally open true (not the same as "active-low" or "active-high"). This means when the device wants to send a 0, it drives the wire LOW. When it wants to send a 1 it sets the pin to INPUT, letting the pullup generate the high. Sometimes Jon cheats and has the SX drive the line high, and uses a series resistor to take care of possible shorts, but if OPEN TRUE (OT) is used on the Stamp or SX side with SERIN/SEROUT, you will get the line set to input for "1s".
The internal pullups on the SX are not strong enough for this purpose, unless your platform is remarkably free of noise and interference.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ When the going gets weird, the weird turn pro. -- HST
Since those having trouble seem to be applying more guesswork than science I'm going to guess that the ghost of Mickey Mouse (I live near the Disney studio) is watching over my desk, making this work for me but not for you! (Relax, I'm poking a bit of fun to lighten up this thread)
On the odd event that I just got lucky after four hours of work last Saturday I removed a project from my PDB, reconnected the SX to the BS2, and then re-ran the programs. Thank you, Mickey! -- they work yet again. I've even taken a picture of my setup and used different colored wires so that you can see exactly how I did it. For those that want to pay travel and per diem, I'm happy to bring my setup to your home to prove it to you!
For review (warning: science stuff):
* True mode means the line idle state is high. A start bit will go low and the data bits, which arrive LSB first, will have their normal polarity (i.e., a "1" is high, a "0" is low); the stop bit is at the line idle state (high for True mode). See attached image.
* True mode communications drives the TX and CTS outputs all the time -- this means that no pull-ups are required for this program to work properly. It also means that we need to initialize these pins as outputs and high (both sides do this).
* True mode is not a "cheat" -- it's used when the TX line of one device connects to the RX of another and comms flows in one direction only (on that connection). Why use Open True mode, then? We only need this mode when using half-duplex communications on the same wire, that is, the TX line can become an RX line and vice-versa (like with the PSC); by using Open baud modes we can prevent an electrical conflict if both sides try to transmit at the same time.
As a reminder... frustration rarely brings solutions. I walked away from my desk more than once on Saturday to clear my head when I got frustrated. After the first program worked, everything after flowed very easily. It will for you, too -- if you just hang in and not give up.
Aha! After getting my project working (again) I went back and looked at Shawn's image to see what was up. Shame on you, pal -- you owe me a beer. Why?....
Because you're using a BS2sx and didn't change the serial baud constant in the PBASIC program which is setup for a stock BS2. Maybe this is Ugha-bugga's problem as well: a BS2sx is NOT a BS2; they work at different speeds and require different constants for some functions (e.g., SEROUT and SERIN). Now, if Ugha said he was using a BS2sx then I apologize. Shawn changed the $STAMP constant but not the baud constant for the BS2sx. Lesson for us all (the little things we overlook will kick our butts).
I modified the program so that it will conditionally compile for any BS2-series Stamp with the correct baud constant for the selected Stamp and the desired baud rate. I retested and guess what? It still works (thank you, Mickey)! No change is required to the SX program because the compiler takes care of the baud timing for the specified rate.
Man, I hope that this settles this thread....
[noparse][[/noparse]Edit] Interesting final note: The PBASIC help file says that 19.2K is the fastest baud for use with flow control, and yet this program works great at 38.4K. The spec is either very conservative (likely) or meant for Stamp-to-Stamp comms.
P.S. -- in my experience *all* the Stamps will do 38.4k baud in both directions, with or w/o flow control, but on the slower Stamps you MUST use STR to tx or rx multiple bytes from/to an array or implied array -- if you use individual discrete byte variables, the set up time for each one will blow 38.4k baud.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ When the going gets weird, the weird turn pro. -- HST
As I had this back on my PDB I connected a 'scope to the LED pin just to look at the timing. You'll see that the LED is on for about 1.5ms which is the time spent in the TX_BYTE subroutine (with flow control). As a byte at 38.4K takes just 0.26ms to transmit the rest of the time is the BS2 loading the SEROUT instruction and taking its CTS pin low to allow the SX to transmit.
The very long low period in the signal is due to the BS2 using DEBUG to report in and out bytes to the PC.
Zoot said...
P.S. -- in my experience *all* the Stamps will do 38.4k baud in both directions, with or w/o flow control, but on the slower Stamps you MUST use STR to tx or rx multiple bytes from/to an array or implied array -- if you use individual discrete byte variables, the set up time for each one will blow 38.4k baud.
I'm in agreement with Zoot, here. In fact, in my "packet" demo that was part of Saturday's work the BS2 end has SERIN setup like this:
The point that Zoot is making is that with just one SERIN we're receiving multiple bytes at the desired rate -- using individual SERINs for each byte would kill throughput.
I've attached the updated "packet" programs that have the C/C baud setup. And my friend Bean pointed out something in my ASM code that could be improved to allow the SX programs to migrate to the SX48. All updates tested (working) and attached.
I like the full Program approach, instead of the code fragment approach. Since I'm not just learning the SXB code, But also the compiler/Editor as well. I think this was the reason the BS2 was so successful. It had well documented programs and I tried most of them and got a feel for the $BS2 and the Editor before I ever went on line and did something really complex and need help.
Just a Suggestion.
Bill Chennault: Can You Imagine what the SX28 would have done for A ignition module to replace the points? I still struggle to see how a dual point Distributor could make and break @ 10,000RPM's even tough it's at half the crank speed, It still has to fire 8 cylinders???!!!!Chrysler Had there ($h^%) Stuff together.
________________$WMc%__________
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Truth is out there············································ BoogerWoods, FL. USA
Yes, you are absolutely correct. An SX would have improved things immensely. In the meantime, I guess they had strong springs to keep those points from bouncing.
Comments
I'm very glad you did not give up on this project!
You might have to be somewhat more direct with Parallax. Your request for their help was down towards the bottom of your message. I'd either send tech support an e-mail outlining the problem and including the url of this entire thread, or start a new thread with a subject line that makes it clear you are asking specifically for their help.
I've done both, including calling them. I cannot recommend one method over the other. All have worked very well for me. Additionally, folks reading this thread will probably offer help, as well.
It snowed a little while ago. But, it is too warm and it all went away. Things are back to normal here in The Land Of Oz, except the wind has died way down. I'm sure the gusts aren't over 50mph, or so.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
The FREQ directive does NOT change the running clock speed of an SX running standalone -- whatever the resonator is is what the clock speed will be. The FREQ directive tells both the compiler what frequency to presume when generating code for SERIN, SEROUT, etc. and for setting up the SX-Key in debug mode.
If you have a given FREQ, make sure to have a resonator that matches that freq and that your OSC settings are correct, and that you have the parallel resistor (see the SX manual for values) across the outer two pins of the resonator (10k for 20mhz-50mhz, higher values for lower clock speeds). The resonators are not polarized -- the outer two pins go to the OSC pins, the inner pin is ground.
If your FREQ directive does not match the resonator, then SX/B timed commands like SERIN, SEROUT, PAUSE, PULSIN, RCTIME, etc. will be way off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Again, don't take the simple stuff for granted; in 35+ years of experimenting I cannot count the number of times when a bad connection or broken wire (inside the insulation) has caused me hours if not days of misery.
This is a very good thread (at least for me) for a couple reasons:
1. It got me to play with my new PDB!! Yeah, use that device!! [noparse]:)[/noparse]
2. It got me playing with my SX!!!
So, with happiness out of the way, lets get onto unhappiness. I have tried all three of JonnyMac's demo programs for talking to and from a BS2 with an SX. None of them work for me. I have checked and double and triple checked my connections. The darn 'forget to put the resonator in' thing got me...twice ( one day, shawn, you wont be stupid ).
I am attaching the first program as modified by me. I have a BS2SX not a bs2. I am also attaching the SX program as I could not find a 20 M resonator, but found a 4 M. I am also attaching a schematic of my hookup ( a quick one ).
I understand Jon got his running on his PDB, and I know his programs work. Just not for me. Im with Ugha - what can I be doing wrong? The program works for me, just no good data. In my first program I slowed it down so I could see the led blink for each byte, and my bs2 cycled through the data, but all I got on the debug window from the stamp was <?>. The other two programs did nothing, I waited about 2 minutes, but nada.
·
edit:uploaded photo of hookups
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe
When all else fails.....procrastinate!
Post Edited (Shawn Lowe) : 2/12/2009 3:39:42 AM GMT
I'm glad I'm not the only one going bonkers trying to figure this out!
PLEASE by all means, let me know if you come up with a solution!
I've attached two programs I wrote that work a great deal like JonnyMac's BS2_TO_SX programs... except for the case change anyways.
They are extremely simple and I was using them to just figure out if there was something wrong with my processors... they both work perfectly.
The SX program is completely in SX/B and very poorly coded (no constants, no subs/functions) as this was purely a test platform to see if
I could figure out any way for serial to work at all.
I did find one thing out though... the SX is so fast that when communicating with a BS2 using flow control and SEROUT, you have to wait for the
control line to come back up to 1 between each byte or else it'll send the data faster than the stamp can raise pins high and low, thus missing the
first bit or two and receiving garbage (This is why my previous program had to send a byte of "trash" to get them in sync).
My testing reveals no problems sending uninterrupted SEROUTs if flow control isn't used... but I wouldn't trust it to always be true.
I still can't get JonnyMac's version to work, even after attempting to tweak it. You can attribute that to my complete lack of understanding for
assembly though.
Can someone else attempt JonnyMac's programs? If we can find someone else that it works for, we can compare the setups and track down the
problem.
Edit: I forgot to mention that I used Watch in JonnyMac's programs and it shows that the bytes are being received corrupted for some reason I
can't figure.
Post Edited (Ugha) : 2/12/2009 3:23:38 AM GMT
With attached programs I get:
4,5,6,7 %11111100
all else %11110000
Shawn
P.S. How do you get a screen capture? Arrgh!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe
When all else fails.....procrastinate!
+5v ^ | 4.7k | +--\/\/\---+ | sx >----+----< stamp▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Post Edited (Zoot) : 2/12/2009 6:19:57 AM GMT
Is serial active-low? I thought it was active-high?
Would the SX's internal pullup work?
Also, to take a screenshot press the Print Screen (sometimes Prn Scr) button on your keyboard. To take a picture of JUST your active window (the window
your working in right now) press alt+print screen.
Then paste it into an art program like Microsoft Paint.
Post Edited (Ugha) : 2/12/2009 12:26:16 PM GMT
Yeah, I was going to try that last night. I even suggested Ugha try, but I couldn't see anything in any posts about it. I should have been more thourough. I'll give it a shot after work tonight. Ugha, if you can try it sooner, let me know your results!
After you press Alt+PrintScreen, do you see anything or does it just copy to the clipboard?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe
When all else fails.....procrastinate!
You can paste it into Word or Paint or even Excel (I think). To paste it, call up the target program (say, Word), click Edit/Paste, or simply do a Ctrl-V.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
The serial protocol used by JonnyMac and others is generally open true (not the same as "active-low" or "active-high"). This means when the device wants to send a 0, it drives the wire LOW. When it wants to send a 1 it sets the pin to INPUT, letting the pullup generate the high. Sometimes Jon cheats and has the SX drive the line high, and uses a series resistor to take care of possible shorts, but if OPEN TRUE (OT) is used on the Stamp or SX side with SERIN/SEROUT, you will get the line set to input for "1s".
The internal pullups on the SX are not strong enough for this purpose, unless your platform is remarkably free of noise and interference.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
On the odd event that I just got lucky after four hours of work last Saturday I removed a project from my PDB, reconnected the SX to the BS2, and then re-ran the programs. Thank you, Mickey! -- they work yet again. I've even taken a picture of my setup and used different colored wires so that you can see exactly how I did it. For those that want to pay travel and per diem, I'm happy to bring my setup to your home to prove it to you!
For review (warning: science stuff):
* True mode means the line idle state is high. A start bit will go low and the data bits, which arrive LSB first, will have their normal polarity (i.e., a "1" is high, a "0" is low); the stop bit is at the line idle state (high for True mode). See attached image.
* True mode communications drives the TX and CTS outputs all the time -- this means that no pull-ups are required for this program to work properly. It also means that we need to initialize these pins as outputs and high (both sides do this).
* True mode is not a "cheat" -- it's used when the TX line of one device connects to the RX of another and comms flows in one direction only (on that connection). Why use Open True mode, then? We only need this mode when using half-duplex communications on the same wire, that is, the TX line can become an RX line and vice-versa (like with the PSC); by using Open baud modes we can prevent an electrical conflict if both sides try to transmit at the same time.
As a reminder... frustration rarely brings solutions. I walked away from my desk more than once on Saturday to clear my head when I got frustrated. After the first program worked, everything after flowed very easily. It will for you, too -- if you just hang in and not give up.
Because you're using a BS2sx and didn't change the serial baud constant in the PBASIC program which is setup for a stock BS2. Maybe this is Ugha-bugga's problem as well: a BS2sx is NOT a BS2; they work at different speeds and require different constants for some functions (e.g., SEROUT and SERIN). Now, if Ugha said he was using a BS2sx then I apologize. Shawn changed the $STAMP constant but not the baud constant for the BS2sx. Lesson for us all (the little things we overlook will kick our butts).
I modified the program so that it will conditionally compile for any BS2-series Stamp with the correct baud constant for the selected Stamp and the desired baud rate. I retested and guess what? It still works (thank you, Mickey)!
Man, I hope that this settles this thread....
[noparse][[/noparse]Edit] Interesting final note: The PBASIC help file says that 19.2K is the fastest baud for use with flow control, and yet this program works great at 38.4K. The spec is either very conservative (likely) or meant for Stamp-to-Stamp comms.
Post Edited (JonnyMac) : 2/12/2009 6:26:05 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
The very long low period in the signal is due to the BS2 using DEBUG to report in and out bytes to the PC.
I'm in agreement with Zoot, here. In fact, in my "packet" demo that was part of Saturday's work the BS2 end has SERIN setup like this:
The point that Zoot is making is that with just one SERIN we're receiving multiple bytes at the desired rate -- using individual SERINs for each byte would kill throughput.
I like the full Program approach, instead of the code fragment approach. Since I'm not just learning the SXB code, But also the compiler/Editor as well. I think this was the reason the BS2 was so successful. It had well documented programs and I tried most of them and got a feel for the $BS2 and the Editor before I ever went on line and did something really complex and need help.
Just a Suggestion.
Bill Chennault: Can You Imagine what the SX28 would have done for A ignition module to replace the points? I still struggle to see how a dual point Distributor could make and break @ 10,000RPM's even tough it's at half the crank speed, It still has to fire 8 cylinders???!!!!Chrysler Had there ($h^%) Stuff together.
________________$WMc%__________
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Truth is out there············································ BoogerWoods, FL. USA
Yes, you are absolutely correct. An SX would have improved things immensely. In the meantime, I guess they had strong springs to keep those points from bouncing.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.