ShiftOut command
SailerMan
Posts: 337
Is there any way to slow down a shiftout command?
I can't seem to get my propeller to read the data.· (Is the Shiftout to fast for the Propeller?)
Eric
·
I can't seem to get my propeller to read the data.· (Is the Shiftout to fast for the Propeller?)
Eric
·
Comments
From what I have read regarding the Propeller, I highly doubt you are sending it data faster than it can receive it.
Also, I do not think the SX/B "shiftout" command can be slowed with an optional clock modifier, though it can be sped up. I can think of several ways to slow down a shift out function for testing. That *might* help you. However, I suspect there is likely something wrong with your Propeller code, your expectation of the way the data is presented (MSB first? LSB first?) or your connections.
If you really want to run the shiftout command at a lower speed, you can try lowering your clock frequency. If you have an SX-Key, you should be able to use it to generate extremely low clock speeds for the SX.
If you need more help slowing the shiftout sequence, let me know.
- Sparks
The Propeller can easily handle better than 20000 Baud in SPIN doing asynchronous serial transfers. SPI transfers (like done by SHIFTOUT) should be faster. In assembly, the Propeller can transfer well in excess of 1M bits per second in either mode (asynchronous or synchronous).
I did a short bit bang (8-Bits) from the SX to the Propeller's ShiftIn_SLave Clock (Bs2.Spin) and it worked...The Shiftout Command from the SX did not. (Hmm..)
Can I directly connect the Sclk and Dpins from the SX to the Prop?
Regards,
Eric
>> "Can I directly connect the Sclk and Dpins from the SX to the Prop?"
Yes. You can connect the pins directly, assuming the two devices share a common ground connection.
If you can bit-bang it and make it work, you have to close. Electrically the connections must be right. Have you tried all four of the SX/B shift modes?
- Sparks
·
·· Is the SX running at 3.3V?· If not I wouldn’t connect them directly, but rather I would place a resistor in between the I/O pins.· See the sticky thread in the Propeller Forum if connecting 3.3V devices (Propeller) and 5V devices (SX?)…Take care.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
They both need to be using the same logic levels (something I assumed and probably should not have) or you will need to adjust for that.
- Sparks
Well, actually they dont need to be the same logic levels; they just need to be able to go above and below each other's switching thresholds. Also, current limiting will be required so the higher voltage one does not clobber the lower voltage device. For moderate speeds this can be simply handled by a series resistor of 1 to 3 KOhms or so.
Cheers,
Peter (pjv)
SX28
Main: Do RB.0=0 IF RB.3=1 Then 'RB.3 is Pin 19 On the Propeller RB.0=1 Shiftout RB.1,RB.2,0,Encoder_A_Count_LSB Endif LoopPropeller::
Repeat OUTA[noparse][[/noparse]19]:=1 SX:=SHIFTIN_SLV (17,18,0,8) OUTA[noparse][[/noparse]19]:=0Debug.Bin(SX,8) Debug.Str(String(" ")) Debug.Dec(SX) Debug.Str(String(" ",13))Propeller Pin 17 ---- SX Pin RB.1· 1k Resistor
··········· Pin 18
SX Pin RB.2· 1K Resistor
··········· Pin 19
SX Pin RB.3
What am I missing that I can't get this working. For 1 week now I have been trying to get the SX28 to communicate with the Propeller.. I'm to much of a Novice I guess because I'm really needing a sample of how to get 1 byte sent.
Help Please.
·
If it's possible in SX/B to slow the SX down by many orders of magnitude, you might stick an LED on the SX transmit bit, rb.0, and observe what it is sending. You can make things slow (enough ??) by using the SX-Key as the clock source and setting its speed in the "clock" window, or in the program with a FREQ directive.
I'm not positive you can slow it down enough, but unless you have an oscilloscope, it's probably as good an indication as you can get.
Of course that does not help the Propeller end, but it might eliminate problems in half of the equipment.
Alternately use the SX-Key's "debug" facility and single step the compiled assembly equivalent program to see what it's up to.
Have you tried Guenther's simulator ?
Really, this task is not THAT tough! I'll write you a variable speed assembly routine (not much good at SX/B yet) to output data from the SX if you wish.
I presume you do have an SX-Key ?? You're dead without one !
Cheers,
Peter (pjv)
1) I assume your SX routine is happy with mode 0 (MSBPRE)
2) I assume that your SX routine expects Data on RB.1 and Clock on RB.2
3) On the Propeller, have you set "DIRA[noparse][[/noparse]19] := 1"? It won't work if you don't. You should probably set "OUTA[noparse][[/noparse]19] := 1" just before that to ensure that the SX won't see a zero too early when the pin becomes an output.
You have a Parallax USB Oscilloscope. I know this from another posting you made a while ago. That silly little tool really helped me understand synchronous serial communication, along with the different methods of sending the data. Can you hook up the scope and set the trigger for the first bit transition? Capture an image and post it on this thread. We can get this problem solved! Once we know the SX is generating something that makes sense, it'll only be a matter of getting the Prop to understand it too. I find that the best way to solve these problems is one bit at a time. . .
Ken Gracey
Parallax
Post Edited (Ken Gracey (Parallax)) : 10/18/2006 5:14:31 AM GMT
Mike I believe I do have your suggestion implemented, but maybe not in the proper sequence.
I was using the Oscope to I saw the proper pulses... When I get home tonight I will post a screen shot.
One thing I forgot to mention was I did·Clock the SX28 at 128khz and the transfer was fine... I think something is wrong with my timing at higher speeds, I'm going to·have to make sure I have the SX and the Propeller Sync before the transfer is made.
I swear if I get this working, I will have learned a great deal on serial transfer.
I'll Post the photo later tonight... Around 5:30 est. Check back Please!
Post Edited (SailerMan) : 10/18/2006 12:19:10 PM GMT
I am shifting out Decimal 10.· Bin 00001010.
Do Low RB.0 If RB.3=1 then Shiftout DataPin,ClockPin,0,10 Endif High RB.0 LoopI am clocking the SX at 128KHZ and I am recieving data on the propeller as Such...·Decimal 10 (Bin 00001010)... Yippy...All is Fine. Except I can't Clock any faster than 128K.
When I clock the SX28 higher that 128k... It loses communications and I get junk data.
Con _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 MSBPRE = 0 LSBPRE = 1 MSBPOST = 2 LSBPOST = 3 LSBFIRST = 0 MSBFIRST = 1 Var Long MicroSecond Long SX Obj Debug : "TV_Text" Pub Main|Range MicroSecond:= clkfreq / 1_000_000 Debug.start(12) DirA[noparse][[/noparse]19]:=1 Repeat SX:=0 OUTA[noparse][[/noparse]19]:=1 If OUTA[noparse][[/noparse]16]:=1 SX:=SHIFTIN_SLV (17,18,3,8) OUTA[noparse][[/noparse]19]:=0 WaitCnt(10_000_000+Cnt) Debug.Str(String("Bin=")) Debug.Bin(SX,8) Debug.Str(String(" Dec=")) Debug.Dec(SX) Debug.Out(13) PUB SHIFTIN_SLV (Dpin, Cpin, Mode, Bits) : Value | InBit {{ Shift data in, SLAVE clock (other device clocks), For mode use BS2#MSBPRE, #MSBPOST, #LSBPRE, #LSBPOST Clock rate above 16Kbps is not recommended. Use at 80MHz only is recommended. Can cause cog lockup awaiting clock pulses. X := BS2.SHIFTIN_SLV(5,6,BS2#MSBPOST,8) BS2.DEBUG_DEC(x) }} dira[noparse][[/noparse]Dpin]~ ' Same as SHIFTIN, but clock dira[noparse][[/noparse]Cpin]~ ' acts as input (slave) outa[noparse][[/noparse]Cpin]:=0 If Mode == MSBPRE Value:=0 REPEAT Bits InBit:= ina[noparse][[/noparse]Dpin] Value := (Value << 1) + InBit waitpeq(1<< Cpin,|< Cpin, 0) ' wait on clock waitpne(1<< Cpin,|< Cpin, 0) elseif Mode == MSBPOST Value:=0 REPEAT Bits waitpeq(1<< Cpin,|< Cpin, 0) waitpne(1<< Cpin,|< Cpin, 0) InBit:= ina[noparse][[/noparse]Dpin] Value := (Value << 1) + InBit elseif Mode == LSBPOST Value:=0 REPEAT Bits waitpeq(1<< Cpin,|< Cpin, 0) waitpne(1<< Cpin,|< Cpin, 0) InBit:= ina[noparse][[/noparse]Dpin] Value := (InBit << (bits-1)) + (Value >> 1) elseif Mode == LSBPRE Value:=0 REPEAT Bits InBit:= ina[noparse][[/noparse]Dpin] Value := (Value >> 1) + (InBit << (bits-1)) waitpeq(1<< Cpin,|< Cpin, 0) waitpne(1<< Cpin,|< Cpin, 0)·Thanks for the help,
Eric
PS I uploaded another Picture... I was Sending 0 Decimal. and I clocked the SX28 @ 1MHZ... As you can see I was getting 16 Clock Pulses. It Bounce for 8 to 16 in a random fashion... Is this normal?
Post Edited (SailerMan) : 10/18/2006 10:02:26 PM GMT
If you want higher speeds, you'll have to use an assembly routine on the Propeller side. You should be able to get well over 1Mbps that way.
I think he meant he was running the SX at 128KHz.
Eric,
The standard SHIFTOUT speed for SX/B is 84Kbps. When you run the SX really slow (128KHz) it doesn't output that fast.
You will either have to use assembly on the propeller, or write a bit-bang shiftout on the SX.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin
·
Mike......Unfortunately... I've always had a problem learning Assembler, I've always wanted to learn, but I don't get a lot of the concepts and without someone to talk with it's hard to learn from reading.
Thanks for the sample...I will look at it closely.
First, with the Internet in general, and forums like this specifically, there has never been an easier time to learn assembly since you can indeed ask questions to a broad spectrum of programmers.
Second, one key thing to remember in assembly language programming is that it has all the same basic abilities as a high level language - but it doesn't simplify them for you. In other words, lets say that you wanted to set up a variable in assembly and then assign a value to it. In assembly you have to manually allocate some space for it using code ike this:
org $8 ;Set the current address to the global bank TempCounter ds 1 ; Just a TEMP!Then, later in your code, you would have to use something like this:
Third, when trying to learn assembly language, you need to write the simplest program you can think of so you don't confuse the problems of trying learn assembly with the problems of trying to debug a program. When I say simple, I mean SIMPLE! I'm talking about a program that just loads a couple of memory locations with values, and does some trivial addition and subtraction with them. Forget about input and output. The values are hard coded in the source file, and the output is verified by using the hardware debugger and the WATCH command.
Most folks are so busy trying to write a program to control an autonomous robot with realtime vision capability as their first programming project that they surrender and give up. Once you've got a couple of internal memory locations swapping values, then write the classic "blink an LED program". After that, try and do some sort of simple program that actually has some use to you.
One really cool thing about Assembly language is that once you learn one, you discover that all assembly languages are really just variations on each other. They all require you to do more or less the same things, but with the details different. This means that it's much easier to pick up a second or third assembly language because so much of the learning hurdle is in the first one.
I have no idea of your level of programming experience. But it doesn't matter. I've been programming for almost 30 years, but when I start with a new language or new CPU, I always start with the simplest program possible until I understand the landscape a bit better.
Thanks,
PeterM
Thanks for that... It's funny you ask how long I have been programming.
Really, on and off for almost 30 years myself... but I always used a form of Basic. My First computer was a commodore Pet in 1977 I was just 11 and loved seeing what I could come up with. It's my own stupid fault that I didn't learn assembler.. But I guess it not to late!!
Are you willing to help a little?
Thanks and best Regards,
Eric
·
You asked if it was normal that you are sometimes getting 8 and sometimes getting 16 clock pulses when you run the SX at higher speeds. My answer is, yes, I think you can expect this. I think your observation can be explained by considering that when the SX is transmitting faster, the Propeller may or may not see all of the state changes of the clock line. This result is a complex condition of both the transmission speed of the SX and the sampling speed of the Propeller but should only occur when the sampling speed of the Propeller is too slow to guarantee a good reading.
According to the Nyquist theorem, we know that the Propeller ought to be sampling the state of the clock line at a rate that is faster than twice the maximum clock cycle frequency. (By this I mean the frequency at which the SX is cycling the state of the clock line, not the frequency of the instruction clock that is controlling the SX itself.) When sampling in the 2x to 1x range of the clock line the Propeller may or may not see all of the clock line state changes. This result depends upon when those changes occur in relation to when the line was sampled. Therefore you must ensure that the Propeller will sample faster than 2x the clock line frequency to guarantee no clock pules will be missed.
If the Propeller were to miss a clock pulse, as could happen if the Propeller is sampling at or below twice the rate at which the SX is cycling the clock line, it would fail to change the state of your "handshake" line RB.3. When the SX finished sending its data, it will loop back and check the status of this line again. If it is still low, as would be the case if the Propeller missed a clock pulse, the SX will transmit again. Therefore sometimes you may see 8 clock pulses sent. Sometimes you may see 16!
So it does appear that you are facing a timing issue, though not one that is (at least of yet) limited by the hardware of either device.
- Sparks
I can help where I can help, and there are many more on the forum as well. If you're interested, just jump in and do as I suggested - write a program that adds two variables together and stores the results in a third. Initially, you can do all of the work in the global variables, and when that works, try doing a version that works across the SX chip's memory pages.
Thanks,
PeterM