lkml.org 
[lkml]   [2013]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Stupid user with user-space questions, matrix LED driving with user space code only.
From
Date
On Sat, 2013-02-16 at 14:37 +0000, Jonathan Andrews wrote:
> I hope this is the correct place, I expect to get abused.
>
> I'm trying to do a mostly soft real-time task with a very small hard
> real time element.
>
> I've written some code to drive matrix LED signs using a Raspberry Pi.
>
> Source here:
> http://www.jonshouse.co.uk/download/128x32_red_green_led_sign.tar.gz
>
>
> Since I last used linux you kernel people have fiddled with it yet
> again:
>
> Linux raspberrypi 3.6.11+ #375 PREEMPT Tue Feb 12 01:41:07 GMT 2013 armv6l GNU/Linux
>
> I'm scanning an LED display to produce a 2 bits per pixel image. The
> code simply alters the amount of time any one LED is on, for higher
> intensity pixels the true amount of "on" time is non critical.
>
> I've marked my process as realtime.
>
> My problem is that for very dim pixels the amount of "on" time for the
> LED is very critical, this is only a fraction of a percent of the total
> processes timeslice.
> It scans 100 frames of brightest, 100 frames of brighter and 1 frame of
> dim pixels for example, so 200:1 ratio of don't care much /vs care a lot
> timing !
>
> To this end I'm using a hard coded small delay instead of usleep for the
> tight timing section:
>
> // Delay for ARM without yeilding to schedular, roughly calibrated but better than usleep for short delays
> inline usleep_arm_hard(int usecs)
> {
> long int outer,inner;
>
> for (outer=0;outer<usecs;outer++)
> {
> for (inner=0;inner<300;inner++)
> asm("andeq r0, r0, r0"); // NOP
> }
> }
>
> The dim pixel code is timing critical (but as I said only a tiny
> fraction of the total CPU usage). What I need to do is grab the CPU and
> prevent any context switch (IRQ or PREEMPT) for this period.
why you want to do this?
>
> I cant find a user space mechanism other than changing the kernel to
> disable preemtion ? No simple /proc switch to turn it on/off ? If not
> why - I cant be the only one who wants to toggle preemption off without
> swapping kernels ?
you can't disable pre-emption from user space.
>
> The other issue is that of IRQs, my dim pixels on the display seem to
> flash brighter from time to time, this I assume is partly preemption
> (maybe possibly) and partly IRQ handling (more likely) allowing context
> switches or just taking a while on slow hardware.
>
> I need only a tiny fraction of the runtime to be hard real time, on
> intel in the past i've simply disabled IRQs briefly with some inline
> assembler.
you shouldn't fiddle with irq's from user space but...
> The Raspberry Pi board would also probably survive this as the only
> active peripheral is ethenet, I suspect couple of missed IRQs would not
> matter as once IRQs are re-enabled the USB/ethernet hardware will likely
> have the data or it can be re-tried. Does anyone have an example of a
> dirty hack along these lines they can share with me :-)

> Do I have any simple mechanism available to disable (or defer) kernel
> IRQ handling briefly from user space code, I suspect not but no harm in
> asking ?
Use any sysfs to disable/enable the irq. This approach is very bad but
as you said you wanted a hack.
> Thanks,
> Jon
>
> PS I'm not a kernel hacker - yes I know I could write a proper driver
> for the task but I lack any real skill and the required time !
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/




\
 
 \ /
  Last update: 2013-02-17 09:21    [W:0.044 / U:1.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site