How do you store 1 to 2ms servo pulses in a variable?

Gents (and ladies), first off, thanks for the neat forum.

Rather than charge in like a bull at a gate (this is my first posting), I took the liberty of snooping the 'read-this-before-you-post' pages first. That cracking-looking chick there, she mentioned something about new members being mostly berks, and that you experts should be good to us.
In my defence, I did have a good look around prior to posting this, but couldn't find what I'm looking for.
Could I ask that you pardon this berky question, but can anybody help me with this?...
Using the PICBASIC compiler, is it possible to have a '16F84 read 1mS to 2mS radio-control pulses at PORT A, then send the same pulse to PORT B, but inverted? (Inverted as in the RC servo horn operating in reverse).
I've dabbled with the PCM and SERIN commands and from that you can probably tell I don't really know what I'm doing.

Can I call on you boffins for your help, please?

Many thanks for reading.

pulsewidth var word

main:
pulsin port-whatever-pin-whatever, 1, pulsewidth '1 if you pulse is active high
pulsewidth = 2000 - pulsewidth
pulsout port-whatever-pin-whatever, pulsewidth
goto main

Of course, this assumes that your max pulse width is 2ms, usually they go a tad bit farther than 2ms (2.5ms is max endpoint on one of my Futaba's). And the 2000 will also depend on how fast your oscillator runs.
And this will (by default), run at the correct frequency, since the pulsin will only activate when you're servo gets a pulse. Then the program will output the 'inverted' pulse, then go back to the start and wait for the next pulse.

3 other questions: :D
What's a berk?
What is it to be berky?
What's a boffin, and how many of them does it take to screw in a light bulb? :D

Hi, Skimask

I wonder it was a typo ...

but inverting "formula" is :

Inv.pulsewidth = ( 2*Neutral ) - pulsewidth

so, in µS it's .... ( 2*1500 ) - pulsewidth

Alain

Quote:

---

Originally Posted by Acetronics

Hi, Skimask
I wonder it was a typo ...
but inverting "formula" is :
Inv.pulsewidth = ( 2*Neutral ) - pulsewidth
so, in µS it's .... ( 2*1500 ) - pulsewidth
Alain

---

I've been using my bit of 'pseudo-code' for awhile, works for me, but there's also a lot of assumptions (4mhz osc, 1500us perfect center, 2000 perfect endpoint, etc).
I like your bit of code better and I'm going to change my ways of doing those.

But my understanding is that PULSIN and PULSOUT only applies to PORT B.
Is there a way that RC pulses can be read into PORT A?
Can it indeed be done on the PIC16F84 with the PICBASIC compiler?

Appreciate your time and help with this.

Quote:

---

Originally Posted by Martin Peters

But my understanding is that PULSIN and PULSOUT only applies to PORT B.

---

Where'd you get that info?
PulsIn/PulsOut doesn't have those restrictions.
If the pin can be read, you can use PulsIn.
If the pin can be written, you can use PulsOut.
It's all in the PBP manual.

And are you using PicBasic (PBC) or PicBasicPro (PBP)?
And which version?

That info. was gleaned from "PIC BASIC - An Introduction" (Neil Edwards & Jasper Roberts). Apologies, I thought I'd already stated the compiler is PICBASIC (PBC).
The PULSIN / PULSOUT commands work fine with PORT B, but not with PORT A. I'm looking to store five R/C channels on each of the five Port A pins, before routing them to PORT B.
From the above postings I've learnt how to get the needed servo reverse action (thanks), but how do you get the RC pulse on PORT A when PBC doesn't recognise PULSIN for that port?

Well, we don't know for sure which PIC you're using (you hinted at the 16F84, but never really specified)...but...
As far as PBC, yep, you sure did mention it... I missed it. My bad.
And PBC is limited in that respect, Pin 0 - Pin 7, that's what you get. Maybe Pin 8 will get you PortA.0. I don't know, I don't use PBC.
If you want my advice, get the upgrade to PBP. You'll be MUCH happier in the long run.

Short of that, don't use the pulsin statement ('cause PBC won't let you).
Write your own tight loop to mock pulsin.
Wait for the pin to go high (or low)
Sit in a tight loop counting the passes thru the loop while the pin is high (or low)
Exit when the pin changes again.
Take the loop count, multiply it by the # of us spent in each loop, and you've got your answer...

OR...
Use the pulsin on the PortB, and use a delay loop to send the 'pulsout' on PortA.

'Fraid you're waaaay over me now.

I've downloaded the PBP demo version and the code in your first post works great. But the project calls for five seperate pulses on each pin of PORT A (running on a PIC16F84, BTW).
Adding a few more lines to your original code just isn't working. Re:

Pulse0 VAR WORD
Pulse1 VAR WORD
Pulse2 VAR WORD
Pulse3 VAR WORD
Pulse4 VAR WORD

Main:

PulsIn PORTA.0, 1, Pulse0
PulsIn PORTA.1, 1, Pulse1
PulsIn PORTA.2, 1, Pulse2
PulsIn PORTA.3, 1, Pulse3
PulsIn PORTA.4, 1, Pulse4

PulsOut PORTB.0, Pulse0
PulsOut PORTB.1, Pulse1
PulsOut PORTB.2, Pulse2
PulsOut PORTB.3, Pulse3
PulsOut PORTB.4, Pulse4

GoTo Main

End

Works fine with just one servo, but as soon as the extra code is added, nothing happens at all.

Would you be interested in commiting yourself to help with this? You obviously have the wherewithal to do this stuff, but I wouldn't expect your help for free. Care to name your price?

Hi, Martin

Do you know these tiny inverters are VERY simple to build with CMOS circuits ???

TONS of circuit schemes are available on the web ...

Note those gadgets also are available as ready to use devices from R/C manufacturers ... if you're ready to pay for.

I can't believe you have to "invert" all the 5 channels at the same time ...


Alain

Ace,
Your comments are noted - tnx for your reply.

Four of the five PORTA channels are the usual throttle, rudder, ailerons and ele' channels. The fifth channel is a so-called 'switching channel'. It shifts PORTA pulses to either four outputs on PORTB.0 to PORTB.3... or PORTB.4 to PORTB.7.
Only the latter four will be inverted.
Instead of aeroplanes, think along the lines of two working gun turrets - each requiring four servos. A sort of pseudo 8-channel Tx.

I'm loathe to buy such gadgets. I'd rather bung a few quid in the direction of someone who builds, rather than buy.


Thanks for the CMOS suggestion. Maybe Google will throw some light this way.

Hi, Martin

Would be surprising if you couldn't find what you need here ...



http://www.uoguelph.ca/~antoon/gadgets/gadgets.htm


http://homepages.ihug.co.nz/~atong/index.html


If you still do not find ( laughs ...) ring me up !!!

Alain

Might I think about a Tirpitz, Prinz Eugen, Sharnhorst ... Hood, Rodney ... ???

Look in the manual under 'DEFINE PULSIN_MAX'

I get the feeling that your code is getting 'hung up' waiting for a pulsin, and it doesn't happen, or it's just not arriving when you want it to. Pulsin times out and returns 0 for a value.

If you limit your pulsin to 3ms (DEFINE PULSIN_MAX 300 @ 4Mhz will limit pulsin to 3ms), the program might work like you want it to. But then you have to add some 'error checking' code. I.E., if the pulsin timed out, don't output the 'dead' value, re-output the old value, something along those lines.

Mhhhhhh,

I think reading the 5 signals one after the other can't work like expected ...

signal n+1 begins ~ 15 ns ( yes ... NANO seconds ) past signal n ends ...
Pbp cannot follow that !!! ( verified ... need time to change input pin: 4-6 µs.) and we must wait for the following signals burst.

So, @ 4 Mhz the default timeout is 650 ms ...

here we have :

2 + 27 + 27 + 27 + 27 + 5 x 2ms ( maxi ) ... 120 ms per loop ... ( W/a 40 Hz frame )

The truth is elsewhere ...

we must also verify pulses come in the same order as the inputs are connected ...

I already have realised that (with 4 channels ...) and it can be done with a PULSIN - RCTIME - RCTIME - RCTIME - RCTIME sequence ...

My Application is a 4 channel ... Failsafe. WORKING

Alain

Quote:

---

Originally Posted by Acetronics

signal n+1 begins ~ 15 ns ( yes ... NANO seconds ) past signal n ends ...

---

Alain[/QUOTE]

That's what I'm saying, PBP and pulsin will likely miss every 2nd servo 'pulse' coming from the receiver.
Normally, obviously, you wouldn't want to use this sort of thing in an aircraft, or even an R/C car...but apparently, this is for some sort of 'turret control'.
So, if that's the case, it probably wouldn't hurt to miss a pulse here and there. The code could just grab whatever pulses it could from whatever pins, and whichever pins it misses, just resend the last good value it got for that pin.

Hi, Skimask


Back to our friend's program ... there's something " not told " ... cause it might give outputs ... even one of 3 or 4 !!!

I'll give a try to that code on my breadboard ... or just use a 16F84 instead of my failsafe processor !!! Test board already made for 4 channels ...

results tomorrow morning ...

Alain

Quote:

---

Originally Posted by Acetronics

Hi, Skimask
Back to our friend's program ... there's something " not told " ... cause it might give outputs ... even one of 3 or 4 !!!
I'll give a try to that code on my breadboard ... or just use a 16F84 instead of my failsafe processor !!! Test board already made for 4 channels ...
results tomorrow morning ...
Alain

---

If I'm reading this right, the original poster, wants to sample 5 channels, and based on the value of the 5th channel (be it high or low or whatever), send the 1st 4 channels either out these 4 channels or those 4 channels...just like he said, a channel switcher.
If that's the case, why bother sampling the other 4 channels? Just sample the 5th channel and use an output based on that decision as an input to a 2 input AND gate, along with the other input coming from channel X.
2 74L08's (8 2-input AND gates), one PIC12Fxxx (or even 10Fxxx) should handle the 5th channel switching chores.

Of course that's only if I'm reading the project correctly.

Chaps, this is dead interesting stuff. Not sure that I follow ALL what is being said, but still good nonetheless.
In the previous post I mentioned that both turrets need four servos each to operate. Apologies... I mislead. Each turret needs just THREE servos - not four. The usual 'landing gear' switch (Ch.5) is to be the switch that changes the three R/C pulses at PORTA to either PORTB.0 to B.2, or B.3 to B.5.

Using a 4MHz crystal/resonator I found the output gives a slight amount of servo jitter. Not much, but enough to be annoying. Swapping the Xtal to 10MHz does counter that unwanted jitter, but then the 'reverse' timing becomes out of sync (servo neutral shifts to somewhere other than neutral).

I like the AND gate suggestion. But in this case the three servos which are not being operated are to be set to their neutral positions while they're sleeping.

The downloadable version is PBP is limited to around thirty lines of code. I'm toying with the idea of purchasing the full-working version, but reluctant to splash out £££s if I can't even understand how to write simple code for gadgets such as this.
You guys obviously know what you're doing so I'm hanging on to your advice.

Ace': Good luck with the breadboard lash-up. And thanks!
Same goes for you too, Ski'.... Thanks for all your input with this.

[QUOTE=Martin Peters;39803]

Using a 4MHz crystal/resonator I found the output gives a slight amount of servo jitter. Not much, but enough to be annoying.

> Good news ... your program works now ???

Swapping the Xtal to 10MHz does counter that unwanted jitter, but then the 'reverse' timing becomes out of sync (servo neutral shifts to somewhere other than neutral).

> Héhé, PULSIN resolution changes with XTal freq. ... so @ 10 MHz ... neutral becomes 150 x 10 / 4 = 375.

I like the AND gate suggestion. But in this case the three servos which are not being operated are to be set to their neutral positions while they're sleeping.

> Sending no signal to servos ( but servos always powered ) **might** leave them to their last position, if light effort like placing a gun barrel ... to be verified "live"

The downloadable version is PBP is limited to around thirty lines of code. I'm toying with the idea of purchasing the full-working version, but reluctant to splash out £££s if I can't even understand how to write simple code for gadgets such as this.

> If you want to do ... you have to learn !!! no "pushbutton" miracle device here ...
> You'll have to learn some basics of general program writing like flowcharts ... clearly told : to write down what you want to do and how you will do it.
> Translating those papers into µP languages is the easier part of the thing ...

> Those "gadgets" we play with have needed some years learning and experiencing ... and we still learn each and everyday !!!
> Are you ready for that ???

You guys obviously know what you're doing

> do you really think we know what we do ??? ( LOL )

so I'm hanging on to your advice.

My own advice is to look at what you want to do w/µP ... programming is like jogging ... stop for a while and It's a bit hard to recover the "cruising speed"

Alain

Hi, Martin

I did some diving into my Model Boats docs ... and found a Proton Basic Program Called "Turret1" ... I think you found it too !!!

That raised in my mind the problem is much more complicated than we think ...

- Use the minimum count of channels to drive from 1 to 4 Turrets
- Have slow turret rotation
- Move 1 to 4 Turret at the same time ( "Inverting The signal" good reason ... ).
- couple by couple would be really nice ...
- Have slow Barrels positionning too ...

And overall keep a "driving board" that can be placed on a Classic Transmitter !!!

So, ... I decided to re-Start the project on the Basis Here explained ...

Alain

Quote:

---

Originally Posted by Acetronics

- Use the minimum count of channels to drive from 1 to 4 Turrets
- Move 1 to 4 Turret at the same time ( "Inverting The signal" good reason ... ).
- couple by couple would be really nice ...
- Have slow Barrels positionning too ...
And overall keep a "driving board" that can be placed on a Classic Transmitter !!!
So, ... I decided to re-Start the project on the Basis Here explained ...
Alain

---

This could come in handy for things on R/C planes, bomb doors, flour bomb drops, tail hooks, etc.etc...not to mention extra turrets too...
This might be fun...

Hi, Skimask

"Turrets driver" is the only gadget I do not have realised for my planes yet ...
As piloting + controlling turrets is not so easy ( LOL ) I'd planned to drive them with an IR source located on the ground.

it's the moment to design it ... I've just finished an A26 Invader plan ...1/8.4 Scale

Led-Machine guns,Electric gear control, bomb bay control and navigation lights are already built ...

Alain

Quote:

---

Originally Posted by Acetronics

Hi, Skimask
"Turrets driver" is the only gadget I do not have realised for my planes yet ...
As piloting + controlling turrets is not so easy ( LOL ) I'd planned to drive them with an IR source located on the ground.
it's the moment to design it ... I've just finished an A26 Invader plan ...1/8.4 Scale
Led-Machine guns,Electric gear control, bomb bay control and navigation lights are already built ...
Alain

---

Well, I was thinking more in terms of a 'co-pilot' running another box that might be 'hard-wired' to a spare channel. (hey, your feet aren't doing anything when you're flying an R/C plane!!!)
Or how about randomly turning turrets/gadget...bring up the gear, wheel hits a lever switch, turrets start moving...

I was thinking to the thoughts of the scale judges colledge looking at the gun barrels pointing to THEM ... ha,ha,ha ...

Alain

Quote:

---

Originally Posted by Acetronics

I was thinking to the thoughts of the scale judges colledge looking at the gun barrels pointing to THEM ... ha,ha,ha ...

Alain

---

Surely a case for building an IR tracker if I ever saw one! :)