Creating very fast LED pulse trains with the Prop: Spin vs, Assembly Code???
ElectricAye
Posts: 4,561
I'm trying to figure out an easy way to get my Prop to produce a "train" of pulses in which the various highs and lows of the train can be adjusted according to some variables (For example, one pulse might be high for 20 usec, followed by an off state of 10 usec, followed by a high state of 15 usec, followed by an off state of 10 usec, etc. etc.).
I notice that when I use SPIN code like this:
I can get pulses that are about 7.5 usec wide.
I don't know assembly language but I'm wondering if assembly can produce shorter pulses than this? Ideally, I would like to get the pulse widths down to about a microsecond, but even shorter might be better.
I suppose there are other ways of doing this, too. Some sort of serial data output approach???
I'm impressed that I can get SPIN to get the widths down to 7.5 usec, but it doesn't look like I have much control over them with SPIN. At 7.5 usec per pulse, I'm running the code as fast as it can go (I think).
Suggestions much appreciated.
I notice that when I use SPIN code like this:
Repeat outa[1] := %1 outa[1] := %0 outa[1] := %1 outa[1] := %0
I can get pulses that are about 7.5 usec wide.
I don't know assembly language but I'm wondering if assembly can produce shorter pulses than this? Ideally, I would like to get the pulse widths down to about a microsecond, but even shorter might be better.
I suppose there are other ways of doing this, too. Some sort of serial data output approach???
I'm impressed that I can get SPIN to get the widths down to 7.5 usec, but it doesn't look like I have much control over them with SPIN. At 7.5 usec per pulse, I'm running the code as fast as it can go (I think).
Suggestions much appreciated.
Comments
xor outa, #%1 loop xor outa, #%1 xor outa, #%1 xor outa, #%1 jmp #loopOf course you get a glitch on the jmp here. So timing things nicely may result in less than 10 million/second.Oh, Heater, bless you!
I'm using this to blast samples with photons so a glitch here and there is nooooo problem. I guess now would be a good time for me to learn some assembly, eh?
Thanks for the tip!
http://www.rayslogic.com/propeller/PulseGen.htm
Martin,
Yes, PWM would be fast, but I'm trying to make each pulse width in the train somewhat different. And, ideally, I would like some real time control of those widths. I don't think PWM can change pulse widths on a pulse by pulse basis, or can it?
Rayman,
I've just taken a glance at your most awesome link. Wow! It, like, takes you by the hand and walks you through this very sort of problem. It's going to take me some time to study this, but this is amazing stuff.
Thanks for the help!
Oh yes, time to learn some PASM. You can do a lot of interesting stuff in PASM with out it getting horribly complicated. Only when you want to wring the last once of performance out of something, like many do around here, does PASM start to become incomprehensible.
Still, as Martin says you might be able to do what you want in Spin using the counters.
Thanks to the timing of its showing up in my email, Martin's mention of PWM caused me to think of a solution to another problem I've been puzzled by. Maybe he's psychic or something.
Man, you guys are better than coffee in the morning! (Well, almost.)
Thanks guys. I'm marking this one as SOLVED.
Yes I guess you are right. I've never done anything with video yet. But as far as I understand - any graphical pattern ist stored in a buffer and a video-driver reads the buffer byte for byte and creates the according
signal which is nothing else but a variable pulsetrain.
best regards
Stefan
That's a very interesting idea. Do you know if that's something that can be implemented in SPIN, or does one have to ascend to assembly language for that?
Thanks. :-)
So it sounds like SPIN might be fast enough.
I am pretty sure you could make some text video out programs and use spin for the rest. It might not even require two cogs to generate the signal you want.
Currently the VGA _Hi_Res_Text reads a line of ascii text from hub ram and uses a lookup table to produce the bit patterns for the video. IIRC each line of text results in 16 lines of video.
I don't see any reason why you could not put the bit pattern you want to output in hub ram and have the cog output that pattern without translation. It should be much simpler than producing a video signal.
Using the settings for 1024x1280 requires a pixel rate of 60MHz so the smallest change to a pulse would be 16nS. I am pretty sure that can be reduced to 10nS or less.
The limitation here would be the size of hub ram. At 60MHz the cog would cycle through the entire hub ram in slightly less than 17.5mS.
All in all, I have found the video capabilities of the prop to be an awesome asset for generating precisely timed digital and analog signals.
That is truly phenomenal. A very tempting target but I'm going to have to do my homework to understand how all of that works.
I wonder if there's a way to use shift registers, load up a bit pattern using the Propeller, then chug out the pulse train using some kind of high speed clock? I guess it might take a large number of parallel-serial (?) chips to get good resolution and a reasonable size pulse train.
Thanks again to eric and kwinn for the information on this.
In essence the video circuitry is a shift register and using the waitvid instruction that shift register could be as long as the hub memory available beyond what any running spin programs require. Use PASM for generating the video and creating/modifying the waveform and the full 32K is available. That would be 1048576 bits. Also, you would be loading 32 bit words from hub ram rather than bytes.
The video part of the software would also be much simpler than generating actual video out. Once the video generator is set up it would be a loop that loads a long from hub ram, executes a waitvid, checks for the end of the hub buffer and sets the pointer to the beginning if true, then repeats. Checking and resetting the hub pointer could be as simple as an and instruction if care is taken.