OK, here are some AtoD converter ideas -
Quote:
Originally Posted by MPaulHolmes
To get the resolver board to work, you would replace the encoder initialization with configuring 2 of those inputs as A/D inputs. Then, maybe you could do these 4 A/Ds:
throttle
CURRENT 1
CURRENT 2
RESOLVER 1
and then one time of this:
THROTTLE
CURRENT 1
CURRENT 2
RESOLVER 2
and then back to this:
throttle
CURRENT 1
CURRENT 2
RESOLVER 1
The trouble is, AN0 is throttle, AN1 is current 1, AN2 is current 2. For the 4 simultaneous samples, AN0, AN1, AN2 must be together, and then ANx is the most flexible. unfortunately, I chose AN0 to be throttle. It would have been better to have throttle be ANx (for some x not equal to 0, 1, or 2) since it doesn't have to be done as often.
The noise on the throttle is maybe +/- 1 (sometimes 1.5) A/D ticks out of a range of 1024, which doesn't need a whole lot of oversampling.
So, we could either alternate with resolver 1 and resolver 2 (I'm sure you could infer about the angle by getting alternating sine and cos values for the angle), or you could move the throttle with a little wire over to ANx, and then wire, say, resolver 1 to where the throttle used to be, and then once every 32 times check the throttle, and 31/32 times check resolver 2?
edit: maybe the alternating sine and cos isn't so bad... the only time you need both pieces of info is when you aren't sure about what quadrant you are in.
|
I hate to say this, because it's also a hardware issue.
I think it would be best to move the throttle down among stuff that isn't hyper time dependant. Yes, the throttle is one of the most important feedback devices connected to this controller. However, it's not going to change so fast that it needs to be checked on a PWM frequency level.
This does look like it's going to be a pain from a setup level. I was really hoping the QEI interface pins would simply be exchanged for AtoD pins, with one extra pin left over.
You are right about just needing both to figure out what quadrant you're in. That could be very beneficial. I was hoping the ultimate advantage of a resolver would be that sin and cos would not need to be derived, just measured from the resolver. It really does look possible to do this as I look deeper into your FOC code.
I'm a little leery about sharing input pins. Technically it sounds very do-able, but one would have to be very careful about what cycle the code is on... If the code was expecting a throttle value and instead got a resolver value, what would happen?? Could there just be some bit of code to check whether an outlier happened?
This may bring up an opportunity - again, just thinking aloud - would it be possible to have certain inputs changable in hardware via jumpers to account for different set-ups? For example, my demo board uses two different sets of uart pins depending on which jumpers are chosen. If jumpers aren't reliable, it seems possible to have different 0 ohm solder in place jumpers, or something.
I'm very seriously trying to figure out a dual user-input setup. ( throttle/brake or throttle-throttle override ) The other possibility is that OE throttles like the Prius throttle have two outputs for a safety feature. In other words, having an extra analog input pin or two would be a very good thing.
I have no problem with modifying my current board(s) to re-route the throttle input. The configurable input might be a nice thing to add to the rev3 board.
- E*clipse