I'm attempting to isolate a potential resource conflict on a 1280n. Based the docs, this should be okay, but I still see sporadic problems.
Are any of these incompatible with each other?
External INTs (0 to 7)
inputcaptureEx E.7 (TMR3)
SPI channel 1
TMR5
getADC
EDIT: Based on tests, apparently SPICmd (channel 1) conflicts with TMR3 (inputCaptureEx E.7). I may have missed it, but I don't see which timer SPI uses in the resource usage section.
Either way, the solution appears to be the use of another inputcapture pin to use a free timer.
Which of these could be conflicting?
Re: Which of these could be conflicting?
The SPI subsystem doesn't use a timer. Offhand, I don't see a potential resource conflict so I'm puzzled as to why the problem appears to be solved by using a different timer. Which I/O pin are you using for the chip select for the SPI transaction?pjc30943 wrote:I don't see which timer SPI uses in the resource usage section.
- Don Kinzer
I see; that would explain why it wasn't in the docs.
The CS is B.0.
Actually all of the inputcapture pins actually appear to cause a problem when the SPI is running in a separate task, so it may not be a resource conflict after all. The routine which might cause the errors is attached. When this routine is commented out from a task that runs concurrently with the inputCaptureEx task, no erroneous inputCaptureEx values result. This routine just one piece of a larger program, of course, so it may not be the cause.
The SPI is in HW, correct? So it executes atomically without requiring CPU time from the host.
I used another ZX I had laying around to do the inputcapture, and output a digital signal to the host when the pulse criteria is met (I only required a boolean outout from the subroutine), so fortunately this question is not delaying anything. It'd be nice though to not have to use a separate controller.
The CS is B.0.
Actually all of the inputcapture pins actually appear to cause a problem when the SPI is running in a separate task, so it may not be a resource conflict after all. The routine which might cause the errors is attached. When this routine is commented out from a task that runs concurrently with the inputCaptureEx task, no erroneous inputCaptureEx values result. This routine just one piece of a larger program, of course, so it may not be the cause.
The SPI is in HW, correct? So it executes atomically without requiring CPU time from the host.
I used another ZX I had laying around to do the inputcapture, and output a digital signal to the host when the pulse criteria is met (I only required a boolean outout from the subroutine), so fortunately this question is not delaying anything. It'd be nice though to not have to use a separate controller.
- Attachments
-
- SPI routine.txt
- SPI routine
- (2.28 KiB) Downloaded 2184 times
Paul