new user, need confusion suppressed

[aubug2]

My development kit showed late last wk. [Isopod, $149]. Application is as a diesel engine speed controller operating a BIG vacuum pump & associated system supervision.

1. What software version is most likely installed?

2. Would like to spend port A input for status bits, port A output for loading a byte register to store status bits - different assignments.

Haven't found any document statements of what interfacing signal can be used to put the output of a 74HC244 noninverting buffer onto the port bus during a port A input nor what is available to clock in the port A output to an octal latch; need active low when data is to be shipped.

Haven't found a statement of how long an output pin stays active after the data is sent. Hope it's a long time - would simplify the fuel on command, a few others re driver interfacing by not having to capture them when sent.

3. Have an existing 1 shot for setpoint of engine speed, a pot sets the period, want the same control on this board - can use a voltage divider to get the 5Vdc max to a 0.5 to 3 V, gets an ADC count of N = 4964 to 29782.

Need to convert these to a scaled value of 0.5 Vdc corresponding to an engine speed pickup period of 15 mS and the 3V to a period of 4.166666 mS; linearly varying between end points.

Manual says the 8 bits gets shifted, implication is it happens during the input sequence but code copy of the mini-sumo says to do a 3 bit shift after it's loaded.

What's the process with my board?

What do you recommend for count to mS conversion?

4. Need to input a speed pulse period [mostly same duty cycle] , need the edge rise time to get period made; then send a varying PWM duty cycle to a filter that controls injector pump fuel stroke. There can be maybe 30% difference in the engine torque at any speed so need a fairly wide range on the PWM waveform, think a PWM period of about 18 or so mS should do. Existing ckt uses an up/down counter driving a DAC for error correction of speed, increments / decrements 1 count per speed pulse. Doesn't have to be interrupt driven but shouldn't go more than maybe 20 pulses before the PWM gets attended & correction trend started. Time for correction is not critical but would like it to happen within about 10 sec., shorter = better. Only other overhead during speed supervision is a status check every 100 mS or so to see if an alarm happened & shut off the fuel if it did, or a speed set point change .

How would you recommend it be done? This is the killer part of the conversion, can handle the rest.


Thanks. Joe

[RMDumse]

Originally posted by aubug2
My development kit showed late last wk. [Isopod, $149]. Application is as a diesel engine speed controller operating a BIG vacuum pump & associated system supervision.


Wow. Neat application, Joe. I'll be interested in following your progress, and helping where possible.


1. What software version is most likely installed?


These days we are shipping V0.6 of IsoMax(TM) installed.


2. Would like to spend port A input for status bits, port A output for loading a byte register to store status bits - different assignments.


Sounds like you're thinking of Port A as a bidirectional bus, rather than a simple port. It can be used that way, but it's quite a bit more complicated to do.

You didn't mention Port B. Could you use Port A for input and Port B for output?


Haven't found any document statements of what interfacing signal can be used to put the output of a 74HC244 noninverting buffer onto the port bus during a port A input nor what is available to clock in the port A output to an octal latch; need active low when data is to be shipped.


Well, generally you will use one set of pins for inputs. You just read the data when you want them. You may use another set of Port pins as outputs. Again you just set them when you want to change them, then forget them.

Now if you want to read multiple sources, say on Port A, you could use several HC244's, and other lines to enable on or another. These other lines could be Port B lines, or even the extra Port E lines on the SPI connector. In this configuration you'd set one of those control ines low, and then just read Port A, and return the line high. To read another one, change the control bits and set a different one low, and read Port A again, and so on. This would be treating the Port A more as a data bus port, than a general purpose I/O port, but it is certainly a reasonable thing to do to expand the inputs possible on a single port.


Haven't found a statement of how long an output pin stays active after the data is sent. Hope it's a long time - would simplify the fuel on command, a few others re driver interfacing by not having to capture them when sent.


Yes, the Ports are latched, so if you write to them, and make them outputs, those outputs stay latched until rewritten, changed to inputs, or power cycles.

And as above, if you want to make the port into a byte input and byte output port, using a few other port lines for control, you can do that as well. You'd write a value to the port, then strobe some external octal latch to keep the data.


3. Have an existing 1 shot for setpoint of engine speed, a pot sets the period, want the same control on this board - can use a voltage divider to get the 5Vdc max to a 0.5 to 3 V, gets an ADC count of N = 4964 to 29782.


So, if I understand, you want to use a pot as an input? I'd power the pot off the GND to 3.3V lines, and run that straight into the A/D. Then you don't have to worry about doing a divider to get it down from the 5V range.


Need to convert these to a scaled value of 0.5 Vdc corresponding to an engine speed pickup period of 15 mS and the 3V to a period of 4.166666 mS; linearly varying between end points.



Let me be sure I'm following. You have a set point pot. it will go into the 'Pod on an A/D channel. Also you'll have an engine speed pickup. The object is to read the set point, and adjust a PWM output to control speed, then read the engine pick up to know if you're low or high. Am I following?

If I am, then when the set point is at the low end (.5V) the engine speed should be pulsing every 15mS and when the set point is at the high end (3V) the engine speed should be pulsing every 4.16mS.

The timers on the 'Pod are really excellent and have many useful modes. They can be set to look for the time period between rising edges, and so I think we can measure the engine speed very easily with these.


Manual says the 8 bits gets shifted, implication is it happens during the input sequence but code copy of the mini-sumo says to do a 3 bit shift after it's loaded.

What's the process with my board?


The A/D is left shifted so the upper bits are significant. If you don't want them left shifted you can do the 3 bit shift to get them right justified instead.

Generally, A/D's are doing this left justified thing as to be compatible whether you read an 8-bit 10-bit or 12-bit (etc.) version. The most significant bits are in the same place across all these A/D's

So the hardware delivers them in the upper bits, left shifted. You can do with them what you want. Use the that way, of shift them down like the Mini-sumo did.


What do you recommend for count to mS conversion?


As mentioned the timers on the 'Pod can be set to look for the time period between rising edges. They can count up to 40MHz at their fastest. We will probably want to set their prescalers down so they count at least a period larger than the longest pulse we might want to measure.

They are 16-bit counters. So a 65536 count of the 40MHz IP clock (40,000,000/2^16) would give 1.6mS before overflow. Too fast. If we had a prescaler of 16 on the timer, we could count a period of 26mS before overflow. This is nice given the engine speed range signal you suggest.

So we set a timer to capture on rising edges, and measure the number of counts between their occurances.


4. Need to input a speed pulse period [mostly same duty cycle] , need the edge rise time to get period made; then send a varying PWM duty cycle to a filter that controls injector pump fuel stroke. There can be maybe 30% difference in the engine torque at any speed so need a fairly wide range on the PWM waveform, think a PWM period of about 18 or so mS should do. Existing ckt uses an up/down counter driving a DAC for error correction of speed, increments / decrements 1 count per speed pulse. Doesn't have to be interrupt driven but shouldn't go more than maybe 20 pulses before the PWM gets attended & correction trend started. Time for correction is not critical but would like it to happen within about 10 sec., shorter = better. Only other overhead during speed supervision is a status check every 100 mS or so to see if an alarm happened & shut off the fuel if it did, or a speed set point change .

How would you recommend it be done? This is the killer part of the conversion, can handle the rest.


PWM can be generated by the timers, or the hardware PWM outputs. As with most of the other features of the 'Pod, these can be set and forget. If you set up a rate and it doesn't need to be changed, you leave it along and it keeps generating it. It's easy to change as needed as well.

An 18mS PWM period would be 55Hz. The slowest the hardware PWM outputs can go is 76Hz without slowing the CPU's IP clock. Can we go faster than 55Hz? If not we should use a Timer, which has more prescaler options, and still generates nice PWM.

Well, pls let me know if I'm understanding your problem correctly. If I am, then we can work on the details of setting up the timers and PWM.

[aubug2]

2. You've talked me out of splitting port A functions - have 8 bits assigned as inputs, [port A], 8 bits as output status [LED drivers] to the control panel [port B], 5 more for system excersize - fuel on, engine fans relay coil [10 sec startup delay to keep from pulling an extra 120 amps out of the battery while starter is on], chopper drive [in cabinet test feature to simulate the speed input under s/w supervision; see if it can get the speed regulation before attempting an engine start], injector pump stroke control [PWM] & oil pressure indicator to the control panel [loss of oil pressure enough to let the pressure switch close causes fuel shutoff; have to grind on the starter long enough to get oil pressure before fuel comes on]. Will spend individual bits of port E for those.

3. Speed setpoint pot will stay wired to a separate cabinet 5V supply routed thru the system control panel [want it to be compatible w the existing discrete card] so don't mind spending a dime for a voltage divider to get the range scaled.

You're following just fine.

26mS prescaling looks good. Even allows the RPM to get reported thru SOUT to the 2 x 16 LCD during idle warmup & cooldown sequence [req'd to dry out the blower - uses water injection supervised by a programmable controller to limit outlet temp & keep the lube temp in spec; $7,000 liability if it dies + down time loss of revenue, 2 - 4 wks waiting on the blower factory].

4. PWM will continually drift according to operating conditions so during the 'run' mode, need it to track within parameters above.

Operator expects to dream up a setpoint after looking at the job [yeah - van mounted, 12Vdc primary power source]. After code testing, will use Ignition ON to supply a 7808 for Isopod power, makes another layer of noise isolation.

Gets on site, reels out stuff while in idle, comes back & sets 'run' mode, speed; goes away to work. When finished, puts stuff back while in cooldown, gets paid & when cooldown is complete the system shuts down automaticly, maybe while enroute to next stop.

Prefer to deal w a timer rather than doing CPU speed changes, less risky.

For the first pass - you did just fine. Thanks.

[RMDumse]

Originally posted by aubug2
You've talked me out of splitting port A functions - have 8 bits assigned as inputs,... 8 bits as output status ... 5 more for system excersize... Will spend individual bits of port E for those.


You've got lots of I/O available on the IsoPod(TM) so you shouldn't have to worry about multiplexing things up on ports.

PWM should come off the timers or the PWM pins.

If you don't use the PWM for anything else, they have extra current capabilities (at least 15mA which is enough for most indicator LED's), and so, maybe you can drive your panel LED's directly with them, and save the Port B lines and remove the need for external buffers. Just a suggestion.


Speed setpoint pot will stay wired to a separate cabinet 5V supply routed thru the system control panel [want it to be compatible w the existing discrete card] so don't mind spending a dime for a voltage divider to get the range scaled.


Yes, so this is the control side of the loop. We can set up your SCHEDULES-RUN to operate at whatever repetition rate you need to run the control loop.


26mS prescaling looks good. Even allows the RPM to get reported thru SOUT to the 2 x 16 LCD during idle warmup & cooldown sequence [req'd to dry out the blower - uses water injection supervised by a programmable controller to limit outlet temp & keep the lube temp in spec; $7,000 liability if it dies + down time loss of revenue, 2 - 4 wks waiting on the blower factory].


Well, we can set a 26mS loop time, but really, I just wanted to be sure we'd have enough counts in the timer we set up to capture the whole pulse to pulse time. But this is again set and forget hardware. Our main loop doesn't have to be limited to this. It can be slower or faster as we like, since the hardware of the timer is going to capture this pulse time for us, if I can figure it out just right.


4. PWM will continually drift according to operating conditions so during the 'run' mode, need it to track within parameters above.


The control with the counter moving up or down sounds a bit like a very slow follower. We can get fancier if you like. We can even try to do a PID control if you want. Or something as simple as a P loop (just a proportional response) or we can make something that will match the response of the system you already have.

The processor is way fast enough to handle any of these approaches.

[aubug2]

Will check driver count vs function needs re PWM pins to run LEDs. Looks like I could do a cable from the port to the main card connector & save a discrete driver platform & socket.

Re 26 mS - think the idle speed would fit in a 20 mS interval - the .5Vdc corresponds to 1,000 RPM & it should be adequate range. Besides - don't need to speed control during idle & cooldown.


Re slow follower - don't have the actual system response yet, op'n by nature has lots of reserve vacuum capacity so can live w a tracking correction time of several seconds & the operator won't be capable of detecting any change at the end of a 100 ft hose. Can't expect instant response from the amount of rotating mass here.

Have a fun wk end. Back Tue.

[lat]

Free ideas:

If you need to make note of an input line which is active a shorter time than the IsoPod VPMA repetition rate, some of the GPIO inputs can be setup to cause an edge-triggered interrupt.

Also, I remember that some pairs of the 16-bit timers can be chained to act like a 32-bit timer, if you don't want to reduce your timing accuracy.

Finally, some hardware can easily turn a 76 Hz repetition rate PWM into a 38 Hz repetition rate -- just ignore every other pulse (but one would want to NEVER use 100%, and the maximum output would only be two counts less than 50%). ;)

[aubug2]

Re last on thread - would like the scan rate to be 76 - 100 Hz. Nothing happens on the status inputs that needs a quicker update. Most rapid change would be loss of oil pressure. Would then do a fuel shutoff; lots quicker than coast down under load. Any of the other 4 alarms would happen in a random manner, same action, looser time for shutdown.

Re timer accuracy - can't see how chaining will help since the allowable variance is so wide - is more important to get a quick responce to the speed pulse train; can live w some overshoot. Time constant for the PWM speed control output should be about 20 mS so there could be a lag of 5 - 10 pulses to get a correction completed - 10 @ 5 mS would be 50 mS elapsed, 200 Hz correction rate - better than anybody else's, lots better, more sensitive than the centrifugal governor in older injector pumps. If it's working right - error magnitude drifts smaller as the correction proceeds so what little overshoot might accumulate would get masked by the set point resolution of maybe 3600 / 256 = 14 RPM [for 8 input bits - actual 12 would be 14 / 16, under 1 RPM]. Client will be happy if it stays within 100 RPM for a full range change in load; can respond faster than the load changes so believe the net drift should stay under about 30. A 5 mS RPM period setpoint [3000 RPM] & a 30 RPM variation would be a period shift of 1% or 0.05 mS; likely have that much variation between pulses while on speed - relies on 4 stamped gaps on a plate bolted to the crankshaft.

[RMDumse]

Copied this out of the user manual for you:


The IsoPodÔ can also measure pulse-width-modulated (PWM) square waves on the 13 timer pins:

TA0 TA1 TA2 TA3
TB0 TB1 TB2 TB3
TC0 TC1
TD0 TD1 TD2

The commands to measure a PWM pulse width are

pin SET-PWM-IN to start measurement, and
pin CHK-PWM-IN to get the result.

SET-PWM-IN makes the specified timer pin an input, and puts it into the pulse-width-measurement mode. It will do nothing until it sees a rising edge on the input. Then, it will measure the time that the input is high. The falling edge after a rising edge ends the time measurement.

CHK-PWM-IN gets the result of the time measurement. If the rising edge has not yet been seen, or if the “high” width is still being measured (i.e., the falling edge hasn’t been seen), CHK-PWM-IN will return a value of zero. After a complete pulse has been received (rising edge, then falling edge), the first use of CHK-PWM-IN will return the width of that pulse, which will be nonzero.

BEWARE: if you then use CHK-PWM-IN again, without resetting the timer, you will get an unpredictable nonzero value. Only the first nonzero value returned by CHK-PWM-IN is valid. After you receive that value, you must reset the timer with SET-PWM-IN.

The value returned by CHK-PWM-IN is an unsigned integer, representing ticks of a 2.5 MHz clock. This is the same timebase used for PWM output. Each tick of this clock takes 0.4 microseconds. So, the measured pulse time can be computed with the formula

microseconds = N * 0.4

If you measure a pulse input of 25000 decimal, you know that this is 10 milliseconds.

The PWM measurement has been divided into two actions (“set” and “check”) to avoid the problem of Program Counter Capture. We don’t want our IsoMax program to sit waiting for a pulse to be measured -- especially if the pulse never arrives! Instead we have two commands, SET-PWM-IN and CHK-PWM-IN, which are guaranteed to always execute immediately. You can test CHK-PWM-IN to cause a state transition when the pulse has been received.

[RMDumse]

So, notice, the counts returned by CHK-PWM-IN are in .4 microseconds so the maximum count as this is set up will be .4 * 65536 or 26mS. Looks like it will fit nicely as already provided in the language.

[aubug2]

Need to derive the time between rise [or fall] & next pulse rise of speed input pulses. Can skip alternate ones for processing but would be nicer to get the math done during time waiting for next pulse. Believe the input duty cycle to be on the order of 10% so could get a good enough approximation by using the 90% part instead of spending 2 inputs & adding to get total period. Whatever mismatch in the ADC speed setting occurs only would need a bit different speed selection for a successful ADC count compare re the speed pulses. Then need to add to the output PWM high time if underspeed / shorten if over setpoint. [Low count corresponds to idle setpoint].

Q. Would implementation be easier if the 90% D.C. format is used or can you think of an easy way to get the period directly?

Q. Can you select whether the rise time or the fall time triggers first ? - equivalent of s / w inversion of the input voltage; a round about way of asking - do I need an input pulse inverter in the interface? Current design uses a limit resistor & zener to clip the signal swing.

[nmitech]

(Section numbers refer to the DSP56F801-7UM User's Manual.)

1. The standard SET-PWM-IN and CHK-PWM-IN words use Triggered-Count mode
(14.6.7) to start the counter on a rising edge, and Capture on Falling Edge
(14.7.2.9) to read the counter. To read the period, I would use continuous
Count mode (14.6.2) and write a word to watch for successive captured edges.
Note that you'll have to read the capture register twice and take the
difference. Also, you'll have to reset the IEF flag after you read the
captured value. Unfortunately, this will require the program to wait for the
first captured edge, so it can't run in the "background" while the processor
does other things.

For reference, here's how the existing words are defined in IsoMax. BASEADDR
is the starting I/O address of the particular timer; the other labels are
timer registers.

\ The timer inputs can be programmed to measure time between input
\ transitions. This method will switch the given timer to the
\ triggered-count mode, and count two successive transitions on the
\ input pin.
\ Triggered-Count mode (count from rising edge to next edge)
\ | Count source IPbus/16
\ | | Secondary input (controls counter)
\ | | | Continuous Count
\ | | | | Roll over (don't reinitialize on compare)
\ | | | | | Count up
\ | | | | | | assert OFLAG while counter active (not used)
\ 110 1100 xx 0 0 0 0 000
\
\ xx indicates the input pin to be used. 00=Timer0, 01=Timer1, etc.
\ This can be computed from BASEADDR[4:3].

: SET-PWM-IN ( -- ) \ measures time that input is active
E000 TMR_CTRL CLEAR-BITS \ stop the timer while changing mode
0000 TMR_CNTR ! \ clear the count
0000 TMR_LOAD ! \ clear the load register
0 TMR_CAP ! \ clear the capture register
FFFF TMR_CMP1 ! \ set compare for maximum count
TMR_SCR @ 202 AND \ preserve the polarity bits...
80 OR TMR_SCR ! \ clear the FORCE bit, disable output pin
\ clear Input Edge flag, disable interrupts
\ capture mode = 10 = load on falling edge
BASEADDR 18 AND 10 * \ get timer input number (xx), shift left
D800 + TMR_CTRL ! \ set timer mode per above, enables timer
\ Timer is now waiting for a positive(*) transition to start counting
\ from zero. Next transition (?) or compare will stop counting.
\ Capture register is waiting for a negative(*) edge.
\ (* invert if ACTIVE-LOW)

: CHK-PWM-IN ( -- count )
TMR_SCR @ 800 AND IF \ check Input Edge Flag
800 TMR_SCR CLEAR-BITS \ clear Input Edge Flag
THEN
TMR_CAP @
;


2. The word ACTIVE-LOW applied to a timer pin will give a software inversion,
e.g., TA2 ACTIVE-LOW. ACTIVE-HIGH will restore normal operation. (These
change the IPS bit in the TMR_SCR register.)

[RMDumse]

So, it's been a while since we've heard. How is the project going? Can we be of more help?