Capturing Receiver Outputs [Archive]

labmaster

Oct 05, 2007, 06:56 AM

only to think about:

when using interrupt on pinchange for each channel you've to be aware that this could cause a big jitter at the sampled channel values.

eg. when using a pic 16 controller with let me say 8mhz clock:
-the instruction cycle time is 1/2us
-for entering the int routine checking flags and saving registers you need at least about 14 instruction cycles (7us)
-additional a couple of more instrustion cycles until the int routine is finished (as at least you've to save some timer values)
so let me say your int routine is well designed and very short to take only 18 instructions (9us).
-after that you've to restore your registers and jump back, so again at least 8 instruction cycles (4us)

so when we add up the times
7us + 9us + 4us = 20us

Now think about what happens if two pins changes state at nearly the same time.
then the first of both pins cause the interrupt, the interrupt vector will be entered
now it depends on how your interrupt flag check is made, anyway one of the flags cause entering the measurement routine
but during this time (20us) the other pin change int flasg is still set and waiting.
after finishing the routine it again depends how your backjump is made and if your routine immediatly is able to enter the next one
if a flag is set. This all assumes you have donethe best timeoptimized coding possible.
Anyway you may have a measurement failure on the next int of minimum the complete int lenght (20us)

20us is a hughe time as the allover dif time is only about 1000 us (2ms - 1ms = 1000us) , so 20us is 2%.

for getting rid of big jitter you need a much more faster or more effective controller, or a controller that offers enought capture units or
programmable logic

or you simply don't care about such jitter, as there are a lot of applications where it's not so important, let me say boats :-)

regards,
Walter

AndyKunz

Oct 05, 2007, 08:10 AM

Now think about what happens if two pins changes state at nearly the same time.

Hi Walter,

That's not something you'll have to worry about very much. I have seen three different methods in the RC systems I have worked with for the past 20 years.

1) Analog style - one pin goes high at a time, and the falling edge of one corresponds to the leading edge of another. (Most common)

2) Futaba paired style - as described above, two channels starting at exactly the same time, but they can go down independently (but at 500ns minimum delta).

3) All channels starting at the same time - long, long ago somebody was using a Hitachi with 8 separate PWM outputs. They all started at the same time, but ended independently, with 1us resolution.

Number 1 is far and away the most common (probably 100X more common than Number 2). You can easily use the IOC, CCP, Gated Timer, and INT functions of a PIC to handle this.

Number 2 is handled similarly, but you need to put the paired pins on different interrupts from one another.

Number 3 - I haven't seen this in at least 10 years, so I assume we really don't have to worry about them any more.

Andy

labmaster

Oct 05, 2007, 10:06 AM

Hello Andy.

...
Number 1 is far and away the most common (probably 100X more common than Number 2). You can easily use the IOC, CCP, Gated Timer, and INT functions of a PIC to handle this.

yes, thats easy to handle even with a pic controller.

Number 2 is handled similarly, but you need to put the paired pins on different interrupts from one another.

differnt interrrupts dont change anything, even if they are different they took their time to finish (as i wrote in the last post), so this is no solution.

Number 3 - I haven't seen this in at least 10 years, so I assume we really don't have to worry about them any more.

maybe, but a good design should take care of such things.

also, now you've to think of newer systems like G3 from Futaba (T14, T12) also new 2.4GHz Futaba, JR .... There it's quite common to output the servo signals in Blocks.

..

also you missed one case i've had in past quite a couple of times.

what if different servo signals comes from different sources (like the output of lets say 3 single gyros + one receiver) ?
In this case you've 4 completly asyncronous signals to take care of.

For a good design (that works always with nearly no jitter) you need a very fast controller, togehter with a well designed piece of software or a controller with the hardware built in to have a caputer compare block for each single signal.

I do bitbanging on pic controllers (in assembler) since years now (my job) but this problem was not solvable on a standard pic at least not with my demand on jitter and accuracy. (resolution 1us (10bit) and jitter less than signal resolution)

regards,
Walter

shanghai_fool

Oct 05, 2007, 08:09 PM

Thanks gentlemen,
It looks like the only method to do this reliably is individual capture/compare modules for each channel. I'll have to do more research as so far I can only find chips with 8 ccp modules. To be universal, it would have to have at least 14 channels for the newer radios. Of course, the easiest is just to limit this to ppm type systems. But, I do like my Futaba 9C.

The idea is basicly a black box that would go between receiver and servos. Anything could be in the box. Gyros, accelerometers, other sensors, processing, mixing, etc.

Several people have made devices that do specific things for UAV,s autopilots, etc. I was just trying to come up with a basic building block that would allow whatever needed to be done without modifing a receiver or limiting equipment selection.

Each type can be done independently fairly straight forward but to do them all with precision is difficult. Even the paired type can be done with 2 ccp by muxing the pairs. There is sufficient time between pairs to do this.

I'm still searching.

Donald

shanghai_fool

Oct 06, 2007, 09:12 AM

andrewm1973

Oct 06, 2007, 08:13 PM

Don't use 8 pin change interrupts for the 8 channels.

Use a timer interrupt running at your desired resolution (time wise) and each service check all 8 pins. If one has changed then do something (or if you are using a real CPU pop the value into a stack somewhere to keep the ISR small)

If it is running on a real CPU and your code does not use any other interrupts then the jitter will be very small (1 maybe 2 clocks) which will be orders of magnitude below the resolution.

Does NOT need a fast CPU or 8/14 dedicated input capture units. (8 bit resolution gives you 80 clocks between edge checks on a 20Mhz part)

However you would still consume between 25% and 50% of your CPU power just capturing PPM so if you can afford the weight and expense - using some programmable logic to make 14 Input capture units in hardware would be a good idea.

ilufa

Oct 06, 2007, 10:11 PM

another idea:

use a low end PIC to do all capture/compare task, save the result as 10 bits data and trans those data to another powerful PIC to do whatever you want

maybe another low end to output PWM to servos

shanghai_fool

Oct 06, 2007, 11:44 PM

Thanks guys but what I am attempting to do is a universal interface with any receiver (which, at the moment is up to 14 channels) at at a mininum of 1us resolution and using a mininum of processing time to do the I/O. I want to use a single cpu to minimize parts count and still have enough I/O to bring in other inputs from sensors, A/D converters, etc. And as many servo outputs as possible. Some outputs need much faster updates than the 20 or so per second. As seen from above posts, the inputs can be in a variety of types from sequential to single or multiple blocks. An interrupt driven RTOS is the most effective and efficient way to do this.

In my current project, I have 3 gyros, 3 Vtail mixers, 2 Microloggers and 14 servos. And there is more I would like to do.

I have read through this and other forums and there are many projects that are very complex and very interesting but all have some limitation with channels, tx systems or abilities. Most were designed with a very specific task in mind do that task very well. If you need to do additional functions, you have to add another block of electronics. I am researching to see if there is a way to simplify and correlate any or all of these various functions into a single building block. It all starts with the ability to receive inputs from receiver and other sensors and output to servos or other devices. It should have enough computing power to do anything in between without needing a 50 watt power supply. Remember speed=power.

There are a lot of people in these forums that are a lot smarter than me so I'm trying to get some input and direction. The hardest part is starting with a clean sheet of paper and deciding which to do first. I am trying to select the best platform to start with that has the least limitations. Maybe its an impossible task but it only costs time to try. The computing power is cheap but the programming is very time expensive so simplicity has to be weighed in also.

This is a non-commercial venture so any infomation gathered here will be free to all.

vintage1

Oct 07, 2007, 06:35 AM

shanghai_fool

Oct 07, 2007, 08:16 AM

I think polling at 1us interval is a little too much but I'll have to delve more into what the ARM has to do in an interrupt to see if it can be accomplished with a 48MHz clock. Thats only 5 mips so it may not be able to do it either. Although I can handle multiple changes on the same service routine, I probably couldn't handle 2 spaced 1-2 us apart and maintain resolution. I know my 9C has 5us steps for trims and I can detect that in a servo or ESC so I know I have to have better resolution than that. Only the PCM can change that quickly if the 2 channels end at close to the same time. I don't know about the others that may do more than 2 channels at a time. For PPM, except for the first and last, all others will change 2 at a time.

Yes, I would rather have an FPGA but thats beyond my abilities. Maybe this is too but I want to try it anyway. I can do things in asm but C is not my strong suit. Never too old to learn though, just slower.

andrewm1973

Oct 07, 2007, 06:22 PM

Its easy enough to work out which method - interrupt on change, or interrupt on timer, is the most processor efficient.

I'd sketch out both and see..but I won;t. My time of adding up clock cycles on assembly code is hopefully over ;)

The int on pin change will always win the "less CPU usage" race.

However it has variable latency and some other complications.

The Timer service int is a waste of CPU cycles but gives predictable results and less headaches.

I would not do it that way either now reading that the orginal poster wants 1uS resolution. It is 1/2 sensible at 8bits on a PPM signal (4uS). At 1uS it would use over 80% of a 20Mhz AVRs power to do 16 inputs. (and be undoable on a 20Mhz PIC)

I don't think an ARM running at 4 times the speed trying to use some C code and someone else RTOS is going to have much more fun doing it by poling or Interrupts.

Def go external hardware. Maybe programmable logic - maybe external CPU.

I would say that 2 x external 8 bit CPUs each doing 8 PPM inputs could win the size,cost and ease competition - even if it was not as "cool" as a CPLD or FPGA.

shanghai_fool

Oct 07, 2007, 07:05 PM

I'm hoping to pick up a device today and try some things. It been a week long holiday here. The chip cost is irrevelant as they are about $15.
Now for the logic:

Case 1 PPM no problem. Single interrupt at 1ms or greater.

Case 2 PCM Possible. paired pulses start at same time, no problem there. I can handle first pulse end in a mininum of instructions. I have plenty of time after getting second pulse. I just have to see what I have to stash to service the first pulse end. Hopefully just push a couple of registers , save counter to memory, pop registers and return.

Case 3 - Multiple pulse blocks. Just depends on what I can get done in 1 us.

I do not know what the output format is for the newer 14 channel systems are. maybe someone who has one can give me a clue. I have a 9C (paired pulses) to test with.

AndyKunz

Oct 08, 2007, 01:22 PM

Thanks to Andy for some good info in another thread. It looks like the ARM AT91SAM7A3 is probably the best bet for a universal interface. Unfortunately, although I have development tools for the PIC, I do not have anything for the ARM and that one in particular. Is there anything you could recommend?

Atmel makes several chips with a built-in USB bootloader. I used the AT91SAM7X512 on my project (the 256 is more mature - use it instead). The dev tools were a free download of the GCC compiler used with CygWin, or you could use the WinARM compiler (also free).

Your total dev tool investment will be one standard USB cable, and some time to download the tools. The only reqt put on you is to use the correct xtal for USB (18.432MHz).

The different ARM vendors each use their own I/O modules. The Atmel one is, from what I saw, best for the kind of project being discussed in this thread.

You can do an AWFUL LOT of work at 50MHz (the Atmel's PLL lets you run the micro much faster than the 18MHz input frequency).

Andy

shanghai_fool

Oct 09, 2007, 02:51 AM

I went shopping for parts today but found nothing available I could use. They don't stock the Atmel parts so small quantities are not available in the mom & pop distributers. They only order for quantity purchase. The only development boards are for the Philips chips. I really need to test the interrupt routine first to see what the mininum time will be. I will pick up parts in 2 weeks on my US visit. Thank goodness for Digikey. I'll play around with finding and using a sim to learn the syntax and asm structure.

MatC

Oct 10, 2007, 06:19 AM

Donald:
I'm working on a PPM/PWM mixer at the moment too, and want mine similarly universal (although mine is much simpler than what you are building). I've come across the same issues with interrupts, and have realised that CCP inputs are the best way forward if you have to process more than one thing at once. I've cheated for mine and added an extra PPM output to my receiver.

- Have you considered using several microcontrollers linked together? Work out the most channels per buck you can process, and then have each input processor output a more microcontroller friendly encoding [eg i2c or roll your own]. Outputting 10 bits in 1/50 second ain't too tough...
- Which chip are you using that has 8 CCP modules?
- The ARM processors run at upwards of 50 MHz, and I believe it is one instruction per clock cycle. sparkfun and/or futurlec stock nice modules.
- The ultimate solution would be an FPGA to handle the inputs, outputs and low level mixing. As many CCP modules as you want that way :)
Mat

shanghai_fool

Oct 10, 2007, 12:21 PM

Mat,
I haven't picked a chip yet although I gave the ARM AT91SAM7A3 the best score. But even at 50 MHz, I don't think it can service an interrupt and maintain 1us accuracy. It takes a lot of houskeeping just to do the interrupt service in addition to reading the timer and stashing it. You have to make sure its only 1 interrupt pin and stash it where it supposed to go. It may be possible to do with a paired channel system but not for multiple channels ending at close to the same time. Same starting times are no problem.

I'm looking at other solutions for the I/O problem. The CPU part is no problem at this point.

Donald

andrewm1973

Oct 10, 2007, 06:38 PM

ShanghaiFool,

There are Atmel parts (and I am sure other companies) that have ARM cores with FPGAs tacked on. They are most often BGA parts though if that is a problem for you.

Else - go back to the idea of an external logic chip or co-processors.

shanghai_fool

Oct 10, 2007, 09:18 PM

My problem is I know nothing about how to program FPGA's or CPLD's.I am doing some research into them though.

I have no problem with co-processors as I intend to use a FP math co as well. I could not find an I/O logic chip that would handle the input. The SD21 could handle the output. If you now have a separate input processor, that makes 4 which makes for larger and more expensive solution. I will take another look at the other Atmel parts. I missed the one with co-FPGA's.
Thanks
Donald

shanghai_fool

Oct 12, 2007, 09:56 PM

OK, I've looked at FPGA's and its way over my head. I'm sure it can be done but not very quickly by me. So far, the only 1 cpu chip solution I've come up with is the AT91SAM7A3 with its 62 I/O pins. I can get up to 14 inputs (with IOC) and at least 19 servo outputs depending upon tradeoffs.
The literature I've read states the mininum latency for interrupts is 5 instructions and the max is 25 or .7usec. so it looks like its possible. Now, thats just for servicing the interrupt, not for doing anything useful. The very mininum we have to do is save 2 registers (32 bit) read the input port (32 bits) to 1 register and read the counter (16 bits) into a second register. At this point, we could re-enable the interrupts because the next one will do the same thing. So now we have the information we need stashed in a last-in-first-out (LIFO) basis. My question to the genius's out there is: What is the simplest elegant method for figuring out which bits have changed so we can stash the counters at the right places? Remember, we can have multiple bits change at the same time. The real stashes are linear with the bits so we need to work with a single bit at a time. In other words, The data now is in registers (in the stack) and we need to stash them in memory locations so other parts of the program can work with them in the user part of the program. I can do this with brute force and dozens of rotate and compare's but I'm looking for a more elegant solution.

The hard part is figuring out which bits have changed in reverse order. Any ideas?

Maybe I need to do a little more inside the minimum interrupt service. Until I get a real processor to test with, I don't know what I can get away with in 1 us. There is a little housekeeping involved with this cpu like adding 4 to the return address, reading/setting ports to clear interrupt flags, saving registers being used, etc.

shanghai_fool

Oct 13, 2007, 01:25 AM

also you missed one case i've had in past quite a couple of times.

what if different servo signals comes from different sources (like the output of lets say 3 single gyros + one receiver) ?
In this case you've 4 completly asyncronous signals to take care of.
regards,
Walter
Walter, I've been thinking about this and did some tests.
First, my idea is to pass ALL receiver outputs through this which means that I can detect the entire stream. Gyros do not have an output unless they have an input pulse. That means you have to use 1 of the device outputs to drive it. That's ok. During the initialization process, I plan to detect how many channels are giving pulses and whether they are single or multiple. I can then turn on the outputs to drive the servos and gyros. The gyro output will then be in sync. The actual mixing of the gyro is done in the main program to whatever channel or channels you want. I do plan on have gyros on board or at least a place to put them. They are much cheaper as chips than commercially available packages.

Second, if you do put the gyro in series with the receiver, the output is still synchronous as it outputs a pulse at the same rate as the input.

MatC

Oct 13, 2007, 07:31 AM

maxvtol

Oct 13, 2007, 08:16 AM

Second, if you do put the gyro in series with the receiver, the output is still synchronous as it outputs a pulse at the same rate as the input.

If you use a Futaba GY401 in the digital mode, you put 40 or 50hz in and get 270hz out. This is desired if you want a faster response rate.

shanghai_fool

Oct 13, 2007, 09:12 AM

My thinking on this (I'm familiar with PICs, so will think in terms of those) is to use small devices as input translators (12F509 and interrupt-on-change [and suffer the 1cycle jitter] or 12F683 with its CCP module). Get these to output the signal in a nice easy to read way at around 1-10 KHz, easy as pie to read in the background from the main processor, which can do the mixing and output too.
If you use say a 16F877/873 part you get 2 CCP modules, then with 6 input translators you've got a sensible system that handles 8 independent inputs.
Mat,
12F509 only has 4 IOC pins RB0/GP0, RB1/GP1, RB3/GP3 and RB4 and no 16 bit counter.
12F683 has 6 IOC + 1 CCP.
16F877 also only has 4 IOC pins.

Even then you have to figure out which one changed and save the counter faster than another interrupt comes in. The pic is just not fast enough to handle blocks of multiple channels. Also I want at least 14 channel capability.

If you use a Futaba GY401 in the digital mode, you put 40 or 50hz in and get 270hz out. This is desired if you want a faster response rate.

You are correct Joe and I just checked and its output is also asynchronous even in normal mode. I'll give this some thought. I'm still working on the interrupt routine and it may be able to handle it. Thats 3.7ms apart.

JimDrew

Oct 13, 2007, 11:34 AM

The easiest solution is to do what we did. Either use an 8 channel scope or logic analyzer, or an expensive solution that works perfectly for what you want to do:

http://www.hobbylab.us/USBOscilloscope/Home.htm

MatC

Oct 13, 2007, 12:30 PM

shanghai:
12F509 would only need 2 IO pins - one for the input, one for the output. You would use one '509 for each extra input signal you want to measure. The SMD versions are really quite small and cheap though. You don't need a 16 bit counter, you can easily cope with the 8bit counter and track when to update it. You've still got 1 cycle jitter on interrupt though (depending what instr was executing as the interrupt happened).

16F877 has only 2 CCP pins anyway, I don't like 4 way IOC any more than you do.

14 channels.... ok, that's horrid having 12 additional IO chips :\

MatC

Oct 13, 2007, 05:35 PM

There is one more possibility I can think of, from "wild and crazy ideas ltd", and that is to use the ADC module. Sampling/interrupt on the inputs as usual, but also take the signal through a resistor/capacitor to the ADC inputs.
If you arrange the slope correctly (can calibrate in software), you should be able to see how long ago the input changed, to within a microsecond or perhaps a little better. You'll need to take into account the final voltage level and hope that the incoming slope is sharp, but it might work :)

kbosak

Nov 18, 2007, 06:20 AM

OK so let's make a summary for foolproof approach, labmaster.
I am a scientific soft. devel. but recently I worked on RT OS (eCos) in a private company and I understand that you understand the importance of jitter here.
I find your advises about polling to be very wise, calculation of cycles to be perfectly professional and I find the other proposals about sticking to interrupts as a little naive - the interrupt-on-change-level-based handling is exactly what FMA Co-pilot uses and is the reason why ot fails to cooperate with PCM futabas - look at Servo buffer/level shifting thread.

PROBLEM
To add my 2cents, I have spotted that the jitter becomes more pronounced when servo is moving, using fast servos (you can hear things when moving Hitec HS-81 powered at 6V power when polling under 16MHz ChocaPIC16F877, bknd CC5X compiler - free so no optimization).

So my idea is to:
SCENARIO 1:
-stick with bknd CC5X free (assembler is full of pitfalls on each new platform), 220USD personal or 350USD pro license out of question at the moment
-use a pair of PICs, 16 i/o, 8 digital inputs and 8 analog outputs each, getting PWM, sending stupid analog, noisy but at least white noise no jitter. I must use only really minimalist IRQ routines - no state machines for main loop at all!
-one 16F877 for assembling those 16 analogs and putting them to an external eeprom chip (data logging or whatever)

SCENARIO 2:
-move to bknd CC8E free (assembler is full of pitfalls on each new platform), 220USD personal or 350USD again too high, so 1KB code limit applies, supports 18-series chips that have PLL that boosts operational MHz to 40.
-use similar hardware as in scenario 1 but to use 40MHz internal clock input PICs
-opt for changing 16F877 to something similar of 18 series, as CC8E only supports 18 series chips

Not only moving to 18 seris will allow to use 40MHz, but also
"The CC8E C compiler supports all new PIC18 instructions and generates optimized code." overall I suppose less code (soem 10%?), and less jitter. This could be naive as <<free>> CC8E is not optimizing.

QUESTIONS:
a. Do you have some advises for the choice of the PIC chips and on the approach?
b. I am starting to doubt in PICs, shouldn't I switch to AVR because:
-for fast hobbyist development I need C languagem given the headaches with manual paging etc.
-AVRs appear to scale easier (smoother than PICs) above 1k of the code, because free bknd compilers for PICs have limit to 1KB of code (it shrinks so fast in my project :eek:) and because of paging everywhere
-AVR have totally free gcc (this is maybe why AVR dominates 90% of hobby market in Poland - a truly free and unlimited C compiler, as it looks from distance).
My initial planning was to use a big guy with RTOS (PC/104 x86 100...133MHz, 5W power cons.) for autopilot and microcontrollers for even more time-critical tasks, datalogging, sensor handling and at most linear filtering (floating point at microcontrollers stinks I think).
Because of the jitter, fast MHz and predictable runtimes, flat instruction set was more important for microcontrollers in this plan, so I choose PICs. However now I see that I will have to add very soon 220USD for bknd compiler or operate under uncomfortable 1KB limit.
The only thing is stopping me from AVR is:
-shops with AVR open tomorrow (they can sell beer, shops operate, but why the hell they cannot sell chips on sunday :confused: )
-AVR appear to have smaller MHz, uneven clock cycles per instruction, gcc is known for fantastic C++ and C-level optimisations, excellent x86 ASM opt since the year 2002 only, but I don't think gcc's optimiser will be very efficient at low level assembler for PICs (it took them ages even for x86 they were lagging in assembler level opts behind everything until the recent times, now they excel).
This all means that the jittering in AVR when using gcc might be more pronounced. ASM programming out of question - once again boring time eater. I would rather learn FPGA tech.

I think the only pro way to go would be FPGA, but I know how it looks in hi-tech company and what are the costs of the software + learning curve so... Another day.

kbosak

Nov 18, 2007, 07:25 AM

Atmel makes several chips with a built-in USB bootloader. I used the AT91SAM7X512 on my project (the 256 is more mature - use it instead). The dev tools were a free download of the GCC compiler used with CygWin, or you could use the WinARM compiler (also free).

FYI,
AT91SAM7X512 is in sampling status (pre-production)
while
AT91SAM7X256 is in production,
14USD unitary pricing at mouser. nice price.

AT91SAM7A3 is some 17USD,
yet AT91SAM7A3-EK devkit is some 240USD @ mouser, quite out-of budget considering its hobby use.

At the same time one can get 16F877 devkits flying around on ebay or even in a grocery for a tiny 40USD. I would like to start using those atmels, yet it could be difficult to adapt to them. Where to start? Some forum, webpage, cheap devkit+sampleboard+programmer (but must be fully functional)?

andrewm1973

Nov 18, 2007, 07:29 AM

-AVR appear to have smaller MHz, uneven clock cycles per instruction

AVRs do more per MHz than PIC. They do not have the 4 phase clock of the PIC so one-clock = one-instruction except for branch (and 16 bit ops).

This means a 20Mhz AVR does as many instructions as a 80Mhz PIC would.

kbosak

Nov 18, 2007, 07:50 AM

AVRs do more per MHz than PIC. They do not have the 4 phase clock of the PIC so one-clock = one-instruction except for branch (and 16 bit ops).

This means a 20Mhz AVR does as many instructions as a 80Mhz PIC would.
So let's face it: the only reason to stay with PIC 10, 12, 16 or 18 and not to switch to AVR is based on its popularity, habits, small number of ASM instructions (easier to learn to do inlines?) and that the PIC10F series is exceptionally small?
So far everything tells me that for the task in this thread the atmels AT91SAM7A3 mentioned would be perfect if not the cost of devkits and small availability, and AVRs appear to be superior than PIC because of free gcc (as opposed to bknd) and not-worse-than-PIC efficiency (we are hobbyists for the moment, let's talk about grocery chips here, not some exotic flagship chips)?

kbosak

Nov 18, 2007, 08:07 AM

AVRs do more per MHz than PIC. They do not have the 4 phase clock of the PIC so one-clock = one-instruction except for branch (and 16 bit ops).
AFAIK (read on the other forum)
PIC 18 have PLL, 4x10 gives 40MHz, there are some rated at 48MHz.
PIC 24 have 16 bits.
one-clock = one-instruction except for branch is exactly what is written in 16F87xx midrange refman among the first lines. If it holds as plain as it says (without tiny letter text in the bottom of the page) PIC and AVR are equally RISCy.

Both of them are already discutable because of limited availability (the largest beast PIC for hobbyists available immediately in 800.000 populated city (4th in Poland) is 16F877A, so midrange, let's compare apples to apples. PIC 18s are in 1 week deliv. on local ebay, everything above is random bigger hunting at distributors that neglect small series and hobbyists).

The same applies to French cicites as far as I remember so we can assume this is european market conditions for Europeans (in Germany or UK it could be occasionally better in some regions). So when talkin about hobbyist use we are at midrange chips, not over it.
When we talk about a part that I have to order, I would rather order a perfect solution like AT91xxxxx with 8PWM inputs or so and wait a month or so.
So let's be sure we don't start bidding AVR vs PIC. I know the differences for the task are tiny and both are insufficient in that they do not have 8 (not to mention 14) PWM inputs. They are considered as best solutions just because of availability and guaranteed low price of programmers and devboards (f.ex PIC 60USD full off timers, digit LCD, pixel LCD, diodes, buzzer, USB port, 2 relays, potentiometers, RS232, RS485, wireless 468MHz, temperature Dallas, RT clock, external EEPROM chip, IR port, SD card, all with demo software in ASM with 18F877 included and God knows what else that I havent read in the manual).

kbosak

Nov 18, 2007, 08:41 AM

Does NOT need a fast CPU or 8/14 dedicated input capture units. (8 bit resolution gives you 80 clocks between edge checks on a 20Mhz part)

This one is discutable. TX gives 10 bit precision. Suppose you want to make RELIABLE PCM failsafe buzzer. This means once all signals stand still, make a beep. The problem is, to prevent false alarms, you need those 10 bits.

More, if you are making your own F/S system (maybe coupling Co-pilot to OSD to GPS to whatever) you need this resolution,since if you want to connect servo travel from FMA co-pilot, refilter it and add another stabilization idea, you need 10bit or the PID feedbacks will oscillate very easily.

I you have FPV system you want to govern tilt/pan camera smoothly. With a servo travel stretched from -45...45deg to -90...90deg, 256 possibilities makes granularity of 0,70degrees. Connect this to pan servo and jumpy camera movement guaranteed.

At the end, while 8bits look almost smooth on the graph ('smooth enough' for most people), they don't look that smooth when you make a derivative of it (we are truncating or rather 'jittering out', not rounding 2 bits). However the derivative is what is sensed by analog logic inside the servo (PID controller in faster servos, PI in slower models). This adds servo jitering around null position, particularly during movement.

shanghai_fool

Nov 18, 2007, 07:06 PM

I am using the Atmel 7A3 and using interrupts and at 48MHz, it seems to handle the PCM and PWM pulses nicely. I cannot see any appreciable difference between input and output pulse widths even on pulses that end at nearly the same time. The 256k and 512k units, although having more memory, suffer from not enough I/O pins to fully utilize the internal peripherials. Yes, the development board is pricy but the other tools are free. Don't forget you also need a programmer. I also got the SAM-ICE because it works well and is plug 'n play with the development board. It is much more difficult to program though. Not nearly in the same realm as the Pics or AVR. Almost all the programming is done in C++. Only the startup code and interrupts use assembly and those routines are provided.

The Atmel solution was also the only one I found that could give me more than 8 interrupt on change inputs. I wanted 14 to be usable with ANY system currently available.

Also the 8 PWM's available are outputs, not inputs. It does have an additional 9 internal timers that can be used for either capture inputs or PWM outputs although you will probably be using most of them for other purposes.

As far as resoultion goes, with the Futaba 9C, the trims change about 5us which are almost non perceptable in analog servos. I don't have a digital servo to test with. I did most of my testing with a Polulu 8 servo controller that has .5us steps and sometimes the interrupt routine would vary + or - 1 us from the input. That may also be due to the 25MHz digital scope I am using.

I am working on finishing up the board design so I can get some proto boards made. I don't want to have to buy a PCB design software package just for this 1 project. They are only "free" for 30 days. Yes, there are free pcb design programs and they are worth every penny you pay. ( I know, as I just tried 2 of them and wasted time as I had to re-input the schematic on each one). They just don't have the capability of the good ones.

So, how does this sound for a "do anything" board?
14 channel inputs, 14 servo outputs, 15 buffered A/D inputs, MMC/SD memory card, 2 UART serial ports, both I2C and SPI serial (for adding more servos or other stuff), 4 brushless RPM mesuring inputs and maybe 1 other secret function. All on 1 board. Also with a mating daughterboard with the air pressure sensors for altitude and air speed, gyros and GPS. The cost should be low. The parts are not that much and the pcb is cheap. Its the SMD assembly that may kill me.

Stay tuned.

Donald

andrewm1973

Nov 18, 2007, 07:23 PM

one-clock = one-instruction except for branch is exactly what is written in 16F87xx midrange refman among the first lines. If it holds as plain as it says (without tiny letter text in the bottom of the page) PIC and AVR are equally RISCy.

The PIC are One instruction per SYSTEM clock not the input clock.

The input clock is divided by 4 so a 48Mhz crystal on a PIC is actualy a 12Mhz system clock. At least that is the way 16F and 12Fs used to be.

maxvtol

Nov 18, 2007, 09:55 PM

So, how does this sound for a "do anything" board?
14 channel inputs, 14 servo outputs, I'll put my order in for 18 servo outputs, since I need 16 now. The only thing I can think I might want to add at some point in the future is pan and tilt for a camera.

I'm sure that affects the pin count, so I would choose fewer input channels. I can't see how you would need 14 inputs to be mixed onboard, since the only radio capable of 14 channels has very sophisticated mixing already. You could just put the inputs into this mixer that need to be mixed onboard, then run the rest of the servos directly off the receiver. I really can't see how you would need more than 10 inputs mixed onboard.

Can one of the input channels handle a PPM signal from a hacked Rx?

AndyKunz

Nov 19, 2007, 12:35 PM

The PIC are One instruction per SYSTEM clock not the input clock.

The input clock is divided by 4 so a 48Mhz crystal on a PIC is actualy a 12Mhz system clock. At least that is the way 16F and 12Fs used to be.

"Used to be" is correct. Many of the newer parts have PLLs that will allow you to run with a 4MHz xtal providing 48MHz to the internals. Take an especially close look at the Full Speed USB parts.

Andy

andrewm1973

Nov 19, 2007, 03:53 PM

I just looked through microchips site at most the Full Speed USB parts (18F24x and 18F25x). A 48Mhz PLL clock is still only 12M instructions. The input clock is 48Mhz (from either a PLL or direct input) and the system clock is 12Mhz (4 phases dervied from 48Mhz).

So not even taking into account that an AVR can usually get more done per MIP - a 20Mhz AVR (20 MIPS) part is alread faster than a 48Mhz PIC (12 MIPS).

Even looking through the parametric product listing the quickest thing I saw was 16 MIPS which is slower than a 20Mhz AVR part.

rmteo

Nov 19, 2007, 05:15 PM

Did you check out the PIC32 here:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2607

Good for 110MIPS at 72Mhz. ;)

andrewm1973

Nov 19, 2007, 05:50 PM

jeffs555

Nov 19, 2007, 06:51 PM

Did you check out the PIC32 here:
http://www.microchip.com/stellent/i...AGE&nodeId=2607

Good for 110MIPS at 72Mhz.

That is 110 DMIPS and the AVR32 claims 210 DMIPS. However, DMIPS (ie Drystone MIPS) is just a benchmark, and like most benchmarks has several versions and is not necessarily predictive of real world performance.

I also agree that with the proliferation of cheap ARM7s from just about every chipmaker, and the open source GCC tools, the ARM7 is a much better choice for the hobbyist that needs the horspower of a 32 bit processor.

AndyKunz

Nov 20, 2007, 07:40 AM

I also don't think there are many compelling reasons to use either a PIC32 or an AVR32 over the defacto industry standard ARM core for most generic applications.

Which ARM is "standard"? ARM4, 5, 7, 9, or 11? Isn't there a 13 out there now too? With or without Thumb?

ARM is no different than Microchip or Atmel's AVR - they look the same (or reasonably similar) at one level but at another are very different.

The PIC32 is based upon MIPS 4000, and it has the advantage of being able to have custom instructions, something that ARM lacks. MIPS is another industry standard, in case you haven't noticed.

I make my living developing on both ARM7 and PIC 8/16-bit platforms. Each has its place, but if I had a 32-bit PIC with 512K flash and MII two years ago my products wouldn't be using ARM today. While the Atmel SAM7X has a great peripheral suite, the ability to use the same peripheral libraries on my 16/32 bit stuff is pretty handy (oh wait, that's another claim of the AVR groupies...)

Well maybe things aren't quite as different among vendors as their adherents believe...

Andy

andrewm1973

Nov 20, 2007, 08:23 AM

Give me an M
give me an I
give me a C
give me an R
give me an O
give me a C
give me a H
give me an I
give me a P

Lets have a big hand for the microchip cheer squad :D

Its rather factitious to mention ARM 4 or 5 and probably even 11 when talking stand alone MCUs. ARM7 and 9 are it are they not.

I actually hadn't noticed MIPs was an industry standard in MCUs. Pretty standard in playstations but probably 1/10th the vendors in MCUs than ARM.

Anyways - I don't have an inherint dislike of PIC32s. They are probably quite adequate. AVR32s are probably quite adequate as well. I just see no great reason for choosing either of them over an ARM for most things.

It's only the PIC 8 bit chips I am not fond of. Price is about the only thing I think they have going for them. That lack of registers makes it just like using an 8051 with less instructions. At least some 8051s these days have a single phase system clock so they are not being misleading when they quote the chips speeds.

I guess if I sold PIC development systems and compilers I would be more fond of them.

AndyKunz

Nov 20, 2007, 01:10 PM

Its rather factitious to mention ARM 4 or 5 and probably even 11 when talking stand alone MCUs. ARM7 and 9 are it are they not.

Depends on what you're doing. You can still buy 4 & 5 chips, and you really do want an 11 if you're doing something really hot. Sorry I forget Cortex.

I actually hadn't noticed MIPs was an industry standard in MCUs. Pretty standard in playstations but probably 1/10th the vendors in MCUs than ARM.

They just don't advertise as much, I think. Nothing like patting yourself on the back all the time.

It's only the PIC 8 bit chips I am not fond of. Price is about the only thing I think they have going for them. That lack of registers makes it just like using an 8051 with less instructions.

An 8051 has more registers in it, and lots of Mots do too. Why is Microchip #1 in 8 bits? Apparently the number of registers isn't that important...

I guess if I sold PIC development systems and compilers I would be more fond of them.

Yeah, me too! I would never even have to think about other vendors.

Andy

PS - The PIC24/dsPIC33 and PIC32 compilers are GCC-based.

andrewm1973

Nov 20, 2007, 04:42 PM

Why is Microchip #1 in 8 bits? Apparently the number of registers isn't that important...

Hepatits-B is #1 in its field. Doesn't mean I want it. But I would think that the real reasons PICs might be number one is one thing I mentioned earlier.

Price

They are the cheapest in small sizes. If you are making 2 million of something then every cent counts.

Us hobbiest are not making 2 million of anything so that metric is of lesser value. I would prefer to spend 20 cents more on the chip and have a little more ease of use.

AndyKunz

Nov 21, 2007, 07:49 AM

We hobbyists (yes, I do it for a hobby too) don't mind solving difficult problems with minimal resources. It's how I got into engineering in the first place - I like to find better ways to accomplish the same with less.

Microchip enjoys a profit margin significantly better than other chip vendors, include Atmel. Why is there so much happening in the legal world with Atmel? Because they're on a tight rope!

Andy

kbosak

Nov 28, 2007, 11:55 AM

I don't think that is comparing apples with apples.

Neither the PIC32 or the AVR32 are realy the same chips as the 8bit PIC/AVR apart from the name for markeing reasons. I also don't think there are many compelling reasons to use either a PIC32 or an AVR32 over the defacto industry standard ARM core for most generic applications.
The reason is the price of hardware programmer and that in case of hitech frenzy I can visit nearby shop for students and grab a dozen of PIC16F877 or ATMEGA162 (which has 6PPM modules as I discovered).

Alan Hopper

Nov 28, 2007, 11:58 AM

Just a thought for decoding Futaba pcm 1024 receiver outputs. If these receivers output two channels at once every 14.25 ms , one of them is probably just a duplicate of the previous value as pcm1204 only sends a new value for each channel every 28.5 ms so you could capture them alternately without loosing information. You might have to do some magic to work out which has the most recent info, to minimise latency. Alternately just capture the pcm stream and decode on your processor
Alan

shanghai_fool

Dec 01, 2007, 08:26 PM

The Futaba 9C outputs pulses in pairs because there is no enough time in 15ms to do more than 6 or so like PPM. They are not duplicates. Channels 1 & 2 start at the same time as do 3 & 4 and so on. Therein lies the problem. The channels can end differently as close as 5us. Thats the mininum I could get just moving the trim 1 beep.

That means you have 5 us to service the interrupt to get back in time to detect the ending of the second pulse. With the Atmel 7 series running at a 48mHz system clock, you only have time for 15 instructions. I don't know where the RISC comes in because it takes 20 instructions just to handle the interrupt NOT including doing anything useful. I could do that in 10 non RISC instructions on an 8085 but of course it wasn't running at 48 mHz.

This will cause a glitch in the longer channel but only at the 5us difference. More difference than that will not cause a problem. I have set up a test rig to verify this and although I can't feel the servo move with my hand, I can see it on the jig.

The jig is very useful for detecting any glitches. I mounted 2 servos on a 4"x7" panel and mounted 8" long wires to the servo output arms. You can definitely see the glitch at 5us. This is using generic analog servos.

I am not sure I can reduce the interrupt to 5us or less. I don't know enough asm for the ARM to be sure. I only have to store 3 values during the interrupt and raise a flag. Everything else could be done by polling the flag. The 3 values are the current period counter value, the bits that have changed ( there can be more than 1) and the current state of the bits.

I think I will need some outside expertise to fix this as I am not sure what instructions I can reduce at this point.

Donald

PS. I hope I can solve this as I have ordered 10 boards which will be here this week.

shanghai_fool

Dec 02, 2007, 12:33 AM

Is it possible to use Force-Fast interrupt in this instance? The code for servicing this is 10 instructions + the code for actually doing something. This doesn't require writing the EOICR to renable interrupts so I'm not sure at what point this could be made re-entrant.
;------------------------------------------------------------------------------
;- Function : FIQ_Handler_Entry
;- Treatments : FIQ Controller Interrupt Handler.
;- Called Functions : AIC_FVR[interrupt]
;------------------------------------------------------------------------------

FIQ_Handler_Entry:

;- Switch in SVC/User Mode to allow User Stack access for C code
; because the FIQ is not yet acknowledged

;- Save and r0 in FIQ_Register
mov r9,r0
ldr r0 , [r8, #AIC_FVR]
msr CPSR_c,#I_BIT | F_BIT | ARM_MODE_SVC

;- Save scratch/used registers and LR in User Stack
stmfd sp!, { r1-r3, r12, lr}

;- Branch to the routine pointed by the AIC_FVR
mov r14, pc
bx r0

;- Restore scratch/used registers and LR from User Stack
ldmia sp!, { r1-r3, r12, lr}

;- Leave Interrupts disabled and switch back in FIQ mode
msr CPSR_c, #I_BIT | F_BIT | ARM_MODE_FIQ

;- Restore the R0 ARM_MODE_SVC register
mov r0,r9

;- Restore the Program Counter using the LR_fiq directly in the PC
subs pc,lr,#4

----------------------------------------------------------------------
I am working on the asm code to stash the data I need. Do I still need to branch to the AIC vector?

Experts needed!!!!

Donald

kbosak

Dec 02, 2007, 08:57 AM

Just a thought for decoding Futaba pcm 1024 receiver outputs. If these receivers output two channels at once every 14.25 ms , one of them is probably just a duplicate of the previous value as pcm1204 only sends a new value for each channel every 28.5 ms so
speculative analysis all wrong.
every 14.25ms there are fresh data, half channels got full update and another half takes partial update. after 28.5ms everything is fresh even in one of the channels experienced 'full stroke' (a switch). however for general flying under quite mild assumptions the expected update rate for all channels is 14.25ms inside the receiver. that the output to the servos has different refresh rate is another story.

[WHOPS recent finding indicate this data is wrong: the update rate is indeed 28.5ms, everythin looks fine just the time scale for PCM1024 has to be multiplied by 2]

kbosak

Dec 02, 2007, 09:02 AM

There is something really ugly in decoding PWM when we want to decode it with 'professional quality'. We are looking around 60MHz ARM7 now and this is still not a piece of cake. I went the way through PIC16F877@20MHz, moved to ATMEGA162@16MHz (still glitching) now looking at ARM7 devkit - everytime I got ino obvious evidence that the tool is not suited for the putpose because of some intrinsic programming or timing quirks. That's amazing that seemingly :censored: simple problem calls so loudly for curstom hardware (FPGA or CPLD). For me everything started when I have spotted that FMA Co-pilot glitches like hell until I delay one of the channels by serious 2ms.

Alan Hopper

Dec 02, 2007, 10:06 AM

There is a degree of misinformation on the web about pcm1024. I can assure you, that having just successfully written code to decode pcm1024, there is only new data every 28.5 ms.

see among others
http://www.flightsense.nl/pcm1024/docs/pcm1024_signal_analyzed.pdf

190 bits holds 4 absolute values and 4 delta values
each bit takes 150us ie 28.5 ms

I don't know about pcm2048 but for pcm1024 comming out of my 6exa transmitter there is only new data per channel every 28.5 ms

kbosak

Dec 02, 2007, 01:43 PM

There is a degree of misinformation on the web about pcm1024. I can assure you, that having just successfully written code to decode pcm1024, there is only new data every 28.5 ms.

see among others
http://www.flightsense.nl/pcm1024/docs/pcm1024_signal_analyzed.pdf

Agree.
The document you have shown clearly indicates that with data rate 6666bps,
190 bits=half frame takes 28.5ms. This half frame indeed contains for half of the channels the full data and for half of channels delta data.
The attachment I have posted is therefore wrong, suggesting 2x higher update rate.

Thank you for sharing, I haven't had time to re-verify everything I read with oscilloscope. Oh I was naive.

JimDrew

Dec 02, 2007, 09:52 PM

I know for fact that you can easily decode the PCM datastream with a 4MHz PIC. This holds true for Futaba PCM (such as Alan shows) as well as JR's and Airtronic's versions. It only requires a single capture/compare register and an interrupt handler. We have been doing this to get 250ns resolution using a 16MHz PIC with our PPM pulse capture for the XtremeLink system since day one.

Alan is correct about the frame rate being 28.5ms for new data. The data is 10 bits per channel (1024) and the frequency is about 35 times per second. It's pretty easy to see why PPM with our system being 16 bits per channel (65536) with a frequency of about 44 times per second, is much more responsive than any PCM system.

BTW, nice job Alan on the reverse engineering. You have actually discovered a few things related to the parity that I did not see when I dumped the PCM data stream with the logic analyzer. I spent a fare amount of time working on this same thing with the idea of supporting PCM modes with the XtremeLink, but the difference in response speed is so dramatic I felt that it was a waste of time.

teamdavey

Dec 02, 2007, 10:27 PM

250 nsec resolution = 12 bit not 16.

Alan Hopper

Dec 03, 2007, 04:26 AM

Jim,
I cannot take credit for the reverse enginering, I am neither of the people in the link. My challenge was making it all fit in the 1k available on the Hitec hfs-05 receiver that I have reprogrammed.

kbosak,
It took me a little while to twig that the 14.25ms folklore did not tie up with the code I was writting!

In my current project I am running all my code on the receiver but my plan for my next more complex project is to decode pcm or ppm on the receiver and send it out as serial data to a bigger processor. Jim maybe a serial data output from your receiver would appeal to some people here.

shanghai_fool

Dec 03, 2007, 08:22 PM

The Atmel 7A3 can do the dual pulse PCM by using IOC pins on odd channels and CCP on the even channels but you give up some of the A/D channels and tie up lots of the 9 available counters. I don't know if there are any systems that are using more than 2 pulses at a time though. It also gives 8 pwm outputs. so an 8-9 channel mixer is do-able with 1 chip if you don't need to do much anything else. Maybe I am trying to do too much but I just want to combine all the things I'm doing now plus a few more into 1 system. I'm getting some help from Atmel on the FIQ so maybe there is still hope.

Donald

JimDrew

Dec 03, 2007, 09:10 PM

250 nsec resolution = 12 bit not 16.

250ns is 16MHz. 12 bits is only 4096 steps, which would be only 1.024ms of time... not enough for single channel, not to mention an entire frame.

teamdavey

Dec 03, 2007, 10:45 PM

That is my point you are capturing at 12 bits so the 16 bit capability of your "channel" is meaningless.

But you knew that :D

Alan Hopper

Dec 04, 2007, 04:42 AM

Donald,
As I said before, if you are using pcm1024 there is only new data per channel every second servo output pulse. The only downside of capturing the paired channel alternately is that you would add 14.25 ms latency to one of them.

A simple trick to reduce the effect of missing the second pulse during the interrupt in your solution would be to poll the input once or twice in the interrupt handler. Not perfect but it might bring things close enough.

Alan

shanghai_fool

Dec 04, 2007, 06:39 AM

Thanks Alan. That explains why the channel 2 pulse was so jittery on the scope. I will get my 10 PC boards tomorrow so I was practicing my SMD skills today. I have a cold so its hard to write code when your head feels like a balloon. I am not familiar with ARM assembly so its taking me a little longer to learn the syntax. I think I can do the stashes with 3 instructions. Since you don't have to switch stacks and other chores with the fast interrupt, it should be possible to do in 5us.

Am I correct that 5us is the smallest change I should expect? That was the smallest change I could get from my transmiter. I couldn't get that with the sticks, only with the trim tab. Maybe my fingers are just too old. I'm not sure where the "1024" comes in if the resolution in the pot isn't detected that small. At ±512 us, there should be a detectable 1us change. Maybe thats just the theoretical in the coding, not in actual ptractice.

Alan Hopper

Dec 04, 2007, 07:06 AM

Donald,
I don't know the resolution your receiver uses for its pwm outputs, however looking at my decoded pcm I have no problem creating a 1us change by small stick movements. I did notice that the neutral position varies by up to 2us, I guess due to stiction in the sticks (cheap 6exa tx!).
Alan

JimDrew

Dec 04, 2007, 09:11 AM

That is my point you are capturing at 12 bits so the 16 bit capability of your "channel" is meaningless.

But you knew that :D

Huh? I don't think you would be fly too well with only 12 bits (1.024ms) of data! Servo pulses can be more than double that length!

teamdavey

Dec 04, 2007, 10:49 AM

Thank you for confirming a theory about XPS operation.

JimDrew

Dec 04, 2007, 01:43 PM

LOL!... this is old news. :)

kbosak

Dec 06, 2007, 08:38 AM

I know for fact that you can easily decode the PCM datastream with a 4MHz PIC. This holds true for Futaba PCM (such as Alan shows) as well as JR's and Airtronic's versions. It only requires a single capture/compare register and an interrupt handler.
1. Single capture/compare register per channel or in total?
2. On 16F877 I see only the following pins to be able to trigger interrupt-on-change:

"Microcontroller Core Features: (...) Interrupt capability (up to 14 sources)"
"Four of the PORTB pins, RB7:RB4, have an interrupton-
change feature. Only pins configured as inputs can
cause this interrupt to occur (i.e., any RB7:RB4 pin
configured as an output is excluded from the interrupton-
change comparison)."
So even this method shows that the cababilities of PIC are numerous in the datasheet but limited in numbers at the pins.
At the same time I see 8 external interrupt pins for ATMEGA128.
for atmega 162 (as easily available as midrange PIC), I see only 3 ext. intr pins, but
"The External Interrupts are triggered by the INT0, INT1, INT2 pin, or any of the PCINT15..0 pins.".
The more I learn the less I like about midrange PICs.

shanghai_fool

Dec 06, 2007, 09:20 AM

I think he is referring to capturing the data stream while it is still in serial format before being decoded into channels. I went through this process before and only the Atmel ARM7 series offered IOC on every I/O pin. In the case of the 7A3, you have 32 pins on portA or 30 pins on portB, all are IOC. However, as I have mentioned here with the case of Futaba PCM and possibly others that have multiple pulses starting at the same time, there is not enough time to process 1 interrupt and get back in time to process another and have 1us resolution. It will work as Jim mentioned by alternating the interrupts on each scan. That is what I have decided to do since I aready have boards made and I want it to work with my Futaba 9C. I don't know how XPS outputs the servos in their receiver but am interested in finding out as I desire to change it to 2.4GHZ due to lack of frequency control here.

Depending on how many channels you are looking at, the 7A3 also has 9 - 16 bit timers that are capable of capturing the channels independently. If I redesign the board, I will look into that option. I am trying to do the most I can in a 1 CPU solution and the 7A3 had the most features and 62 I/O pins available. The standard IOC solution works very well with PPM where the pulses are sent in sequence though. I'll be happy to share the design if you are interested.

Donald

kbosak

Dec 14, 2007, 01:24 AM

However, as I have mentioned here with the case of Futaba PCM and possibly others that have multiple pulses starting at the same time, there is not enough time to process 1 interrupt and get back in time to process another and have 1us resolution.

I fully agree with your approach and analysis, however after re-thinking the situation, my specs are even more demanding glitch-wise: I want to capture any servo signals, where 8 among them are coming from Futaba receiver, but for example the 9th other one is futaba processed by gyro, 10th comes from Co-pilot (verrry handy, would optionally use co-pilot as extra input to my future autopilot without tinkering) etc. this way any PWM failing or raising edge can collide with any other edge from another channel. Futaba PCM was is just an exercise. Apparently only 10...14xPIC10F202 SOT {ok this is a mistake, minimum is PIC12F as it has 16 bit counter, like 12F675, powered by external 20MHz clock will have 16-bit clock counter resolution of 5MHz that overflows after some 13.1072ms} each with external oscillator talking to single PIC16 can do the job. The problem is that I cannot get rid of those 10 external oscillators and the price is uncool, but the price of starter kits +FPGA software is not better. Can we drive many PICs with a single osc without problems?

The idea of alternating the channel scanned is brilliant, but frankly speaking very narrow-targeted. I am looking for something that could be simply plugged in without additional cable ordering etc. since with the board I will be changing airframe often.

shanghai_fool

Dec 14, 2007, 03:21 AM

shanghai_fool

Dec 14, 2007, 06:01 AM

If you are really serious, you might take a look at the ST10F276 but at $35 a pop might be overkill.

JimDrew

Dec 14, 2007, 07:42 AM

Your best bet would probably be to figure out how each channel is output in relation to each other. You will find that 99.999% of all receivers output their channels sequentially, just like the original PPM data. This is how our system currently works, Spektrum works, etc. I am testing new code that would output all of the channels at virtually the same time (each channel starts 32us apart - a far cry from the normal 750us-2250us spacing).

If the receiver does sequential channel outputs, there is a HUGE amount of time (at least 750us) between each output. You could easily factor in the code overhead and have a perfectly accurate capture.

shanghai_fool

Dec 14, 2007, 08:12 AM

Thanks Jim. I was looking over your XPS and I read that your receiver outputs all channels simultaneously and My Futaba 9 PCM outputs in pairs. All the other radios I have had output in sequence as you said but I was looking for a universal solution and the only one I have come up with that would work for any system is the capture/compare type of input. At least that is the elegant solution, if not the easiest or most practical. I wanted to upgrade my 9C to 2.4GHz in January so I was looking at the XPS system where I read the info.

Right now with my ARM prototype, I will continue to test the mixing algorithms and the sensors while I look for a better long term approach. I am sure there is something out there, I just haven't found it yet. Also, it's not just capturing the receiver inputs, I also need many A/D for sensors and logging as well as PWM servo outputs and other I/O functions as well. I really had high hopes for the ARM but 5us was as close as I could get with the PCM and interrupts and that just isn't good enough. By using both IOC and CC, I could get by, but its not the solution I want. It just isn't "pretty". I'm still looking, though. Haven't given up yet.

kbosak

Dec 14, 2007, 08:51 AM

I agree that solution is not elegant and is not for production. However, the problem has led me to search further. While looking for the PIC202 (PIC10F202, I presume), I find the single counter is only 8 bit. Not enough for 1us or better resolution even though you can drive them from single oscillator.

100% true, edited my initial post. I left a PIC10F202 SOT on the workbench and while unattended it grew in my imagination to a number crunching monster.

I did find the PIC24F series that all have 5 16 bit capture counters as well as 5 PWM outputs each. 2 of these would suffice and probably cheaper than 10 202's. In addition, they offer several other peripherials. I would need to take a closer look but may be sufficient for our purpose.

The problem is that PIC24 is from Troll Technology International:
-requires special version of C compiler (+300USD?), bknd C CC5X is pic 10-16, CC8E is PIC18, others are as far as I remember doubling the price and have no limited amateur version (bknd is not optimizing but generates up to 1Kops code perfectly)
-has even more stupid assembler commands that offer nothing really exciting (I prefer x86 assembler, it's like chess on 1024x1024 board)
-PIC24 has 3 weeks delivery timeframe in Polish reality and delivery must be negotiated with evil Germans by phone (for comparison excellent quality LPC2148 flew less than 24h from local electronics development company).
-AVR vs PIC10, 12,16 popularity is 10:1 ratio in Poland
-absence of free (albeit inefficient) gcc/g++ is very unkool for PICs so this is not very good for amateur anyway

Now I am moving to a concept of 16x PIC12F675SOT since I have found a cheapo source (around 1.5USD indeed) with shared external 20MHz clock generator (to be designed and learnt). The host will be ATMEGA128-16 or LPC2148 that will order all chips to latch results at given moment then will pull the result bit by bit using single wire serial protocol (3 lines per connection should suffice, 3x16 hives 48I/O, hope I will find enough fred I/O on LPC2148 or I will cut down the number of channels).

kbosak

Dec 15, 2007, 01:07 AM

Hi,
as experiments and forums confirm, Schmitt Trigger inputs in most uProcessors are insensitive to 3.2V inputs from Futaba PCM receivers. This means that I have the following options:
1. RX to 4050 buffer boosting to TTL (5V) connected to ST (Schmitt) input at uProc
2. RX to 4049 inferting buffer boosting to TTL (5V) connected to 40106 or 4584 (Schmitt inverter, also insensitive to 3.2V) then to any input at uProc
2. a. now the questions is the internal pull-up necessary/optional/desirable/sufficient or should be backed by external pull-up resistors? Note on PIC architecture the software-programmable weak pull-ups tend to be available on PORT on which are no ST options,
The use of Schmitt buffer thanks to hysteresis mainly reduces noise switching that come from low switching time but also from transients. So I suppose that on a reliable system I need Schmitt at input.
But isn't that pre-boosting with 4050 is making schmitt trigger placed after it useless
because 4050 switches the signal fast enough to make hysteresis always working one-way?

AndyKunz

Dec 15, 2007, 10:17 AM

You missed the easiest - run your micro at 3.2V.

I do not use ST's on any of my RC products (ESCs, mixers, failsafes, digital switches, etc.). The external pull-up is essential, though, as the PIC's weak pull-ups are just too weak. 4K7 to 10K are what I typically use.

If you are going with PIC, use an LV type to have specified operation at 3.2V if you are using one of their older technology chips. Using a more modern chip will help, as they are heading toward lower voltages as they shrink the die size while maintaining clock speed.

To answer your last question: Yes, it makes it useless.

Andy

AndyKunz

Dec 15, 2007, 10:39 AM

The problem is that PIC24 is from Troll Technology International:
-requires special version of C compiler (+300USD?),

The PIC24 compiler is GCC-based. Use the temporary license version. If you grab the header files from the temporary version, you can use them with the GCC PIC24 compiler (or so I'm told). The PIC32 compiler is also GCC.

If you're using mid-range PIC you can use the Hitech free compiler with limitations. You can fool it a little bit by compiling for one chip and using in another, similar one.

If you use an ARM, there are very good GCC options available.

Andy

kbosak

Dec 15, 2007, 11:08 AM

Regarding 3.3V levels,
PIC16LF87xx (this was meant to be my workhorse - at the beginning) (low voltage version) is max 10MHz, while PIC16LF87xx is max 20MHz if Vdd is > 4.5V, else 16MHz max.
PIC12F675 anc 683 - apparently no low voltage versions.

I have 2 options:
A. use LPC2148 or ATMEGA128 for capture of many channels,
B. or PIC12F for each channel and ATMEGA128 of LCP2148 as storege/management/processing host.
LPC and ATMEGA satisfies A.
PIC12F being not on low voltage is not fitting B. I will need a buffer.

Nice to know PIC24 has gcc. But then considering the availability in Poland... ATMEGA162 or 128 wins a little. cool thing PIC24 is 16 bit - it's quite a pain to disable interrupts every time I am processing shared 16bit values where the assignment could be simply made atomic at the hardware level.

The reason of not using 3.3v is that I can place the capture electronics on the other end of the cable (together with some exotic electronics or maybe unexpected noise emitters), the receiver at the other end, boost receiver outputs to 5V and be sure that the servos at the end of long wings will read the signals properly, as well as the capturing electronics. In short, more room for noise, that can be a plenty until I will discover which ESC was too cheap. Or the other way, I will be the main user of this and I want this part to be... er... foolproof!

kbosak

Dec 15, 2007, 11:14 AM

....

AndyKunz

Dec 15, 2007, 01:49 PM

I just sent myself a note at work to finish up the FPGA that will do what you need. There are enough folks wanting this that it would make a decent product to be able to share.

What brands of FPGA are easily obtainable in Poland? Or would you prefer a pre-programmed part mounted on the PCB? I think I can handle the 3.3V inputs and 5.5V outputs for you relatively easily as well if I put it on a PCB for you.

Andy

shanghai_fool

Dec 15, 2007, 07:25 PM

Andy, Please let me know how close you are to releasing your FPGA. I do not want to lay out another board if it wil be obsolete in a short time.

Also I am using the MAX3000E as level translators and they seem to work very well.
I am also taking a closer look at the ST10F276. The FPGA would, of course, make a better solution.

kbosak

Dec 15, 2007, 09:59 PM

I started to be suspicious that FPGA is the only serious way to do the capture.

Because major manufacturers are in France, in Poland we are lagging behind some 1-1.5 years in availability, I am not sure what is representative for the whole Europe, but here:
http://www.kamami.pl/?id_k1=52&id_k2=64
what is limiting is the choice od devkits. We see devkits for
Altera Cyclone II
Altera MAX II CPLD
Altera Cyclone III FPGA
Xilinx CoolRunner-II
Xilinx Spartan-3A DSP 1800A
Spartan-3A
Spartan-3AN
Spartan-3E-500
and
fitting modules
Spartan XC3S200
EP1C

Here:
http://www.kamami.pl/?id_k1=87
we see available chips

Układy programowalne = programmable logic:
http://www.kamami.pl/?id_k1=87&id_k2=76

and Mikrokontrolery (you guess what):
http://www.kamami.pl/?id_k1=87&id_k2=56

This is a very representative, realtively not too expensive and well equipped
internet shop that ships in 2 days from any city to any in my country.

I am not up-to date about the branching of the families of FPGAs so I make no resume'.

There are others like:
http://ww.seguro.pl
http://www.tme.pl
https://www.distrelec.com (those are expensive)
and one of 3 'Electronic Groceries' that run in my city (everything listed is immediately available in minimal quantities like 10-20 per type):
www.semiconductors.com.pl (you will se that except midrange pics you will not get much power, and the most powerful are ATMEGA162 - esentially student's food).

---
P.S. In order to make some laugh at the shop I can ask them for FPGAs in DIP packages ;-)
P.S.2 FYI 2.5PLN=1USD
P.S.3 take a look here: CPLD made into DIP-like module, not too expensive.
http://www.kamami.pl/?id_prod=10514 C9572XL

AndyKunz

Dec 16, 2007, 01:35 PM

I play with it at work during break, and I guess I'm still over a month out due to extremely busy schedule (shipments by end of quarter with an aggressive schedule). I would say you're better off working on your own solution right now.

I use Lattice and Altera. I prefer Lattice because we get them dirt cheap. Altera makes some really high-end parts that would allow me to easily integrate the micro with the pulse in/out module but that would further limit the usability by most guys. A two-chip solution lets both the AVRfreaks and PIC users do their own thing.

Right now it's prototyped at 16 inputs, 12 outputs. Resolution is 125ns with 16MHz input clock, but you can cut EMI and still have better performance than most servos using a 4MHz clock. Connectors take WAY more space than anything else. I use a Philips 3.3-5V level shifter for outputs. The inputs are 5V tolerant and have series R on them just in case.

Interface is SPI (to 24MHz). One chip select is for reading inputs, other is for setting outputs. When you ask for a channel status (1 byte) you get back two 32-bit readings - first duty, then period. Setting outputs is symmetrical - specify channel (1 byte) then duty & PWM.

I'll try to get a schematic posted here this week.

Andy

jeffs555

Dec 16, 2007, 03:59 PM

I use Lattice and Altera. I prefer Lattice because we get them dirt cheap.
Andy,
Just curious as to some part numbers for for the "dirt cheap" parts. I have used FPGA's in the past, but haven't kept up with pricing on them.

Jeff

AndyKunz

Dec 16, 2007, 04:39 PM

We pay about $2.50 in small quantities (under 500) for LCMXO256C-3TN100C4W for the one project I'm involved in purchasing as well as engineering.

Andy

shanghai_fool

Dec 16, 2007, 08:13 PM

Andy,
The 2 chip solution works best for me and a month or so is not unreasonable as long as I can get something out before next flying season ( sorry Australia). I do hope it isn't BGA. I'm not comfortable with prototyping them. I can work on the user programming side until then. I do have problems getting small quantity parts here but will be back in US in mid-February and can pick up parts then. If its available from Digikey, etc. should be no problem. I can also work on my model which has been sitting for some time.

I have been playing with the 7A3 and have discovered other features which I really like. Such as, the Peripherial DMA which lets several devices do DMA without CPU. It includes the A/D and SPI and other serial devices.

If you let me know the physical and I/O pins, I can get a layout done to save some time when it's ready. I will be happy to supply boards at cost to anyone in the forum.

AndyKunz

Dec 16, 2007, 10:50 PM

TQFP-100, and boards will be right off the schematic.

I'm using the SAM7X512 on one an just love it. Excellent features/peripherals.

Andy

shanghai_fool

Dec 16, 2007, 11:41 PM

It took awhile to D/L the 9MB data sheet on the 512 and it also looks good but there are a few differences.
PWM 16 bit Counters Ethernet A/D
7A3 8 9 0 16
512 4 3 1 8

There may be other differencies (in addition to memory), I have to study it.
I do like the Ethernet port but I really need the 16 A/D's for logging, sensor inputs.
Of course, its possible to add external A/D.

Donald

AndyKunz

Dec 17, 2007, 07:00 AM

For me it serves as a server (SNMP, FTP, Telnet) and runs our main application. I use 0 internal analog and 1 PWM, but even that is easily offloaded to a DAC. The integrated Ethernet interface is the key for me. All the peripherals are on SPI or bit-banged. We've actually implemented the application with ARM9 (STmicro), PIC18, and PIC33/18 combo. Not using the internal peripherals has aided me tremendously. If I were doing the project again, I would go further up the foodchain and use a Geode for the server functions.

Andy

shanghai_fool

Dec 17, 2007, 08:28 AM

That chip probably works well for the network application and there are others as well. You probably need more horsepower for faster ethernet though. It has been mentioned here that the 1 wait state required with the flash reduces the speed to about half depending on how much is actually done in the faster RAM.

Our application is basically instrumentation with only slight computing power unless we get into PID control for autostabilization. But lots of sensor inputs are required. If we can get the receiver inputs and servo outputs under control, then we can work on the rest of the system.

Thanks

Donald

AndyKunz

Dec 17, 2007, 01:38 PM

We don't need faster ethernet. One of our requirements was for minimal bandwidth utilization. SNMP is obviously best for that, but my HTTP is pretty minimal as well. Telnet performance is intentionally the same as thru a 9600 bps hard connection - that's all they customer had available on the backhaul connection for it.

Andy

Alan Hopper

Dec 17, 2007, 02:47 PM

Donald, Andy,
Can you recommend a free/cheap simulator for these ARM processors.
Alan

shanghai_fool

Dec 17, 2007, 08:21 PM

I am using the IAR (http://www.iar.com) Kickstart development system which is free but will only compile up to 32K of code. The regular system is ~$3K. I am hoping to limit my code to that. It has a built-in C-Spy simulator and debugger.

I tried using the free gcc system which does work but is more difficult for a beginner in C++ to put a system together. I don't know if it has a simulator. Atmel does have app notes (http://www.atmel.com/dyn/resources/prod_documents/doc6310.pdf)describing how to get started with the free tools.

The IAR system is very good and I don't know how far I would have gotten with this project without it. There are probably other good systems as well. There are a lot of tools and info on the DVD that comes with the EK development board. Most have free either 30 day or limited capacity starter packages.

I hope this helps.

Donald

Alan Hopper

Dec 18, 2007, 10:51 AM

Donald,
Thanks, just what I wanted.
Alan

shanghai_fool

Dec 19, 2007, 11:20 PM

Andy,
I am certainly glad you decided on SPI as the communication interface. On the 7A3, it has the PDC (peripherial DMA) which makes things much simpler. I have just been playing with the TW/I2C and it is a pain. It does not have the PDC which probably wouldn't work to well with it anyway.

Now, on to the next step, the SD/MMC controller. I am working on getting each peripherial to work independantly to learn how each functions and what each requires. After that, I will try to get all working together. I'll have to understand C a lot better before I get to that stage. All the A/D inputs seem to be working well.

AndyKunz

Dec 20, 2007, 07:57 AM

Yes, it's a pain - if it even WORKS on your chip. Atmel just released an update TWI app note last week. I pasted this out of the notif.mcu@atmel.com notice.

-------------------------------------
Application Note - AT91-AN01: Using the Two-wire interface (TWI) in Master Mode on AT91SAM Microcontrollers - Rev. B - 2007-12-12 -
http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=11269

Andy

shanghai_fool

Dec 20, 2007, 09:42 AM

That is the app note I was using although it is dated Aug. 2007. It is for the 256 so I had to make some changes. I did not have any of the devices used in the demo so I was using the LCD display from my Eagletree logger. I had seen someone decoding some of the commands in another thread. I have the display responding but have not yet been able to display data. I had to stop work to do some other things so I hope to get back on it tomorrow when I'm fresh.

What I really need to do is get the USB working well to provide a 2 way path for the user interface and program download. I did get the USB to UART working but have not been able to send but 1 character to the PC. Its a matter of understanding the C code a little better.

I could probably get the TWI to work on the EK board as it has a memory chip on board to test with but I have not gone back to the EK since I have my prototype board working.

I need to check out all the sensors and interfaces in case I need to make hardware mods for the next prototypes. I have already discovered that I need to use a better reference for the IMU as the outputs are ratiometric. I will run them off the same ref as the A/D which is a 3.0V precision reference. There are probably other changes to be made as well. So far, I am happy with the sensors I have chosen. The Freescale MPXV5004G is sensitive enough to measure the change in the elevator going from ground to the 24th floor. I did not realize that is was dual ported but after covering the bottom port it made barometric reading very well. I think the dual port will probably be sensitive enough for pitot air speed also but only testing will tell. When I get a display, I'll take a taxi ride to test it out. The IDOF5 seems to be sensitive enough without additional amplification but I do have buffer amps on them.

I'll keep plugging away so as to be ready for the FPGA. I still have lots of work to do.

Donald