multiple Pulsin

[the old fart]

Hi Guys,

Before I put an order in for the chips, can you check my thinking please.


I require 3 'pulsin' inputs, from a radio control unit. (from spare inputs on my model boat RC.)

The pulse width of each input will determine what happens to a bank of relays and/or opto isolators.

If I use the 20M2 chip I can use multiple starts, I believe.


so would this work:

start0:

do

pulsin c.1,1,b4
pulsin c.2,1,b5
pulsin c.3,1,b6
loop


start1:
; evaluate b4
do

;program

loop


start2:
; evaluate b5
do

;program

loop


start3:
; evaluate b6
do

;program

loop

My thinking is that whilst b4 is in a 'pause' condition then b5 and b6 will still be processed.



I already use the 'pulsin' on a 20X2, but there is a wait until the program finishes other tasks.

thanks

TOF

 

[AllyCat]

Hi,

I must admit that I've never used multitasking, but I rather doubt if Start1 will work as you want, because AFAIK PULSIN is a "blocking" command (i.e. nothing else is executed at the same time). What happens if a pulse appears on c.2 whilst the program is executing the PULSIN c.1,... (answer I believe is nothing)?

Possibly, it can be done by setting c.1, c.2 and c.3 in an interrupt mask and then running a polling routine on the "active" pin, but it depends on the timing resolution that you require. Or is it possible to "predict" the sequence in which the three pulses occur? In that case the issue will be how s-l-o-w-l-y you can tolerate the parallel tasks operating (one instruction between each PULSIN?).

Cheers, Alan.

 

[inglewoodpete]

As Alan has indicated, the M2 series chips cannot execute more than one command at a time. Refer to "Parallel Task Processing" in Manual 1 (about page 62).

Your best bet would be to go back to the 20X2 and use interrupts on 3 pins while running a background timer for timing.

 

[Rick100]

Hello OF,
Have a look at this link:
http://www.picaxeforum.co.uk/showthread.php?13032-Interface-Picaxe-18X-with-an-RC-receiver-to-control-relay

Post 8 has some code you can probably adapt.

Good luck,
Rick

 

[the old fart]

I'll have alook at that code. thanks.

The pulses are approx,

0.5ms to 2ms, repeated every 20ms.


TOF

 

[Technical]

As these are 'standard' servo pulses that repeat continuously you can probably just cycle between the 3 inputs in turn for your application in a single task program, as if you miss a pulse it doesn't matter as there is always another one coming soon!

 

[AllyCat]

Hi,

Yes, the pulses are probably interleaved (on the wireless carrier) so you probably just need to measure their sequence (I believe you have a DP/Santa Scope) and then "sandwich" the additional code in between the PULSINs.

However, if the "parallel" code is long and/or asynchronous, then you could put some short "dummy" code inbetween the PULSINs (e.g. HIGH pin : LOW pin : HIGH pin : LOW pin ) to give the parallel tasks more opportunities to run.

Cheers, Alan.

 

[the old fart]

The problem, which is why I'm looking at parrallel program, is that say:


pulsin c.1 causes a command to 'pause' somewhere in the program, then c.2 and c.3 would have to wait.

would not parrallel processing allow c.2 and c.3 to continue cycling?
or do all processes pause.
TOF

 

[AllyCat]

.....or do all processes pause.

Yes, I think so.

The manual doesn't seem to be totally explicit with:

"Commands that require total core processing to maintain critical timing integrity (e.g. readtemp, sertxd, debug, serin, irin etc.) will ‘block’ the parallel tasking until that command has finished/timed out. Therefore the other tasks will appear to momentarily ‘hang’ during the processing of that command."

but I'm fairly sure that PULSIN (and PULSOUT) use "tight" loops (i.e. "total core processing") both during the "waiting" and the "measuring" phases of the instruction.

Cheers, Alan.

 

[Rick100]

but I'm fairly sure that PULSIN (and PULSOUT) use "tight" loops (i.e. "total core processing") both during the "waiting" and the "measuring" phases of the instruction.

You are almost certainly right. The pic code for the pulsin command probably looks something like this.

http://www.dontronics.com/psbpix/pulsin.html

It's from Scott Edwards "Pic Source Book". The code between 'Pulsin_Edge2' and 'goto Pulsin_Edge2" times the pulse. It takes exactly 10 us at 4MHz. It doesn't have any delays or 'nops' so there is no time for the pic to do anything else.

pulsin c.1 causes a command to 'pause' somewhere in the program, then c.2 and c.3 would have to wait.

I think you will be alright reading the pulses one after the other and then processing them. Like technical says, if you miss the start of a pulse the pulsin command won't timeout before it comes around again in 20 milliseconds.

You could try this simple program to read the receiver pulses.

do

pulsin c.1,1,w1
pulsin c.2,1,w2
pulsin c.3,1,w3


sertxd("C.1 pulse = ",#w1,13,10) 
sertxd("C.2 pulse = ",#w2,13,10)
sertxd("C.3 pulse = ",#w3,13,10)

loop

Good luck,
Rick

 

[Technical]

pulsin command is not the same as a pause command.
It needs to be a tight loop or else it simply won't be accurate.
So no other task processes whilst a pulsin is in progress.

 

[Goeytex]

Whether or not a pulse is missed, is determined by the position of the pulse in relation to the previous pulse and by command overhead time . At a processor speed of 4Mhz, ff the pulses are spaced apart by > ~ 250us and are read sequentially then no pulse will be missed and the read loop will process in <= 20ms after the first pulse is received.

However, if the pulse at c.2 starts at < ~ 250us from the end of the c.1 pulse, it will be missed and pulsin will need to wait ~ 20ms to catch it the next time around. The faster the processor operates, the less the command overhead will be and the less likely a pulse will be missed.

If you have a multi channel scope you can look at the pulses and their relative position to each other and then possibly re-arrange the order that they are read in order to speed up the read loop.

 

[the old fart]

Thanks for everyones input.

I'll hook the receiver to the 'xmas' scope and see what order the signals are received.

TOF

 

[rossko57]

An interesting challenge (not one for me!) to write some code to auto-determine the RC frame order; listen to see what order the three pulses arrive in at start-up, and use that order for the real code. I guess you could pick any arbritary one as 'A' then determine whether delay A to B or A to C is smallest, and jiggle the order only if B > C. Perhaps only do that after 4 or 5 frames to allow the originating equipment to settle down.

 

[goom]

In my experience, the frame order is the same as the order of the channels on the RC receiver.

 

[AllyCat]

Hi,

It could be that you don't want the PICaxe to "read" the pulses in the sequence that they are transmitted/received ! There might be quite a small gap between pulses, shorter that the time that your program takes to process any data. Suppose, for example, that there is a gap of 1ms between pulses, but your code takes 2ms to do whatever it does (and not muich can be done in 2ms even at 32 or 64 MHz). So the PICaxe then will have to wait for 19ms before it sees the next pulse that it is looking for.

Therefore, in practice, you might want to arrange for the PICaxe to look for alternate pulses (e.g. 1, 3, 5...... 2, 4, ....). I believe that such a technique is/was common when reading sectors from a hard drive disk, for example.

But nobody can predict what will be the best strategy for your application. You need to measure the time between, and sequence of, the input pulses, AND how long the PICaxe takes to execute the code blocks that you wish/need to run. Or, if you want a real challenge, you could write code that predicts/measures how long it is taking itself to execute each module, and then calculates which is the next "expected" pulse.

Cheers, Alan.

 

[Goeytex]

If c.1,c.2 & c.3 are on sequential channels ( do we know?) then the order in the read loop will be irrelevant. Likewise if the signals are jammed next to each other (no space between pulses) then missed pulses are certain.

 

[BeanieBots]

The delay/order of RC signals depends on your radio gear.
The older radios put the pulses out in sequence, the newer 2.4GHz ones all come at the same time.
In most of my applications, I read one pulse, 'do what is required within 20mS' and then do the next.
The only time reading each and every pulse is required is for channel mixing on outputs that must not have delay such as aircraft control surfaces. Unfortunatley, PICAXE is not very good for such applications especially when you think most model flyers complain about the delay between channels let alone any other induced delays!

 

[hippy]

From the description of the desired program, multiple tasks acting on pulse lengths and having PAUSE commands within them, the ideal solution may be to use two PICAXE chips. The first reading the pulse lengths and passing those on to the second. This allows the first to continually block without continually blocking the second.