How to enter FIQ mode in assembler?
Neil Fazakerley (464) 124 posts |
I’m working on a single-tasking Basic project that uses the R-Pi/BBxm GPIOs for some short bursts of fast pulse output trains generated in assembler. The pulses need to hold their timing to within 3-4 usecs. A scope shows regular waves of timing gitter running through them, which I assume are caused by all the various interrupts running in the background. Using OS_IntOff makes little difference to them, so I guess these must FIQ interrupts. As these pulses will only be needed for 5-6 msecs bursts from time to time, I’d like to try them running in FIQ mode to see if that produces more stable output timing. I haven’t coded in FIQ mode before and the various manuals are a bit vague on the subject, so could can anyone supply a code fragment of the top and tail routines required to enter and leave from user mode? I’ll be sticking to R0-R7, so won’t need to use any of the _FIQ registers. I will need to use Druck’s TimerMod SWI inside the code though, if that affects anything. Cheers, |
Rick Murray (539) 13840 posts |
I am wondering if times like this are when you need to evaluate the code for timings, down to cache misses and the like? Are you sure your code in its various paths takes exactly the same length of time, down to exact cycle counts? |
Jeffrey Lee (213) 6048 posts |
The OMAP3 ROM doesn’t use FIQs for anything, and the Pi has only started using them a couple of days ago. So unless you’re running the latest Pi ROM there won’t be anything using FIQs. Have you considered that the jitter you’re seeing might be down to memory accesses by the GPU? Try blanking the screen while your code is running and see if that helps. |
Dave Higton (1515) 3526 posts |
If you need accurately repeatable timing for a series of pulses, you might save yourself a world of pain by having a dedicated hardware subsystem to do it for you. Programme it with the required information and fire it. Depending on details of your requirements, you might get away with a small microcomputer without any OS. For rock solid results, programmable logic is the best – an FPGA or PLD. |
Rick Murray (539) 13840 posts |
…a PIC? :-) |
Dave Higton (1515) 3526 posts |
If you must… Joking aside, there are lots of choices in ARM processors. Even the lowly LPC1114 might be enough for this job. It’s cheap. There is a complete free set of tools available. |
Rick Murray (539) 13840 posts |
Indeed. A small MCU given this as a dedicated task should perform it well enough. My video recorder (PVR) uses an MSP430 to handle the IR stuff partially to offload the work from the main processor, and partially because a secondary processor can devote its entire self to the task of interpreting the IR commands1, something you just couldn’t do reliably if running an OS, recording video, etc etc… and it’d then just interrupt the main processor when it has something to say. 1 It’s a little more complex than just understanding its own remote; it provides an IR ‘blaster’ function so it is supposed to be capable of learning IR commands2, condensing them down to a short bitstream, replying that bitstream later, all while being spot-on with the pulse timings. 2 It could learn my VHS video recorder, but it got totally flummoxed by the satellite receiver. The difference? The VHS controller sends one command per button push. The satellite receiver sends the same command repeatedly and something in the receiver sorts it out. 3 One could say it holds true in bigger contexts as well – what’s inside the Pi? Neon for fast FP, VFP for slower FP, a GPU for clever graphics stuff…..all performing their tasks well and allowing the ARM to pass ‘difficult’ operations to dedicated devices that specialise. The FPU would suck at executing a telnet client (if it was even possible), but working out realistic merge/blend patterns for a “healing” paintbrush in a graphics program? That’s numbers. That’s something it can do. |