Quote:
|
Originally Posted by Astronouth7303
Why not connect the PWM outs from the '03 EDU to the '04 EDU PWM ins? Basically do the same thing you already are, just remove the programming hassle. The only thing I don't know is what wires to connect (Ins are 3, outs are 4). The volatages should be safe (The hobby recievers only use up to 6v, the IFI EDU motors are expecting 5.5v to 8.6v).
|
According to IFI, connecting PWM OUTs to PWM INs
may cause unreliable operation, and as of now they're not guaranteeing it.
I talked to IFI tech support about this last fall. The stated reason this may be unreliable is that the CPUs implement PWM OUT with separate hardware, and PWM IN by a scanning technique. IOW, the PWM outputs don't all come out at the same time, and the PWM inputs are checked one at a time.
AFAICD, the
real problem is that PWM IN is NOT an interrupt based technique. The CPU has to wait for data input, and if asked to wait too long simply assumes the line is unconnected and ignores it.
According to IFI, the asynchronous nature of this CAN make things unreliable. It WOULD be OK however, IF your order of checking things MATCHES the order in which it is SENT. Otherwise, in certain input/output pairings, you COULD end up with either "old data", or consistently missed data on specific lines due to timeouts from asking it to wait too long and the '04 CPU assumes the line is unconnected.
There's a couple of ways this can become an intermittent problem:
1) The PWM IN on the '04 EDU scans the inputs in order (R/C radio decoders send out their pulses one at a time, in order), and the '03 PWM OUT does NOT send them out in order, causing missed data in SOME pairing cases.
2) We may hit INTERMITTENT timeouts in some data cases. Bear in mind that the data is encoded by pulse WIDTH (PWM = "Pulse WIDTH Modulation"). IOW, for example in a wiring that makes a marginal timeout situation on channel 6, if channels 1-5 ALL have long data (2ms end of the 1-2ms scale), the cpu may be waiting too long for input of data on channel 6, and timeout OCCASIONALLY. I don't know if this IS the case here, but it is a known potential problem with CPU scanned techniques of R/C systems, that would need to be verified by IFI.
Now IFI said that the solution was that THEY would need to tell us how to match the firing order of the PWM OUTS with the scanning order of the PWM IN. However, they refused to state what that WAS at that time, since they'd have to VERIFY it, and they were too busy right then trying to get ready for Kickoff. They DID promise me that "when they had time" they'd review the situation and put out an app note outlining the EXACT pairings to GUARANTEE reliable operation. <Checks IFI site> I see they still don't have that in their doc, whitepaper, nor FAQ areas yet, so either they haven't Gotten a Round Tuit yet, or it simply never worked for THEM.
If IFI isn't going to document this, and you DO wish to try this technique, what we'd need to do is to figure out if such a matching is possible, or if the '03 CPU
changes the PWM OUT firing order with time because of multiple pieces of asynchronous hardware driving the PWM OUTs, introducing the POSSIBILITY that things would run fine for a WHILE, yet may suddenly flake out on you LATER. (I hate those kinds of "bugs"..)
A test for you: Has anyone 'scoped the '03 PWM OUTs with a multitrace oscilloscope yet, to get a sense of the order in which they fire? If so, please comment on that.
If you decide to try this test, put the EDU on a power supply, reboot it a few times to see if the order changes, and also leave it running for a few hours (or days) to see if the order changes over time (both tests help detect two or more asynchronous pieces of hardware sending data out on different ranges of PWM OUT lines).
*IF* a consistent firing order can be determined, simply match it. I'd assume the '04 CPU most likely scans the PWM inputs in order. That's the simplest case.
If the firing order is NOT consistent (changes with time), the ABSOLUTE worst case scenario I can think of is it will take a piece of hardware to capture all PWMs
regardless of order sent, and either "regenerate" them in an order that the '04 CPU is happy with, or simply sends the data in via the serial port to the '04 EDU. (IOW, another PIC in between them...) I hope it won't come down to that, though...
But, is this even worth the time? Short of reverse engineering the interface and firmware (IFI won't release schematics nor internal code), if IFI won't even guarantee consistent operation, I'm not sure this is a smart way to interface them. You could have a robot that goes out of control on occasion.
Didn't someone get a '03 EDU / '04 EDU combination running RELIABLY last fall with a serial technique? I thought someone tied the two serial ports together and ran a small program in the '03 that shoved the data out the serial port to the '04 EDU serial port, but I never saw the code posted for it. If so, let's stop wasting time with this whole PWM OUT/IN interface technique.
Can someone simply please point us to the wiring AND the code required on both CPUs to go serial?
Thanks!
- Keith