Possible resource conflicts

[FFMan]

as various single function prototypes get the green light I am thinking about combining the several functions into one device using a zx40n. Reading the documentation I wonder if I have some resource conflicts that maybe an issue or that i need to consider use of particular pins for ?

The main contenders are:-

GPS @ 5hz running on a hardware uart
Waitforinterrupt looking for an infrequent pin change
Inputcapture counting engine rpm data

On the face of it, it should all be ok but have i missed something ?

thanks

[dkinzer]

I wonder if I have some resource conflicts [...]?

There are no resource conflicts among the those that you mentioned. Using InputCapture(), however, means that you won't be able to use any other timed I/O routines (see the table on the page below).

http://www.zbasic.net/doc/ZBasicSysLib.php?page=22

[spamiam]

GPS @ 5hz running on a hardware uart
Waitforinterrupt looking for an infrequent pin change
Inputcapture counting engine rpm data

I have one thought about measuring the engine RPM. The input capture function will work, but it records lots of data, and you are likely not to need such high resolution.

When I measured somewhat similar data, I only needed to average the value over a relatively long time. All that inputcapture() detail wastes RAM and processor overhead.

In my case, I had exclusive use of a timer, and used it as a counter for the external signal. It would count the number of edges on the signal, and periodically I would read the value, and calculate the average. I used an integer with enough bits to store the worst case number of counts.

For the inputcapture, you need to reserve a long array then service the array before it overflows. You need to read every other entry in the array, and average them. You are likely to need to do this several times before you have the average over the appropriate time period. This is a lot of work! But you may not have a timer/counter available for your exclusive use.

It would be useful to be able to hook into the i/o timer interrupt for user code.... I do not know of a ZBasic function that provides this functionality, but Don thinks of everything, and he may well already have something for this! If such a thing were possible then you could have a simple state machine to poll a pin and then increment a counter if there is a low-to-high (or vice-versa) state change. It would be a quick function without a huge amount of extra overhead.... I think that the I/O timer runs at a high enough speed that it is unlikely to miss engine tach state changes.

-Tony

[FFMan]

thanks for the reply

however i think i can achieve a basic rpm reading in 2 lines of code (the input capture & the calc on one reading).

If this proves to be not accurate enough I'll do some averaging, but in essence i was going to have a small table for inputcapture and run the capture every tenth of a second to produce a reading.

the processor will be busy doing other stuff too so simple is good in the application as its just to drive a shift light.