Yay, I got the transmitter working, too! While probably not as elegant or efficient as your setup, Peter, it seems to be working and I feel like I can do everything else within the context of the scheduler. I would love to have a thread on your programming strategies -- I finally feel like I'm getting to the point where I can start integrating them into my own projects.
[noparse][[/noparse]Edit] Made use of RX_BYTE function in scheduler.
That is so short. Nice. I like the use of __INTOPTION as well.
I have one question for either JonnyMac or pjv --
MOV PC, txState ' else jump to state
'---
MOV txState, #TX_Bits ' update state
When you move and address to a fr to the PC, I presume that's only 8 bits, so the addresses and the MOV PC must be in the lower half of a code page? Is that right? Of can you have the MOV PC and addresses in the upper half of a code page because the MOV PC won't set bit 8 of the PC anyway?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ When the going gets weird, the weird turn pro. -- HST
Speaking of "working", here is a video of my implementation on the five processor Ugly Buster. This particular code--as everything I did with the machine--was very simple because I wanted to learn some fundamentals. All this code does is use the quadrature encoders (EDIT: But only a SINGLE channel.)·to cause the robot to move straight forward and straight back to its starting place. The movement is ALMOST precise. (I have many of these videos, including ones taken outdoors on the grass, rocks, concrete, and snow should anyone want to see them. Most of these videos include Ugly Buster actually manuevering, like in turns and pivots! [noparse][[/noparse]Even in the grass and on rocks.])
The uneven noises you hear are the gear motors responding to commands to speed up and to resume normal speed as the master accumulates encoder events. In this case, the window was 10 events. In other words, when one track was ten encoder events ahead of the other, the master would command the slower track, via its OEM-BS2 slave in conjunction with its respective HB-25, to speed up. When the master calculated (with feedback from the dedicated encoder OEM-BS2s) that the encoders were equal or within 10 encoder events, it would then instruct the appropriate OEM-BS2 to slow down to "normal" speed".
Remember that Ugly Buster weighs about 25 pounds and that there is no use of SERIN/SEROUT to communicate between the slave processors (OEM-BS2s) and the master processor (BS2p40). In this video, the HB-25s are set to about the mid-point in both direction. It proved fast enough both inside and outside, whether it was carpet, my flagstone patio, grass, or snow. (I screwed up in the snow. It was wet and balled up. As soon as it passed through Ugly Buster's timing belt pulley and timing belt track, it compacted into a hard ball. Since I designed the track mechanism with no thought of a variable tension mechanism, a track was promptly thrown! (There are videos of all of this and more, but I do not want to bore anyone.)
Here is the code which runs on two OEM-BS2s that monitors the gear motor encoders on their sides of the machine . . .
Master_Send··· PIN········ 0············· ' This is the pin the Slave uses to re- ········································· ' port encoder events to the Master.
Shut_Down····· PIN········ 1············· ' If 1, shutdown the Slave.
Encoder_Event· PIN······· 15············· ' The Slave detects encoder events on this
'
[noparse][[/noparse] Variables ]
oldEncoder·· VAR······ Bit··············· ' Bit variable to save Encoder status for ········································· ' later comparison.
'
[noparse][[/noparse] Program Code ]
Main: · DO ··· INPUT Encoder_Event:INPUT Shut_Down·· ' Get encoder event and see if Master wants ········································· ' to shutdown. ··· IF Encoder_Event = 1 THEN ····· HIGH Master_Send ····· ELSE ······· LOW Master_Send ··· ENDIF · LOOP 'UNTIL Shut_Down = 1
END
And here is the code that decrypts my five bit instruction set that controls the HB-25s that control the gear motors. I quickly figured out that I did not need all the capability that five bits gave me, but it worked and I was too lazy to change it. (The master sent this code·two speeds (normal and "catchup"], which worked for me both indoors and outdoors.) It is important to note, that this code was controlled by the master processor, which in turn received information from the two BS2-OEMs concerning wheel counts. (Not speed, or direction, merely encoder counts.)
HB25················ PIN· 15 '
[noparse][[/noparse] Constants ]
command_array······· VAR· Byte(1)········ '·Set up a one byte array of eight bits. ··································································· ' The "command set" for the HB-25 will use ··································································· ' five of the eight bits. The high-order ···································································· ' bit will indicate forward (1) or ······································································· ' reverse (0). The low order bits will ···································································· ' indicate one of 16 speeds specified in ······································································ ' the table above. Command············· VAR· command_array ' The master's current command
oldCommand·········· VAR· Byte···················' A byte to let us know when the master's ······································································· ' command changes '
[noparse][[/noparse] Initialization ]
' Wait for left HB-25 to power up . . .
DO : LOOP UNTIL HB25 = 1
LOW HB25···················································· ' Make I/O Pins Output/Low
PAUSE 20······················································· ' Wait For HB-25s To Initialize
PULSOUT HB25, 750···································· ' Stop the motor '
[noparse][[/noparse] Main Program ]
DO · ' The following five statements receive and re-construct the master's command in the · ' command array . . . · command_array.BIT0 = IN4 · command_array.BIT1 = IN3 · command_array.BIT2 = IN2 · command_array.BIT3 = IN1 · command_array.BIT4 = IN0 · SELECT· Command ··· CASE %10011············································' Forward, slow ····· PULSOUT HB25, 795 ····· PAUSE 20 ··· CASE %11000············································ ' Forward, cruise ····· PULSOUT HB25, 870 ····· PAUSE 20 ··· CASE %11100············································ ' Forward, catchup ····· PULSOUT HB25, 930 ····· PAUSE 20 ··· CASE %00011············································ ' Reverse, slow ····· PULSOUT HB25, 705 ····· PAUSE 5 ··· CASE %01000············································' Reverse, cruise ····· PULSOUT HB25, 630 ····· PAUSE 5 ··· CASE %01100············································' Reverse, catchup ····· PULSOUT HB25, 570 ····· PAUSE 5 ··· CASE %10001··········································· ' Hard brake ····· PULSOUT HB25, 535 ····· PAUSE 5 ··· CASE %00000 ····· PULSOUT HB25, 750································ ' Stop ····· PAUSE 5 · ENDSELECT
LOOP
I have not included the code for the master, since all the master did was act as the "personality" of the robot. In all cases, that personality was derived from the extremely simple things I wanted to accomplish as modified by the encoder counts, which determined position . . . very well on carpet! As soon as the machine was operated on another surface, slippage occured. With nothing but encoders as sensors, Ugly Buster never knew anything was wrong.
I do not know if implementing quadrature encoder code would have helped or not. However, I seriously doubt it. But, I am going to experiment with it, nonetheless. (Not on Ugly Buster; he is at end of life. I am in the process of building an SX operated machine, which I think will be a single processor device, that has Bluetooth onboard and is controlled via a GUI on my laptop using VB6.0. It is up and running now, although it does nothing more than blink LEDs on Ugly Buster. Blinking an LED is no different than sending a signal to an HB-25, though.
This code can doubtless stand a lot of criticism and I will appreciate every bit of it. But, remember that it was written for a multiprocessing environment. I had access to much of the code that would have made execution faster, but there was no need for it. Therefore, I sacrificed execution speed for clarity, which should always be done when appropriate.
I look forward to your feed back. I may defend this approach, but I have no ego. I am here to learn.
--Bill
ps When I started with Parallax products about a year ago, I knew nothing·about microcontrollers, although I had built robots as long as 30 years ago using Z80s. I learned everything I know from the kind folks on this forum and the the folks that work for Parallax.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Post Edited (Bill Chennault) : 2/6/2009 2:25:59 AM GMT
JM - that code is an excellent learning tool - thnx
Couple of newbie questions to ensure I understood -
a) The 1.5 bits after the initial start detection - is that to place your sample into the 'middle' of the pulse so that a minor mis-timing doesn't catch an edge?
b) The timing of the RxReady test is set up so that even if the ready happens immediately after the previous test there will still be another test before a full byte comes in - correct ?
c) Your interupt seems to be going at least 3 times faster than you ever really use (you're always clocking it down in your code) - so why have it so fast?
In general, I believe it is not good practice to put much of anything in the ISR. I realize that generalization cannot be fully adhered to; there are some things, for example ADC/ DAC code that absolutely must be executed exactly at the same time every time if accuracy is important, and hence they MUST reside in the ISR, and at a consistently timed spot to boot, so they are the excepton to that rule..... but that's about it. Everything else should be outside the ISR, and because the ISR is executed every tick, it should be as short as possible. That leaves the most time for the rest of the multi-tasking apps.
But this is a general practice rule I follow and if your apps are not very demanding, then that rule can be bent quite a ways.
In the final analysis, the proof is in the pudding, and if bending it works, well, then it works!
David Bayliss said...
JM - that code is an excellent learning tool - thnx
Couple of newbie questions to ensure I understood -
a) The 1.5 bits after the initial start detection - is that to place your sample into the 'middle' of the pulse so that a minor mis-timing doesn't catch an edge?
b) The timing of the RxReady test is set up so that even if the ready happens immediately after the previous test there will still be another test before a full byte comes in - correct ?
c) Your interupt seems to be going at least 3 times faster than you ever really use (you're always clocking it down in your code) - so why have it so fast?
David
A) Yes; after start bit detection (RX goes low using True mode) one waits 1.5 bit periods to land int the "middle" of the first bit; after that the timing is set to 1 bit
Yes; at 38.4k baud a byte will take 260 microseconds; by checking at twice this rate I should never miss anything. And Peter's code gives us a buffer so we can actually be receiving a second byte before retrieving the first.
C) I chose that speed to get very close to a baud-friendly rate (I use 4x [noparse][[/noparse]or multiple thereof] oversampling) and so that I could generate a tick timing of 10us that will be used for other processes (specifically, servos -- I've yet to add them in).
You should use an odd number for oversampling on catching the START bit (I like 5 but 3 should work) that way you can properly position the sample for following bits in their middle 20% or middle 33%.. And once START is detected somewhere in the beginning 20% or 33%, then set the sample for only the next bit to 140% or 133%, and the subsequent samples at 100%.
With today's modern communications we no longer see much skew in the mark/space ratio coming from transmitting devices or communications media, but longish capacitive lines can still mess you up. So that is my recommendation to make your system more forgiving in dealing with skew.
Ok.. this conversation has gone way... WAY over my head.
I hope you guys don't mind if I inject a little newbieness to this with a question.
I was simply trying to transfer a couple bytes between a BS2 and a SX (to prepare to learn more advanced stuff later) and I've
come accross a major problem.
The data I'm sending out is getting corrupted somehow and I'd like some expert info on what I'm doing wrong.
I'm simply sending ABC from my BS2 to the SX and then from the SX back to the BS2.
It comes out scrambled for some reason.
I've attached the code both for the BS2 and the SX. My setup is simple, I've got a single wire (pulled down with a 1k resistor)
connected from pin 14 of the BS2 to pin RB2 of the SX. I'm translating the bytes into binary on the BS2 so I can better see
whats going on.
Here's my results:
Sent Data... A: 01000001 B: 01000010 C: 01000011
Received Data... 1: 01010000 2: 10101000 3: 11101000
The results are consistant and unchanging. I can't figure out, for the life of me, what's wrong.
You need some mechanism to allow the SEROUT on the BS2 side when the SX side is sitting on a SERIN statement; this means an extra IO pin for hardware flow control. You could define another output pin on the SX to gate the BS2 SEROUT statements. I would create a function like this:
Get_Packet:
FOR idx = 0 TO 2
buffer(idx) = RX_BYTE
NEXT
The call to RX_BYTE will signal the BS2 that it's oaky to send a byte. Personally, I wouldn't do it this way -- I'd go with buffered serial so that you can send a message packet and retrieve it at any time.
I sort of get it.
My timing was off... I understand that part. I just don't get how.
I thought that by delaying transmission things would sync up properly since serin causes the entire microprocessor (either one) to stop and wait for data.
I thought it'd work like this:
1> Start both processors at the same time.
2> Stamp would execute a 5 second delay to give the SX time to enter the SERIN loop
3> Stamp sends the data at the same rate that the SX is receiving
4> SX pauses 1 second to allow Stamp to finish DEBUG and enter SERIN
5> SX transmits data to the waiting Stamp
On which section is the timing getting messed up?
I'll try your suggestion of course, I just want to understand the problem more.
Also... Is it just me or is the SX/B serout/serin a lot more limited than the stamp's?
PS: I'm planning on doing a form of buffering like you've shown me in your examples, at the moment I'm just trying to get the two to talk at all.
None of your methods are robust in my opinion. If one device resets an you lose sync with the other everything goes to heck. Use hardware flow control or buffering on the SX end. Now... even with buffering on the SX end you still might need HFC because the Stamp has to be sitting on a SERIN statement to receive data.
Yes, SERIN and SEROUT in SX/B only work with bytes but you can synthesize routines to do what the Stamp compiler does for you. SX/B is not supposed to be PBASIC compatible, just similar to it.
After pretty much an entire day of frustration... I think I've finally got flow control and communication between a BS2 and SX down.
I do have some questions though.
1: In order for any serial to come over "clean" I always have to send a byte of trash.... doesn't matter what it is as long as I don't care if it arrives corrupted. I don't
understand why this is needed. Is this to sync the serial or establish baud rate or something? (this is what took me all day to discover)
2: At the end of the SX program cntrl is always set to 0. I checked this with WATCH and it stays 0 most of the program (except during the actual serial communication)
Why is this?
3: In the SX program, between sending the trash data and entering the actual transmit loop, I have to have a pause there (duration doesn't matter) otherwise the first
byte is garbled. Is this to give the stamp time to reset the pin high and enter its own loop or some other reason?
4: On the BS2 side, the first SERIN (receiving the trash data) internal flow control with the rdy pin doesn't seem to work. The program won't function unless I set the
pin to 0 and then back to 1 manually as I have it. Why is this?
5: I have to constantly set the pins to high to make everything work. Would a pullup resistor function better for this form of flow control? (I couldn't find enough 10k resistors
to test this myself)
6: Does a serial line need to be pulled down/up? (I'm currently pulling it down)
JonnyMac:
You mentioned buffered serial... I'm assuming its nothing like I have here so can you explain it a bit more?·Don't bother taking the time to give more code examples, I'm
sure you've got better things to do than to code for a newbie [noparse]:)[/noparse] Just a broken-down explanation would be wonderful.
Have a look at the attached programs -- they work very well together (I have them running on my PDB now). Use the Pause button on the PBASIC Debug window to verify that the uppercase letter going out is being sent back as lowercase.
Since the SX at 20MHz is about 1600x faster than the BS2 I'm confident this demo proves that hardware flow control is working else the SX would start transmitting back before the BS2 was ready.
Let me suggest you study the SERIN and SEROUT sections of the PBASIC help file; there is a lot of information there that will help you.
It's important to work through problems a step at a time. Once you get the programs above working, have a look at these -- I think this gets you closer to your ultimate goal. The SX side uses buffered serial so the SX can be doing something else while serial data arrives. Hardware flow-control is still used to maintain comms between the Stamp and SX.
The SX demo waits from three bytes, adds them, then sends the result (low byte only) back to the Stamp comparison. I've even attached a screen shot from my PC so you can see what it looks like when running.
One more demo -- sends packets to and fro. It's important that both sides know (or can communicate) the size of packet otherwise it will be easy to get out of sync. If your packet values can be less than 128 then you could use BIT7 as a sentinel to re-sync a packet (MIDI does this).
First, I'm working on understanding your code still, I'll most likely be hitting you with questions soon.
I was wondering one thing though...
As far as studying the helpfiles for SERIN and SEROUT, I've read them several times and I don't see exactly what your pointing out that I should learn.
Can you give a dense newbie a bit more of a push in the right direction?
Another problem...
The BS2_TO_SX.BS2 and SX_TO_BS2.SXB programs don't seem to work for me.
I connected the pins according to the programs, linked the two grounds together and didn't alter anything except the SX's clock...
Here's a sample of my result:
Out: N In: <?>
Out: O In: <?>
Out: P In: 8
Out: Q In: 8
Out: R In: <
Out: S In: <
Out: T In: <
Out: U In: <
Out: V In: <
Out: W In: 8
Out: X In: <
Out: Y In: 8
Out: Z In: <
Out: A In: <?>
Out: B In: <?>
Out: C In: <?>
Out: D In: <?>
I did alter the clock of the SX, if that makes a difference. I don't have a 20mhz resonator (Just the 4mhz and 50mhz that come with the tech toolkit) so I set it to 50mhz with no improved response, then set it to 4mhz with the same result.
I understand I can simulate a 20mhz clock with the SX-key but that would make it impossible for me to read the debug screen on the BS2 side (I've only got one com port).
I have a request for your book... can you please go into detail about resonators and crystals and the like? There's next to no information out there explaining such things to a total newbie of microprocessors. I'm still extremely vague on many issues related to them after studying every single source parallax provides. It seems that most of the material just simply assumes you know how they work, or that your going to use the internal RC clock.
I'm sorry for being such a trouble with all this. I really am attempting to learn all this on my own without bugging you... I use this forum as an absolute last resort and as a result spend a lot of time re-reading things I've already read, and experimenting for hours with nothing to show for it.
I'm not trying to be an annoying newbie... I'm just born that way I guess.
Okay... if you can't get working programs working there may be nothing I can say/write that will help. That said, I'll try... one last time.
* Don't assume you've connected anything correctly -- very dangerous; I had to reconnect things two or three times yesterday before I got the first programs working; once the connections were correct everything after that was a breeze. I even walked away a couple times when frustrated. I've been doing this a long time and it took some effort; you keep reminding us that you're a newbie so I'm going to drop the connections thing on you ( bet you'll stop calling yourself a newbie now.... )
* Next to the PDB my favorite development tool is a white board and lots of color markers; I did this drawing yesterday to get my head around what I wanted to do:
This should get your connections straight and help you with the code (it did for me).
* If you're switching the SX to 50MHz then change OSCXT2 to OSCHS2. I just re-ran the programs using a 50MHz resonator on the SX (instead of the Key) and it still works. See page 50 of the SX-Key manual for OSC recommendations. I tend to use OSCXT2 for 4MHz, 8MHz and 20MHz, and OSCHS2 for 50MHz -- that's based on using the resonators I have (same as what Parallax sells). See section 9.0 of the SX28 docs for gory details on oscillator circuits (what I'm really saying is that using SX/B does not relieve you of any responsibility to learn the SX and connecting things to it).
* When using True mode serial the idle state of the TX line is output-high (1); this needs to be done at start-up (both programs do).
* Using hardware flow-control (HFC) with True mode the CTS pin will be high (1) to stop incoming serial, and go low (0) to allow it. The CTS pin should be initialized output-high to prevent the other side from trying to transmit until this side is ready. The CTS of the receiving device connects to the RTS of the transmitting device (see above). The transmitting device will watch for its RTS input to go low before transmitting.
* Okay, blow-by-blow: The BS2 wants to transmit a byte to the SX via its TX_BYTE subroutine. Using HFC it checks its own RTS input to see if the SX is ready to receive; when RTS is low (0) the byte will be transmitted. On the SX side the RX_BYTE function signals that it's ready by taking its CTS output low then dropping into SERIN. Once the byte as been received by the SX the CTS line is taken back high; this stops the BS2 from sending anything else. Going the other direction... when the BS2 is ready to receive a byte it goes to its RX_BYTE subroutine where, again using HFC, it will take its CTS pin low to signal the SX that it's ready. When the SX's TX_BYTE subroutine sees its RTS input go low it will transmit a byte to the waiting BS2. Everybody is happy -- I've given you three sets of programs that prove it!
* Finally.... I used to work for a guy named Bob who said every person needs to see/hear/read something three to seven times before it sinks in -- you may need to re-read some material as we all have different rates at which the "Aha!" light illuminates. Don't assume that reading things once or twice will be enough; you're human, allow yourself to be. And keep experimenting... that's a much better way to learn than counting on windbags like me!
Ok... I think your getting pretty frustrated with me so I'll just make this as brief as possible...
I have been understanding how HFC works since about 5 minutes after you originally mentioned it. In fact, I had used something of a crude, inverted, form·in my
original program I posted without even realizing it. My questions weren't related to how it works, more to the exact problems I was having with my applications of it.
I know I did something wrong... I was asking what.
I did verify several times that I had the connections correct... I will go into deftail now (and verify again as I do so):
BS2 Pin 15 (RTS)
> SX pin RA.1 (CTS)
BS2 Pin 14 (TX)
> SX pin RA.0 (RX)
BS2 Pin 13 (CTS)
> SX pin RA.3 (RTS)
BS2 Pin 12 (RX)
> SX pin RA.2 (TX)
LED -> 220ohm Resistor -> RC.7 (LED)
BS2 Vss
> SX Vss
SX is powered by regulated 5.9volt wall-wart to barrel jack on SX Tech board
BS2 powered by 9volt battery
When I attempted to use the 50mhz resonator, I did have it changed to OSCHS2. I also changed the FREQ command accordingly.
When I said I didn't understand resonators, I meant more practical aspects... Are they polarized? How do you read the markings on them? Does static damage them?
Do magnetic fields damage them? Which is better, a crystal or a resonator? Can I underclock them to run at a slower speed(Use a lower FREQ?)? What speeds are best
for what applications? What is too fast for X? What is too slow for X? ect... I've answered some of those, but I just wanted to give an example of the information I
still wanted after reading and re-reading the sources you listed and many more.
I have directly downloaded your attached programs into my stamp and SX, I did not edit the programs at all except to change the clock of the SX, and I still get this
result:
Out: J In: 8
Out: K In: 8
Out: L In: 8
Out: M In: 8
Out: N In: 8
Out: O In: 8
Out: P In: <?>
Out: Q In: <?>
Out: R In: <?>
Out: S In: <?>
Out: T In: <?>
Out: U In: <?>
Out: V In: <?>
Out: W In: <?>
Out: X In: 8
Out: Y In: 8
I've attached both programs exactly as I ran them.
If its not in my wiring or your program, then it must be something else. I wish I knew what.
I'm sorry your frustrated with me. I will attempt to figure out things on my own from this point. Thank you for your help... I've learned a lot from you.
I can't tell you how valuable the exchange between you and Ugha has been for me and doubtless many, many other new folks that are either to embarrassed to ask the questions that Ugha asks or, if they are truly like me, do not know those questions even exist!
It is difficult to communicate across several levels of experience. I could see both of you straining. I hope neither of you give up because ALL of us are learning an incredible amount. The subject line of this thread is truly appropriate: Learning SX/B.
I noticed that even some of your contemporaries had exchanges in which you and they learned a bit. I think. It was a "bit" over my head, but I didn't mind that as I know the waters can get very deep in this technology. Simple folks like Ugha and me are desperately trying to get out of the shallow end of the pool. Without people like you, only our knees will ever get wet. (Well, Ugha has gone a little deeper than me, but he may be the first to admit there is a long way to go before he can scuba dive!)
I try to participate in these exchanges because I always learn something -- now I know, with certainty, how to use HFC between the SX and a BASIC Stamp and have several demos that prove it. I wish, though, I was smart enough to know what to say to get programs that work for me to work for others. I'm not. I think, though, a big part of that is experience, and that's just a matter of time spent struggling through frustrating circuits/code -- Heaven knows I struggle every day....
I was just gonna wait on the SX/B Manuel to come in print.
Bill Chennault:
I'm sorry that I'm this late in the thread. I didn't realize that their was any Mopar fans out there.I would almost kill to " street " a 70'HemiCuda, especially a Sox&Martin HemiCuda!!!!!
Not to many people would recognize a late 60's Hemi. They didn't call it the elephant motor for nothing!
I look at JonnyMac and Bean as the Sox and Martin of the Microcontroller "SXB" Stamp!!!!
__________$WMc%__________
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Truth is out there············································ BoogerWoods, FL. USA
It was a lot of fun while it lasted. BUT, if I had taken that original hemi 'Cuda off the showroom floor and put it in storage, do you have ANY idea what it would be worth today? [noparse]:)[/noparse]
Of course, when I was younger, I trashed a lot of '57 Chevy's, too.
I think I have LEARNED. My Crossfire, which is either no longer manufactured or no longer imported from Europe, is going into storage. My son will inherit it.
--Bill
ps Man! That screaming Sox and Martin engine was fun! It had a tunnel ram manifold and dual 850, gear driven Holley double pumpers on it. I had to look off to the side to see around them. The engine was so well balanced that it would wind to 9k, although I always kept it down close to eight. The first and only time I ever used first gear with the BIG hemi in it, I wound it up to 10k before I could pull a shift. No damage. But, I could have sure used a PARALLAX based governor that shut things down at about 9.5k rpm.
The power supply doesn't seem to be the problem.
I ran the regulated 5v VDD straight from my BOE into the VDD of my SX tech board and still have the exact same problems.
I can't explain why one person can run JonnyMac's program (him) and I can't. I'm assuming there's something I'm not seeing wrong with my setup... or perhaps the PDB he's using is
better suited to the task or... something.
I don't know.
Can someone from Parallax·please contact me via PM and walk me through testing my hardware (BS2, BOE, SX, SX tech board) to see if I have
a problem? I know my SX tech tool kit was refurbished so it makes me wonder if there was a problem that wasn't fixed or a repaired problem returning.
Comments
[noparse][[/noparse]Edit] Made use of RX_BYTE function in scheduler.
Post Edited (JonnyMac) : 2/6/2009 12:20:56 AM GMT
I have one question for either JonnyMac or pjv --
MOV PC, txState ' else jump to state '--- MOV txState, #TX_Bits ' update stateWhen you move and address to a fr to the PC, I presume that's only 8 bits, so the addresses and the MOV PC must be in the lower half of a code page? Is that right? Of can you have the MOV PC and addresses in the upper half of a code page because the MOV PC won't set bit 8 of the PC anyway?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
the mov pc,w instruction itself may be anywhere in the page.
Here is a tip if you ever want to move the code beyond page 0.
use MOV txState,·#TX_Bits·&·255
to suppress warnings "literal truncated"
It makes no difference in codesize.
regards peter
Speaking of "working", here is a video of my implementation on the five processor Ugly Buster. This particular code--as everything I did with the machine--was very simple because I wanted to learn some fundamentals. All this code does is use the quadrature encoders (EDIT: But only a SINGLE channel.)·to cause the robot to move straight forward and straight back to its starting place. The movement is ALMOST precise. (I have many of these videos, including ones taken outdoors on the grass, rocks, concrete, and snow should anyone want to see them. Most of these videos include Ugly Buster actually manuevering, like in turns and pivots! [noparse][[/noparse]Even in the grass and on rocks.])
http://www.billcnkc.com/Robotics/Ugly%20Buster/07-11-08-a.mpg
The uneven noises you hear are the gear motors responding to commands to speed up and to resume normal speed as the master accumulates encoder events. In this case, the window was 10 events. In other words, when one track was ten encoder events ahead of the other, the master would command the slower track, via its OEM-BS2 slave in conjunction with its respective HB-25, to speed up. When the master calculated (with feedback from the dedicated encoder OEM-BS2s) that the encoders were equal or within 10 encoder events, it would then instruct the appropriate OEM-BS2 to slow down to "normal" speed".
Remember that Ugly Buster weighs about 25 pounds and that there is no use of SERIN/SEROUT to communicate between the slave processors (OEM-BS2s) and the master processor (BS2p40). In this video, the HB-25s are set to about the mid-point in both direction. It proved fast enough both inside and outside, whether it was carpet, my flagstone patio, grass, or snow. (I screwed up in the snow. It was wet and balled up. As soon as it passed through Ugly Buster's timing belt pulley and timing belt track, it compacted into a hard ball. Since I designed the track mechanism with no thought of a variable tension mechanism, a track was promptly thrown! (There are videos of all of this and more, but I do not want to bore anyone.)
Here is the code which runs on two OEM-BS2s that monitors the gear motor encoders on their sides of the machine . . .
Master_Send··· PIN········ 0············· ' This is the pin the Slave uses to re-
········································· ' port encoder events to the Master.
Shut_Down····· PIN········ 1············· ' If 1, shutdown the Slave.
Encoder_Event· PIN······· 15············· ' The Slave detects encoder events on this
'
[noparse][[/noparse] Variables ]
oldEncoder·· VAR······ Bit··············· ' Bit variable to save Encoder status for
········································· ' later comparison.
'
[noparse][[/noparse] Program Code ]
Main:
· DO
··· INPUT Encoder_Event:INPUT Shut_Down·· ' Get encoder event and see if Master wants
········································· ' to shutdown.
··· IF Encoder_Event = 1 THEN
····· HIGH Master_Send
····· ELSE
······· LOW Master_Send
··· ENDIF
· LOOP 'UNTIL Shut_Down = 1
END
And here is the code that decrypts my five bit instruction set that controls the HB-25s that control the gear motors. I quickly figured out that I did not need all the capability that five bits gave me, but it worked and I was too lazy to change it. (The master sent this code·two speeds (normal and "catchup"], which worked for me both indoors and outdoors.) It is important to note, that this code was controlled by the master processor, which in turn received information from the two BS2-OEMs concerning wheel counts. (Not speed, or direction, merely encoder counts.)
HB25················ PIN· 15
'
[noparse][[/noparse] Constants ]
command_array······· VAR· Byte(1)··· ····· '·Set up a one byte array of eight bits.
············································· ··· ·· ················ · ' The "command set" for the HB-25 will use
···························· ································ · · ····· ' five of the eight bits. The high-order
············································ ················· · ······ ' bit will indicate forward (1) or
······································································· ' reverse (0). The low order bits will
························ ····································· ·· ····· ' indicate one of 16 speeds specified in
········································ ······························ ' the table above.
Command············· VAR· command_array ' The master's current command
oldCommand·········· VAR· Byte·················· ·' A byte to let us know when the master's
·································································· ····· ' command changes
'
[noparse][[/noparse] Initialization ]
' Wait for left HB-25 to power up . . .
DO : LOOP UNTIL HB25 = 1
LOW HB25····················· ······························· ' Make I/O Pins Output/Low
PAUSE 20······················································· ' Wait For HB-25s To Initialize
PULSOUT HB25, 750···································· ' Stop the motor
'
[noparse][[/noparse] Main Program ]
DO
· ' The following five statements receive and re-construct the master's command in the
· ' command array . . .
· command_array.BIT0 = IN4
· command_array.BIT1 = IN3
· command_array.BIT2 = IN2
· command_array.BIT3 = IN1
· command_array.BIT4 = IN0
· SELECT· Command
··· CASE %10011············································' Forward, slow
····· PULSOUT HB25, 795
····· PAUSE 20
··· CASE %11000············································ ' Forward, cruise
····· PULSOUT HB25, 870
····· PAUSE 20
··· CASE %11100············································ ' Forward, catchup
····· PULSOUT HB25, 930
····· PAUSE 20
··· CASE %00011············································ ' Reverse, slow
····· PULSOUT HB25, 705
····· PAUSE 5
··· CASE %01000····························· ···············' Reverse, cruise
····· PULSOUT HB25, 630
····· PAUSE 5
··· CASE %01100········································· ···' Reverse, catchup
····· PULSOUT HB25, 570
····· PAUSE 5
··· CASE %10001···································· ······· ' Hard brake
····· PULSOUT HB25, 535
····· PAUSE 5
··· CASE %00000
····· PULSOUT HB25, 750················· ··············· ' Stop
····· PAUSE 5
· ENDSELECT
LOOP
I have not included the code for the master, since all the master did was act as the "personality" of the robot. In all cases, that personality was derived from the extremely simple things I wanted to accomplish as modified by the encoder counts, which determined position . . . very well on carpet! As soon as the machine was operated on another surface, slippage occured. With nothing but encoders as sensors, Ugly Buster never knew anything was wrong.
I do not know if implementing quadrature encoder code would have helped or not. However, I seriously doubt it. But, I am going to experiment with it, nonetheless. (Not on Ugly Buster; he is at end of life. I am in the process of building an SX operated machine, which I think will be a single processor device, that has Bluetooth onboard and is controlled via a GUI on my laptop using VB6.0. It is up and running now, although it does nothing more than blink LEDs on Ugly Buster. Blinking an LED is no different than sending a signal to an HB-25, though.
This code can doubtless stand a lot of criticism and I will appreciate every bit of it. But, remember that it was written for a multiprocessing environment. I had access to much of the code that would have made execution faster, but there was no need for it. Therefore, I sacrificed execution speed for clarity, which should always be done when appropriate.
I look forward to your feed back. I may defend this approach, but I have no ego. I am here to learn.
--Bill
ps When I started with Parallax products about a year ago, I knew nothing·about microcontrollers, although I had built robots as long as 30 years ago using Z80s. I learned everything I know from the kind folks on this forum and the the folks that work for Parallax.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Post Edited (Bill Chennault) : 2/6/2009 2:25:59 AM GMT
Couple of newbie questions to ensure I understood -
a) The 1.5 bits after the initial start detection - is that to place your sample into the 'middle' of the pulse so that a minor mis-timing doesn't catch an edge?
b) The timing of the RxReady test is set up so that even if the ready happens immediately after the previous test there will still be another test before a full byte comes in - correct ?
c) Your interupt seems to be going at least 3 times faster than you ever really use (you're always clocking it down in your code) - so why have it so fast?
David
I feel dumb asking this but I need to learn somehow. [noparse]:)[/noparse]
You said:
use MOV txState, #TX_Bits & 255
to suppress warnings "literal truncated"
What making that line suppress the warning? Is it because "& 255"?
Mark
which won't fit a byte, hence the warning.
The & 255 strips the higher bits.
regards peter
·
In general, I believe it is not good practice to put much of anything in the ISR. I realize that generalization cannot be fully adhered to; there are some things, for example ADC/ DAC code that absolutely must be executed exactly at the same time every time if accuracy is important, and hence they MUST reside in the ISR, and at a consistently timed spot to boot, so they are the excepton to that rule..... but that's about it. Everything else should be outside the ISR, and because the ISR is executed every tick, it should be as short as possible. That leaves the most time for the rest of the multi-tasking apps.
But this is a general practice rule I follow and if your apps are not very demanding, then that rule can be bent quite a ways.
In the final analysis, the proof is in the pudding, and if bending it works, well, then it works!
Cheers,
Peter (pjv)
A) Yes; after start bit detection (RX goes low using True mode) one waits 1.5 bit periods to land int the "middle" of the first bit; after that the timing is set to 1 bit
C) I chose that speed to get very close to a baud-friendly rate (I use 4x [noparse][[/noparse]or multiple thereof] oversampling) and so that I could generate a tick timing of 10us that will be used for other processes (specifically, servos -- I've yet to add them in).
You should use an odd number for oversampling on catching the START bit (I like 5 but 3 should work) that way you can properly position the sample for following bits in their middle 20% or middle 33%.. And once START is detected somewhere in the beginning 20% or 33%, then set the sample for only the next bit to 140% or 133%, and the subsequent samples at 100%.
With today's modern communications we no longer see much skew in the mark/space ratio coming from transmitting devices or communications media, but longish capacitive lines can still mess you up. So that is my recommendation to make your system more forgiving in dealing with skew.
Cheers,
Peter (pjv)
I hope you guys don't mind if I inject a little newbieness to this with a question.
I was simply trying to transfer a couple bytes between a BS2 and a SX (to prepare to learn more advanced stuff later) and I've
come accross a major problem.
The data I'm sending out is getting corrupted somehow and I'd like some expert info on what I'm doing wrong.
I'm simply sending ABC from my BS2 to the SX and then from the SX back to the BS2.
It comes out scrambled for some reason.
I've attached the code both for the BS2 and the SX. My setup is simple, I've got a single wire (pulled down with a 1k resistor)
connected from pin 14 of the BS2 to pin RB2 of the SX. I'm translating the bytes into binary on the BS2 so I can better see
whats going on.
Here's my results:
The results are consistant and unchanging. I can't figure out, for the life of me, what's wrong.
Any assistance would be much appreciated.
The you would use it in place of SERIN like this:
Get_Packet: FOR idx = 0 TO 2 buffer(idx) = RX_BYTE NEXTThe call to RX_BYTE will signal the BS2 that it's oaky to send a byte. Personally, I wouldn't do it this way -- I'd go with buffered serial so that you can send a message packet and retrieve it at any time.
My timing was off... I understand that part. I just don't get how.
I thought that by delaying transmission things would sync up properly since serin causes the entire microprocessor (either one) to stop and wait for data.
I thought it'd work like this:
1> Start both processors at the same time.
2> Stamp would execute a 5 second delay to give the SX time to enter the SERIN loop
3> Stamp sends the data at the same rate that the SX is receiving
4> SX pauses 1 second to allow Stamp to finish DEBUG and enter SERIN
5> SX transmits data to the waiting Stamp
On which section is the timing getting messed up?
I'll try your suggestion of course, I just want to understand the problem more.
Also... Is it just me or is the SX/B serout/serin a lot more limited than the stamp's?
PS: I'm planning on doing a form of buffering like you've shown me in your examples, at the moment I'm just trying to get the two to talk at all.
Yes, SERIN and SEROUT in SX/B only work with bytes but you can synthesize routines to do what the Stamp compiler does for you. SX/B is not supposed to be PBASIC compatible, just similar to it.
I do have some questions though.
1: In order for any serial to come over "clean" I always have to send a byte of trash.... doesn't matter what it is as long as I don't care if it arrives corrupted. I don't
understand why this is needed. Is this to sync the serial or establish baud rate or something? (this is what took me all day to discover)
2: At the end of the SX program cntrl is always set to 0. I checked this with WATCH and it stays 0 most of the program (except during the actual serial communication)
Why is this?
3: In the SX program, between sending the trash data and entering the actual transmit loop, I have to have a pause there (duration doesn't matter) otherwise the first
byte is garbled. Is this to give the stamp time to reset the pin high and enter its own loop or some other reason?
4: On the BS2 side, the first SERIN (receiving the trash data) internal flow control with the rdy pin doesn't seem to work. The program won't function unless I set the
pin to 0 and then back to 1 manually as I have it. Why is this?
5: I have to constantly set the pins to high to make everything work. Would a pullup resistor function better for this form of flow control? (I couldn't find enough 10k resistors
to test this myself)
6: Does a serial line need to be pulled down/up? (I'm currently pulling it down)
JonnyMac:
You mentioned buffered serial... I'm assuming its nothing like I have here so can you explain it a bit more?·Don't bother taking the time to give more code examples, I'm
sure you've got better things to do than to code for a newbie [noparse]:)[/noparse] Just a broken-down explanation would be wonderful.
Since the SX at 20MHz is about 1600x faster than the BS2 I'm confident this demo proves that hardware flow control is working else the SX would start transmitting back before the BS2 was ready.
Let me suggest you study the SERIN and SEROUT sections of the PBASIC help file; there is a lot of information there that will help you.
The SX demo waits from three bytes, adds them, then sends the result (low byte only) back to the Stamp comparison. I've even attached a screen shot from my PC so you can see what it looks like when running.
Post Edited (JonnyMac) : 2/8/2009 6:53:00 AM GMT
I was wondering one thing though...
As far as studying the helpfiles for SERIN and SEROUT, I've read them several times and I don't see exactly what your pointing out that I should learn.
Can you give a dense newbie a bit more of a push in the right direction?
Post Edited (Ugha) : 2/8/2009 10:16:54 PM GMT
The BS2_TO_SX.BS2 and SX_TO_BS2.SXB programs don't seem to work for me.
I connected the pins according to the programs, linked the two grounds together and didn't alter anything except the SX's clock...
Here's a sample of my result:
I did alter the clock of the SX, if that makes a difference. I don't have a 20mhz resonator (Just the 4mhz and 50mhz that come with the tech toolkit) so I set it to 50mhz with no improved response, then set it to 4mhz with the same result.
I understand I can simulate a 20mhz clock with the SX-key but that would make it impossible for me to read the debug screen on the BS2 side (I've only got one com port).
I have a request for your book... can you please go into detail about resonators and crystals and the like? There's next to no information out there explaining such things to a total newbie of microprocessors. I'm still extremely vague on many issues related to them after studying every single source parallax provides. It seems that most of the material just simply assumes you know how they work, or that your going to use the internal RC clock.
I'm sorry for being such a trouble with all this. I really am attempting to learn all this on my own without bugging you... I use this forum as an absolute last resort and as a result spend a lot of time re-reading things I've already read, and experimenting for hours with nothing to show for it.
I'm not trying to be an annoying newbie... I'm just born that way I guess.
* Don't assume you've connected anything correctly -- very dangerous; I had to reconnect things two or three times yesterday before I got the first programs working; once the connections were correct everything after that was a breeze. I even walked away a couple times when frustrated. I've been doing this a long time and it took some effort; you keep reminding us that you're a newbie so I'm going to drop the connections thing on you ( bet you'll stop calling yourself a newbie now....
* Next to the PDB my favorite development tool is a white board and lots of color markers; I did this drawing yesterday to get my head around what I wanted to do:
SX.TX (o) ---> BS2.RX (i)
SX.RTS (i) <--- BS2.CTS (o)
SX.RX (i) <--- BS2.TX (o)
SX.CTS (o) ---> BS2.RTS (i)
This should get your connections straight and help you with the code (it did for me).
* If you're switching the SX to 50MHz then change OSCXT2 to OSCHS2. I just re-ran the programs using a 50MHz resonator on the SX (instead of the Key) and it still works. See page 50 of the SX-Key manual for OSC recommendations. I tend to use OSCXT2 for 4MHz, 8MHz and 20MHz, and OSCHS2 for 50MHz -- that's based on using the resonators I have (same as what Parallax sells). See section 9.0 of the SX28 docs for gory details on oscillator circuits (what I'm really saying is that using SX/B does not relieve you of any responsibility to learn the SX and connecting things to it).
* When using True mode serial the idle state of the TX line is output-high (1); this needs to be done at start-up (both programs do).
* Using hardware flow-control (HFC) with True mode the CTS pin will be high (1) to stop incoming serial, and go low (0) to allow it. The CTS pin should be initialized output-high to prevent the other side from trying to transmit until this side is ready. The CTS of the receiving device connects to the RTS of the transmitting device (see above). The transmitting device will watch for its RTS input to go low before transmitting.
* Okay, blow-by-blow: The BS2 wants to transmit a byte to the SX via its TX_BYTE subroutine. Using HFC it checks its own RTS input to see if the SX is ready to receive; when RTS is low (0) the byte will be transmitted. On the SX side the RX_BYTE function signals that it's ready by taking its CTS output low then dropping into SERIN. Once the byte as been received by the SX the CTS line is taken back high; this stops the BS2 from sending anything else. Going the other direction... when the BS2 is ready to receive a byte it goes to its RX_BYTE subroutine where, again using HFC, it will take its CTS pin low to signal the SX that it's ready. When the SX's TX_BYTE subroutine sees its RTS input go low it will transmit a byte to the waiting BS2. Everybody is happy -- I've given you three sets of programs that prove it!
* Finally.... I used to work for a guy named Bob who said every person needs to see/hear/read something three to seven times before it sinks in -- you may need to re-read some material as we all have different rates at which the "Aha!" light illuminates. Don't assume that reading things once or twice will be enough; you're human, allow yourself to be. And keep experimenting... that's a much better way to learn than counting on windbags like me!
Post Edited (JonnyMac) : 2/9/2009 1:56:18 AM GMT
I have been understanding how HFC works since about 5 minutes after you originally mentioned it. In fact, I had used something of a crude, inverted, form·in my
original program I posted without even realizing it. My questions weren't related to how it works, more to the exact problems I was having with my applications of it.
I know I did something wrong... I was asking what.
I did verify several times that I had the connections correct... I will go into deftail now (and verify again as I do so):
BS2 Pin 15 (RTS)
> SX pin RA.1 (CTS)
BS2 Pin 14 (TX)
> SX pin RA.0 (RX)
BS2 Pin 13 (CTS)
> SX pin RA.3 (RTS)
BS2 Pin 12 (RX)
> SX pin RA.2 (TX)
LED -> 220ohm Resistor -> RC.7 (LED)
BS2 Vss
> SX Vss
SX is powered by regulated 5.9volt wall-wart to barrel jack on SX Tech board
BS2 powered by 9volt battery
When I attempted to use the 50mhz resonator, I did have it changed to OSCHS2. I also changed the FREQ command accordingly.
When I said I didn't understand resonators, I meant more practical aspects... Are they polarized? How do you read the markings on them? Does static damage them?
Do magnetic fields damage them? Which is better, a crystal or a resonator? Can I underclock them to run at a slower speed(Use a lower FREQ?)? What speeds are best
for what applications? What is too fast for X? What is too slow for X? ect... I've answered some of those, but I just wanted to give an example of the information I
still wanted after reading and re-reading the sources you listed and many more.
I have directly downloaded your attached programs into my stamp and SX, I did not edit the programs at all except to change the clock of the SX, and I still get this
result:
I've attached both programs exactly as I ran them.
If its not in my wiring or your program, then it must be something else. I wish I knew what.
I'm sorry your frustrated with me. I will attempt to figure out things on my own from this point. Thank you for your help... I've learned a lot from you.
Good luck with your experiments.
Try a 4.7k resistor tied to +5V on your TX line coming from the SX.
Resonators aren't polarized (good question, I had it too). I think they are pretty robust (not too easily damaged).
Please let us know if you find a solution!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe
When all else fails.....procrastinate!
I can't tell you how valuable the exchange between you and Ugha has been for me and doubtless many, many other new folks that are either to embarrassed to ask the questions that Ugha asks or, if they are truly like me, do not know those questions even exist!
It is difficult to communicate across several levels of experience. I could see both of you straining. I hope neither of you give up because ALL of us are learning an incredible amount. The subject line of this thread is truly appropriate: Learning SX/B.
I noticed that even some of your contemporaries had exchanges in which you and they learned a bit. I think. It was a "bit" over my head, but I didn't mind that as I know the waters can get very deep in this technology. Simple folks like Ugha and me are desperately trying to get out of the shallow end of the pool. Without people like you, only our knees will ever get wet. (Well, Ugha has gone a little deeper than me, but he may be the first to admit there is a long way to go before he can scuba dive!)
Thanks, again!
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Thanks for this post!
I was just gonna wait on the SX/B Manuel to come in print.
Bill Chennault:
I'm sorry that I'm this late in the thread. I didn't realize that their was any Mopar fans out there.I would almost kill to " street " a 70'HemiCuda, especially a Sox&Martin HemiCuda!!!!!
Not to many people would recognize a late 60's Hemi. They didn't call it the elephant motor for nothing!
I look at JonnyMac and Bean as the Sox and Martin of the Microcontroller "SXB" Stamp!!!!
__________$WMc%__________
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Truth is out there············································ BoogerWoods, FL. USA
It was a lot of fun while it lasted. BUT, if I had taken that original hemi 'Cuda off the showroom floor and put it in storage, do you have ANY idea what it would be worth today? [noparse]:)[/noparse]
Of course, when I was younger, I trashed a lot of '57 Chevy's, too.
I think I have LEARNED. My Crossfire, which is either no longer manufactured or no longer imported from Europe, is going into storage. My son will inherit it.
--Bill
ps Man! That screaming Sox and Martin engine was fun! It had a tunnel ram manifold and dual 850, gear driven Holley double pumpers on it. I had to look off to the side to see around them. The engine was so well balanced that it would wind to 9k, although I always kept it down close to eight. The first and only time I ever used first gear with the BIG hemi in it, I wound it up to 10k before I could pull a shift. No damage. But, I could have sure used a PARALLAX based governor that shut things down at about 9.5k rpm.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
The power supply doesn't seem to be the problem.
I ran the regulated 5v VDD straight from my BOE into the VDD of my SX tech board and still have the exact same problems.
I can't explain why one person can run JonnyMac's program (him) and I can't. I'm assuming there's something I'm not seeing wrong with my setup... or perhaps the PDB he's using is
better suited to the task or... something.
I don't know.
Can someone from Parallax·please contact me via PM and walk me through testing my hardware (BS2, BOE, SX, SX tech board) to see if I have
a problem? I know my SX tech tool kit was refurbished so it makes me wonder if there was a problem that wasn't fixed or a repaired problem returning.
Post Edited (Ugha) : 2/11/2009 5:13:24 PM GMT