Stefano Moratto wrote:
I'm helping Georg, and this is the modification I made to raspiraw http://pastebin.com/QFwAgxu1
It is basically the same program; I added command line parsing in order to get the image's height and the registry settings functions.
I'm able to get images having height from 1944 to 80 pixels. Below 80 the handler's function is never called.
OK, that all looks vaguely sane although I haven't tried it myself. (I do object to a variable called "HEIGHT" though. Defines in capitals, variables in lower or mixed case, otherwise you confuse people.
Do you actually get the frame rate increase you're expecting with height 80? I know there are other registers which control related values and I'm not sure you have got them all.
I've checked the code handling the CSI2 peripheral. It has a slightly too simplistic approach to how many interrupts to produce per frame by taking height>>3 as the line interrupt frequency. In your case that will result in the crazy number of every 4 lines or 130usecs (each line is ~32.5us). It may be running an RTOS, but that is excessive. I guess I wasn't expecting people to be running at quite such a rate.
I will make a patch to the rawcam component to set the line interrupt rate to something more sane (probably 16). There are a couple of other patches waiting to be released, so I'll throw that at Pi Towers now in the hope it'll make an rpi-update release in the next day or so.
You can enable the GPU logging from the rawcam component by doing "vcgencmd set_logging level=0xc0", and "sudo vcdbg log msg" to read it. I doubt you'll be able to read it reliably whilst rawcam is running as the circular buffer will be written faster than the ARM is extracting it, so do a test run, stop it, then grab the logs.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.