BS2_Functions.spin Timing question

Sariel

Hey guys!

I am new to this whole propeller thing, and I found this nifty object that is designed for folks like me that know the BS2 inside and out, and need a jumpstart in the propeller. I have a pretty time sensitive project going, and I was wondering if I have the time to learn all about the .spin language, or if I should just cut the corner and use the object.

My question is about a little comment in the object file itself that reads:

" Note: SHIFTIN/OUT, DEBUG/IN and SERIN/OUT are only recommended at 80MHz
Maximum Baud Rate is 9600.
For more options, use the"FullDuplexSerial" Library."

That being said, does that mean that I am going to be restrained to how fast SHIFTIN/SHIFTOUT works on the BS2? I completed the same project on the BS2, and while it worked, the amount of time it took to shift everything out then back in again, and get the needed results was unacceptable. I switched over to the Prop hoping that I could get things done faster. If I am limited by the speed this object can muster up, then I am going to have to bite the bullet and figure out how to use the 74HC595 and the 74HC165 without the object.

Any help, as soon as possible would be greatly appriciated. Thanks folks!

Sariel

Another thing I wanted to add, is that I found the objects for using these chips in the Obex. While this is good news for me, and makes things a bit easier, it still does not make it easier to write the base code.

And a bit of background on my project, just to make things easier....

I want to build a cable tester. The basic idea I have is to have a mating connector on the parallel end of a 74HC595, and another on the parralel end of the 74HC165. Then, have the prop shift out 0000 0001 to the 595, and scan the 165 for the same pattern. If, for example, it finds 0000 0011, it will know that pins 1 and 2 are shorted together, and it will report a failure to the operator.

Mike Green

The routines in BS2_Functions.spin are written for the general case and are written completely in Spin without any use of assembly language. Spin is interpreted and while much faster than the BS2 equivalent operations, is much slower than assembly language. For example, a serial input/output routine completely written in Spin will operate up to 19.2KBps with an 80MHz Propeller system clock (5MHz crystal * 16 with the PLL multiplier). The equivalent using an assembly language low-level serial I/O routine (FullDuplexSerial) can go well over 230KBps at 80MHz. The same sort of thing is true for clocked serial I/O (SHIFTIN / SHIFTOUT), but more so. The Spin routines are comparable to the asynchronous serial versions, but, using assembly and some other features (like the cog counters), you can easily get 10MHz clock speeds. There have been some special purpose serial I/O routines written (for Prop to Prop communications) that operate at 20MHz with an 80MHz system clock.

Cluso99

Sariel: Firstly, welcome to this fabulous forum.

Regarding your problem... Have you thought about just using the props I/O pins. You could use 2 8bit ports (pins) with 8 as output and 8 as input. Just put a code on the 8 output pins and read in on the 8 input pins. This is simple and quite fast in spin, and no shifting required.

Sariel

Ahhh if it were only that simple. I would love to, but the first cable that this is designed to test is going to have a total of 24 wired networks including drains and case to case connections, so I am already out of I/O's at the start of the project. I stated it that way just for simplicity's sake, ommiting the fact that I am going to be cascading multiple shift registers. I would like to start with having 3, maybe 4 shift registers on each end, and once I get better at the code I want ot be able to test different cables with the same base tester, just by having different fixtures to hook up to the main processor box.

Sariel

Ok... from what I gather, I should be trying to get the 165 and 595 objects rolling, Now that I have looked at them a bit closer, I might be able to get this going, while keeping my project deadline. I'll post any further questions I may have here. Thank you everyone for your support, and this is just one more reason I turn to Parallax for uC stuffs. Documentation is pretty good, Support forums are top notch, and the hardware is stable as all get-out, plus it is easy to find out there from pretty much any distributor.

Thanks guys... as I was warned, Mr. Green and company are really helpful.

Sariel

All right folks. This is probably going to end up being a simple one to answer, but I am working with the jm_595_ez_demo object, and I want to get the cascading thing to go, but the comments in the object file are not too straight forward on what lines I need to edit in order to get more than one chip going. I have the circuit built, and I verified more than once that it is wired correctly, but I am noticing that both of the chips are outputting identical patterns.

Can anyone give me a quick answer to this?

Mike Green

Read the comments in jm_595_ez. It should be very obvious how to output to 1 to 4 74HC595s. jm_595_ez_demo is written to use just a single 74HC595. If you run the demo with cascaded 595s, it outputs to the first one, then cycles again and the bits from the first 595 get clocked to the second 595 on the second cycle, etc.

Sariel

Nevermind. I think I got it... well, at least a crude implementation of it anyhow. Here is a snippet of what I did, in case anyone sees a better way of passing this data through.

pub main | pattern
leds.init(2, 1, 0) ' initialize 595 driver
pattern1 := %0000_0001
pattern2 := %0000_0000
repeat
repeat
leds.out2(pattern1, pattern2)
waitcnt((MS_001 * 75) + cnt)
pattern1 <<= 1
until pattern1 == %1000_0000
pattern1 := %0000_0000
pattern2 := %0000_0001
repeat
leds.out2(pattern1, pattern2)
waitcnt((MS_001 * 75) + cnt)
pattern2 <<= 1
until pattern2 == %1000_0000

Hey, cut me some slack. I am a noob to this language ;o)